Errori comuni del diagramma ER

Scopri il diagramma ER (Entity Relationship), le sue parti e cosa spesso va storto durante la sua creazione.

Hai mai creato un modello di database relazionale? O forse stai cercando di creare il tuo primo? Sai (o lo scoprirai presto) che tradurre i problemi del mondo reale nella logica del database a volte può essere piuttosto difficile.

Uno degli strumenti che potrebbe aiutarti è il diagramma ER. La saggezza comune sulla progettazione di database sostiene che migliore è il diagramma ER, più facile sarà costruire il modello di database. Questo importante elemento dà il tono a tutte le future frustrazioni o successi. Con un buon diagramma ER, la creazione di un modello di database relazionale è abbastanza semplice. Naturalmente, è possibile commettere errori in qualsiasi fase della modellazione del database. Tuttavia, avere un buon diagramma ER può aiutarti a evitare alcuni di questi errori.

Quindi, vediamo cos'è il diagramma ER e come possiamo evitare i suoi errori comuni.

Cos'è un diagramma ER?

"ER Diagram", o ERD, è l'abbreviazione di Entity Relationship Diagram. Traccia il problema da modellare, ma in modo strutturato che mostra le relazioni tra le entità.

Gli elementi costitutivi di un diagramma ER

I diagrammi ER sono costituiti dai seguenti elementi:

• Entità
• Relazioni
• Attributi di entità o relazione

Il primo elemento del diagramma ER è l'entità . L'entità è un oggetto o un'occorrenza di cui vogliamo memorizzare informazioni. Fondamentalmente, è qualsiasi cosa su cui possiamo raccogliere dati. Ad esempio, potremmo archiviare dati su dipendenti, studenti, insegnanti, acquirenti, prodotti, dipartimenti, pagamenti, sedi, ecc.

Una volta che abbiamo le entità, è necessario creare relazioni . Una relazione mostra come un'entità è connessa e associata a una o più altre entità.

L'elemento finale del diagramma ER è un attributo di entità o relazione . Un attributo è una descrizione di una proprietà appartenente a un'entità o relazione. Gli attributi hanno valori. Alcuni attributi per le entità sopra menzionate potrebbero essere:

• Dipendente, studente, insegnante, acquirente – ID, nome, cognome, data di nascita, indirizzo, ecc.
• Prodotto – ID, categoria, descrizione, colore, numero di serie, ecc.
• Dipartimento – ID, nome del dipartimento, capo dipartimento, numero di dipendenti, ecc.
• Pagamenti – ID, data e ora, importo.
• Posizione – Città, CAP, regione, paese, continente.

Tipi di relazioni

Prima di entrare nei soliti errori riscontrati nei diagrammi ER, è importante comprendere i possibili tipi di relazione. La maggior parte degli errori ERD sono essenzialmente relazioni erroneamente definite tra entità.

Esistono tre tipi di relazioni tra entità:

• Uno a uno (1:1)
• Uno a molti (1:N)
• Molti a molti (M:N)

Relazioni uno a uno (1:1)

Il primo tipo di relazione è uno a uno o 1:1 . In questa relazione, una singola istanza di un'entità può essere connessa solo con una singola istanza di un'altra entità (e viceversa, ovviamente).

Diciamo che abbiamo l'entità studente con gli attributi nome e cognome . Abbiamo anche l'entità id con l'unico attributo id . La relazione 1:1 significherebbe che uno studente può avere un solo numero ID. Significa anche che un numero ID può appartenere a un solo studente.

Questa relazione è vista molto raramente nei database. Se è possibile collegare un solo ID con un solo studente, non è necessario separarli in due entità diverse.

Ecco un esempio di questa relazione:

Relazioni uno a molti (1:N)

Il tipo più comune di relazione con il database è uno-a-molti o 1:N . Una relazione uno-a-molti significa che ogni singola istanza di un'entità può essere collegata a più istanze di un'altra entità. Significa anche che ogni istanza della seconda entità può essere associata a una sola istanza della prima entità.

Ad esempio, esiste un'entità acquirente con gli attributi id , nome e cognome . Vogliamo stabilire una relazione con l'entità pagamento che ha gli attributi id , data e valore . Questa è una relazione 1:N perché un acquirente può effettuare uno o più pagamenti. Tuttavia, un pagamento non può essere effettuato da più acquirenti; può essere fatto solo da un acquirente.

Ecco l'esempio:

Questa relazione può essere vista anche al contrario. In questa situazione, si chiama molti-a-uno o N:1 . Naturalmente, questo non è un nuovo tipo di relazione. È lo stesso di 1:N, ma è visto dalla direzione opposta.

Ad esempio, supponiamo di avere l'entità dipendente con gli attributi id , nome e cognome . Vogliamo creare un dipendente rapporto di ' con l'entità dipartimento che ha gli attributi id e nome . La relazione tra queste due entità è N:1. Ciò significa che ogni dipendente può lavorare in un solo reparto, ma più dipendenti possono lavorare nello stesso reparto.

Relazioni molti-a-molti (M:N)

Un Molti a molti o M:N relazione significa che ogni istanza della prima entità può essere associata a più di un'istanza della seconda entità. Significa anche che ogni istanza della seconda entità può essere associata a più istanze della prima entità.

Vediamo come funziona tra le entità studente e lezione . Diciamo che studente ha gli attributi id , nome e cognome . L'entità lezione ha gli attributi id e nome . Una relazione molti-a-molti può essere interpretata nel modo seguente:uno studente può frequentare una o più lezioni, mentre una lezione può essere frequentata da uno o più studenti.

Ecco il diagramma per questo esempio:

Nella modellazione di database, tali relazioni sono solitamente suddivise in due o più relazioni 1:N o N:1 introducendo nuove entità.

Errori tipici commessi durante la creazione di un diagramma ER

Molti errori del diagramma ER rientrano in una di queste quattro categorie:

• Relazioni errate tra entità
• Utilizzo di un'istanza di entità invece di un'entità
• Confondere un attributo con un'entità
• Attributi complessi

Diamo un'occhiata a ciascuno individualmente.

Relazioni errate tra entità

Gli errori più comuni si verificano durante la definizione della relazione tra entità . Di solito non ci sono errori in una relazione 1:1. Tuttavia, è molto facile confondere una relazione 1:N con una relazione M:N. Questo di solito deriva dalla non comprensione dei requisiti forniti dall'utente finale. È fondamentale avere requisiti ben definiti e una profonda comprensione del motivo per cui è necessario il database e di come verrà utilizzato. Se creiamo un diagramma ER con dati insufficienti e una comprensione incompleta, molto probabilmente comporterà una definizione errata delle relazioni tra le entità.

Diamo un'occhiata a un esempio. Se stai creando un database per una banca, molto probabilmente creerai un diagramma ER con l'entità client con gli attributi id , nome e cognome . Avrai anche un'entità chiamata account con gli attributi id e digitare . Se non hai esperienza nel settore bancario, probabilmente penserai che ci sia sempre una relazione 1:N tra il cliente e account entità, come illustrato di seguito.

Un cliente può avere più conti in una banca. Tuttavia, un account può essere di proprietà di un solo cliente. Questo è effettivamente vero? Forse lo è, forse non lo è. Molte banche offrono conti cointestati che possono essere utilizzati da più clienti. Stai creando un diagramma ER per una banca che offre un servizio del genere? Se la banca non offre conti cointestati, hai ragione:il rapporto tra cliente e account è 1:N. Tuttavia, se la banca offre conti cointestati, la relazione è M:N.

Utilizzo di un'istanza di entità invece di un'entità

Un altro errore comune consiste nell'utilizzare un'istanza di entità anziché un'entità. Un'istanza di entità è una singola occorrenza di una determinata entità, ovvero un'entità che potrebbe effettivamente essere un attributo di una categoria più ampia.

Diciamo che lavoriamo in un'azienda che assegna telefoni cellulari e laptop a determinati dipendenti. Quindi, nel nostro database, avremmo un'entità chiamata laptop con gli attributi id e modello e un'entità denominata dipendente con gli attributi id , nome e cognome , giusto?

C'è un problema qui:un laptop in realtà non è un'entità:ci sono anche telefoni cellulari di cui tenere conto. La soluzione è sostituire l'entità laptop con un'entità più generale, come attrezzature . Questa entità potrebbe avere gli attributi ID , digita e modello , come mostrato di seguito. Il tipo potrebbe essere costituito da valori come telefono , PC , tablet e computer portatile . In questo modo, non è necessario creare un'entità separata per ogni tipo di attrezzatura.

Puoi trovare l'esempio qui:

Confondere un attributo con un'entità

Il prossimo errore comune è confondere un attributo con un'entità. Diciamo che abbiamo deciso di creare un'entità chiamata employee che sarà composto dagli attributi id , nome , cognome , data_di_nascita , id_dipartimento , nome_reparto e dipartimento_testa . Questa entità ci metterà nei guai quando creiamo un modello di database perché è costituita da troppi attributi che non definiscono in modo univoco questa particolare entità .

Ricorda, abbiamo definito entità come qualsiasi cosa su cui possiamo raccogliere dati. Con questo in mente, possiamo vedere che l'attuale dipendente l'entità può essere suddivisa in due entità:dipendente e dipartimento , come mostrato di seguito.

Attributi complessi

L'ultimo errore comune di cui parleremo è includere un attributo complesso in un'entità. In altre parole, abbiamo un attributo che dovrebbe essere effettivamente la propria entità .

Supponiamo di avere un'entità chiamata studenti che è definito dai seguenti attributi:id , nome , cognome , data_di_nascita , indirizzo e esame_superato . Qui, esame_superato è un attributo complesso che consiste in più di un'informazione, ovvero l'ID e la data dell'esame e il punteggio dello studente. Lasciarlo così sarebbe un errore. Invece, dovremmo creare una nuova entità da questo complesso attributo . La nuova entità potrebbe essere denominata esami e sono costituiti dai seguenti attributi:id , data , ID_studenti e punteggio .

Puoi trovare l'esempio qui:

Hai ricevuto suggerimenti utili sul diagramma ER?

Questi quattro tipi di errori sono i più comuni nel processo di creazione del diagramma ER. Naturalmente, non esiste un elenco completo di errori tipici o tipi di errori. Nella vita reale, è probabile che accadano molti tipi di errori. La mancanza di pianificazione, il supporto tecnico insufficiente e un processo di progettazione del database affrettato contribuiscono tutti ai propri problemi. Se hai mai creato database o partecipato dal lato aziendale, probabilmente ne hai sperimentati alcuni! Tutte queste circostanze portano a vari errori, alcuni dei quali sono piuttosto unici.

Hai il tuo esempio di diagramma ER non così buono? O forse ci sono altri errori che trovi frequentemente? Per favore fatemelo sapere nella sezione commenti.