Free Press

Modelul de date Entity Relationship (ER) există de peste 35 de ani. Este bine adaptat pentru modelarea datelor pentru utilizarea cu baze de date deoarece este destul de abstract și este ușor de discutat și explicat. Modelele ER sunt ușor de tradus în relații. Modelele ER, denumite și schemă ER, sunt reprezentate prin diagrame ER.

Modelarea ER se bazează pe două concepte:

• Entități, definite ca tabele care conțin informații specifice (date)
• Relații, definite ca asociații sau interacțiuni între entități

Iată un exemplu de cum pot fi combinate aceste două concepte într-un model de date ER: Prof. Ba (entitate) predă (relație) cursul de Sisteme de baze de date (entitate).

Pentru restul acestui capitol, vom utiliza o bază de date de probă numită baza de date COMPANIA pentru a ilustra conceptele modelului ER. Această bază de date conține informații despre angajați, departamente și proiecte. Punctele importante de reținut includ:

• Există mai multe departamente în cadrul companiei. Fiecare departament are o identificare unică, un nume, locația biroului și un anumit angajat care gestionează departamentul.
• Un departament controlează un număr de proiecte, fiecare dintre acestea având un nume unic, un număr unic și un buget.
• Care angajat are un nume, un număr de identificare, o adresă, un salariu și o dată de naștere. Un angajat este atribuit unui singur departament, dar poate participa la mai multe proiecte. Trebuie să înregistrăm data de început a angajatului în fiecare proiect. De asemenea, trebuie să știm care este superiorul direct al fiecărui angajat.
• Vrem să ținem evidența persoanelor aflate în întreținere pentru fiecare angajat. Fiecare persoană dependentă are un nume, o dată de naștere și o relație cu angajatul.

Entity, Entity Set and Entity Type

O entitate este un obiect din lumea reală cu o existență independentă care poate fi diferențiată de alte obiecte. O entitate poate fi

Entitățile pot fi clasificate în funcție de puterea lor. O entitate este considerată slabă dacă tabelele sale sunt dependente de existență.

• Aceasta înseamnă că nu poate exista fără o relație cu o altă entitate
• Cheia sa primară este derivată din cheia primară a entității-mamă
  • Tabela Spouse, din baza de date COMPANY, este o entitate slabă deoarece cheia sa primară este dependentă de tabela Employee. Fără o înregistrare corespunzătoare a angajatului, înregistrarea soțului/soției nu ar exista.

O entitate este considerată puternică dacă poate exista separat de toate entitățile sale înrudite.

• Kernelurile sunt entități puternice.
• Un tabel fără o cheie străină sau un tabel care conține o cheie străină care poate conține nulități este o entitate puternică

Un alt termen care trebuie cunoscut este tipul de entitate care definește o colecție de entități similare.

Un set de entități este o colecție de entități de un tip de entitate la un anumit moment dat. Într-o diagramă de relații între entități (ERD), un tip de entitate este reprezentat de un nume într-o casetă. De exemplu, în figura 8.1, tipul de entitate este EMPLOYEE.

Existența dependenței

Existența unei entități depinde de existența entității aferente. Aceasta este dependentă de existență dacă are o cheie externă obligatorie (adică un atribut de cheie externă care nu poate fi nul). De exemplu, în baza de date COMPANY, o entitate Spouse este dependentă de existența entității Employee.

Kinds of Entities

De asemenea, trebuie să fiți familiarizați cu diferite tipuri de entități, inclusiv entități independente, entități dependente și entități caracteristice. Acestea sunt descrise mai jos.

Entități independente

Entitățile independente, denumite și nuclee, reprezintă coloana vertebrală a bazei de date. Ele sunt cele pe care se bazează celelalte tabele. Nucleele au următoarele caracteristici:

• Ele sunt elementele de bază ale unei baze de date.
• Cheia primară poate fi simplă sau compusă.
• Cheia primară nu este o cheie străină.
• Nu depind de o altă entitate pentru existența lor.

Dacă ne referim din nou la baza noastră de date COMPANY, exemple de entități independente includ tabelul Customer, tabelul Employee sau tabelul Product.

Entități dependente

Entitățile dependente, denumite și entități derivate, depind de alte tabele pentru semnificația lor. Aceste entități au următoarele caracteristici:

• Entitățile dependente sunt utilizate pentru a conecta două nuclee între ele.
• Se spune despre ele că depind de existența a două sau mai multe tabele.
• Relațiile de tip multiplu devin tabele asociative cu cel puțin două chei străine.
• Pot conține și alte atribute.
• Cheia străină identifică fiecare tabel asociat.
• Există trei opțiuni pentru cheia primară:
  1. Utilizați un compozit de chei străine ale tabelelor asociate, dacă sunt unice
  2. Utilizați un compozit de chei străine și o coloană calificativă
  3. Crearea unei noi chei primare simple

Entități caracteristice

Entitățile caracteristice oferă mai multe informații despre un alt tabel. Aceste entități au următoarele caracteristici:

• Reprezintă atribute cu mai multe valori.
• Descriu alte entități.
• De obicei, au o relație de tip unu la mulți.
• Cheia externă este utilizată pentru a identifica în continuare tabelul caracterizat.
• Opțiunile pentru cheia primară sunt următoarele:
  1. Utilizați un compus de cheie externă plus o coloană calificativă
  2. Crearea unei noi chei primare simple. În baza de date COMPANY, acestea ar putea include:
     • Employee (EID, Name, Address, Age, Salary) – EID este cheia primară simplă.
     • EmployeePhone (EID, Phone) – EID este parte a unei chei primare compozite. Aici, EID este, de asemenea, o cheie externă.

Atribute

Care entitate este descrisă de un set de atribute (de exemplu, Employee = (Name, Address, Birthdate (Age), Salary).

Care atribut are un nume și este asociat cu o entitate și un domeniu de valori legale. Cu toate acestea, informațiile despre domeniul atributului nu sunt prezentate pe ERD.

În diagrama de relații între entități, prezentată în figura 8.2, fiecare atribut este reprezentat de un oval cu un nume în interior.

Tipuri de atribute

Există câteva tipuri de atribute cu care trebuie să fiți familiarizați. Unele dintre acestea trebuie lăsate așa cum sunt, dar altele trebuie ajustate pentru a facilita reprezentarea în modelul relațional. Această primă secțiune va discuta tipurile de atribute. Mai târziu vom discuta despre fixarea atributelor pentru a se potrivi corect în modelul relațional.

Atribute simple

Atributele simple sunt cele extrase din domeniile de valori atomice; ele se mai numesc și atribute cu o singură valoare. În baza de date COMPANY, un exemplu ar fi: Nume = {John} ; Vârsta = {23}

Atribute compuse

Atributele compuse sunt cele care constau într-o ierarhie de atribute. Utilizând exemplul bazei noastre de date și prezentat în figura 8.3, adresa poate fi compusă din număr, stradă și suburbie. Așadar, acesta ar fi scris ca → Address = {59 + ‘Meek Street’ + ‘Kingsford’}

Atribute multivalorate

Atributele multivalorate sunt atribute care au un set de valori pentru fiecare entitate. Un exemplu de atribut multivalorat din baza de date COMPANY, așa cum se vede în figura 8.4, sunt gradele unui angajat: BSc, MIT, PhD.

Atribute derivate

Atributele derivate sunt atribute care conțin valori calculate din alte atribute. Un exemplu în acest sens poate fi văzut în figura 8.5. Vârsta poate fi derivată din atributul Birthdate (Data nașterii). În această situație, Birthdate se numește un atribut stocat, care este salvat fizic în baza de date.

Caife

O constrângere importantă asupra unei entități este cheia. Cheia este un atribut sau un grup de atribute ale căror valori pot fi utilizate pentru a identifica în mod unic o entitate individuală într-un set de entități.

Tipuri de chei

Există mai multe tipuri de chei. Acestea sunt descrise mai jos.

Calea candidată

O cheie candidată este o cheie simplă sau compusă care este unică și minimă. Ea este unică deoarece nu există două rânduri dintr-un tabel care să aibă aceeași valoare în orice moment. Este minimă deoarece fiecare coloană este necesară pentru a obține unicitatea.

Din exemplul nostru de bază de date COMPANY, dacă entitatea este Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID), cheile candidate posibile sunt:

• EID, SIN
• First Name and Last Name – presupunând că nu mai există nimeni altcineva în companie cu același nume
• Last Name and DepartmentID – presupunând că două persoane cu același nume de familie nu lucrează în același departament

Cheie compozită

O cheie compozită este compusă din două sau mai multe atribute, dar trebuie să fie minimă.

Utilizând exemplul din secțiunea privind cheile candidate, cheile compozite posibile sunt:

:

• First Name and Last Name – presupunând că nu mai există nimeni altcineva în companie cu același nume
• Last Name and Department ID – presupunând că două persoane cu același nume de familie nu lucrează în același departament

Cheie primară

Cheia primară este o cheie candidată care este selectată de către proiectantul bazei de date pentru a fi utilizată ca mecanism de identificare pentru întregul set de entități. Ea trebuie să identifice în mod unic tuplurile dintr-un tabel și să nu fie nulă. Cheia primară este indicată în modelul ER prin sublinierea atributului.

• O cheie candidată este selectată de către proiectant pentru a identifica în mod unic tuplurile dintr-un tabel. Ea nu trebuie să fie nulă.
• O cheie este aleasă de către proiectantul bazei de date pentru a fi utilizată ca mecanism de identificare pentru întregul set de entități. Aceasta se numește cheie primară. Această cheie este indicată prin sublinierea atributului în modelul ER.

În exemplul următor, EID este cheia primară:

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

Ceava secundară

O cheie secundară este un atribut utilizat strict în scopuri de regăsire (poate fi compozit), de exemplu: Phone și Last Name.

Alternate key

Cele alternative sunt toate cheile candidate care nu sunt alese ca cheie primară.

Foreign key

O cheie externă (FK) este un atribut dintr-un tabel care face referire la cheia primară dintr-un alt tabel SAU poate fi nulă. Atât cheile străine, cât și cheile primare trebuie să fie de același tip de date.

În exemplul de bază de date COMPANY de mai jos, DepartmentID este cheia străină:

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

Nulls

Un null este un simbol special, independent de tipul de date, care înseamnă fie necunoscut, fie inaplicabil. Nu înseamnă zero sau gol. Caracteristicile lui null includ:

• Nu se introduc date
• Nu este permis în cheia primară
• Ar trebui evitat în alte atribute
• Poate reprezenta
  • O valoare necunoscută a unui atribut
  • O valoare cunoscută, dar lipsă, o valoare de atribut
  • O condiție „nu se aplică”
• Poate crea probleme atunci când se utilizează funcții precum COUNT, AVERAGE și SUM
• Poate crea probleme logice atunci când tabelele relaționale sunt legate

NOTA: Rezultatul unei operații de comparare este nul atunci când oricare dintre argumente este nul. Rezultatul unei operații aritmetice este nul atunci când oricare dintre argumente este nul (cu excepția funcțiilor care ignoră nulitățile).

Exemplu de utilizare a lui null

Utilizați tabelul Salary (Salary_tbl) din figura 8.6 pentru a urmări un exemplu de utilizare a lui null.

Pentru început, găsiți toți angajații (emp#) din Sales (sub coloana jobName) al căror salariu plus comisionul sunt mai mari de 30.000.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (comision + salariu) > 30,000 -> E10 și E12

Acest rezultat nu include E13 din cauza valorii nule din coloana comision. Pentru a ne asigura că rândul cu valoarea nulă este inclus, trebuie să ne uităm la câmpurile individuale. Prin adăugarea comisionului și a salariului pentru angajatul E13, rezultatul va fi o valoare nulă. Soluția este prezentată mai jos.

Relații

Relațiile sunt lipiciul care ține tabelele împreună. Ele sunt utilizate pentru a conecta informațiile legate între tabele.

Relațiile se bazează pe modul în care este definită cheia primară a unei entități legate. O relație slabă, sau neidentificabilă, există dacă cheia primară a entității înrudite nu conține o componentă de cheie primară a entității-mamă. Exemple de baze de date ale companiilor includ:

• Customer(CustID, CustName)
• Order(OrderID, CustID, Date)

O relație puternică, sau de identificare, există atunci când cheia primară a entității înrudite conține componenta cheie primară a entității-mamă. Exemplele includ:

• Curs(CrsCode, DeptCode, Description)
• Class(CrsCode, Section, ClassTime…)

Tipuri de relații

Mai jos sunt descrise diferitele tipuri de relații.

Relația unu la mulți (1:M)

O relație unu la mulți (1:M) ar trebui să fie norma în orice proiect de bază de date relațională și se găsește în toate mediile de baze de date relaționale. De exemplu, un departament are mulți angajați. Figura 8.7 prezintă relația dintre unul dintre acești angajați și departament.

Relație unu la unu (1:1)

O relație unu la unu (1:1) este relația unei entități cu o singură altă entitate și viceversa. Ea ar trebui să fie rară în orice proiect de bază de date relațională. De fapt, ar putea indica faptul că două entități aparțin de fapt aceluiași tabel.

Un exemplu din baza de date COMPANY este că un angajat este asociat cu un soț, iar un soț este asociat cu un angajat.

Relații de la mulți la mulți (M:N)

Pentru o relație de la mulți la mulți, luați în considerare următoarele puncte:

• Nu poate fi implementată ca atare în modelul relațional.
• Poate fi transformată în două relații 1:M.
• Poate fi implementată prin rupere pentru a produce un set de relații 1:M.
• Implică implementarea unei entități compozite.
• Creează două sau mai multe relații 1:M.
• Tabela entității compozite trebuie să conțină cel puțin cheile primare ale tabelelor originale.
• Tabloul de legătură conține mai multe apariții ale valorilor cheilor străine.
• Se pot atribui atribute suplimentare, după cum este necesar.
• Se pot evita problemele inerente unei relații M:N prin crearea unei entități compozite sau a unei entități punte. De exemplu, un angajat poate lucra la mai multe proiecte SAU un proiect poate avea mai mulți angajați care lucrează la el, în funcție de regulile de afaceri. Sau, un student poate avea mai multe clase și o clasă poate avea mai mulți studenți.

Figura 8.8 prezintă un alt aspect al relației M:N în care un angajat are date de începere diferite pentru diferite proiecte. Prin urmare, avem nevoie de un tabel JOIN care să conțină EID, Code și StartDate.

Exemplu de cartografiere a unui tip de relație binară M:N

• Pentru fiecare relație binară M:N, identificați două relații.
• A și B reprezintă două tipuri de entități care participă la R.
• Crearea unei noi relații S pentru a reprezenta R.
• S trebuie să conțină PK-urile lui A și B. Acestea împreună pot fi PK-ul din tabelul S SAU acestea împreună cu un alt atribut simplu din noul tabel R pot fi PK-ul.
• Combinația cheilor primare (A și B) va constitui cheia primară a tabelului S.

Relație unară (recursivă)

O relație unară, numită și recursivă, este o relație în care există o relație între apariții ale aceluiași set de entități. În această relație, cheile primare și străine sunt aceleași, dar ele reprezintă două entități cu roluri diferite. A se vedea figura 8.9 pentru un exemplu.

Pentru unele entități aflate într-o relație unară, se poate crea o coloană separată care se referă la cheia primară a aceluiași set de entități.

Relații ternare

O relație ternară este un tip de relație care implică relații multe la multe între trei tabele.

Referiți-vă la figura 8.10 pentru un exemplu de cartografiere a unui tip de relație ternară. Rețineți că n-ary înseamnă mai multe tabele într-o relație. (Rețineți, N = multe.)

• Pentru fiecare relație n-ară (> 2), creați o nouă relație pentru a reprezenta relația.
• Ceea primară a noii relații este o combinație a cheilor primare ale entităților participante care dețin partea N (multe).
• În cele mai multe cazuri ale unei relații n-ary, toate entitățile participante dețin o latură many.

Atribuții

Acest capitol din Proiectarea bazelor de date (inclusiv imaginile, cu excepția cazului în care se menționează altfel) este o copie derivată a lucrării Data Modeling Using Entity-Relationship Model de Nguyen Kim Anh licențiată sub licența Creative Commons Attribution License 3.0 license

Celelalte materiale au fost scrise de Adrienne Watt:

1. Secțiunea Nulls și exemplu
2. Termeni cheie
3. Exerciții

.