Modelul „Entitate-relație. Model de bază de date conceptuală - Diagrama relației obiect

Ca orice model, modelul entitate-relație are mai multe Noțiuni de bază, care formează cărămizile inițiale din care se construiesc mai multe obiecte complexe după reguli prestabilite.

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ăruia se modelează o clasă de obiecte asemănătoare. 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ărul 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 care numele entității este scris în partea de sus, iar atributele sunt enumerate mai jos, cu atributele cheie marcate, de exemplu, cu un caracter de subliniere sau 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 ea 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 descrisă prin împărțirea legăturii la 3. Legătura are un nume comun de „Discipline Design” și are nume de rol pe partea ambelor entități. Din partea elevului, acest rol se numește „Scrie o teză sub îndrumare”, din partea profesorului, această conexiune se numește „Îndrumător”. O interpretare grafică a unei relații vă permite să citiți imediat sensul relației dintre entități, este vizuală ș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 partea stângă a unei relații poate fi asociată cu mai multe instanțe ale unei entități situate în partea dreaptă a unei relații. 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ă ce profesori ascultă prelegeri. acest elevși cărora studenții le dă curs acest profesor. 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ă. Iar perpendiculara este interpretată ca ce macar o instanță a entității participă la această relație.

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 teză trebuie să aibă propriul director de proiect de teză, dar, pe de altă parte, nu fiecare profesor ar trebui să conducă proiectul de teză. Prin urmare, în această formulare 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 la nivelul 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 dactilizării unei entități se introduce un element grafic special, 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 o sarcină analitică care este efectuată folosind applet-uri Java pre-scrise, fie un test într-o anumită zonă de cunoaștere, constând dintr-un set de întrebări și un set de răspunsuri propuse pentru fiecare întrebare.

Ca urmare a construirii modelului domeniul subiectului sub forma unui set de entităţi şi conexiuni 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-mai multe (1:M) între entitățile „Cărți” și „Instanțe”, care este necesară de ambele părți. Ce determină acest tip de conexiune? 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” atribut 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, în directorul de sistem Nu ar trebui să existe un astfel de domeniu de cunoaștere, informații despre care să nu fie 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ă.

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 servește ca modele infologice„entitate-relație” (ER - diagramă).

Cel mai adesea, formalizarea ideilor despre domeniul subiectului se realizează în cadrul modelului „entitate-relație” („obiecte-relații”). 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. În cadrul acestui proiect de curs, entitățile sunt: angajat, 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ță a unui obiect este caracterizată de un set de valori specifice de atribut de acest tip 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 crește claritatea și ușurința de proiectare, sunt utilizate mijloace grafice de reprezentare a entității, instanțe ale entității și relațiile dintre ele. 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-urile relaționale, pentru a indica relațiile de tabel, se efectuează o operație de legătură. 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.

Următoarele pot fi instalate între mese:

conexiuni binare;

Conexiuni ternare;

Legături N-are.

Când se leagă două tabele, se disting un tabel primar și unul 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âmpurile de legătură ale unui tabel suplimentar sunt cel mai adesea 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âmpurile cheie ale celor două tabele nu se repetă, există o corespondență unu-la-unu între înregistrările 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 relațiilor”.

Î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”

Noțiuni de bază

Scopul modelării informațiilor este de a oferi oamenilor cele mai naturale modalități de a colecta și prezenta informațiile care ar trebui să fie stocate în baza de date creată. Prin urmare, ei încearcă să construiască un model de date infologice prin analogie cu limbajul natural (cel din urmă nu poate fi utilizat în formă pură datorită complexităţii procesării textului pe calculator şi ambiguităţii oricărui limbaj natural). Principalele elemente constructive ale modelelor informaționale sunt entitățile, conexiunile dintre acestea și proprietățile (atributele) acestora.

Esență– orice obiect distins (un obiect pe care îl putem distinge de altul), informații despre care trebuie stocate într-o bază de date. Entitățile pot fi persoane, locuri, avioane, zboruri, gust, culoare etc. Este necesar să se facă distincția între concepte precum tip de entitateȘi instanță de entitate. Conceptul de tip de entitate se referă la un set de indivizi omogene, obiecte, evenimente sau idei care acționează ca un întreg. O instanță de entitate se referă la un anumit lucru dintr-un set. De exemplu, tipul de entitate poate fi CITY, iar instanța poate fi Moscova, Kiev etc.

Atribut– o caracteristică numită a unei entități. Numele său trebuie să fie unic pentru tip specific esență, dar poate fi același pentru tipuri variate entități (de exemplu, CULOARE poate fi definită pentru multe entități: CÂINE, MAȘINĂ, FUM etc.). Atributele sunt folosite pentru a defini ce informații trebuie colectate despre o entitate. Exemple de atribute pentru entitatea CAR sunt TYPE, MAKE, LICENCE PLATE, CULOARE etc. Și aici există o distincție între tip și instanță. Tipul de atribut COLOR are multe instanțe sau valori:

Roșu, Albastru, Banană, Noapte Albă etc.,

Cu toate acestea, fiecărei instanțe de entitate i se atribuie o singură valoare de atribut.

Nu există nicio diferență absolută între tipurile de entități și atribute. Un atribut este astfel numai în raport cu tipul de entitate. Într-un alt context, un atribut poate acționa ca o entitate independentă. De exemplu, pentru o fabrică de mașini, culoarea este doar un atribut al produsului de producție, dar pentru o fabrică de vopsele și lacuri, culoarea este un tip de entitate.

Cheie – set minim atribute ale căror valori pot fi folosite pentru a găsi în mod unic instanța necesară a unei entități. Minimitatea înseamnă că excluderea oricărui atribut din set nu permite identificarea entității de către cele rămase. Pentru entitatea Schedule (clauza 1.2), cheia este atributul Flight_number sau setul de: Departure_point, Departure_time și Destination_point (cu condiția ca un avion să zboare dintr-un punct în altul de fiecare dată).

Conexiune– asocierea a două sau mai multe entități. Dacă scopul bazei de date era doar acela de a stoca date individuale, fără legătură, atunci structura acesteia ar putea fi foarte simplă. Cu toate acestea, una dintre principalele cerințe pentru organizarea unei baze de date este asigurarea capacității de a găsi unele entități prin valorile altora, pentru care este necesar să se stabilească anumite conexiuni între ele. Și deoarece bazele de date reale conțin adesea sute sau chiar mii de entități, teoretic se pot stabili mai mult de un milion de conexiuni între ele. Prezența unei asemenea multitudini de conexiuni determină complexitatea modelelor informaționale.

Caracteristicile conexiunilor și limbajul de modelare

Când construiți modele de informații, puteți utiliza limbajul Diagramele ER(din engleza Entity-Relationship, adică entity-relationship). În ele, entitățile sunt descrise ca dreptunghiuri marcate, asocierile ca diamante marcate sau hexagoane, atributele ca ovale marcate și conexiunile dintre ele ca margini nedirecționale, deasupra cărora gradul de conexiune (1 sau o literă care înlocuiește cuvântul „multe”). iar explicaţia necesară poate fi indicată.

Între două entități, de exemplu, A și B, sunt posibile patru tipuri de conexiuni.

Primul tip– Relație ONE-TO-ONE (1:1): la fiecare moment de timp, fiecărui reprezentant (instanță) al entității A îi corespunde 1 sau 0 reprezentanți ai entității B:

Un student nu poate „câștiga” o bursă, să nu primească o bursă obișnuită sau să primească una dintre bursele îmbunătățite.

Al doilea tip– Relația ONE-TO-MANY (1:M): un reprezentant al entității A corespunde cu 0, 1 sau mai mulți reprezentanți ai entității B.

Apartamentul poate fi gol, unul sau mai mulți rezidenți pot locui în el.

Deoarece sunt posibile conexiuni în ambele direcții între două entități, există încă două tipuri de relații: MULTE-LA-UNUL (M:1) și MULTE-LA-MULTE (M:N).

Exemplul 2.1. Dacă legătura dintre entitățile BĂRBAT și FEMEIE se numește CĂSĂTORIE, atunci există patru reprezentări posibile ale unei astfel de conexiuni:

Natura legăturilor dintre entități nu se limitează la cele enumerate. Există, de asemenea, conexiuni mai complexe:

multe legături între aceleași entități

(un pacient, având un singur medic curant, poate avea și mai mulți medici consultanți; un medic poate fi medicul curant al mai multor pacienți și poate consulta simultan mai mulți alți pacienți);

conexiuni de antrenament

(un medic poate comanda mai mult de un pacient pentru mai mult de un test, un test poate fi comandat de mai mult de un medic pentru mai mult de un pacient, iar un pacient poate fi comandat pentru mai mult de un test de mai mult de un medic);

conexiuni de ordine superioare, a căror semantică (sens) este uneori foarte complexă.

În exemplele date, pentru a îmbunătăți caracterul ilustrativ al relațiilor luate în considerare, atributele entităților și asociațiilor din toate diagramele ER nu sunt afișate. Astfel, introducerea doar a câtorva atribute de bază în descrierea legăturilor de căsătorie va complica semnificativ diagrama ER (Fig. 2.1a). În acest sens, limbajul diagramelor ER este folosit pentru a construi modele mici și pentru a ilustra fragmente individuale ale celor mari. Mai puțin vizual, dar mai semnificativ, este folosit mai des. limbaj de modelare a informaţiei(YIM), în care entitățile și asociațiile sunt reprezentate prin propoziții de forma:

ENTITATE (atribut 1, atribut 2, ..., atribut n) ASOCIAȚIE [ENTITATE S1, ENTITATE S2, ...] (atribut 1, atribut 2, ..., atribut n)

unde S este gradul de conectare, iar atributele incluse în cheie trebuie marcate cu un caracter de subliniere.

Astfel, exemplul de mai sus al unui set de conexiuni între entități poate fi descris în NAM după cum urmează:

Doctor ( Doctor_number, Nume, Prenume, Patronimic, Specialitate)Pacient ( Număr de înregistrare, Număr de pat, Nume de familie, Prenume, Patronimic, Adresă, Data nașterii, Sex) Medicul curant [Doctor 1, Pacient M] ( Doctor_number , Număr de înregistrare)Consultant [Doctor M,Pacient N] ( Doctor_number , Număr de înregistrare).

Orez. 2.1. Exemple de diagrame ER

Pentru a identifica relațiile dintre entități, este necesar, cel puțin, definirea entităților în sine. Dar aceasta nu este o sarcină simplă, deoarece în diferite domenii, același obiect poate fi o entitate, un atribut sau o asociere. Să ilustrăm această afirmație cu exemple legate de descrierea legăturilor conjugale (vezi exemplul 2.1).

Exemplul 2.2. Departamentul de înregistrare stare civila(Oficiul Înregistrării) nu se ocupă de toate persoanele, ci doar de cei care au solicitat înregistrarea căsătoriei, nașterii sau decesului. Prin urmare, în țările în care sunt permise numai căsătoriile tradiționale, oficiile de stare civilă pot publica informații despre căsătoriile înregistrate într-o singură entitate:

Căsătoria ( Numarul certificatului, Numele soțului, Prenumele soțului, Patronimul soțului, Data nașterii soțului, Numele soției, ... , Data înregistrării, Locul înregistrării, ...),

Diagrama ER a cărei diagramă este prezentată în Fig. 2.1, b.

Exemplul 2.3. Acum luați în considerare o situație în care oficiul de stare civilă este situat într-o țară care permite poligamia. Dacă utilizați entitatea „Căsătorie” din exemplul 2.2 pentru a înregistra căsătoriile, atunci informațiile despre soții care au mai multe soții vor fi duplicate (vezi Tabelul 2.1).

Tabelul 2.1

Dublarea poate fi eliminată prin crearea unei entități suplimentare „Soți”

Soții ( Cod_M, Nume, Prenume, Patronimic, Data nașterii, Locul nașterii)

și înlocuirea entității „Căsătorie” cu o caracteristică (a se vedea clauza 2.3) cu referire la descrierea corespunzătoare din entitatea „Soți”.

Căsătoria ( Numarul certificatului , Cod_M, Numele soției, ..., Data înregistrării, ... (Soți).

Diagrama ER a conexiunii dintre aceste entități este prezentată în Fig. 2.1,c și un exemplu de copii ale acestora este în tabel. 2.2 și 2.3.

Tabelul 2.2

domeniul subiectuluiși sarcini de rezolvat. Deci, în model relațional date, pe care le vom studia în „Modelul de date relaționale”, este imposibil să stabilim constrângeri de integritate declarativă, altele decât primare, unice și chei externe. Descrierea restricțiilor procedurale se află în general în afara acestui model.

Modelul entitate-relație (diagrame ER, model ER) discutat mai jos este caz special modele de date bogate semantic. Vă permite să descrieți semantica destinată uzului uman. Adică, puteți introduce descrieri care nu sunt implementate în software. Pe de altă parte, înregistrează metadatele și constrângerile de integritate utilizate pentru a crea scripturi care generează schema bazei de date.

2.1 Modele semantice și aspect cognitiv

2.1.1 Modele de date semantice

Ce stochează bazele de date? Desigur, date. Cu toate acestea, chiar și pentru a organiza stocarea datelor, trebuie să țineți cont de semnificațiile asociate acestora. Astfel, în secțiunea anterioară a fost descris cheia principala, care previne intrările duplicate într-un set. Această proprietate definește semnificația privată a unui set de înregistrări cu o cheie primară. Tipurile de date, domeniile, metadatele definesc alte semnificații ale datelor stocate.

Dar dacă numai datele sunt stocate în baza de date, atunci cum sunt stocate semnificațiile? În primul rând, semnificațiile sunt și date asociate cu datele a căror semnificație reprezintă.

Să evidențiem următoarele tipuri de semnificații:

Semnificații destinate numai oamenilor. Poate fi depozitat în sisteme de informare ah (IS), dar pasiv, adică inaccesibil pentru sistem și, prin urmare, nu afectează comportamentul acestuia. Poate fi recuperat doar de oameni
Înțelesuri interne IS. Sunt activi, adică schimbă sau creează un comportament nou al SI. Exemple tipice: chei, tipuri de date, metadate.
Semnificații externe asociate cu sisteme sau sarcini externe IS sau, mai restrâns, bazei de date. Aceste semnificații sunt și ele active.

Cum se manifestă activitatea semnificațiilor interne? Să existe o cheie primară. Vrei să scrii o înregistrare într-un set. Cu toate acestea, DBMS va face mai întâi ceea ce nu ați cerut - va verifica validitatea valorii cheii introduse - și numai dacă această valoare lipsește va scrie o înregistrare.

Un exemplu de al treilea tip de semnificație: Există un tabel care conține notele tuturor elevilor la toate disciplinele. Este posibil să se calculeze scorul mediu? Cu siguranță. Cu toate acestea, dacă sunteți familiarizat cu scalele de măsurare, atunci știți că performanța este măsurată pe o scară de comandă. În ea, scorul mediu nu are nicio semnificație, sau, mai bine zis limba oficiala, este o statistică inadecvată.

Pe stadiul inițial creând o aplicație (analiza de afaceri), este necesar să existe un model de domeniu care să ofere o descriere informală a tuturor caracteristici semnificative sarcini cunoscute de director. În același timp, eliminarea detaliilor care nu se încadrează în modelele de date utilizate în etapa de implementare a proiectului poate duce la o denaturare semnificativă a enunțului problemei. În faza de analiză, caracterul complet al informațiilor ar trebui să fie preferată posibilității descrierii lor oficiale.

Modelele semantice sunt denumite în mod obișnuit modele care oferă o reprezentare a semanticii datelor. Ca și alte modele, acestea pot include părți structurale, manipulative și holistice. Cu toate acestea, având în vedere că există un fel de semantică în orice model, acele modele care conțin mai multă semantică pot fi considerate semantice decât modelele „non-semantice” care conțin puțină semantică. Această pseudo-definiție este foarte vagă. Dar deocamdată este suficient pentru noi.

În cadrul modelului semantic se creează o schemă conceptuală a bazei de date, care este de obicei convertită manual sau automat (dar nu automat) într-o schemă de bază de date valabilă în cadrul modelelor de date implementate în etapele următoare. ciclu de viață proiect - proiectare, dezvoltare si suport.

Semantica datelor va fi discutată în detaliu în prelegerea „Semantica bazei de date” a manualului.

Cel mai faimos model semantic„entitate-relație” (ER) a fost propusă de Peter Chen în 1976.

2.1.2 Aspectul cognitiv

Modelele semantice sunt implementate sub formă de diagrame care pot fi citite de om. ÎN stiinta modernaîn general și în informatică în special, se acordă o atenție deosebită și meritată aspectelor cognitive. În contextul bazelor de date, aceasta înseamnă identificarea celor doi actori principali - oameni și programe - și dezvoltarea unor modele, limbaje, interfețe și algoritmi naturale, prietenoase cu oamenii, pentru experiența utilizatorului. Desigur, este necesar să se țină cont de pregătirea profesională preliminară a utilizatorului, care determină, alături de cunoștințele de zi cu zi, lumea mentală a unei persoane, setul de imagini (gestalturi) cu care operează. De ce ne așteptăm la un meniu principal în partea de sus a ferestrei? Doar pentru că dezvoltatorii unora de succes produse software.

2.1.3 Niveluri de model

În urma lucrării fundamentale a lui Peter Chen privind diagramele entitate-relație, distingem patru niveluri de reprezentare a modelului de date cu definiții ușor modificate:

Informații despre obiecte și relații ale domeniului (software), prezentate în termeni software (model conceptual).
Informații structurate despre software, prezentate în termeni de sisteme informaționale (model logic).
Structuri de date care sunt independente de metoda de acces, adică nu sunt legate de structurile de date, căutare, indexare etc. (model fizic).
Structuri de date în funcție de metoda de acces (model la nivel hardware).

Privind în perspectivă, observăm că modelul relațional se referă la nivelurile 2 și 3. Modelele de rețea și ierarhice, așa cum existau acum 20 de ani, funcționează în principal la nivelurile 3 și 4. UML este nivelurile 1, 2 și 3, dar UML merge departe. dincolo de descrierea datelor. Modelul entitate-relație funcționează la nivelurile 1 și 2.

Scopul modelului.

Hashing.

Această metodă este utilizată atunci când întregul set de chei este cunoscut în prealabil și poate fi introdus memorie cu acces aleator. În acest caz, este construit functie speciala, care mapează în mod unic un set de chei la un set de pointeri, numită funcție hash (de la cuvânt englezesc„a hașa” - tăia, măcina). Având o astfel de funcție, puteți calcula adresa unei înregistrări dintr-un fișier folosind o anumită cheie de căutare. În general, datele cheie utilizate pentru a determina adresa unei înregistrări sunt organizate într-un tabel numit tabel hash.

Dacă setul de chei este necunoscut în avans sau este foarte mare, atunci ideea de a calcula în mod unic adresa unei înregistrări din cheia sa este abandonată, iar funcția hash este considerată pur și simplu ca o funcție care dispersează setul de chei în un set de adrese.

2.1.Reprezentarea datelor folosind modelul „entitate-relație”.

Înainte de a începe crearea unui sistem automat de procesare a informațiilor, 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ă despre lumea reală și este destinată logic prezentarea datelor. Acesta definește semnificațiile datelor în contextul relațiilor lor cu alte date. Important pentru noi este faptul că din modele entitate-relaţie pot fi generate toate cele existente modele de date(ierarhic, de rețea, relațional, obiect), prin urmare este cel mai general.

Rețineți că modelul entitate-relație nu este un model de date în sensul definit în paragraful 1.1.2, deoarece nu definește operațiuni pe date și se limitează la descrierea doar a structurii sale logice.

Modelul entitate-relație a fost propus în 1976 de Peter Ping-Sheng Chen.

Orice fragment din domeniul subiectului poate fi reprezentat ca set de entitati, între care există unele multe conexiuni. Să dăm definiții:

Esență O entitate este un obiect care poate fi identificat într-un fel care îl distinge de alte obiecte. Exemple: persoana speciala, întreprindere, eveniment etc.

Set de entitati(set de entități) - un set de entități de același tip (având aceleași proprietăți). Exemple: toți oamenii, afacerile, vacanțele etc. Seturile de entități nu trebuie să fie disjunctive. De exemplu, o entitate care aparține setului MAN aparține și setului OAMENI.

Esența, de fapt, pare a fi o multitudine atribute, care descriu proprietățile tuturor membrilor acest set entitati.

În viitor, pentru a defini o entitate și atributele acesteia, vom folosi o notație a formei

ANGAJAT (NUMĂR_PERSONAL, NUME, VÂRĂ).

De exemplu, departamentele în care este împărțită întreprinderea și în care lucrează angajații pot fi descrise ca DEPARTAMENT (NUMĂR_DEPARTAMENT, NUME).

Setul de valori (domeniul) al unui atribut este numit domeniu. De exemplu, pentru atributul AGE, domeniul (să-l numim NUMBER_YEARS) este specificat de intervalul de numere întregi mai mari decât zero, deoarece nu există persoane cu o vârstă negativă.

În articolul menționat de P. Chen, atributul este definit ca o funcție care mapează un set de entități la un set de valori sau la un produs cartezian de seturi de valori. Deci, atributul AGE se mapează la setul de valori (domeniu) NUMBER_YEARS. Atributul NUME mapează seturile de valori PRENUME, NUME și PATRONIC într-un produs cartezian.

De aici este determinat cheie de entitate- 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. Cu alte cuvinte: o cheie de entitate este unul sau mai multe atribute care definesc în mod unic această entitate. În exemplul nostru, cheia entității ANGAJAT este atributul PERSONNEL_NUMBER (desigur, numai dacă toate numerele de personal din întreprindere sunt unice).

Conexiune(relația) este o asociere stabilită între mai multe entități. Exemple:

întrucât fiecare angajat lucrează într-un anumit departament, există o relație „lucrează în” sau DEPARTAMENT-ANGAJAT între entitățile ANGAJAT și DEPARTAMENT;
întrucât unul dintre angajații departamentului este șef al acesteia, atunci între entitățile ANGAJAT și DEPARTAMENT există o legătură „manager” sau DEPARTAMENT-ȘEF;
Pot exista si conexiuni intre entitati de acelasi tip, de exemplu o conexiune PARENT - DESCENDANT intre doua entitati PERSONA;

Din păcate, nu există reguli generale determinarea a ceea ce este considerat o entitate și ce este o conexiune. În exemplul discutat mai sus, am presupus că „conducerea” este o conexiune. Totuși, putem considera entitatea „manager”, care are legături „gestionează” cu entitatea „departament” și „este” cu entitatea „angajat”.

O relație poate avea și atribute. De exemplu, pentru relația DEPARTAMENT-ANGAJAT, puteți seta atributul WORK_TERRENCE_IN_DEPARTMENT.

Rolul entității în relație- funcția pe care o îndeplinește o entitate într-o conexiune dată. De exemplu, într-o relație PARENT-COPIL, entitățile PERSONA pot avea rolurile „părinte” și „copil”. Specificarea rolurilor în modelul entitate-relație este opțională și servește la clarificarea semanticii relației.

Set de conexiuni(mult de relații) este relația dintre n(și n nu mai puțin de 2) entități, fiecare aparținând unui anumit set de entități.

Când n=2, adică când o relație combină două entități, se numește binară. S-a dovedit că n-un set de conexiuni ( n>2) pot fi întotdeauna înlocuite cu multe binare, dar primele reflectă mai bine semantica materiei.

Se numește numărul de entități care pot fi asociate printr-un set de conexiuni cu o altă entitate gradul de conexiune. Luarea în considerare a grade este utilă în special pentru relațiile binare. Pot exista următoarele grade de legături binare:

unu la unu (notat 1: 1 ). Aceasta înseamnă că într-o astfel de relație, entitățile cu un rol corespund întotdeauna cel mult unei entități cu alt rol. În exemplul pe care l-am analizat, aceasta este relația „liderilor”, deoarece fiecare departament poate avea un singur supervizor, iar un angajat poate gestiona doar un departament. Acest lucru este prezentată în figura următoare, unde dreptunghiurile reprezintă entitățile, iar diamantul reprezintă relația. Deoarece gradul de conectare pentru fiecare entitate este 1, acestea sunt conectate printr-o linie.

O alta caracteristică importantă legătura pe lângă gradul său este clasa de membru entități incluse în acesta sau cardinalitatea comunicatii. Deoarece fiecare departament trebuie să aibă un manager, fiecare entitate „DEPARTAMENT” trebuie să aibă neapărat o entitate „ANGAJAT” corespunzătoare. Totuși, nu fiecare angajat este șeful unui departament, prin urmare, în acest sens, nu fiecare entitate „ANGAJAT” are asociată o entitate „DEPARTAMENT”.

Astfel, se spune că entitatea „ANGAJAT” are clasa de membru obligatorie(acest fapt este indicat și prin indicarea intervalului numărului de posibile apariții ale entității într-o relație, în acest caz este 1,1), iar entitatea „DEPARTAMENT” are clasă de membru opțională(0,1). Acum această legăturăîl putem descrie ca 0,1:1,1 . În cele ce urmează, vom desemna cardinalitatea conexiunilor binare de gradul 1 după cum urmează:

unu la multi ( 1:n). În acest caz, o entitate cu un rol poate corespunde oricărui număr de entități cu alt rol. Aceasta este relația DEPARTAMENT-ANGAJAT. Fiecare departament poate avea orice număr de angajați, dar un angajat poate lucra doar într-un singur departament. Grafic gradul de conexiune n este afișat ca o linie „arborele”, așa cum se face în figura următoare.

Această figură ilustrează în continuare faptul că mai multe seturi de relații pot fi definite între două entități.

Aici este necesar să se țină cont și de clasa de membru al entităților. Fiecare angajat trebuie să lucreze într-un anumit departament, dar nu fiecare departament (de exemplu, unul nou format) trebuie să includă cel puțin un angajat. Prin urmare, entitatea „DEPARTAMENT” are o clasă obligatorie, iar entitatea „ANGAJAT” are o clasă de membru opțională. Cardinalitatea relațiilor de grade binare n o vom nota astfel:

multi la unu ( n: 1). Această relație este similară cu cartografierea 1:n. Să presupunem că întreprinderea pe care o avem în vedere își bazează activitățile pe baza unor contracte încheiate cu clienții. Acest fapt se reflectă în modelul entitate-relație folosind conexiunea CONTRACT-CLIENT, care combină entitățile CONTRACT(NUMBER, DUE_DATE, AMOUNT) și CUSTOMER(NAME, ADDRESS). Întrucât cu un client pot fi încheiate mai multe contracte, relația CONTRACTUL-CLIENT dintre aceste entități va avea gradul n: 1.

În acest caz, din motive absolut evidente (fiecare contract se încheie cu un anumit client, iar fiecare client are cel puțin un contract, altfel nu ar fi așa), fiecare entitate are o clasă de membru obligatorie.

multi la multi ( n:n). În acest caz, fiecare dintre entitățile asociate poate fi reprezentată de orice număr de instanțe. Lăsați întreprinderea pe care o luăm în considerare să creeze a grup de lucru, care include angajați din diferite departamente. Deoarece fiecare angajat poate fi membru al mai multor grupuri de lucru (inclusiv niciunul) și fiecare grup trebuie să includă cel puțin un angajat, relația dintre entitățile ANGAJAT și WORK_GROUP are un grad n:n.

Dacă existenţa unei entităţi X depinde de existenţa unei entităţi y, Acea X numit entitate dependentă(uneori entitatea X numit „slab” și „esență” y - puternic). Ca exemplu, luați în considerare relația dintre entitățile descrise anterior WORKING_GROUP și CONTRACT. Grupul de lucru este creat numai după semnarea contractului cu clientul și încetează să existe la finalizarea contractului. Astfel, entitatea WORKING_GROUP este dependentă de entitatea CONTRACT. Vom desemna o entitate dependentă printr-un dreptunghi dublu, iar legătura ei cu o entitate puternică printr-o linie cu săgeată:

Rețineți că cardinalitatea conexiunii pentru o entitate puternică va fi întotdeauna (1,1). Clasa de membru și gradul de relație pentru o entitate dependentă pot fi orice. Să presupunem, de exemplu, că întreprinderea pe care o luăm în considerare utilizează mai multe împrumuturi bancare, care sunt reprezentate de un set de entități CREDIT(AGREEMENT_NUMBER, AMOUNT, REPAYMENT_TERM, BANK). Pentru fiecare împrumut trebuie efectuate plăți de dobândă și rambursare. Acest fapt este reprezentat de un set de entități PAYMENT(DATE, AMOUNT) și un set de relații „realizate de”. În cazul în care un împrumut programat este anulat, informațiile despre acesta trebuie șterse din baza de date. În consecință, toate informațiile despre plățile programate pentru acest împrumut trebuie șterse. Astfel, entitatea de PLATA depinde de entitatea de CREDIT.

2.2.Diagrama entitate-relație.

O proprietate foarte importantă a modelului entitate-relație este aceea că poate fi reprezentat sub formă schema grafica. Acest lucru facilitează foarte mult analiza domeniului subiectului. Există mai multe opțiuni pentru denumirea elementelor unei diagrame entitate-relație, fiecare dintre ele având propriile caracteristici pozitive. Scurtă recenzie Unele dintre aceste notații vor fi făcute în secțiunea 2.4. Aici vom folosi un fel de hibrid al notațiilor lui Chen (desemnarea entităților, conexiunile și atributele) și Martin (desemnarea gradelor și cardinalitățile conexiunilor). Tabelul 2.1 listează notația folosită aici.

Tabelul 2.1

Atributele cu entități și entitățile cu relații sunt conectate prin linii drepte. În acest caz, pentru a indica cardinalitatea conexiunilor, se folosesc notațiile introduse în paragraful anterior.

În procesul de construire a unei diagrame, există mai multe etape evidente:

Identificarea entităților și a relațiilor de interes.
Identificarea informațiilor semantice în seturi de legături (de exemplu, dacă un anumit set de legături este o mapare 1:n).
Determinarea cardinalității conexiunilor.
Definirea atributelor și a seturilor de valori ale acestora (domenii).
Organizarea datelor sub formă de relații entitate-relație.

De exemplu, să construim o diagramă care arată conexiunea de date pentru subsistemul de contabilitate a personalului unei întreprinderi.

Să evidențiem entitățile și conexiunile care ne interesează:

În primul rând, o întreprindere este formată din departamente în care lucrează angajații. Salariul fiecarui angajat depinde de postul ocupat: inginer, inginer conducator, contabil, curatenitor etc. Să presupunem în continuare că compania noastră permite mai multe poziții, de ex. Fiecare angajat poate avea mai mult de o poziție (și poate lucra în mai multe departamente) și poate fi part-time. În același timp, mai mulți angajați pot ocupa același post în același timp. Ca urmare a acestui raționament, trebuie să introducem seturi de entități

DEPARTMENT(DEPARTMENT_NAME),
ANGAJAT(NUMĂR DE PERSONAL, NUME),
POSITION(POSITION_NAME, SALARY),

și setul de conexiuni WORKS_B cu atributul licitareîntre ele. Atribut licitare poate lua valori din intervalul ]0,1] (mai mare decât zero, dar mai mică sau egal cu unu), determină ce parte din salariul oficial primește un anumit angajat.

După cum sa menționat mai sus, fiecare n Un set -ary de conexiuni poate fi înlocuit cu mai multe seturi binare. Acum este un moment oportun pentru a evalua avantajele fiecăreia dintre aceste modalități de reprezentare a relațiilor.

Conexiunea de antrenament prezentată aici aduce cu siguranță mai mult informatii complete despre domeniul subiectului. Într-adevăr, reflectă în mod clar faptul că salariul unui angajat depinde de poziția sa, de departamentul în care lucrează și de tarif. Cu toate acestea, în acest caz există unele probleme cu determinarea gradului de conectare. Deși, după cum s-a spus, fiecare angajat poate ocupa mai multe funcții, iar în personalul fiecărui departament există posturi vacante cu diferite posturi, cu toate acestea, clasa de membru a entității POSIȚIE din figura de mai sus este setată la (1,1). Acest lucru se explică prin faptul că POZIȚIA este asociată de fapt nu cu entitățile ANGAJAT și DEPARTAMENT, ci cu relația dintre acestea. Se propune să se indice acest fapt așa cum se arată în diagrama următoare:

Aici, entitățile de relație ANGAJAT, DEPARTAMENT și WORK_B sunt agregate într-o nouă entitate abstractă care este asociată cu entitatea POZIȚIE folosind o relație de grad n:1.

Să încercăm să afișăm asociații de angajați, departamente și posturi folosind conexiuni binare.

În acest caz, pentru a descrie în mod adecvat semantica materiei, este necesară introducerea unei alte entități STAFF_UNIT, care înlocuiește de fapt relația WORK_B în entitatea abstractă și deci are atributul licitare.

Transfer de la n Conexiunea -ariană prin agregarea de entități la un set de relații binare poate fi considerată ca etape succesive ale unui singur proces, ceea ce duce la generarea fără ambiguitate a unui model de date relaționale. Când construiți o diagramă " entitate-relaţie„Puteți folosi oricare dintre aceste trei moduri de a prezenta datele.

Enumerați un număr de obiecte descrise în paragraful anterior care vor fi utile în modelarea datelor întreprinderii în cauză. Le corespund următoarele entități:

CUSTOMER(CUSTOMER_NAME,ADDRESS)
CONTRACT(NUMBER, START_DATE, END_DATE, AMOUNT)
GRUP DE LUCRU (PERCENTAGE_REWARD)

Atribut "procentul de remunerare" reflectă partea din valoarea contractului care este destinată să plătească membrii grupului de lucru relevant. Semnificația atributelor rămase este clară fără explicații suplimentare. Relațiile dintre entitățile listate sunt descrise și în paragraful anterior.
De regulă, unul dintre membrii grupului de lucru este lider în raport cu ceilalți angajați incluși în componența acestuia. Pentru a reflecta acest fapt trebuie să introducem legătura „ghidurilor” cu cardinalitatea 1,1:0,nîntre entitățile ANGAJAT și WORK_GROUP (un angajat poate conduce un număr arbitrar de grupuri de lucru, dar fiecare grup de lucru are unul și un singur lider).

Acum să aruncăm o privire mai atentă obiect informativ"client". În practică, este adesea necesar să se facă distincția între naționalitate entitati legale cu care întreprinderea intră în relaţii contractuale. Acest lucru se datorează faptului că pentru companiile străine este necesară stocarea, de exemplu, a informațiilor despre moneda în care se fac plățile, limba în care a fost semnat contractul etc. La rândul său, pentru companiile naționale este necesar să existe informații despre forma lor de proprietate (privată sau de stat), deoarece procedura de impozitare a fondurilor primite pentru executarea lucrărilor în baza unui contract poate depinde de aceasta.
Astfel, ajungem la concluzia că este necesar să mai introducem în considerare două seturi disjunse FOREIGN_ENTERPRISE(CURRENCY, LANGUAGE) și DOMESTIC_ENTERPRISE(FORM OF PROPERTY), a căror unire constituie setul complet CLIENT. Asocierea dintre aceste obiecte se numește relație de moștenire sau legătura ierarhică, deoarece entitățile FOREIGN_ENTERPRISE și DOMESTIC_ENTERPRISE moștenesc atributele entității CUSTOMER(CUSTOMER_NAME, ADDRESS). Pentru a determina cărui subset îi aparține o anumită entitate din setul CLIENT (și, în consecință, ce set de atribute are), trebuie să introduceți atributul numită „naționalitate”. discriminant. Acest tip de conexiune se propune a fi afișat pe diagramă după cum urmează:

Rezumând toate raționamentele de mai sus, obținem diagrama „entitate-relație” prezentată în figura următoare.

La sfârșitul acestei secțiuni, cititorului i se oferă câteva întrebări pentru studiu independent:

Cum se va schimba diagrama entitate-relație dacă procentul de remunerare pentru toate contractele este același?
Ce se va schimba în diagramă dacă mai multe poziții sunt interzise, de ex. fiecare angajat va avea dreptul de a ocupa un singur post cu cota 1?