Cunoaște Intuit, curs, modelare Infological

Rezumat: se ocupă de curs cu modelele semantice utilizate în cazul sistemelor moderne

Modelul Infological este aplicat în a doua etapă a proiectului bazei de date. adică, după descrierea verbală a zonei subiect. De ce infological modelul si ce beneficii ofera designerilor? Încă o dată vreau să reamintesc faptul că proiectarea unui proces lung, este nevoie de o discuție cu clientul, cu experții din zona de subiect. În cele din urmă, dezvoltarea sistemelor informatice majore corporative, de proiectare a bazei de date este baza pe care să construiască întregul sistem, și problema posibilității de creditare experților băncii de multe ori a decis, pe baza acesteia se face cu competență de bază de date a proiectului infological. În consecință, modelul trebuie să includă infological o descriere formalizată a domeniului. care va fi ușor de „citit“ nu numai experți în bazele de date. Și această descriere ar trebui să fie cât mai concisă, pentru a fi în măsură să aprecieze adâncimea și valabilitatea studiului a bazei de date a proiectului. Și, desigur, așa cum am menționat mai devreme, acesta nu ar trebui să fie legat de o anumită bază de date. Selectarea bazei de date - aceasta este o sarcină separată pentru a aborda în mod corespunzător, este necesar să existe un proiect care nu este legată de nici o anumită bază de date.

Design Infological se datorează în primul rând o încercare de a reprezenta domeniul semantica în modelul bazei de date. Modelul de date relațional datorită simplității și concizia nu permite semantica de afișare, adică, sensul zonei subiect. modele teoretice timpurii grafic afișat din ce în ce domeniu semantic. Ei au definit în mod explicit relațiile ierarhice între domeniul obiectelor.

Problema reprezentării semanticii are dezvoltatori lung interesate, și mai multe dintre aceste modele au fost propuse în anii șaptezeci numite modele semantice. Printre acestea se numără modelul de date semantic. 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 au avantajele și dezavantajele lor, dar a trecut testul timpului, numai ultima. Ș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. A devenit general acceptat abrevierea ER-model, majoritatea CASE-unelte moderne includ instrumente pentru descrierea datelor în formalismul modelului. În plus, tehnicile dezvoltate de proiect automat de conversie de la ER-DB în modelul relațional, conversia se realizează în datalogicheskuyu modelul corespunzător unui anumit DBMS. Toate CASE-au dezvoltat sisteme de 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.

Model „entitate-relație“

Ca orice model, „entitate-relație“ are câteva concepte de bază care formează blocurile de construcție originale ale obiectelor mai complexe deja construite în conformitate cu reguli predefinite.

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 bazat pe ER-model.

În centrul ER-model se bazează pe următoarele concepte de bază:

• Esența, prin care simulate clasă de obiecte similare. Essence are un nume care este unic în cadrul sistemului fiind modelat. Deci, ca esență corespunde unei clase de obiecte similare, se presupune că sistemul are mai multe instanțe ale unei anumite entități. Obiectul, care corespunde noțiunii de natură, are propriul set de atribute - caracteristici care determină proprietățile reprezentantului de clasă. În același set de atribute trebuie să fie de așa natură încât a fost posibil să se facă distincția între instanțe specifice ale entității. De exemplu, entitatea angajat poate fi următorul set de atribute: număr personal, numele, prenumele, data nașterii, numărul de copii, prezența rudelor în străinătate. Un set de atribute care identifică în mod unic un caz particular al esenței. Tasta de apelare .Pentru Angajat atribut al cheii entitate numărul personal este, deoarece pentru toți angajații întreprinderii numere de personal vor fi diferite. entitate angajaților instanță este o descriere a unui anumit angajat al companiei. Unul convențional simboluri grafice entitate - un dreptunghi în partea superioară care conține numele entității și atributele enumerate mai jos, în care atributele cheie marcate, de exemplu, prin sublinierea sau tip special: (Figura 7.1.)

Fig. 7.1. EXEMPLU entitate determinarea în modelul ER

Între entități poate fi stabilită conexiunea - asociații binare. care arată modul în care entitatea corelate sau interacționează. Comunicarea poate exista între două entități diferite sau între esență și ea însăși (relație recursiv) .Se arată modul în care instanțe ale entităților sunt conectate între ele. În cazul în care comunicarea se stabilește între cele două entități, definește relația dintre instanțe ale 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, se va lega "one-to-many" (1: M), unul din "Învățătorul" și multe din "Student" (a se vedea figura 7.2 ..).

Fig. 7.2. Un exemplu al relației „unu-la-multe relații“ în entitate „student“ cu caracter obligatoriu și „profesor“

Diferite capacitate de comunicare notatii este descrisă î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. Pe partea studentului, acest rol este numit „Scrie o diplomă sub îndrumarea“ din partea profesorului, această conexiune este numit „gestionat“. Interpretarea grafică de comunicare vă permite să citiți imediat sensul relației dintre entități, acesta este afișat proeminent și ușor interpretabil. Comunicații sunt împărțite în trei tipuri în funcție de multitudinea de unu la unu (1: 1), unu-la-mulți (1: M), mulți la mai mulți (M: M). One-la-unu relație înseamnă că o instanță a unei entități este asociată cu o singură instanță a unei alte entități. Comunicarea 1: M înseamnă că o singură instanță a unei entități. situată în partea stângă a comunicării poate fi asociat cu mai multe instanțe ale entității situat la conexiunea dreapta. Comunicarea „one-to-one“ (1: 1) înseamnă că o singură instanță a unei entități este asociată cu o singură instanță a celeilalte entități, și să comunice „mulți-la-mulți“ (M: M) înseamnă că o instanță a primei entități poate să fie asociat cu mai multe instanțe ale a doua entitate, și vice-versa, o instanță a doua entitate 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ă cu o varietate de elevi. O astfel de conexiune este prezentată în Fig. 7.3.

Între două entități pot fi date orice număr de relații cu sens diferit. De exemplu, între două entități „student“ și „profesor“ se pot instala două conexiuni semantice, una - considerate anterior „absolvent de design“, iar al doilea poate fi numit în mod condiționat „Lectures“, și determină conferințe, pe care cadrele didactice asculta elevului și cum elevii prelegerilor profesorilor. In mod evident, acest tip de conexiune, Exemplu multe-la-multe relații dintre acestea este prezentată în Fig. 7.3.

Fig. 7.3. Exemplu de simulare de comunicare "multi-to-many"

Comunicarea oricare dintre aceste tipuri poate fi necesară în cazul în care fiecare instanță a unei entități ar trebui să fie implicate în acest sens. opțional - în cazul în care nu toate instanțele unei entități ar trebui să fie implicate în acest sens. Conexiunea poate fi obligatorie pe de o parte, și opțional pe de altă parte .Obyazatelnost comunicarea în diferite moduri, în diferite notări indicate. Noi folosim din nou notația POWER DESIGNER. Aici o legătură opțională este indicată printr-un cerc gol la sfârșitul link-ului, și să fie legat de linia perpendiculară traversează conexiunea. Și această notație are o interpretare simplă. Cercul înseamnă că nici un caz nu poate fi implicat în acest sens. Un perpendiculara este interpretat ca faptul că cel puțin o instanță a unei entități este implicată în acest sens. Pentru aceasta considerăm exemplul menționat anterior comunicării „absolvent de design.“ În ilustrația noastră, această relație este interpretată ca un opțional pe ambele părți. Dar, de fapt, fiecare student care scrie o diplomă, trebuie să aibă capul lor de proiecte de diploma, dar, pe de altă parte, nu fiecare profesor ar trebui să realizeze un design de diplomă. Prin urmare, în acest sens, formularea acestei interconectări se va schimba pentru a arata ca acest lucru, așa cum se arată în Fig. 7.4.

Fig. 7.4. EXEMPLU comunicare obligatorie și opțională între entitățile