Zostavte modelovú politickú geografickú mapu vzťahu entity. Model prepojenia entít. Atribút, hodnota a súbor hodnôt

Prvky modelu vzťahu entít

Modelovanie štruktúry databázy pomocou normalizačného algoritmu opísaného v predchádzajúcich kapitolách má vážne nevýhody:

Prvé umiestnenie všetkých atribútov do rovnakého vzťahu je veľmi neprirodzená operácia. Vývojár intuitívne navrhuje niekoľko vzťahov naraz v súlade s objavenými entitami. Aj keď sa dopustíte násilia na sebe a vytvoríte si jeden alebo viacero vzťahov, vrátane všetkých údajných atribútov, zmysel výsledného vzťahu je úplne nejasný.

Nie je možné okamžite určiť úplný zoznam atribútov. Používatelia majú tendenciu nazývať rovnaké veci rôznymi menami, alebo naopak, nazývať rôzne veci rovnakými menami.

Na vykonanie normalizačného postupu je potrebné vybrať závislosti atribútov, čo je tiež veľmi ťažké, pretože nevyhnutné výslovne vypíšte všetky závislosti, dokonca aj tie, ktoré sú zrejmé.

Pri reálnom návrhu štruktúry databázy sa používa iná metóda - tzv. sémantické modelovanie ... Sémantické modelovanie je modelovanie dátovej štruktúry založené na význame týchto dát. Ako nástroj sémantického modelovania sa používajú rôzne možnosti entitno-vzťahové diagramy (ER - Entity-Relationship ).

Prvú verziu modelu entita-vzťah navrhol v roku 1976 Peter Ping-Sheng Chen. Neskôr mnohí autori vyvinuli svoje vlastné verzie takýchto modelov (Martinova notácia, IDEF1X notácia, Barkerova notácia atď.). Okrem toho sa rôzne softvérové ​​nástroje, ktoré implementujú rovnakú notáciu, môžu líšiť vo svojich schopnostiach. V skutočnosti sú všetky varianty diagramov entít a vzťahov založené na jednej myšlienke - kresba je vždy jasnejšia ako textový popis. Všetky takéto diagramy využívajú grafické znázornenie doménových entít, ich vlastností (atribútov) a vzťahov medzi entitami.

Opíšeme prácu s ER diagramami blízkymi Barkerovmu zápisu ako pomerne ľahko pochopiteľnú na základných myšlienkach. Táto kapitola je skôr ilustráciou techník sémantického modelovania ako úplným úvodom do tejto oblasti.

Základné pojmy ER diagramov

Definícia 1. Podstatou je trieda objektov rovnakého typu, informácie o ktorých je potrebné brať do úvahy v modeli.

Každá entita musí mať podstatné meno v jednotnom čísle.

Príkladmi entít môžu byť také triedy objektov ako „Dodávateľ“, „Zamestnanec“, „Faktúra“.

Každá entita v modeli je znázornená ako obdĺžnik s názvom:

Ryža. 1

Definícia 2. Inštancia entity - ide o konkrétneho zástupcu tohto subjektu.

Napríklad zástupcom entity „Zamestnanec“ môže byť „Zamestnanec Ivanov“.

Inštancie entity musia byť rozlíšiteľné, t.j. entity musia mať nejaké vlastnosti, ktoré sú jedinečné pre každú inštanciu tejto entity.

Definícia 3. Atribút entity je pomenovaná charakteristika, ktorá je nejakou vlastnosťou entity.

Názov atribútu by mal byť vyjadrený v jednotnom čísle podstatného mena (prípadne s charakteristickými prídavnými menami).

Príkladmi atribútov entity „Zamestnanec“ môžu byť atribúty ako „Osobné číslo“, „Priezvisko“, „Krstné meno“, „Patronym“, „Pozícia“, „Plat“ atď.

Atribúty sa kreslia v rámci obdĺžnika definujúceho entity:

Ryža. 2

Definícia 4. Kľúč entity - toto je nadbytočný súbor atribútov, ktorých hodnoty sú kolektívne jedinečný pre každú inštanciu entity. Neredundancia spočíva v tom, že odstránením akéhokoľvek atribútu z kľúča sa poruší jeho jedinečnosť.

Entita môže mať niekoľko rôznych kľúčov.

Kľúčové atribúty sú v diagrame zobrazené podčiarknutím (alebo je vedľa kľúčového atribútu nakreslený znak kľúča):

Ryža. 3

Definícia 5. Pripojenie je nejaký druh asociácie medzi dva subjektov. Jedna entita môže byť spojená s inou entitou alebo sama so sebou.

Vzťahy umožňujú jednej entite nájsť ďalšie entity, ktoré s ňou súvisia.

Vzťahy medzi entitami môžu byť vyjadrené napríklad nasledovnými frázami – „ZAMESTNANEC môže mať viacero DETÍ“, „každý ZAMESTNANEC musí byť uvedený práve v jednom ODDELENÍ“.

Vzťah je graficky znázornený čiarou spájajúcou dve entity:

Ryža. 4

Každý odkaz má dva konce a jeden alebo dva názvy. Meno sa zvyčajne vyjadruje v neurčitom slovesnom tvare: „mať“, „patriť“ atď. Každý z mien odkazuje na iný koniec odkazu. Niekedy sa mená nepíšu, pretože sú zrejmé.

Každý odkaz môže mať jednu z nasledujúcich možností typy komunikácie :

Ryža. 5

Typ odkazu jeden na jedného znamená, že jedna inštancia prvej entity (vľavo) je spojená s jednou inštanciou druhej entity (vpravo). Vzťah jedna k jednej najčastejšie naznačuje, že v skutočnosti máme len jednu entitu, nesprávne rozdelenú na dve.

Typ odkazu jeden k mnohým znamená, že jedna inštancia prvej entity (vľavo) je spojená s viacerými inštanciami druhej entity (vpravo). Toto je najpoužívanejší typ komunikácie. Volá sa ľavá entita (z "jednej" strany). rodič , vpravo (zo strany "veľa") - dcérska spoločnosť ... Typický príklad takéhoto zapojenia je na obr. 4.

Typ odkazu mnoho-k-mnohým znamená, že každá inštancia prvej entity môže byť spojená s viacerými inštanciami druhej entity a každá inštancia druhej entity môže byť spojená s viacerými inštanciami prvej entity. Typ vzťahu mnoho k mnohým je dočasné typ vzťahu, ktorý je prijateľný v počiatočných štádiách vývoja modelu. V budúcnosti musí byť tento typ vzťahu nahradený dvoma vzťahmi typu one-to-many vytvorením medzičlánku.

Každá väzba môže mať jednu z dvoch komunikačné modality :

Ryža. 6

modalita" možno môže súvisieť s jednou alebo viacerými inštanciami inej entity, možno nie je pripojený so žiadnym.

modalita" by mal "znamená, že inštancia jednej entity musí byť spojený aspoň s jedným inštancia inej entity.

Komunikácia môže mať odlišná modalita z rôznych koncov (ako na obr. 4).

Opísaná grafická syntax umožňuje jednoznačnečítať diagramy pomocou nasledujúcej frázovej konštrukčnej schémy:

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

Každý odkaz je možné čítať zľava doprava, ako aj sprava doľava. Odkaz na obr. 4 znie takto:

Zľava doprava: "každý zamestnanec môže mať viacero detí."

Sprava doľava: "Každé dieťa musí patriť presne jednému zamestnancovi."

Príklad vývoja jednoduchého modelu ER

Pri vývoji modelov ER by sme mali dostať nasledujúce informácie o predmetnej oblasti:

Zoznam doménových entít.

Zoznam atribútov entity.

Popis vzťahov medzi entitami.

ER diagramy sú vhodné, pretože proces extrakcie entít, atribútov a vzťahov je iteratívny. Po vytvorení prvej približnej verzie diagramov ich spresňujeme rozhovormi s odborníkmi na danú problematiku. V tomto prípade dokumentáciou, v ktorej sú zaznamenané výsledky rozhovorov, sú samotné diagramy ER.

Predpokladajme, že stojíme pred úlohou vyvinúť informačný systém, ktorý si objednal nejaký veľkoobchodník. V prvom rade si musíme naštudovať predmetnú oblasť a procesy v nej prebiehajúce. Za týmto účelom vedieme rozhovory so zamestnancami spoločnosti, čítame dokumentáciu, študujeme objednávky, faktúry atď.

Napríklad počas rozhovoru s manažérom predaja sa ukázalo, že on (manažér) verí, že navrhnutý systém by mal vykonávať nasledujúce akcie:

Uchovávajte informácie o zákazníkoch.

Tlač faktúr za uvoľnený tovar.

Sledujte dostupnosť tovaru na sklade.

Vyberme všetky podstatné mená v týchto vetách - budú to potenciálni kandidáti na entity a atribúty a analyzujme ich (nezrozumiteľné výrazy zvýrazníme otáznikom):

Zákazník

Prepravný list je jasným kandidátom na subjekt.

Produkt- jasný kandidát na subjekt

(?)Sklad- vo všeobecnosti, koľko skladov má firma? Ak ich bude viacero, tak to bude kandidát na nový subjekt.

(?) Dostupnosť produktu- toto je s najväčšou pravdepodobnosťou atribút, ale atribút ktorej entity?

Okamžite sa vynorí zjavné prepojenie medzi subjektmi – „kupujúci si môže kúpiť veľa tovaru“ a „tovar možno predať mnohým kupujúcim“. Prvá verzia diagramu vyzerá takto:

Ryža. 7

Po dodatočných otázkach manažérovi sme zistili, že spoločnosť má viacero skladov. Okrem toho môže byť každý produkt skladovaný v niekoľkých skladoch a môže byť predávaný z akéhokoľvek skladu.

Kde majú byť umiestnené entity „Faktúra“ a „Sklad“ a s čím ich prepojiť? Položme si otázku, ako tieto entity súvisia medzi sebou a s entitami „Kupujúci“ a „Produkt“? Kupujúci nakupuje tovar, pričom dostáva faktúry, ktoré obsahujú údaje o množstve a cene kupovaného tovaru. Každý zákazník môže dostať niekoľko dodacích listov. Každá faktúra musí byť vystavená pre jedného kupujúceho. Každá faktúra musí obsahovať viacero tovarov (neexistujú prázdne faktúry). Každú položku je možné predať viacerým zákazníkom prostredníctvom viacerých dodacích listov. Navyše, každá faktúra musí byť vystavená z konkrétneho skladu a veľa faktúr môže byť vystavených z akéhokoľvek skladu. Po objasnení teda bude diagram vyzerať takto:

Ryža. osem

Je čas premýšľať o atribútoch entity. Pri rozhovore so zamestnancami spoločnosti sme zistili nasledovné:

Každý kupujúci je právnická osoba a má meno, adresu, bankové spojenie.

Každý produkt má názov, cenu a je tiež charakterizovaný mernými jednotkami.

Každá faktúra má jedinečné číslo, dátum vystavenia, zoznam tovaru s množstvom a cenami, ako aj celkovú sumu faktúry. Prepravný list je vystavený z konkrétneho skladu a pre konkrétneho zákazníka.

Každý sklad má svoj názov.

Poďme si opäť napísať všetky podstatné mená, ktoré budú potenciálnymi atribútmi a analyzovať ich:

Entita- rétorický výraz, nepracujeme s jednotlivcami. Nevenujte pozornosť.

Meno kupujúceho

Adresa- jasná charakteristika kupujúceho.

Bankové údaje- jasná charakteristika kupujúceho.

Názov produktu- explicitná charakteristika produktu.

(?) Cena produktu- Zdá sa, že ide o charakteristiku produktu. Líši sa táto funkcia od ceny na faktúre?

jednotka merania- explicitná charakteristika produktu.

Číslo faktúry- jasná jedinečná charakteristika nákladného listu.

Dátum vystavenia faktúry- výslovná charakteristika nákladného listu.

(?) Zoznam tovaru vo faktúre- zoznam nemôže byť atribút. Pravdepodobne budete musieť tento zoznam rozdeliť do samostatnej entity.

(?) Množstvo tovaru vo faktúre je zrejmá vlastnosť, ale charakteristika čoho? Toto je charakteristika nielen „tovaru“, ale aj „tovaru na faktúre“.

(?) Cena tovaru vo faktúre- opäť by to nemala byť len charakteristika produktu, ale charakteristika produktu uvedená v nákladnom liste. Ale cena produktu sa už stretla s vyššou - je to to isté?

Fakturovaná suma- výslovná charakteristika nákladného listu. Táto vlastnosť nie je nezávislá. Fakturovaná suma sa rovná súčtu hodnôt všetkého tovaru zahrnutého na faktúre.

Názov skladu- jasná charakteristika skladu.

Počas dodatočného rozhovoru s manažérom sa podarilo objasniť rôzne pojmy cien. Ukázalo sa, že každý produkt má určitú aktuálnu cenu. Toto je cena, za ktorú sa položka momentálne predáva. Prirodzene, táto cena sa môže časom meniť. Cena toho istého produktu v rôznych faktúrach vystavených v rôznych časoch sa môže líšiť. Existuje teda dve ceny- cena tovaru vo faktúre a aktuálna cena tovaru.

So vznikajúcim konceptom „Zoznam tovaru vo faktúre“ je všetko celkom jasné. Entity Faktúra a Produkt sú navzájom prepojené vzťahom mnoho k mnohým. Takýto vzťah, ako sme už uviedli, musí byť rozdelený do dvoch vzťahov jeden k mnohým. To si vyžaduje ďalšiu entitu. Touto entitou bude entita „Zoznam tovaru vo faktúre“. Jej prepojenie s entitami „Faktúra“ a „Tovar“ je charakterizované nasledovnými frázami – „každá faktúra musí mať viacero záznamov zo zoznamu tovaru vo faktúre“, „každý záznam zo zoznamu tovaru vo faktúre musí obsahovať práve v jednej faktúre“, „každý tovar môže byť zaradený do viacerých záznamov zo zoznamu tovaru vo faktúre“, „každý záznam zo zoznamu tovaru vo faktúre musí byť spojený práve s jednou položkou“. Atribúty „Množstvo tovaru na faktúre“ a „Cena tovaru na faktúre“ sú atribútmi entity „Zoznam tovaru na faktúre“.

Urobme to isté so vzťahom spájajúcim entity Sklad a Produkt. Predstavme si doplnkový subjekt „Tovar na sklade“. Atribút tohto subjektu bude „Množstvo tovaru na sklade“. Tovar bude teda zaradený v akomkoľvek sklade a množstvo v každom sklade bude iné.

Teraz to všetko môžete pridať do diagramu:

Ryža. deväť

Koncepčné a fyzikálne modely ER

Príklad ER diagramu vyvinutý vyššie je príkladom koncepčný diagram ... To znamená, že diagram neberie do úvahy vlastnosti konkrétneho DBMS. Z tohto konceptuálneho diagramu môžete stavať fyzikálny diagram , ktorý už bude brať do úvahy také vlastnosti DBMS, ako sú prípustné typy a názvy polí a tabuliek, obmedzenia integrity atď. Fyzická verzia diagramu znázornená na obr. 9 môže vyzerať takto:

Ryža. desať

V tomto diagrame je každá entita databázovou tabuľkou, každý atribút sa stáva stĺpcom zodpovedajúcej tabuľky. Upozorňujeme, že v mnohých tabuľkách, napríklad „VLASTNÝ_DETAIL“ a „PROD_IN_SKLAD“, zodpovedajúcich entitám „Zápis v zozname faktúr“ a „Položka na sklade“, sa objavili nové atribúty, ktoré neboli v konceptuálnom modeli – to sú kľúčové atribúty rodičovské tabuľky, migroval do podriadených tabuliek s cieľom poskytnúť prepojenia medzi tabuľkami prostredníctvom cudzích kľúčov.

Je ľahké vidieť, že výsledné tabuľky sú okamžite v 3NF.

závery

Skutočným nástrojom na modelovanie údajov nie je formálna metóda normalizácie vzťahov, ale tzv sémantické modelovanie .

Ako nástroj sémantického modelovania sa používajú rôzne možnosti entitno-vzťahové diagramy (ER - Entity-Relationship ).

Diagramy vzťahov entít vám umožňujú používať vizuálne grafické symboly na modelovanie entít a ich vzťahov.

Rozlišovať koncepčný a fyzické ER diagramy. Koncepčné diagramy nezohľadňujú špecifiká konkrétnych DBMS. Fyzické diagramy sú založené na konceptuálnych diagramoch a predstavujú prototyp špecifickej databázy. Entity definované v koncepčnom diagrame sa stávajú tabuľkami, atribúty stĺpcami tabuliek (toto zohľadňuje dátové typy a názvy stĺpcov, ktoré sú povolené pre daný DBMS), prepojenia sú implementované migrácie kľúčové atribúty nadradených entít a vytváranie cudzích kľúčov.

Pri správnom definovaní entít budú výsledné tabuľky okamžite umiestnené v 3NF. Hlavnou výhodou metódy je, že model je konštruovaný metódou postupného spresňovania počiatočných diagramov.

Táto kapitola, ktorá ilustruje techniky modelovania ER, sa nezaoberá zložitejšími aspektmi tvorby grafov, ako sú podtypy, neprepájajúce roly, neprenosné prepojenia, identifikačné prepojenia atď.

Anotácia: Táto prednáška pojednáva o definícii domény pre dátové sklady, metóde modelovania „entita-vzťah“, normálnych formách vzťahov, procese normalizácie entít modelu „entita-vzťah“, sú uvedené príklady konštruovania entitno-relačných diagramov.

Účel prednášky

Po preštudovaní materiálu tejto prednášky budete vedieť:

• definícia predmetná oblasť Databáza
• čo tvorí databázu;
• základné štruktúry a prvky logického databázového modelu;
• čo je šesť normálne vzťahy ;
• spôsoby, ako dostať vzťahy do normálnych foriem;

a naučiť sa:

• rozlišovať medzi základnými pojmami predmetná oblasť: objekt (entita), jadro predmetnej oblasti, situácia, stav predmetnej oblasti ;
• čítať entitno-vzťahové diagramy.
• vybudovať normálne formy v modeli entita-vzťah.

Úvod

Nasledujúce techniky sa používajú na logický návrh relačných DW.

• Metóda modelovania vzťahov entít(ER modelovanie) poskytuje abstraktný model predmetná oblasť subjektov(subjekty), vzájomné prepojenie(vzťahy) medzi subjektmi a atribúty(atribúty) reprezentovať vlastnosti entít a vzťahov.
• Metóda viacrozmerného modelovania(Rozmerové modelovanie) poskytuje abstraktný model predmetná oblasť pomocou nasledujúcich základných pojmov: ukazovatele alebo metriky(Opatrenia), faktov(fakty) a merania(rozmery).
• Techniky modelovania časových údajov(Modelovanie časových údajov) poskytujú abstraktný model fragmentu predmetná oblasť predstavujúce údaje časových radov a používajú tieto základné pojmy: časové pečiatky(časové pečiatky), časové rady(časový rad), dátum, rozsah dátumov, triedy.
• Metóda modelovania dátového fondu(Data Vault) poskytuje abstraktný model fragmentu predmetná oblasť, založený na matematických princípoch normalizačných vzťahov a používa tieto základné pojmy: uzlové entity(Entity centra), spájajúcich subjektov(Entity prepojenia), satelitné entity(satelitné entity),

V tejto prednáške sa pozrieme na metódu modelovania entít a vzťahov.

Koncept domény a dátová architektúra

Koncept predmetnej oblasti

Hlavným účelom informačných systémov (IS), vrátane systémov na ukladanie dát, je promptne poskytnúť užívateľovi informácie o vonkajšom svete implementáciou vzťah otázka – odpoveď... Vzťahy otázka-odpoveď, interpretované vo vonkajšom svete (svet mimo IS), umožňujú vyčleniť jeho určitý fragment pre IS - predmetná oblasť, ktorý bude implementovaný v systéme. Informácie o vonkajšom svete sú prezentované v IS vo forme dát. To obmedzuje možnosti sémantickej interpretácie informácie a konkretizuje sémantiku jej reprezentácie v IS. Súhrn týchto vyhradených údajov pre formuláre IS doménový logický model opisujúci jeho stav s určitou presnosťou.

Je dôležité tomu rozumieť model logickej domény je vytvorený v štádiu analýzy požiadaviek na IS a neobsahuje predpoklady o technológii implementácie úložiska alebo databázy.

Pokiaľ ide o „údaje“ a „otázky“, vzťah otázka-odpoveď môže byť reprezentovaný ako tabuľka s údajovými položkami ako stĺpcami a otázkami ako riadkami. Každá bunka v takejto tabuľke má logickú hodnotu 1, ak otázka používa túto údajovú položku, alebo 0 v opačnom prípade.

koncepcia predmetná oblasť je jedným zo základných pojmov informatiky a nemá presnú definíciu. Jeho použitie v kontexte IP predpokladá existenciu časovo stabilnej korelácie medzi menami, pojmami a určitými realitami vonkajšieho sveta, nezávisle od samotného IP a jeho okruhu používateľov. Teda predstavenie pojmu predmetná oblasť obmedzuje a zviditeľňuje priestor na vyhľadávanie informácií v IS a umožňuje splnenie dopytov v konečnom čase.

Súbor realít (objektov) vonkajšieho sveta – objektov, o ktorých možno klásť otázky – tvorí objekt jadro predmetnej oblasti... Dostať v IS odpoveď na otázku, ktorú nepozná, je nemožné.

Pojem „objekt“ je primárny, nedefinovaný pojem. Synonymá pre výraz „objekt“ sú „realita“, „entita“, „vec“. Všimnite si, že výraz "entita" je tu ďalej chápaný o niečo užšie, ako zložka určitého. Strávené v predmetná oblasť objekty menia na entity analytici (nie dizajnéri). V čom vecná podstata sa chápe ako výsledok abstrakcie reálneho objektu zvýraznením a zafixovaním jeho vlastností.

Na obr. 6.1 predstavuje jeden z prístupov ku klasifikácii objektov predmetná oblasť.

Ryža. 6.1.

Príklady entít (v zmysle model logickej domény) alebo objekty (z pohľadu vonkajšieho sveta vo vzťahu k IP) sú: žiak, skupina žiakov, trieda, vyučovací čas a pod. atď.

S objektmi sú spojené dva problémy – identifikácia a adekvátny popis. Na identifikačné použitie názov... V tomto prípade sa predpokladá, že dochádza k odmietnutiu jeho významu, ktorý je vlastný prirodzenému jazyku. Používa sa iba orientačná funkcia názvu. Meno je priamy spôsob identifikácie objektu... Nepriame metódy identifikácie objektu zahŕňajú jeho vlastnosti v ich chápaní ako charakteristiky alebo znaky.

Objekty sa navzájom ovplyvňujú prostredníctvom svojich vlastností, čo vedie k situáciám. Situácie sú vzťahy, ktoré vyjadrujú vzťahy medzi objektmi.. Predmetné situácie sú opísané prostredníctvom vyhlásení o predmetná oblasť pomocou výrokového počtu a predikátového počtu, t.j. formálna, matematická logika. Napríklad príslovie „Programátor, manažér sú zamestnanci firmy“ popisuje inkluzívny vzťah. Teda všetky informácie o objektoch a predmetné subjekty popísané pomocou výrokov v prirodzenom jazyku.

Metódy matematickej logiky vám umožňujú formalizovať tieto tvrdenia a prezentovať ich vo forme vhodnej na analýzu.

Príklad.

Zvážte výrok: „Študent AA Ivanov, narodený v roku 1992“. Vyjadruje nasledujúce vlastnosti objektu „Ivanov AA“:

• výslovne - rok narodenia;
• implicitne – patriace študentovi.

Prvá vlastnosť vytvára spojenie medzi dvojicami objektov „Ivanov AA“ a „rok narodenia“ a druhá vlastnosť vytvára spojenie medzi dvojicami objektov „Ivanov AA“ a „veľa študentov“. Formalizácia tohto tvrdenia je prezentovaná ako výsledok priradenia hodnôt premenným zahrnutým v nasledujúcich predikátoch:

NARODENÝ (Ivanov A.A., 1982)

JE ŠTUDENT (Ivanov A.A.)

Všimnite si, že v sémantike prirodzených jazykov sa situácia a vzťah považujú takmer za synonymá. Situácia obsahuje výpoveď o objektoch predmetná oblasť, ktorému môžete priradiť nejaké pravdivostné skóre a po zavedení premenných ho reprezentovať ako predikát. Teda súhrn výrokov o predmetná oblasť možno interpretovať ako definíciu informačného priestoru pre IS.

Na obr. 6.2 predstavuje jeden z prístupov ku klasifikácii situácií v rámci predmetná oblasť.

Rozlišujte medzi statickými a dynamickými situáciami. Príkladom statických situácií sú situácie ako „mať farbu“, „mať vek“ atď. Príkladmi dynamických situácií sú situácie ako „vytvor mašinériu“, „upeč chlieb“ atď.

Všimnite si, že situácia môže byť aj objektom a môže mať vlastnosti. Takáto kolízia vytvára nejednoznačnosť v modelovaní predmetná oblasť.

Vyššie uvedená klasifikácia uvádza predmetná oblasť dva dôležité aspekty sú priestor a čas a čas je chápaný ako moment udalosti a ako interval medzi udalosťami. Predmetná oblasť existuje v priestore a čase, t.j. má, podobne ako skutočný svet, časové a priestorové vzťahy a súvislosti. Je potrebné rozlišovať medzi reálnym časom vonkajšieho sveta a jeho odrazom v IS a v informačných zdrojoch. V IS sa časovo závislé vzťahy evidujú až po ich zaevidovaní. teda predmetná oblasť v ktoromkoľvek danom čase je vybraný súbor určitých predmetov a situácií, tzv stav predmetnej oblasti (alebo snímka).

teda predmetná oblasť- ide o účelovú primárnu transformáciu obrazu vonkajšieho sveta na určitý špekulatívny obraz, ktorého určitá časť je zaznamenaná v IS ako algoritmický model fragmentu reality.

koncepcia predmetná oblasť bol predstavený začiatkom 80. rokov minulého storočia, keď si vedci v oblasti IP uvedomili potrebu používať sémantické modely na reprezentáciu informácií v počítačových systémoch. Tak ako sú požiadavky na počítačový systém tvorené pomocou prirodzeného jazyka, tak sú informácie v počítačových systémoch reprezentované pomocou špeciálneho jazyka s určitou sémantikou. Prvýkrát tento prístup predstavil P. Chen v roku 1976.

Príklad klasiky predmetná oblasť pre tvorbu dátových skladových systémov a teda aj pre CD je úlohou analyzovať tržby spoločnosti. Ako predmety tohto predmetná oblasť možno rozlíšiť: „manažér predaja“, „produkt“, „sklad“, „obchodná kancelária“, „kupujúci“. Ako situácie - "predať tovar", "kúpiť tovar", "odoslať tovar zo skladu", "dodať tovar".

Architektúra údajov domény

HD je doménovo špecifická, integrovaná, časovo konštantná zbierka historických údajov, ktorú používajú rôzne skupiny používateľov na podporu rozhodovania alebo analýzu údajov. Informácie v počítačových systémoch, vrátane CD, sú prezentované vo forme položiek. Jedným z hlavných ustanovení koncepcie CD je čistenie, filtrovanie, transformácia, sumarizácia a agregácia údajov a ich následné umiestnenie do štruktúry, ktorá spĺňa informačné potreby používateľov. Určenie takejto štruktúry je jednou z hlavných úloh logické modelovanie HD.

Jednou z prvých úloh DW dizajnéra je definovanie dátovej architektúry. Dátová architektúra je princípom subjektívnej reprezentácie informácií ako dát v rámci doménového modelu. Pri budovaní dátovej architektúry dizajnér CD definuje dátové prvky, ich vlastnosti a vzťahy medzi nimi. Jedným z kľúčových bodov pri budovaní dátovej architektúry je zrnitosť informácií pri jeho prevode na dátové položky. Proces tejto premeny je tzv štruktúrovanie údajov.

Pre dátové systémy OLTP nie je riešenie problémov súvisiacich s úrovňou granularity dát také dôležité ako v systémoch na skladovanie dát. V databáze OLTP sú údaje zvyčajne podrobne štruktúrované. Pre prezentáciu údajov na CD sa musí projektant špecificky rozhodnúť o úrovni štruktúrovania údajov na základe požiadaviek na systém ukladania údajov. Riešenie tohto problému je veľmi dôležité, pretože pri agregácii a sumarizácii údajov nemusia byť niektoré rozsahy údajov z dodávajúceho systému OLTP zastúpené v HD. Napríklad CD telekomunikačnej spoločnosti môže obsahovať telefónne poplatky zhrnuté v minútach a informačný systém uchováva tieto údaje po sekundách.

Úroveň štruktúrovania (zrnitosť alebo zrnitosť) údajov(Zrnitosť údajov) je jednou z najdôležitejších charakteristík CD. Úroveň štruktúrovania údajov je miera podrobnosti uložených údajov, optimálna z hľadiska riešenia informačných a analytických problémov v rámci dátovej domény.

Zhruba povedané, úroveň štruktúrovania údajov určuje počet požiadaviek, ktoré môžu byť zodpovedané v systéme dátového skladu. Ak si CD zachováva vysokú úroveň štruktúrovania údajov, potom systém podporuje takmer všetky požiadavky predmetná oblasť HD. Vo vyššie uvedenom príklade nie je možné získať odpoveď na otázku: koľko predplatiteľov Ivanov A.A. zaplatil za päť sekúnd konverzácie 1. januára 2009.

Podpora vysokej úrovne štruktúrovania údajov vedie k potrebe ukladať a udržiavať veľké množstvo údajov, čo môže negatívne ovplyvniť výkon skladovacie systémy, najmä o dobe odpovede na žiadosť. Na druhej strane nízka úroveň štruktúrovania dát vedie k tomu, že systém dátového skladu dokáže reagovať na prísne obmedzený okruh požiadaviek. Preto jedna z úloh CD dizajnéra na úrovni logické modelovanie rozhodovanie o optimálnej úrovni štruktúrovania údajov na CD.

Štruktúrovanie údajov zahŕňa rozdelenie celého súboru údajov do špecifických tried za účelom ďalšieho detailovania v rámci vybranej triedy. Pre CD existujú tri hlavné typy údajov (triedy).

• Faktické údaje(Real-time data) predstavujú aktuálny stav kvantitatívnych a kvalitatívnych ukazovateľov organizácie. Zdrojom takýchto údajov sú zvyčajne systémy OLTP. K takýmto údajom patrí vysoká úroveň štruktúrovania. Aby bolo možné použiť takéto údaje v HD, musia byť vopred spracované pomocou čistiacich postupov.
• Odvodené dáta(Odvodené údaje) sú údaje, ktoré sa získavajú sčítaním, agregovaním a spriemerovaním skutočných údajov. V závislosti od úloh analýzy môžu byť takéto údaje podrobné alebo konečné.
• Konsolidované údaje(Odsúhlasené údaje) sú skutočné údaje, ktoré boli vyčistené a poskytujú integrovaný zdroj údajov na riešenie problémov analýzy. Hlavnou požiadavkou na takéto údaje je konzistentnosť.

Koncept domény a dátového skladu

koncepcia predmetná oblasť využíva sa prakticky pri návrhu a vývoji všetkých tried informačných systémov s databázami a dátovými skladmi. Predmetná oblasť definuje tú časť reálneho sveta, ktorá bude modelovaná a implementovaná v systéme. Predmetná oblasť definuje najvšeobecnejšie kritériá a systémové požiadavky vyplývajúce z jeho sémantiky.

Podľa definície je CD vecne orientovaná elektronická zbierka, t.j. spočiatku sa zameriava na určité oblasti činnosti organizácie, predmetná oblasť, - napríklad výroba alebo predaj.

Otázky, s ktorými sa používatelia obracajú na HD, sú spravidla strategické a všeobecnejšie ako v systémoch OLTP. Odpovede na ne zahŕňajú agregáciu a sumarizáciu údajov v rôznych oblastiach činnosti organizácie. To si vyžaduje, aby sa HD systémy zamerali na konkrétne tematické oblastičinnosti organizácie.

Tematické oblasti v systémoch s CD sa tvoria v súlade s pokynmi organizácie. Na definovanie zoznamu tematické oblasti pre takéto systémy je potrebné definovať hlavné činnosti organizácie – napríklad predaj, výroba, zákazníci atď.

Na zvýraznenie tematické oblasti v HD sa často používa takzvaná technika „pravidlá SW1“, konkrétne odpovedanie na otázky: kedy (kedy), kde (kde), kto (kto), čo (čo), prečo (prečo) a ako (ako ) - vo vzťahu k typom činností organizácie (obchodné záujmy). Napríklad pri odpovedi na otázku „kto“ môžu obchodné záujmy zahŕňať nasledujúce entity: zákazníci, zamestnanci, dodávatelia, manažéri, obchodní partneri atď.

Po zostavení zoznamu potenciálu tematické oblasti pre systémy s CD sú zvyčajne podrobnejšie rozložené každým predmetná oblasť... V dôsledku toho je možné získať zoznam tematické oblasti, ktorá najplnšie zastupuje činnosť organizácie. Zároveň je dôležité určiť vzťah medzi vybranými tematické oblasti, čo je dôležité pre stanovenie meraní pri viacrozmerné modelovanie HD.

Všimnite si, že pri riešení problémov analýzy a následne pri vývoji BI systémov je najsľubnejší prístup k určovaniu predmetná oblasť je štúdium obchodných procesov organizácie a nie funkcie, ako v prípade systémov OLTP.

Ďalej zvážte metódu modelovania vzťahov medzi entitami. Táto metóda sa používa na reprezentáciu predmetná oblasť vo forme svojho logického modelu. Aplikovaním metódy sa vytvorí model predmetná oblasť implementácia nezávislá. Metóda sa používa ako pri modelovaní tematické oblasti OLTP systémy a modelovanie tematické oblasti BI systémy. Znalosť tejto metódy pomáha dizajnérovi DW rýchlo nadviazať logické prepojenia medzi databázovými modelmi systémov OLTP v organizačnom meradle a modelmi systémov DW BI.

Modelovanie vzťahov entít

Základné pojmy modelu entita-vzťah

Výsledkom modelovania entitných vzťahov alebo modelovania ER je model ER. ER model je reprezentovaný pomocou ER diagramov, čo sú grafické zápisy na abstrahovanie údajov vo forme entít, vzťahov a atribútov. Takže sémantika predmetná oblasť je reprezentovaný v ER-modeli z hľadiska subjektívnych prostriedkov popisu - entity, atribúty, identifikátory entít, nadtypy, podtypy atď.

Podstata predmetu je výsledkom abstrakcie skutočného objektu zvýraznením a fixáciou súboru jeho vlastností... Entita teda predstavuje triedu objektov, ktorá je výsledkom abstrakcie reálneho objektu. Zvyčajne sa označujú podstatným menom v prirodzenom jazyku.

Entita je opísaná pomocou údajov nazývaných vlastnosti resp atribúty(atribúty) entity. Atribúty sú zvyčajne definície v príkaze entity a označujú sa podstatnými menami v prirodzenom jazyku.

Entity medzi sebou komunikujú prostredníctvom svojich atribútov. Každá skupina atribútov popisujúcich jeden skutočný prejav entity je inštancia entity(príklad). Inými slovami, inštancia entity - sú to realizácie entity, ktoré sa navzájom líšia a dajú sa jednoznačne identifikovať... Jednotné pomenovanie entity uľahčuje neskoršie čítanie modelu. V skutočnosti je názov entity daný názvom jej inštancie.

Jednou z hlavných počítačových metód na rozpoznávanie entít v IS je priraďovanie k entitám identifikátory(Identifikátor entity). často ID entity sa volajú kľúč... Úloha výberu ID entity je sémanticky subjektívna úloha. Keďže entita je definovaná množinou jej atribútov, pre každú entitu je vhodné vybrať takú podmnožinu atribútov, ktorá túto entitu jednoznačne identifikuje.

Niektoré entity majú prirodzené identifikátory. Napríklad prirodzeným identifikátorom faktúry je jej číslo. Identifikátory entít môžu byť zložené – pozostávajúce z niekoľkých atribútov a atómové – pozostávajúce z jedného atribút entity.

Jedinečný identifikátor entity je atribút entity, ktorý umožňuje rozlíšiť jednu entitu od druhej... Ak ich má účtovná jednotka viacero jedinečné identifikátory, takzvané možné kľúče, potom musí projektant vybrať primárny kľúč entity.

Rozlišovať jednoznačné a nejednoznačné atribúty. Jednoznačné sú atribúty, ktoré v rámci konkrétneho inštancia entity majú len jeden význam. V opačnom prípade sa považujú za nejednoznačné..

Dôležitý bod pri štúdiu modelu predmetná oblasť dizajnér má zdôrazniť nejednoznačné atribúty entity... Dôvodom je skutočnosť, že relačný model nepodporuje viachodnotové atribúty a musí byť vyriešený v neskorších fázach návrhu.

Každý atribút má doménu. doména je výraz, ktorý špecifikuje hodnoty povolené pre daný atribút... Inými slovami, doména je doména atribútu. Pre každý atribút entity doména musí byť definovaná. Na úrovni logické modelovanie priradenie údajov domény k atribútu je všeobecné. Atribút je napríklad textový, číselný, binárny, dátumový alebo „nedefinovaný“. V druhom prípade musí analytik poskytnúť popis domény. V ďalších fázach sa typ domény konkretizuje, význam pojmu doména vo fyzikálnom modeli CD je užší, ako to analytik dokáže pochopiť. Je to spôsobené tým, že v rámci fyzického modelu je doména implementovaná prostredníctvom mechanizmu obmedzenia domény a DBMS nerozumie nedefinovaným doménam.

Subjekty neexistujú oddelene od seba. Je medzi nimi skutočný vzťah, ktorý by sa mal odraziť aj na modeli. predmetná oblasť... Pri identifikácii vzťahov sa kladie dôraz na fixáciu vzťahov a ich charakteristík. Postoj (spojenie) predstavuje spojenie (vzťah) medzi dvoma alebo viacerými entitami... Každé spojenie sa realizuje cez hodnoty atribúty entity... Zvyčajne sa spojenie označuje slovesom. Každý spoj musí mať aj svoj vlastný jedinečný identifikátor odkazu.

V relačnom modeli sú vzťahy implementované iba prostredníctvom obmedzení integrity cudzieho kľúča. Preto musí dizajnér relačného DW zabezpečiť, aby sa vzťah medzi entitami realizoval prostredníctvom dobre špecifikovaných atribútov, ktoré budú definovať jedinečný kľúč pre vzťah. Výber kľúčov entity je jedným z najdôležitejších návrhových rozhodnutí, ktoré musí dizajnér urobiť pri prechode na fyzický databázový model.

Spoje sa vyznačujú stupňom spojenia a trieda vlastníctva entity k spojeniu. Stupeň (sila) komunikácie Je pomer počtu subjektov podieľajúcich sa na vytvorení spojenia... Napríklad jedna k jednej, jedna k mnohým, veľa k mnohým. Na úrovni logického modelu je povolený nedefinovaný alebo nevyriešený vzťah. Trieda entity - to je povaha účasti subjektu na spojení... Rozlišovať povinný a voliteľné triedy členstva v subjektoch k spojeniu. Povinné je nasledovné trieda príslušnosti, kedy inštancie entity bezpodmienečne sa podieľať na nadväzovaní komunikácie. V opačnom prípade entita patrí medzi nepovinné trieda spolupatričnosti... Pre voliteľné trieda entity stupeň spojenia sa môže rovnať nule, t.j. inštancia entity môžu byť spojené s 0, 1 alebo viacerými inštanciami inej entity. Za povinné trieda spolupatričnosti stupeň spojenia nemôže byť nulový.

vzťah, entitná väzba sám, sú tzv reflexné... Typickým príkladom reflexívneho vzťahu je definovanie reťazca velenia vo vzťahu k „Zamestnancom“. Reflexívne vzťahy najčastejšie odrážajú hierarchické vzťahy v rámci dátovej štruktúry. Predstavujú množstvo konštrukčných problémov, o ktorých sa bude diskutovať neskôr.

Pokiaľ ide o vzťahy, existujú slabé entity(slabý). Slabé entity sú entity, ktoré nemôžu byť prítomné v databáze, kým neexistuje pridružená inštancia inej entity. Príkladom takejto entity je objednávka, ktorá nemôže existovať bez zákazníka. Slabé subjekty majú povinné trieda príslušnosti, pričom stupeň prepojenia takejto entity nemôže byť rovný nule. Vyžaduje sa vzťah objednávka – zákazník.

Identifikácia slabých entít a ich súvisiacich väzbových vzťahov je nevyhnutná na zabezpečenie integrity a konzistentnosti údajov. Takže napríklad nie je možné priradiť zákazku neznámemu zákazníkovi.

Niekedy má významná entita vzťah zahrnutia alebo vzťah časť-celok. Okrem toho existuje nejaký atribút, ktorého hodnoty vytvárajú rozdelenie množiny inštancie entity do nesúvislých podmnožín - kategórie subjektov... Kategórie entít sú tzv podtypy a v rámci vzťahu vyčleniť subjekt podriadený, ktorý je kategóriou pôvodného subjektu. Atribúty spoločné pre výsledné kategórie sú extrahované z pôvodnej entity, a teda je extrahovaná entita, ktorá sa stáva nadtypom. Meno pôvodnej entity sa zvyčajne ponecháva za entitou vybraného nadtypu, hoci sa mení jej sémantický význam.

Supertyp s ním generovanými podtypmi je príkladom tzv zložená entita... Zložená entita je logická konštrukcia modelu, ktorý predstavuje súbor entít a vzťahov medzi nimi ako celkom.

Príklad. Entitu „auto“ možno rozdeliť na tieto podtypy: autá s pohonom dvoch kolies, autá s pohonom štyroch kolies, autá s prepínateľným pohonom.

Pre dizajnéra je dôležité vedieť, že všetky inštancie entity nadtypu patria len do jedného z jej podtypov. Prítomnosť podtypov a supertypov v modeli komplikuje dizajn a vytvára určité ťažkosti pri implementácii. Preto je dôležité v počiatočnom štádiu návrhu zistiť, či je prítomnosť supertypov v modeli nevyhnutná.

Ak to chcete urobiť, musíte vykonať nasledujúce akcie:

• určiť, či mnohé z rovnakých vlastností majú rôzne podtypy. Malo by sa pamätať na to, že čím menej sú si podtypy podobné, tým je pravdepodobnejšie, že zavedú supertyp;
• alebo nájsť inštancia entity ktoré možno primerane zahrnúť do viac ako jedného podtypu. Keďže je to v rozpore s definíciou nadtypu, navrhované rozdelenie je neplatné.

Typická forma dokumentácie model logickej domény v modelovaní ER sú entitno-vzťahové diagramy alebo ER-diagramy (Entity Relationship Diagram). ER-diagram vám umožňuje graficky znázorniť všetky prvky logického modelu podľa jednoduchých, intuitívnych, ale prísne definovaných pravidiel - zápisy.

Na vytváranie ER diagramov sa zvyčajne používa jeden z dvoch najbežnejších zápisov.

• Integrácia DEDefinícia pre informačné modelovanie (IDEF1X). Tento zápis bol vyvinutý pre americkú armádu a stal sa federálnym štandardom USA. Okrem toho je štandardom v rade medzinárodných organizácií (NATO, Medzinárodný menový fond atď.).
• Informačné inžinierstvo (IE). Notácia vyvinutá Martinom, Finkelsteinom a ďalšími sa používa predovšetkým v priemysle.

Konštrukcia ER-diagramov sa spravidla vykonáva pomocou nástrojov CASE. V tejto prednáške sa vo všetkých príkladoch, pokiaľ nie je uvedené inak, použije zápis MS Office Visio 2007.

Entitu na ER diagrame predstavuje obdĺžnik s názvom v hornej časti (obr. 6.3).

Ryža. 6.3. Znázornenie entity „Zamestnanec“ v diagrame ER

Obdĺžnik uvádza atribúty entity, pričom atribúty tvoria jedinečný identifikátor entity, sú podčiarknuté (obr. 6.4).

Ryža. 6.4. Zobrazenie entity zamestnanca s atribútmi a jedinečným identifikátorom entity

Každý inštancia entity musia byť jedinečné a odlišné od ostatných atribútov. Jednou z hlavných počítačových metód na rozpoznávanie entít v IS je prideľovanie identifikátorov entít entitám. Keďže entita je definovaná množinou jej atribútov, pre každú entitu je vhodné vybrať takú podmnožinu atribútov, ktorá túto entitu jednoznačne identifikuje. často ID entity nazývaný primárny kľúč.

Primárny kľúč je atribút alebo skupina atribútov, ktoré jedinečne identifikujú inštanciu entity... Atribúty primárneho kľúča v diagrame nevyžadujú špeciálne označenie - sú to atribúty, ktoré sú v zozname atribútov nad vodorovnou čiarou (obr. 6.3).

Voľba primárneho kľúča môže byť náročná úloha, ktorej riešenie môže ovplyvniť efektivitu budúcej IP. Jedna entita môže obsahovať niekoľko atribútov alebo množín atribútov, ktoré tvrdia, že sú primárnym kľúčom. Takíto žiadatelia sú tzv potenciálne kľúče(kľúč kandidáta).

Kľúče môžu byť komplexný, t.j. obsahujúce viacero atribútov. Komplexné primárne kľúče nevyžadujú špeciálnu notáciu – sú to zoznam atribútov nad vodorovnou čiarou.

Zvážte kandidátov na primárny kľúč entity „zamestnanec“ (obr. 6.5).

Ryža. 6.5. Definovanie primárneho kľúča pre zamestnaneckú entitu

Tu možno identifikovať nasledujúce potenciálne stopy.

1. Personálne číslo.
2. Číslo pasu.
3. Priezvisko + meno + patronymum.

Aby sa stal primárnym, potenciálny kľúč musí spĺňať množstvo požiadaviek.

Jedinečnosť... Tieto dve inštancie nesmú mať rovnaké možné hodnoty kľúča. Potenciálny kľúč (Priezvisko + meno + patronymum) je zlý kandidát, pretože organizácia môže mať úplných menovcov.

Kompaktnosť... Komplexný kandidátsky kľúč by nemal obsahovať žiadny atribút, ktorý by po odstránení nespôsobil stratu jedinečnosti. Aby sa zabezpečila jedinečnosť kľúča ( Priezvisko + meno + patronymum) dopĺňame atribútmi Dátum narodenia a Farba očí... Ak obchodné pravidlá hovoria, že kombinácie atribútov Priezvisko + meno + patronymum + dátum narodenia stačí na jednoznačnú identifikáciu zamestnanca Farba očí sa ukazuje ako nadbytočný, teda kľúč Priezvisko + Meno + Stredné meno + Dátum narodenia + Farba očí nie je kompaktný.

Pri výbere primárneho kľúča by sa mali uprednostniť jednoduchšie kľúče, to znamená kľúče s menším počtom atribútov. V tomto príklade sú klávesy #1 a #2 vhodnejšie ako kláves #3.

Kľúčové atribúty nesmú obsahovať hodnoty null. Ak sa predpokladá, že zamestnanec nemusí mať pas alebo inú formu identifikácie namiesto pasu, potom kľúč #2 nebude vhodný pre úlohu primárneho kľúča. Ak na zabezpečenie jedinečnosti je potrebné doplniť potenciálny kľúč dodatočné atribúty, nesmú obsahovať hodnoty null. Pri pridávaní kľúča č.3 s prívlastkom Dátum narodenia musíte sa uistiť, že dátumy narodenia sú známe všetkým zamestnancom.

Hodnota kľúčových atribútov by sa nemala meniť počas celej životnosti inštancia entity... Zamestnanec organizácie sa môže oženiť a zmeniť priezvisko aj pas. Preto kľúče #2 a 3 nie sú vhodné pre úlohu primárneho kľúča.

Každý subjekt musí mať aspoň jeden potenciálny kľúč... Mnoho subjektov má iba jeden potenciálny kľúč... Tento kľúč sa stáva primárnym. Niektoré entity môžu mať viac ako jeden možný kľúč. Potom sa jeden z nich stane primárnym a zvyšok - alternatívne kľúče. Alternatívny kľúč je potenciálny kľúč, ktorý sa nestal primárnym.

Niektoré entity majú prirodzené kľúče. Napríklad prirodzeným identifikátorom faktúry je jej číslo. V opačnom prípade môže dizajnér vytvoriť náhradný kľúč – atribút, ktorého hodnota je vytvorená umelo a nesúvisí s doménou. Pri modelovaní dátových štruktúr pre HD sú v mnohých situáciách vhodnejšie náhradné kľúče.

Domény prideľujú analytici a zaznamenávajú sa v špeciálnom dokumente - dátový slovník(Dátový slovník). Pri vytváraní logického modelu môžu byť domény špecifikované v entitách v ER diagrame.

Každý atribút má doménu. Doménu možno definovať ako abstraktný atribút, z ktorého možno generovať regulárne atribúty, pričom vygenerované atribúty majú všetky vlastnosti nadradenej domény. Každý atribút môže byť definovaný iba v jednej doméne, ale v každej doméne môže byť definovaných veľa atribútov. Pojem domény zahŕňa nielen dátový typ, ale aj rozsah dátových hodnôt. Môžete napríklad definovať doménu „Vek“ ako kladné celé číslo a definovať atribút Vek zamestnanca ako patriace do tejto domény.

Na úrovni logické modelovanie priradenie údajov domény k atribútu je všeobecné. Atribút je napríklad textový, číselný, binárny, dátumový alebo „nedefinovaný“. V druhom prípade musí analytik poskytnúť popis domény. V ďalších fázach sa typ domény konkretizuje, význam pojmu doména vo fyzikálnom modeli CD je užší, ako to analytik dokáže pochopiť. Je to spôsobené tým, že v rámci fyzického modelu je doména implementovaná cez mechanizmus obmedzenia domény, DBMS nerozumie nedefinovaným doménam.

Dizajnér si musí dôkladne preštudovať domény každého atribútu z hľadiska ich realizovateľnosti v DBMS, za účasti analytikov ich zmeniť, ak nie je splnená podmienka realizovateľnosti. V tomto prípade sa dizajnér riadi nasledujúcim:

• na implementáciu ukladania relačných údajov musíte použiť relačný alebo objektovo relačný DBMS, napríklad MS SQL Server 2008;
• Väčšina relačných DBMS používa SQL ako svoj jazyk na manipuláciu a popis údajov, ktorý podporuje určité štandardy, ako napríklad ANSI SQL-92.

Postoj (spojenie) entity v ER diagrame sú znázornené čiarou spájajúcou tieto entity. Pomer sa číta pozdĺž čiary, buď zľava doprava alebo sprava doľava. Na obr. 6.6 je uvedený vzťah: každá odbornosť podľa vzdelania musí byť registrovaná u konkrétnej fyzickej osoby (osoby), jednotlivec môže mať jednu alebo viac odborností podľa vzdelania.

Ryža. 6.6.

V MS Office Visio názov vzťahu, stupeň vzťahu (kardinalita) a trieda entity prepojenie je definované na karte Vlastnosti databázy, ako je znázornené na obr. 6.7. Šípka na komunikačnej linke označuje rodičovská tabuľka.

Pri identifikácii odkazov sa kladie dôraz na identifikáciu ich charakteristík. Vzťah je vzťah medzi dvoma alebo viacerými entitami. Každé spojenie sa realizuje cez hodnoty atribúty entity, napríklad, inštancia entity"Zamestnanec" (obr. 6.6) je spojený s inštancia entity„Vzdelanie“ rovnakými hodnotami atribútu Personálne číslo... Inými slovami, keď vytvoríte vzťah v jednej z entít nazývaných podriadená entita, vytvorí sa nový atribút s názvom cudzí kľúč(Foreign Key, FK) (na obrázku 6.6 ide o atribút Personálne číslo). Niekedy sú atribúty cudzieho kľúča označené (FK) za ich názvom.

Vzťah je logický vzťah medzi entitami. Každé spojenie musí byť pomenované slovesom alebo slovesnou frázou Názov vzťahu (Verb Phrase) – slovné spojenie, ktoré charakterizuje vzťah medzi nadradenými a podradenými entitami... Názov vzťahu vyjadruje určitý druh obmedzenia alebo obchodného pravidla a uľahčuje čítanie diagramu. Na obr. 6.8 ukazuje priradenie názvu vzťahu.

Existujú rôzne typy vzťahov: identifikujúci vzťah jeden k mnohým, vzťah mnoho k mnohým a neidentifikujúci vzťah jeden k mnohým. S typmi vzťahov sú spojené aj rôzne typy entít.

Existujú dva typy subjektov: závislý(závislý subjekt) a nezávislý(Nezávislý subjekt). Typ entity je určený jej vzťahom k iným entitám. Medzi nezávislými (rodičovský koniec vzťahu) a závislými (podriadený koniec vzťahu) entitami sa vytvorí identifikačný vzťah.

Inštancia závislej entity je definovaná len prostredníctvom vzťahu k materskej entite, t.j. v štruktúre na obr. 6.8 informácie o špecializácii nie je možné zadať a nemajú zmysel bez informácií o zamestnancovi, ktorý má špecializáciu podľa diplomu o vzdelaní. Keď sa vytvorí identifikačný vzťah (na obrázku súvislá čiara), atribúty primárneho kľúča nadradenej entity sa automaticky prenesú do primárneho kľúča podriadenej entity (súvislá čiara). Toto doplňovacia operácia atribúty podriadenej entity pri vytváraní vzťahu sa nazýva migrácia atribútov. V podradenej entite sa takýto atribút považuje za cudzí kľúč.

Ak je model vytvorený pomocou nástrojov CASE, potom pri generovaní databázovej schémy dostanú atribúty primárneho kľúča znak NOT NULL, čo znamená, že nie je možné vykonať zápis do tabuľky „Zamestnanci“ bez informácií o zamestnancovi. osobné číslo.

Keď sa vytvorí neidentifikujúci vzťah (obr. 6.9, prerušovaná čiara), podriadená entita zostáva nezávislá a atribúty primárneho kľúča nadradenej entity migrujú do nekľúčových komponentov nadradenej entity. Na prepojenie nezávislých entít sa používa neidentifikujúci vzťah (obrázok 6.9).

Inštancia entity„Zamestnanec“ môže existovať bez ohľadu na kohokoľvek inštancia entity"Oddelenie", to znamená, že zamestnanec môže pracovať v organizácii a nesmie byť uvedený v žiadnom oddelení.

Identifikačný odkaz je v diagrame znázornený ako plná čiara s tučným bodom na podradenom konci odkazu (pozri obr. 6.8), neidentifikujúcim bodom - prerušovanou (pozri obr. 6.9).

Vzťah medzi mnohými(vzťah mnoho k mnohým) je možné vytvoriť iba na úrovni logického modelu. Na obr. Obrázok 6.10 ukazuje príklad definovania vzťahu mnoho k mnohým. Lekár môže vidieť veľa pacientov, pacienta môže ošetrovať viacero lekárov. Toto spojenie je naznačené plnou čiarou s dvoma šípkami na koncoch.

Vzťah „many-to-many“ by mal byť pomenovaný v dvoch frázach – v oboch smeroch (v príklade „akceptuje / je ošetrený“). To uľahčuje čítanie diagramu. Komunikácia zapnutá

Ako každý model, aj model „entity-relationship“ má niekoľko základných konceptov, ktoré tvoria počiatočné stavebné kamene, z ktorých sa podľa vopred stanovených pravidiel stavajú zložitejšie objekty.

Tento model najviac zodpovedá konceptu objektovo orientovaného dizajnu, ktorý je v súčasnosti nepochybne základom pre vývoj zložitých softvérových systémov, takže mnohé koncepty sa vám môžu zdať povedomé, a ak je to pravda, tým ľahšie to bude aby ste zvládli technológiu návrhu databázy založenú na modeli ER.

Model ER je založený na nasledujúcich základných konceptoch:

• Esencia, s pomocou ktorej sa modeluje trieda objektov rovnakého typu. Entita má názov, ktorý je v rámci modelovaného systému jedinečný. Keďže entita zodpovedá určitej triede objektov rovnakého typu, predpokladá sa, že v systéme existuje veľa inštancií tejto entity. Objekt, ktorý zodpovedá pojmu entity, má svoj vlastný súbor atribúty - charakteristiky, ktoré definujú vlastnosti tohto zástupcu triedy. V tomto prípade musí byť množina atribútov taká, aby bolo možné rozlíšiť medzi konkrétnymi inštanciami entity. Subjekt Zamestnanec môže mať napríklad nasledujúcu množinu atribútov: Osobné číslo, Priezvisko, Meno, Patronymia, Dátum narodenia, Počet detí, Príbuzní v zahraničí. Volá sa množina atribútov, ktorá jednoznačne identifikuje konkrétnu inštanciu entity kľúč. Pre subjekt Zamestnanec bude kľúčovým atribútom Osobné číslo, keďže osobné čísla budú pre všetkých zamestnancov daného podniku odlišné. Inštanciou entity Zamestnanec bude popis konkrétneho zamestnanca podniku. Jedným zo všeobecne akceptovaných grafických označení entity je obdĺžnik, v hornej časti ktorého je napísaný názov entity a nižšie sú uvedené atribúty a kľúčové atribúty sú označené napríklad podčiarknutím, resp. špeciálne písmo (obr. 7.1):

Ryža. 7.1.Príklad definovania entity v modeli ER

Medzi entitami je možné nastaviť spojenia- binárne asociácie znázorňujúce, ako entity navzájom súvisia alebo interagujú. Spojenie môže existovať medzi dvoma rôznymi entitami alebo medzi entitou a ňou samou (rekurzívny odkaz). Ukazuje, ako inštancie entít navzájom súvisia. Ak sa vytvorí vzťah medzi dvoma entitami, potom to definuje vzťah medzi inštanciami jednej a druhej entity. Napríklad, ak máme vzťah medzi entitou „Študent“ a entitou „Učiteľ“ a tento vzťah je smerovaním maturitných projektov, potom má každý študent iba jedného vedúceho, ale ten istý učiteľ môže viesť mnoho postgraduálnych študentov. Preto to bude vzťah jeden k mnohým (1: M), jeden zo strany „Učiteľ“ a veľa zo strany „Študent“ (pozri obr. 7.2).

Ryža. 7.2.Príklad vzťahu „jeden k mnohým“ pri prepojení entít „Študent“ a „Učiteľ“

Sila väzby je v rôznych notáciách znázornená rôzne. V našom príklade používame zápis CASE systému POWER DESIGNER, tu je mnohopočetnosť znázornená delením komunikačnej línie číslom 3. Vzťah má spoločný názov „Graduate Design“ a má názvy rolí na strane oboch subjektov. . Zo strany študenta sa táto rola nazýva „Písanie diplomovky pod vedením“, zo strany učiteľa sa toto spojenie nazýva „Dozor“. Grafická interpretácia vzťahu umožňuje okamžite prečítať význam vzťahu medzi entitami, je vizuálna a ľahko interpretovateľná. Vzťahy sú rozdelené do troch typov podľa ich početnosti: jeden na jedného(1:1), jeden a-k-mnohým(1 milión), mnoho-k-mnohým(MM). Vzťah jedna k jednej znamená, že inštancia jednej entity je spojená iba s jednou inštanciou inej entity.

Vzťah 1: M znamená, že jedna inštancia entity umiestnená naľavo od vzťahu môže byť spojená s niekoľkými inštanciami entity umiestnenej napravo od vzťahu. Vzťah jedna k jednej (1: 1) znamená, že jedna inštancia jednej entity je spojená iba s jednou inštanciou inej entity a vzťah mnoho k mnohým (M: M) znamená, že jedna inštancia prvej entity entita môže byť spojená s viacerými inštanciami druhej entity a naopak, jedna inštancia druhej entity môže byť spojená s viacerými inštanciami prvej entity. Napríklad, ak uvažujeme vzťah typu „Štúdium“ medzi entitami „Študent“ a „Disciplína“, potom ide o vzťah typu „mnoho k mnohým“ (M:M), pretože každý študent môže študuje viacero odborov, ale každý odbor študuje veľa študentov.Takýto vzťah je znázornený na obr. 7.3.

• Medzi dvoma entitami je možné nastaviť ľubovoľný počet spojení s rôznym sémantickým zaťažením. Napríklad medzi dvoma entitami „Študent“ a „Učiteľ“ môžete vytvoriť dve sémantické spojenia, jedno je predtým považované za „Graduate Design“ a druhé sa môže bežne nazývať „Prednášky“ a určuje, ktoré prednášky ktorých učiteľov daný študent počúva a ktoré tento učiteľ študentom prednáša. Je jasné, že ide o spojenie typu mnoho-k-mnohým. Príklad týchto spojení je na obr. 7.3.

Ryža. 7.3.Príklad modelovania vzťahu veľa k mnohým

• Komunikácia akéhokoľvek z týchto typov môže byť povinné, ak sa na tomto spojení musí zúčastniť každá inštancia subjektu, voliteľné - ak sa na danom vzťahu nemusí zúčastniť každá inštancia subjektu. V tomto prípade môže byť spojenie na jednej strane povinné a na druhej strane voliteľné. Povinná komunikácia sa tiež označuje rôznymi spôsobmi v rôznych notáciách. Opäť používame notáciu POWER DESIGNER. Tu je voliteľný odkaz označený prázdnym kruhom na konci odkazu a povinný je označený kolmou čiarou, ktorá odkaz prečiarkne. A tento zápis má jednoduchý výklad. Kruh znamená, že žiadna inštancia sa nemôže zúčastniť tohto spojenia. A kolmica sa interpretuje ako skutočnosť, že aspoň jedna inštancia entity sa zúčastňuje tohto vzťahu.

Na tento účel zvážte predtým uvedený príklad vzťahu „Graduate Design“. V našej ilustrácii je tento vzťah interpretovaný ako voliteľný na oboch stranách. V skutočnosti však každý študent, ktorý píše diplomovku, by mal mať svojho vedúceho nad návrhom diplomu, no na druhej strane nie každý učiteľ by mal navrhovať diplomovku. Preto sa v tomto sémantickom nastavení obraz tohto spojenia zmení a bude vyzerať tak, ako je znázornené na obr. 7.4.

Ryža. 7.4.Príklad povinného a voliteľného vzťahu medzi entitami

Okrem toho je v ER-modeli povolený princíp kategorizácie subjektov. To znamená, že podobne ako v objektovo orientovaných programovacích jazykoch sa zavádza pojem podtyp entity, to znamená, že „entita môže byť reprezentovaná vo forme dvoch alebo viacerých svojich podtypov - entity, z ktorých každý môže mať spoločné atribúty a vzťahy a/alebo atribúty a vzťahy, ktoré sú raz definované na najvyššej úrovni a zdedené na spodnej úrovni. Všetky podtypy jednej entity sa považujú za vzájomne sa vylučujúce a pri rozdeľovaní entity na podtypy musí byť reprezentovaná ako úplná množina vzájomne sa vylučujúcich podtypov. Ak na úrovni analýzy nie je možné identifikovať úplný zoznam podtypov, potom sa zavedie špeciálny podtyp, podmienečne nazývaný OTHER, ktorý je možné ďalej spresniť. V reálnych systémoch môže stačiť zaviesť podtyp na dvoch alebo troch úrovniach.

Entita, na základe ktorej sa stavajú podtypy, sa nazýva tzv supertyp. Každá inštancia nadtypu musí byť špecifického podtypu. Na grafické znázornenie princípu kategorizácie alebo typizácie entity sa zavádza špeciálny grafický prvok, tzv. diskriminačný uzol, v notácii POWER DESIGNER je zobrazený ako polkruh s konvexnou stranou smerujúcou k superentite. Táto strana je spojená smerovanou šípkou so superentitou a podtypy tejto entity sú spojené s priemerom tohto kruhu šípkami (pozri obr. 7.5).

Ryža. 7.5.Diagram podtypu entity TEST

Tento diagram možno dešifrovať nasledovne. Každý test v určitom testovacom systéme je buď testom na overenie znalosti jazyka SQL, alebo nejakou analytickou úlohou, ktorá sa vykonáva pomocou vopred napísaných Java appletov, alebo testom v určitej oblasti znalostí, ktorý pozostáva zo sady otázok a súboru odpovedí ponúkaných na každú otázku.

Výsledkom vybudovania doménového modelu vo forme množiny entít a vzťahov dostaneme súvislý graf. Vo výslednom grafe je potrebné vyhnúť sa cyklickým spojeniam - odhaľujú nesprávnosť modelu.

Ako príklad navrhneme mytologický model systému určeného na uchovávanie informácií o knihách a oblastiach vedomostí prezentovaných v knižnici. Opis predmetnej oblasti bol uvedený skôr. Začnime s vývojom modelu zvýraznením hlavných entít.

V prvom rade je tu podstata „Knihy“, každá kniha má jedinečnú šifru, ktorá je jej kľúčom, a množstvo atribútov, ktoré sú prevzaté z popisu predmetnej oblasti. Mnoho inštancií entity definuje množstvo kníh, ktoré sú uložené v knižnici. Každá inštancia entity "Knihy" nezodpovedá konkrétnej knihe na poličke, ale popisu určitej knihy, ktorý je zvyčajne uvedený v predmetovom katalógu knižnice. Každá kniha môže byť prítomná v niekoľkých exemplároch, a to sú práve tie konkrétne knihy, ktoré sú na policiach knižnice.

Aby sme to zohľadnili, musíme zaviesť entitu Inštancie, ktorá bude obsahovať popisy všetkých inštancií kníh, ktoré sú uložené v knižnici. Každá inštancia entity Inštancie zodpovedá konkrétnej knihe na poličke. Každý exemplár má jedinečné inventárne číslo, ktoré jednoznačne identifikuje konkrétnu knihu. Okrem toho môže byť každý exemplár knihy buď v knižnici, alebo v rukách určitého čitateľa, a v druhom prípade pre tento exemplár dátum prevzatia knihy čitateľom a dátum predpokladaný návrat knihy je uvedený dodatočne.

Medzi entitami „Knihy“ a „Inštancie“ existuje vzťah jedna k mnohým (1: M), ktorý je povinný na oboch stranách. Čo určuje tento typ pripojenia? Môžeme predpokladať, že každá kniha môže byť v knižnici prítomná vo viacerých exemplároch, preto je vzťah „jeden k mnohým“. Okrem toho, ak knižnica nemá jedinú kópiu knihy, neuložíme jej popis, a preto, ak je kniha opísaná v podstate ako „Knihy“, potom sa aspoň jedna kópia tejto knihy nachádza v knižnica. To znamená, že zo strany knihy je odkaz povinný. Pokiaľ ide o entitu „Inštancie“, v knižnici nemôže byť ani jedna inštancia, ktorá nepatrí ku konkrétnej knihe, preto je vzťah povinný aj zo strany „Inštancie“.

Teraz musíme definovať, ako bude čitateľ prezentovaný v našom systéme. Je prirodzené navrhnúť na tento účel zaviesť entitu „Čitatelia“, ktorej každý výskyt bude zodpovedať konkrétnemu čitateľovi. V knižnici má každý čitateľ pridelené jedinečné číslo čitateľského preukazu, ktoré bude jednoznačne identifikovať nášho čitateľa. Číslo čitateľského preukazu bude kľúčovým atribútom entity Čitatelia.

Entita "Čitatelia" musí navyše obsahovať ďalšie atribúty, ktoré sú potrebné na riešenie zadaných úloh, budú to tieto atribúty: "Priezvisko Meno Patronymické", "Adresa čitateľa", "Telefón domov" a "Telefón do práce". Prečo sme zaviedli dva samostatné atribúty pre telefóny? Pretože na tieto telefóny musíte volať v rôznych časoch, aby ste zachytili čítačku, bude preto dôležité, aby vedenie knižnice vedelo, do akého typu tento telefón patrí. V popise našej tematickej oblasti je obmedzenie veku našich čitateľov, preto je potrebné v entite "Čitatelia" zadať povinný atribút "Dátum narodenia", ktorý nám umožní kontrolovať vek. našich čitateľov.

Z popisu tematickej oblasti vieme, že každý čitateľ môže držať v rukách niekoľko výtlačkov kníh. Aby sme túto situáciu odzrkadlili, musíme nakresliť vzťah medzi entitami „Čitatelia“ a „Inštancie“. Prečo nie medzi entitami „Čitatelia“ a „Knihy“? Čitateľ si totiž z knižnice berie konkrétny výtlačok konkrétnej knihy, a nie len knihy. Ako však zistíte, akú knihu daný čitateľ má? A to bude možné zistiť dodatočným prepojením medzi entitami "Inštancie" a "Knihy", pričom tento vzťah priraďuje ku každej inštancii jednu knihu, takže kedykoľvek môžeme jednoznačne určiť, ktoré knihy sú v rukách čitateľa. , hoci s čitateľom spájame len inventárne čísla prevzatých kníh. Medzi entitami Čitatelia a Inštancie je vytvorený vzťah typu one-to-many a nie je povinný na oboch stranách. Čitateľ v súčasnosti nemusí držať v rukách ani jednu knihu a na druhej strane túto kópiu knihy nemusí vlastniť žiadny čitateľ, ale len tak stáť na poličke v knižnici.

Teraz musíme reflektovať poslednú entitu, ktorá je priradená k systémovému katalógu. Systémový katalóg obsahuje zoznam všetkých oblastí vedomostí, informácie o ktorých sú obsiahnuté v knihách knižnice. Môžeme si vyvolať systémový katalóg v knižnici, z ktorého zvyčajne začíname hľadať knihy, ktoré potrebujeme, ak nepoznáme ich autorov a názvy. Názov oblasti znalostí môže byť dlhý a pozostávať z niekoľkých slov, preto na modelovanie systémového katalógu zavedieme entitu „Systémový katalóg“ s dvoma atribútmi: „Kód oblasti znalostí“ a „Názov oblasti znalostí“. Atribút Knowledge Area Code bude kľúčovým atribútom entity.

Z popisu predmetnej oblasti vieme, že každá kniha môže obsahovať informácie z viacerých oblastí poznania a na druhej strane z praxe vieme, že knižnica môže obsahovať veľa kníh súvisiacich s rovnakou oblasťou vedomostí, takže medzi entitami „Systémový katalóg“ a „Knihy“ musíme vytvoriť prepojenie „myogie-to-many“, povinné na oboch stranách. Systémový katalóg by skutočne nemal obsahovať takú oblasť vedomostí, o ktorej informácie nie sú uvedené v žiadnej knihe našej knižnice, opak by nemal zmysel. Naopak, každá kniha by mala byť zaradená do jednej alebo viacerých oblastí vedomostí, aby ju čitateľ rýchlejšie našiel.

Mytologický model tematickej oblasti „Knižnica“ je znázornený na obr. 7.6.

Ryža. 7.6.Mytologický model "Knižnica"

Mytologický model "Knižnica" bol vyvinutý nami pre úlohy, ktoré boli uvedené vyššie. V týchto úlohách sme si nestanovili podmienku uchovávania histórie čítania knihy, napríklad s cieľom nájsť niekoho, kto predtým knihu držal a mohol by jej ublížiť alebo v nej omylom zabudnúť väčší obnos peňazí. Ak by sme si dali za úlohu ukladať aj tieto informácie, tak náš info-logický model by bol iný. Túto úlohu nechám na vašu samostatnú tvorivosť.

Predtým, než sa vývojár pustí do vytvárania systému automatizovaného spracovania informácií, musí si vytvoriť koncepty o objektoch, skutočnostiach a udalostiach, s ktorými bude systém fungovať. Aby sa tieto pojmy dostali do jedného alebo druhého dátového modelu, je potrebné ich nahradiť informačnými reprezentáciami. Jedným z najpohodlnejších nástrojov na jednotnú reprezentáciu údajov, nezávisle od softvéru, ktorý ju implementuje, je model entít a vzťahov (ER-model).

Model entita-vzťah je založený na niektorých dôležitých sémantických informáciách o skutočnom svete a je navrhnutý tak, aby logicky reprezentoval údaje. Definuje hodnoty údajov v kontexte ich vzťahu k iným údajom. Pre nás je dôležité, že všetky existujúce dátové modely (hierarchický, sieťový, relačný, objektový) je možné generovať z entitno-relačného modelu, preto je najvšeobecnejší.

Model „entity-relationship“ navrhol v roku 1976 Peter Ping-Sheng Chen, ruský preklad jeho článku „The entity-relationship model – a step to unified data presentation“ bol publikovaný v časopise „DBMS“ č. , 1995.

Vrstvené reprezentácie údajov

Pri skúmaní dátového modelu by ste mali identifikovať logické reprezentácie dát, ktorých sa model týka. Rozšírením súboru ustanovení môžeme definovať štyri úrovne prezentácie údajov:

Informácie súvisiace s entitami a vzťahmi, ktoré existujú v našej predstavivosti; - informačná štruktúra - organizácia informácií, v ktorej sú entity a vzťahy reprezentované údajmi. - dátová štruktúra, ktorá je nezávislá od prístupových ciest, - dátová štruktúra, ktorá nie je spojená s vyhľadávacími schémami, indexovaním atď. - dátová štruktúra závislá od prístupových ciest.

Obrázok 1. Analýza dátových modelov pomocou viacerých úrovní logických reprezentácií

Informácie o entite a vzťahu

Na tejto úrovni uvažujeme o entitách a vzťahoch. Entita je položka, ktorú možno identifikovať nejakým spôsobom, ktorý ju odlišuje od iných položiek. Príkladmi entity sú konkrétna osoba, spoločnosť alebo udalosť. Vzťah je spojenie vytvorené medzi subjektmi. Napríklad otec-syn je spojenie medzi dvoma entitami osoby. 1)

Podniková databáza obsahuje informácie o subjektoch a vzťahoch, ktoré sú pre tento podnik zaujímavé. Do podnikovej databázy nie je možné zadať úplný popis entity alebo vzťahu. Nie je možné (a zrejme ani nevyhnutné) uchovávať všetky potenciálne dostupné informácie o subjektoch a vzťahoch. Ďalej budeme brať do úvahy len tie entity a vzťahy (a informácie o nich), ktoré by mali byť zahrnuté v databázovom projekte.

Esencia a mnohé entity

Nech e označuje nejakú entitu, ktorá existuje v našej predstavivosti. Každá entita patrí do určitej odlišnej množiny entít, ako je napríklad ZAMESTNANEC, PROJEKT alebo ODDELENIE. Každá množina entít je spojená s predikátom, ktorý vám umožňuje skontrolovať, či daná entita patrí do danej množiny. Ak napríklad vieme, že entita patrí do množiny entít ZAMESTNANEC, tak vieme aj to, že táto entita má spoločné vlastnosti s inými entitami z množiny entít ZAMESTNANEC. Tieto vlastnosti zahŕňajú vyššie uvedený predikát. Nech Ei označuje množinu entít. Všimnite si, že množiny entít nemusia byť disjunktné. Napríklad entita patriaca do množiny entít MALE-PERSON tiež patrí do množiny entít PERSON. V tomto prípade je MALE-PERSON podmnožinou PERSON.

Spojenie, rola a mnohé súvislosti.

Zvážte asociácie entít. Množina vzťahov Ri je matematický vzťah medzi n entitami, z ktorých každá sa vzťahuje na množinu entít:

(| e1 ∈ E1, e2 ∈ E2, ..., en ∈ En), a každá n-tica entít,, je vzťah. Všimnite si, že v tejto definícii Ei nemusia byť odlišné množiny. Napríklad manželstvo je vzťah medzi dvoma entitami zo súboru entít PERSON.

Úloha subjektu vo vzťahu je funkcia, ktorú subjekt v tomto vzťahu vykonáva. Manžel a manželka sú role. Poradie entít v definícii vzťahu (všimnite si, že boli použité hranaté zátvorky) môže chýbať, ak sú roly entít vo vzťahu výslovne špecifikované: (r1 / e1, r2 / e2, ..., rn / en) , kde ri je v tejto súvislosti úlohou entity ei.

Atribút, hodnota a množina hodnôt.

Informácie o entite alebo vzťahu sa získavajú pozorovaním alebo meraním a sú vyjadrené vo viacerých pároch atribút-hodnota. 3, červená, Peter a Johnson sú významy. Hodnoty sú rozdelené do rôznych sád hodnôt, ako sú FEET, COLOR, FIRST-NAME a LAST-NAME. Ku každej množine hodnôt je priradený predikát, aby sa otestovalo, či hodnota patrí do tejto množiny. Hodnota z množiny hodnôt môže byť ekvivalentná inej hodnote z inej množiny hodnôt. Napríklad 12 z hodnôt INCH zodpovedá 1 v FEET.

Atribút možno formálne definovať ako funkciu, ktorá mapuje množinu entít alebo množinu vzťahov na množinu hodnôt alebo karteziánsky súčin množín hodnôt:

f: Ei alebo Ri → Vi alebo Vi1 × Vi2 × ... × Vin Obrázok 2 zobrazuje niekoľko atribútov definovaných v množine entít PERSON. Atribút AGE sa mapuje na množinu hodnôt NO-OF-YEARS. Atribút môže špecifikovať mapovanie množín hodnôt na karteziánsky súčin. Napríklad atribút NAME sa mapuje na sady hodnôt FIRST-NAME a LAST-NAME. Upozorňujeme, že niekoľko atribútov môže špecifikovať mapovanie rovnakej množiny entít na rovnakú množinu hodnôt (alebo rovnakú skupinu množín hodnôt). Napríklad atribúty NAME a ALTERNATIVE-NAME špecifikujú mapovanie zo množiny entít ZAMESTNANCA na množiny hodnôt FIRST-NAME a LAST-NAME. Atribút a množina hodnôt sú teda rozdielne pojmy, hoci v niektorých prípadoch môžu mať rovnaký názov (napríklad atribút ZAMESTNANCA-NO (ČÍSLO ZAMESTNANCOV) určuje mapovanie zo ZAMESTNANCA (ZAMESTNANCI) na množinu ZAMESTNANEC-NIE (ČÍSLO -SERVER)). Toto rozlíšenie nie je explicitné v sieťovom modeli a v mnohých existujúcich systémoch správy údajov. Všimnite si tiež, že atribút je definovaný ako funkcia. Preto mapuje danú entitu na jednu hodnotu (alebo jednu n-ticu hodnôt v prípade karteziánskeho súčinu množín hodnôt).

Ryža. 2. Atribúty definované na množine entít PERSON

Upozorňujeme, že odkazy majú aj atribúty. Zvážte súbor vzťahov PROJEKT – PRACOVNÍK (obrázok 3). Atribút PERCENTAGE-OF-TIME, ktorý predstavuje časť času prideleného konkrétnemu zamestnancovi na konkrétny projekt, je atribút definovaný na množine prepojení PROJECT-WORKER. Nejde ani o atribút entity ZAMESTNANEC, ani o atribút entity PROJEKTU, keďže jej význam závisí od zamestnanca aj od projektu. Koncept atribútu odkazu je dôležitý pre pochopenie sémantiky údajov a definovanie funkčných závislostí medzi údajmi.

Ryža. 3. Atribúty definované na množine odkazov PROJECT-WORKER

Koncepčná štruktúra informácií.

Teraz budeme diskutovať o tom, ako môžete usporiadať informácie o entitách a vzťahoch. Tento článok navrhuje metódu na oddelenie informácií o entitách a informácií o vzťahoch. Ukážeme, že toto oddelenie je užitočné na identifikáciu funkčných závislostí medzi údajmi.

Na obr. 4 poskytuje informácie o entitách v množine entít vo forme tabuľky. Každý riadok hodnôt odkazuje na rovnakú entitu a každý stĺpec odkazuje na množinu hodnôt, ktoré zase odkazujú na atribút. Poradie riadkov a stĺpcov nie je podstatné.

Ryža. 4. Informácie o entitách zo skupiny entít (tabuľková forma)

Ryža. 5. Informácie o odkazoch zo skupiny odkazov (tabuľková forma)

Na obr. 5 poskytuje informácie o vzťahoch v súbore vzťahov. Všimnite si, že každý riadok hodnôt sa vzťahuje na vzťah, ktorý je označený skupinou entít, z ktorých každá má špecifickú úlohu a patrí do konkrétnej množiny entít.

Všimnite si, že na obr. Obrázky 4 a 2 (rovnako ako obrázky 5 a 3) zobrazujú rôzne formy tej istej informácie. Tabuľkový formulár sa používa na uľahčenie prepojenia s relačným modelom.

Informačná štruktúra

Entity, spojenia a významy na úrovni 1 (pozri obrázok 2-5) sú konceptuálne objekty, ktoré existujú v našej predstavivosti (tj boli sme v konceptuálnej sfére). Na úrovni 2 sa pozrieme na reprezentácie konceptuálnych objektov. Predpokladáme, že existujú bezprostredné reprezentácie hodnôt. Ďalej popíšeme, ako môžete reprezentovať entity a vzťahy.

Primárny kľúč.

Na obr. 2 hodnoty pre atribút ZAMESTNANEC-NIE možno použiť na identifikáciu entít v skupine entít ZAMESTNANCOV, ak má každý zamestnanec jedinečné číslo zamestnanca. Môže sa stať, že na identifikáciu entít v skupine entít je potrebných viac ako jeden atribút. Je tiež možné, že na identifikáciu entít sa použije viacero skupín atribútov. Kľúč entity je v podstate skupina atribútov, takže mapovanie zo sady entít na zodpovedajúcu skupinu množín hodnôt je mapovanie jedna ku jednej. Ak nie je možné nájsť takéto mapovanie na dostupných údajoch, alebo ak je požadovaná jednoduchosť pri identifikácii objektov, potom je možné umelo určiť atribút a množinu hodnôt, aby sa dosiahlo mapovanie jedna ku jednej. V prípade viacerých kľúčov sa ako primárny kľúč entity (PK) zvyčajne volí sémanticky významný kľúč.

Ryža. 6. Reprezentácia entít hodnotami (číslami zamestnancov)

Ryža. 6 sa získa zlúčením množiny entít ZAMESTNANCA s množinou hodnôt ZAMESTNANC-NIE z obr. 2. Venujme pozornosť niektorým sémantickým dôsledkom obr. 6. Každá hodnota v množine hodnôt ZAMESTNANEC-NIE predstavuje subjekt (zamestnanca). Atribúty určujú mapovanie zo súboru hodnôt EMPLOYEE-NO na iné súbory hodnôt. Všimnite si tiež, že atribút EMPLOYEE-NO špecifikuje mapovanie hodnoty EMPLOYEE-NO nastavenej na seba.

Vzťah entity / vzťahu.

Informácie o entitách vo viacerých entitách môžu byť teraz usporiadané vo forme znázornenej na obr. 7. Všimnite si, že obr. 7 je podobný obr. 4, okrem toho, že entity sú reprezentované hodnotami ich primárneho kľúča. Celá tabuľka na obr. 7 predstavuje vzťah entity a každý riadok predstavuje n-ticu entít.

V niektorých prípadoch nemožno entity v množine entít jednoznačne identifikovať podľa hodnôt ich vlastných atribútov; preto na ich identifikáciu musíme použiť odkaz(y). Zoberme si napríklad závislé a podporné entity: podriadení sú identifikovaní podľa svojich mien a hodnôt primárneho kľúča zamestnancov-nadriadených (t. j. ich vzťahov s týmito zamestnancami). Všimnite si, že na obr. 9 ZAMESTNANEC-NIE nie je atribútom subjektov v množine ZÁVISLÁ, ale je primárnym kľúčom zamestnancov, ktorí majú podriadených. Každý riadok hodnôt na obr. 9 je množina entít s primárnymi kľúčmi EMPLOYEE-NO a NAME. Celá tabuľka je vzťah entity.

Teoreticky možno na identifikáciu entít použiť akýkoľvek druh vzťahu. Pre jednoduchosť sa obmedzíme len na jeden druh vzťahu: binárne vzťahy s zobrazením 1:n, v ktorých existencia n entít na jednej strane vzťahu závisí od existencie jednej entity na druhej strane vzťahu. . Napríklad jeden zamestnanec môže mať n (n = 0, 1, 2, ...) podriadených a existencia podriadených závisí od existencie zodpovedajúceho zamestnanca-nadriadeného.

Tento spôsob identifikácie entít vzťahmi s inými entitami je možné aplikovať rekurzívne, kým neexistujú entity, ktoré možno identifikovať podľa hodnôt ich vlastných atribútov. Napríklad primárny kľúč oddelenia v spoločnosti môže pozostávať z čísla oddelenia a primárneho kľúča oddelenia, ktorý sa skladá z čísla oddelenia a názvu spoločnosti.

Preto máme dve formy vzťahu entít. Ak sa na identifikáciu entít používajú vzťahy, budeme to nazývať slabý vzťah entít (obrázok 9). Ak sa na identifikáciu entít nepoužívajú vzťahy, budeme to nazývať bežný vzťah entít (obrázok 8). Ak sú niektoré entity vo vzťahu identifikované inými vzťahmi, budeme to nazývať slabým vzťahovým vzťahom. Napríklad akýkoľvek vzťah medzi ZÁVISLÝMI entitami a inými entitami povedie k vytvoreniu slabých vzťahových vzťahov, keďže ZÁVISLÁ entita je identifikovaná svojim názvom a vzťahom s entitou ZAMESTNANEC. Rozlišovanie medzi pravidelnými a voľnými vzťahmi entít a vzťahov pomôže zachovať integritu údajov.