Free Press

Il modello di dati delle relazioni tra entità (ER) esiste da oltre 35 anni. È adatto alla modellazione dei dati per l’uso con i database perché è abbastanza astratto ed è facile da discutere e spiegare. I modelli ER sono facilmente traducibili in relazioni. I modelli ER, chiamati anche schema ER, sono rappresentati da diagrammi ER.

La modellazione ER si basa su due concetti:

• Entità, definite come tabelle che contengono informazioni specifiche (dati)
• Relazioni, definite come associazioni o interazioni tra entità

Ecco un esempio di come questi due concetti potrebbero essere combinati in un modello di dati ER: Prof. Ba (entità) insegna (relazione) il corso di Sistemi di database (entità).

Per il resto di questo capitolo, useremo un database di esempio chiamato COMPANY per illustrare i concetti del modello ER. Questo database contiene informazioni su impiegati, dipartimenti e progetti. I punti importanti da notare sono:

• Ci sono diversi dipartimenti nell’azienda. Ogni dipartimento ha un’identificazione unica, un nome, l’ubicazione dell’ufficio e un particolare dipendente che gestisce il dipartimento.
• Un dipartimento controlla una serie di progetti, ognuno dei quali ha un nome unico, un numero unico e un budget.
• Ogni dipendente ha un nome, un numero di identificazione, un indirizzo, uno stipendio e una data di nascita. Un dipendente è assegnato a un dipartimento ma può partecipare a diversi progetti. Abbiamo bisogno di registrare la data di inizio del dipendente in ogni progetto. Abbiamo anche bisogno di conoscere il supervisore diretto di ogni dipendente.
• Vogliamo tenere traccia delle persone a carico per ogni dipendente. Ogni dipendente ha un nome, una data di nascita e una relazione con l’impiegato.

Entità, set di entità e tipo di entità

Un’entità è un oggetto nel mondo reale con un’esistenza indipendente che può essere differenziata da altri oggetti. Un’entità potrebbe essere

Le entità possono essere classificate in base alla loro forza. Un’entità è considerata debole se le sue tabelle sono dipendenti dall’esistenza.

• Ovvero, non può esistere senza una relazione con un’altra entità
• La sua chiave primaria è derivata dalla chiave primaria dell’entità madre
  • La tabella Spouse, nel database COMPANY, è un’entità debole perché la sua chiave primaria dipende dalla tabella Employee. Senza un record dipendente corrispondente, il record coniuge non esisterebbe.

Un’entità è considerata forte se può esistere a parte tutte le sue entità correlate.

• I kernel sono entità forti.
• Una tabella senza chiave esterna o una tabella che contiene una chiave esterna che può contenere nulls è un’entità forte

Un altro termine da conoscere è il tipo di entità che definisce una collezione di entità simili.

Un insieme di entità è una collezione di entità di un tipo di entità in un particolare momento. In un diagramma di relazione tra entità (ERD), un tipo di entità è rappresentato da un nome in una casella. Per esempio, nella figura 8.1, il tipo di entità è EMPLOYEE.

Dipendenza di esistenza

L’esistenza di un’entità dipende dall’esistenza dell’entità collegata. È dipendente dall’esistenza se ha una chiave esterna obbligatoria (cioè, un attributo di chiave esterna che non può essere nullo). Per esempio, nel database COMPANY, un’entità Coniuge è dipendente dall’esistenza dell’entità Employee.

Tipi di entità

Dovresti anche avere familiarità con diversi tipi di entità, incluse entità indipendenti, entità dipendenti ed entità caratteristiche. Queste sono descritte di seguito.

Età indipendenti

Le entità indipendenti, chiamate anche kernel, sono la spina dorsale del database. Sono ciò su cui si basano le altre tabelle. I kernel hanno le seguenti caratteristiche:

• Sono i mattoni di un database.
• La chiave primaria può essere semplice o composita.
• La chiave primaria non è una chiave esterna.
• Non dipendono da un’altra entità per la loro esistenza.

Se ci riferiamo al nostro database COMPANY, esempi di un’entità indipendente sono la tabella Customer, la tabella Employee o la tabella Product.

Età dipendenti

Le entità dipendenti, dette anche entità derivate, dipendono da altre tabelle per il loro significato. Queste entità hanno le seguenti caratteristiche:

• Le entità dipendenti sono usate per collegare due kernel insieme.
• Si dice che dipendono da due o più tabelle.
• Le relazioni molti a molti diventano tabelle associative con almeno due chiavi esterne.
• Possono contenere altri attributi.
• La chiave esterna identifica ogni tabella associata.
• Ci sono tre opzioni per la chiave primaria:
  1. Utilizzare un composto di chiavi esterne di tabelle associate se uniche
  2. Utilizzare un composto di chiavi esterne e una colonna qualificante
  3. Creare una nuova chiave primaria semplice

Età caratteristiche

Le entità caratteristiche forniscono maggiori informazioni su un’altra tabella. Queste entità hanno le seguenti caratteristiche:

• Rappresentano attributi multivalutati.
• Descrivono altre entità.
• In genere hanno una relazione uno a molti.
• La chiave esterna è usata per identificare ulteriormente la tabella caratterizzata.
• Le opzioni per la chiave primaria sono le seguenti:
  1. Utilizzare un composto di chiave esterna più una colonna qualificante
  2. Creare una nuova chiave primaria semplice. Nel database COMPANY, queste potrebbero includere:
     • Employee (EID, Name, Address, Age, Salary) – EID è la chiave primaria semplice.
     • EmployeePhone (EID, Phone) – EID è parte di una chiave primaria composta. Qui, EID è anche una chiave esterna.

Attributi

Ogni entità è descritta da un insieme di attributi (ad esempio, Employee = (Name, Address, Birthdate (Age), Salary).

Ogni attributo ha un nome, ed è associato con un’entità e un dominio di valori legali. Tuttavia, le informazioni sul dominio dell’attributo non sono presentate sull’ERD.

Nel diagramma di relazione tra entità, mostrato in figura 8.2, ogni attributo è rappresentato da un ovale con un nome all’interno.

Tipi di attributi

Ci sono alcuni tipi di attributi con cui devi avere familiarità. Alcuni di questi devono essere lasciati così come sono, ma alcuni devono essere adattati per facilitare la rappresentazione nel modello relazionale. Questa prima sezione discuterà i tipi di attributi. Più avanti parleremo della correzione degli attributi per adattarli correttamente al modello relazionale.

Attributi semplici

Gli attributi semplici sono quelli tratti dal dominio dei valori atomici; sono anche chiamati attributi a valore singolo. Nel database COMPANY, un esempio di questo sarebbe: Nome = {John} ; Età = {23}

Attributi composti

Gli attributi composti sono quelli che consistono in una gerarchia di attributi. Usando il nostro esempio di database, e mostrato nella figura 8.3, l’indirizzo può essere composto da Numero, Via e Periferia. Quindi questo sarebbe scritto come → Indirizzo = {59 + ‘Meek Street’ + ‘Kingsford’}

Attributi multivalutati

Gli attributi multivalutati sono attributi che hanno un insieme di valori per ogni entità. Un esempio di un attributo multivalutato dal database COMPANY, come si vede nella figura 8.4, sono i gradi di un dipendente: BSc, MIT, PhD.

Attributi derivati

Gli attributi derivati sono attributi che contengono valori calcolati da altri attributi. Un esempio di questo può essere visto nella figura 8.5. L’età può essere derivata dall’attributo Birthdate. In questa situazione, Birthdate è chiamato un attributo memorizzato, che è fisicamente salvato nel database.

Keys

Un importante vincolo su un’entità è la chiave. La chiave è un attributo o un gruppo di attributi i cui valori possono essere usati per identificare univocamente una singola entità in un insieme di entità.

Tipi di chiavi

Ci sono diversi tipi di chiavi. Queste sono descritte qui sotto.

Chiave candidata

Una chiave candidata è una chiave semplice o composita che è unica e minima. È unica perché due righe di una tabella non possono avere lo stesso valore in qualsiasi momento. È minima perché ogni colonna è necessaria per raggiungere l’unicità.

Dal nostro esempio di database COMPANY, se l’entità è Employee (EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID), le possibili chiavi candidate sono:

• EID, SIN
• Nome e Cognome – assumendo che non ci sia nessun altro nell’azienda con lo stesso nome
• Cognome e DepartmentID – assumendo che due persone con lo stesso cognome non lavorino nello stesso dipartimento

Chiave composta

Una chiave composta è composta da due o più attributi, ma deve essere minima.

Utilizzando l’esempio della sezione delle chiavi candidate, le possibili chiavi composite sono:

• Nome e Cognome – assumendo che non ci sia nessun altro nell’azienda con lo stesso nome
• Cognome e ID Dipartimento – assumendo che due persone con lo stesso cognome non lavorino nello stesso dipartimento

Chiave primaria

La chiave primaria è una chiave candidata che viene scelta dal progettista del database per essere usata come meccanismo di identificazione per l’intero set di entità. Deve identificare univocamente le tuple in una tabella e non essere nulla. La chiave primaria è indicata nel modello ER sottolineando l’attributo.

• Una chiave candidata è selezionata dal progettista per identificare univocamente le tuple in una tabella. Non deve essere nullo.
• Una chiave è scelta dal progettista del database per essere usata come meccanismo di identificazione per l’intero insieme di entità. Questa viene chiamata chiave primaria. Questa chiave è indicata sottolineando l’attributo nel modello ER.

Nell’esempio seguente, EID è la chiave primaria:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Chiave secondaria

Una chiave secondaria è un attributo usato strettamente per scopi di recupero (può essere composto), per esempio: Telefono e Cognome.

Chiave alternativa

Le chiavi alternative sono tutte le chiavi candidate non scelte come chiave primaria.

Chiave esterna

Una chiave esterna (FK) è un attributo in una tabella che fa riferimento alla chiave primaria in un’altra tabella OPPURE può essere nullo. Entrambe le chiavi straniere e primarie devono essere dello stesso tipo di dati.

Nell’esempio di database COMPANY qui sotto, DepartmentID è la chiave straniera:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Nulls

Un null è un simbolo speciale, indipendente dal tipo di dati, che significa sconosciuto o inapplicabile. Non significa zero o vuoto. Le caratteristiche di null includono:

• Nessun dato inserito
• Non consentito nella chiave primaria
• Dovrebbe essere evitato in altri attributi
• Può rappresentare
  • Un valore di attributo sconosciuto
  • Un valore noto, ma mancante,
  • Una condizione “non applicabile”
• Può creare problemi quando si usano funzioni come COUNT, AVERAGE e SUM
• Può creare problemi logici quando le tabelle relazionali sono collegate

NOTE: Il risultato di un’operazione di confronto è nullo quando uno dei due argomenti è nullo. Il risultato di un’operazione aritmetica è nullo quando uno dei due argomenti è nullo (eccetto le funzioni che ignorano i nulli).

Esempio di come può essere usato null

Utilizzare la tabella Salary (Salary_tbl) in Figura 8.6 per seguire un esempio di come può essere usato null.

Per iniziare, trova tutti gli impiegati (emp#) in Sales (sotto la colonna jobName) il cui stipendio più le commissioni sono maggiori di 30.000.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (commission + salary) > 30,000 -> E10 e E12

Questo risultato non include E13 a causa del valore nullo nella colonna commission. Per assicurarci che la riga con il valore nullo sia inclusa, dobbiamo guardare i singoli campi. Aggiungendo la commissione e lo stipendio per il dipendente E13, il risultato sarà un valore nullo. La soluzione è mostrata qui sotto.

Relazioni

Le relazioni sono la colla che tiene insieme le tabelle. Sono usate per collegare le informazioni correlate tra le tabelle.

La forza delle relazioni si basa su come è definita la chiave primaria di un’entità correlata. Una relazione debole, o non identificativa, esiste se la chiave primaria dell’entità correlata non contiene un componente della chiave primaria dell’entità madre. Esempi di database aziendali includono:

• Cliente(CustID, CustName)
• Ordine(OrderID, CustID, Data)

Una relazione forte, o identificativa, esiste quando la chiave primaria dell’entità correlata contiene il componente chiave primaria dell’entità padre. Esempi includono:

• Corso(CrsCode, DeptCode, Descrizione)
• Classe(CrsCode, Sezione, ClassTime…)

Tipi di relazioni

Di seguito sono descritte le varie tipologie di relazioni.

Relazioni uno a molti (1:M)

Una relazione uno a molti (1:M) dovrebbe essere la norma in ogni progetto di database relazionale e si trova in tutti gli ambienti di database relazionali. Per esempio, un dipartimento ha molti dipendenti. La figura 8.7 mostra la relazione di uno di questi impiegati con il dipartimento.

Relazioni uno a uno (1:1)

Una relazione uno a uno (1:1) è la relazione di un’entità con una sola altra entità, e viceversa. Dovrebbe essere rara in qualsiasi progetto di database relazionale. Infatti, potrebbe indicare che due entità appartengono effettivamente alla stessa tabella.

Un esempio dal database COMPANY è un dipendente associato a un coniuge, e un coniuge è associato a un dipendente.

Relazioni molti a molti (M:N)

Per una relazione molti a molti, considerare i seguenti punti:

• Non può essere implementata come tale nel modello relazionale.
• Può essere modificata in due relazioni 1:M.
• Può essere implementato rompendo per produrre un insieme di relazioni 1:M.
• Comporta l’implementazione di un’entità composita.
• Crea due o più relazioni 1:M.
• La tabella entità composita deve contenere almeno le chiavi primarie delle tabelle originali.
• La tabella di collegamento contiene più occorrenze dei valori delle chiavi esterne.
• Attributi aggiuntivi possono essere assegnati secondo necessità.
• Può evitare problemi inerenti ad una relazione M:N creando un’entità composita o un’entità ponte. Per esempio, un dipendente può lavorare su molti progetti OPPURE un progetto può avere molti dipendenti che ci lavorano, a seconda delle regole di business. Oppure, uno studente può avere molte classi e una classe può contenere molti studenti.

La figura 8.8 mostra un altro aspetto della relazione M:N dove un dipendente ha diverse date di inizio per diversi progetti. Pertanto, abbiamo bisogno di una tabella JOIN che contenga l’EID, il codice e la data d’inizio.

Esempio di mappatura di un tipo di relazione binaria M:N

• Per ogni relazione binaria M:N, identificare due relazioni.
• A e B rappresentano due tipi di entità partecipanti a R.
• Crea una nuova relazione S per rappresentare R.
• S deve contenere i PK di A e B. Questi insieme possono essere il PK nella tabella S OPPURE questi insieme ad un altro semplice attributo nella nuova tabella R possono essere il PK.
• La combinazione delle chiavi primarie (A e B) farà la chiave primaria di S.

Relazione unaria (ricorsiva)

Una relazione unaria, detta anche ricorsiva, è una relazione in cui esiste una relazione tra occorrenze dello stesso insieme di entità. In questa relazione, la chiave primaria e quella esterna sono le stesse, ma rappresentano due entità con ruoli diversi. Vedere la figura 8.9 per un esempio.

Per alcune entità in una relazione unaria, può essere creata una colonna separata che si riferisce alla chiave primaria dello stesso insieme di entità.

Relazioni ternarie

Una relazione ternaria è un tipo di relazione che comporta relazioni molti a molti tra tre tabelle.

Riferimento alla figura 8.10 per un esempio di mappatura di un tipo di relazione ternaria. Notate che n-ary significa più tabelle in una relazione. (Ricordate, N = molti.)

• Per ogni relazione n-aria (> 2), create una nuova relazione per rappresentare la relazione.
• La chiave primaria della nuova relazione è una combinazione delle chiavi primarie delle entità partecipanti che tengono il lato N (molti).
• Nella maggior parte dei casi di una relazione n-aria, tutte le entità partecipanti hanno un lato many.

Attribuzione

Questo capitolo di Database Design (incluse le immagini, salvo diversa indicazione) è una copia derivata di Data Modeling Using Entity-Relationship Model di Nguyen Kim Anh con licenza Creative Commons Attribution License 3.0 license

Il seguente materiale è stato scritto da Adrienne Watt:

1. Sezione Nulls ed esempio
2. Termini chiave
3. Esercizi