Il Modello di dati sulle relazioni tra entità , chiamato anche ER , è uno dei vari modelli di dati che puoi utilizzare per ragionare sui tuoi dati.
In particolare, è un modello di dati concettuale , in quanto non è collegato a nessuna implementazione particolare. Questo è un compito lasciato al modello di dati logici.
Il modello di dati ER è così generale, di così alto livello, che può essere implementato da una varietà di tipi di database completamente diversi.
È fantastico perché non pensi ai dettagli di implementazione, ma pensi solo ai i tuoi dati e a come sono organizzati . E mentre lo fai, sei costretto ad analizzare il problema in modi a cui non avevi pensato prima.
Trovo i diagrammi ER ottimi per aiutarti ad analizzare uno scenario in cui sono coinvolti i dati.
Il Modello ER ti offre gli strumenti per rappresentare, utilizzando una notazione grafica, tutti i dati di cui hai bisogno per modellare, le relazioni tra i diversi tipi di dati e le informazioni ad essi associate.
Ci sono 2 articoli che compongono un modello ER:
- le entità
- le relazioni
Le entità sono tipi di dati, come elementi o persone, che hanno proprietà comuni.
Le relazioni sono le relazioni tra entità.
Lascia che ti faccia un esempio, parliamo di libri e dei loro autori. Abbiamo 2 entità :
- prenota
- autore
Un libro particolare è un'istanza dell'entità libro.
Poiché abbiamo 2 entità, abbiamo 2 relazioni tra loro. Uno è il rapporto tra un singolo libro e l'entità degli autori. Uno è il rapporto tra un singolo autore e l'entità dei libri. Se ci pensiamo, abbiamo:
- un libro ha un autore
- un autore può scrivere molti libri diversi
La notazione visiva per le entità
Dato questo semplice esempio, possiamo iniziare a introdurre la notazione visiva che ci aiuterà a creare il modello di dati ER del nostro scenario.
Nota:ci sono molti modi diversi per disegnare diagrammi ER. Userò quello che, secondo me , è più visivo e ha più senso.
Le entità sono rappresentate come rettangoli, con del testo al loro interno per identificarle:
La notazione visiva per le relazioni
La relazione tra entità è rappresentata, nella sua forma più elementare, utilizzando una linea che collega due relazioni, e un rombo con del testo per identificare il tipo di relazione:
Nota che non ho creato 2 relazioni "libro ha autore" e "autore ha scritto libro". Ho creato un unico rapporto “autore” tra un Libro e un Autore.
Cardinalità
Una volta che abbiamo una relazione, dobbiamo ora indicare i numeri coinvolti. Al momento, abbiamo molte domande:
- Quanti autori può avere un libro?
- Un autore può scrivere più libri?
- Un autore ha bisogno di scrivere almeno un libro per essere chiamato autore?
- Un libro può essere scritto da più autori?
- Può esistere un libro senza almeno un autore?
Tutte queste sono buone domande da porre, e in questo caso penso che le risposte siano piuttosto ovvie. E quando la risposta non è ovvia, puoi pensare al problema e aggiungere i tuoi vincoli.
Esistono vari modi per indicare visivamente le cardinalità su un diagramma. Alcuni preferiscono cambiare la forma della linea quando si collega a un'entità.
Preferisco i numeri, che rendono le cose più chiare:
I numeri sopra significano questo:un libro può essere scritto da 1 o più autori. n indica un numero qualsiasi di elementi.
E un autore può aver scritto da 0 libri (forse ne sta scrivendo uno ora) a un numero infinito di libri.
La prima è chiamata relazione da zero a molti . La seconda è una relazione uno a molti .
Possiamo anche avere:
- relazioni uno-a-uno
- relazioni molti-a-molti
- relazioni zero a uno
Attributi
Ogni entità può avere uno o più attributi.
Diciamo che useremo la relazione sopra in una libreria. Ogni autore ha un nome, una biografia, l'URL di un sito web.
Ogni libro ha un titolo, un editore, un anno di pubblicazione, un ISBN. Anche l'editore potrebbe essere un'entità, se vogliamo. Ma possiamo anche definirlo come un attributo di un libro.
Ecco come possiamo rappresentare le informazioni di cui sopra:
Attributi dell'identificatore
Le entità devono essere identificate da una chiave univoca. L'entità libro può essere identificata in modo univoco dall'attributo ISBN. Ogni libro ha un unico ISBN (considerando che non rappresentiamo una singola copia di un libro, ma un "titolo" del libro).
Identifichiamo gli attributi della chiave primaria in base ad essi:
L'autore, d'altra parte, non ha un identificatore univoco al momento. Due autori possono avere lo stesso nome.
Dobbiamo quindi aggiungere un attributo chiave univoco. Ad esempio un id attributo:
Gli attributi dell'identificatore possono estendersi su più attributi.
Ad esempio, l'ID passaporto e il paese dell'autore identificano in modo univoco la persona e potrebbero sostituire il id attributo che abbiamo aggiunto:
Quale scegliere? È una questione di ciò che ha più senso nella tua applicazione. Se stiamo modellando una libreria, non possiamo aspettarci di avere il paese e l'ID passaporto di tutti gli autori di libri. Utilizzeremo quindi un id casuale sceglieremo e associeremo a ciascun autore.
Attributi di relazione
Gli attributi non sono univoci per le entità. Anche le relazioni possono avere attributi.
Considera che abbiamo bisogno di modellare una libreria. Oltre alle entità libro e autore, ora introduciamo l'entità lettore , una persona che prende in prestito il libro per leggerlo. Prendiamo il suo nome e il numero della carta d'identità quando lo prendono in prestito:
Ma ci mancano ancora le informazioni. Abbiamo bisogno di sapere quando la persona ha preso in prestito il libro e la data in cui lo ha restituito, in modo da poter archiviare le informazioni su tutta la storia di un determinato libro nella nostra biblioteca. Queste informazioni non appartengono né al libro né alle entità lettori; appartiene alla relazione:
Entità deboli
Abbiamo parlato delle chiavi primarie sopra e di come l'aiuto identifica in modo univoco un'entità.
Alcune entità dipendono da altre entità per la loro esistenza e sono chiamate entità deboli .
Supponiamo di dover modellare gli ordini per un negozio online.
Per ogni ordine, memorizzeremo l'ID dell'ordine, che parte da 1 e aumenta nel tempo, la data e l'ora in cui è stato effettuato e le informazioni sul cliente, così sappiamo a chi fatturare e dove spedirlo.
Quindi dobbiamo anche sapere cosa hanno ordinato. Creiamo un'entità debole "articolo ordinato", che rappresenta ogni articolo nel carrello al momento del checkout.
Questa entità memorizzerà il prezzo dell'articolo al momento del checkout (quindi quando modifichiamo il prezzo dei prodotti in vendita, non influirà sugli ordini già effettuati), la quantità di articoli che sono stati ordinati e le opzioni scelte. Supponiamo che vendiamo magliette, quindi dobbiamo memorizzare il colore e la taglia della maglietta ordinata.
È un'entità debole perché un'entità articolo ordinato non può esistere senza un'entità ordine.
Relazioni ricorsive
Un'entità può avere una relazione ricorsiva con se stessa. Supponiamo di avere un'entità persona. Possiamo modellare la relazione genitore-figlio in questo modo:
Una persona può avere da 0 a n figli, un bambino ha 2 genitori (considerando lo scenario più semplice).
Relazioni ISA
ISA sta per IS-A ed è un modo per modellare le generalizzazioni nel modello ER.
Lo usiamo per raggruppare entità simili sotto un ombrello comune. Ad esempio, un autore e un lettore, nel caso dell'esempio di libri e biblioteche, possono essere generalizzati utilizzando un'entità persona.
Entrambi hanno un nome, quindi estraiamo il nome fino all'entità persona e gestiamo solo le peculiarità di essere un autore o lettore nell'entità corrispondente:
Relazioni non binarie
Non tutte le relazioni sono rigorosamente binarie. Prendiamo uno scenario di lezione.
Oggi alle 10:00 si svolge una lezione in un'aula della scuola, con un insegnante che parla a una classe di fisica.
Quindi, una lezione viene impartita in un determinato momento della giornata, coinvolge una materia, un insegnante, una classe e un'aula.
Possiamo modellarlo in questo modo:
