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

Cea mai comună formalizare a ideilor despre domeniul subiectului se realizează în cadrul modelului „entitate-relație” („obiecte relaționale”). Pe această etapă proiectare, se folosește metoda „relație-esență”, care se mai numește și metoda „diagramelor ER” („Esență” – esență, „Relație” – conexiune). Această metodă se bazează pe utilizarea diagramelor, numite diagrame de instanță ER și, respectiv, diagrame de tip ER.

ER - diagrama entitate-relație este un ansamblu de multe obiecte și caracteristicile acestora, precum și relațiile dintre ele, necesare identificării datelor care sunt utilizate în continuare de funcțiile sistemului proiectat.

Principalele concepte ale metodei entitate-relație sunt următoarele:

Esență;

atribut de entitate;

cheie de entitate;

Comunicarea intre entitati;

Gradul de conectare;

Clasa de apartenență a instanțelor de entitate;

Diagrame ale instanțelor 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 în baza de date. Instanțele de entitate sunt distincte unele de altele și identificate în mod unic. Numele de entități sunt substantive. Fiecare tip de obiect este identificat prin propriul set 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 - I atribut) - o proprietate sau un lucru care este inseparabil de un obiect) este un element indivizibil din punct de vedere logic al structurii informaționale, caracterizat printr-un set de valori atomice. Acest concept este similar cu conceptul de „atribut” în 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 un anumit tip poate juca rolul unui atribut cheie (o cheie de entitate). În acest proiect de curs, entitățile de mai sus sunt caracterizate prin atribute, cum ar fi: cod_facultate, nume_facultate, 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 relație î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 vizibilitatea și ușurința de proiectare, folosim ajutoare grafice reprezentări ale unei entități, instanțe ale unei entități și relații dintre acestea. Diagrama ER este prezentată în Anexa A.

Clasificarea relațiilor

Î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 specifica legăturile 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 legăturile stabilite.

Stabilirea de legături facilitează accesul la date la efectuarea operațiunilor: căutare, vizualizare, editare, selecție și întocmire raport, deoarece este oferit accesul la orice câmpuri ale tabelelor asociate.

Între mese se pot seta:

Legături binare;

Conexiuni ternare;

Legături N-are.

Atunci când se leagă două tabele, se disting tabelele principale și subordonate (părinte și copil). Tabelele sunt legate logic folosind cheia de legătură. Câmpurile tabelului principal pot fi simple și cheie. Câmpurile de legătură ale tabelului suplimentar sunt cel mai adesea cheie. În funcție de modul în care sunt definite câmpurile de link ale tabelelor principale și suplimentare (cum se raportează câmpurile cheie la câmpurile de link), se stabilesc tipurile de linkuri:

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 din relația dintre tabelele părinte și fii sunt câmpuri cheie. Deoarece valorile din câmpurile cheie ale celor două tabele nu sunt repetate, este furnizată 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 tabelului suplimentar.

O relație M:M apare atunci când mai multe înregistrări ale tabelului principal corespund mai multor înregistrări ale tabelului suplimentar.

Ca 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 mese. În acest caz, o masă poate avea tipuri diferite legături către mai multe tabele, formând o ierarhie sau „arborele de legături”.

În acest proiect de curs, tabelele sunt legate prin relații 1:M (unu-la-mulți). De exemplu, tabelul „facultăți” este tabelul părinte al tabelului copil „departamente”. Aceste tabele sunt legate printr-o relație 1:M folosind cheia „faculty_code”

Elemente de model entitate-relație Entitate - Clasă de entitate - Atribute de instanță de entitate - Atribute compuse - Identificatori de atribute cu mai multe valori - Unice/Neunice - Relații compuse - Clase de relații - Instanțe de relație - Relații recursive

Elemente ale modelului entitate-relație O clasă de entități este o colecție de entități descrise de structura sau formatul entităților care alcătuiesc această clasă. O Instanță de entitate (o instanță) Reprezintă o entitate specifică De obicei, o clasă de entitate deține multe instanțe ale unei entități.

Elemente ale modelului entitate-relație Atribute Atributele (proprietăți) descriu caracteristicile unei entități. Exemplu de atribut compus: o adresă care constă dintr-un grup de atribute (stradă, oraș, cod poștal). Un exemplu de atribut cu mai multe valori: atributul Student Name al entității TEACHER, care poate conține numele mai multor elevi predați de aceasta.

Elemente de identificare a modelului entitate-relație Identificatorii sunt atribute prin care instanțe de entitate sunt denumite sau identificate. Dacă identificatorul este unic, valoarea sa va indica o singură instanță a entității. Dacă identificatorul nu este unic, valoarea lui va indica un set de instanțe. Identificatorii care constau din mai multe atribute sunt numiți identificatori compoziți.

Elemente ale relațiilor model entitate-relație Relațiile dintre entități sunt exprimate prin relații. Clasele de relații sunt relații între clase de entități. instanțe de relație relație între instanțe de entitate grad de relație numărul de clase de entități implicate în relație. Notarea prin intermediul diagramelor UML: se notează relația

Elemente ale modelului „entitate-relație” Trei tipuri de relații binare Desemnare prin mijloace în Diagramele UML: Relația 1:1 ("unu la unu") este desemnată Relația 1:N ("unu la N" sau "unu la mulți") - Relația N:M (a se citi "N la M" sau "mulți la mulți") - Legătura de a avea într-o formă generalizată, când nu este indicat un anumit tip de conexiune - Numerele din interiorul rombului care simbolizează legătura indică suma maxima entități de fiecare parte a relației. Aceste restricții se numesc numere cardinale maxime, iar combinația a două astfel de restricții pentru ambele părți ale conexiunii se numește cardinalitate maximă a conexiunii.

Diagrame entitate-relație Diagramele binare de relații descrise mai sus sunt numite diagrame entitate-relație sau diagrame ER (diagrame entitate-relație, diagrame ER). Există mai multe moduri de a specifica cardinalitatea minimă. Una dintre ele este prezentată mai jos. Relația cu cardinalitatea minimă specificată

Entități slabe Entitățile slabe sunt entități care pot exista într-o bază de date numai dacă o entitate de alt tip este prezentă în baza de date. O entitate care nu este slabă se numește entitate puternică. Entitățile dependente de ID sunt acele entități ai căror identificatori conțin identificatorul altei entități.

27

Diagrame entitate-relație în stil UML Construcții OOP introduse de UML Toate clasele de entități care trebuie stocate într-o bază de date sunt marcate cu stereotipul „Persistent” UML permite atribuirea de atribute claselor de entități UML folosește notația orientată pe obiect pentru a indica vizibilitatea de atribute și metode "+" - deschis "#" - protejat "-" - închis

Diagrame entitate-relație în stil UML Un atribut public este un atribut care poate fi citit și modificat prin orice metodă a oricărui obiect. Termenul protejat înseamnă că atributul sau metoda este disponibilă numai pentru metode. această clasăși subclasele sale. Iar termenul privat indică faptul că atributul sau metoda corespunzătoare este disponibilă numai pentru metodele acestei clase. UML definește constrângeri și metode.

Un model de tip entitate-relație este un model de domeniu informal care este utilizat în etapa de proiectare a bazei de date infologice. Acest model vă permite să modelați obiecte software, relații obiect. Simplitatea relativă, utilizarea limbajului natural și ușurința de înțelegere fac posibilă utilizați modelul ca instrument de comunicare cu viitorii utilizatori pentru a colecta informații despre domeniul subiectului pentru proiectarea bazei de date.

Scopul principal al modelului informal „entitate-relație” este o descriere semantică a domeniului subiectului și prezentarea de informații pentru a justifica alegerea tipurilor de modele și structuri de date care vor fi ulterior utilizate în sistem.

Există mai multe abordări ale construirii modelelor de tip „entitate-relație”. Comun tuturor abordărilor este utilizarea a trei elemente constructive principale pentru a reprezenta componentele software-ului - entitate, atribut și relație. Informațiile despre proiect sunt combinate folosind diagrame grafice. Componenta „timp” din compoziția elementelor structurale lipsește în mod explicit. Ora de apariție a evenimentelor poate fi reprezentată în model folosind atribute. De exemplu, AN NĂSCUIT, DATA ÎNTRĂRII, DATA DE SFÂRȘIT etc.

Esență este un concept colectiv, o abstractizare a unui obiect, proces sau fenomen din viața reală, despre care este necesară stocarea informațiilor în sistem. Ca entități în modele software, sunt considerate obiecte materiale (întreprindere, produs, angajați ai instituției etc.) și nemateriale (descrierea unor fenomene utilizate în datele de sistem, rezumate ale articolelor științifice etc.). În modelele software de tip „entitate-relație”, fiecare entitate specifică luată în considerare este un punct nodal pentru colectarea informațiilor despre această entitate. Modelul folosește și conceptul de „instanță de entitate”.

Un tip de entitate definește un set de obiecte omogene, iar o instanță de entitate definește un obiect specific din set. Fiecare tip de entitate luat în considerare în model trebuie să fie numit.

Pentru a identifica cazuri specifice de entități dintr-un anumit tip, sunt utilizate atribute speciale de identificare. Poate fi unul sau mai multe atribute, ale căror valori fac posibilă distingerea în mod unic a unei instanțe de entitate de alta.

Atribut este o caracteristică numită a unei entități care preia valori dintr-un set de valori. Într-un model, un atribut acționează ca un mijloc prin care sunt modelate proprietățile entității. De exemplu, pentru a descrie proprietățile entității CARTE, puteți folosi atributele TITLUL, NUMELE AUTORULUI, ANUL-PUBLICAȚIE. Pentru a seta un atribut într-un model, trebuie să îi dați un nume, să oferiți o descriere semantică a atributului, să definiți setul de valori valide ale acestuia și să indicați pentru ce este folosit.

Scopul principal al atributului este de a descrie proprietatea unei entități, precum și de a identifica instanțe de entitate. De exemplu, atributul DETAIL-CIP, care corespunde unui set de valori unice ale cifrurilor detaliilor, vă permite să identificați în mod unic instanțe specifice ale entității DETAIL în setul corespunzător. Atributul poate fi folosit și pentru a reprezenta conexiuni (relații) între entități, întrucât o legătură (relație) caracterizează exact acele obiecte între care există (de exemplu, relația TATĂL - natura rudeniei), și prin urmare poate acționa ca o proprietate , semn al unei entități.

DINcravată acționează în model ca un mijloc prin care sunt reprezentate relațiile dintre entitățile care au loc în software.Un tip de relație este considerat între tipuri de entități, iar o instanță specifică a unei relații de tipul considerat există între instanțe specifice ale entității luate în considerare. tipuri. Când se analizează relațiile dintre entități, pot exista relații binare (între două entități), ternare (între trei entități) și, în cazul general, relații n-are.

Legăturile binare sunt cele mai comune. Pentru a determina natura relației dintre două tipuri de entități, sunt utilizate mapări directe și inverse între cele două seturi corespunzătoare de instanțe de entități. Să dăm o clasificare a relațiilor binare.

Mapare 1:1 (relație unu la unu). Folosind o mapare 1:1, se definește acest tip de relație între tipurile de entități ȘIși LA, când fiecare instanță de entitate ȘI se potrivește cu o singură instanță de entitate LAși invers, pentru fiecare instanță de entitate LA se potrivește cu o singură instanță de entitate ȘI. Aceasta înseamnă că o instanță a entității de la care este direcționată relația, de exemplu ȘI, identifică una și doar o instanță a altei entități LA(spre care este îndreptată legătura) și invers. Identificarea instanței de entitate este unică în ambele direcții pentru mapările 1:1.

Cartografiere 1:M (relație unu-la-mulți). Folosind maparea 1:M, se determină tipul de relație dintre tipurile de entități ȘIși LA, când o instanță de entitate ȘI poate potrivi cu 0, 1 sau mai multe instanțe de entitate LA, cu toate acestea, fiecare instanță de entitate LA se potrivește doar cu o singură instanță de entitate ȘI. Aceasta înseamnă că cu o singură instanță de entitate ȘI poate fi asociat fie cu mai multe instanțe ale unei entități LA, fie unul, fie niciunul. Dar, în același timp, fiecare instanță a entității B este asociată cu o singură instanță a entității ȘI, adică identificarea instanțelor la afișajul 1: .M unic numai în direcția de la LA la ȘI.

Afişa M: 1 (relație multi-la-unu). Această mapare este inversa cartografierii 1:M

Afişa M: N(relație multi-la-cam-mulți). Folosind afișajul M : N se determină tipul de relaţie dintre tipurile de entităţi ȘIși LA,în care fiecare instanţă a entităţii ȘI poate potrivi cu 0, 1 sau mai multe instanțe de entitate LA si invers. Cu o singură instanță de entitate ȘI poate fi asociat fie cu mai multe instanțe ale unei entități LA, fie unul, fie niciunul. Dimpotrivă, cu o singură instanță de entitate LA poate fi, de asemenea, asociat fie cu mai multe instanțe de entitate ȘI, fie unul, fie niciunul, adică identificarea instanțelor de entitate nu este unică în ambele direcții.

În unele cazuri, este oportun să se ia în considerare o relație unidirecțională de la o entitate ȘI la esență LA.În funcție de caracteristicile cantitative ale afișajului, se distinge o relație simplă și cu multe valori.

Cu o relație unidirecțională simplă de la entitatea A la entitatea B în aceeași instanță de entitate ȘI se potrivește cu aceeași instanță de entitate LA.În acest caz, feedback-ul nu este definit. Identificarea instanței entității LA instanțe de entitate ȘI- unic (unic).

Cu o relație unidirecțională multi-valorică de la o entitate ȘI la esență LA aceeași instanță de entitate ȘI se potrivește cu 0, 1 sau mai multe instanțe de entitate LA. Când feedback-ul nu este definit. Identificarea instanței entității LA instanțe de entitate ȘI nu este unic.

Relațiile (relațiile) dintre entități sunt specificate prin expresii relaționale, în care entitățile sunt reprezentate prin atributele lor identificatoare. În multe cazuri, nu faptul că există o relație între entități este interesant, ci proprietățile acestei relații. Pentru zonele de producție și economice, aceste proprietăți sunt determinate de o anumită măsură numerică. Raportul entităților, împreună cu măsura numerică a acestui raport, determină conceptul-indicator, care este utilizat pe scară largă în activitățile de management.

În aceste cazuri, putem considera tipul de relație care ne interesează ca un anumit tip de entitate (ceea ce nu contrazice definiția introdusă). De exemplu, relația DETALII - X - PLACATE - IN - STOC - V este considerată ca o entitate despre care dorim să stocăm unele informații (de exemplu, despre numărul de piese, care ar trebui reprezentat de atributul CANTITATE corespunzător). Sau, de exemplu, relația EXAMEN dintre entitățile STUDENT, DISCIPLINĂ și PROFESOR poate fi considerată ca o entitate și are astfel de atribute descriptive precum EVALUARE și DATA - EXAMEN.

Informațiile despre proiect se întocmesc prin întocmirea de specificații pentru entități, atribute și relații folosind diagrame grafice, pentru aceasta ele indică: tipuri de entități - dreptunghiuri; atribute - în ovale, conectându-le cu tipurile de entități corespunzătoare cu margini nedirecționate, sunt subliniate atributele de identificare; legături (relații) - diamante, conectându-le cu tipurile corespunzătoare de entități prin muchii nedirecționate, cu excepția legăturilor binare, care sunt reprezentate prin muchii direcționate. Următoarele reguli generale sunt utilizate în modelare:

sunt folosite doar trei tipuri de elemente constructive - entitate, atribut, conexiune;

într-o reprezentare separată de proiectare, fiecare componentă de informație este modelată de un singur element structural, adică este necesar să se evite redundanța în utilizarea elementelor structurale.

Atunci când modelează un domeniu, designerul îl împarte într-un număr de domenii locale, modelează fiecare reprezentare locală și apoi le combină.

Modelul fizic Datele (tabulare) conțin definițiile tuturor obiectelor implementabile dintr-o anumită bază de date pentru un anumit SGBD.

Modelele sunt piatra de temelie a designului. Inginerii trebuie să construiască un model de mașină, să elaboreze toate detaliile înainte de a o pune în producție. În același mod, inginerii de sisteme dezvoltă mai întâi modele pentru a studia logica afacerii și pentru a-și aprofunda înțelegerea structurii bazei de date.

În ultima prelegere, ne-am familiarizat cu metodologiile IDEF0 și DFD care ne permit să descriem procesele de afaceri care au loc într-un sistem informațional. În modelul DFD, am considerat un element - un depozit de date, care arată tipurile de informații pe care operează sistemul. Cu toate acestea, această metodologie nu are scopul de a descrie structura informațiilor stocate. Pentru aceasta, sunt mai potrivite diverse Relații de Entități - diagrame (diagrame esențiale), al căror scop este de a descrie structura datelor stocate și relațiile dintre ele. Au fost dezvoltate tehnici care permit convertirea unor astfel de date într-un set de comenzi care vor crea stocarea necesară (tabelele) în baza de date a sistemului informațional.

Modelare ER

În sistemele informaționale, datele sunt împărțite în categorii separate sau entități. La urma urmei, ne amintim că o bază de date este un set de date structurate. Date tipuri variate depozitate separat. Sarcina modelului ER este de a arăta ce tipuri de informații sunt stocate în sistem, care este structura lor și cum sunt interconectate. Modelul ER este construit pe baza analizei de afaceri efectuate (diagrama DF construită). În acest caz, inițial, fiecare stocare pe diagrama DF devine o entitate pe diagrama ER. În cursul unei analize ulterioare, acestea pot fi împărțite în părți constitutive. Este de remarcat faptul că modelele ER sunt mai rezistente la schimbările din structura afacerii decât diagramele DF. Procesele de afaceri se pot schimba, dar informațiile necesare implementării lor rămân adesea neschimbate.

Principalele avantaje ale modelelor ER:

• Un format precis și ușor de înțeles pentru documentarea structurii informațiilor.
• Vă permite să specificați cerințele pentru date și relațiile dintre acestea.
• Vă permite să afișați vizual structura depozitului pentru a facilita proiectarea bazei de date.
• Există metode pentru maparea modelelor ER la tabelele bazei de date și invers.
• Puneți bazele integrării cu alte aplicații.

Principalele tipuri de obiecte din diagrama ER:

• Entitate - tipul de obiecte, informații despre care vor fi stocate în baza de date. De exemplu: departamente, angajați, mărfuri, facturi.
• Atribut - elementele care alcătuiesc entitatea. De exemplu, pentru entitatea „bunuri”, atributele pot fi „nume”, „descriere”, „cantitate”, „preț” și altele, în funcție de nevoile sistemului informațional. În funcție de notarea diagramei ER, lângă atribut, pe lângă denumirea acestuia, indicați tipul și completarea obligatorie. Slide-ul arată o diagramă ER în notația „Ingineria informațiilor”, conform căreia numele, tipul și este un strigăt extern și/sau primar este indicat pentru atribut.
• Relațiile arată relațiile dintre entități. De exemplu, un angajat lucrează într-un departament, unde „departamentul” și „departamentul” sunt entități.

O entitate este un set de obiecte din lumea reală, fiecare dintre ele având următoarele caracteristici:

• Unic (poate fi separat de toate celelalte într-un fel)
• Joacă un rol specific în sistemul simulat
• Poate fi descris prin una sau mai multe informații (Atribut)

Exemplu: oameni, personal, evenimente, comenzi, vânzări, clienți, furnizori

Un atribut descrie unele proprietăți ale unei entități. O entitate poate avea multe atribute, dar sunt selectate doar cele care sunt importante pentru sistem. Atributele sunt împărțite în cheie (Entity Keys) și descriptive (Entity Descriptors). Atributele cheie trebuie să identifice în mod unic instanțele de entitate. Pentru fiecare atribut, trebuie specificat un domeniu (tip, domeniu).

Slide-ul arată cum sunt scrise entitățile și atributele în diferite notații ale modelului ER. În toate notațiile, o entitate este un obiect dreptunghiular cu numele entității în partea de sus. Atributele sunt listate sub numele entității.

Să aruncăm o privire mai atentă la care sunt atributele cheie. Acest lucru este important pentru înțelegerea tipurilor de relații dintre entități.

Termeni de bază

Modelul relațional, dacă este necesar, poate fi descris limbaj matematic, adică cele mai exacte dintre cele inventate de om. Următoarele sunt definiții libere ale unor concepte ale modelului relațional.

• „Tipul de date” (tip, domeniu - domeniu) - un set de valori valide („domeniu”) și operațiuni. Pentru toate tipurile există operații de comparare și atribuire. Nu li se interzice valorilor să aibă structura, de exemplu, a unui obiect.
• „Relație” (relație) - un set de atribute: nume unice cu specificarea tipului de date; plus un set de „seturi de valori” („rânduri”) corespunzătoare atributelor. Valorile în mulțimi pot fi reprezentate doar prin valori individuale ale tipurilor de atribute corespunzătoare, adică pot fi scalari („prima formă normală”).
• „Cheie” (cheie) - un grup de atribute, ale căror valori sunt diferite în toate seturile în relație, dar niciun subgrup al acestor atribute nu are o astfel de proprietate (proprietatea „minimă” a cheii). În special, un grup poate consta dintr-un singur atribut. O relație trebuie să aibă întotdeauna o cheie, iar dacă există mai multe, una dintre ele trebuie desemnată „primară”.
• „Cheie străină” (cheie străină) - un grup de atribute, ale căror valori în fiecare set de valori ale relației trebuie să se potrivească cu valorile cheii unei eventuale alte relații. Cheile străine în relație sunt opționale și sunt declarate în funcție de necesitățile modelării.
• „Operațiuni” (operațiune) - un set de acțiuni comune asupra relațiilor, care din nou au ca rezultat relații („închiderea operațiunilor”). Sunt folosite pentru a obține noi relații în nevoile modelării ulterioare sau la extragerea datelor necesare din baza de date. Lista operațiunilor poate fi definită în diferite moduri; în primele propoziții ale modelului au fost date opt operații (proiecții, îmbinări, selecții etc.), nemaifiind setul minim, ca compromis între lipsa redundanței și ușurința în utilizare.
• " Baza de date relațională" (bază de date relațională) - un set de relații.

„Tipul de date” se numește uneori „domeniu” (domeniu), dar uneori prin „domeniu” înseamnă doar „domeniul” de valori. „Setul de valori” (tuplu) în rusă este altfel numit „tuplu” sau „n-koy”.

Pentru comoditate, relațiile sunt adesea descrise ca tabele, deși o astfel de prezentare este ilegală (nici ordinea atributelor și nici ordinea seturilor de valori nu sunt definite într-o relație, spre deosebire de un tabel). În SQL, pe baza căruia este construit și SGBD-ul Oracle, conceptul de „relație” ca instrument de modelare a fost înlocuit doar cu un „tabel”. O altă reprezentare a datelor de relație poate fi un hipercub și, de asemenea, uneori este convenabil să se recurgă la el în raționamentul despre o bază de date existentă.

Dacă renunțăm la cuvântul de urmărire definitiv „relațional”, atunci termenul „bază de date relațională” poate fi tradus ca „bază de date relațională” (mai precis, „bază de date construită prin relații"; relații ca instrument, nu obiect de modelare: altfel termenul inițial ar fi baza de date de relații). În același mod, termenul „model relațional" poate fi tradus ca „model relațional", adică „un sistem". de concepte pentru construirea unui model de domeniu sub forma unei relaţii de set". Din mai multe motive, inclusiv istorice şi lingvistice, acest lucru nu s-a făcut la momentul respectiv.

Toate relațiile de date sunt descrise clarși numai valori în seturi (poate fi diferit în alte abordări de modelare). Nu există dependențe „implicite” (inclusiv la nivelul logicii programului), cu excepția relațiilor formulate de variabile. Abordarea relațională distinge între descrierea datelor și logica programului care însoțește aplicația (spre deosebire de, de exemplu, abordarea obiect).

Vederea de mai sus a unei baze de date relaționale (un set de relații și operații) este tipică pentru algebră relațională. Acesta nu este singurul punct de vedere. Fiecare set de valori din variabila relație poate fi înțeles ca o afirmație adevărată („predicat”): există un angajat cu așa și cutare proprietăți; cutare departament și așa mai departe. Astfel, o bază de date relațională în fiecare moment de timp este un set de enunțuri adevărate despre domeniul subiectului, formulate prin relații. În esență, un set de afirmații în variabile de relațieși formează modelul de domeniu reprezentat de baza de date. Această vedere a unei baze de date relaționale este tipică pentru calculul relațional. Ambele puncte de vedere asupra modelului relațional au fost bine studiate și echivalența lor expresivă a fost dovedită.

Pentru termenii enumerați în diapozitivul anterior, există echivalente informale pentru a facilita înțelegerea și amintirea semnificației lor:

• Relație → Tabel
• Tuplu → șir, înregistrare
• Cardinalitate → Număr de rânduri
• Atribut → Coloană, câmp
• Grad → Număr de coloane
• Cheie primară → Identificator
• Domeniu → Interval valid

Câmpuri cheie

Unele dintre atributele relației sunt cheie sau chei. Există mai multe tipuri de chei:

• O cheie simplă constă dintr-un atribut, o cheie compusă este formată din mai multe.
• Cheie potențială- un atribut sau un set de atribute care pot identifica fiecare dintre tuplurile din relație. De exemplu, în ceea ce privește Biroul de pașapoarte("Numărul pașaportului") și ("Numele" și "Data nașterii") sunt potențiale chei care permit fiecărei persoane să fie identificată în mod unic.
• Fiecare relație poate avea o singură cheie primară - un atribut sau un set de valori ale atributelor ale căror valori identifică în mod unic fiecare intrare. Dacă mai multe seturi de atribute au astfel de proprietăți, atunci unul dintre ele este selectat ca principal, iar toate celelalte sunt alternative.
• cheie străină - magazine sens cheia principala altă relație. Cheile externe sunt folosite pentru a lega relații.

cheia principala

• Fiecare relație are o singură cheie primară, toate celelalte sunt alternative.
• Valoarea tuturor atributelor cheii primare nu poate nedefinit. De exemplu, o relație stochează informații despre locuitorii unui oraș. Cheie primară - compusă (NUME, PRENUME, data nașterii). Sistem informatic stabilit în Islanda, care nu folosește nume de familie, astfel încât atributul „nume de familie” pentru majoritatea tuplurilor va fi necompletat. În ciuda acestui fapt, cheia primară compozită va continua să identifice în mod unic fiecare dintre tupluri. Cu toate acestea, nu este permis ca valorile tuturor atributelor cheii primare să fie goale în același timp.
• Valoarea cheii primare nu afectează aranjarea tuplurilor în vizualizarea tabelului a relației. Chiar dacă valoarea cheii primare este un număr (de ex. 1,2,3...) în general, nu garantează că tuplurile din baza de date sunt stocate în aceeași ordine și vor fi scoase în aceeași ordine. În „cazul general” înseamnă că uneori, din cauza specificului unui anumit SGBD, rândurile pot fi stocate ordonate după cheia primară, dar aceasta este mai degrabă o excepție. În cazul ieșirii rezultatelor interogării, trebuie să specificăm în mod explicit ordinea în care trebuie să apară rândurile, dacă o astfel de ordine este importantă. Rezultatele interogării „da-mi primii 5 oameni” sunt imprevizibile, cu excepția cazului în care specificăm ce criterii ar trebui să fie „primi”.
• Cheia primară nu afectează accesul la atributele tuplului. De exemplu, în legătură cu „oficiul de pașapoarte”, împreună cu numele complet și data nașterii, este stocată adresa de înregistrare a persoanei. Putem cere bazei de date să extragă toate adresele fără a ști numele complet și data nașterii.

Cheie externă

O cheie externă este folosită pentru a stabili relații între relații. De exemplu, să luăm două relații „Proprietari” (cheie primară „număr de pașaport”) și „Imobiliare”. Pentru a stabili cine deține fiecare dintre obiectele imobiliare, vom lega aceste relații de valoarea atributului „număr pașaport”. Spre deosebire de cheia primară, valoarea cheii străine poate fi nedefinită (linia 4 pe slide) - dacă nu cunoaștem proprietarul proprietății, nu o specificăm. Spre deosebire de cheia primară, valoarea cheii străine poate fi repetată (rândurile 1.3 de pe diapozitiv) - un proprietar poate avea mai multe proprietăți. Cu toate acestea, faptul că atributul „număr pașaport” în relația „imobiliară” este o cheie străină pentru cheia primară a relației „proprietar” asigură că valoarea atributului „număr pastor” poate fi doar valori de la cheia primară. Nu putem specifica ca valoare de atribut numărul păstoririi unei persoane care nu se află deja în relația „Proprietar” (linia 5).

Prin setarea unei chei externe, puteți seta în mod explicit comportamentul DBMS dacă modificați valoarea cheii primare sau ștergeți tuplu. Cu toate acestea, aceasta păstrează regula „numai valorile care sunt în cheia primară sau o valoare nedefinită (NULL) sunt stocate în cheia externă”.

O cheie străină între relații este de obicei setată la proiectarea unei baze de date. Cu toate acestea, poate fi eliminat oricând sau reinstalat dacă adăugarea acestei constrângeri nu intră în conflict cu proprietățile cheii străine. Îndepărtarea/instalarea cheilor străine se face de obicei atunci când se inserează foarte volume mari date, pentru a accelera acest proces - SGBD nu poate stoca date inconsistente (incorecte, eronate), prin urmare verifică fiecare constrângere la inserarea fiecărui rând.

Modele ER: Conexiuni

Pe modelele ER, cheile externe sunt afișate ca relații.

Fiecare conexiune este caracterizată de 4 proprietăți - puterea, puterea, gradul și participarea entității la conexiune.

Să aruncăm o privire asupra acestor caracteristici.

Participarea unei entități într-o relație

Este indicat pe legătură printr-o linie transversală sau un cerc.

Linia transversală înseamnă obligatoriu (obligatoriu) participarea entității la conexiune, iar cercul - opțional (opțional).

În cazul participării obligatorii a unei entități la o conexiune, descrierea unei astfel de conexiuni folosește verbul „ ar trebui să". Cu participarea opțională a entității în relație, utilizați verbul " poate".

În departament poate lucrează cu mai mulți angajați. Angajat ar trebui să lucrează într-unul din departamente.

Gradul de conectare ( relaţie grad) indică numărul de entități asociate. Legătură binară ( binar relaţie) descrie asociații a două entități. Conexiune ternară (ternar relaţie) apare atunci când sunt asociate trei entități. legătură unară (unar relaţie) descrie asociații în cadrul unei singure entități.

Cele mai comune legături binare - conectează două entități diferite ("Departament" - "Angajat", "Comandă" - "Marfa", "Curs" - "Prelegeri", "Grup" - "Studenți"). Mai puțin obișnuite, dar încă des folosite, sunt legăturile unare. Cu ajutorul lor, de obicei stabilesc relația de imbricare pe obiecte de același tip (relația „Detalii” - putem specifica parte integrantă care detaliu este cel dat, relația „Angajați” – putem indica care dintre angajați este șeful pentru acesta).

Puterea legăturii indică câte instanțe ale unei entități sunt asociate cu instanțe ale altei entități.

Puterea poate fi:

• unu la unu(1:1) - în grupul de elevi este un singur conducător;
• unu-la-multi(1:N) - mulți angajați lucrează într-un singur departament;
• multi-la-multi(M:N) - un cumpărător a cumpărat o mulțime de bunuri, mulți cumpărători au cumpărat bunuri.

Puterea conexiunii: conexiune puternică (identificarea relației)

O entitate copil nu poate exista fără o entitate părinte. (Nu există răspuns fără întrebare; nu există niciun produs în coșul utilizatorului dacă coșul în sine nu există)

În acest caz, cheia primară migrează de la entitatea părinte la copil, unde devine parte a cheii primare.

În diagramă, o relație puternică este prezentată ca o linie solidă între entități.

Puterea legăturii: legătură slabă (relație de neidentificare)

Entitățile părinte și fii sunt înrudite, dar entitatea copil poate fi creată mai devreme. (Expedierea aparține comenzii, dar transportul poate fi în stoc înainte de crearea comenzii).

Cheia primară migrează de la entitatea părinte la entitatea copil și nu face parte din cheia primară (devine doar o cheie străină).

Diagrama arată o relație puternică linie punctata intre entitati.

Legătură recursiva (link unară)

Cel mai adesea folosit pentru a construi ierarhii.

Un furnizor POATE lucra cu ZERO sau MAI MULTI clienți (id_Customer).

Clientul TREBUIE să lucreze cu un singur furnizor (id_Sup).

Dar furnizorul și clientul - fie că este o firmă sau o organizație - sunt obiecte de același tip și, prin urmare, sunt stocate în aceeași relație.

Relație de la mulți la mulți.

Exemplu: Furnizorii pot furniza multe tipuri de bunuri. Furnizori diferiți pot furniza aceleași tipuri de mărfuri.

O relație multi-la-mulți este valabilă din punctul de vedere al modelului ER, dar nu poate fi reflectată direct în termenii algebrei relaționale.

Ambiguitatea relației este rezolvată prin introducerea de entități tranzitorii, așa cum se arată în diapozitiv.

Modele ER și realitate

La o examinare mai atentă a relației unu-la-unu, se dovedește aproape întotdeauna că A și B sunt de fapt subseturi diferite ale aceluiași subiect sau puncte de vedere diferite asupra acestuia, având doar nume diferite și relații și atribute descrise diferit.

Imaginați-vă că A este un furnizor, B este un produs.

Obligatoriu-obligatoriu. Pentru exemplul prezentat pe diapozitiv, această relație înseamnă că fiecare furnizor (furnizor) ar trebui să furnizează doar unul unic un set de mărfuri (Factură). Din punct de vedere teoretic, aici totul este bine. În practică, acest lucru nu este acceptabil: nimeni nu va căuta un furnizor nou dacă furnizorul pe care l-ați verificat poate furniza mai multe linii de produse. Și acum despre emoțiile pe care le va experimenta operatorul atunci când încearcă să introducă date despre un nou furnizor. El nu va putea introduce date în niciunul dintre tabele. Așa că toate bagajele de limbaj obscen îți vor fi trimise.

facultativ-obligatoriu. Un exemplu de conexiune este prezentat pe slide. După cum puteți vedea, operatorul se descurcă acum bine: poate introduce date. Afacerea are din nou o problemă: trebuie să caute un nou furnizor, chiar dacă furnizorul pe care l-ați verificat poate oferi mai multe linii de produse. Afacerile au nevoie de probleme? Nu. Trebuie sa functioneze. Cum să satisfacă afacerea? Răspunsul este simplu. Când proiectați o bază de date, trebuie să vă gândiți la normalizare. Dacă Furnizorul este o entitate, atunci utilizați relații opțional-obligatoriu (obligatoriu-opțional) sau opțional-opțional. De cele mai multe ori, totuși, relațiile unu-la-unu sunt o greșeală.

Opțional-opțional. După cum puteți vedea, operatorul merge din nou bine, dar afacerea are din nou o problemă. Să rezumam pentru o relație unu-la-unu. Dacă entitățile participă la o relație ca: - obligatoriu-obligatoriu, atunci o astfel de relație nu are dreptul să existe; - opțional-obligatoriu (obligatoriu-opțional) sau opțional-opțional, atunci suportul de afaceri este problematic.

Relația obligatorie-unul-la-mulți este un construct suficient de puternic încât intrarea entității B nu poate fi creată fără crearea simultană cel puțin o apariție a entității A asociată cu aceasta. Cel mai adesea, aceasta este o asociere incorectă.

Relația obligatorie-opțională unu-la-mulți este cea mai comună formă de relație. Se presupune că fiecare apariție a entității A poate exista numai în contextul uneia (și numai una) apariție a entității B. La rândul lor, aparițiile lui B pot exista atât în ​​legătură cu aparițiile lui A, cât și fără ea.

Relația unu-la-mulți opțional-opțional - Atât A, cât și B pot exista fără o relație între ele.

În ceea ce privește diapozitivul anterior, aceste diagrame pot fi ilustrate cu următoarele exemple.

Relații unu-la-mulți. Aceste relații sugerează că o înregistrare dintr-un tabel poate fi legată logic de mai multe înregistrări dintr-un alt tabel.

Obligatoriu-obligatoriu. Pentru exemplul prezentat pe diapozitiv, această relație înseamnă că fiecare furnizor (A) trebuie să furnizeze unul sau mai multe seturi de mărfuri (B). Din punct de vedere teoretic, aici totul este bine. Cu toate acestea, în practică, operatorul nu va putea introduce date în niciunul dintre tabele, deoarece înregistrările trebuie să fie simultan intra in ambele tabele.

facultativ-obligatoriu.În acest caz, operatorul se descurcă acum bine: poate introduce datele, dar afacerea poate avea probleme. Ideea este că relația opțional-obligatorie presupune că furnizorul (A) ar trebui să furnizează unul sau mai multe seturi de bunuri (B), în timp ce B poate aparțin furnizorului. Cu alte cuvinte, bunurile pot exista fără furnizor în timp ce furnizorul are bunuri. Acestea. posibilă conduită comercială necontrolată: cine a furnizat bunurile? Pe cine sa intrebi? Afacerile au nevoie de probleme? Nu. Trebuie să fie profitabil. În acest caz, este mai bine să utilizați obligatoriu-opțional: furnizorul poate furniza unul sau mai multe seturi de bunuri, în timp ce bunurile trebuie să aparțină furnizorului. Cu alte cuvinte, produsul are un furnizor, iar datele despre furnizorii care odată au furnizat produsul vor fi salvate. Și oile sunt în siguranță, iar lupii sunt plini - operatorul poate introduce date, iar omul de afaceri este la curent.

Opțional-opțional. După cum puteți vedea, totul este bine cu operatorul din nou, dar afacerea are o problemă - lipsa de control: un produs poate exista fără furnizor și un furnizor fără produs.
Să rezumăm relația unu-la-mulți. Dacă entitățile participă la o relație ca: - obligatoriu-obligatoriu, atunci o astfel de relație nu are dreptul de a exista, întrucât este imposibil să se introducă înregistrări simultan în ambele tabele; - optional-optional, atunci suportul de afaceri este problematic.

Relațiile multi-la-mulți sunt permise în diagramele ER, totuși, atunci când sunt convertite într-o reprezentare tabelară, o astfel de relație este înlocuită cu o entitate intermediară.

Many-to-many obligatoriu-obligatoriu - o astfel de construcție are loc adesea la începutul etapei de analiză și înseamnă o relație - fie neînțeleasă pe deplin și necesită o permisiune suplimentară, fie reflectând o simplă relație colectivă - o listă dublu legată.

Many-to-many obligatoriu-opțional - Foarte rar folosit. Astfel de link-uri sunt întotdeauna supuse unor detalii suplimentare.

Legături recursive. Aceste relații implică faptul că intrările din tabel pot fi legate logic între ele.

Opțional-opțional unu-la-unu. Pentru exemplul prezentat pe diapozitiv, această relație înseamnă că orice bărbat (femeie) poate fi căsătorit cu o singură femeie (bărbat). Această conexiune este convenabilă pentru urmărirea istoricului soților: pentru prima dată, din nou, ... Cu alte cuvinte, un tip alternativ de conexiune.

Opțional-opțional unu-la-mulți. Un exemplu de conexiune este prezentat pe slide. Aceasta este o ierarhie clasică (structură arborescentă). Legătura prezentată pe slide poate fi interpretată, de exemplu, astfel: orice angajat poate fi subordonat unui singur manager, în timp ce un manager poate gestiona unul sau mai mulți angajați.

Opțional-opțional M:M Un exemplu de conexiune este prezentat în diapozitivul 3. Aceasta este o structură de rețea.

Lista de verificare a întrebărilor entităților

• Numele unei entități reflectă esența acest obiect?
• Există o intersecție cu alte entități?
• Există cel puțin două atribute?
• Nu există mai mult de opt atribute în total?
• Există sinonime/omonime pentru această entitate?
• Este entitatea pe deplin definită?
• Există un identificator unic?
• Există cel puțin o conexiune?
• Există cel puțin o funcție pentru crearea, căutarea, actualizarea, ștergerea, arhivarea și utilizarea unei valori de entitate?
• Există un istoric al schimbărilor?
• Există respectarea principiilor normalizării datelor?
• Există aceeași entitate într-un alt sistem de aplicații, poate sub un alt nume?
• Are și esența bun simț?
• Este suficient nivelul de generalizare încorporat în el?

Lista de verificare a atributelor:

• Numele unui atribut este un substantiv singular care reflectă esența proprietății notate de atribut?
• Numele atributului nu include numele entității (nu ar trebui)?
• Atributul are o singură valoare la un moment dat?
• Lipsesc valori (sau grupuri) duplicate?
• Sunt descrise formatul, lungimea, valorile valide, algoritmul de derivare etc.?
• Acest atribut ar putea fi o entitate omisă care ar fi utilă pentru un alt sistem de aplicații (existent sau propus)?
• Ar putea fi un link pierdut?
• Există undeva o referire la atribut ca „funcție de proiect” care ar trebui să dispară atunci când treceți la stratul de aplicație?
• Este nevoie de un istoric al schimbărilor?
• Valoarea sa depinde doar de entitatea dată?
• Dacă valoarea unui atribut este necesară, este întotdeauna cunoscută?
• Este necesar să se creeze un domeniu pentru aceasta și atribute similare?
• Înțelesul său depinde doar de o anumită parte identificator unic?
• Valoarea acestuia depinde de valorile unor atribute care nu sunt incluse în identificatorul unic?

Înainte de a porni sistemul prelucrare automată informații, dezvoltatorul trebuie să formeze concepte despre obiecte, fapte și evenimente pe care le va opera acest sistem. Pentru a aduce aceste concepte într-un anumit model de date, este necesar să le înlocuim reprezentări informaţionale. Una dintre cele mai instrumente la îndemână reprezentare unificată a datelor, independentă de cel care le implementează software, este modelul entitate-relație (modelul ER).

Modelul entitate-relație se bazează pe câteva informații semantice importante despre lumea reală și este conceput pentru a reprezenta datele într-un mod logic. Acesta definește semnificațiile datelor în contextul relației lor cu alte date. Important pentru noi este faptul că din modelul „entitate-relație” se pot genera toate modelele existente date (ierarhice, de rețea, relaționale, obiect), deci este cea mai generală.

Modelul entitate-relație a fost propus în 1976 de Peter Ping-Shen 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” N 3, 1995.

Vizualizări de date stratificate

Când se examinează un model de date, ar trebui să se identifice nivelurile de reprezentare logică a datelor pentru care acest model este relevant. Extinderea setului de prevederi, putem defini patru niveluri de prezentare a datelor:

Informații referitoare la entități și relații care există în imaginația noastră; - structura informaţiei - organizarea informaţiei în care entităţile şi relaţiile sunt reprezentate prin date. - structură de date independentă de căile de acces - structuri de date care nu sunt asociate cu scheme de căutare, indexare etc. - structura datelor dependentă de căile de acces.

Figura 1. Analiza modelelor de date folosind mai multe niveluri 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 element care poate fi identificat într-un fel care îl deosebește de alte elemente. Exemple de entitate sunt persoana speciala, companie sau eveniment. O relație este o asociere stabilită între entități. De exemplu, un tată-fiu este o relație între două ființe 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 întreprinderii Descriere completa entități sau relații. Este imposibil (și, aparent, nu este necesar) să salvezi toate potențialele informatii disponibile despre entităţi şi relaţii. În plus, 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 set de 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ă această entitate aparține set dat. 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, entitatea aparținând setului entități PERSOANĂ-BĂRBAȚI (BĂRBAȚI), aparține de asemenea ansamblului de entități PERSOANA (PERSOANE). În acest caz, PERSOANĂ BĂRBAȚĂ este un subset al PERSOANĂ.

Conexiune, rol și multe legături.

Luați în considerare asociațiile de entități. Mulțimea 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 în relația respectivă. Soțul (soțul) și soția (soția) sunt roluri. Ordonarea entităților în definiția relației (rețineți că am folosit paranteza patrata) poate lipsi dacă relația specifică în mod explicit rolurile entităților: (r1/e1, r2/e2 ,..., rn/en), unde ri este rolul entității ei în această relație.

Atribut, valoare și set de valori.

Informațiile despre entitate sau relație sunt obținute prin observare sau măsurare și sunt exprimate printr-o multitudine de perechi atribut-valoare. 3, roșu, Peter și Johnson sunt valorile. Valorile sunt clasificate în diverse seturi seturi de valori precum PICIOARE, CULOARE, PRENUME și NUME. Fiecare set de valori are asociat un predicat pentru a verifica 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 la un set de valori sau un produs cartezian de seturi de valori:

f: Ei sau Ri → Vi sau Vi1 × Vi2 × ... × Vin 2 prezintă mai multe atribute definite pe setul de entități PERSONA. Atributul AGE se asociază cu setul de valori NO-OF-YEARS. Un atribut poate specifica o mapare la un produs cartezian de seturi de valori. De exemplu, atributul NUME (NUME COMPLET) specifică o mapare cu valorile NUME (NUME) și NUME (NUME). 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 NUME (NUME COMPLET) și NUME ALTERNATIVE (ALTUT-NUME COMPLET) specifică o mapare de la setul de entități ANGAJAT la seturile de valori FIRST-NUME și LAST-NAME. Astfel, atributul și setul de valori sunt concepte diferite, deși în unele cazuri pot avea același nume (de exemplu, atributul ANGAJAT-NU (NUMĂR-ANGAJAT) specifică o mapare de la ANGAJAT (ANGAJAT) la setul de valori ANGAJAT- NU (NUMĂR DE ANGAJAT).- SERVATOR)). Această distincție nu este clară în model de rețea iar în multe sistemele existente management de date. De asemenea, rețineți că un atribut este definit ca o funcție. Prin urmare, se afișează entitate datăî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 entitati PERSONA

Rețineți că linkurile au și atribute. Luați în considerare setul de relații PROIECT-LUCRĂTOR (EXECUTOR-PROIECT) (Fig. 3). Atributul PERCENTAGE-DE-TIME, reprezentând proporția de timp alocată unui anumit angajat pentru 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 relații PROIECT-LUCRĂTOR

Structura conceptuală a informațiilor.

Vom discuta acum despre cum pot fi organizate informațiile despre entități și relații. Acest articol propune o metodă de separare a informațiilor despre entitate și informații despre relație. Vom arăta că o astfel de separare este utilă pentru identificarea dependențelor funcționale dintre date.

Pe fig. 4 prezintă informații despre entitățile din setul de entități sub forma unui 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 din setul de entități (formular tabel)

Orez. 5. Informații despre link-uri dintr-un set de link-uri (form tabel)

Pe fig. 5 oferă informații despre legăturile din setul de legături. 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. 4 și 2 (precum și în Fig. 5 și 3) sunt diferite forme aceleași informații. Formularul tabelului este folosit pentru a facilita asocierea cu modelul relațional.

Structura informațiilor

Entitățile, relațiile și valorile de la nivelul 1 (vezi Figura 2-5) sunt obiecte conceptuale care există în imaginația noastră (adică ne-am aflat în domeniul conceptual). La nivelul 2, luăm în considerare reprezentări ale obiectelor conceptuale. Presupunem că există reprezentări directe ale valorilor. În continuare, descriem cum pot fi reprezentate entitățile și relațiile.

cheia principala.

Pe fig. Cele 2 valori ale atributului 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 o mapare 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ă pe datele disponibile sau dacă se dorește simplitate în identificarea obiectelor, atunci un set de atribute și valori poate fi definit artificial pentru a realiza o mapare unu-la-unu. Când există mai multe chei, cheia semnificativă din punct de vedere semantic este de obicei aleasă ca cheie primară a entității (PK).

Orez. 6. Reprezentarea entităților prin valori (număr de angajați)

Orez. 6 se obţine prin comasarea entităţii ANGAJAT setată cu valoarea ANGAJAT-NU setată 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 definesc o mapare de la setul de valori ANGAJAT-NU la alte seturi de valori. Rețineți, de asemenea, că atributul EMPLOYEE-NO specifică o mapare din valoarea EMPLOYEE-NO setată la sine.

Relații entitate/relație.

Informațiile despre entitate dintr-un set de entități pot fi acum organizate în forma prezentată în Figura 2. 7. Rețineți că fig. 7 este similar cu fig. 4, cu excepția faptului că entitățile sunt reprezentate de valorile cheii lor primare. Întregul tabel din 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 (relațiile) pentru a le identifica. De exemplu, luați în considerare entitățile slujitori-subordonați (dependenți) și servitori-șefi (susținători): subordonații sunt identificați după numele lor și valorile cheii principale a servitorilor-șefi (adică, relațiile lor cu acești angajați). Rețineți că în fig. 9 ANGAJAT-NU nu este un atribut al entităților din setul DEPENDENT, ci este cheia primară a angajaților care au subordonați. Fiecare rând 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.

Teoretic, orice fel de relație poate fi folosită pentru a identifica entități. Pentru simplitate, ne restrângem 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-șef corespunzător.

Această metodă de identificare a entităților prin relații cu alte entități poate fi aplicată recursiv până când există entități care pot fi identificate prin propriile valori ale atributelor. 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.

Prin urmare, avem două forme de relații între entități. Dacă relațiile sunt folosite pentru a identifica entitățile, ne vom referi la aceasta ca o relație slabă de entitate (Figura 9). Dacă relațiile nu sunt folosite pentru a identifica entitățile, vom numi aceasta 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ție între entitățile DEPENDENTE și alte entități va avea ca rezultat o relație de relație slabă, deoarece entitatea DEPENDENTE este identificată prin numele și relația sa cu entitatea ANGAJAT. Distingerea dintre relațiile obișnuite și cele slabe între entități și relații va fi utilă în menținerea integrității datelor.