Model de date entitate-relație. Model de bază de date conceptuală - Diagrama relației obiect
Pentru a dezvolta o bază de date a cărei structură nu depinde de specific nevoi de informareși vă permite să îndepliniți orice solicitare a utilizatorului, diagrama modelului informațional „entitate-relație” (diagrama ER) servește ca diagramă.
Cea mai comună formalizare a ideilor despre domeniul subiectului realizat în cadrul modelului „entitate-relație” („obiecte relaționale”). Pe în această etapă proiectare, se folosește metoda „relație-esență”, care se mai numește și metoda „diagramă ER” („Esență” - entitate, „Relație” - conexiune). Această metodă se bazează pe utilizarea diagramelor numite diagrame de instanță ER și, respectiv, diagrame de tip ER.
ER – o diagramă „entitate-relație” este un ansamblu de multe obiecte și caracteristicile acestora, precum și relațiile dintre ele, necesare identificării datelor care sunt ulterior utilizate de funcțiile sistemului proiectat.
Principalele concepte ale metodei entitate-relație sunt următoarele:
Esență;
atribut de entitate;
cheie de entitate;
Relația dintre entități;
Gradul de conectare;
Clasa de apartenență a instanțelor de entitate;
diagrame de instanță ER;
Diagrame de tip ER.
Un obiect informațional este înțeles ca o entitate dintr-un fragment de realitate, de exemplu: o organizație, un document, un angajat, un loc, un eveniment etc. O entitate este un obiect despre care informațiile sunt stocate într-o bază de date. Instanțele de entitate sunt distincte unele de altele și sunt identificate în mod unic. Numele de entități sunt substantive. Fiecare tip de obiect este identificat prin setul său inerent de atribute. In acest proiect de curs Entitățile sunt: salariat, posturi, educație, forme de participare la muncă, facultăți, departamente și subiecte.
Un atribut ((din latină attributo - atribut) - o proprietate sau un lucru inseparabil de un obiect) este un element indivizibil din punct de vedere logic al structurii informaționale, caracterizat printr-o multitudine de valori atomice. Acest concept este similar cu conceptul de „atribut” într-o relație. O instanță de obiect este caracterizată printr-un set de valori specifice atributelor unui anumit tip de obiect. Unul sau un grup de atribute ale unui obiect de acest tip poate juca rolul unui atribut cheie (cheie de entitate). În acest proiect de curs, entitățile de mai sus sunt caracterizate prin atribute, cum ar fi: cod_departament, nume_departament, cod_departament, nume_angajat etc.
O cheie de entitate este un atribut sau un set de atribute care identifică o instanță a unei entități (de exemplu, job_code).
O relație între două sau mai multe entități este o dependență între atributele acelor entități. Se notează printr-un verb. În plus, există două tipuri de conexiuni:
Ierarhic;
Un singur nivel.
Pentru a îmbunătăți claritatea și ușurința de proiectare, folosim instrumente grafice reprezentări ale unei entități, instanțe de entitate și relații dintre acestea. Diagrama ER este prezentată în Anexa A.
Clasificarea conexiunilor
În bazele de date reale, informațiile sunt plasate în mai multe tabele. Tabelele sunt legate prin semantică informațională. ÎN SGBD relațional Pentru a indica relațiile dintre tabele se realizează operația de legare a acestora. Acest lucru crește fiabilitatea informațiilor stocate în baza de date, deoarece SGBD controlează integritatea datelor introduse în baza de date în conformitate cu conexiunile stabilite.
Stabilirea conexiunilor facilitează accesul la date atunci când se efectuează operațiuni: căutarea, vizualizarea, editarea, preluarea și pregătirea unui raport, deoarece este oferit accesul la orice câmpuri ale tabelelor asociate.
Între mese pot fi instalate următoarele:
conexiuni binare;
Conexiuni ternare;
Legături N-are.
Când se leagă două tabele, se disting un tabel primar și un tabel subordonat (părinte și copil). Legătura logică a tabelelor se face folosind o cheie de legătură. Câmpurile principale ale tabelului pot fi simple sau cheie. Câmpuri de link mese suplimentare s sunt cel mai adesea cele cheie. În funcție de modul în care sunt definite câmpurile de conexiune ale tabelelor principale și suplimentare (cum se raportează câmpurile cheie la câmpurile de conexiune), se stabilesc tipurile de conexiuni:
1:1 (unu la unu);
1:M (unu la mulți);
M:1 (mulți la unu);
M:M (mulți la mulți).
O relație 1:1 se formează dacă toate câmpurile relației dintre tabelele părinte și copil sunt cheie. Deoarece valorile din câmpuri cheie două tabele nu se repetă, se asigură o corespondență unu-la-unu a înregistrărilor din aceste tabele. De fapt, mesele în sine devin egale aici.
O relație 1:M apare atunci când o înregistrare din tabelul părinte corespunde mai multor înregistrări din tabelul copil.
O relație M:1 apare atunci când una sau mai multe înregistrări ale tabelului principal sunt asociate cu o înregistrare a unui tabel suplimentar.
O relație M:M apare în cazurile în care mai multe înregistrări ale tabelului principal corespund mai multor înregistrări ale tabelului suplimentar.
Similar cu o relație 1:1, o relație M:M nu stabilește subordonarea tabelelor. În practică, o relație implică de obicei mai multe tabele. În acest caz, o masă poate avea tipuri diferite conexiuni cu mai multe tabele, formând o ierarhie sau „arborele de relații”.
În acest proiect de curs, tabelele sunt conectate prin relații 1:M (unu-la-mai multe). De exemplu, tabelul „facultăți” este tabelul părinte al tabelului copil „departamente”. Aceste tabele sunt legate într-o relație 1:M folosind cheia „faculty_code”
Ca orice model, modelul „entitate-relație” are câteva concepte de bază care formează blocurile inițiale din care sunt construite obiecte mai complexe conform unor reguli predeterminate.
Acest model este cel mai în concordanță cu conceptul de design orientat pe obiecte, care în prezent este, fără îndoială, baza dezvoltării complexului sisteme software, atât de multe concepte vi se pot părea familiare, iar dacă acest lucru este adevărat, cu atât vă va fi mai ușor să stăpâniți tehnologia de proiectare a bazelor de date bazată pe modelul ER.
Modelul ER se bazează pe următoarele concepte de bază:
- Esența, cu cu ajutorul căreia se modelează o clasă de obiecte similare. O entitate are un nume care este unic în cadrul sistemului care este modelat. Deoarece o entitate corespunde unei anumite clase de obiecte de același tip, se presupune că există multe instanțe ale acestei entități în sistem. Obiectul căruia îi corespunde conceptul de entitate are un set propriu atribute - caracteristici care determină proprietățile unui reprezentant de clasă dat. În acest caz, setul de atribute trebuie să fie astfel încât să fie posibil să se distingă instanțe specifice ale entității. De exemplu, entitatea Salariat poate avea următorul set de atribute: Număr de personal, Nume, Prenume, Patronimic, Data nașterii, Număr copii, Prezența rudelor în străinătate. Este apelat un set de atribute care identifică în mod unic o anumită instanță a unei entități cheie. Pentru entitatea Angajat, atributul cheie va fi Număr de personal, deoarece pentru toți angajații a acestei intreprinderi numerele de personal vor fi diferite. O instanță a entității Angajat va fi o descriere a unui anumit angajat al întreprinderii. Una dintre cele general acceptate simboluri grafice entități - un dreptunghi, în partea superioară a căruia este scris numele entității, iar atributele sunt enumerate mai jos, cu atribute cheie marcate, de exemplu, cu subliniere sau un font special (Fig. 7.1):
Orez. 7.1.Exemplu de definire a entității în modelul ER
Între entități pot fi setate comunicatii- asociații binare care arată modul în care entitățile se relaționează sau interacționează între ele. O relație poate exista între două entități diferite sau între o entitate și ea însăși (conexiune recursiva). Acesta arată modul în care instanțele de entitate sunt legate între ele. Dacă se stabilește o relație între două entități, atunci aceasta definește relația dintre instanțe ale uneia și celeilalte entități. De exemplu, dacă avem o legătură între entitatea „Student” și entitatea „Profesor”, iar această legătură este supravegherea proiectelor de diplomă, atunci fiecare elev are un singur supervizor, dar același profesor poate supraveghea mulți absolvenți. Prin urmare, va fi o relație unu-la-mai mulți (1:M), una pe partea Profesorului și mulți pe partea Studentului (vezi Figura 7.2).
Orez. 7.2.Un exemplu de relație unu-la-mulți atunci când se leagă entitățile „Student” și „Profesor”
Diferitele notații exprimă puterea de comunicare în mod diferit. În exemplul nostru folosim notația CASE a sistemului POWER DESIGNER, aici multiplicitatea este reprezentată prin împărțirea legăturii în 3. Legătura are denumirea comună„Diploma Design” și are nume de rol din partea ambelor entități. Din partea elevului, acest rol se numește „Scrierea unei teze sub îndrumare”, din partea profesorului, această conexiune se numește „Supervizarea”. Interpretare grafică conexiunea vă permite să citiți imediat sensul relației dintre entități, este clar și ușor de interpretat. Conexiunile sunt împărțite în trei tipuri în funcție de multiplicitatea lor: unu la unu(1:1), od și i-la-mulți(1M), multi-la-multi(MM). O relație unu-la-unu înseamnă că o instanță a unei entități este legată doar de o instanță a altei entități.
Relația 1: M înseamnă că o instanță a unei entități situată în stânga relației poate fi asociată cu mai multe instanțe ale entității situate în partea dreaptă a relației. O relație unu-la-unu (1:1) înseamnă că o instanță a unei entități este asociată cu o singură instanță a altei entități, în timp ce o relație multi-la-mulți (M:M) înseamnă că o instanță a primei entități o entitate poate fi asociată cu mai multe instanțe ale unei a doua entități și, invers, o instanță a unei a doua entități poate fi asociată cu mai multe instanțe ale unei prime entități. De exemplu, dacă luăm în considerare o relație de tip „Studiu” între entitățile „Student” și „Disciplină”, atunci aceasta este o relație de tip „mulți-la-mulți” (M:M), deoarece fiecare student poate studia mai multe discipline, dar fiecare disciplină este studiată de mulți studenți. O astfel de legătură este prezentată în Fig. 7.3.
- Orice număr de conexiuni cu încărcări semantice diferite poate fi specificat între două entități. De exemplu, între două entități „Student” și „Profesor”, se pot stabili două conexiuni semantice, una este „Proiectarea diplomelor” discutată anterior, iar a doua poate fi numită condiționat „Prelegeri” și determină care cursuri ale profesorilor sunt acestea. elevul ascultă și pe care Acest profesor ține cursuri elevilor. Este clar că aceasta este o legătură ca multi-la-multi. Un exemplu de aceste conexiuni este prezentat în Fig. 7.3.
Orez. 7.3.Exemplu de modelare a unei relații multi-la-mulți
- Oricare dintre aceste tipuri de comunicare poate fi obligatoriu, dacă fiecare instanță a unei entități trebuie să participe la o anumită relație, optional - dacă nu fiecare instanță de entitate trebuie să participe la o anumită relație. În acest caz, conexiunea poate fi obligatoriu pe de o parteȘi opțional pe de altă parte. Caracterul obligatoriu al conexiunii este, de asemenea, indicat diferit în diferite notații. Folosim din nou notația POWER DESIGNER. Aici, opționalitatea unei conexiuni este indicată printr-un cerc gol la capătul conexiunii, iar obligația este indicată printr-o linie perpendiculară care taie legătura. Și această notație are o interpretare simplă. Un cerc înseamnă că nicio instanță nu poate participa la această legătură. Și perpendicular este interpretat ca însemnând că cel puțin o instanță a entității este implicată în această legătură.
Pentru a face acest lucru, luați în considerare exemplul dat anterior al conexiunii „Diploma Design”. În figura noastră, această conexiune este interpretată ca opțională pe ambele părți. Dar, de fapt, fiecare student care scrie o diplomă trebuie să aibă propriul director de proiectare a diplomei, dar, pe de altă parte, nu fiecare profesor ar trebui să conducă proiectarea tezei. Prin urmare, în această setare semantică, imaginea acestei conexiuni se va schimba și va arăta la fel ca în Fig. 7.4.
Orez. 7.4.Un exemplu de relație obligatorie și opțională între entități
În plus, modelul ER permite principiul categorizării entităților. Aceasta înseamnă că, ca și în limbajele de programare orientate pe obiecte, este introdus conceptul de subtip de entitate, adică o entitate poate fi reprezentată ca două sau mai multe dintre subtipurile sale - entitati, fiecare dintre acestea poate avea atribute și relații comune și/sau atribute și relații care sunt definite o dată la nivelul superiorși sunt moștenite de nivel inferior. Toate subtipurile unei entități sunt considerate a se exclude reciproc și, atunci când se împarte o entitate în subtipuri, aceasta ar trebui prezentată sub forma Set complet subtipuri care se exclud reciproc. Dacă la nivel de analiză nu se poate identifica o Listă completă de subtipuri, atunci se introduce un subtip special, numit condiționat ALTE, care poate fi clarificat în continuare. ÎN sisteme reale Uneori este suficient să introduceți subtipărirea la două sau trei niveluri.
Se numește entitatea pe baza căreia sunt construite subtipurile supertip. Orice instanță a unui supertip trebuie să aparțină unui subtip specific. Pentru imagine grafică principiul categorizării sau dactilografierii unei entități, o specială element grafic, numit nod discriminator,în notația POWER DESIGNER este reprezentat ca un semicerc cu latura sa convexă îndreptată spre super-entitate. Această latură este conectată printr-o săgeată direcționată la super-entitate, iar subtipurile acestei entități sunt conectate la diametrul acestui cerc prin săgeți (vezi Fig. 7.5).
Orez. 7.5.Diagrama de subtip de entitate TEST
Această diagramă poate fi descifrată după cum urmează. Fiecare test dintr-un sistem de testare este fie un test de cunoaștere a limbajului SQL, fie unele sarcina analitica, care se realizează folosind applet-uri Java pre-scrise, sau un test într-un anumit domeniu de cunoaștere, constând dintr-un set de întrebări și un set de răspunsuri propuse pentru fiecare întrebare.
Ca rezultat al construcției unui model de domeniu sub forma unui set de entități și relații, obținem un graf conex. În graficul rezultat, este necesar să se evite conexiunile ciclice - acestea dezvăluie incorectitudinea modelului.
Ca exemplu, vom proiecta un model mitologic al unui sistem conceput pentru a stoca informații despre cărți și domenii de cunoaștere prezentate în bibliotecă. Descrierea domeniului subiectului a fost dată mai devreme. Să începem dezvoltarea modelului prin identificarea principalelor entități.
În primul rând, există entitatea „Carte”, fiecare carte are un cifr unic, care este cheia ei, și o serie de atribute care sunt preluate din descrierea domeniului subiectului. Setul de instanțe de entitate definește setul de cărți care sunt stocate în bibliotecă. Fiecare instanță a entității „Carte” nu corespunde unei anumite cărți de pe raft, ci unei descrieri a unei anumite cărți, care este de obicei dată în catalogul de subiecte al bibliotecii. Fiecare carte poate fi prezentă în mai multe exemplare, iar acestea sunt doar acele cărți specifice care se află pe rafturile bibliotecii.
Pentru a reflecta acest lucru, trebuie să introducem o entitate Instanțe, care va conține descrieri ale tuturor copiilor cărților care sunt stocate în bibliotecă. Fiecare instanță a entității Instanțe corespunde unei anumite cărți de pe raft. Fiecare exemplar are un număr unic de acces care identifică în mod unic o anumită carte. În plus, fiecare exemplar al unei cărți poate fi fie în bibliotecă, fie în mâinile unui anumit cititor, iar în acest din urmă caz, pentru un anumit exemplar, data la care cititorul a preluat cartea și data preconizată a returnării carte sunt indicate suplimentar.
Există o relație unu-la-mulți (1:M) între entitățile „Cărți” și „Instanțe”, care este necesară de ambele părți. Ceea ce determină acest tip conexiuni? Putem presupune că fiecare carte poate fi prezentă în bibliotecă în mai multe exemplare, de unde relația unu-la-mulți. Mai mult, dacă biblioteca nu are o singură copie a unei anumite cărți, atunci nu vom stoca descrierea acesteia, deci dacă cartea este descrisă în esența „Carte”, atunci cel puțin o copie a acestei cărți este prezentă în bibliotecă. . Aceasta înseamnă că din partea cărții conexiunea este obligatorie. În ceea ce privește entitatea „Copii”, nu poate exista un singur exemplar în bibliotecă care să nu aibă legătură cu o anumită carte, de aceea este obligatorie și conectarea din partea „Copii”.
Acum trebuie să stabilim cum va fi reprezentat cititorul în sistemul nostru. Este firesc să propunem introducerea entității „Cititori” în acest scop, a cărei instanță va corespunde unui anumit cititor. În bibliotecă, fiecărui cititor i se atribuie un număr unic de card de bibliotecă, care va identifica în mod unic cititorul nostru. Numărul cardului de bibliotecă va fi un atribut cheie al entității Readers.
În plus, în entitatea „Cititori” trebuie să existe atribute suplimentare care sunt necesare pentru rezolvarea sarcinilor atribuite, aceste atribute vor fi: „Nume Prenume Patronimic”, „Adresa cititorului”, „Telefon de domiciliu” și „Telefon de serviciu”; . De ce am introdus două atribute separate pentru telefoane? Pentru că este necesar timp diferit sunați la aceste numere pentru a prinde un cititor, așa că va fi important ca administrația bibliotecii să știe ce tip acest telefon. În descrierea domeniului nostru de subiect există o restricție privind vârsta cititorilor noștri, așa că în esență trebuie introdus „Cititori” atributul necesar„Data nașterii”, care ne va permite să controlăm vârsta cititorilor noștri.
Din descrierea materiei, știm că fiecare cititor poate ține în mâini mai multe exemplare de cărți. Pentru a reflecta această situație, trebuie să facem o conexiune între entitățile „Cititori” și „Instanțe”. De ce nu între entitățile „Cititori” și „Cărți”? Pentru că cititorul ia o anumită copie a unei anumite cărți din bibliotecă, și nu doar o carte. Cum poți afla ce carte are un anumit cititor? Și acest lucru poate fi aflat de către comunicare suplimentarăîntre entitățile „Copii” și „Cărți”, iar această legătură asociază fiecare exemplar cu o carte, astfel încât putem oricând să stabilim fără ambiguitate care cărți sunt în mâinile cititorului, deși asociem doar numerele de inventar ale cărților luate. cu cititorul. Între entitățile „Cititori” și „Instanțe” se stabilește o relație unu-la-mulți și, în același timp, este opțională de ambele părți. Cititorul în acest moment poate să nu țină o singură carte în mâini și, pe de altă parte, această copie a cărții poate să nu fie în posesia vreunui cititor, ci pur și simplu să stea pe un raft din bibliotecă.
Acum trebuie să reflectăm ultima entitate care este asociată cu directorul de sistem. Catalogul de sistem conține o listă a tuturor domeniilor de cunoaștere, informații despre care sunt conținute în cărțile bibliotecii. Putem aminti catalogul de sistem din bibliotecă, din care de obicei începem să căutăm cărțile de care avem nevoie dacă nu le cunoaștem autorii și titlurile. Denumirea zonei de cunoștințe poate fi lungă și constă din mai multe cuvinte, așa că pentru a modela catalogul de sistem vom introduce entitatea „System Catalog” cu două atribute: „Knowledge Area Code” și „Knowledge Area Name”. Atributul Knowledge Area Code va fi atributul cheie al entității.
Din descrierea disciplinei, știm că fiecare carte poate conține informații din mai multe arii de cunoaștere, iar pe de altă parte, din practică știm că o bibliotecă poate conține multe cărți legate de aceeași arie de cunoaștere, deci trebuie să stabilim între entități „Catalog de sistem” și „Cărți” sunt o relație multi-la-mulți, obligatorie de ambele părți. Într-adevăr, catalogul de sistem nu ar trebui să conțină o astfel de zonă de cunoaștere, informații despre care nu sunt prezentate în nicio carte din biblioteca noastră, dimpotrivă, ar fi lipsită de sens. Și invers, fiecare carte ar trebui să fie atribuită uneia sau mai multor domenii de cunoaștere, astfel încât cititorul să o găsească mai repede.
Modelul mitologic al disciplinei „Bibliotecă” este prezentat în Fig. 7.6.
Orez. 7.6.Model mitologic „Biblioteca”
Am dezvoltat modelul mitologic „Biblioteca” pentru sarcinile enumerate mai devreme. În aceste sarcini, nu am stabilit o condiție pentru stocarea istoriei lecturii unei cărți, de exemplu, cu scopul de a găsi pe cineva care a ținut cartea anterior și ar fi putut să o facă rău sau să o lase în ea accidental. o mare cantitate bani. Dacă ne-am stabili sarcina de a stoca aceste informații, atunci modelul nostru logic informațional ar fi diferit. Voi lăsa această sarcină pentru creativitatea ta independentă.
Unul dintre cele mai populare mijloace de oficializare a domeniului de subiect al sistemelor axate pe prelucrarea informațiilor faptice este modelul „entitate-relație”, care stă la baza unui număr semnificativ de produse CASE comerciale care susțin ciclul complet de dezvoltare a sistemelor de baze de date. sau etapele sale individuale. În același timp, multe dintre ele nu numai că susțin etapa de proiectare conceptuală a domeniului subiect al sistemului în curs de dezvoltare, dar permit și etapa de proiectare logică să fie realizată pe baza modelului construit prin mijloacele lor. . generare automată o schemă de bază de date conceptuală pentru un SGBD selectat, de exemplu, o schemă de bază de date pentru un server SQL sau un SGBD obiect.
Modelarea domeniului în acest caz se bazează pe utilizare diagrame grafice, inclusiv un număr relativ mic de componente și, cel mai important - tehnologia constructiilor astfel de diagrame.
Baza semantică a modelului ER constă din următoarele ipoteze:
acea parte a lumii reale (un set de obiecte interconectate), informații despre care ar trebui plasate în baza de date, poate fi prezentat ca totalitate entitati;
Fiecare entitate are proprietăți (atribute) caracteristice care o deosebesc de alte entități și îi permit pentru a identifica;
Entitățile pot fi clasificate pe tipuri de entități: fiecare instanță a unei entități (reprezentând un obiect) poate fi clasificată La clasa - tip de entitate, fiecare instanță are proprietăți comune și care le deosebește de entitățile din alte clase;
sistematizarea reprezentării pe bază de clasă presupune în general o dependenţă ierarhică de tipuri: entitatea tip A este subtip esență ÎN, dacă fiecare instanţă de tip A este o instanță a unei entități de tip ÎN;
relaţiile dintre obiecte pot fi reprezentate ca conexiuni - entitati, care servesc la înregistrarea (reprezentarea) interdependenţei a două sau mai multe entităţi.
Aici ar trebui să subliniem încă o dată natura informațională a conceptului esențăși relația acestuia cu obiectele materiale sau imaginare ale domeniului subiectului. Orice obiect din domeniul subiectului are proprietăți, dintre care unele sunt distinse ca caracteristice - semnificative din punctul de vedere al sarcinii aplicate. În acest caz, de exemplu, în procesul de analiză și sistematizare a unui domeniu, clase - o colecție de obiecte care au același set de proprietăți, specificate în formular seturi de atribute(valorile atributelor pentru obiecte din aceeași clasă, desigur, pot diferi). În consecință, la nivelul reprezentării domeniului subiectului (adică, modelul ei infologic), obiectul considerat ca un concept (un obiect în mintea umană) corespunde conceptului. esență; un obiect, ca parte a lumii materiale (și existând independent de conștiința umană), corespunde conceptului instanță de entitate; clasa de obiecte corespunde conceptului tip de entitate.
În cele ce urmează, din moment ce modelul infologic nu ia în considerare instanțe individuale de obiecte, ci clase, nu vom face distincția între conceptele corespunzătoare acestor două niveluri, adică ne vom asuma identitatea conceptelor. un obiectȘi entitate, proprietate a unui obiectȘi proprietatea unei entități.
model ER, ca o descriere a domeniului subiectului, trebuie să definească obiecte și relații între ele, adică să stabilească conexiuni de următoarele două tipuri.
1. Conexiuni între obiecte și seturi de proprietăți caracteristice, și astfel definiți obiectele în sine.
2. Conexiuni între obiecte, definind natura și natura funcțională a interdependenței lor.
După cum sa menționat mai devreme, modelarea ER a unui domeniu se bazează pe utilizarea diagramelor grafice ca modalitate simplă (familiară), vizuală și în același timp informativă și multidimensională de afișare a componentelor proiectului. Prin urmare, prezentarea principalelor prevederi ale modelului ER va fi ilustrată cu material dintr-un exemplu de diagramă ER prezentat în Fig. 5.4.
Esență. Entitatea prin care este modelată o clasă de obiecte similare este definită ca „un obiect care poate fi identificat în mod clar”. Așa cum fiecare obiect este caracterizat în mod unic de un set de valori de proprietate, o entitate trebuie fi determinat ca aceasta un set de atribute, care ar permite să se facă distincția între instanțe individuale ale unei entități. Fiecare instanță a unei entități trebuie să fie distinsă de orice altă instanță a aceleiași entități (această cerință este similară cu cerința că nu există tupluri duplicate în tabelele relaționale). De exemplu, pentru a identifica în mod unic fiecare instanță a entității „Angajat”, este introdus atributul „Număr de personal”, care, datorită naturii sale, va avea întotdeauna o valoare unică în cadrul întreprinderii. Adică, un identificator unic de entitate poate fi un atribut, o combinație de atribute, o combinație de relații sau o combinație de relații și atribute care distinge în mod unic orice instanță a entității de alte instanțe ale aceluiași tip de entitate.
Entitatea are Nume, unic în cadrul modelului. în care numele entitatii - Acest nume de tip,și nu un exemplu anume.
Entitățile sunt împărțite în puternicȘi slab. O entitate este slabă dacă existența ei depinde de o altă entitate care este puternică în raport cu ea. De exemplu, entitatea Subordonată este slabă împotriva La Entitatea „Angajat”: dacă o înregistrare corespunzătoare unui anumit angajat care are subordonați este ștearsă, atunci trebuie șterse și informațiile despre subordonare.
Proprietăți. Natura proprietății, cum natura conexiunii proprietățile cu o entitate (obiect) pot fi diferite. Să ne uităm la principalele tipuri de proprietăți.
Proprietatea poate fi multiplu sau singur - adică un atribut care definește o proprietate poate avea simultan mai multe valori sau, în consecință, doar una. De exemplu, un angajat poate avea mai multe specialități, dar singura valoare este „Număr de personal”.
Proprietatea poate fi simplu(nu fac obiectul unei divizări ulterioare din punct de vedere al sarcinilor aplicate) sau compus - dacă valoarea sa este formată din valori proprietăți simple. De exemplu, proprietatea „Anul nașterii” este simplă, iar proprietatea „Adresa” este complexă, deoarece include valorile proprietăților simple „Oraș”, „Strada”, „Casa”.
În unele cazuri, este util să distingem de bazăȘi derivate proprietăți. De exemplu, un „Furnizor” poate avea o proprietate „Număr total de piese furnizate”, care este calculată prin însumarea numărului de piese pe care le furnizează pentru un proiect.
Dacă prezența unei proprietăți pentru toate instanțele unei entități nu este obligatorie, atunci o astfel de proprietate este numită condiţional. De exemplu, nu toți angajații au proprietatea „diplomă academică”.
Valorile proprietăților pot fi constante - static sau dinamic, adică se schimbă în timp. De exemplu, proprietatea Număr de personal este statică, în timp ce proprietatea Adresă este dinamică. Proprietatea poate fi incert, dacă este dinamic, dar valoarea sa actuală nu a fost încă setată.
Proprietatea poate fi considerată ca cheie, dacă sensul său este unic și, poate într-un anumit context, identifică în mod unic entitatea. De exemplu, un subordonat al unui anumit angajat.
Conexiuni Pe lângă conexiunile dintre un obiect și proprietățile sale, modelul infologic reflectă conexiunile dintre obiecte diferite clase. ÎN conexiune este definită ca „o asociație care reunește mai multe entități”. Această asociere poate exista întotdeauna între diferite entități sau între o entitate și ea însăși (asociere recursiv).
Ca și esența, conexiunea este tipic concept, adică toate instanțele de entități legate sunt supuse regulilor de legare de tip. Diferența fundamentală între tipurile de conexiuni între tipuri și instanțe este ilustrată de diagramele ER pentru tipuri și instanțe prezentate în Fig. 5.5.
Se numesc entitățile unite printr-o relație participanții. Gradul de conectare determinat de numărul de participanți la comunicare.
Dacă fiecare instanță a unei entități participă la cel puțin o instanță a unei relații, atunci o astfel de participare a acelei entități se numește complet(sau obligatoriu); in caz contrar - incomplet(sau opțional).
Este specificată natura cantitativă a participării instanțelor de entitate (una sau mai multe). tip de conexiune(sau putere de comunicare), Posibil următoarele tipuri: "unu la unu"(1:1), "unu la multi"(1M), "multi la unu"(M:1), „mulți la mulți”(MM).
Trebuie remarcat faptul că instrumentul de legătură este un mijloc de reprezentare obiecte complexe, fiecare dintre acestea poate fi considerat ca un ansamblu de oarecum interconectate obiecte simple. Împărțirea în obiecte simple și complexe, precum și natura relației, este condiționată și este determinată de particularitățile analizei domeniului subiectului, adică, în cele din urmă, de natura utilizării acestor obiecte în rezolvare. Probleme. probleme aplicate. Mai mult, din punctul de vedere, de exemplu, al unui designer, un DETALIU este obiect complex, iar din punctul de vedere al furnizorului - simplu.
Dintre numeroasele tipuri de relații, cele mai frecvente sunt astfel de relații tip ierarhic, ca „parte - întreg”, „gen - specie”.
Relația parte-întreg este folosită pentru a reprezenta obiecte compozite. De exemplu, MAȘINI sunt formate din UNITĂȚI, UNITĂȚI sunt formate din PARTE. Relațiile sunt posibile aici "unu la multi" deci si „mulți la mulți”.
Relația „gen – specie” – pentru reprezentare obiecte generalizate. De exemplu, ANGAJAȚII sunt împărțiți pe profesie în DESIGNĂRI, PROGRAMĂTORI, LUCRĂTORI; PROGRAMTORI - în PROGRAMTORI DE APLICAȚII și PROGRAMĂTORI DE SISTEM. Relațiile ierarhice, și în special relațiile „gen-specie”, sunt de obicei folosite ca bază pentru clasificarea obiectelor în funcție de seturi de trăsături caracteristice. Mai mult, obiecte „specie”. moşteni proprietăți de „generic”.
Un alt tip de relație utilizat pe scară largă este agregarea - combinarea obiectelor simple în altele complexe pe baza principiului apartenenței lor. unitate sau participarea lor comună la un proces. Agregarea, considerată aici ca mai mult caz general relații ierarhice, unește obiecte de diferite naturi cu un singur proprietate comună„participare comună”. Obiectele agregate sunt de obicei denumite prin substantive verbale, de exemplu, "Compus": SUBDIVIZIUNE cuprinde ANGAJATII; "Livra": FURNIZOR provizii DETALII.
Supertipuri și subtipuri. O entitate poate fi împărțită în două sau mai multe care se exclud reciproc subtipuri, fiecare dintre acestea include atribute și/sau relații comune. Aceste atribute și/sau relații comune sunt definite în mod explicit o dată nivel inalt. Subtipurile își pot defini propriile atribute și/sau relații. În principiu, subtiparea poate continua pentru mai mult niveluri scăzute, dar în cele mai multe cazuri două sau trei niveluri sunt suficiente.
Se numește entitatea pe baza căreia se determină subtipurile supertip. Subtipurile trebuie să formeze un set complet, adică orice instanță a unui supertip trebuie să aparțină unui subtip. Uneori, pentru a completa setul, este necesar să definiți un subtip suplimentar, de exemplu, ALȚII.
Subtipul moștenește proprietățile și relațiile supertipului. De exemplu, tipul de entitate PROGRAMATOR este un subtip de entitate ANGAJAT. Programatorii au toate proprietățile angajaților și participă la toate comunicările, dar invers nu este adevărat.
Se formează un tip de entitate, subtipurile sale, subtipurile acestor subtipuri etc ierarhia tipurilor de entități, un exemplu din care este prezentat în fig. 5.6.
Modelul a fost propus de Peter Ping-Shen Chen în 1976. Cele mai multe abordări moderne ale proiectării bazelor de date (în principal relaționale) se bazează pe utilizarea variațiilor modelului ER. Modelarea domeniului se bazează pe utilizarea diagramelor grafice care includ un număr mic de componente eterogene. Datorită clarității prezentării diagramelor de baze de date conceptuale, modelele ER au devenit larg răspândite în sistemele CASE care suportă proiectare asistată de calculator baze de date relaționale.
Noțiuni de bază Modelele ER sunt entitate, relație și atribut.
Esență– este un obiect real sau imaginar, informații despre care prezintă interes. În diagramele modelului ER, o entitate este reprezentată ca un dreptunghi care conține numele entității. În acest caz, numele entității este numele tipului și nu un obiect specific - o instanță de acest tip. Fiecare instanță a unei entități trebuie să fie distinsă de orice altă instanță a aceleiași entități.
Conexiune este o asociere reprezentată grafic stabilită între două entități. Această asociere este întotdeauna binară și poate exista între două entități diferite sau între o entitate și ea însăși (relație recursiva). În orice conexiune, sunt identificate două capete (în conformitate cu perechea de entități conectate), fiecare dintre acestea indicând numele sfârșitului conexiunii, gradul de sfârșit al conexiunii (cate instanțe ale acestei entități sunt conectate) , natura obligatorie a conexiunii (adică dacă vreo instanță a acestei entități trebuie să participe la această conexiune).
O conexiune este reprezentată ca o linie care leagă două entități sau care duce de la o entitate la ea însăși. În acest caz, în punctul în care conexiunea cu entitatea „se alătură”, este utilizată o intrare în trei puncte în dreptunghiul entității. Dacă această entitate poate avea mai multe instanțe de entitate în relație, și intrare într-un singur punct dacă o singură instanță de entitate poate participa la relație. Capătul necesar al conexiunii este reprezentat cu o linie continuă, iar capătul opțional cu o linie întreruptă.
La fel ca o entitate, o relație este un concept generic, toate instanțele ambelor perechi de entități înrudite sunt supuse regulilor de asociere.
Orez. 12. Un exemplu de relație între entități
Această diagramă poate fi interpretată astfel: Fiecare STUDENT învață într-un singur GRUP; Orice GRUP este format din unul sau mai mulți STUDENTI. Figura următoare ilustrează entitatea MAN cu o conexiune recursivă care o conectează la sine.
Orez. 13. Exemplu de legături recursive
O interpretare orală laconică a diagramei descrise este următoarea:
Fiecare PERSOANA este fiul unei singure PERSOANE;
Fiecare PERSOANA poate fi tatăl unuia sau mai multor OAMENI („OAMENI”).
Un atribut de entitate este orice detaliu care servește la clarificarea, identificarea, clasificarea, cuantificarea sau exprimarea stării entității. Numele atributelor sunt introduse într-un dreptunghi reprezentând entitatea, sub numele entității și sunt prezentate cu litere mici. De exemplu:
Orez. 14. Imaginea unei entități cu atributele sale
Identificatorul unic al unei entități este un atribut, o combinație de atribute, o combinație de relații sau o combinație de relații și atribute care distinge în mod unic orice instanță a entității de alte instanțe ale aceluiași tip de entitate.
Ca și în schemele de baze de date relaționale, schemele ER introduc conceptul de forme normale, iar semnificația lor se potrivește îndeaproape cu semnificația formelor normale relaționale. Rețineți că formulările formelor normale ale schemelor ER clarifică semnificația schemelor relaționale de normalizare Vom lua în considerare doar definiții foarte scurte și informale ale primelor trei forme normale.
In primul forma normala Schemele ER elimină atributele duplicate sau grupurile de atribute, adică entitățile implicite „deghizate” ca atribute sunt identificate.
În a doua formă normală sunt eliminate atributele care depind doar de o parte a identificatorului unic. Această parte a identificatorului unic identifică o entitate individuală.
În a treia formă normală atribute care depind de atributele care nu sunt incluse în identificator unic. Aceste atribute sunt baza unei singure entități.
Ne-am concentrat doar pe cele mai importante concepte ale modelului de date ER. Elementele mai complexe ale modelului includ următoarele:
Subtipuri și supertipuri entitati. Modelul ER vă permite să specificați relația IS-A între tipuri. Mai mult, dacă T, IS-A T 2 (unde T 1 și T 2 sunt tipuri de entități), atunci T se numește subtip al lui T 2, iar T 2 este un supertip al lui T. Astfel, există posibilitatea de a moșteni un tip de entitate bazat pe unul sau mai multe supertipuri.
Relații de la multe la multe. Uneori este necesar să legați entitățile în așa fel încât să poată exista mai multe instanțe ale entității la ambele capete ale legăturii (de exemplu, toți membrii unei cooperative dețin în comun proprietatea cooperativei). Pentru a face acest lucru, este introdus un tip de relație „mulți-la-mulți”.
Grade de conectare specificate. Uneori este util să se definească numărul posibil de instanțe de entitate care participă la o anumită relație (de exemplu, un angajat are permisiunea de a participa la cel mult trei proiecte simultan). Pentru exprimarea acestei constrângeri semantice este permisă indicarea la sfârşitul conexiunii gradul maxim sau obligatoriu al acesteia.
Ștergeri în cascadă ale instanțelor de entitate. Unele relații sunt atât de puternice (în cazul unei relații unu-la-mulți, desigur) încât atunci când ștergeți instanța entității de referință (corespunzătoare unui capăt al relației), trebuie să ștergeți și toate instanțele de entitate corespunzătoare multe sfârşit ale relaţiei. Cerința corespunzătoare de „ștergere în cascadă” poate fi formulată atunci când se definește o entitate.
Domenii. Ca si in cazul model relațional date, poate fi util să puteți defini un set potențial valid de valori pentru un atribut de entitate (domeniu).
Acestea și alte elemente mai complexe ale modelului de date Entitate-Relație îl fac mai puternic, dar în același timp îl fac ceva mai dificil de utilizat. Desigur, atunci când utilizați diagrame ER pentru proiectarea bazei de date, trebuie să vă familiarizați cu toate posibilitățile.
Înainte de a începe să creați sistemul prelucrare automată informații, dezvoltatorul trebuie să-și formeze concepte despre obiectele, faptele și evenimentele cu care va opera acest sistem. Pentru a aduce aceste concepte la unul sau la altul model de date, este necesar să le înlocuim reprezentări informaţionale. Una dintre cele mai instrumente convenabile reprezentare unificată a datelor, independentă de implementator software, este un model entitate-relație (ER - model).
Modelul entitate-relație se bazează pe unele importante informație semantică O lumea realași este destinat pentru prezentarea logică a datelor. Acesta definește semnificațiile datelor în contextul relațiilor lor cu alte date. Important pentru noi este faptul că de la modelul „entitate-relație” toate modelele existente date (ierarhice, de rețea, relaționale, obiect), deci sunt cele mai generale.
Modelul „entitate-relație” a fost propus în 1976 de Peter Ping-Sheng Chen, traducerea în limba rusă a articolului său „Modelul „entitate-relație” - un pas către o reprezentare unificată a datelor” a fost publicată în revista „DBMS” nr; 3, 1995.
Vizualizări de date pe mai multe niveluri
Când studiați un model de date, ar trebui să identificați nivelurile de reprezentare logică a datelor la care se referă acest model. Prin extinderea setului de prevederi, putem defini patru niveluri de prezentare a datelor:
Informații referitoare la entități și conexiuni care există în imaginația noastră; - structura informațională – organizarea informațiilor în care entitățile și relațiile sunt reprezentate prin date. - structura de date independentă de căile de acces - structuri de date care nu sunt asociate cu schemele de căutare, indexare etc. - structura datelor dependentă de căile de acces.
Figura 1. Analiza modelelor de date folosind mai multe straturi de vederi logice
Informații despre entități și relații
La acest nivel luăm în considerare entitățile și relațiile. O entitate este un obiect care poate fi identificat într-un fel care îl distinge de alte obiecte. Exemple de entitate sunt persoana speciala, companie sau eveniment. O relație este o asociere stabilită între entități. De exemplu, tată-fiu este o legătură între două entități umane.1)
O bază de date a întreprinderii conține informații despre entitățile și relațiile care sunt de interes pentru acea întreprindere. Nu poate fi introdus în baza de date a companiei Descriere completa entități sau conexiuni. Este imposibil (și, aparent, nu este necesar) să salvezi tot potențialul informatii disponibile despre entități și conexiuni. În continuare, vom lua în considerare doar acele entități și relații (și informații despre acestea) care ar trebui incluse în proiectul bazei de date.
Entitate și multe entități
Să desemnăm o entitate care există în imaginația noastră. Fiecare entitate aparține unui set de entități distincte, cum ar fi ANGAJAT, PROIECT sau DEPARTAMENT. Fiecare set de entități este asociat cu un predicat care vă permite să verificați dacă o anumită entitate îi aparține acest set. De exemplu, dacă știm că o entitate aparține setului de entități ANGAJAT, atunci știm și că această entitate are proprietăți comune cu alte entități din setul de entități ANGAJAT. Aceste proprietăți includ predicatul menționat mai sus. Fie Ei să desemneze setul de entități. Rețineți că seturile de entități nu trebuie să fie disjunctive. De exemplu, o entitate care aparține setului de entități BĂRBAȚI-PERSOANĂ aparține și setului de entități PERSONA. În acest caz, PERSOANĂ BĂRBAȚĂ este un subset al PERSOANĂ.
Conexiune, rol și multe legături.
Să luăm în considerare asociațiile de entități. O mulțime de relații Ri este o relație matematică între n entități, fiecare dintre ele aparținând unui anumit set de entități:
( | e1 ∈ E1, e2 ∈ E2, ..., en ∈ En), iar fiecare tuplu de entități, , este o relație. Rețineți că în această definiție, Ei nu trebuie să fie mulțimi distincte. De exemplu, căsătoria este o relație între două entități din setul de entități PERSONA.
Rolul unei entități într-o relație este funcția pe care o îndeplinește entitatea într-o relație dată. Soțul (soțul) și soția (soția) sunt roluri. Ordonarea entităților în definiția unei relații (rețineți că am folosit paranteza patrata) pot lipsi dacă rolurile entităților sunt indicate în mod explicit în legătură: (r1/e1, r2/e2 ,..., rn/en), unde ri este rolul entității ei în această legătură.
Atribut, valoare și set de valori.
Informațiile despre o entitate sau o relație sunt obținute prin observare sau măsurare și sunt exprimate ca un set de perechi atribut-valoare. 3, roșu, Peter și Johnson sunt valorile. Valorile sunt clasificate în diferite seturi de valori, cum ar fi PICIOARE, CULOARE, PRENUME și NUME. Fiecare set de valori are asociat un predicat pentru a testa dacă valoarea aparține acelui set. O valoare dintr-un set de valori poate fi echivalentă cu o altă valoare dintr-un alt set de valori. De exemplu, 12 în setul de valori INCH este echivalent cu 1 în setul de valori FEET.
Un atribut poate fi definit formal ca o funcție care mapează un set de entități sau un set de relații într-un set de valori sau un produs cartezian de seturi de valori:
f: Ei sau Ri → Vi sau Vi1 × Vi2 × ... × Vin În fig. Figura 2 prezintă câteva atribute definite pe setul de entități PERSONA. Atributul AGE se asociază cu setul de valori NO-OF-YEARS. Atributul poate specifica maparea seturilor de valori într-un produs cartezian. De exemplu, atributul NUME specifică afișarea valorilor FIRST-NAME și LAST-NAME în set. Rețineți că mai multe atribute pot mapa același set de entități la același set de valori (sau același grup de seturi de valori). De exemplu, Atributele NAME(NUME COMPLET) și NUME ALTERNATIVE specifică o mapare de la setul de entități ANGAJAT la seturile de valori FIRST-NUME și LAST-NAME. Astfel, un atribut și un set de valori sunt concepte diferite, deși în unele cazuri pot avea același nume (de exemplu, atributul EMPLOYEE-NU specifică o mapare de la EMPLOYEE la un set de valori EMPLOYEE-NO - EMPLOYEE)). Această diferență nu este clară în model de rețea iar în multe sistemele existente management de date. Rețineți, de asemenea, că atributul este definit ca o funcție. Prin urmare, se afișează această entitateîntr-o singură valoare (sau un tuplu de valori în cazul unui produs cartezian de mulțimi de valori).
Orez. 2. Atribute definite pe setul de entități PERSONA
Rețineți că conexiunile au și atribute. Să luăm în considerare setul de conexiuni PROIECT-WORKER (Fig. 3). Atributul PERCENTAGE-OF-TIME, care reprezintă proporția de timp alocată unui anumit angajat într-un anumit proiect, este un atribut definit în setul de relații PROIECT-LUCRĂTOR. Nu este nici un atribut al entității ANGAJAT și nici un atribut al entității PROIECT, întrucât semnificația acestuia depinde atât de angajat, cât și de proiect. Conceptul de atribut de relație este important pentru înțelegerea semanticii și definirea datelor dependențe funcționaleîntre date.
Orez. 3. Atribute definite pe setul de conexiuni PROJECT-WORKER
Structura conceptuală a informațiilor.
Vom discuta acum despre cum pot fi organizate informațiile despre entități și relații. Această lucrare propune o metodă de separare a informațiilor despre entitate și informații despre relații. Vom arăta că această separare este utilă pentru identificarea dependențelor funcționale dintre date.
În fig. 4 prezintă informații despre entitățile din setul entității sub formă de tabel. Fiecare rând de valori se referă la aceeași entitate, iar fiecare coloană se referă la un set de valori, care la rândul său se referă la un atribut. Ordinea rândurilor și coloanelor nu este semnificativă.
Orez. 4. Informații despre entități dintr-un set de entități (forma tabelară)
Orez. 5. Informații despre conexiuni dintr-un set de conexiuni (forma tabelară)
În fig. 5 prezintă informații despre conexiunile din setul de conexiuni. Rețineți că fiecare rând de valori se referă la o relație care este indicată de un grup de entități, fiecare dintre ele având un rol specific și aparținând unui anumit set de entități.
Rețineți că în fig. Figurile 4 și 2 (și, de asemenea, figurile 5 și 3) prezintă forme diferite ale aceleiași informații. Formularul de tabel este folosit pentru a facilita conectarea la modelul relațional.
Structura informației
Entitățile, relațiile și semnificațiile de la Nivelul 1 (vezi Figura 2-5) sunt obiecte conceptuale care există în imaginația noastră (adică, ne aflam în domeniul conceptual). La nivelul 2 avem în vedere reprezentări ale obiectelor conceptuale. Presupunem că există reprezentări directe ale sensului. În continuare, descriem cum pot fi reprezentate entitățile și relațiile.
Cheia principala.
În fig. 2 Valorile atributelor ANGAJAT-NU pot fi folosite pentru a identifica entitățile din setul de entități ANGAJAT dacă fiecare angajat are un număr unic de angajat. Este posibil să aveți nevoie de mai mult de un atribut pentru a identifica entitățile dintr-un set de entități. De asemenea, este posibil ca mai multe grupuri de atribute să fie utilizate pentru a identifica entitățile. În esență, o cheie de entitate este un grup de atribute astfel încât maparea de la un set de entități la un grup corespunzător de seturi de valori este o mapare unu-la-unu. Dacă o astfel de mapare nu poate fi găsită în datele disponibile sau dacă se dorește ușurința identificării obiectelor, atunci un set de atribute și valori pot fi definite artificial pentru a realiza o mapare unu-la-unu. În cazul existenței mai multor chei, acesta este de obicei selectat semantic cheie semnificativă la fel de cheia principala entități (cheie primară de entitate - PK).
Orez. 6. Reprezentarea entităților după valori (numerele de angajați)
Orez. 6 a fost obținută prin comasarea setului de entități ANGAJAT cu setul de valori ANGAJAT-NU din Fig. 2. Să fim atenți la unele consecințe semantice ale Fig. 6. Fiecare valoare din setul de valori ANGAJAT-NU reprezintă o entitate (angajat). Atributele specifică maparea de la setul de valori EMPLOYEE-NO la alte seturi de valori. De asemenea, rețineți că atributul EMPLOYEE-NO specifică maparea unui set de valori EMPLOYEE-NO în sine.
Relații entitate/relație.
Informațiile despre entitățile din setul de entități pot fi acum organizate în forma prezentată în figură. 7. Rețineți că fig. 7 este similară cu Fig. 4, cu excepția faptului că entitățile sunt reprezentate de valorile cheilor lor primare. Întregul tabel este în Fig. 7 reprezintă o relație de entitate, iar fiecare rând reprezintă un tuplu de entitate.
În unele cazuri, entitățile dintr-un set de entități nu pot fi identificate în mod unic prin propriile valori ale atributelor; prin urmare, trebuie să folosim relația(e) pentru a le identifica. De exemplu, luați în considerare entitățile dependente și susținătoare: subordonații sunt identificați după numele lor și valorile cheie primare ale superiorilor lor (adică, prin relațiile lor cu acei angajați). Rețineți că în fig. 9 ANGAJAT-NU nu este un atribut al entităților din setul DEPENDENT, ci reprezintă cheia primară a angajaților care au subordonați. Fiecare linie de valori din Fig. 9 este un tuplu de entități cu EMPLOYEE-NO și NAME ca chei primare. Întregul tabel este o relație de entitate.
În teorie, orice tip de relație poate fi folosit pentru a identifica entități. Pentru simplitate, ne vom limita la un singur tip de relație: relații binare cu o mapare 1:n, în care existența a n entități pe o parte a relației depinde de existența unei entități pe cealaltă parte a relației. . De exemplu, un angajat poate avea n (n = 0, 1, 2,...) subordonați, iar existența subordonaților depinde de existența angajatului superior corespunzător.
Această metodă de identificare a entităților prin relații cu alte entități poate fi aplicată recursiv până când sunt întâlnite entități care pot fi identificate prin valorile propriilor atribute. De exemplu, cheia primară a departamentului unei companii poate consta din numărul departamentului și cheia primară a departamentului, care la rândul său constă din numărul departamentului și numele companiei.
În consecință, avem două forme de relații între entități. Dacă relațiile sunt folosite pentru a identifica entitățile, vom numi aceasta o relație slabă de entitate (Figura 9). Dacă relațiile nu sunt folosite pentru a identifica entitățile, o vom numi o relație obișnuită de entitate (Figura 8). Dacă unele entități dintr-o relație sunt identificate de alte relații, vom numi aceasta o relație de relație slabă. De exemplu, orice relații dintre entitățile DEPENDENTE și alte entități vor avea ca rezultat relații de asociere slabe, deoarece entitatea DEPENDENTĂ este identificată prin numele și relația sa cu entitatea ANGAJAT. Distingerea dintre relațiile și relațiile cu entitate obișnuite și slabe va fi utilă în menținerea integrității datelor.
