Model de date infologice „entitate-relație”. Modelul informațional entitate-relație al bazelor de date

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 folosit în forma sa pură din cauza complexității procesării textului computerizat și a 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 un anumit tip de entitate, dar poate fi același pentru diferite tipuri de entitate (de exemplu, CULOARE poate fi definită pentru mai 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 automobile, 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- un set minim de atribute ale căror valori pot fi folosite pentru a găsi fără ambiguitate instanța necesară a unei entități. Minimalitatea î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.

Rezumat: Model infologic al bazelor de date „Entitate-relație”

Model infologic bazele Date entitate-relație

Noțiuni de bază

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 un anumit tip de entitate, dar poate fi același pentru diferite tipuri de entitate (de exemplu, CULOARE poate fi definită pentru mai 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.

Cheie– un set minim de atribute ale căror valori pot fi folosite pentru a găsi în mod unic instanța necesară a unei entități. Minimalitatea î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ȚIA [ENTITATEA S1, ENTITATEA 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) Rabdator ( Număr de înregistrare, Număr pat, Nume, Nume, patronimic, adresă, data nașterii, sex) Attending_doctor [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. Oficiul de Stare Civilă (ZAGS) 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, Numele de mijloc al soțului, Data nașterii_soțului, Numele de familie al 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

Numarul certificatului	Numele de familie al soțului	...	Numele de familie al soției	...	Data Înregistrării
1-YUB 154745	Petukhov		Kurochkina		06/03/1991
1-YUB 163489	Petukhov		Pestrușkina		11/08/1991
1-UB 169887	Petukhov		Ryabova		12/12/1992
1-UB 169878	Seleznev		Utochkina		12/12/1992
1-YUB 154746	Parasiuk		Svinyushkina		06/03/1991
1-UB 169879	Parasiuk		Khavroniya		12/12/1992

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ții).

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

Cod_M	Nume de familie	Nume	Nume de familie	Anul/b.	Locul nașterii
	Petukhov	Alfred	Ostapovici	1971	Tsapelka
	Seleznev	Vavila	Abramovici	1973	Gusev
	Parasiuk	Horaţiu	Fedolovici	1972	Svinyin

Tabelul 2.3

Numarul certificatului	Cod_M	Numele de familie al soției	Numele soției	Data Înregistrării	...
1-YUB 154745		Kurochkina	Augustin	06/03/1991
1-YUB 163489		Pestrușkina	Mariana	11/08/1991
1-UB 169877		Ryabova	Milano	12/12/1992
1-UB 169878		Utochkina	Veronica	12/12/1992
1-YUB 154746		Svinyushkina	Elvira	06/03/1991
1_UB 169879		Khavroniya	Rufina	12/12/1992

Exemplul 2.4.În cele din urmă, luați în considerare cazul în care o organizație avea nevoie de date despre prezența cuplurilor căsătorite în ea și exista deja o entitate care să stocheze informații despre angajați

Angajati ( Număr de personal, Ultimul nume primul nume, ...).

Utilizarea entității „Căsătorie” discutată în exemplul 2.2 este inadecvată: „Angajații” conține deja numele de familie, prenumele și patronimele soților. Prin urmare, să creăm o asociație

Căsătoria [Angajat 1, Angajat 1] (Număr_personal_soț, număr_personal_soție, ...),

conectarea anumitor instanțe ale entității „Angajați” (Fig. 2.1,d).

În concluzie, observăm că diagrama ER Fig. 2.1a descrie structura de plasare a datelor privind căsătoriile în oficiile de înregistrare ale țărilor care permit căsătorii în grup, iar diagramele ER din exemplul 2.1 descriu orice tip de căsătorie în organizații în care există entități „bărbați” și „femei”, inclusiv singuri și persoane necăsătorite.

Ce este „conexiune”? În diagramele ER, aceasta este o linie care conectează forme geometrice reprezentând entități, atribute, asociații și alte obiecte informaționale. În text, acest termen este folosit pentru a indica interdependența entităților. Dacă această interdependență are atribute, atunci se numește asociere.

Clasificarea entităților

A sosit momentul să înțelegem terminologia. K. Data definește trei clase principale de entități: tijă, asociativȘi caracteristică, precum și o subclasă de entități asociative – denumiri.

Esența de bază (nucleu) este o entitate independentă (va fi definită mai detaliat mai jos).

În exemplele discutate mai devreme, tijele sunt „Student”, „Apartament”, „Bărbați”, „Doctor”, „Căsătorie” (din exemplul 2.2) și altele, ale căror nume sunt plasate în dreptunghiuri.

Entitate asociativă (asociere) este o relație multi-la-mulți ("-la-mulți", etc.) între două sau mai multe entități sau instanțe ale unei entități (ca în Exemplul 2.4). Asociațiile sunt tratate ca entități cu drepturi depline:

pot participa la alte asociații și desemnări la fel ca entitățile de bază;

poate avea proprietăți, adică au nu numai un set de atribute cheie necesare pentru a indica relațiile, ci și orice număr de alte atribute care caracterizează relația. De exemplu, asociațiile „Căsătorie” din exemplele 2.1 și 2.4 conțin atributele cheie „Cod_M”, „Cod_Zh” și „Numărul personalului soțului”, „Numărul personalului soției”, precum și atributele clarificatoare „Numărul certificatului”, „Data înregistrării” , „Locul de înregistrare”, „Numărul de înscriere în cartea registraturii”, etc.

Entitate caracteristică (caracteristică) este o relație multi-la-unu sau unu-la-unu între două entități (un caz special de asociere). Singurul scop al unei caracteristici din domeniul subiectului luat în considerare este de a descrie sau clarifica o altă entitate. Necesitatea acestora apare din cauza faptului că entitățile din lumea reală au uneori proprietăți cu mai multe valori. Un soț poate avea mai multe soții (exemplul 2.3), o carte poate avea mai multe caracteristici ale unei retipăriri (corectate, extinse, revizuite, ...) etc.

Existența unei caracteristici depinde în întregime de entitatea care este caracterizată: femeile își pierd statutul de soție dacă le moare soțul.

Pentru a descrie caracteristica, se folosește o nouă propunere JIM, care are, în general, forma:

CARACTERISTICA (atributul 1, atributul 2, ...) (LISTA ENTITATILOR CARACTERIZATE).

Să extindem și limbajul diagramelor ER prin introducerea unui trapez pentru a reprezenta caracteristicile (Fig. 2.2).

Orez. 2.2. Elemente ale limbajului de diagramă ER extins

Entitatea care desemnează sau desemnare este o relație „mulți-la-unu” sau „unu-la-unu” între două entități și diferă de o caracteristică prin aceea că nu depinde de entitatea desemnată.

Să luăm în considerare un exemplu legat de înscrierea angajaților în diferite departamente ale organizației.

În lipsa unor reguli stricte (un angajat poate fi înscris simultan în mai multe departamente sau să nu fie înscris în niciun departament), este necesar să se creeze o descriere cu asociația Înscriere:

Angajații (număr de personal, nume, ...) Înscriere [Departamente M, Angajați N] (Numărul departamentului, Numărul personalului, Data înscrierii).

Cu toate acestea, cu condiția ca fiecare angajat să fie înscris într-unul dintre departamente, puteți crea o descriere cu denumirea de Angajați:

Departamente (numărul departamentului, numele departamentului, ...) Angajații (număr de personal, nume, ..., număr departament, Data înscrierii)[Departamente]

În acest exemplu, angajații au o existență independentă (dacă un departament este șters, nu înseamnă că și angajații acelui departament ar trebui șters). Prin urmare, ele nu pot fi caracteristici ale departamentelor și se numesc desemnări.

Notațiile sunt folosite pentru a stoca valori repetate ale atributelor de text mari: „codificatori” disciplinelor studiate de studenți, numele organizațiilor și departamentele acestora, liste de bunuri etc.

Descrierea unei denumiri diferă din exterior de descrierea unei caracteristici doar prin aceea că entitățile desemnate sunt incluse nu între paranteze, ci între paranteze drepte:

NOTĂ (atribut 1, atribut 2, ...)[LISTA ENTITĂȚI DEsemnate].

De obicei, desemnările nu sunt tratate ca entități complete, deși acest lucru nu ar duce la nicio eroare.

Denumirile și caracteristicile nu sunt entități complet independente, deoarece presupun existența unei alte entități care va fi „desemnată” sau „caracterizată”. Cu toate acestea, ele reprezintă încă cazuri speciale ale unei entități și pot avea, desigur, proprietăți, pot participa la asociații, desemnări și au propriile lor caracteristici (nivel inferior). De asemenea, subliniem că toate instanțele unei caracteristici trebuie să fie asociate cu o anumită instanță a entității caracterizate. Cu toate acestea, este permis ca unele instanțe ale entității caracterizate să nu aibă relații. Adevărat, dacă aceasta se referă la căsătorii, atunci esența „Soților” ar trebui înlocuită cu esența „Bărbaților” (nu există soț fără soție).

Să redefinim acum entitatea de bază ca o entitate care nu este nici o asociere, nici o desemnare, nici o caracteristică. Astfel de entități au existență independentă, deși pot desemna alte entități, cum ar fi angajații desemnează departamente.

În concluzie, să luăm în considerare un exemplu de construire a unui model informativ al bazei de date „Nutriție”, în care informațiile despre feluri de mâncare (Fig. 2.3), consumul zilnic al acestora, produsele din care sunt preparate aceste feluri de mâncare și furnizorii acestor produse ar trebui să fi depozitat. Informațiile vor fi folosite de bucătarul și managerul unei mici unități de catering, precum și de vizitatorii acesteia.

Orez. 2.3. Exemplu de rețetă

Cu ajutorul acestor utilizatori au fost identificate următoarele obiecte și caracteristici ale bazei proiectate:

Mâncăruri care necesită date incluse în rețetele lor culinare pentru a descrie: numărul felului de mâncare (de exemplu, dintr-o carte de rețete culinare), numele felului de mâncare, tipul preparatului (aperitiv, supă, fel principal etc.), rețetă (tehnologie pentru pregătirea preparatului), randamentul (greutatea porției), denumirea, conținutul caloric și greutatea fiecărui produs inclus în preparat.
Pentru fiecare furnizor de produse: numele, adresa, numele produsului furnizat, data livrarii si pretul la momentul livrarii.
Consumul zilnic de alimente (consum): fel de mâncare, număr de porții, data.

Analiza obiectelor ne permite să evidențiem:

tulpini Mâncăruri, produse și orașe;
asociații Compoziție (legături Vase cu Produse) și

Consumabile (conectează Furnizorii cu Produse);

desemnarea Furnizorilor;
caracteristici Reţete şi Consum.

Diagrama ER a modelului este prezentată în Fig. 2.4. iar modelul în limbajul YAM are următoarea formă:

Feluri de mâncare (BL, Dish, View) Produse (PR, produs, conținut caloric) Furnizori (POS, oraș, furnizor) [oraș] Compoziție [Vafuri M, Produse N] (BL, PR, Greutate (g)) Consumabile [Furnizori M, Produse N] (POS, PR, Data_P, Preț, Greutate (kg)) Orașe (oraș, țară) Rețete (BL, Rețetă) (Mâncăruri) Consum (BL, Data_R, Porții) (Văcare)

În aceste modele, Dish, Product și Supplier sunt nume, iar BL, PR și POS sunt coduri digitale ale vaselor, produselor și organizațiilor care furnizează aceste produse.

Orez. 2.4. Modelul infologic al bazei de date „Nutriție”.

Despre cheile primare și externe

Să ne amintim asta cheie sau posibil indiciu este un set minim de atribute ale căror valori pot fi folosite pentru a găsi fără ambiguitate instanța necesară a unei entități. Minimalitatea înseamnă că excluderea oricărui atribut din set nu permite identificarea entității de către cele rămase. Fiecare entitate are cel puțin o cheie posibilă. Unul dintre ei este luat ca cheia principala. Atunci când alegeți o cheie primară, ar trebui să acordați preferință cheilor non-compozite sau cheilor formate dintr-un număr minim de atribute. De asemenea, este nepotrivit să folosiți chei cu valori de text lungi (sunt de preferat atributele întregi). Astfel, pentru a identifica un elev, puteți utiliza fie un număr unic de carte de înregistrare, fie un set de nume, prenume, patronim, număr de grup și, eventual, atribute suplimentare, deoarece este posibil ca doi elevi (și mai des eleve). ) cu aceleași nume de familie, prenume și patronimice. De asemenea, este rău să folosiți ca cheie nu numărul felului de mâncare, ci numele acestuia, de exemplu, „Aperitiv de brânză prelucrată „Prietenie” cu șuncă și castraveți murați” sau „Iepure în smântână cu crochete de cartofi și salată de varză roșie. .”

Cheia primară a unei entități de bază (orice atribut care participă la cheia primară) nu are voie să aibă o valoare nedefinită. În caz contrar, va apărea o situație contradictorie: va apărea o instanță non-individuală, și deci inexistentă, a esenței de bază. Din aceleași motive, este necesar să se asigure unicitatea cheia principala.

Acum despre chei externe:

Dacă entitatea C leagă entitățile A și B, atunci trebuie să includă chei străine corespunzătoare cheilor primare ale entităților A și B.
Dacă entitatea B se referă la entitatea A, atunci trebuie să includă o cheie externă corespunzătoare cheii primare a entității A.

În paragraful 2.3, s-a luat în considerare un exemplu în care „Angajații” a indicat „Departamente” și a inclus o cheie străină „Numărul departamentului” corespunzătoare cheii primare a entității „Departamente”.

Relația dintre cheile primare și cele externe ale entităților este ilustrată în Fig. 2.5.

Orez. 2.5. Structuri: a - asociaţii; b - denumiri (caracteristici)

Aici, pentru a desemna oricare dintre entitățile asociate (nuclee, caracteristici, desemnări sau chiar asociații), se folosește un nou termen de generalizare „Obiectiv” sau „Entitate țintă”.

Astfel, atunci când luăm în considerare problema alegerii modului de reprezentare a asociațiilor și notațiilor într-o bază de date, întrebarea principală la care trebuie să se răspundă este: „Ce sunt cheile străine?” Și apoi, pentru fiecare cheie externă, trebuie rezolvate trei întrebări:

1. Poate această cheie străină să accepte valori nedefinite (valori NULL)? Cu alte cuvinte, poate exista vreo instanță a unei entități de un anumit tip pentru care entitatea țintă indicată de cheia externă este necunoscută? În cazul proviziilor, acest lucru probabil nu este posibil - o aprovizionare de la un furnizor necunoscut sau o furnizare a unui produs necunoscut nu are sens. Dar în cazul angajaților, o astfel de situație ar putea avea totuși sens - este foarte posibil ca vreun angajat să nu fie înscris în prezent în niciun departament. Rețineți că răspunsul la această întrebare nu depinde de capriciul designerului bazei de date, ci este determinat de cursul real de acțiune adoptat în acea parte a lumii reale care urmează să fie reprezentată în baza de date în cauză. Remarci similare sunt relevante pentru problemele discutate mai jos.

2. Ce ar trebui să se întâmple când încercați să ștergeți o entitate țintă la care se face referire printr-o cheie străină? De exemplu, la ștergerea unui furnizor care a efectuat cel puțin o livrare. Există trei posibilități:

CASCADE	Operația de ștergere este „în cascadă” pentru a șterge și proviziile de la acest furnizor.
LIMITAT.	Sunt șterși doar acei furnizori care nu au efectuat încă livrări. În caz contrar, operația de ștergere este respinsă.
INSTALAT	Pentru toate livrările furnizorului care sunt eliminate, valoarea NULL a cheii externe este setată la nedefinit și apoi furnizorul este eliminat. Această caracteristică, desigur, nu este aplicabilă dacă cheia externă nu trebuie să conțină valori NULL.

3. Ce ar trebui să se întâmple când încercați să ACTUALIZAȚI cheia primară a unei entități țintă la care se referă o cheie străină? De exemplu, se poate încerca actualizarea numărului unui furnizor pentru care există cel puțin o livrare corespunzătoare. Pentru claritate, vom analiza din nou acest caz mai detaliat. Aveți aceleași trei opțiuni ca atunci când ștergeți:

CASCADE	Operațiunea de actualizare este „în cascadă” pentru a actualiza și cheia externă din consumabilele furnizorului respectiv.
LIMITAT.	Se actualizează cheile primare doar ale acelor furnizori care nu au efectuat încă livrări. În caz contrar, operațiunea de actualizare este respinsă.
INSTALAT	Pentru toate livrările acelui furnizor, valoarea NULL a cheii externe este setată la nedefinită, iar apoi cheia primară a furnizorului este actualizată. Această caracteristică, desigur, nu este aplicabilă dacă cheia externă nu trebuie să conțină valori NULL.

Astfel, pentru fiecare cheie străină dintr-un design, proiectantul bazei de date trebuie să specifice nu numai câmpul sau combinația de câmpuri care alcătuiește acea cheie străină și tabelul țintă care este identificat prin acea cheie, ci și răspunsurile la întrebările de mai sus ( trei constrângeri care se aplică acestei chei străine).

În sfârșit, despre caracteristici - entități denotatoare, a căror existență depinde de tipul de entități denotate. Desemnarea este reprezentată de o cheie străină în tabelul corespunzătoare acelei caracteristici. Dar cele trei constrângeri ale cheii externe discutate mai sus pentru acest caz ar trebui specificate după cum urmează:

Valorile NULL nu sunt permise ȘTERAREA DIN (țintă) CASCADE UPDATE (cheie primară țintă) CASCADES

Specificațiile specificate reprezintă dependența de existența entităților caracteristice.

Constrângeri de integritate

Integritate(din engleza integritate - intactness, inviolabilitate, siguranta, integritate) - se intelege drept corectitudinea datelor in orice moment. Dar acest obiectiv poate fi atins doar în anumite limite: SGBD nu poate controla corectitudinea fiecărei valori introduse în baza de date (deși fiecare valoare poate fi verificată pentru plauzibilitate). De exemplu, nu se poate descoperi că valoarea de intrare 5 (reprezentând ziua săptămânii) ar trebui să fie de fapt 3. Pe de altă parte, valoarea 9 ar fi în mod clar o eroare și ar trebui respinsă de SGBD. Cu toate acestea, pentru a face acest lucru, ar trebui să i se spună că numerele zilelor săptămânii trebuie să aparțină setului (1,2,3,4,5,6,7).

Menținerea integrității bazei de date poate fi considerată ca protejarea datelor împotriva modificărilor sau distrugerii neautorizate (a nu se confunda cu modificările și distrugerea neautorizate, care reprezintă o problemă de securitate). SGBD-urile moderne au o serie de mijloace pentru a asigura menținerea integrității (precum și mijloace pentru a asigura menținerea securității).

Există trei grupuri de reguli de integritate:

Integritatea entității.
Integritate referenţială.
Integritate definită de utilizator.

În secțiunea 2.4, a fost luată în considerare motivația pentru două reguli de integritate care sunt comune oricăror baze de date relaționale.

Orice atribut care participă la o cheie primară nu are voie să aibă o valoare nedefinită.
Valoarea cheii externe trebuie să fie:

să fie egală cu valoarea cheii primare a țintei;
fi complet nesigur, adică Fiecare valoare de atribut care participă la o cheie străină trebuie să fie nulă.

Pentru orice bază de date specifică, există o serie de reguli specifice suplimentare care se aplică numai acesteia și sunt determinate de dezvoltator. Cel mai adesea controlat:

unicitatea anumitor atribute,
intervalul de valori (scorul examenului de la 2 la 5),
aparținând unui set de valori (genul „M” sau „F”).

Despre construirea unui model informativ

Un cititor care s-a familiarizat doar cu materialul din acest capitol și din capitolele precedente nu va putea percepe și evalua corect acele sfaturi și recomandări pentru construirea unui model de informare bun, care au fost dezvoltate de-a lungul deceniilor de cei mai mari specialiști în domeniul procesarea datelor. Pentru a face acest lucru, trebuie să studiați cel puțin următoarele materiale. În mod ideal, este necesar ca cititorul să implementeze mai întâi cel puțin un proiect de sistem informatic, să îl ofere utilizatorilor reali și să fie un administrator de baze de date și de aplicații suficient de mult pentru a realiza cel puțin o mică parte din problemele care apar dintr-o gândire insuficientă. design afară. Experiența autorului și a tuturor specialiștilor în sisteme informatice pe care îi cunoaște arată că orice recomandări teoretice sunt luate în serios doar după mai multe încercări nereușite de a reînvia sistemele prost proiectate. (Deși există și designeri care continuă să creadă că pot reînvia un proiect pe moarte schimbând programe, mai degrabă decât prin schimbarea modelului infologic al bazei de date.)

Într-adevăr, pentru a determina lista și structura datelor stocate, este necesar să colectați informații despre aplicațiile reale și potențiale, precum și despre utilizatorii bazei de date, iar atunci când construiți un model de informații, ar trebui să vă pese doar de fiabilitatea stocării acestor date, uitând complet de aplicațiile și utilizatorii pentru care se creează baza de date.

Acest lucru se datorează cerințelor complet diferite pentru baza de date a programatorilor de aplicații și administratorul bazei de date. Primii ar dori să aibă într-un singur loc (de exemplu, într-un singur tabel) toate datele de care au nevoie pentru a implementa o solicitare dintr-un program de aplicație sau dintr-un terminal. Aceștia din urmă se ocupă de eliminarea eventualelor distorsiuni ale datelor stocate atunci când introduc informații noi în baza de date și actualizează sau șterge informațiile existente. Pentru a face acest lucru, ei elimină duplicatele și relațiile funcționale nedorite dintre atribute din baza de date, împărțind baza de date în multe tabele mici (vezi secțiunea 4.6). Întrucât mulți ani de experiență globală în utilizarea sistemelor informatice construite pe baza de baze de date arată că defectele de proiectare nu pot fi eliminate prin niciun truc din programele de aplicație, designerii experimentați nu își permit să întâlnească programatorii de aplicații la jumătate (chiar și atunci când ei înșiși sunt astfel).

distinge clar între concepte precum solicitarea de date și menținerea datelor (introducerea, modificarea și ștergerea);
amintiți-vă că, de regulă, o bază de date este baza de informații nu a uneia, ci a mai multor aplicații, dintre care unele vor apărea în viitor;
un design prost de bază de date nu poate fi corectat de nicio aplicație (chiar și cele mai sofisticate).

LITERATURĂ

Atre S. Abordarea structurală a organizării bazelor de date. – M.: Finanțe și Statistică, 1983. – 320 p.
Boyko V.V., Savinkov V.M. Proiectarea bazelor de date sisteme informatice. – M.: Finanțe și Statistică, 1989. – 351 p.
Data K. Ghid pentru SGBD-ul relațional DB2. – M.: Finanțe și Statistică, 1988. – 320 p.
Jackson G. Proiectarea bazelor de date relaționale pentru utilizare cu microcalculatoare. -M.: Mir, 1991. – 252 p.
Kirillov V.V. Limbajul de interogare structurat (SQL). – Sankt Petersburg: ITMO, 1994. – 80 p.
Martin J. Planificarea dezvoltării sistemelor automatizate. – M.: Finanțe și Statistică, 1984. – 196 p.
Meyer M. Teoria bazelor de date relaţionale. – M.: Mir, 1987. – 608 p.
Tiori T., Fry J. Design of database structures. În 2 cărţi, - M.: Mir, 1985. Carte. 1. – 287 p.: Carte. 2. – 320 s.
Ullman J. Baze de date în Pascal. – M.: Inginerie mecanică, 1990. – 386 p.
Hubbard J. Design automatizat de baze de date. – M.: Mir, 1984. – 294 p.

Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

postat pe http://www.allbest.ru/

Infologicmodeldate„Conexiune-entitate”

2.1 Concepte de bază

Modelul entitate-relație a fost propus de cercetătorul american de baze de date Peter Chen în 1976. De atunci, a fost extins și modificat atât de Chen însuși, cât și de mulți alți cercetători. În diferite versiuni, a devenit parte a multor instrumente automate pentru a sprijini proiectarea sistemelor informaționale. În prezent, nu există un standard unic pentru acest model, dar există un set de modele comune care stau la baza majorității variantelor sale. Vom studia aici aceste construcții generale.

Există multe sisteme diferite pentru construirea modelelor ER.

Desigur, nu intenționăm să le studiem pe toate. Nu este necesar. După ce stăpânesc conceptele de bază ale modelului ER și principiile construcției diagramelor într-un sistem de notație, nu este dificil să înțelegem niciunul.

Indiferent de sistemele utilizate, diagrama ER reflectă clar și precis reprezentare autor O date . Prin urmare, este o sursă bună de informații pentru proiectantul modelului de date logice. Sunt foarte utile atunci când discutați despre cerințele de date cu utilizatorii finali.

2.2 Elemente ER - modele

model de date de entitate infologică

Elementele de bază ale modelelor informaționale sunt entitățile, conexiunile dintre acestea și proprietățile (atributele) acestora.

2.2.1 Esența

O entitate este un obiect alocat ( identificabile) de către utilizator în domeniul subiectului.

Ceva pe care un utilizator ar dori să observe și să stocheze observațiile (date). De exemplu,

STUDENT Petrov,

PROFESOR Lomov,

MANUAL DB,

PUBLIC,

ACTIVITĂȚI DE INSTRUIRE pentru grupuri etc.

Din exemple reiese clar că entitățile pot fi persoane, obiecte, locuri, evenimente etc. Pentru a generaliza, putem spune că o esență este ceva care are o existență reală (fizică) sau conceptuală și se distinge în lumea înconjurătoare.

Din pacate, formaldefinițiiacestconcepteNuexistă. Cel puțin pentru azi.

Entitățile de același tip formează Clasă esență sau tip esență .

Este necesar să se facă distincția între concepte precum tip esență (Clasă esență ) Și copie esență . 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.

STUDENT este un tip sau o clasă de entitate care are aceeași seturi caracteristici, ale căror valori sunt de interes pentru utilizator (care). Utilizatorul este interesat de informații despre copii clasă. De exemplu, despre studenții care studiază în prezent la Departamentul de PM.

Astfel, un tip de entitate este o abstractizare, concept alocate de utilizator. În mintea utilizatorului, conceptul este comparat simbol- numele entității (vom conveni pe viitor să scriem numele entităților cu majuscule). Acest simbol are o semnificație foarte specifică, totuși, o persoană fără experiență nu îl poate transmite întotdeauna folosind alte simboluri. Mai mult, persoane diferite pot atribui semnificații diferite aceluiași simbol.

De exemplu, ideile despre STUDENT pe care le are deputatul. decanul, profesorul și doamna de curățenie sunt diferite.

Pentru deputat Decanul este o persoană repartizată prin ordin al rectorului unui anumit grup. Una dintre responsabilitățile deputatului. decan – monitorizează progresul acestei persoane în toate etapele procesului de învățare. Aceasta determină setul de informații despre această persoană pe care deputatul ar dori să le aibă. decan.

Pentru un profesor, ELEV este o persoană care are dreptul să-și frecventeze cursurile și este obligată să raporteze într-un anumit interval de timp asupra rezultatelor studierii disciplinelor predate de profesor.

Pentru o doamnă de la curățenie, un STUDENT este o mulțime de oameni fără chip, care târăște murdăria de pe stradă, scuipă peste tot, umple toate camerele cu gunoaie, fac zgomot fără sens pe coridoare și îngreunează fluturatul cu mopul.

În literatură termenul „ esență"ca în" tip esență", și în sensul de " copie esență" La fel vom face atunci când nu va provoca neînțelegeri.

2.2.2 Atribut

Atribut este o caracteristică numită a unei entități (o proprietate a tipului de entitate) care este semnificativă din punctul de vedere al utilizatorului.

Numele său trebuie să fie unic pentru un anumit tip de entitate, dar poate fi același pentru diferite tipuri de entitate (de exemplu, CULOARE poate fi definită pentru mai multe entități: CAR, TEXT 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.

Un atribut are, de asemenea, o distincție între tip și instanță, cu o singură valoare de atribut atribuită fiecărei instanțe a unei entități.

De exemplu:

Tipul de atribut COLOR are multe instanțe sau valori:

Roșu, Albastru etc.

Orice atribut este un atribut 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 automobile, culoarea este doar un atribut al produsului de producție, dar pentru o fabrică de vopsele și lacuri, culoarea este un tip de entitate.

Exemple: numărul biletului de student, Numele profesorului, Titlul manualului, Client și așa mai departe.

Atributul poate fi simplu, ca primele trei. Valorile lor aparțin unor tipuri de date simple.

Poate fi compus, de exemplu (Numele clientului, adresa clientului, numărul de telefon al clientului)

Rețineți că decizia dacă un atribut este simplu sau compus depinde de nivelul de detaliu care este acceptabil pentru utilizator. De exemplu, AudienceNumber poate fi considerat un atribut simplu dacă utilizatorul este destul de mulțumit de valorile șirului precum ` 227rk", `418 grăsime", `411gl".

Atributul poate fi derivat. De exemplu, atributele entității GROUP pot include atributul Numărul de grupuri . Valoarea sa pentru fiecare instanță de GROUP poate fi calculată numărând numărul de instanțe ale entității STUDENT asociate cu acea instanță.

cometariu. Valorile atributelor derivate sunt stocate în baza de date în cazuri excepționale. Cu toate acestea, în timpul fazei de proiectare, toate aceste atribute de interes pentru utilizator trebuie identificate și descrise.

Cheie - un set minim de atribute ale căror valori pot fi folosite pentru a găsi fără ambiguitate instanța necesară a unei entități. Minimalitatea înseamnă că excluderea oricărui atribut din set nu permite identificarea entității de către cele rămase.

Pentru entitate Programatrenuri cheia este atributul Număr_tren sau setați: (Punct de plecare,Timp de plecareȘiDestinaţie).

A evidentia unic chei (chei potențiale) și neunic. Valoarea unei chei unice nu poate apărea în două cazuri ale unei entități. Indică o singură instanță ( numărul biletului de student, Numărul de audiență ). Valoarea unei chei non-unice indică un set de instanțe ( Numele de familie al profesorului = Ivanov indică toată predarea lui Ivanov la universitate).

Cheia poate să nu fie un atribut de entitate. De exemplu, Data angajarii sau Denumirea funcției Este puțin probabil ca profesorii să fie folosiți pentru a identifica profesorii.

O entitate poate avea mai multe chei unice și neunice.

Atributul nu este permis numi o cheie unică de entitate. Fie el este ca atare, sau Nu este.

2.2.4 Comunicare

Conexiune este o caracteristică a relației dintre 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.

Ca și în cazul entităților și atributelor, modelul ER diferă tipuri (clase) Și copii conexiuni.

DescriereentitatiȘial lorconexiuni-AcestȘiExistă(CupuncteviziuneproiectantDB)principalPartemodelecerințeutilizatorLadate.

Cu toate acestea, instrumentele de limbaj natural nu sunt foarte potrivite pentru descriere, în primul rând din cauza naturii lor greoaie și a vizibilității slabe. Orice model non-trivial va conține zeci de modele similare cu cele de mai sus. În acest set de propuneri este dificil de identificat toate conexiunile în care intră aceeași entitate, este dificil de urmărit lanțurile de conexiuni care sunt implicate în tranzacții etc. Sunt necesare instrumente lingvistice speciale pentru a reprezenta modelul.

2.3 Clasificarea entităților și a relațiilor. Sisteme de desemnare a modelului ER

Ideea lui Chen, care l-a făcut un nume cunoscut în cercurile de proiectare a bazelor de date, este aceea esență Și comunicatii ar trebui să introduce grafic. Apoi, modelul cerințelor utilizatorului va fi compact și clar. Există Grozavo multime desistemenotaţiePentrureprezentareModele ER. Nu există un standard. Ne vom ține de cele mai comune notații.

Postat pe Allbest.ru

Documente similare

Construirea unui model informativ al unui program de testare bazat pe un manual electronic pentru testarea cunoștințelor elevilor. Modelarea infologică și reprezentarea semantică a unui subiect într-o bază de date. Modelul entitate-relație și relațiile dintre entitățile identificate.