Kuvaus er-kaaviosta. Hei opiskelija. Käsitteellinen tietokantamalli on

Työn tavoite

"Entity-Relationship" -mallin luomisen menetelmiin ja algoritmeihin tutustuminen.

Entiteetti-suhdemallin peruskäsitteet. ER mallit.

Tietomallia käytetään tietokannan suunnittelun toisessa vaiheessa sanallisen kuvauksen jälkeen aihealue. Sen tulee sisältää muodollinen kuvaus aihealueesta, jota sekä tietokantaasiantuntijat että kaikki käyttäjät voivat helposti "lukea". Tämän kuvauksen tulee olla niin laaja, että on mahdollista arvioida tietokantaprojektin kehityksen syvyyttä ja oikeellisuutta, eikä sitä tietenkään tule sitoa tiettyyn DBMS:ään. DBMS:n valitseminen on erillinen tehtävä ratkaistaksesi sen oikein, sinulla on oltava projekti, joka ei ole sidottu mihinkään tiettyyn tietokantajärjestelmään.

Infologinen suunnittelu liittyy ensisijaisesti yritykseen esittää aihealueen semantiikkaa tietokantamallissa, mikä heijastuu huonosti verkko-, hierarkkisissa tietomalleissa.

On ehdotettu useita tietomalleja, joita kutsutaan semanttisiksi malleiksi. Kaikilla näillä malleilla oli positiiviset ja negatiiviset puolensa, mutta vain "entiteetti-suhde"-mallista tai entiteettisuhteista tuli de facto standardi infologisessa tietokantamallinnuksessa. Lyhennetty nimi ER-malli on tullut yleisesti hyväksytyksi, ja useimmat nykyaikaiset CASE-työkalut sisältävät työkaluja tietojen kuvaamiseen tämän mallin formalismissa. Lisäksi on kehitetty menetelmiä tietokantaprojektin automaattiseen muuntamiseen ER-mallista relaatiotietokantaan ja samalla muuntamalla tiettyyn DBMS-malliin. Kaikissa CASE-järjestelmissä on kehitetty työkaluja kehitysprosessin dokumentoimiseksi automaattisten raporttien luojien avulla nykyinen tila projekti, jossa on yksityiskohtainen kuvaus tietokantaobjekteista ja niiden suhteista, mikä helpottaa huomattavasti projektinhallintaa.

Kuten missä tahansa mallissa, "entiteetti-suhde" -mallissa on useita peruskäsitteitä, joista enemmän monimutkaisia ​​esineitä ennalta määrättyjen sääntöjen mukaan. Tämä malli on parhaiten sopusoinnussa olio-suunnittelun käsitteen kanssa, joka on perustavanlaatuinen monimutkaisten ohjelmistojärjestelmien kehittämisessä.

Tarkastellaanpa ER-mallin taustalla olevia peruskäsitteitä.

1. olemus, jonka avulla mallinnetaan samantyyppisten objektien luokka. Entiteetillä on yksilöllinen nimi mallinnettavassa järjestelmässä. Koska entiteetti vastaa tiettyä samantyyppisten objektien luokkaa, oletetaan, että tätä entiteettiä on useita esiintymiä järjestelmässä. Objektilla, jota kokonaisuuden käsite vastaa, on oma joukko attribuutit - ominaisuudet, jotka määrittävät tietyn luokan edustajan ominaisuudet. Tässä tapauksessa attribuuttijoukon on oltava sellainen, että on mahdollista erottaa entiteetin tietyt esiintymät. Esimerkiksi kokonaisuus Työntekijä Voi olla seuraava setti Ominaisuudet: Henkilöstönumero, Sukunimi, Etunimi, Isännimi, Syntymäaika, Lasten määrä, Sukulaisten oleskelu ulkomailla. Kutsutaan attribuuttijoukko, joka yksilöi entiteetin tietyn esiintymän avain. Työntekijä-yksikön avainattribuutti on Henkilöstönumero, koska henkilöstönumerot ovat erilaisia ​​tietyn yrityksen kaikilla työntekijöillä. Kokonaisuuden esiintymä Työntekijä siellä on kuvaus tietystä yrityksen työntekijästä. Yksi yleisimmistä entiteetin graafisista esityksistä on suorakulmio, jonka yläosaan on kirjoitettu entiteetin nimi ja alla luetellut attribuutit, joiden tärkeimmät attribuutit on merkitty esimerkiksi alleviivauksella tai erityisellä fontilla, kuten alla on esitetty:

2. Kokonaisuudet voidaan muodostaa viestintä - binaariset assosiaatiot , näyttää kuinka kokonaisuudet liittyvät toisiinsa tai ovat vuorovaikutuksessa keskenään. Suhde voi olla kahden eri entiteetin välillä tai kokonaisuuden ja itsensä välillä (rekursiivinen yhteys). Se näyttää kuinka entiteettiinstanssit liittyvät toisiinsa. Jos suhde muodostetaan kahden entiteetin välille, se määrittelee suhteen yhden ja toisen entiteetin esiintymien välillä. Jos esimerkiksi Opiskelija-kokonaisuuden ja Opettaja-kokonaisuuden välillä on yhteys ja tämä yhteys on diplomiprojektien ohjaus, niin jokaisella opiskelijalla on vain yksi ohjaaja, mutta sama opettaja voi ohjata useita jatko-opiskelijoita. Siksi se on yksi-moneen-suhde (1:M), yksi "Opettaja"-puolella ja monet "Oppilas"-puolella (kuva 10.1.).

3. Eri merkinnöissä viestintäteho on kuvattu eri tavalla. Tarkastetussa esimerkissä monikertaisuus esitetään jakamalla viestintälinja kolmeen. Yhteydellä on yleinen nimi"Diploma Design" ja sillä on roolinimet molemmilla kokonaisuuksilla. Opiskelijan puolelta tätä roolia kutsutaan nimellä "Ohjataanko projektia" opettajan puolelta tätä yhteyttä kutsutaan nimellä "Johtaa". Suhteen graafisen tulkinnan avulla voit heti lukea entiteettien välisen suhteen merkityksen, se on visuaalinen ja helppo tulkita. Liitännät on jaettu kolmeen tyyppiin niiden moninaisuuden mukaan: Yksi yhteen (1:1), yksi-moneen(1 milj.), monesta moneen(MM). Yksi-yhteen-suhde tarkoittaa, että yhden entiteetin ilmentymä liittyy vain yhteen toisen entiteetin esiintymään. Suhde 1: M tarkoittaa, että suhteen vasemmalla puolella sijaitsevan entiteetin yksi esiintymä voidaan liittää useisiin suhteen oikealla puolella sijaitsevan entiteetin esiintymiin. Monista moneen (M:M) -suhde tarkoittaa, että ensimmäisen entiteetin yksi ilmentymä voidaan liittää useisiin toisen entiteetin esiintymiin, ja päinvastoin, toisen entiteetin yksi ilmentymä voidaan liittää useisiin ensimmäisen entiteetin esiintymiin. . Esimerkiksi "Opiskelu"-tyyppinen suhde entiteettien "Student" ja "Dicipline" välillä on tyyppiä "monesta moneen" (M:M) oleva suhde, koska jokainen opiskelija voi opiskella useita tieteenaloja ja jokainen tieteenala on monet opiskelijat opiskelevat. Tämä kytkentä on esitetty kuvassa. 10.2.

4. Kahden entiteetin välille voidaan määrittää mikä tahansa määrä yhteyksiä, joilla on erilainen semanttinen kuormitus. Esimerkiksi kahden entiteetin "Opiskelija" ja "Opettaja" välille voidaan muodostaa kaksi semanttista yhteyttä, joista toinen on aiemmin käsitelty "Diploma Design" ja toinen on ehdollisesti nimeltään "Luennot", ja se määrittää minkä opettajien luennot tämä opiskelija kuuntelee ja jota Tämä opettaja pitää luentoja opiskelijoille. On selvää, että tämä on yhteys monesta moneen.

5. Viestintä mitä tahansa näistä tyypeistä voi olla pakollinen, jos kokonaisuuden jokaisen esiintymän on osallistuttava tiettyyn suhteeseen, ja valinnainen- jos ei jokaisen kokonaisuuden esiintymän on osallistuttava tiettyyn suhteeseen. Tässä tapauksessa yhteys voi olla toisaalta pakollinen Ja toisaalta valinnainen. Myös yhteyden pakollisuus on merkitty eri tavoin eri merkinnöissä. Yhteyden valinnaisuus voidaan ilmaista tyhjällä ympyrällä yhteyden lopussa ja kohtisuoran suoran pakollisuudesta, joka ylittää yhteyden. Ja tällä merkinnällä on yksinkertainen tulkinta. Ympyrä tarkoittaa, että mikään instanssi ei voi osallistua tähän yhteyteen. Ja kohtisuora tulkitaan tarkoittavan, että ainakin yksi kokonaisuuden esiintymä on mukana tässä yhteydessä.

Aiemmin annetussa "Diploma Design" -liitännän esimerkissä tämä liitäntä tulkitaan valinnaiseksi molemmin puolin. Itse asiassa jokaisella opinnäytetyötä tekevällä opiskelijalla tulee olla oma opinnäytetyön ohjaaja, mutta toisaalta jokainen opettaja ei johda opinnäytetyötä. Siksi tässä semanttisessa muotoilussa tämän yhteyden kuva muuttuu ja näyttää samalta kuin kuvassa 1. 10.3.

Luomalla toimialuemalli joukon entiteettien ja suhteiden muodossa saamme yhdistetyn graafin. Tuloksena olevassa kaaviossa on välttämätöntä välttää syklisiä yhteyksiä - ne paljastavat mallin virheellisyyden.

Esimerkki ER-mallin luomisesta

Suunnitellaan tietomalli järjestelmästä, joka on suunniteltu tallentamaan tietoa kirjastossa esitellyistä kirjoista ja osaamisalueista. Aloitetaan mallin kehittäminen tunnistamalla pääkokonaisuudet.

Ensinnäkin on "Kirjan" ydin; Jokaisella kirjalla on ainutlaatuinen salaus, joka on sen avain, ja joukko attribuutteja, jotka on otettu aihealueen kuvauksesta. Entiteettiinstanssien joukko määrittää kirjastoon tallennettujen kirjojen joukon. Jokainen "Kirja"-kokonaisuuden esiintymä ei vastaa tiettyä kirjaa hyllyssä, vaan tietyn kirjan kuvausta, joka yleensä annetaan kirjaston aiheluettelossa. Jokainen kirja voi olla useana kappaleena, ja nämä ovat vain niitä kirjoja, jotka ovat kirjaston hyllyillä. Tämän heijastamiseksi sinun tulee ottaa käyttöön Instances-entiteetti, jonka pitäisi sisältää kuvaukset kaikista kirjastoon tallennetuista kirjojen kopioista. Jokainen Instances-entiteetin esiintymä vastaa tiettyä kirjaa hyllyssä. Jokaisella kopiolla on yksilöllinen tunnusnumero, joka yksilöi tietyn kirjan. Lisäksi jokainen kirjan kopio voi olla joko kirjastossa tai tietyn lukijan käsissä, ja jälkimmäisessä tapauksessa tietyn kappaleen osalta päivämäärä, jolloin lukija otti kirjan, ja päivämäärä, jolloin kirjan odotettu palautuspäivä on. kirja on lisäksi merkitty.

Entiteettien "Kirjat" ja "Esimerkit" välillä on suhde (1:M), joka on pakollinen molemmilla puolilla. Mikä määrää tämä tyyppi yhteyksiä? Jokainen kirja voi olla kirjastossa useana kappaleena, joten - 1:M-suhde. Lisäksi, jos kirjastolla ei ole ainuttakaan kopiota tietystä kirjasta, emme tallenna sen kuvausta, joten jos kirja on kuvattu "Kirja"-oliossa, niin vähintään yksi kappale tästä kirjasta on kirjastossa, mikä tarkoittaa, että kirjan puolelta yhteys on pakollinen. Mitä tulee "Kopiot" -kokonaisuuteen, kirjastossa ei voi olla ainuttakaan kopiota, joka ei liittyisi tiettyyn kirjaan, joten yhteys "Kopiot"-puolelta on myös pakollinen.

Nyt sinun on määritettävä, kuinka lukija esitetään järjestelmässä. Tätä tarkoitusta varten on luonnollista ehdottaa "Lukijat"-kokonaisuuden käyttöönottoa, jonka jokainen esiintymä vastaa tiettyä lukijaa. Kirjastossa jokaiselle lukijalle annetaan yksilöllinen kirjastokorttinumero, joka yksilöi lukijan. Kirjastokortin numero on Readers-kokonaisuuden keskeinen attribuutti. Lisäksi "Readers"-olion on sisällettävä lisäattribuutteja, joita tarvitaan määritettyjen tehtävien ratkaisemiseen. nämä määritteet ovat: "Sukunimi Etunimi Isännimi", "Lukijan osoite", "Kotipuhelin" ja "Työpuhelin". Lisäksi "Lukijat" -kohteeseen tulee syöttää "Date of Birth" -attribuutti, jonka avulla voit hallita lukijoiden ikää.

Jokainen lukija voi pitää kädessään useita kirjoja. Tämän tilanteen heijastamiseksi on luotava yhteys "Lukijat" ja "Kopiot" entiteettien välille, koska lukija ottaa kirjastosta tietyn kopion tietystä kirjasta, ei vain kirjaa. Ja voit selvittää, mikä kirja tietyllä lukijalla on lisäviestintää entiteettien "Kopiot" ja "Kirjat" välillä ja tämä yhteys liittää jokaisen kopion yhteen kirjaan, joten on aina mahdollista yksiselitteisesti määrittää, mitkä kirjat ovat lukijan käsissä, vaikka yhdistämmekin vain otettujen kirjojen inventaarionumerot lukijan kanssa. 1:M-suhde muodostetaan "Readers"- ja "Instances"-olioiden välille, ja samalla se on valinnainen molemmilla puolilla. Lukija ei voi tällä hetkellä pitää käsissään ainuttakaan kirjaa, ja toisaalta tämä kirjan kopio ei välttämättä ole kenenkään lukijan hallussa, vaan se voi vain seisoa kirjaston hyllyssä.

Nyt sinun pitäisi heijastaa viimeksi yhdistettyä entiteettiä järjestelmähakemisto, joka sisältää luettelon kaikista tietoalueista, joista tiedot sisältyvät kirjaston kirjoihin. Tietoalueen nimi voi olla pitkä ja koostua useista sanoista, joten järjestelmäluettelon mallintamiseksi otamme käyttöön kokonaisuuden "Järjestelmäkatalogi", jossa on kaksi attribuuttia: "Tietoaluekoodi" ja "Tietoalueen nimi". Knowledge Area Code -määrite on entiteetin avainattribuutti.

Aihealueen kuvauksesta tiedetään, että jokainen kirja voi sisältää tietoa useilta tietoalueilta, ja toisaalta kirjastossa voi olla useita samaan tietoalueeseen liittyviä kirjoja, joten on tarpeen selvittää entiteettien “System Catalog” ja “Books” välillä M:M-yhteys, pakollinen molemmilla puolilla. Itse asiassa järjestelmäluettelo ei saa sisältää sellaista tietoaluetta, josta ei ole tietoa missään kirjaston kirjassa. Ja päinvastoin, jokainen kirja tulisi osoittaa yhdelle tai useammalle tietoalueelle, jotta lukija löytää sen nopeammin.

"Kirjasto"-aihealueen ER-malli on esitetty kuvassa. 10.4

Tietomalli ”Kirjasto” kehitettiin aiemmin lueteltuihin tehtäviin. Heillä ei ole ehtoa tallentaa kirjan lukuhistoriaa esimerkiksi sellaisen henkilön löytämiseksi, joka on aiemmin pitänyt kirjaa hallussaan ja olisi voinut vahingoittaa sitä. Jos tämän tiedon tallentamisen tehtävä olisi asetettu, niin infologinen malli olisi ollut erilainen.

ER-kaavioiden normalisointi

Tietomallia käytetään projektin kehittämisen alkuvaiheessa. Jos ymmärrät kieltä symboleja, jotka vastaavat ER-mallin luokkia, se voidaan helposti "lukea", joten se on yksittäisiä sovelluksia kehittävien ohjelmoijakehittäjien analysoitavissa. Sillä on yksiselitteinen tulkinta, toisin kuin jotkin luonnollisen kielen lauseet, ja siksi kehittäjien puolelta ei voi tulla väärinkäsityksiä.

Asiantuntijat ilmaisevat aina mieluummin ajatuksensa jollain muodollisella kielellä, joka varmistaa niiden yksiselitteisen tulkinnan. Tällainen ohjelmoijien kieli on algoritmien kieli. Jokaisella algoritmilla on yksiselitteinen tulkinta. Se toteutetaan eri kieliä ohjelmointi, mutta itse algoritmi pysyy ennallaan. Algoritmien kuvaamiseen käytetään erilaisia ​​formalismeja.

ER-mallikielestä on tullut perinteisesti hyväksytty kieli tietokannan kuvauksessa. ER-mallille on olemassa algoritmi, jolla se muunnetaan yksiselitteisesti relaatiotietomalliksi, mikä mahdollisti myöhemmin monien instrumentaalisten järjestelmien kehittämisen, jotka tukevat tietokantateknologiaan perustuvien tietojärjestelmien kehittämisprosessia. Ja kaikissa näissä järjestelmissä on keinot kuvata kehitettävän tietokannan infologista mallia ja mahdollisuus generoida automaattisesti dataloginen malli, jonka pohjalta projektia tulevaisuudessa toteutetaan.

Säännöt ER-mallin muuntamiseksi relaatiotietokannaksi

Tarkastellaan sääntöjä ER-mallin muuntamiseksi relaatiotietokannaksi.

1. Jokainen entiteetti on liitetty relaatioon relaatiotietomallissa. Tässä tapauksessa entiteetin nimet ja suhde voivat olla erilaisia, koska entiteettien nimiin ei voi kohdistua muita syntaktisia rajoituksia kuin mallin nimen ainutlaatuisuus. Suhteiden nimet voivat olla rajoitettuja tietyn DBMS:n vaatimusten mukaan. Useimmiten nämä nimet ovat tunnisteita joissakin peruskieli, niiden pituus on rajoitettu, eivätkä ne saa sisältää välilyöntejä tai erikoismerkkejä. Esimerkiksi kokonaisuus voidaan nimetä « Kirjaluettelo”, ja on suositeltavaa nimetä vastaava suhde, esimerkiksi KIRJAT (ilman välilyöntejä ja latinalaisin kirjaimin).

2. Jokaisesta entiteettiattribuutista tulee vastaavan suhteen attribuutti. Attribuuttien uudelleennimeämisen on tapahduttava samojen sääntöjen mukaisesti kuin suhteiden uudelleennimeämisessä kappaleessa 1. Jokaiselle attribuutille määritetään tietty tietotyyppi, joka on sallittu DBMS:ssä ja onko tämä attribuutti pakollinen vai valinnainen vai ei.

3. Entiteetin ensisijaisesta avaimesta tulee vastaavan suhteen ENSISIJAINEN AVAIN. Suhteen ensisijaiseen avaimeen sisältyvät attribuutit vaaditaan automaattisesti.

4. Jokaiseen alikokonaisuutta vastaavaan suhteeseen lisätään pääentiteetin attribuuttijoukko, joka on pääolion ensisijainen avain. Alaosaa vastaavassa suhteessa tästä attribuuttijoukosta tulee vierasavain.

5. Valinnaisen suhteen mallintamiseksi fyysisellä tasolla vierasavainta vastaavat attribuutit asetetaan sallimaan nolla-arvot. Kun yhteystyyppi on pakollinen, määritteillä ei ole tyhjäarvoja.

On mahdollista luoda vain yksi suhde yhden supertyypin kaikille alatyypeille. Se sisältää kaikkien alatyyppien kaikki attribuutit, mutta useissa tapauksissa useilla määritteillä ei ole järkeä. Ja vaikka niillä on määrittelemätön merkitys, tarvitaan lisäsääntöjä alatyypin erottamiseksi toisesta. Tämän esityksen etuna on, että luodaan vain yksi suhde.

Toisessa menetelmässä kullekin alatyypille ja supertyypille luodaan erilliset suhteet. Tämän esitystavan haittana on, että se luo paljon suhteita, mutta tällä menetelmällä on enemmän etuja, koska työskentelet vain alatyypin merkittävien attribuuttien kanssa. Lisäksi supertyypistä alatyyppeihin siirtymisen mahdollistamiseksi on välttämätöntä sisällyttää supertyyppiin yhteystunniste.

7. Lisäksi, kun kuvataan tyypin ja alatyyppien välistä suhdetta, on tarpeen ilmoittaa erottimen tyyppi. Syrjijä voi olla toisensa poissulkeva tai ei. Jos tämä erottimen tyyppi on asetettu, se tarkoittaa, että yksi supertyyppientiteetin ilmentymä liittyy vain yhteen alatyyppientiteetin ilmentymään, ja jokaiselle supertyyppientiteetin ilmentymälle on lapsi. Lisäksi sinun on määritettävä toiselle menetelmälle, peritäänkö alatyyppeihin vain supertyypin tunniste vai peritäänkö kaikki supertyypin attribuutit.

8. Jos ER-kaaviossa on M:M-suhde (relaatiot), jota relaatiomalli ei tue, otetaan käyttöön erityinen yhdistävä relaatio, joka liitetään jokaiseen alkuperäiseen suhteeseen 1:M-suhteella. Tämän suhteen attribuutit ovat niihin liittyvien suhteiden ensisijaisia ​​avaimia.

Algoritmi semanttisen mallin tuomiseksi 3NF:ään

Algoritmi semanttisen mallin pelkistämiseksi kolmanteen normaalimuotoon voi olla seuraava:

1. Analysoi kaaviosta sellaisten entiteettien läsnäoloa, jotka mallintavat piilossa useita erilaisia ​​toisiinsa liittyviä objektiluokkia todellista maailmaa(tämä on juuri sitä, mikä vastaa normalisoimattomia suhteita). Jos tämä havaitaan, jaa kukin näistä kokonaisuuksista useiksi uusiksi kokonaisuuksiksi ja luo asianmukaiset yhteydet niiden välille; tuloksena oleva piiri on ensimmäisessä normaalimuodossa.

2. Analysoi kaikki entiteetit, joilla on yhdistetyt ensisijaiset avaimet, epätäydellisten ei-ensisijaisten attribuuttien toiminnallisten riippuvuuksien esiintymisen varalta ehdokasavaimen attribuuteista. Jos tällaisia ​​riippuvuuksia löytyy, jaa nämä entiteetit kahteen osaan, määritä kunkin entiteetin ensisijaiset avaimet ja luo asianmukaiset suhteet niiden välille. Tuloksena oleva piiri on toisessa normaalimuodossa.

3. Analysoi kaikkien entiteettien ei-avainattribuutit transitiivisten toiminnallisten riippuvuuksien esiintymisen varalta. Jos niitä löytyy, jaa jokainen kokonaisuus useisiin transitiivisten riippuvuuksien eliminoimiseksi. Piiri on kolmannessa normaalimuodossa.

Tarkastettujen säännösten avulla normalisoimme ER-kaavion. Normalisoinnin tulos näkyy kuvassa. 5. Kaavaa normalisoitaessa otettiin siihen relaatio ”Kirja-luettelosuhteet”, joka sisältää attribuutit ”ISBN” ja ”Knowledge Area Code”, jotka palvelevat M:M-yhteyden ”Kirjat - systemaattinen luettelo” toteuttamista. relaatioon "Kopiot" sen suhteiden "Kirjat" ja "Lukijat" yhteydessä otettiin käyttöön attribuutit "Kirjastokortin numero" ja "ISBN". Nuolet osoittavat liitäntöjen suunnan.

Voidaan osoittaa, että kuvan kaavio. 10.5 täyttää 3. normaalimuodon vaatimukset.

Työmääräys

1. Suorita semanttinen alueanalyysi alla olevaa esimerkkiä varten.

Esimerkki. IS-aihealue: Henkilöstöosasto.

Ominaisuuksien vähimmäisluettelo:

    Koko nimi, kotiosoite, puhelinnumero, syntymäaika, asema, ilmoittautumispäivä, palvelusaika, koulutus;

    kunkin työntekijän perheenjäsenten sukunimi, etunimi, sukunimi ja syntymäaika;

    osaston nimi, henkilöstömäärä, palkka, palkkasumma kuukaudelta ja vuodelta.

2. Kuvittele aihealue ER-mallina käyttämällä yllä olevaa metodologiaa.

3. Käytä edellä käsiteltyä ER-mallin normalisointitekniikkaa, vähennä kehitetty ER-malli 3NF:ksi.

4. Näytä työn tulokset raportin kaikissa vaiheissa.

ER-kaavio

Kuten aiemmin todettiin, yksi semanttisen mallinnuksen päätavoitteista on varmistaa, että aihealueen analyysin tulokset heijastuvat melko yksinkertaisessa, visuaalisessa, mutta samalla formalisoidussa ja riittävän informatiivisessa muodossa.

Tässä mielessä ER-kaavio on erittäin hyvä ratkaisu. Siinä yhdistyvät toiminnalliset ja informaatiolähestymistavat, mikä mahdollistaa sekä suoritettavien toimintojen sarjan että tietorakenteiden määrittelemien järjestelmän elementtien välisten suhteiden esittämisen. Samalla graafinen muoto mahdollistaa kokonaisuuksien ja suhteiden typologian ja ominaisuuksien näyttämisen kompaktissa muodossa (visuaalisten symbolien ansiosta) ja ER-kaavioiden taustalla olevat formalismit mahdollistavat seuraava askel design looginen rakenne tietokannassa on tiukka normalisointilaitteisto.

Entiteetit. Jokainen entiteettityyppi ER-kaavioissa esitetään suorakulmiona, joka sisältää kokonaisuuden nimen. Substantiivit (tai substantiivin lauseet) käytetään yleensä nimissä yksikkö. Heikkotyyppisten kokonaisuuksien heijastamiseksi käytetään suorakulmioita, joiden sivut on piirretty kaksoisviivoilla. Esimerkiksi alla käsitellyssä ER-kaaviossa, joka on esitetty kuvassa. 5.4, ​​SUBJECT - heikon tyyppinen kokonaisuus.

Ominaisuudet. Ominaisuudet selventävät, tunnistavat, karakterisoivat tai ilmaisevat kokonaisuuden tai suhteen tilaa. Ominaisuudet näytetään ellipseinä, jotka sisältävät ominaisuuden nimen. Ellipsi on yhdistetty vastaavaan kokonaisuuteen tai suhteeseen viivalla.

Avainominaisuuksien nimet on alleviivattu, esimerkiksi HENKILÖSTÖ-kokonaisuuden "Personnel number" -ominaisuus.

Ellipsin ääriviivat piirretään kaksoisviivalla, jos ominaisuus on moniarvoinen, esimerkiksi TYÖNTEKIJÄ-entiteetin ominaisuus "Erikoisuus".

Ellipsin ääriviivat piirretään katkoviivalla, jos ominaisuus on johdettu, esimerkiksi TOIMITTAJAN kokonaisuuden "Qty"-ominaisuus.

Ellipsi yhdistetään katkoviivalla, jos ominaisuus on ehdollinen, esimerkiksi ominaisuus " Vieras kieli» EMPLOYEE-yksiköt.

Jos ominaisuus on yhdistelmä, sen muodostavat ominaisuudet näkyvät muilla yhdistelmäellipsiin liitetyillä ellipseillä, esimerkiksi kokonaisuuden "Osoite"-ominaisuus. TYÖNTEKIJÄ sisältää yksinkertaiset ominaisuudet"Kaupunki", "Katu", "Talo".

Liitännät Suhde on graafisesti esitetty assosiaatio, joka on muodostettu entiteettien välille. Jokainen suhdetyyppi ER-kaaviossa on esitetty timanttina, jonka sisällä on suhteen nimi. Niminä käytetään yleensä verbaalisia substantiivija.

Timantin sivut piirretään kaksoisviivoilla, jos kyseessä on yhteys heikon tyyppisen kokonaisuuden ja sen riippuvuuden välillä. Esimerkiksi alisteisuussuhde, joka sitoo heikon tyypin kokonaisuuden AIHE olemuksen kanssa TYÖNTEKIJÄ, josta se riippuu.

Viestinnän osallistujat yhdistetään viestintään linjoilla. Kaksoisviiva tarkoittaa kokonaisuuden täyttä osallistumista tämän puolen yhteydessä. Esimerkiksi SUBJECT-yksikön "alisteisuus"-suhde.

Suhdetta voidaan muokata määrittämällä rooli. Esimerkiksi rekursiiviselle yhteydelle "Composition" määritetään roolit: "Osa sisältää..." ja "Osa mukana yhdiste...».

Luennon tarkoitus: näyttää, miten aihealuetta kuvataan käsitteellisen mallinnuksen aikana (millä käsitteillä, esityskeinoilla ja rakennustekniikoilla) ja miten tietokannan tiedon luotettavuus varmistetaan käsitteellisen mallin eheyden rajoitusten vuoksi.

5.1. Kuvaus aihealueen tiedon esityksestä. ER-kaavio

Havainnollistamme esille tulleita käsitteitä ja tietokannan suunnittelun vaiheita käyttämällä esimerkkiä, joka on lähellä lukijakohtaista aihealue: tietojen esittäminen yliopisto-opiskelijoista. Annetaan Lyhyt kuvaus tarkasteltavana oleva aihealue. Yliopistossa on useita tiedekuntia, joista jokainen tarjoaa koulutusta useilla erikoisaloilla tai aloilla. Tiedekunnalla on jokaiselle erikoisalalle oma opetussuunnitelma, joka sisältää luettelon opiskeluista aineista koulutuskursseja ilmoittamalla tuntien lukumäärän. Opiskelijat opiskelevat asiaankuuluvia tieteenaloja, suorittavat kokeita ja kokeita sekä saavat arvosanoja.

Useammin Havainnemalli esitetään muodossa entiteetti-suhdekaaviot(entiteetti-suhde) tai ER-kaaviot. ER-kaavion rakentamisprosessi kutsutaan ER-mallinnus.

Otetaan käyttöön peruskäsitteet, joilla aihealuetta kuvataan.

Entiteetti tai esine – mihin tietoon kertyy tietojärjestelmä(jotain, jota käyttäjä haluaa tarkkailla).

Jos järjestelmä käsittelee tiedekuntia koskevia tietoja, kokonaisuus on tiedekunta, jos opiskelijoista, kokonaisuus on opiskelija jne.

ER-mallinnuksessa kokonaisuuden nimi kirjoitetaan yleensä isoilla kirjaimilla. Jokaisella kokonaisuudella on tietty joukko ominaisuuksia, jotka tallennetaan tietojärjestelmään (otamme huomioon vain ominaisuudet, jotka kiinnostavat tutkimuksen puitteissa). Eli esim. FACULTY-olion ominaisuuksiksi voit määrittää tiedekunnan numeron, tiedekunnan nimen, STUDENT-kokonaisuuden ominaisuuksiksi voit määrittää sukunimen, syntymäajan, syntymäpaikan, EXAM-olion ominaisuuksiksi - aihe. , kokeen päivämäärä, kokeen vastaanottajat.

Entiteetin informatiivisessa kuvauksessa otetaan käyttöön attribuutin käsite.

Attribuutti on entiteetin nimetty ominaisuus (ominaisuus). Attribuutti on informaationäyttö entiteetin ominaisuudesta ja ottaa tietyn arvon joukosta hyväksyttäviä arvoja. Joten esimerkiksi FACULTY-entiteetin kohdalla entiteetin tietyn esiintymän "nimi"-attribuutti saa "laskennallisen matematiikan ja kybernetiikan" erityisen merkityksen. Joten attribuutti edustaa tietojen kuvaus kokonaisuuden kvantitatiiviset tai laadulliset ominaisuudet, kuvaa kokonaisuuden tilaa, mahdollistaa kokonaisuuden tunnistamisen. Tietoa entiteetistä edustaa joukko attribuutteja. Tätä attribuuttien kokoelmaa kutsutaan usein objektitietueeksi.

Kutsutaan joukko entiteettejä, joita tietojärjestelmässä on luonnehtinut samalla ominaisuusluettelolla entiteettiluokka(joukko esineitä). Joten esimerkiksi kaikkien STUDENT-olioiden kokoelma muodostaa STUDENT-entiteettiluokan, kaikkien TIEDEKUNNAN entiteettien kokoelma FACULTY-entiteettiluokan. Entiteettiluokkaa kuvaa tämän luokan muodostavien entiteettien ominaisuuksien luettelo.

Entiteetin ilmentymää kutsutaan tietyksi entiteetiksi (entiteetti, jolla on tietyt arvot vastaavat ominaisuudet). Yllä määritimme kokonaisuuden joksikin, josta tietoa kerääntyy tietojärjestelmään. Tämä on vain yksi puoli. Tietoa ei pidä vain tallentaa sellaisenaan, vaan käyttää tyydyttämään tiedon tarpeisiin käyttäjä. Toteuttaakseen valtavan määrän pyyntöjä, käyttäjän on ensin löydettävä häntä kiinnostava entiteettiinstanssi(käsittelyä, mukauttamista, poistamista varten). Siksi entiteetin tärkein ominaisuus on sen ilmentymien yksiselitteinen tunnistaminen yhdellä tai attribuuttiryhmällä (yksilöllinen tunniste). FACULTY-yksikölle tämä on esimerkiksi STUDENT-yksikön tiedekunnan numero, se voi olla "sukunimi"-attribuutti, jos kaikilla opiskelijoilla on eri sukunimet, attribuuttiryhmä "sukunimi", "etunimi"; ”, ”isännimi” tai erityisesti syötetty yksilöllinen tunniste, esimerkiksi lisätty attribuutti ”opiskelijakoodi”.

Yleisin tapa esittää käsitteellistä mallia on ns. ER-diagrammi. SISÄÄN eri lähteistä käytetään erilaisia ​​järjestelmiä merkintä ER-kaavioissa. Käytännössä käytössä eri tavoin ER-kaavioiden kirjoittaminen ei ole erityisen vaikeaa - dokumentaation asiaankuuluvan osan nopealla lukemisella voit nopeasti hallita käytetyn merkintäjärjestelmän. SISÄÄN tämä käsikirja ER-kaaviossa edustamme entiteettien luokkaa nelikulmiona. Nelikulmio sisältää entiteettiluokan yksilöivän nimen ( isoilla kirjaimilla) ja määritteiden nimet pienillä kirjaimilla.

Esimerkki STUDENT-entiteettiluokasta ja tietystä entiteettiinstanssista on esitetty kuvassa. 5.1


Riisi. 5.1.

Käyttäjän tietotarpeiden täyttämiseksi ei riitä, että löytää häntä kiinnostavaa tietoa entiteettiinstanssi. Tiedontarpeet liittyvät läheisesti organisaatiossa vallitseviin toiminnallisiin suhteisiin (esim. on selvitettävä, millä osastolla tietty opiskelija opiskelee). Tällaisten pyyntöjen (käyttäjätietotarpeiden) toteuttamiseen käytetään olemassa olevia järjestelmiä. aihealue entiteettien väliset suhteet. Vastaavat entiteettien väliset suhteet ilmaistaan ​​suhteilla. On olemassa linkkiluokkia ja linkkien esiintymiä. Suhdeluokat ovat entiteettiluokkien välisiä suhteita, ja suhdeinstanssit ovat entiteettiinstanssien välisiä suhteita.

Yhteysluokka voi kattaa useita entiteettiluokat. Määrä entiteettiluokat, joka osallistuu yhteyteen, kutsutaan yhteysasteeksi n = 2, 3, ... Joten esimerkiksi entiteettien luokkaan STUDENT liittyy entiteettiluokka TIEDEKUNNAN viestintä "opiskelee tiedekunnassa." Tämän yhteyden aste on kaksi. Kun n = 2, suhdetta kutsutaan binääriseksi. Huomaa, että suhdetta tulee pitää kaksisuuntaisena: "opiskelija opiskelee tiedekunnassa" ja "opiskelijat opiskelevat tiedekunnassa". Tarkastellaanpa binäärisidosten luokittelua. Riippuen kuinka paljon entiteettiinstanssit yksi luokka liittyy kuinka monta entiteettiinstanssit toinen luokka, erota seuraavat tyypit liitännät:

  • 1:1 yhteys. Yhden luokan entiteetin yksi ilmentymä liittyy toisen luokan entiteetin yhteen esiintymään. Esimerkkinä on entiteettiluokkien TIEDEKUNNAN ja OPETUSSUUNNITELMAN välinen yhteys TIEDEKUNNAN ERIKOISALASSA (jokaisella tiedekunnalla on oma opetussuunnitelma erikoisalalla tai suunnalla).
  • Linkki 1:M. Yhden luokan yksi entiteettiesiintymä liittyy useisiin entiteettiinstanssit toinen luokka. Esimerkkinä tiedekunnan ja STUDENT-kokonaisluokkien välinen suhde (yhdessä tiedekunnassa opiskelee monta opiskelijaa).
  • M:N yhteys. Jonkin verran entiteettiinstanssit yksi luokka liittyy useisiin entiteettiinstanssit toinen luokka. Esimerkkinä on entiteettiluokkien FACULTY ja SPECIAALTY välinen yhteys (tiedekunnassa voi olla useita erikoisuuksia ja sama erikoisuus voi olla useissa tiedekunnissa).

Tyyppejä kuvaavat numerot

ER-tietokantamalli

Entiteetti-suhdemallilla (ERM) voit kuvata aihealueen käsitteellisiä kaavioita.

ER-mallia käytetään korkean tason tietokantasuunnittelussa. Sen avulla voit tunnistaa keskeiset entiteetit ja tunnistaa yhteyksiä, jotka voidaan muodostaa näiden entiteettien välille. ER-malli on muodollinen konstruktio, joka ei määrittele graafiset työkalut hänen ideoitaan. Vakiona graafinen esitys ER-malli, entiteetti-suhdekaavio ER-kaavio (Entity Relationship Diagram - ER-kaavio) kehitettiin. Tietokantoja suunniteltaessa ER-malli muunnetaan tietyksi tietokantaskeemaksi.

Kuten tiedetään, peruskonsepti Relaatiotietokanta on taulukko (relaatio). Taulukkoa käytetään tietojen jäsentämiseen ja tallentamiseen. Relaatiotietokannassa jokainen taulukon solu sisältää yhden arvon. Lisäksi yhdessä tietokannassa on taulukoiden välisiä suhteita, joista jokainen määrittelee jakaminen taulukon tiedot.

ER-kaavio esittää graafisesti suunnitellun tietokannan tietorakennetta. Entiteetit näytetään suorakulmioiden avulla, taulukot, jotka sisältävät kokonaisuuden nimen - tietokantataulukko. Entiteettisuhteet näytetään yksittäisiä kokonaisuuksia yhdistävinä linjoina.

Suhde osoittaa, että yhden entiteetin tiedot viittaavat toisen entiteetin tietoihin tai liittyvät niihin.

Sidosten päättymisaste on esitetty graafisesti, ja sidoksen moninkertaisuus on kuvattu "haarukkana" sidoksen lopussa. Yhteyden modaliteetti on kuvattu myös graafisesti - yhteyden valinnaisuus on merkitty ympyrällä yhteyden lopussa. Yhteyden nimeäminen ilmaistaan ​​yhdellä verbillä (kuva 13).

Kuva 13.

Attribuutit entiteetit kirjoitetaan kokonaisuutta edustavan suorakulmion sisään ja ilmaistaan ​​yksikön substantiivilla.

Attribuuteista erottuu entiteettiavain. Kun luot entiteetin, sinun on valittava attribuuttien ryhmä, joka voi olla ensisijainen avain, ja valittava sitten attribuutit, jotka sisällytetään ensisijaiseen avaimeen:

· Ensisijainen avain on valittava siten, että sen sisältämien attribuuttien arvot pystyvät tunnistamaan entiteettiinstanssin tarkasti.

· Millään primaariavaimen attribuutilla ei saa olla nolla-arvoa.

· Ensisijaisen avaimen määritteiden arvojen ei pitäisi muuttua. Jos arvo on muuttunut, kyseessä on entiteetin eri esiintymä.

Kun valitset ensisijaista avainta, syötä pääsääntöisesti entiteetti lisämäärite, josta tulee avain.

Näin ollen ensisijaisen avaimen määrittämiseen käytetään usein yksilöllisiä numeroita, jotka järjestelmä voi generoida automaattisesti lisättäessä entiteettiinstanssia tietokantaan. Sovellus ainutlaatuisia numeroita helpottaa indeksointia ja hakua tietokannasta.

Ensimmäinen askel luomisessa looginen malli Tietokanta on ER-kaavion rakenne, joka koostuu kolmesta osasta: entiteetit, attribuutit ja suhteet.

Eri alustoille on kehitetty monia työkaluja ER-kaavioiden visuaaliseen luomiseen. Tämä projekti käytti kehitystä MySQL Workbench.

Tämä työkalu yksinkertaistaa tietokannan suunnittelua ja ylläpitoa, automatisoi aikaa vievät ja virhealttiit tehtävät ja parantaa viestintää kehitystiimien ja tietokanta-arkkitehtien välillä. Sen avulla data-arkkitehdit voivat visualisoida vaatimuksia, kommunikoida sidosryhmien kanssa suunnitteluasioista ennen kuin projektiin investoidaan. Tämä tarjoaa mallipohjaisen tietokantasuunnittelun, joka on tehokkain menetelmä todellisten ja hyvin suunniteltujen tietokantojen luomiseen. ER - etätestausjärjestelmän tietokantakaavio ( kontrolli_testit) on esitetty kuvassa (kuva 14). Kaksi pystysuorat palkit toisaalta ja "kolmio" toisaalta tarkoittavat vastaavasti "yksi moneen suhdetta".

Riisi. 14. ER - etätestausjärjestelmän ohjaus_testitietokantakaavio


Tietokannan normalisointi

SISÄÄN relaatioteoria Tietokanta Luotettavan, kertakaikkiaan suunnitellun tietokannan suunnittelulle ei ole universaaleja määräyksiä tai lakeja. Kehittäjät tekevät tietokannan suunnittelupäätöksensä tukeutumalla vahvasti kokemukseen, intuitioon ja erilaisiin suunnittelutyökaluihin ja -tekniikoihin.

Joitakin kanoneja ja sääntöjä on kuitenkin edelleen olemassa. Tällaisia ​​sääntöjä ovat muun muassa normalisointisäännöt, ts. palauttaa suhteet normaaliksi.

Haluaisin tehdä pienen lisäyksen Khabravian ueasleyn artikkeleihin Kehitys → Tietokantataulukoiden suhteet ja Kehitys → Tietokantojen suunnittelu.

Haluan kuvata säännöt, joiden mukaan voit rakentaa relaatioskeema Tietokanta. Näistä säännöistä ei todennäköisesti ole kenellekään mitään hyötyä, koska kehittäjät käyttävät niitä intuitiivisella tasolla, mutta ne ovat jopa mielenkiintoisia, koska ne virallistavat tietokantaskeeman rakentamisprosessin.

Nämä säännöt koskevat ER-mallia eli "kokonaissuhde"-mallia.

ER malli

ER-malli on kaavio, jonka komponentit ovat:

  • Essence- tämä on todellinen tai kuvitteellinen kohde, jonka tiedot on tallennettava tietokantaan. ER-mallikaaviossa entiteetti on kuvattu suorakulmiona, joka sisältää kokonaisuuden nimen.
  • Yhteys- assosiaatio kahden (useimmiten) entiteetin tai saman kokonaisuuden välillä (rekursiivinen suhde), joka näytetään graafisesti kaaviossa. Liitos on kuvattu timanttina, jossa on kaksi päätä, yksi kullekin kokonaisuudelle. Tämän yhteyden kummallekin puolelle on määritetty seuraavat:
    1. Assosiaatioaste – kuinka monta tietyn entiteetin esiintymää on liitetty
    2. Pakollinen yhteys - onko tämän kokonaisuuden välttämättä osallistuttava yhteyteen.
Annan sinulle esimerkin:
Oletetaan, että sinun on tallennettava tietoja asiakkaista ja heidän tilauksistaan. Rakennetaan kaavio

Huomaa, että "ORDER"-entiteetin puolelta suhde ilmaistaan ​​ylimääräisellä suorakulmiolla - tämä tarkoittaa, että jokainen "ORDER"-yksikön esiintymä vastaa "CLIENT"-olion esiintymää (asiakkaalle tilausta ei tarvita). Aste "M" tarkoittaa, että jokaiselle "CLIENT"-kokonaisuudelle voi olla useita "ORDER"-olion esiintymiä (mutta ei päinvastoin, koska jokaisessa tilauksessa on aina vain yksi asiakas - asetamme asteen " 1”)

Suhdetta (joka yleensä vastaa tietokannan taulukkoa) ei pidä sekoittaa entiteettiin. Entiteetti muunnetaan suhteeksi erottamalla se ER-kaaviosta.

Suunnittelun vaiheet

  1. Käsitteellinen suunnittelu

    Laaditaan ER-kaavio, joka sisältää kaikki entiteetit ja suhteet. Saamme käsitteellisen (infologisen) mallin. On ymmärrettävä, että tällainen malli ei välttämättä vastaa suhteellinen rakenne suunniteltu tietokanta.

    Oletetaan, että sinun on rakennettava tietokanta, johon sinun on tallennettava täydelliset tiedot tilauksista, asiakkaista, työntekijöistä. Jokaiselle tilaukselle on luettelo tämän tilauksen elementeistä (useita tuotteita), joista jokainen liittyy kulutettujen materiaalien ja suoritettujen toimintojen luetteloon.

    Sain seuraavan kaavion.


    Riisi. 2

  2. Looginen suunnittelu

    Joukko alustavia suhteita muodostetaan, mikä osoittaa kunkin suhteen ensisijaisen avaimen. Attribuuttien luettelo laaditaan, minkä jälkeen nämä attribuutit jaetaan suhteiksi. On välttämätöntä, että kaikki suhteet pysyvät BCNF:n sisällä.

    Siirtyminen relaatiorakenteeseen (suhteiden joukon rakentaminen) tapahtuu seuraavien sääntöjen mukaisesti:

    1. Jos binäärisuhteen aste on 1:1 ja molempien entiteettien jäsenyysluokka vaaditaan, tarvitaan vain yksi suhde. Tämän suhteen ensisijainen avain voi olla jommankumman näistä kahdesta entiteetistä avain. Tässä tapauksessa jokainen avainarvo taataan esiintyvän kerran missä tahansa suhteen esiintymässä.
    2. Jos binäärisuhteen aste on 1:1 ja yhden entiteetin luokka on valinnainen, on tarpeen rakentaa kaksi suhdetta jokaiselle entiteetille. Sen entiteetin avain, jolle jäsenyysluokka on valinnainen, lisätään attribuutiksi vaaditun jäsenyysluokan entiteetille varattuun suhteeseen.
    3. Jos binäärisuhteen aste on 1:1 ja minkään entiteetin jäsenyysluokka on valinnainen, käytetään kolmea suhdetta - yksi kullekin entiteetille - joiden avaimet toimivat ensisijaisina vastaavissa suhteissa ja yksi suhteelle. Suhteelle omistetulla suhteella on yksi entiteettiavain jokaiselta entiteetiltä.
    4. Jos binäärisuhteen aste on 1: M ja M:ään liittyvän entiteetin jäsenyysluokka on pakollinen, riittää, että käytetään kahta relaatiota: yksi kullekin entiteetille edellyttäen, että entiteettiavain toimii ensisijaisena avaimena vastaava suhde. Yksinkertaisesti yhdistetyn entiteetin avain on lisättävä attribuutiksi M-liitetylle entiteetille määritettyyn relaatioon.
    5. Jos binäärisuhteen aste on 1: M ja M:ään liittyvän entiteetin jäsenyysluokka on valinnainen, on käytettävä kolmea suhdetta: yksi entiteetille ja yksi suhteelle. Suhteen attribuuttien joukossa on oltava entiteettiavain jokaiselle entiteetille.
    6. Jos binäärisuhteen aste on M:M, datan tallentamiseen tarvitaan kolme suhdetta: yksi entiteetille ja yksi suhteelle. Entiteettiavaimet sisältyvät suhteeseen. Jos yksi entiteeteista on rappeutunut, on olemassa kaksi suhdetta (eli kaksi taulukkoa riittää).
    7. Kolmisuuntaisessa suhteessa on käytettävä neljää suhdetta: yksi yksikköä kohden ja yksi suhteelle. Yhteyden muodostama relaatio sisältää attribuuttien joukossa kunkin entiteetin entiteettiavaimet.

    Käytetään sääntöjä ja laitetaan tiedot taulukkoon.

    Entiteetit Säännön numero Suhde
    Asiakas
    Tilaus
    4 Asiakas(#Client
    Tilaus (#Tilaus, #Asiakas
    Työntekijä
    Tilaus
    4 Työntekijä (# Työntekijä
    Tilaus (#tilaus, #työntekijä
    Tilaus
    Tilaa kohde
    4 Tilaa (#Tilaa
    Tilauselementti (#Tilauselementti, #Tilaus
    Prikaati
    Tilaa kohde
    4 Prikaati (#prikaatit
    Tilauselementti (#Elementti, #Crew
    Tuote
    Tilaa kohde
    4 Tuote (# Tuotteet
    Tilaa tuote (#Tuotteet, #Tuotteet
    Asiakas
    Tilaus
    6 Asiakas(#Client
    Tilaa (#Tilaa
    Maksu (#Maksu, #Asiakas, #Tilaus
    Prikaati
    Työntekijä
    5 Prikaati (#prikaatit
    Työntekijä (# Työntekijä
    Tiimin työntekijä (#prikaatin työntekijä, #työntekijä, #prikaati
    Tilaa kohde
    Operaatio
    5 Tilaa tuote (#Tuote
    Operation(#Operations
    Tallennustoiminto (#Records, #Element, #Operations
    Tilaa kohde
    Materiaali
    5 Tilaa tuote (#Tuote
    Materiaali (#Material
    Kulutus (#tietueet, #elementti, #materiaali
    Pöytä 1

    Kun attribuutit on jaettu saatujen suhteiden mukaan, saamme (kenttien luettelossa ensinnäkin - pääavain, loput "#":lla merkityt ovat vierasavaimia):

    PRIKAATI (#miehistö, #työnjohtaja, sijainti)
    TYÖNIMIKE (#Asetukset, Asema, Palkka)
    TILAUS (#tilaus, #asiakas, #työntekijä, sijoituspäivä, pakollinen päivämäärä, toteutuspäivä, kuvaus)
    ASIAKAS (#Asiakas, arvonimi, etunimi, sukunimi, organisaatio tai osasto, osoite, puhelinnumero, sähköpostiosoite)
    TALLENNUSTOIMINNOT (#tietueet, #tuote, #toiminta, #työntekijä, määrä)
    MAKSU (#Maksu, #asiakas, #tilaus, maksusumma, maksupäivä, huomautukset)
    KULUTUS (#Records, #Consumables, #Items, Quantity)
    YHDISTE (#tuote, #tilaus, #tuote, #tiimi, määrä)
    SOTRBRIGADA (#CrewBrigade, #Brigade,#Temployee)
    TYÖNTEKIJÄ (#Työntekijä, Passin numero, Sukunimi, Etunimi, Isännimi, #Asema, Osoite, Kotipuhelin, Työpuhelin, Syntymäaika, Palkkauspäivä, Sopimuksen päättymispäivä, Valokuva, Muistiinpanot)
    OPERAATIO (#Toiminnot, Kuvaus, Kustannukset, Aika, Laitteet, Suoritus)
    MATERIAALI (#Exp.Mat, NaimExp.Mat, hinta, tiheys, tyyppi, koostumus)
    TUOTE (#Tuote, merkki, nimi, tuotteen kuvaus, tyyppi, sarjanumero, varastossa, hinta)
    Pöytä 2

Näin meille opetettiin yliopistossa. Ehkä jotakuta kiinnostaa. Mitä tulee kysymykseen "onko tämä tarpeellista", kuuntelen mielipiteitänne!