înțelegerea blocuri de baze de date în SQL Server

ca acest Blog 3

adăugat de Peter Avila noiembrie 21, 2012

fiecare casă are o bucătărie, cel puțin o baie și un dormitor, o ușă din față, un sistem de instalații sanitare și alte lucruri. Aceste lucruri pot fi aranjate în moduri diferite și în numere diferite pentru a produce case diferite. Deci, este cu baze de date. Există anumite lucruri pe care toate bazele de date le au în comun. În această postare, voi introduce blocurile care alcătuiesc toate bazele de date și voi arăta cum sunt asamblate. Voi discuta, de asemenea, trei reguli care trebuie respectate atunci când se utilizează blocurile de construcție.

materialul prezentat în acest post ar trebui să fie de valoare pentru oricine are orice fel de interacțiune cu bazele de date, dar este la un nivel foarte elementar. Pentru o discuție mai cuprinzătoare despre proiectarea bazelor de date, vă rugăm să consultați articolul meu, o abordare intuitivă a proiectării bazelor de date.

Mini-Lumi.

înainte de a ajunge la blocurile de construcție, să luăm un moment pentru a înțelege termenul mini-lume, deoarece ne va ajuta să înțelegem blocurile de construcție.

o bază de date este un model al unei mini-lumi. O mini-lume poate fi un cabinet medical, o afacere cu amănuntul, o bibliotecă sau multe alte lucruri. Când vrem informații despre mini-lume, apelăm la baza de date care o modelează.

să presupunem că mergeți la medic pentru o întâlnire. Când îi spuneți recepționerului că aveți o întâlnire, recepționerul va încerca să vă găsească întâlnirea în model (baza de date). Dacă modelul a fost menținut la curent cu mini-lumea sa, ar trebui să poată confirma că aveți o întâlnire. În mod similar, dacă o afacere dorește să știe care dintre clienții lor cu volum mare nu au plasat comenzi în ultimele 6 luni, pot apela la modelul mini-lumii lor dacă a fost menținut la curent cu acea mini-lume.

o mini-lume poate fi o afacere întreagă sau poate face parte dintr-o afacere, cum ar fi o sucursală bancară sau departamentul de vânzări.

primul lucru pe care îl face un designer de baze de date este să înțeleagă mini-lumea, deoarece sarcina designerului este să proiecteze un model al acelei mini-lumi. Și pentru a înțelege mini-lumea, proiectantul începe prin identificarea blocurilor care vor intra în asamblarea unei baze de date.

Blocurile De Construcție

1. Entități

o entitate este ceva care există în mini-lume și care are caracteristici care ne interesează. De exemplu, într-o mini-lume de înscriere la școală, există entități studențești, entități de curs, entități de instructor și altele. Elevii au nume, adrese, GPA-uri și alte caracteristici care ne interesează. Cursurile au titluri, credite, Taxe și altele. Și instructorii au nume, adrese, calificări și altele. Entitățile sunt unice. Fiecare student este o entitate unică; există Ioan și Maria și așa mai departe. Fiecare curs este o entitate unică și fiecare instructor este o entitate unică.

entitățile nu trebuie să fie lucruri fizice. Deși nu puteți atinge, vedea sau mirosi o înscriere, totuși există în mini-lumea înscrierii la școală și are caracteristici care ne interesează, cum ar fi data înscrierii, studentul care s-a înscris, cursul la care s-a înscris elevul și nota finală primită. Vânzările sunt alte exemple de entități care nu au o componentă fizică, dar care au caracteristici de interes pentru noi (data vânzării, clientul, agentul de vânzări, totalul comenzii, metoda de expediere, condițiile de plată etc.).

2. Tipurile de entități

entitățile de același tip aparțin unui tip de entitate. Un tip de entitate este un set de entități de acest tip. Tipul de entitate studențească este setul tuturor studenților. Tipul entității cursului este setul tuturor cursurilor, iar tipul entității instructorului este setul tuturor instructorilor.

tipurile de entități sunt cel mai important concept din acest post. Ele devin tabele într-o bază de date.

3. Atribute

atributele unei entități sunt caracteristicile acelei entități care ne interesează. După cum sa menționat deja, atributele studenților includ numele, adresa, GPA și altele. Cursurile au nume, credite, departamente din care fac parte și altele. Și așa mai departe cu alte tipuri de entități.

asamblarea blocurilor de construcție

cum sunt reprezentate aceste blocuri de construcție în baza de date? Fiecare tip de entitate este reprezentat de un tabel în baza de date. În acel tabel, rândurile individuale sunt entitățile unice, iar coloanele sunt atributele. Iată un exemplu de tabel care reprezintă tipul de entitate al cardului de Credit:

reguli de blocuri de construcție

când lucrați cu blocuri de construcție, este important să respectați anumite reguli care nu numai că facilitează lucrul cu obiectele bazei de date, ci și împiedică anomaliile datelor (anomaliile de date depășesc domeniul de aplicare al acestui post, dar sunt discutate în detaliu în articolul meu, o abordare intuitivă a proiectării bazei de date).

Regula 1: fiecare tabel trebuie să reprezinte un singur tip de entitate.

baza de date a înscrierii școlare mini-lume, de mai sus, are nevoie de următoarele tabele: Student, curs, Instructor, înscriere și altele, câte una pentru fiecare tip de entitate identificat în acea mini-lume. Baza de date a cabinetului medical mini-world are nevoie de o masă de medic, o masă de pacienți, o masă de întâlniri, o masă de medicamente și altele. Un tabel pentru fiecare tip de entitate.

există o excepție de la această regulă. Pregateste-te, aici vine twister creier: Dacă două tipuri de entități au aceleași atribute și o entitate dintr-unul dintre tipurile de entități este, de asemenea, o entitate din celălalt tip de entitate (o entitate este membru al ambelor tipuri de entități), atunci cele două tipuri de entități pot fi reprezentate într-un singur tabel. Iată, din nou: un tip de entitate profesor și un tip de entitate consilier pot fi reprezentate într-un singur tabel, deoarece consilierii sunt și profesori și au aceleași atribute (numele profesorului/consilierului, calificările profesorului/consilierului și altele). Și din nou: Un tip de entitate de Folder și un tip de entitate de SubFolder pot fi reprezentate într-un singur tabel, deoarece toate entitățile de SubFolder sunt, de asemenea, entități de Folder și au aceleași atribute (titlul folderului, dimensiunea folderului, numărul de elemente din folder, folderul părinte și altele). Încă una: tipurile de entități angajat și Manager pot fi reprezentate în același tabel, deoarece angajații și entitățile manager au aceleași atribute, iar entitățile manager sunt, de asemenea, entități angajat. Această excepție de la regulă este examinată mai îndeaproape într – un alt blog: SQL Server-interogarea Self Join.

apropo, observați că această regulă este motivul pentru care modul corect de a numi un tabel este la singular. Tabelele reprezintă un singur tip de entitate.

Regula 2: toate coloanele trebuie să fie atomice.

v-ați întrebat vreodată de ce tabelele bazei de date ar putea avea coloane pentru oraș și stat, dar o singură coloană pentru adresă? Poate v-ați întrebat de ce nu există o coloană pentru numărul adresei, alta pentru tipul străzii adresei (Blvd., Bulevard etc.), altul pentru numărul apartamentului și așa mai departe. De ce sunt aceste coloane, de obicei, toate lumped împreună într-o singură coloană adresă? Răspunsul la toate aceste întrebări constă într-o înțelegere a atomicității.

când spunem că o coloană este atomică, ne referim la faptul că nu poate fi subdivizată în continuare și încă păstrează sensul. Să alcătuim o coloană și să o numim MegaAddress care include o adresă stradală împreună cu orașul și statul.

dar pentru că facem căutări, Sortează și alte operațiuni pe porțiuni din acea coloană (Căutare după oraș, Sortare după stat, imprima doar partea adresă stradă, și așa mai departe), putem spune că subdiviziuni ale acelei coloane au propriul lor sens (StreetAddress, oraș, și de stat). Deci, MegaAddress nu este atomic. O masă mai bună ar fi:

acum, Ce zici de coloana StreetAddress? Ar trebui să ne subdiviza că în jos în continuare în StreetNumber, StreetName și StreetType? Atâta timp cât nu facem nimic semnificativ cu subdiviziunile sale—dacă nu sortăm numerele străzilor, nu căutăm toate drumurile sau bulevardele și așa mai departe—atunci coloana este atomică așa cum este. Dar dacă facem aceste lucruri, atunci coloana nu este atomică și atunci, da, ar trebui să o subdivizăm așa cum este descris.

Regula 3: coloanele nu pot fi multivaluate.

unele tipuri de entități conțin atribute multivaloare sau un atribut care poate avea mai multe valori. Într-un tabel de curs, poate exista un atribut numit premise. Deoarece o entitate curs poate avea mai mult de o condiție prealabilă, atributul condiție este un atribut multivaloare. Când vom crea un tabel pentru tipul de entitate curs, nu vom fi în măsură să reprezinte atributul condiție prealabilă ca o coloană în tabel. Pentru a reprezenta corect un atribut multivalor, va trebui să creăm un alt tabel pentru acesta și să îl raportăm la tabelul original folosind o relație unu-la-mulți (relațiile sunt discutate în detaliu în cursurile pe care le predau la Interface Tachnic Training SQL100: Introducere în Transact-SQL și SQL250: Transact-SQL pentru dezvoltatori și în articolul meu, o abordare intuitivă a proiectării bazelor de date). Alte exemple de atribute multivaluate includ dependenții unui angajat, calificările unui medic și așa mai departe.

Regula 3 spune că, pentru o entitate dată (rând într-un tabel), poate exista o singură valoare în fiecare coloană.

rezumat

această postare a introdus conceptul de mini-lume ca aspecte ale unei afaceri sau alt mediu pe care o modelează o bază de date. Postarea a descris, de asemenea, un tabel de baze de date ca reprezentând un singur tip de entitate în care rândurile dețin entitățile individuale de același tip, iar coloanele reprezintă atributele acelor entități. Au fost introduse trei reguli privind tabelele. Regula 1 prevede că un tabel ar trebui să reprezinte un singur tip de entitate. Excepția de la regulă este atunci când două tipuri de entități au aceleași atribute și entitățile dintr-un tip de entitate sunt membre ale celuilalt tip de entitate. În acest caz, ambele tipuri de entități pot fi reprezentate în același tabel. Regula 2 afirmă că toate coloanele unui tabel trebuie să fie atomice, ceea ce înseamnă că o coloană nu poate fi subdivizată și păstrează încă sensul În mini-lume. În cele din urmă, regula 3 afirmă că coloanele dintr-un tabel nu pot fi multivaluate, ceea ce înseamnă că, pentru o entitate dată (rând într-un tabel), poate exista o singură valoare pe coloană.

bucurați-vă!

Peter Avila

SQL Server Instructor-interfață de formare tehnică

Phoenix, AZ