40 Charts „entitate - relație» (ERD)

№40 Diagramele „entitate - relație» (ERD). Tipuri de relații (unu-la-unu, unu-la-mulți, mulți-la-mulți). Construirea unei scheme de baze de date pe baza diagramelor ERD

Scopul de modelare a datelor - oferă dezvoltatorilor EIS schema bazei de date conceptuală sub forma uneia sau a mai multor modele de modele locale, care pot fi relativ ușor mapate la orice sistem de baze de date.

Cele mai frecvente mijloace de diagrame de modelare a datelor sunt „entitate-relație“ (ERD). Notarea care a fost introdus pentru prima dată de Peter Chen în 1976 și a fost dezvoltată în continuare în lucrările lui Richard Barker. Diverse mijloace CASE utilizare ușor diferite unele de altele ERD notație. Una dintre cele mai comune notațiile oferite Barker (Oracle Designer). În SilverRun CASE-instrument utilizează o variantă a notației Chen. Metodologia CASE-instrument ERwin, ER / Studio, Design / IDEF utilizat IDEF 1X.

MetodologiyaIDEF1H a fost dezvoltat pentru armata SUA și este utilizat pe scară largă în agențiile guvernamentale, corporații financiare și industriale. Este dezvoltarea de metodologii IDEF 1, dar concentrat mai mult pe automatizare și mai simplu de înțeles. Acesta vă permite să construiască un model de date, echivalent cu modelul relațional, normalizat la a treia formă normală.

Diagrame „entitate-relație“ (ERD) sunt destinate pentru dezvoltarea modelelor de date și să ofere o modalitate standard de a defini datele și relațiile dintre ele.

De fapt, folosind ERD efectuat detaliind sistem proiectat de stocare a datelor, precum și sistem de esență documentat și modul în care acestea interacționează, inclusiv identificarea obiectelor importante pentru domeniul subiect (entitate), proprietățile acestor obiecte (atribute) și relația lor cu alte obiecte (obligațiuni).

Această tehnică diagrama utilizată în principal pentru proiectarea bazelor de date relaționale (deși pot fi aplicate cu succes și pentru modelarea bazelor de date ierarhice și de rețea).

Diagrame „entitate-relație“ includ:

Modelarea structurii bazei de date folosind algoritmul descris în normalizării capitolele anterioare, are dezavantaje serioase:

  1. plasarea inițială a tuturor atributelor într-un singur sens este o operațiune foarte nenatural. Intuitiv, dezvoltatorul proiectează încă o dată relații în conformitate cu entitățile detectate. Chiar dacă comite violența împotriva celuilalt și de a crea una sau mai multe relații pentru a include toate atributele așteptate, este sensul destul de neclar al acestei relații.
  2. Este imposibil să se determine imediat lista de atribute. Oamenii au obiceiul de apel nume diferite același lucru, sau invers, pentru a numi câteva nume de lucruri diferite.
  3. Pentru normalizarea procedurilor necesare pentru a aloca în conformitate cu atributele, care este, de asemenea, foarte ușor, deoarece trebuie să scrie în mod explicit toate dependențele. chiar și cele care sunt evidente.

În proiectarea reală a structurii bazei de date utilizată o altă metodă - așa-numita modelare semantică. Modelarea semantic este structuri de date de modelare bazate pe sensul datelor. În diverse aplicații concrete diagramele entitate-relație (- Entitate-Relație ER) sunt utilizate ca instrument de modelare semantic.

Vom descrie lucrul cu ER-diagrame aproape de notație Barker este destul de ușor să înțeleagă ideile principale. Acest capitol este mai degrabă o ilustrare a metodelor de modelare semantică decât o introducere completă în acest domeniu.

Concepte de bază ale ER-diagrame

Definiție 1. Esența - o clasă de obiecte similare, informații cu privire la care ar trebui să fie luate în considerare în model.

Fiecare entitate trebuie să aibă un nume, exprimat printr-un substantiv la singular.

Exemple de entități pot fi astfel de clase de obiecte ca „furnizor“, „Angajat“, „factură“.

Fiecare entitate din modelul descris sub forma unui dreptunghi cu numele:

Definiție 2. O copie a esenței - este un reprezentant concret al entității.

De exemplu, un reprezentant al entității „angajat“ poate fi „Ofițer Smith“.

Copiile entitate trebuie să fie distinse. și anume entitatea trebuie să aibă anumite proprietăți care sunt unice pentru fiecare instanță a entității.

3. entitate Atribut Definiție - o caracteristică pe nume, care este o proprietate entitate.

Atributul name trebuie să fie exprimat într-un substantiv singular (eventual cu caracterizarea adjective).

Exemple de entități atribute „Angajat“ poate fi atribute, cum ar fi „numărul de personal“, „Numele“, „Nume“, „Orientul Mijlociu“, „Position“, „salariu“, etc.

Atributele sunt reprezentate în interiorul dreptunghiului care definește esența:

4. Determinarea spiritului cheie - un set de non-redundante de atribute, care valorile în combinație sunt unice pentru fiecare instanță entitate. Irredundancy constă în faptul că eliminarea oricărui atribut al cheii rupe unicitatea lui.

O entitate poate avea mai multe chei diferite.

Atributele cheie sunt reprezentate în diagrama prin subliniere:

Definiția 5. Comunicarea - aceasta este o anumită asociere între cele două entități. O entitate poate fi legată de o altă entitate sau ea însăși.

Conexiunile permit o singură entitate pentru a găsi alte entități asociate cu acesta.

De exemplu, relațiile dintre entități poate fi exprimată prin următoarea frază -. „Angajat poate avea mai multe copii“, „Fiecare angajat este obligat să fie înregistrate exact în același departament“

Link-ul reprezentat de grafic o linie care leagă cele două entități:

Fiecare legătură are două capete, și unul sau două nume. Numele este de obicei exprimat în formă verbală nedefinită „au“, „proprii“, etc. Fiecare dintre elementele se referă la o conexiune de capăt. Uneori, numele nu sunt scrise din cauza lor evidenei.

Fiecare conexiune poate avea una dintre următoarele tipuri de comunicare.

Tipul de relație, unu-la-unu înseamnă că o instanță a primei entități (stânga) este asociată cu o singură instanță a doua entitate (dreapta). Unu-la-unu indică adesea că, de fapt, avem doar o singură esență, incorect împărțit în două.

Comunicarea de tip unu-la-multe înseamnă că o instanță a primei entități (stânga) este asociat cu mai multe instanțe ale doua entitate (dreapta). Acesta este cel mai frecvent utilizat tip de comunicare. entitate stânga (de la „unu“) este părintele. dreapta (de la „mulți“) - o filială. Un exemplu tipic de astfel de conexiune este prezentată în Fig. 4.

tip de comunicare multi-la-multe relații înseamnă că fiecare instanță a primei entități pot fi asociate cu mai multe instanțe ale doua entitate și fiecare instanță a doua entitate poate fi asociată cu instanțe multiple ale primei entități. tip de comunicare multi-la-multe relație este un tip de conexiune temporară, valabilă în primele etape ale modelului de dezvoltare. În viitor, acest tip de comunicare ar trebui să fie înlocuită cu două tipuri de relații unu-la-mulți prin crearea unei entități intermediare.

Fiecare conexiune poate avea una din cele două modalități de comunicare.

Modality „poate“ înseamnă că o instanță de entitate poate fi asociată cu una sau mai multe instanțe ale celeilalte entități, și nu poate fi asociat cu nici o instanță.

Modul de „ar trebui“ înseamnă că o instanță a unei entități este obligat să fie asociat cu cel puțin o instanță a unei alte entități.

Comunicarea poate fi de diferite modalități cu diferite capete (așa cum este prezentat în Fig. 4).

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

De la stânga la dreapta: „Fiecare angajat poate avea mai multe copii.“

De la dreapta la stânga: „Fiecare copil trebuie să aparțină exact un angajat.“

Un exemplu al dezvoltării unui simplu ER-model de

In dezvoltarea ER-modele, avem nevoie pentru a obține următoarele informații despre domeniu:

  1. Lista entităților de domeniu.
  2. Lista entităților atribute.
  3. Descrierea relației dintre entități.

ER-diagrame sunt convenabile în care entitățile de eliberare proces, atribute și relații este iterativ. Dezvoltarea prima versiune a diagramei aproximative, le rafineze, intervievarea expertii in domeniu. În această documentație, care înregistrează rezultatele interviurilor sunt ER-diagrame.

Să presupunem că sarcina noastră este de a dezvolta un sistem de informații cu privire la ordinul unei societăți comerciale en-gros. În primul rând trebuie să examinăm zona subiect și procesele care au loc în ea. În acest scop, am intervievat angajații companiei, citiți documentația, studiu sub forma de comenzi, facturi, etc.

De exemplu, în timpul unei conversații cu un manager de vânzări, a arătat că el (managerul) a spus că sistemul proiectat trebuie să îndeplinească următoarele etape:

  • Stoca informații despre clienți.
  • Imprima facturi pentru bunuri vândute.
  • Pentru a monitoriza disponibilitatea produselor din stoc.

Selectați toate substantivele din aceste propuneri - va fi potențiali candidați pentru entități și atribute, și de a le analiza (termen ciudat, vom lua un semn de întrebare):

  • Cumpărătorul - un candidat evident pentru entitate.
  • Scrisoare de trăsură - un candidat evident pentru entitate.
  • Produse - un candidat evident pentru esența
  • Depozit (?) - și, în general, cât de multe magazine au de companie? În cazul în care mai mult de unul, acesta va fi un candidat pentru noua entitate.
  • Disponibilitatea produselor (?) - este de natură să atribuie, dar atributul care entitate?

Odată ce există o legătură clară între entitățile - „cumpărătorii pot cumpăra o mulțime de bunuri“ și „produsele sunt vândute mulți clienți.“ Primul exemplu de realizare diagramă este după cum urmează:

Pune o întrebare managerului, am constatat că firma are mai multe depozite. Mai mult decât atât, fiecare produs pot fi stocate în mai multe depozite, și care urmează să fie vândute la orice magazin.

În cazul în care pentru a pune esența „factură“ și „depozit“ și ce se asociază? Întrebați-vă modul în care aceste entități sunt legate între ele și cu esența „client“ și „produs“? Cumpărători cumpăra bunuri, în timp ce primesc facturi, în care sunt incluse datele privind numărul și prețul bunurilor achiziționate. Fiecare client poate primi câteva facturi. este necesar Fiecare lot să fie evacuate de la un client. Fiecare factură trebuie să conțină mai multe produse (nu există nici un gol deasupra capului). Fiecare element, la rândul său, pot fi vândute la mai mulți cumpărători în unele deasupra capului. De asemenea, fiecare proiect de lege care urmează să fie evacuate cu un anumit tip și la orice stocare poate fi scris mult deasupra capului. Astfel, după clarificare, graficul va arăta în felul următor:

Este timpul să se gândească la atributele entității. Vorbind cu personalul companiei, am constatat următoarele:

În cursul conversației în continuare cu managerul am fost în măsură să clarifice conceptul de prețuri diferite. Sa dovedit că fiecare produs are un anumit preț curent. Acest preț la care produsul este vândut în acest moment. Desigur, acest preț se poate schimba în timp. Prețul acelorași bunuri în diferite proiect de lege, emise în momente diferite, pot varia. Astfel, există două prețuri - prețul mărfurilor în scrisoarea de trăsură și prețul curent al mărfurilor.

Cu concept de „Lista de mărfuri din lot nota“ este destul de clar. Essence „factură“ și „produs“ asociat relație unele cu altele, cum ar fi multi-la-mulți. O astfel de relație, așa cum am menționat mai devreme, ar trebui să fie împărțită în două tipuri de comunicare este unu-la-mulți. Acest lucru necesită o entitate suplimentară. Aceasta este esența esenței și „Lista de produse în lot.“ legătura sa cu esența „factură“ și „produs“ se caracterizează prin următoarea frază - „fiecare factură este necesară pentru a avea mai multe intrări în lista mărfurilor în scrisoarea de trăsură“, „fiecare intrare în lista mărfurilor în scrisoarea de trăsură trebuie să conțină exact o singură factură“, „fiecare element poate fi inclus mai multe înregistrări din lista mărfurilor în scrisoarea de trăsură „“ este necesară fiecare intrare în lista mărfurilor în scrisoarea de trăsură care urmează să fie asociat cu exact un singur element. " Atributele „numărul de mărfuri în scrisoarea de trăsură“ și „Prețul mărfurilor în scrisoarea de trăsură“ sunt atributele esenței „a mărfurilor în lista lot“.

În mod similar vom continua cu legătura ce leagă esența „depozit“ și „produs“. Introducem mai multe substanțe „Produsul este în stoc.“ Atribut al acestei entități va fi „numărul de produse din stoc.“ Astfel, produsul va fi listat pe orice stoc, iar valoarea acesteia la fiecare stoc va fi a lui.

Acum puteți face toate acestea într-o diagramă:

Conceptual si fizic ER-model de

Prezentat mai sus exemplu ER diagrame ale unui exemplu de diagramă conceptuală. Acest lucru înseamnă că graficul nu ține cont de caracteristicile specifice ale SGBD. Conform acestei diagrame conceptuale, puteți construi o diagramă fizică. care are astfel de caracteristici vor fi considerate ca SGBD tipuri de permise și nume de câmpuri și tabele, constrângeri de integritate, etc. O versiune fizică a diagramei din Fig. 9 pot să apară, de exemplu, după cum urmează:

În această diagramă fiecare entitate este un tabel de baze de date, fiecare atribut devine coloană a tabelului corespunzător. Vă rugăm să acorde o atenție faptului că, în multe tabele, de exemplu, „CUST_DETAIL“ și „PROD_IN_SKLAD“, în spiritul „Record Custodie List“ și „Produsul este în stoc,“ există noi atribute care nu erau în modelul conceptual - o cheie de atribute tabele părinte migrat la tabelele de copil pentru a oferi o legătură între tabele cu ajutorul tastelor străine.

Este ușor de observat că tabelul rezultat imediat sunt în 3NF.

mijloace reale de modelare a datelor nu este o metodă formală de normalizare a relațiilor și așa-numita modelare semantică.

În diverse aplicații concrete diagramele entitate-relație (- Entitate-Relație ER) sunt utilizate ca instrument de modelare semantic.

diagrame entitate-relație vă permit să utilizați notația grafică intuitivă pentru modelarea entităților și relațiile lor.

Distinge între ER diagrame conceptuale și fizice. Diagrama conceptuală nu ia în considerare caracteristicile specifice ale bazei de date. diagrame fizice construite în conformitate cu conceptual și reprezintă transformarea dintr-o anumită bază de date. În esență, unele sunt tabele, atribute devin coloane de tabel în diagrama conceptuală (deci considerate valabile pentru un anumit tip de date Baze de date și nume de coloane), comunicațiile se realizează prin migrarea atributele cheie ale entității-mamă și pentru a crea chei străine.

Odată cu stabilirea corectă a tabelului entității obținut va fi în curând în 3NF. Principalul avantaj al metodei este că modelul este construit de rafinări succesive ale topurilor originale.

În acest capitol, care ilustrează metodele ER simulările nu sunt discutate în aspecte mai complexe de diagrame, cum ar fi subtipuri rol se opun comunicării intolerabil comunicare identificarea datorate etc.