Rezumat: Prelegerea este dedicată modelelor semantice utilizate în sistemele CASE moderne
Modelul de informare este folosit în a doua etapă a proiectării bazei de date. adică după o descriere verbală a domeniului. De ce avem nevoie de un model infologic și ce beneficii le oferă designerilor? Încă o dată, dorim să vă reamintim că procesul de proiectare este lung, necesită discuții cu clientul, cu experți în domeniu. În cele din urmă, atunci când se elaborează sisteme grave de informare corporativă, proiectul bazei de date este fundația pe care se construiește întregul sistem, iar problema posibilei împrumuturi este adesea hotărâtă de experții băncii pe baza unui proiect de baze de date infologificate. Prin urmare, modelul infologic ar trebui să includă o astfel de descriere formalizată a zonei subiectului. care vor fi citite cu ușurință nu numai de către specialiștii bazei de date. Și această descriere ar trebui să fie atât de mare încât să fie posibil să se evalueze profunzimea și corectitudinea dezvoltării proiectului bazei de date. și bineînțeles, așa cum am menționat mai sus, nu ar trebui să fie legată de o anumită bază de date. Alegerea unui DBMS este o sarcină separată, pentru soluția sa corectă este necesar să aveți un proiect care nu este legat de niciun DBMS anume.
Designul infolog este asociat în primul rând cu o încercare de a reprezenta semantica domeniului în modelul bazei de date. Modelul de date relaționale, datorită simplității și laconismului său, nu ne permite să afișăm semantică, adică sensul domeniului subiect. Modelele grafice teoretice timpurii au reflectat mai ales semantica domeniului subiect. Au definit explicit legături ierarhice între obiectele din domeniu.
Problema reprezentării semanticii a fost de mult interesată de dezvoltatori, iar în anii șaptezeci au fost propuse mai multe modele de date, numite modele semantice. Acestea includ modelul semantic de date. a propus Hammer (Ciocan) și Mac-Leon (McLeon) în 1981, modelul de date funcțional Shipman (Shipman), de asemenea, creat în 1981, modelul de "entitate-relație" propusă de Chen (Chen), în 1976, și un număr de alte modele . Toate modelele aveau laturile lor pozitive și negative, dar numai ultimul a fost testul timpului. Și în acest moment este un model de Chen „entitate-relație“ sau „Entitate Relationship“, a devenit standardul de facto pentru modelarea bazelor de date Infological. Modelul abreviat ER-model a devenit comun, cele mai moderne instrumente CASE conțin instrumente pentru descrierea datelor în formalismul acestui model. În plus, s-au dezvoltat metode pentru conversia automată a unui proiect de bază de date de la un model ER la unul relațional, iar transformarea este efectuată într-un model de date corespunzător unui anumit DBMS. Toate sistemele CASE au dezvoltat instrumente pentru documentarea procesului de dezvoltare a bazei de date. generatoare de rapoarte automate permit să pregătească un raport privind stadiul actual al bazei de date a proiectului, cu o descriere detaliată a obiectelor bazei de date și relațiile lor într-o formă grafică și sub formă de rapoarte standard tipărite gata făcute, care facilitează foarte mult managementul proiectului.
În momentul de față, nu există o singură notație general acceptată pentru ER-model și de diferite CASE-sisteme utilizează notația grafică diferită, dar înțeleasă într-un singur loc, ușor de înțeles, și alte notatii.
Modelul entitate-relație
Ca orice model, modelul entitate-relație are mai multe concepte de bază care formează blocurile de construcție originale, din care obiecte mai complexe sunt construite conform unor reguli predeterminate.
Acest model este cel mai în concordanță cu conceptul de design orientat-obiect, care în acest moment este, fără îndoială, baza pentru dezvoltarea de sisteme software complexe, atât de multe concepte s-ar putea parea familiare, iar dacă acest lucru este adevărat, atunci cu atât mai ușor va fi de a stăpâni tehnologia de proiectare a bazei de date pe baza modelului ER.
Bazele modelului ER sunt următoarele concepte de bază:
- Esența prin care este modelată o clasă de obiecte similare. Entitatea are un nume unic în cadrul sistemului simulat. Deoarece entitatea corespunde unei anumite clase de obiecte similare, se presupune că există multe instanțe ale acestei entități în sistem. Un obiect care corespunde noțiunii de entitate are un set propriu de atribute - caracteristici care definesc proprietățile unui reprezentant dat al clasei. În acest caz, setul de atribute trebuie să fie astfel încât să se poată distinge anumite instanțe ale entității. De exemplu, un angajat poate avea următorul set de atribute: Număr de personal, Nume de familie, Prenume, Patronimic, Data nașterii, Numărul de copii, Prezența rudelor în străinătate. Un set de atribute care identifică în mod unic o instanță a entității specifice. Cheia angajatului va fi atributul numărului de personal, deoarece pentru toți angajații acestei întreprinderi numerele de personal vor fi diferite. Instanța angajatului Angajatul va descrie angajatul specific al întreprinderii. Unul dintre simbolurile comune ale entității este un dreptunghi cu numele entității din partea de sus a acesteia, iar atributele sunt enumerate mai jos, atributele cheie fiind marcate, de exemplu, cu un subliniere sau un font special (a se vedea Figura 7.1):
Fig. 7.1. Exemplu de definiție a entității în modelul ER
Între entități se pot stabili legături - asociații binare. care arată modul în care entitățile se raportează sau interacționează între ele. O conexiune poate exista între două entități diferite sau între o entitate și ea însăși (o relație recursivă), care arată modul în care instanțele entității sunt legate între ele. Dacă se stabilește o conexiune între două entități, atunci ea definește relația dintre instanțele uneia și celeilalte entități. De exemplu, dacă avem o legătură între esența „student“ și esența „profesor“ și această conexiune - proiecte de diploma de management, fiecare student are un singur cap, dar același profesor poate conduce o mulțime de studenți absolvent. Prin urmare, va fi o relație unu-la-multe (1: M), una din partea "Profesor" și multe din partea "Student" (a se vedea figura 7.2).
Fig. 7.2. Exemplu de relație one-to-many când se leagă entitățile "Student" și "Profesor"
În diferite notații puterea de comunicare este reprezentată în moduri diferite. În exemplul nostru, vom folosi sistemul de notație CASE POWER DESIGNER, reprezentată aici printr-o multitudine de linii de separare datorate 3. Comunicarea este numele comun „absolvent de design“ și are un nume de rol din ambele entități. Din partea elevului, acest rol este numit "Scrierea unei diplome sub îndrumarea", din partea profesorului această legătură se numește "Gestionează". Interpretarea grafică a conexiunii vă permite să citiți imediat semnificația relației dintre entități, este clar și ușor de interpretat. Legăturile sunt împărțite în trei tipuri prin multiplicitate: unul la unul (1: 1), unul la mulți (1: M), mulți la mulți (M: M). O relație one-to-one înseamnă că o instanță a unei entități este asociată cu o singură instanță a unei alte entități. Comunicarea 1: M înseamnă că există o instanță a entității. situat în partea stângă de link, poate fi asociat cu mai multe instanțe ale entității situate în partea dreaptă de link. Unu-la-unu (1: 1) înseamnă că o instanță a unei entități este asociată cu o singură instanță a unei alte entități și o relație multiplă (M: M) înseamnă că o instanță a primei entități să fie asociat cu instanțe multiple ale celei de-a doua entități și invers, o instanță a celei de-a doua entități poate fi asociată cu mai multe instanțe ale primei entități. De exemplu, dacă luăm în considerare relația de „învățare“ între „Student“ entități și „disciplina“, este o relație de „mulți-la-mulți“ (M: M), astfel încât fiecare elev poate învăța mai multe discipline, dar fiecare disciplină este studiat de o mulțime de studenți. O astfel de relație este prezentată în Fig. 7.3.
Fig. 7.3. Un exemplu de modelare a relației multi-la-multe
Fig. 7.4. Un exemplu de comunicare obligatorie și opțională între entități
Articole similare
Trimiteți-le prietenilor: