Conceptul modelului ER. Conceptul de entitate. Atribute. Tipuri de atribute

1. Ce probleme poate întâmpina un dezvoltator atunci când proiectează o bază de date?

Atunci când proiectați o bază de date și dezvoltați un produs software, cel mai mult problema importanta Există o problemă de interacțiune între dezvoltator și client. Sarcina dezvoltatorului este de a recrea cu cea mai mare acuratețe dorințele clientului atunci când dezvoltă un produs software de gestionare a bazelor de date. Principala problemă pe care trebuie să o rezolve dezvoltatorul este construcție corectă baze de date, sau mai degrabă scheme (structuri) de baze de date.

În plus, dezvoltatorul întâmpină și alte dificultăți, care includ:

• căutarea de algoritmi eficienți;
• selectarea structurilor de date adecvate;
• depanarea și testarea codului complex;
• designul și capacitatea de utilizare a interfeței aplicației.

În stadiul de dezvoltare software, care gestionează baza de date, dezvoltatorul trebuie să învețe în detaliu cerințele clientului. Baza de date trebuie concepută astfel încât să fie de înțeles, să reflecte cel mai exact problema rezolvată și să nu conțină date redundante.

Pentru a facilita procesul de dezvoltare (proiectare) a unei baze de date, așa-numita modele semantice date. Pentru tipuri diferite Cea mai cunoscută bază de date este modelul de date ER (model Entity-Relationship).

2. Ce este modelul ER (model entitate-relație)? De ce trebuie să dezvoltați un model ER?

Modelul ER (Entity-relationship model sau Entity-relationship diagram) este un model de date semantice care are scopul de a simplifica procesul de proiectare a bazei de date. Din modelul ER pot fi generate toate tipurile de baze de date: relaționale, ierarhice, de rețea, obiect. Modelul ER se bazează pe conceptele de „entitate”, „relație” și „atribut”.

Pentru bazele de date mari, construirea unui model ER vă permite să evitați erorile de proiectare extrem de greu de corectat, mai ales dacă baza de date este deja în funcțiune sau în stadiul de testare. Erorile în dezvoltarea structurii bazei de date pot duce la reelaborarea codului software care gestionează această bază de date. Ca urmare, timpul, banii și resursele umane vor fi utilizate ineficient.

Un model ER este o reprezentare a unei baze de date sub formă de diagrame grafice vizuale. Modelul ER vizualizează un proces care definește un anumit domeniu. O diagramă entitate-relație este o diagramă care reprezintă grafic entități, atribute și relații.

Modelul ER este doar un nivel conceptual de modelare. Modelul ER nu conține detalii de implementare. Pentru același model ER, detaliile sale de implementare pot diferi.

3. Ce este o entitate într-o bază de date? Exemple

O entitate dintr-o bază de date este orice obiect dintr-o bază de date care poate fi identificat pe baza esenței domeniului pentru care această bază de date este dezvoltată. Proiectantul bazei de date trebuie să fie capabil să definească corect entitățile.

Exemplul 1.În baza de date a librăriei pot fi distinse următoarele entități:

• carte;
• furnizorul;
• plasare în magazin.

Exemplul 2.În baza de date contabilă a procesului de învățământ a unei anumite instituții de învățământ se pot distinge următoarele entități:

• studenți (studenți);
• profesori;
• grupuri;
• disciplinele care sunt studiate.

4. Ce tipuri de tipuri de entități există? Desemnarea tipurilor de entități în modelul ER

În modelul „entitate”-“relație” se disting două tipuri de tipuri de entități:

• tip slab. Acest tip de entitate este dependent de o entitate puternică;
• tip puternic. Acesta este un tip independent de entitate care nu depinde de nimeni.

Figura 1 prezintă denumirile tipurilor de entități slabe și puternice în modelul ER.

Orez. 1. Desemnarea tipurilor de entități puternice și slabe

5. Pentru ce sunt atributele? Tipuri de atribute. Desemnarea atributelor pe modelul ER

Fiecare tip de entitate are un set specific de atribute. Atributele sunt destinate să descrie o anumită entitate.

Se disting următoarele tipuri de atribute:

• simplu atribute. Acestea sunt atribute care pot face parte din atributele compuse. Aceste atribute constau dintr-o singură componentă. De exemplu, atributele simple includ: codul unei cărți dintr-o bibliotecă sau cursul unui student într-o instituție de învățământ;
• compozit atribute. Acestea sunt atribute care constau din mai multe atribute simple. De exemplu, adresa de rezidență poate conține numele țării, localitatea, strada, numărul casei;
• lipsit de ambiguitate atribute. Acestea sunt atribute care conțin o singură valoare pentru o anumită entitate. De exemplu, atributul „Număr carnet de note” pentru tipul de entitate „Student” este lipsit de ambiguitate, deoarece un student poate avea un singur număr de carnet de teste (o singură valoare);
• polisemantic atribute. Acestea sunt atribute care pot conține mai multe valori. De exemplu, atributul cu mai multe valori „Număr de telefon” pentru entitatea „Student”, deoarece un student poate avea mai multe numere de telefon (acasa, mobil etc.);
• arbitrar atribute. Acestea sunt atribute a căror valoare se formează pe baza valorilor altor atribute. De exemplu, cursul actual de studiu al unui student poate fi calculat pe baza diferenței dintre anul curent de studiu și anul în care studentul a intrat în instituție educațională(dacă studentul nu a avut probleme cu studiile și a studiat bine disciplina „Organizarea bazelor de date și a cunoștințelor”).

Într-o diagramă ER, atributele sunt desemnate așa cum se arată în Figura 2. După cum se poate vedea din figură, orice atribut este desemnat ca o elipsă cu un nume în interiorul elipsei. Dacă atributul este cheia primară, atunci numele său este subliniat.

Figura 2. Reprezentarea atributelor în diagramele modelului ER

6. Cum sunt implementate tipurile de entități și atributele modelului ER în bazele de date reale și în programele pe care le gestionează?

Atunci când se dezvoltă programe de gestionare a bazelor de date, tipurile de entități și atributele acestora pot fi reprezentate în moduri diferite, respectând mai multe abordări:

• alege o tehnologie binecunoscută ca sursă de date (de exemplu, Microsoft SQL Server, Oracle Database, Microsoft Access, Microsoft ODBC Data Source etc.), care a fost deja cercetată, testată, standardizată și are un set imens de gestionare a bazelor de date unelte;
• dezvoltați propriul format de bază de date și implementați metode pentru procesarea acesteia și implementați interacțiunea cu surse de date cunoscute sub formă de comenzi speciale precum Import/Export. În acest caz, va trebui să programați personal toate lucrările de rutină de întreținere și asigurare a funcționării fiabile a bazei de date;
• implementați o combinație a celor două abordări de mai sus. Instrumentele moderne de dezvoltare software au un set puternic de biblioteci pentru procesarea seturilor complexe și vizualizarea datelor din ele (colecții, matrice, componente de vizualizare etc.).

Dacă baza de date este implementată în SGBD relațional bine-cunoscut (de exemplu, Microsoft Access, Microsoft SQL Server etc.), atunci tipurile de entități sunt reprezentate prin tabele. Atributele din modelul ER corespund câmpurilor tabelului. O intrare dintr-un tabel al bazei de date reprezintă o instanță a unei entități.

Fiecare tip de atribut este implementat după cum urmează:

• atribut simplu sau un atribut cu o singură valoare poate fi reprezentat printr-un set accesibil de tipuri de bază care se găsesc în orice limbaj de programare. De exemplu, atributele întregi sunt reprezentate de tipul int, integer, uint etc.; atributele care conțin o parte fracțională pot fi reprezentate ca float, double; atribute șir de tip șir etc.;
• atribut compus este un obiect care include mai multe atribute simple imbricate. De exemplu, în Microsoft Access DBMS, un atribut compus al unui tabel poate fi format pe baza unui set de tipuri simple (câmpuri). În limbajele de programare, unirea câmpurilor este implementată prin structuri sau clase;
• atribut cu mai multe valori poate fi implementat printr-o matrice sau o colecție de atribute simple sau compuse;
• atribut arbitrar implementat de un câmp suplimentar, care se calculează la accesarea tabelului. Un astfel de câmp se numește câmp calculat și se formează pe baza altor câmpuri ale tabelului;
• atribut care este cheia primară poate fi un număr întreg, șir sau alt tip ordinal. În acest caz, valoarea fiecărei celule de tabel care corespunde cheii primare este unică. Cel mai adesea, cheia primară este un tip întreg (int, integer).

Dacă baza de date este implementată într-un format unic, atunci tipurile de entități sunt cel mai convenabil reprezentate ca clase sau structuri. Atributele entității sunt implementate ca câmpuri (date interne) ale clasei. Metodele de clasă implementează procesarea necesară a câmpurilor de clasă (atribute). Interacțiunea (comunicarea) între clase este implementată folosind interfețe special concepute folosind modele de design bine-cunoscute.

7. Exemplu de fragment de model ER pentru tipul de entitate „Student”.

Exemplul de mai sus demonstrează un fragment al modelului ER pentru tipul de entitate „Student”.

Figura 3. Fragment al modelului ER pentru tipul de entitate „Student”.

Figura de mai sus declară următoarele atribute, care într-un SGBD (program) pot avea următoarele tipuri:

• Atributul cheii primare este o valoare întreagă unică care este generată automat. În DBMS acesta este un câmp de contor;
• atributul An de intrare este un atribut simplu care poate fi implementat ca valoare întreagă (int, integer);
• atributul Phone number este un atribut cu mai multe valori care poate fi implementat ca o matrice sau o colecție etc.;
• atribut Numărul cărții de înregistrare– un atribut simplu care poate fi implementat ca șir de caractere, întrucât numărul din cartea de înregistrare poate conține litere în plus față de cifre;
• atributul Țara, Orașul, Strada, Numărul casei sunt atribute care formează atributul compus Adresă. Toate aceste atribute pot fi de tip string (text) (string, Text);
• atribut Nume, Prenume, Patronimic – acestea sunt atribute simple care fac parte din atributul compus Nume Student. Toate aceste atribute pot fi de tip string (text) (string, Text);
• atributul Birthday este un atribut simplu de tipul Date (DateTime);
• atribut Vârsta studentului– un câmp calculat, care este definit ca diferența dintre data curentă (de sistem) și valoarea atributului Zi de naștere.

Regula de bază la crearea tabelelor de entități, acesta este „un tabel separat pentru fiecare entitate”.

Câmpurile tabelului de entități pot fi de două tipuri: cheieȘi non-cheie. Introducerea cheilor într-un tabel în aproape toate SGBD-urile relaționale vă permite să asigurați unicitatea valorilor din înregistrările tabelului după cheie, să accelerați procesarea înregistrărilor din tabel și, de asemenea, să sortați automat înregistrările după valori în câmpurile cheie.

Definiția este de obicei suficientă simplu cheie, mai rar - enter compozit cheie. Un tabel cu o cheie compusă poate fi, de exemplu, un tabel care stochează o listă de angajați (nume, prenume și patronimic), în care se găsesc omonimi. Unele SGBD-uri oferă utilizatorilor opțiunea de a defini un câmp de numerotare a cheilor generat automat (în Access, acesta este un câmp de tip „contor”), ceea ce simplifică soluția la problema unicității înregistrărilor tabelului.

Uneori, tabelele de entități au câmpuri care descriu proprietățile sau caracteristicile obiectelor. Dacă tabelul are un număr semnificativ de repetări în aceste câmpuri și aceste informații au un volum semnificativ, atunci este mai bine să le separați într-un tabel separat (aderând la regula: „fiecare entitate are un tabel separat”). Mai mult, ar trebui creat un tabel suplimentar dacă proprietățile sunt interconectate.

Când procesați tabelele de entități, țineți cont de următoarele. Este ușor să adăugați și să schimbați o nouă entitate, dar atunci când o ștergeți, trebuie să distrugeți toate referințele la aceasta din tabelele de linkuri, altfel tabelele de linkuri vor fi incorecte. Multe SGBD-uri moderne blochează acțiunile incorecte în astfel de operațiuni.

Postări tabele de legături sunt destinate să afișeze relații dintre entități, informații despre care se află în tabelele de entități corespunzătoare.

De obicei, un tabel de relații descrie relația dintre două entități. Deoarece tabelele de entități în cel mai simplu caz au fiecare un câmp cheie, tabelul de relații a două tabele trebuie să aibă două chei pentru a asigura unicitatea înregistrărilor relațiilor. Puteți crea un tabel de relații, ca un tabel de obiecte, fără chei, dar apoi funcțiile de monitorizare a unicității înregistrărilor revin utilizatorului.

Relațiile mai complexe (non-binare) ar trebui reduse la cele binare. Pentru a descrie relațiile dintre N obiecte, sunt necesare N-1 tabele de relații. Nu ar trebui să existe conexiuni tranzitive. Un exces de conexiuni duce la contradicții (vezi exemplul relațiilor ANGAJAT-DEPARTAMENT, ANGAJAT-PROIECT și DEPARTAMENT-PROIECT din subsecțiunea anterioară).

Caracteristicile entităților nu trebuie incluse în tabelele de relații, altfel anomaliile sunt inevitabile. Este mai bine să le stocați în tabele de entități separate.

Folosind tabelele de conexiuni, puteți descrie, de asemenea, un tip de conexiune oarecum specific - o conexiune liniară sau o conexiune slabă. Un exemplu de conexiune liniară poate fi considerat relația de apartenență a entităților la o altă entitate de ordin superior (sisteme formate din noduri; medicamente formate din componente; aliaje metalice etc.). În acest caz, un tabel de conexiuni este suficient pentru a descrie conexiunile.

Când lucrați cu tabelele de legături, ar trebui să rețineți că orice intrare din tabelul de legături poate fi ștearsă cu ușurință, deoarece entitățile se pot descurca fără legături pentru o perioadă de timp. Când adăugați sau modificați conținutul înregistrărilor de tabel, trebuie să verificați corectitudinea referințelor la obiecte existente, deoarece o relație nu poate exista fără obiecte. Majoritatea SGBD-urilor moderne controlează corectitudinea referințelor obiectelor.

Sub integritate să înțeleagă proprietatea unei baze de date, ceea ce înseamnă că aceasta conține informații complete, consecvente și care reflectă în mod adecvat informațiile din domeniu.

Distinge fizice și logice integritate. Integritatea fizică înseamnă că există acces fizic la date și că datele nu se pierd. Integritatea logică înseamnă absența erorilor logice în baza de date, care includ încălcarea structurii bazei de date sau a obiectelor acesteia, ștergerea sau modificarea conexiunilor stabilite între obiecte etc. În viitor vom vorbi despre integritatea logică.

Menținerea integrității bazei de date include verificarea (monitorizarea) integrității și restaurarea acesteia dacă sunt detectate inconsecvențe în baza de date. Integritatea bazei de date este setată folosind constrângeri de integritate sub forma unor condiţii care trebuie îndeplinite de datele stocate în baza de date.

Dintre constrângerile de integritate, se pot distinge două tipuri principale de constrângeri: restricții de valoare atribute de relaţie şi restrictii structurale la tupluri de relaţii.

Exemplu restricții de valoare atributele de relație este cerința ca valorile goale sau duplicate în atribute să fie inadmisibile, precum și controlul ca valorile atributelor să aparțină unui interval dat. Astfel, în înregistrările de relații despre personal, valorile atributului Birth_Date nu pot depăși valorile atributului Reception_Date.

Cele mai flexibile mijloace de implementare a controlului asupra valorilor atributelor sunt proceduri stocateȘi declanșatoare, disponibil în unele SGBD.

Restricții structurale definiți cerințele integritatea entităţilorȘi integritatea legăturii. Pentru fiecare instanță de entitate reprezentată într-o relație, există un singur tuplu corespunzător acesteia. Cerinţă integritatea entităţilor este că orice tuplu al unei relații trebuie să fie distins de orice alt tuplu al acestei relații, adică, cu alte cuvinte, orice relație trebuie să aibă o cheie primară.

Formularea cerinței de integritate a legăturii este strâns legată de concept cheie externă. Să ne amintim că cheile străine sunt folosite pentru a conecta relații (tabele de baze de date) între ele. În acest caz, se numește atributul unei relații (părinte). cheie externă a acestei relații, dacă este primar cheia unei alte relații (copil). O relație în care este definită o cheie străină se spune că face referire la o relație în care același atribut este cheia primară.

Integritatea referențială necesită ca pentru fiecare valoare a cheii străine din tabelul părinte, trebuie să existe un rând în tabelul copil cu aceeași valoare a cheii primare. De exemplu, dacă relația R1 conține informații despre angajații departamentului, iar atributul acestei relații Must este cheia primară a relației R2, atunci în această relație pentru fiecare poziție din R1 ar trebui să existe un rând cu salariul corespunzător.

Multe SGBD-uri moderne au instrumente pentru monitorizarea integrității bazei de date.

Baza modelului bazei de date în orice diagramă sunt entitățile și relațiile, care sunt ulterior transformate în tabele și relații de bază de date. Entitățile sunt create atunci când este generată diagrama modelului bazei de date. Reprezentarea vizuală a modelului este o parte integrantă a designului bazei de date, deoarece permite dezvoltatorului să analizeze mai ușor inexactitățile apărute în model și să prezinte modelul într-o formă convenabilă pentru revizuire de către client și alți dezvoltatori.

Pentru a forma elementele diagramei se folosește paleta de elemente („Paletă”, Fig. 3.49), unde se află zona „Date” cu obiecte și conexiuni „Entitate”. Selectarea elementului din paletă „Entitate” va oferi utilizatorului posibilitatea de a crea un obiect „Entitate” pe diagramă, care necesită introducerea numelui entității.

Crearea entităților poate fi implementată și prin meniul contextual al folderului „Pachet...”, unde elementul de meniu „Adăugați obiect de date/entitate” va crea o entitate în arborele proiectului și va oferi dezvoltatorului posibilitatea de a face ca în diagramă, introduceți numele entității (Fig. 3.50).

De asemenea, este posibil să creați entități direct pe diagramă folosind un meniu grafic sensibil la context. Pentru a face acest lucru, trebuie să mutați cursorul mouse-ului peste un spațiu gol din diagramă și să nu îl mutați o perioadă, ceea ce va face să apară o zonă cu pictograme care indică posibilitatea de a crea elemente valide. Pentru modelul de bază de date logică, va fi afișată o singură pictogramă, indicând capacitatea de a crea o entitate. Selectarea acesteia, ca și în cazurile anterioare, va crea o nouă entitate cu o solicitare de a introduce numele acesteia.

În fila de proprietăți a entității „Volumetrii”, dezvoltatorul poate specifica parametrii pentru modificarea numărului de instanțe ale entității în cauză (Fig. 3.51), inclusiv:

• Numărul inițial de rânduri - indică numărul de date (instanțe) care ar trebui adăugate imediat după crearea tabelului;
• Creșterea rândurilor pe lună (adăugarea de instanțe pe lună) - indică câte instanțe trebuie adăugate pe lună;
• Numărul maxim de rânduri ( suma maxima instanțe) - indică numărul maxim de instanțe care pot fi stocate în tabelul descris de entitatea în cauză.

Orez. „3.51. Setarea parametrilor de modificare
indicatori cantitativi ai entitatii

În secțiunea de proprietăți ale entității, printre parametrii filei „General”, dezvoltatorului i se cere să seteze un parametru suplimentar „Persistent”, care determină posibilitatea transformării entității într-un tabel la trecerea de la modelul logic la cel fizic al bazei de date. . Dar toate informațiile despre structura viitoarei baze de date sunt conținute în conexiunile dintre entități și atribute, care se caracterizează printr-un număr semnificativ mai mare de parametri. Folosind fila „Atribute”, puteți crea atribute de entitate și puteți defini parametrii lor principali.

De asemenea, similar cu crearea unei entități, atributele pot fi create în diferite moduri (Fig. 3.52):

• - utilizarea meniului contextual - meniul contextual al entității este utilizat în arborele proiectului, unde puteți selecta un obiect de creat - un atribut, o cheie alternativă, o constrângere etc.;
• - folosirea proprietăților entității - se folosește zona de proprietăți din fila „Atribute”, unde atributele sunt create și specificate cu ajutorul instrumentelor disponibile acolo;

folosind meniul grafic al irisului - se folosește un meniu grafic cu pictograme la trecerea mouse-ului peste o entitate, cu ajutorul căruia se creează o cheie primară și atribute simple cu posibilitatea de a specifica numele atributului.

Puc. 3,52. Exemplu de creare a unui atribut
prin proprietățile entității

Când folosește proprietățile entității, dezvoltatorul din fila „Atribute”, folosind pictograma cu semnul „+”, creează atribute noi, după care trebuie să definească principalii parametri ai atributului creat:

• Nume - numele atributului prin care se determină semnificația semnificativă a datelor descrise;
• Cheie primară - un semn care indică faptul că atributul este un element al cheii primare și trebuie create constrângeri de integritate adecvate pentru acesta;
• Cheie surogat - un semn care indică faptul că atributul nu este un element al domeniului subiectului, ci este necesar pentru lucrul eficient cu baza de date și va conține valori generate automat în conformitate cu regulile de progresie aritmetică;
• Tip (tip) - tipul de date care descrie valorile reprezentate de atribut;
• Length/Precision (mărime/precizie) - o valoare numerică care indică numărul de caractere (octeți) necesar pentru a stoca valoarea maximă pentru atributul descris;
• Scala este o valoare numerică folosită pentru atributele numerice care descrie numărul de cifre după virgulă zecimală atunci când se lucrează cu numere reale;
• Necesar - un semn că este imposibil să stocați o valoare NULL goală la un atribut;
• Derivat (calculat) - semn al necesității de a calcula o valoare dintr-o anumită expresie folosind operații matematice, lingvistice și diverse funcții ale limbajului SGBD;
• Valoare implicită - valoarea care ar trebui scrisă dacă nu au fost specificate date pentru atribut la adăugarea sau modificarea datelor;
• Derivation Expression - O expresie de formulă care trebuie evaluată atunci când datele sunt adăugate sau modificate.

Este important de reținut că instrumentul oferă posibilitatea de a sorta atributele dintr-o entitate în ordinea dorită de dezvoltator. Acest lucru se face folosind pictograme de control sub formă de săgeți multidirecționale. Totuși, dat fiind faptul că regulile lui Codd determină independența ordinii atributelor, stabilirea ordinii nu este o componentă necesară în modelul bazei de date. Există două motive pentru a construi ordinea necesară a atributelor:

Ușurință în utilizare - prin aranjarea ordinii atributelor în funcție de anumite reguli (de exemplu, atributele care indică cheia primară ar trebui să vină mai întâi, apoi cheile străine trebuie plasate, apoi cheia alternativă și atributele simple), este mai ușor să citiți diagramă model și identifică unele situații problematice care pot apărea când munca practica cu o bază de date, utilizarea tehnologiilor speciale de procesare - atunci când adăugați date în limbajul SQL, este posibil să nu specificați lista

zerouri ale tabelului în care vor fi introduse datele specificate în comandă, ceea ce impune dezvoltatorului codului programului să cunoască ordinea exactă a câmpurilor din tabel, care la nivel de model logic poate fi determinată prin atribute de sortare.

Pe lângă specificarea caracteristicilor pentru fiecare atribut, inclusiv specificarea unei valori implicite și a unei expresii formule pentru calcul, orice entitate poate avea constrângeri de integritate pentru a se asigura că valoarea pentru atributul corespunzător este stocată corect. De exemplu, pentru un atribut care stochează valorile anului, este posibil să doriți să limitați valoarea minimă. Deoarece la nivelul construirii unui model logic, dezvoltatorul poate să nu știe ce DBMS va fi utilizat pentru implementare, utilizarea funcțiilor în oricare dintre limbajele de programare nu va fi corectă. Cu toate acestea, instrumentul IBM InfoSphere Data Architect permite dezvoltatorului să specifice condiția de constrângere în mai multe limbi (Figura 3.53):

• OCL (Object Constraint Language) este un limbaj de restricții pentru obiecte, utilizat în reprezentarea orientată pe obiect a datelor și a programelor de aplicație, destul de rar folosit în implementarea bazelor de date relaționale, utilizează expresii logice standard și indicații ale atributelor entității (de exemplu: Entitate >= 2000 ):
• SQL (Structured Query Language) este un limbaj de interogare structurat folosit în procesarea bazelor de date relaționale, de obicei concentrat pe un anumit SGBD și are multe funcții unice doar pentru SGBD selectat, utilizează operații logice (ȘI (ȘI), SAU (SAU), etc. ) și le aplică la nivelul de atribut al entității în cauză (de exemplu: Anul >= 2000 și Anul
• Engleza este un limbaj natural, care nu poate fi tradus într-un limbaj de programare, folosit de obicei pentru a descrie o constrângere și apoi a o reprezenta în timpul programării cu o expresie logică adecvată (de exemplu: Anul este reprezentat printr-o valoare din interval)