Il modello Entity-Relationship persona Ente lavoro impiegato datore Il modello Entity-Relationship

Modello Entity-Relationship (Entità-Relazione) Proposto da Peter S. Chen nel 1976, rappresenta uno “standard de facto” per la progettazione concettuale di una base dati Ha una rappresentazione grafica Esistono molti dialetti E/R, che spesso si differenziano solo per la notazione grafica adottata (es. modello EER = enhanced E/R) Il modello Entity-Relationship

I costrutti del modello E-R Entità Relationship (relazione, o associazione) Attributo Identificatore Generalizzazione …. Il modello Entity-Relationship

Il modello Entity-Relationship Classe di oggetti (fatti, persone, cose) dell’applicazione di interesse con proprietà comuni e con esistenza “autonoma” ai fini dell’applicazione Ha una esistenza indipendente dalle proprietà ad essa associate Esempi: impiegato, città, conto corrente, ordine, fattura Ogni entità ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni (es. singolare) Il modello Entity-Relationship

Il modello Entity-Relationship Es. La classe dei computer Il modello Entity-Relationship

Entità: schema e istanza Una occorrenza (o istanza) di entità è un elemento della classe (l'oggetto stesso, la persona stessa, …, non un valore che questo può assumere) nello schema concettuale rappresentiamo le entità, non le singole istanze Il modello Entity-Relationship

Rappresentazione grafica di entità Impiegato Dipartimento Città Vendita Il modello Entity-Relationship

Relationship (Associazione) Legame logico fra due o più entità, rilevante nell’applicazione di interesse Esempi: Residenza (fra le entità Persona e Città) Esame (fra Studente e Corso) In inglese relationship, viene tradotto con associazione o relazione (da non confondere con la relazione, da relation, nel modello relazionale) Il modello Entity-Relationship

Il modello Entity-Relationship persona Ente lavora in impiegato datore Il modello Entity-Relationship

Rappresentazione grafica di relationship Esame Studente Corso Residenza Impiegato Città Il modello Entity-Relationship

Relationship, commenti Ogni relationship ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni singolare sostantivi invece che verbi (se possibile) Il modello Entity-Relationship

Relationship, occorrenze Una occorrenza di una relationship binaria è una coppia di occorrenze di entità, una per ciascuna entità coinvolta Una occorrenza di una relationship n-aria è una n-upla di occorrenze di entità, una per ciascuna entità coinvolta Nell'ambito di una relationship non ci possono essere occorrenze (coppie, ennuple) ripetute Il modello Entity-Relationship

associazione A tra E1 ed E2 istanza di E1 entità E1 entità E2 associazione A tra E1 ed E2 occorrenza di A Il modello Entity-Relationship

Relationship corrette Esame Studente Corso Visita Paziente Medico Il modello Entity-Relationship

Il modello Entity-Relationship Esempi di occorrenze E1 Rossi Verdi Pepi Bianchi Studente Algebra Fisica Analisi Corso E2 E3 E4 Il modello Entity-Relationship

Il modello Entity-Relationship Per definizione l’insieme delle istanze di un'associazione è un sottoinsieme del prodotto Cartesiano degli insiemi delle istanze di entità che partecipano all’associazione Ne segue che non possono esservi istanze ripetute nell’associazione Se s è uno Studente e c un Corso, la coppia (s,c) può comparire un’unica volta nell'insieme delle istanze di Esame Studente Corso Esame Il modello Entity-Relationship

Il modello Entity-Relationship Grado di una relazione È il numero di istanze di entità che sono coinvolte in un’istanza dell’associazione associazione binaria: grado = 2 associazione ternaria: grado = 3 Persona Città Lavoro Impiegato Assegnazione Progetto Sede Il modello Entity-Relationship

Due relationship sulle stesse entità Sede di lavoro Residenza Impiegato Città Il modello Entity-Relationship

Relationship ricorsiva: coinvolge “due volte” la stessa entità Persona Conoscenza Il modello Entity-Relationship

Relationship ricorsiva con “ruoli” Successione Sovrano Successore Predecessore Il modello Entity-Relationship

Relationship ternaria ricorsiva È possibile avere anelli anche in relazioni n-arie generiche (n > 2) Il significato di una occorrenza (d1,d2,p) è: il dipendente d1 dirige il dipendente d2 all’interno del progetto p dirige Progetto Dipendente Direzione diretto Il modello Entity-Relationship

Un database sul sistema universitario offerta Corso Studente base propedeutico avanz esame frequenza commissione docente iscrizione Professore CorsodiLaurea

Il modello Entity-Relationship Attributo Proprietà elementare di un’entità o di una associazione, di interesse ai fini dell’applicazione Associa ad ogni occorrenza di entità o relationship un valore appartenente a un insieme detto dominio dell’attributo (contiene i valori ammissibili per l’attributo) Il modello Entity-Relationship

Attributi, rappresentazione grafica Data Voto Cognome Nome Matricola Titolo Codice Esame Studente Corso data e voto non sono proprietà né di uno Studente né di un Corso, ma del legame Studente-Corso che si crea in occasione di un esame

Il modello Entity-Relationship Attributi composti Raggruppano attributi di una medesima entità o relationship che presentano affinità nel loro significato o uso Esempio: Via, Numero civico e CAP formano un Indirizzo Il modello Entity-Relationship

Rappresentazione grafica Cognome Età Impiegato Via Indirizzo Numero CAP Il modello Entity-Relationship

Impiegato Dipartimento Indirizzo Sede Progetto Codice Cognome Direzione Telefono Dipartimento Nome Afferenza Data Partecipazione Composizione Città Indirizzo Sede Via CAP Progetto Nome Budget

Corso Studente Professore CorsodiLaurea esame propedeutico segue ciclo nome telefono nome data voto base matricola Corso Studente esame propedeutico avanz indirizzo commissione segue docente via città nome Professore cognome offre data_nascita cod_id nome iscritto CorsodiLaurea

In ogni schema E/R sono presenti dei vincoli Alcuni sono impliciti, in quanto dipendono dalla semantica stessa dei costrutti del modello: ogni occorrenza di associazione deve riferirsi a istanze di entità occorrenze diverse della stessa associazione devono riferirsi a differenti combinazioni di occorrenze delle entità partecipanti all'associazione Altri vincoli sono espliciti, e vengono definiti da chi progetta lo schema E/R sulla base della conoscenza della realtà che si sta modellando vincoli di cardinalità (per associazioni e attributi) vincoli di identificazione

Altri costrutti del modello E-R Cardinalità di relationship di attributo Identificatore interno esterno Generalizzazione Il modello Entity-Relationship

Cardinalità di relationship Coppia di valori (x,y) associati a ogni entità che partecipa a una relationship Per ogni entità E che partecipa a una relazione R i numeri (x,y) specificano il numero minimo e massimo di occorrenze di R cui ciascuna occorrenza di E può partecipare Il modello Entity-Relationship

Esempio di cardinalità (1,5) (0,50) Assegnamento Impiegato Incarico Il modello Entity-Relationship

Il modello Entity-Relationship per semplicità usiamo solo tre simboli: 0 e 1 per la cardinalità minima: 0 = “partecipazione opzionale” 1 = “partecipazione obbligatoria” 1 e “N” per la cardinalità massima: “N” non pone alcun limite Il modello Entity-Relationship

Il modello Entity-Relationship Residenza Studente Città (1,1) (0,N) Cardinalità di Residenza Il modello Entity-Relationship

Occorrenze di Residenza Città Studente Il modello Entity-Relationship

Il modello Entity-Relationship Tipi di relationship Le relationship si distinguono con riferimento alle cardinalità massime; abbiamo relationship: uno a uno (x,1) — (x,1); uno a molti (x,1) — (x,N); molti a molti (x,N) — (x,N), dove x può valere 0 oppure 1 Il modello Entity-Relationship

Relationship “molti a molti” Esame Studente Corso (0,N) Scalata Montagna Alpinista (0,N) (1,N) Abilitazione Macchinista Locomotore (1,N)

C1 C2 Relationship “uno a molti” Impiego Persona Azienda (0,1) (0,N) Ubicazione Cinema Località (1,1) (0,N) Ubicazione Comune Provincia (1,1) (1,N)

C1 C2 Relationship “uno a uno” Titolarità Professore di ruolo Corso (1,1) (0,1) Titolarità Professore di ruolo Cattedra (1,1)

Cardinalità: altri esempi Persona Risiede Città (1,1) (1,n) Studente Risiede Città (1,1) (0,n) Persona Lavora Città (0,n) Studente Esame Corso (0,n) Persone Ha Telefono (0,n) (1,n)

Cardinalità di attributi E’ possibile associare delle cardinalità anche agli attributi, con due scopi: indicare opzionalità ("informazione incompleta") indicare attributi multivalore Il modello Entity-Relationship

Rappresentazione grafica Impiegato Telefono Nome Numero patente (0,N) (0,1) Il modello Entity-Relationship

Il modello Entity-Relationship

Attributi ripetuti e composti Nel caso di presenza di più attributi multivalore, la creazione di un attributo composto può rendersi necessaria per evitare ambiguità Ad esempio, se una persona ha più indirizzi… …non si può rappresentarlo così! via (1,n) n.civico Persona indirizzo città CAP Persona via (1,n) città (1,n) n.civico (1,n) CAP (1,n)

Identificatore di una entità “strumento” per l’identificazione univoca delle occorrenze di un’entità “minimale”: nessun sottoinsieme proprio dell’identificatore deve a sua volta essere identificatore costituito da: attributi dell’entità: identificatore interno (attributi dell’entità +) entità esterne attraverso relationship: identificatore esterno Il modello Entity-Relationship

Identificatori interni: si usano uno o più attributi dell’entità Automobile Targa Modello Proprietario Persona Data Nascita Cognome Nome Indirizzo

Il modello Entity-Relationship Cognome Matricola Nome (1,1) (0,N) Iscrizione Studente Università Anno di corso Indirizzo Identificatore esterno: l’entità è identificata da una o più entità collegate a essa da associazioni, più eventuali attributi dell’entutà stessa Il modello Entity-Relationship

Il modello Entity-Relationship Alcune osservazioni ogni entità deve possedere almeno un identificatore, ma può averne in generale più di uno un identificatore può coinvolgere uno o più attributi, ognuno dei quali deve avere cardinalità (1,1) una identificazione esterna è possibile solo attraverso una associazione a cui l’entità da identificare partecipa con cardinalità (1,1) COSTR. AUTOMOBILE CASA COSTR. Modello Nome (1,N) (1,1) Il modello Entity-Relationship

Identificatori: esempi da non seguire Errore !! R A1 (1,N) (1,1) B1 E2 E1 Attenzione al formalismo grafico usato per gli identificatori esterni. RECITA FILM ATTORE Titolo Nome (1,N) Non si può usare l’entità ATTORE per identificare l’entità FILM: la cardinalità card(FILM, RECITA) dovrebbe essere (1,1), ma ciò è in netto contrasto con la semantica del problema. Errore !! Il modello Entity-Relationship

Note sugli attributi di una associazione (1) È importante fare attenzione all’uso di attributi in un’associazione! Ogni istanza rk dell’associazione R è dotata di un proprio valore per l’attributo d; d’altro canto la semantica dell’E/R impedisce di usare d per identificare le istanze di R. A B R a1 a2 ... an b1 b2 bm r1, r2, ...,rs d Il modello Entity-Relationship

Note sugli attributi di una associazione (2) MATRIM. data UOMO DONNA (0, N) Non possono esservi due istanze dell’associazione (Ui,Dj,d1) e (Ui,Dj,d2), dunque un uomo e una donna non possono risposarsi. MATRIM. data UOMO DONNA (0, N) (1, N) Un uomo può risposare la stessa donna più volte Il modello Entity-Relationship

Note sugli attributi di una associazione (3) Se gli attributi sono più di uno e ripetuti, la soluzione più elegante consiste nell’introduzione di una nuova entità.       data MEDICO PAZIENTE (0, N) VISITA esito (1, N) data MEDICO PAZIENTE (0, N) VISITA esito     ERRATO: non è possibile associare l’esito della visita alla data in cui è stata effettuata un medico può visitare una sola volta un paziente: ASSURDO ! Il modello Entity-Relationship

Note sugli attributi di una associazione (4) data FA_VISITA (1, 1) (0, N) IN_VISITA MEDICO VISITA PAZIENTE esito data MEDICO PAZIENTE (0, N) VISITA esito (1, N) CORRETTO ma poco leggibile Il modello Entity-Relationship

Impiegato Dipartimento Sede Progetto Indirizzo Cognome (1,1) (0,1) Direzione Telefono (1,N) Impiegato Dipartimento (0,N) (0,1) Afferenza (0,N) (1,N) (1,1) (1,N) Nome Codice Partecipazione Composizione (0,1) Data Sede Progetto Via Indirizzo Città Budget Nome CAP

Il modello Entity-Relationship Generalizzazione mette in relazione una o più entità E1, E2, ..., En con una entità E, che le comprende come caso particolare E è generalizzazione di E1, E2, ..., En E1, E2, ..., En sono specializzazioni di E E E1 E2 En … Il modello Entity-Relationship

Rappresentazione grafica Dipendente Impiegato Funzionario Dirigente Il modello Entity-Relationship

Proprietà delle generalizzazioni Se E (genitore) è generalizzazione di E1, E2, ..., En (figlie) ogni proprietà (attributi, identificatori, associazioni) dell’entità padre E è proprietà anche delle entità figlie E1, E2, ..., En ogni occorrenza di un’entità figlia E1, E2, ..., En è occorrenza anche dell’entità padre E Il modello Entity-Relationship

Città Codice fiscale Persona Lavoratore Studente Stipendio Nascita Codice fiscale (1,1) Persona Nome Lavoratore Studente Stipendio Età

Il modello Entity-Relationship Ereditarietà tutte le proprietà (attributi, relationship, altre generalizzazioni) dell’entità genitore vengono ereditate dalle entità figlie e non rappresentate esplicitamente naturalmente le entità figlie possono avere alcune proprietà in più rispetto all'entità genitore, e queste devono essere rappresentate Il modello Entity-Relationship

Tipi di generalizzazioni totale se ogni occorrenza dell'entità genitore è occorrenza di almeno una delle entità figlie, altrimenti è parziale esclusiva se ogni occorrenza dell'entità genitore è occorrenza di al più una delle entità figlie, altrimenti è sovrapposta consideriamo (senza perdita di generalità) solo generalizzazioni esclusive e distinguiamo fra totali e parziali Il modello Entity-Relationship

Il modello Entity-Relationship Persona Generalizzazione parziale esclusiva Disoccupato Lavoratore Il modello Entity-Relationship

Il modello Entity-Relationship Persona Uomo Donna Generalizzazione totale esclusiva Uomo Donna Il modello Entity-Relationship

Il modello Entity-Relationship Altre proprietà possono esistere gerarchie a più livelli e multiple generalizzazioni allo stesso livello un'entità può essere inclusa in più gerarchie, come genitore e/o come figlia Il modello Entity-Relationship

Gerarchie a più livelli PERSONA esistono anche altri ruoli (t,e) (p,e) UOMO DONNA MANAGER IMPIEGATO (t,s) (p,s) MANAGER TECNICO MANAGER AMMINISTR. TECNICO COMMERC. AMMINISTR esistono anche altri tipi di impiegati; alcuni impiegati possono avere più mansioni alcuni manager possono ricoprire entrambi i ruoli Il modello Entity-Relationship

Il modello Entity-Relationship Sottoinsieme È un caso particolare di gerarchia in cui si evidenzia una sola classe specializzata Studente eredita le proprietà di Persona e in più ha la matricola ogni Studente è anche una Persona Persona Studente matricola data_nascita nome Il modello Entity-Relationship

Il modello Entity-Relationship Esercizio Le persone hanno CF, cognome ed età; gli uomini anche la posizione militare; gli impiegati hanno lo stipendio e possono essere segretari, direttori o progettisti (un progettista può essere anche responsabile di progetto); gli studenti (che non possono essere impiegati) un numero di matricola; esistono persone che non sono né impiegati né studenti (ma i dettagli non ci interessano); per ogni studente si vuole conoscere l’università alla quale è iscritto, l’anno di iscrizione e la sede di tale università. Per ogni persona si rappresenta anche la città in cui vive, la provincia e il CAP di tale città. Il modello Entity-Relationship

Ereditarietà delle proprietà Gli attributi comuni lungo una gerarchia vanno riferiti all’entità più generica in cui sono presenti Analogamente per le associazioni, quindi questo schema non è corretto Persona Studente Professore (t,e) matricola (0,1) nome Iscritta (0,1) (0,n) CdL dipartimento (0,1) Il modello Entity-Relationship

Ereditarietà delle proprietà Gli attributi comuni lungo una gerarchia vanno riferiti all’entità più generica in cui sono presenti obbligatoriamente Questo è lo schema corretto Persona Studente Professore (t,e) matricola nome Iscritta (0,1) (0,n) CdL dipartimento Il modello Entity-Relationship

Osservazioni (1) Nell’ambito della progettazione concettuale E/R le gerarchie di generalizzazione non sono normalmente impiegate per modellare aspetti dinamici della realtà di interesse. (t,e) Nome PERSONA Data di nascita data_matrimonio UOMO DONNA CONTRAE_D (1, 1) MATRIMONIO (0, N) CONTRAE_U Nome UOMO UOMO SPOSATO Data di nascita Nome moglie data di matrim. Data nasc. moglie

Osservazioni (2) Attenzione a non confondere entità con istanze di entità tentando di modellare attraverso gerarchie la conoscenza di specifiche istanze. Esempio: ... un campeggio è diviso in tre aree (spiaggia, centrale, ingresso) ognuna delle quali è caratterizzata da una certa tariffa ... AREA SPIAGGIA INGRESSO CENTRALE Tariffa spiaggia Tariffa ingresso Tariffa centrale Tariffa Tipo Area

Il modello Entity-Relationship Osservazioni (3) Attenzione a non modellare attraverso gerarchie i ruoli che un’entità assume in diversi periodi temporali o in relazione ad altre entità: Esempio: ...un circolo di tennis organizza periodicamente alcuni tornei riservati ai soci... gli arbitri delle partite sono soci che non partecipano al torneo... Il ruolo di ARBITRO è temporaneo (in un altro torneo lo stesso SOCIO potrebbe partecipare come GIOCATORE). Il vincolo che gli arbitri delle partite di un torneo non partecipino al torneo stesso va modellato dinamicamente. (t,e) Tessera SOCIO Nome GIOCATORE ARBITRO arbitra PARTITA Data Tessera SOCIO Nome arbitra PARTITA Data (0,N) (1,1) Il modello Entity-Relationship

Il modello Entity-Relationship Note sulle ternarie (1) Quando in un’associazione ternaria esistono dipendenze funzionali tra le entità in gioco è preferibile sostituire la ternaria con una coppia di binarie (che modellano esplicitamente i vincoli del problema). orario DI (1, 1) (1, 3) SI TIENE (0, 40) CORSO LEZIONE AULA CORSO ORARIO (0, N) SI TIENE (1, 3) AULA (0, 40) preferibile Per gestire il seguente vincolo: in un certo ORARIO della settimana si può tenere solo una lezione (in una specifica AULA) di un CORSO, ovvero: CORSO, ORARIO  AULA Il modello Entity-Relationship

Il modello Entity-Relationship Note sulle ternarie (2) Il modello Entity-Relationship

Note sull’effetto del tempo Fotografia dei corsi attivati in un anno accademico nome ciclo cod_corso data_nascita nome (1,1) (0,n) Corso responsabilità cognome Docente cod_doc Il modello Entity-Relationship

Note sull’effetto del tempo La storia considerando più anni accademici AA ciclo nome (1,1) (0,n) responsabilità cognome Corso_AA Docente data_nascita cod_doc (1,1) attivato (0,n) cod_corso nome Corso Il modello Entity-Relationship

Riassunto della notazione grafica Entità Associazione Attributo Attributo composto Identificatore Gerarchia di generalizzazione Sottoinsieme Vincoli di cardinalità (min-card,max-card)

Errori comuni in schemi E-R In tutti i casi visti si può dire che il problema nasceva da un’analisi poco accurata, che portava a soluzioni intuitive ma non adeguate I nomi di entità e associazioni alle volte traggono in inganno: è bene quindi, nel caso si presentino situazioni poco chiare, provare a ragionare anche in termini di istanze (cosa “contiene” effettivamente questa entità/associazione?) Quando, come praticamente sempre accade, interviene la variabile “tempo” è bene chiedersi quali sono gli aspetti che si vogliono modellare che sono indipendenti dal tempo e quali viceversa variano dinamicamente Il modello Entity-Relationship

Utilità del modello E/R Uno schema E/R è più espressivo di uno schema relazionale, inoltre può essere utilizzato con successo per alcuni compiti diversi dalla progettazione, ad esempio: Documentazione: la simbologia grafica del modello E/R può essere facilmente compresa anche dai non “addetti ai lavori” Reverse engineering: a partire da un DB esistente si può fornirne una descrizione in termini E/R allo scopo di migliorare l’analisi del contesto applicativo ed eventualmente procedere a un’operazione di riprogettazione Integrazione di sistemi: essendo indipendente dal modello logico dei dati, è possibile usare il modello E/R come “linguaggio comune” in cui rappresentare DB eterogenei (es. relazionale, gerarchico, a oggetti), allo scopo di costruire un DB integrato Il modello Entity-Relationship

Documentazione associata agli schemi concettuali Uno schema E-R non è quasi mai sufficiente da solo a rappresentare nel dettaglio tutti gli aspetti di della realtà di interesse: I nomi dei vari concetti possono non essere sufficienti per comprenderne il significato; I costrutti del modello non esprimono direttamente tutte le proprietà dei dati rappresentati né alcuni vincoli, es. “per sostenere un esame è necessario avere sostenuto tutti gli esami propedeutici” “un laureando deve aver sostenuto almeno tutti gli esami dei primi anni” In fase di progettazione bisogna quindi fornire un’ulteriore documentazione appropriata a corredo dello schema Il modello Entity-Relationship

Documentazione associata agli schemi concettuali Il modello Entity-Relationship

Documentazione associata agli schemi concettuali Risulta necessario corredare ogni schema E-R con una documentazione di supporto dizionario dei dati per le entità e per le relationship; documentazione dei vincoli non esprimibili. NOTA: vincoli e derivazioni sono esprimibili nei modelli logico e fisico, attraverso opportune clausole SQL oppure procedure di un linguaggio di programmazione Il modello Entity-Relationship

Indirizzo Dipartimento Sede Impiegato Progetto Città Indirizzo Telefono Dipartimento Composizione Sede Direzione Afferenza Impiegato Progetto Partecipazione Nome Cognome Budget Data Via CAP Codice (1,1) (0,1) (1,N) (0,N) (0,1) (0,N) (1,N) (1,1) (1,N) (0,1)

Dizionario dei dati (entità) Il modello Entity-Relationship

Il modello Entity-Relationship Dizionario dei dati (relationship) Il modello Entity-Relationship

Vincoli non esprimibili (regole aziendali)

Il modello Entity-Relationship Regole aziendali Una regola aziendale può essere: La descrizione di un concetto rilevante per l'applicazione (entità, attributo, associazione); Un vincolo di integrità sui dati dell'applicazione; Una derivazione: un concetto che può essere ottenuto attraverso un'inferenza o un calcolo aritmetico, da altri concetti dello schema (ES. costo=netto+tasse) Il modello Entity-Relationship

Modellazione dati in UML UML = Unified Modeling Language, formalismo per la modellazione completa di applicazioni software: dati operazioni processi secondo il paradigma della programmazione a oggetti Fornisce nuove tipologie di diagrammi Il modello Entity-Relationship

Il modello Entity-Relationship Esercizi Rappresentare le seguenti realtà utilizzando i costrutti del modello E-R e introducendo solo le informazioni specificate: In un giardino zoologico ci sono degli animali appartenenti a una specie e aventi una certa età; ogni specie è localizzata in un settore (avente un nome, una locazione e un codice identificativo) dello zoo. Gli animali dello zoo possono essere nati all’interno dello zoo, oppure essere stati acquistati; nel primo caso si vuol sapere il nome dei genitori dell’animale, nel secondo caso interessa il paese di provenienza. Una casa discografica produce dischi aventi un codice, un titolo e un numero di tracce; ogni disco è inciso da uno o più cantanti, ognuno dei quali ha un nome, data di nascita, indirizzo e, qualcuno, un nome d'arte. Il modello Entity-Relationship

Il modello Entity-Relationship Gli impiegati di una azienda sono dirigenti, programmatori, analisti, capi progetto e segretari. Ci sono analisti che sono anche programmatori. I capi progetto devono essere dirigenti. Gli impegati hanno un codice, un nome, e un cognome. Ogni categoria di impiegato ha un proprio stipendio base. Ogni impegato, tranne i dirigenti, ha un proprio orario di lavoro. Il modello Entity-Relationship