Comprensione Database Blocchi di Costruzione in SQL Server

Come Questo Blog 3

Aggiunto da Pietro Avila novembre 21, 2012

Ogni casa dispone di una cucina, di almeno un bagno e una camera da letto, un portone, un sistema idraulico, e altre cose. Queste cose possono essere disposte in modi diversi e in numeri diversi per produrre case diverse. Così è con i database. Ci sono alcune cose che tutti i database hanno in comune. In questo post, introdurrò gli elementi costitutivi che compongono tutti i database e mostrerò come sono assemblati. Discuterò anche tre regole che devono essere seguite quando si utilizzano i blocchi di costruzione.

Il materiale presentato in questo post dovrebbe essere di valore per chiunque abbia qualsiasi tipo di interazione con i database, ma è a un livello molto elementare. Per una discussione più completa sulla progettazione di database, consultare il mio articolo, Un approccio intuitivo alla progettazione di database.

Mini-Mondi.

Prima di arrivare agli elementi costitutivi, prendiamoci un momento per capire il termine mini-mondo perché ci aiuterà a capire gli elementi costitutivi.

Un database è un modello di un mini-mondo. Un mini-mondo può essere uno studio medico, un’attività di vendita al dettaglio, una biblioteca o molte altre cose. Quando vogliamo informazioni sul mini-mondo, ci rivolgiamo al database che lo modella.

Diciamo che vai dal medico per un appuntamento. Quando comunichi al receptionist che hai un appuntamento, il receptionist cercherà di trovare il tuo appuntamento nel modello (il database). Se il modello è stato mantenuto aggiornato con il suo mini-mondo, dovrebbe essere in grado di confermare che hai un appuntamento. Allo stesso modo, se un’azienda vuole sapere quale dei loro clienti ad alto volume non ha effettuato ordini negli ultimi 6 mesi, può rivolgersi al modello del loro mini-mondo se è stato mantenuto aggiornato con quel mini-mondo.

Un mini-mondo può essere un intero business, o potrebbe essere una parte di un business, come una filiale bancaria, o il reparto vendite.

La prima cosa che un progettista di database fa è capire il mini-mondo, perché il compito del progettista è quello di progettare un modello di quel mini-mondo. E per capire il mini-mondo, il progettista inizia identificando gli elementi costitutivi che andranno nell’assemblaggio di un database.

Gli elementi costitutivi

1. Entità

Un’entità è qualcosa che esiste nel mini-mondo e che ha caratteristiche che ci interessano. Ad esempio, in un mini-mondo di iscrizione alla scuola, ci sono entità studenti, entità del corso, entità istruttore e altri. Gli studenti hanno nomi, indirizzi, GPA e altre caratteristiche che ci interessano. I corsi hanno titoli, crediti, tasse e altri. E gli istruttori hanno nomi, indirizzi, qualifiche e altri. Le entità sono uniche. Ogni studente è un’entità unica; ci sono John e Mary e così via. Ogni corso è un’entità unica e ogni istruttore è un’entità unica.

Le entità non devono essere cose fisiche. Anche se non puoi toccare, vedere o annusare un’iscrizione, tuttavia esiste nel mini-mondo di iscrizione scolastica e ha caratteristiche che ci interessano, come la data dell’iscrizione, lo studente che si è iscritto, il corso a cui lo studente si è iscritto e il voto finale ricevuto. Le vendite sono altri esempi di entità che non hanno un componente fisico ma che hanno caratteristiche di nostro interesse (data di vendita, cliente, venditore, totale dell’ordine, metodo di spedizione, termini di pagamento, ecc.).

2. Tipi di entità

Le entità dello stesso tipo appartengono a un tipo di entità. Un tipo di entità è un insieme di entità di quel tipo. Il tipo di entità studente è l’insieme di tutti gli studenti. Il tipo di entità del corso è l’insieme di tutti i corsi e il tipo di entità istruttore è l’insieme di tutti gli istruttori.

I tipi di entità sono il concetto più importante in questo post. Diventano tabelle in un database.

3. Attributi

Gli attributi di un’entità sono le caratteristiche di quell’entità che ci interessano. Come già accennato, gli attributi degli studenti includono nome, indirizzo, GPA e altri. I corsi hanno nomi, crediti, dipartimenti a cui appartengono e altri. E così via con altri tipi di entità.

Assemblaggio dei blocchi di costruzione

Come vengono rappresentati questi blocchi di costruzione nel database? Ogni tipo di entità è rappresentato da una tabella nel database. In quella tabella, le singole righe sono le entità univoche e le colonne sono gli attributi. Ecco un esempio di una tabella che rappresenta il tipo di entità della carta di credito:

Blocco di Costruzione di Regole

Quando si lavora con la costruzione di blocchi, è importante seguire alcune regole che non solo rendono più facile il lavoro con gli oggetti di database, ma anche impedire che i dati anomalie (dati anomalie sono oltre la portata di questo post, ma sono discussi in dettaglio nel mio articolo, Un Approccio Intuitivo alla Progettazione di Database).

Regola 1: ogni tabella deve rappresentare uno e solo un tipo di entità.

Il database del mini-mondo di iscrizione scolastica, sopra, ha bisogno delle seguenti tabelle: Studente, Corso, Istruttore, Iscrizione e altri, uno per ogni tipo di entità identificato in quel mini-mondo. Il database del mini-mondo dell’ufficio medico ha bisogno di un tavolo medico, un tavolo per pazienti, un tavolo per appuntamenti, un tavolo per i farmaci e altri. Una tabella per ogni tipo di entità.

C’è un’eccezione a questa regola. Preparatevi, ecco che arriva il cervello twister: Se due tipi di entità condividono gli stessi attributi e un’entità in uno dei tipi di entità è anche un’entità nell’altro tipo di entità (un’entità è un membro di entrambi i tipi di entità), i due tipi di entità possono essere rappresentati in una tabella. Eccolo, di nuovo: un tipo di entità professore e un tipo di entità consulente possono entrambi essere rappresentati in un’unica tabella, perché i consulenti sono anche professori e hanno gli stessi attributi (nome professore/consulente, qualifiche professore/consulente e altri). E ancora: Un tipo di entità cartella e un tipo di entità sottocartella possono essere rappresentati in un’unica tabella, poiché tutte le entità della sottocartella sono anche entità cartella e condividono gli stessi attributi (titolo della cartella, dimensione della cartella, numero di elementi nella cartella, cartella principale e altri). Solo un altro: i tipi di entità dipendente e manager possono essere rappresentati nella stessa tabella, poiché i dipendenti e le entità manager hanno gli stessi attributi e le entità manager sono anche entità dipendenti. Questa eccezione alla regola viene esaminata più da vicino in un altro blog: SQL Server – La query Self Join.

A proposito, si noti che questa regola è la ragione per cui il modo corretto di nominare una tabella è al singolare. Le tabelle rappresentano un singolo tipo di entità.

Regola 2: Tutte le colonne devono essere atomiche.

Ti sei mai chiesto perché le tabelle del database potrebbero avere colonne per Città e Stato, ma solo una colonna per l’indirizzo? Forse ti sei chiesto perché non c’è una colonna per il numero di indirizzo, un’altra per il tipo di indirizzo (Blvd., Viale, ecc.), un altro per il numero di appartamento, e così via. Perché queste colonne di solito sono tutte raggruppate in una singola colonna di indirizzo? La risposta a tutte queste domande sta nella comprensione dell’atomicità.

Quando diciamo che una colonna è atomica, intendiamo che non può essere ulteriormente suddivisa e conserva ancora il significato. Creiamo una colonna e chiamiamola MegaAddress che include un indirizzo stradale insieme a città e stato.

Ma poiché eseguiamo ricerche, ordinamenti e altre operazioni su porzioni di quella colonna (ricerca per città, ordinamento per stato, stampa solo la parte dell’indirizzo stradale e così via), possiamo dire che le suddivisioni di quella colonna hanno il loro significato (StreetAddress, City e State). Quindi, MegaAddress non è atomico. Un tavolo migliore sarebbe:

Ora, per quanto riguarda la colonna StreetAddress? Dovremmo suddividerlo ulteriormente in StreetNumber, StreetName e StreetType? Finché non facciamo nulla di significativo con suddivisioni di esso – se non ordiniamo sui numeri stradali, cerchiamo tutte le strade o viali e così via—allora la colonna è atomica così com’è. Ma se facciamo queste cose, allora la colonna non è atomica e quindi, sì, dovremmo suddividerla come descritto.

Regola 3: le colonne non possono essere multivalore.

Alcuni tipi di entità contengono attributi multivalore o un attributo che può avere più di un valore. In una tabella del corso, può esserci un attributo chiamato Prerequisiti. Poiché un’entità corso può avere più di un prerequisito, l’attributo Prerequisito è un attributo multivalore. Quando creiamo una tabella per il tipo di entità del corso, non saremo in grado di rappresentare l’attributo Prerequisito come colonna nella tabella. Per rappresentare correttamente un attributo multivalore, dovremo creare un’altra tabella per esso e relazionarlo alla tabella originale usando una relazione uno-a-molti (le relazioni sono discusse in dettaglio nei corsi che insegno all’interfaccia Tachnical Training SQL100: Introduzione a Transact-SQL e SQL250: Transact-SQL per gli sviluppatori e nel mio articolo, Un approccio intuitivo alla progettazione di database). Altri esempi di attributi multivalore includono i dipendenti di un dipendente, le qualifiche di un medico e così via.

La regola 3 dice che, per una determinata entità (riga in una tabella), può esserci un solo valore in ogni colonna.

Sommario

Questo post ha introdotto il concetto di mini-mondo come gli aspetti di un business o altro ambiente che un database modelli. Il post ha anche descritto una tabella di database come rappresentante di un singolo tipo di entità in cui le righe contengono le singole entità dello stesso tipo e le colonne rappresentano gli attributi di tali entità. Sono state introdotte tre regole relative alle tabelle. La regola 1 afferma che una tabella dovrebbe rappresentare un singolo tipo di entità. L’eccezione alla regola è quando due tipi di entità condividono gli stessi attributi e le entità in un tipo di entità sono membri dell’altro tipo di entità. In tal caso, entrambi i tipi di entità possono essere rappresentati nella stessa tabella. La regola 2 afferma che tutte le colonne di una tabella devono essere atomiche, il che significa che una colonna non può essere suddivisa e conserva ancora il significato nel mini-mondo. Infine, la regola 3 afferma che le colonne in una tabella non possono essere multivalore, il che significa che, per una determinata entità (riga in una tabella), può esserci un solo valore per colonna.

Buon divertimento!

Peter Avila

SQL Server Instructor – Interface Technical Training

Phoenix, AZ