Andmebaasi kujundamise juhend. Relatsiooniandmebaasi arendamine. Riiklik Teadusülikool

valitsus Venemaa Föderatsioon

Riiklik Teadusülikool

MAJANDUSGÜMNAASIUM

PERMI OSA

osakond infotehnoloogiadäris

Infotehnoloogia sisse kontoritöö

Areng infosüsteem andmebaasihaldussüsteemi kasutavad ettevõtted Juurdepääs andmetele 2007

Õppe- ja metoodiline käsiraamat

Perm 2011

Infotehnoloogia kontoritöös. Ettevõtte infosüsteemi arendamine Access 2007 andmebaasihaldussüsteemi abil. NRU HSE PF, 2011, 40 lk.

Koostanud: Vikentjeva Olga Leonidovna, Lebedev Valeri Viktorovitš.

Haridusjuhend on koostatud vastavalt riiklikule haridusstandardile, õppekava ja distsipliini “Infotehnoloogiad majanduses” kontseptsioon. Käsiraamat on mõeldud Riigiülikooli Majanduskõrgkooli pensioniteaduskonna üliõpilastele ja õppejõududele ning sisaldab sarja praktilised tunnid, mis paljastab kaasaegsete infotehnoloogiate võimed luua süsteeme andmete salvestamiseks, otsimiseks ja esitamiseks.

Retsensent: Permi piirkondliku pedagoogiliste infotehnoloogiate instituudi informaatika osakonna dotsent, pedagoogikateaduste kandidaat, hariduse informatiseerimise akadeemia korrespondentliige Kushev V.O.

Õppetund 1. Disain suhteline alus andmeid

Tavalises tähenduses on andmebaas fail või failide kogum, millel on konkreetne organisatsioon. Töötades aga tavapärased süsteemid failitöötlus tekitab mitmeid probleeme, mis on seotud eelkõige neis salvestatud andmete liiasuse ja sõltuvusega. Andmebaasi kujundamisel need probleemid lahendatakse.

Kasutaja peab osalema andmebaasi kujundamise protsessis, kuna ainult tema saab määrata, milliseid andmeid tööks vaja on, näidata nende andmete vahelisi seoseid ja pöörata tähelepanu nende töötlemise peensustele.

Üksikkasutaja infovajadus puudutab enamasti vaid osa infosüsteemi salvestatud andmetest ning nende vajaduste kirjeldus ei pruugi kattuda teiste kasutajate vajaduste kirjeldustega. Idee sellest, millist teavet tööks vaja on, on erinev erinevad rühmad kasutajad, erinevate valdkondade spetsialistid - oleneb nende tööülesannetest (personalispetsialistid ja raamatupidamistöötajad, osakonnajuhatajad jne vajavad oma ülesannete täitmiseks erinevaid andmeid). Neid vajadusi kirjeldatakse artiklis väline tase andmete esitamine (vaated A, B ja C joonisel 1).

Välised kirjeldused Sellest tulenevalt võib andmebaasis olla palju andmeid. Need tuleb kokku viia kontseptuaalne vaade, mis kirjeldab andmeid kogu infosüsteemi kui terviku tasemel. Nende andmete esitamise sisetasandil määrab nende salvestamise viis väline mälu.

Vaatleme linnakauplusi kaupadega varustava ettevõtte infosüsteemi andmebaasi näidet ja võtame arvesse ainult ettevõtte kahe töötaja infovajadust (lihtsustatud kujul - muidu oleks näide liiga tülikas ).

Joonis 1. Andmete esituse moodustamine

Kliendisuhete töötaja vajab oma tööülesannete täitmiseks joonisel 2 toodud infot.

Maksevormidega töötav töötaja vajab klientide kohta muud teavet (joonis 3).

Üksikute spetsialistide kasutatavad andmed asuvad ettevõtte ühtses infosüsteemis, nende jaoks ühises andmebaasis. Seetõttu tuleb üksikute kasutajate välised vaated integreerida kontseptuaalsesse vaatesse, andmete kontseptuaalsel tasandil kirjeldamise eesmärk on luua andmetest niisugune formaalne vaade, et igasugune väline vaade on selle alamhulk. Väliste esinduste integreerimise protsess kõrvaldab üksikute kasutajate teabevajaduste ebaselgused ja vastuolud. Kogu andmebaasi esindav kontseptuaalne kirjeldus peab olema kordumatu.

Joonis 2. Esimese töötaja andmed

Joonis 3. Teise töötaja andmed

Selles näites peab kontseptuaalne vaade sisaldama kogu teavet, mida kõik töötajad vajavad. Vastuolud võivad tekkida sellest, et töötajad, kes kasutavad Üldine informatsioon, võib seda ette kujutada erineval viisil (näiteks: telefoninumbri saab kirjutada erinevad vormingud). Kõik need vastuolud tuleb kõrvaldada, andmed ja nende esitusvorm peavad olema järjepidevad.

Seejärel määrab kontseptuaalse kirjelduse järgmine teave

Kontseptuaalsel diagrammil kirjeldatud andmed tuleb salvestada välismällu, VRAM-ile, mis on mõeldud andmebaasis asuva teabe salvestamiseks. Siseandmete kirjeldus iseloomustab andmete välismällu salvestamise viisi.

Andmete kirjeldamise reeglid määrab valitud andmemudel(V sel juhul vaadeldakse ainult relatsioonimudelit – praegu kõige levinumat).

Kui võtta ülaltoodud näitest linna kauplustele kaupadega tegeleva ettevõtte klientide andmete kirjeldus, mis on toodud joonisel 4, siis ei saa selles tabelis kirjeldatud andmeid sellisel kujul relatsiooniandmebaasis esitada, kuna mitte. kõik väärtused on aatomilised (ridade “Omanik” ja “Aadress” komponendid koosnevad mitmest väärtusest, st nende atribuutide väärtused asendatakse muude suhetega, mille dešifreerivad need omanikku kirjeldavas seoses, väljad “ Aadress” ja „Pass” ei ole samuti aatomid, seetõttu luuakse hierarhia.

Andmebaasi kujundamisel saab neid võtta erinevaid lahendusi, kuid on põhinõuded, mida tuleb tööprotsessi käigus arvestada: seoste kogum peab tagama minimaalse üleliigsuse teabe esitamisel; andmetega manipuleerimine, suhete kohandamine ei tohiks põhjustada andmete terviklikkuse rikkumist, ebaselgust ega teabe kadumist; seoste komplekti ümberstruktureerimine uute atribuutide andmebaasi lisamisel peaks olema minimaalne.

Joonis 4. Andmete üldine esitus

Reaalsete objektide ja nendevaheliste suhete kirjeldamine on suures osas subjektiivne, kuid teatud on üldreeglid, eriti, normaliseerimisreeglid. Normaliseerimine kaitseb andmete terviklikkust, välistades andmete dubleerimise. Selle tulemusena saab ühe objekti andmete esituse jaotada mitmeks väiksemaks seotud tabeliks (kadudeta lagunemine). Piiranguid, mida relatsiooniandmebaasi kujundamisel tuleb järgida, on üsna palju. Piirangute järgimine konkreetsete suhete määratlemisel andmebaasis on seotud juurutamisega normaalsed vormid. Tavavormid nummerdatakse järjestikku, alustades esimesest. Mida suuremat tavavormi numbrit andmebaas rahuldab, seda rohkem tuleb järgida andmebaasi salvestatavate andmete piiranguid. Võimalik on tüüpiline relatsiooniline DBMS kehtestada piiranguid lisakomplekt piirangud, mis toob kaasa tavavormide arvu suurenemise.

Halvasti kavandatud andmebaas võib salvestada kogu teabe ühes tabelis. Ülalkirjeldatud näite puhul võib selline tabel sisaldada järgmisi veerge:

Tänava- ja majaaadressi komponendid on ümber nimetatud, et järgida nõuet, et veergude nimed peavad olema kordumatud (nimetamisreeglid sõltuvad DBMS-ist).

Millised on selle idee puudused?

Esimene normaalne vorm nõuab, et rea ja veeru ristumiskohas oleks üks väärtus, mis peab olema jagamatu (aatomilisuse nõue). Lisaks ei tohiks relatsioonitabel sisaldada korduvaid ridu ega andmerühmi.

Aatomilisuse nõue on täidetud - liitveerud “Aadress” ja “Omanik” (ning omaniku jaoks “Aadress” ja “Pass”) on jagatud komponentideks, mis sisalduvad üldtabelis. Kuid ühel poel võib olla mitu omanikku ja ühel inimesel võib olla mitu poodi. See tähendab, et tabel peab sisaldama kõiki ridu, mis tähistavad kaupluste ja nende omanike „kombinatsioone”, st. andmerühmi korratakse erinevatel ridadel (poe andmeid korratakse mitu korda - iga selle omaniku kohta ja omaniku andmeid korratakse iga selle poe kohta). Selline andmete esitamine toob kaasa tohutu liiasuse ja asjaolu, et VRAM-i mälu kasutatakse ebaefektiivselt. Lisaks võib teabe dubleerimine põhjustada probleeme selle töötlemisel: kaupluse teabe muutmiseks (näiteks kui selle pangakonto muutub), peate neid andmeid muutma mitmes erinevatele omanikele vastavas kirjes.

Kui otsustate, millised tabelid tuleks andmebaasi lisada ja millist teavet nendesse salvestada, peaksite kaaluma järgmine reegel: iga tabel kirjeldab objekti, eksisteerib iseseisvalt, millel on oma omadused. Andmebaasi loomine peaks algama iga objekti esituse loomisest ridadena, mis sisaldavad selle atribuute vastavas tabelis; objektisuhete mudelite määratlemine. Vaadeldavas näites peaks andmebaas tegelikult salvestama teavet kahte tüüpi objektide kohta: kaupluste ja nende omanike kohta. See teave tuleks paigutada kahte erinevasse tabelisse (poed ja omanikud) järgmiste veergudega:

"Poed"

"Omanikud"

Tabeli "Kauplused" iga rida kirjeldab vastava objekti eksemplari (üks pood). Ja iga tabeli „Omanikud” rida sisaldab teavet ühe poe omaniku kohta.

Andmebaasi salvestatud teabega töötades peab DBMS suutma ridu üksteisest eristada. Atribuut või atribuutide kogum, mis identifitseerib üheselt stringi, on selle esmane võti.

Mida saab valida ülalkirjeldatud tabelite primaarvõtmeks?

Võti seos on selline atribuutide kogum, et iga nende väärtuste kombinatsioon esineb ainult seose ühes real ja ühelgi nende atribuutide alamhulgal pole seda omadust. Seega tuvastab võti üheselt rea ja võimaldab seda valida kogu relatsiooni ridade hulgast.

Määratleme tabeli "Kauplused" võtme.

Kui valite võtmeks atribuudi Store Name, kas see vastab määratud nõudele? Ei, kui ühes linnas võib olla mitu kauplust samad nimed asub aastal erinevad osad linnad. Ühemõttelisuse tagamiseks tuleks poe nimele lisada aadress (kaupluse nime ja aadressi järgi saab üheselt valida soovitud rida tabelis), siis on suhtevõti liit.

Lihtsa võtmega, tuvastades õige kauplus, võib olla pangakonto number (kui igal poel on üks arvelduskonto number ja iga arvelduskonto kuulub ühele poele). Võtmeks võib olla ka maksukohustuslase number ( identifitseerimisnumber) kauplus.

Valime primaarvõtmeks atribuudi „TIN”. Lisaks kasutatakse seda atribuuti tabelite „Poed” ja „Omanikud” vaheliste ühenduste korraldamiseks (need ühendused peaksid kajastama tegelikke suhteid kaupluste ja nende omanike vahel).

Otsustame tabeli „Omanikud” võtmed.

Kui võiks eeldada, et poeomanike seas pole nimekaimu, siis võiks võtmeks valida kõnealuse seose atribuudi “Perekonnanimi”. Kuid kahjuks võivad poeomanikud olla mitte ainult nimekaimud, vaid ka täielikud käsilased (ebatõenäoline, kuid täiesti võimalik). Seetõttu saab võtmeks valida omaniku passiandmed, st. kasutage selle tuvastamiseks liitvõtit, sealhulgas atribuute "Series" ja "Number". Peame seda võtit esmaseks võtmeks. Selle abil loome sideme omaniku ja tema kaupluste vahel.

Peamised võtmed ei anna teabe otsimisel mitte ainult ühemõttelisust (need on ainulaadsed), vaid võimaldavad teil ka kahes tabelis asuvaid andmeid linkida.

Määratleme tabelite "Kauplused" ja "Omanikud" vahelise seose tüübi.

Kui eeldada, et üks inimene võib omada mitut kauplust, kuid igal poel on üks omanik, siis peaksime nende tabelite vahel looma üks-mitmele suhte. Sellise ühenduse korraldamiseks andmebaasis oleks võimalik lisada poe infot sisaldava tabeli reale “Poed” väline võti, tuvastades kaupluse omaniku, s.o. tema passiandmed – atribuudid “Seeria” ja “Number”. Sel juhul on võimatu ühendust korraldada, lisades tabelisse "Omanikud" võõrvõtmena kauplusi identifitseeriva võtme "TIN", kuna sel juhul tuleks iga poe kohta teavet omaniku kohta dubleerida. .

Kui teeme eelduse, et üks inimene saab omada ainult ühte kauplust, kuid igal poel võib olla mitu omanikku, saame üks-mitmele suhte, kuid antud juhul väline võti(poe maksukohustuslase number) tuleks lisada tabelisse, mis sisaldab teavet omanike kohta.

Tegelikkuses võib iga inimene olla mitme kaupluse omanik ja igal poel võib olla mitu omanikku, seega tuleb tabelite “Kauplused” ja “Omanikud” vahel luua mitu-mitmele suhe, mille korraldamiseks spetsiaalne tabel. luuakse, mis kirjeldab kaupluste ja omanike vahelisi suhteid:

"Kauplused-omanikud"

TIN

seeria

Number

See tabel võimaldab teil leida kõik selle omanikud, kasutades kaupluse atribuuti „TIN” (passi andmete kaudu) ja liitatribuuti, mis sisaldab omaniku passi atribuute „Seeria” ja „Number”. otsige andmebaasist üles kõik talle kuuluvad kauplused.

Selleks looge tabeli "Kauplused-omanikud" loomisel üks-mitmele seosed tabeli "Kauplused" ja "Kauplused-omanikud" vahel, samuti "Omanikud" ja "Kauplused-omanikud" vahel. tabelid:

TIN seeria Number

"Kauplused-omanikud"

Loodud sidemed aitab DBMS-il säilitada teabe terviklikkust ja järjepidevust. Näiteks saate põhitabelis teabe uuendamisel seada seotud tabelite teabe uuendamise reeglid (näiteks kui kauplus on likvideeritud, tuleks selle teave andmebaasist kustutada ja edastada arhiivi, mitte ainult rida tabelist „Kauplused”, vaid kogu teavet selle poe kohta seotud tabelites).

Kasutajate mugavuse huvides ja otsingute kiirendamiseks toetavad DBMS-id võimalust otsida mitte ainult unikaalsete võtmete järgi. Näiteks leiate tabelist kõik sama nimega kauplused või kõik samale omanikule kuuluvad kauplused.

Andmete normaliseerimise tulemusel jaotati tabelid, eraldades esmase võtme ja võõrvõtme seosed väiksemateks tabeliteks. Normaliseerimise tulemuseks on andmete liiasuse vähenemine – enam ei ole vaja iga poe kohta iga omaniku andmeid dubleerida.

Teine normaalne vorm nõuab, et mis tahes mittevõtmeveerg sõltuks selle primaarvõtmest (ja kogu võtmest, mitte selle üksikutest komponentidest). Seos on teisel normaalkujul, kui see vastab esimesele normaalkujule ega sisalda mittetäielikku funktsionaalsed sõltuvused. Mittetäieliku funktsionaalse sõltuvuse defineerib kaks tingimust: seose võti määratleb funktsionaalselt mõne mittevõtmeatribuudi ja osa võtmest määratleb funktsionaalselt sama võtmevaba atribuudi.

Seost, mis ei vasta teisele normaalvormile, iseloomustab salvestatud andmete liiasus.

Vaadeldavas näites on relatsiooniatribuutide komplekt ja võtmete valik tehtud nii, et tabelid vastavad teisele normaalkujule. Kui seda vastavust ei eksisteeriks, oleks tabelite teiseks normaalkujuks redutseerimiseks vaja korduv teave (osa võtmest ja selle määratletud mittevõtmeatribuudid) eraldada eraldi tabelisse.

Näiteks: andmebaasis on vaja salvestada teavet kauplustesse tarnitavate kaupade kohta. See teave sisaldab toote atribuute “Nimi”, “Kood” ja “Hind” ning tarnitud toote “Kogus”. Kui lisate selle teabe tabelisse "Tarvikud". järgmine etendus:

"Tarvikud"

(siin "TIN" tähistab kauplust, kuhu tarniti (see on võõrvõti, mida kasutatakse üks-mitmele seose loomiseks tabeli "Poed" ja selle tabeli vahel), "Nimi" on toote nimi , "Kood" on selle unikaalne kood (tooted, millel on erinevad omadused ja seetõttu võivad erinevatel hindadel olla sama nimi, kuid koodid on erinevad), “Hind” on toote müügihind, “Kogus” on tarnitava toote kogus), siis võib tekkida üleliigne.

Kauba konkreetsesse kauplusesse tarnimist tähistava rea määratlemiseks saate määrata liitvõtme, mis sisaldab atribuute “TIN” ja “Code”. See teave võimaldab määrata toote hinna ja tarnitava koguse see pood ja arvutada ka kauba kogumaksumus. Kui eeldame, et toodet tarnitakse kõikidesse kauplustesse sama hinnaga ja hind aja jooksul ei muutu, siis ei määra mittevõtmeatribuut "Price" mitte ainult liitvõtmega "TIN" + "kood", vaid ka selle osa - atribuut "Kood" " Seega kordub sama hind kõikidel tabeli ridadel, mis sisaldavad teavet sama toote pakkumise kohta. See toob kaasa koondamise. Toote nimetuse määrab ka selle kood. Seetõttu saab teabe, mis puudutab ainult toodet ja ei sõltu poest, paigutada eraldi tabelisse:

Siin võimaldab võtmeväli "Kood" linkida tabelis "Tarvikud" olevad andmed tabeli "Tooted" andmetega

Seega kõrvaldas taandamine teisele normaalvormile üleliigsuse uute tabelite eraldamisega: tabel “Tarvikud” on jagatud kaheks tabelisse “Tarned” ja “Kaubad”, mille vahel luuakse seos.

Kolmas tavavorm suurendab veelgi nõudeid: seos vastab teisele normaalkujule ja selle atribuutide hulgas ei ole transitiivseid funktsionaalseid sõltuvusi (ükski mittevõtmeveerg ei tohiks sõltuda teisest mittevõtmeveerust, see võib sõltuda ainult primaarvõtmest).

Vaadeldavas näites ilmneks lahknevus kolmanda normaalvormiga, kui on täidetud järgmine tingimus: kõikidel sama nimega kaupadel on sama hind (nime määraks kood ja hind kauba nimetuse järgi). toode). Sel juhul ilmneb liiasus, kuna antud tootenime hind korduks nii mitu korda, kui selle toote jaoks erinevaid koode kasutatakse.

Liigsusest oleks võimalik vabaneda, jagades tabeli “Tooted” kaheks (üks sisaldaks atribuute “Kood” ja “Nimi”, teine “Nimi” ja “Hind”).

Vaadeldavas näites on aga olukord erinev: kaubal on erinevad koodid, kui nende omadused on erinevad, peaksid hinnad olema erinevad.

Neljas tavavorm keelab sõltumatud üks-mitmele seosed võtme- ja mittevõtmeveergude vahel. Lihtsamalt öeldes ei saa heterogeenset teavet paigutada ühte tabelisse, s.t. andmed, mille vahel puudub otsene seos.

Seda reeglit saab näha järgmises näites. Kliendisuhtleja plaanib oma tööülesannete täitmiseks kasutada teavet kaupluste omanike pereliikmete kohta. Seda teavet ei tohiks lisada tabelisse Omanikud, kuna on raske kindlaks teha, kui palju ruumi reserveerida vastavatel tabeliridadel. konkreetsed inimesed, et salvestada nende kohta andmeid perekonnaseis, - üks võib olla vallaline ja teine võib olla paljude laste isa. Pereliikmete andmed tuleb paigutada eraldi tabelisse, mille igal real on andmed ühe pereliikme kohta, sh kaupluse omanikku identifitseeriv võõrvõti, et korraldada ühendus tabeliga „Omanikud”.

Viies normaalvorm tavaliselt lõpetab normaliseerimisprotsessi. Selles etapis on kõik tabelid jaotatud minimaalseteks osadeks, et kõrvaldada nende liiasus. Iga mittevõtmeandmete osa tabelites peaks ilmuma ainult üks kord. See välistab andmebaasis oleva teabe uuendamisega seotud probleemid: kõik mittevõtmeandmete muudatused tuleb teha ainult üks kord, mis annab võimaluse hallata andmete terviklikkust.

Andmebaasi kujundamise protsess on väga oluline etapp infosüsteemide arendamisel. Just disaini kvaliteet määrab suuresti andmebaasi kasutamise efektiivsuse.

Praegu laialdaselt kasutatav erilised vahendid, hõlbustades infosüsteemide arendamise protsessi (CASE-tööriistad – Computer-Aided Software/System Engineering).

Küsimused enesekontrolliks:

1. Mis on andmebaas?

2. Mis on andmete väline esitus?

3. Mis on andmete kontseptuaalse esituse olemus?

4. Mis on andmemudel?

5. Mis on normaliseerimine?

6. Mis on suhtevõti?

7. Millist võtit nimetatakse võõrvõtmeks?

8. Milliseid seoseid saab andmebaasis korraldada?

9. Mis on iga viie normaalvormi olemus?

Ülesanne jaoks iseseisev töö:

Kujundage klienditeenindusettevõtte andmebaasid. Andmebaasi vajavad kolm ettevõtte töötajat. Neist esimene käsitleb ettevõtte poolt osutatavate teenuste ja vajaduste arvestust järgmist teavet:

Teine töötaja kogub teavet esinejate kohta ja on huvitatud:

Kolmas töötaja töötab klientidega ja tema jaoks on oluline teada.

Infosüsteemide andmebaaside kujundamine on üsna töömahukas töö. See viiakse läbi struktuuri ja protsesside vormistamise alusel ainevaldkond, mille teave peaks olema andmebaasis salvestatud. On kontseptuaalne ja skemaatiline-struktuurne disain.

IS-i andmebaasi kontseptuaalne kujundamine on suures osas heuristiline protsess. Selle raames ülesehitatud ainevaldkonna informoloogilise mudeli adekvaatsust kontrollitakse katseliselt IS-i toimimise käigus.

Loetleme etapid kontseptuaalne disain :

· ainevaldkonna uurimine, et kujundada sellest üldine ettekujutus;

· väljatöötatava IS-i funktsioonide ja ülesannete väljaselgitamine ja analüüs;

· ainevaldkonna peamiste objektide-olemite ja nendevaheliste suhete määramine;

· ainevaldkonna formaliseeritud esitus.

Relatsioonilise andmebaasi skeemi kujundamisel saab eristada järgmisi protseduure:

· tabelite loetelu ja nendevaheliste seoste määratlemine;

· iga tabeli väljade loetelu, väljatüüpide, võtmeväljade määramine (tabeliskeem), tabelitevaheliste ühenduste loomine võõrvõtmete kaudu;

· tabelite väljade indekseerimise loomine;

· loendiandmetega valdkondade loendite (sõnastike) väljatöötamine;

· tabelite ja suhete terviklikkuse piirangute kehtestamine;

· tabelite normaliseerimine, tabelite loetelu ja seoste korrigeerimine.

Andmebaasi projekteerimine viiakse läbi füüsilisel ja loogilised tasemed. Disain sisse füüsiline tase rakendatakse DBMS-i abil ja sageli automatiseeritud.

Loogiline disain seisneb tabelite arvu ja struktuuri määramises, andmebaasipäringute väljatöötamises, dokumentide aruandluses, vormide loomises andmete andmebaasi sisestamiseks ja redigeerimiseks jne.

Üks neist kõige olulisemad ülesanded loogiline disain DB on andmete struktureerimine. Eristatakse järgmist: lähenemisi andmestruktuuride kujundamiseks:

· olemiobjektide teabe kombineerimine ühes tabelis (üks seos) koos järgneva dekomponeerimisega mitmeks omavahel seotud tabeliks suhete normaliseerimise protseduuri alusel;

· teadmiste sõnastamine süsteemist (lähteandmete liikide ja seoste määramine) ja andmetöötluse nõuetest, valmis andmebaasi skeemi või isegi valmis rakenduste infosüsteemi saamine CASE süsteemi abil;

· rakendamine süsteemi analüüs ja struktuurimudelite väljatöötamine.

Esimene lähenemine on klassikaline.

Disainiprotsess algab olemiobjektide tuvastamisega, mille kohta teave andmebaasi salvestatakse, ja nende atribuutide määratlemisega. Valitud atribuudid koondatakse ühte tabelisse (seos).

Täielik teave olemuse kohta (tabel) annab liiasuse (korduse), Þ vaja on ümberkujundamist, s.t. lagunemine, s.o. jagunemine mitmeks tabeliks, st. normaliseerimine.

Þ Saadud suhe kuulub normaliseerimisele. Normaliseerimisprotseduur on iteratiivne ja seisneb suhete järjestikuses ülekandmises esimeselt normaalvormilt kõrgemat järku normaalvormidele.

Eristatakse järgmist normaalvormide jada:

· esimene normaalvorm (1NF);

· teine normaalvorm (2NF=1NF+midagi);

· kolmas normaalvorm (ZNF=2NF+midagi);

· tõhustatud kolmas normaalvorm ehk Boyce-Coddi normaalvorm (BCNF);

· neljas normaalvorm (4NF);

· viies normaalvorm (5NF).

(2NF-i nõuded)

korreleerub ainult primaarvõtmega. Þ Kõik andmed salvestatakse andmebaasis ainult ühes kohas. Þ Dubleeritud andmed teisaldatakse teise tabelisse ja selle asemel kasutatakse võõrvõtmeid.

(3NF-i nõuded)

Iga mittevõtmevaldkond ei tohiks sõltuda teisest mittevõtmevaldkonnast (näiteks õpetaja ja osakonna suhe või õppeaine ja osakonna suhe). Selle vältimiseks peate ainevaldkonda üksikasjalikult tundma. Þ Kui seal on "Eriala", eemaldame "ajakavast" "teaduskonna".

3NF pakub deklaratiivset viidet (andmed kataloogidest).

(Nõuded 4NF-i jaoks)

Normaliseerimine võimaldab kõrvaldada teabe liiasuse, mis toob kaasa andmetöötluse anomaaliaid.

Samas tuleks eristada mitteliigset ja üleliigset andmete dubleerimist. Neist esimese olemasolu andmebaasides on lubatud. Siin on näited mõlema dubleerimisvaliku kohta.

Näidet mitteliigsetest andmete dubleerimisest kujutab seos “TELEFONID” (joonis 5.6). Oletame, et ühte ruumi on paigaldatud ainult üks telefon, siis on samas ruumis asuvate töötajate telefoninumbrid samad. Telefoninumber 24212 ilmub mitu korda. See on dubleerimine. Number on aga iga töötaja jaoks kordumatu ja kui üks numbritest kustutatakse, läheb kaotsi info, millise numbriga saab konkreetse töötajani jõuda. See on koondamatuse olemus.

Riis. 5.6. Andmete üleliigne dubleerimine

Seoses “ROOMS” esineb andmete ülemäärast dubleerimist, millele lisandub atribuut “Ruuminumber” (joonis 5.7).

Riis. 5.7. Liigne andmete dubleerimine

Töötajad Belkin, Sinitsõn ja Medvedev on samas ruumis ja seetõttu on neil samad numbrid. See tähendab, et Sinitsõni ja Medvedevi telefoninumbri saab korteežist teada Belkini kohta käiva teabega. See on andmete dubleerimise liiasus.

Andmete liigne dubleerimine põhjustab probleeme relatsioonikorteeži töötlemisel, mida E. Codd nimetab "relatsioonivärskenduse anomaaliateks".

Anomaaliad- sellised olukorrad andmebaasi tabelites, mis toovad kaasa vastuolusid andmebaasis või raskendavad oluliselt andmetöötlust.

Anomaaliaid on kolm peamist tüüpi:

· muutmise (toimetamise) anomaaliad;

· eemaldamise anomaaliad;

· lisandumise anomaaliad.

Modifikatsiooni anomaaliad avalduvad selles, et atribuudi väärtuse muutus võib kaasa tuua kogu tabeli läbivaatamise koos selle atribuudi väärtuste vastava muutusega teistes tabelikirjetes.

Seega nõuab telefoninumbri muutmine ruumis 325 (joonis 5.7) kogu tabeli „ROOMS” ülevaatamist ja atribuudi „Telefoninumber” väärtuste muutmist kirjetes, milles see number kuvatakse.

Kustutamise anomaaliad avalduvad selles, et mis tahes atribuudi väärtuse kustutamisel kaob muu teave, mis ei ole kustutatud väärtusega otseselt seotud.

Seega viib töötaja Volkovi kirje kustutamine (näiteks vallandamise tõttu) ruumi 320 paigaldatud telefoninumbri teabe kadumiseni (vt joonis 5.7).

Lisamise anomaaliad avalduvad selles, et kirjet on võimatu tabelisse lisada enne, kui kõigi selle atribuutide väärtused on teada, ja ka selles, et sisestamine uus sissekanne nõuab kogu tabeli ülevaatamist.

Näiteks tabelis "RUUMID" (vt joonis 5.7) on võimatu kuvada teavet ruumi kohta, kuhu on paigaldatud telefon, enne kui sinna pole paigutatud ühtegi töötajat (eeldusel, et võtmeväli on "Nimi"). .

Lisaks tuleb uue töötaja kohta tabelisse info lisamisel kontrollida tabelist ebakõlasid, mis võivad tekkida, kui vigane sisestus telefoni või toa numbrid. Näide vastuolust: töötajad on samas ruumis, kuid on erinevad numbrid telefonid.

Liigse dubleerimise ja anomaaliate neutraliseerimise viis on dekomponeerimine ehk algse seose (tabeli) poolitamine. Lagundamine peab olema pöörduv, see tähendab, et see peab toimuma ilma teabe kadumiseta

Suhtemudel Teatud teemavaldkonna andmed (RMD) on suhete kogum, mis ajas muutuvad. Infosüsteemi loomisel võimaldab seoste kogum salvestada andmeid ainevaldkonna objektide kohta ja modelleerida nendevahelisi seoseid.

Relatsiooniandmebaas on kahemõõtmeliste tabelite komplekti sisaldav andmeladu, tabelites olevad andmed peavad vastama järgmistele põhimõtetele.

1. Atribuutide väärtused (veerg, väli) peavad olema atomaarsed (teisisõnu, iga rea ja veeru ristumiskohas sisalduvat väärtust ei tohi jagada mitmeks väärtuseks).

2. Iga välja väärtused peavad olema sama tüüpi.

3. Tabeli iga kirje on kordumatu.

4. Igal väljal on kordumatu nimi.

5. Tabeli väljade ja kirjete järjestus ei ole oluline

Suhtumine on oluline mõiste ja on kahemõõtmeline tabel, mis sisaldab mõningaid andmeid.

Essents on objekt ükskõik milline loodus, mille kohta andmeid hoitakse andmebaasis. Olemiandmeid salvestatakse suhetes.

Atribuudid on olemit iseloomustavad omadused. Tabelistruktuuris on igale atribuudile nimi ja see vastab kindla tabeli veeru pealkirjale.

Suhte võti on selle atribuutide kogum, mis identifitseerivad unikaalselt iga seose korteeži.

Klahve kasutatakse tavaliselt järgmiste eesmärkide saavutamiseks:

Duplikaatväärtuste kõrvaldamine võtmeväljadel;

Plaatide tellimine. Kõigi võtmeväljade väärtusi on võimalik järjestada kasvavas või kahanevas järjekorras, samuti segajärjestuses (mõnede jaoks - suurenedes ja teiste jaoks - vähenedes);

Organisatsioone ühendav tabel.

Võõrvõtme mõiste on oluline. Võõrvõtit saab määratleda kui ühe seose atribuutide kogumit R2, mille väärtused peavad väärtustega ühtima võimalik võti teistsugune suhtumine R1.

Seostele saab rakendada operatsioonisüsteemi, mis võimaldab üht tuletada teisest. Näiteks võib relatsiooniandmebaasi päringu tulemuseks olla uus seos, mis arvutatakse olemasolevate seoste põhjal. Seetõttu on võimalik töödeldavad andmed jagada salvestatud ja arvutatud osadeks. Relatsiooniandmebaaside andmetöötluse põhiüksus on relatsioon, mitte selle üksikud korteežid (kirjed).

Infosüsteemide andmebaaside kujundamine on üsna töömahukas töö. See viiakse läbi ainevaldkonna struktuuri ja protsesside vormistamise alusel, mille kohta infot peaks säilitama andmebaasis. Eristama kontseptuaalne ja ringkond- struktuurne disain.

Loetleme kontseptuaalse disaini etapid:

Moodustava ainevaldkonna õppimine üldine idee temast;

Arendatud IS funktsioonide ja ülesannete tuvastamine ja analüüs;

Ainevaldkonna peamiste objektide-olemite ja nendevaheliste suhete määratlemine;

Ainevaldkonna formaliseeritud esitus.

Relatsioonilise andmebaasi skeemi kujundamisel saate eristada järgmisi protseduure :

Tabelite loetelu ja nendevaheliste seoste määramine;

Iga tabeli väljade loendi, väljatüüpide, võtmeväljade määramine (tabeliskeem), tabelitevaheliste seoste loomine võõrvõtmete kaudu;

Tabelite väljade indekseerimise loomine;

Loendavate andmetega valdkondade loendite (sõnastike) koostamine;

Tabelite ja suhete terviklikkuse piirangute kehtestamine;

Tabelite normaliseerimine, tabelite loetelu ja seoste korrigeerimine.

Andmebaasi kujundamine toimub füüsilisel ja loogilisel tasandil. Füüsilise tasandi disain viiakse ellu DBMS-i abil ja on sageli automatiseeritud.

Andmebaaside loogilise disaini üks olulisemaid ülesandeid on andmete struktureerimine. Eristatakse järgmisi andmestruktuuride kujundamise lähenemisviise:

Olemiobjektide teabe ühendamine ühes tabelis (üks seos) koos järgneva dekomponeerimisega mitmeks omavahel seotud tabeliks suhete normaliseerimise protseduuri alusel;

Süsteemi puudutavate teadmiste formuleerimine (lähteandmete liikide ja seoste määramine) ja andmetöötluse nõuetest, valmis andmebaasi skeemi või isegi valmis rakenduste infosüsteemi saamine CASE süsteemi abil;

Süsteemianalüüsi läbiviimine ja struktuurimudelite väljatöötamine.

Andmebaasi kujundamise teemalise 15 artiklist koosneva sarja tõlge.
Teave on mõeldud algajatele.
Aitas mind. Võib-olla aitab see kellelgi teisel lüngad täita.

Andmebaasi kujundamise juhend.

1. Sissejuhatus.

Kui kavatsete luua omad alused Andmed, on hea mõte järgida andmebaasi kujundamise juhiseid, kuna see tagab teie andmete pikaajalise terviklikkuse ja hõlpsa hooldamise. See juhend räägib teile, mis on andmebaasid ja kuidas kujundada andmebaasi, mis järgib relatsioonilise andmebaasi kujundamise reegleid.

Andmebaasid on programmid, mis võimaldavad salvestada ja hankida suuri koguseid seotud Informatsioon. Andmebaasid koosnevad tabelid, mis sisaldavad teavet. Andmebaasi loomisel peate mõtlema, mida tabelid pead looma ja mida side tabelite teabe vahel. Teisisõnu, peate mõtlema projekt teie andmebaas. Kena projekt andmebaas, nagu varem mainitud, tagab andmete terviklikkuse ja hoolduse lihtsuse.

Andmebaas luuakse sellesse teabe salvestamiseks ja vajaduse korral selle teabe hankimiseks. See tähendab, et me peame suutma asetada, sisestada ( LISA) teavet andmebaasi ja me tahame saada teavet andmebaasist ( VALI).
Nendel eesmärkidel leiutati andmebaasi päringukeel, mida kutsuti Struktureeritud päringu keel või SQL. Andmete sisestamise (INSERT) ja nende valimise (SELECT) toimingud on selle keele osad. Allpool on näide andmeotsingu taotlusest ja selle tulemusest.

SQL on suur teema ja jääb sellest õpetusest välja. See artikkel keskendub rangelt esitlusele andmebaasi kujundamise protsess. Hiljem, sisse eraldi käsiraamat, käsitlen SQL-i põhitõdesid.

Suhtemudel.

Selles õpetuses näitan teile, kuidas luua relatsiooniandmemudelit. Relatsioonimudel on mudel, mis kirjeldab, kuidas korraldada andmeid tabelites ja kuidas määratleda nende tabelite vahelisi seoseid.

Reeglid relatsiooniline mudel dikteerivad, kuidas teave tabelitesse paigutada ja kuidas tabelid on omavahel seotud. Lõppkokkuvõttes saab tulemuse esitada andmebaasi diagrammina või täpsemalt olemi-seoste diagrammina, nagu joonisel (Näide võetud MySQL Workbench).

Näited.

Kasutasin juhendis näidetena mitmeid rakendusi.

RDBMS.

RDBMS, mida ma näitetabelite loomisel kasutasin, oli MySQL. MySQL on kõige populaarsem RDBMS ja see on tasuta.

Andmebaasi haldamise utiliit.

Pärast MySQL-i installid saate ainult liidese käsurida MySQL-iga suhtlemiseks. Isiklikult eelistan oma andmebaaside haldamiseks GUI-d. Kasutan SQLyogi sageli. See tasuta utiliit Koos graafiline liides. Tabelite pildid see juhend sealt võetud.

Visuaalne modelleerimine.

Seal on suurepärane tasuta rakendus MySQL Workbench. See võimaldab teil andmebaasi graafiliselt kujundada. Kasutusjuhendis olevad diagrammid on tehtud selles programmis.

RDBMS-ist sõltumatu disain.

Oluline on teada, et kuigi see juhend sisaldab näiteid MySQL-i kohta, on andmebaasi kujundus RDBMS-ist sõltumatu. See tähendab, et teave kehtib relatsiooniandmebaaside kohta üldiselt, mitte ainult MySQL-i kohta. Saate selle õpetuse teadmisi rakendada mis tahes relatsiooniandmebaasides, nagu Mysql, Postgresql, Microsoft Access, Microsoft SQL või Oracle.

Järgmises osas räägin lühidalt andmebaaside arengust. Saate teada, kust pärinevad andmebaasid ja relatsiooniline andmemudel.

2. Ajalugu.

70ndatel ja 80ndatel, kui arvutiteadlased kandsid veel pruune smokingut ja suurte ruudukujuliste raamidega prille, salvestati andmeid struktureerimata failidesse, mis esindasid Tekstdokument andmetega, mis on eraldatud (tavaliselt) komade või tabeldusmärkidega.

Sellised nägid välja infotehnoloogia spetsialistid 70ndatel. (Vasakul all on Bill Gates).

Tekstifaile kasutatakse ka tänapäeval väikese koguse lihtsa teabe salvestamiseks. Komaga eraldatud väärtused (CSV) – komadega eraldatud väärtused on väga populaarsed ja neid toetavad tänapäeval laialdaselt erinevad tarkvara ja operatsioonisüsteemid. Microsoft Excel on üks näide programmidest, mis võivad töötada CSV-failidega. Sellisesse faili salvestatud andmeid saab lugeda arvutiprogrammiga.

Ülal on näide selle kohta, kuidas selline fail välja näeb. Lugemisprogramm sellest failist, tuleks teavitada, et andmed on eraldatud komadega. Kui programm soovib valida ja kuvada kategooriat, milles õppetund asub "Andmebaasi kujundamise õpetus", siis peab ta ridade kaupa lugema, kuni sõnad on leitud "Andmebaasi kujundamise õpetus" ja seejärel peab ta kategooria järeldamiseks lugema koma järel oleva sõna Tarkvara.

Andmebaasi tabelid.

Faili ridade kaupa lugemine ei ole kuigi tõhus. Relatsiooniandmebaasis salvestatakse andmed tabelitesse. Allolev tabel sisaldab samu andmeid, mis failis. Iga rida või "kirje" sisaldab ühte õppetundi. Iga veerg sisaldab mõnda õppetunni omadust. Sel juhul on see pealkiri ja selle kategooria.

Arvutiprogramm võiks otsida antud tabeli tutorial_id veerust konkreetset tutorial_id, et leida kiiresti sellele vastav pealkiri ja kategooria. See on palju kiirem kui failist rida-realt otsimine, täpselt nagu programm tekstifailis teeb.

Kaasaegsed relatsiooniandmebaasid on loodud selleks, et võimaldada andmete toomist konkreetsetest ridadest, veergudest ja mitmest tabelist korraga väga kiiresti.

Relatsioonimudeli ajalugu.

Relatsioonilise andmebaasi mudeli leiutas 70ndatel Briti teadlane Edgar Codd. Ta tahtis oma puudustest üle saada võrgu mudel andmebaasid ja hierarhiline mudel. Ja ta oli selles väga edukas. Relatsiooniandmebaasi mudel on nüüdseks üldtunnustatud ja kaalutletud võimas mudel tõhusa andmekorralduse jaoks.

Saadaval täna lai valik andmebaasihaldussüsteemid: väikestest töölauarakendustest kuni multifunktsionaalseteni serverisüsteemid väga optimeeritud otsingumeetoditega. Siin on mõned kõige enam tuntud süsteemid relatsioonilise andmebaasi haldus (RDBMS):

- Oraakel– kasutatakse peamiselt professionaalsete suurte rakenduste jaoks.
- Microsoft SQL server- RDBMS Microsoft. Saadaval ainult operatsioonisüsteem Windows.
- mysql- väga populaarne avatud lähtekoodiga RDBMS lähtekood. Kasutatakse laialdaselt nii professionaalide kui ka algajate seas. Mida veel vaja on?! See on tasuta.
- IBM– omab mitmeid RDBMS-e, millest kuulsaim on DB2.
- Microsoft Access– RDBMS, mida kasutatakse kontoris ja kodus. Tegelikult on see midagi enamat kui lihtsalt andmebaas. MS Access võimaldab luua kasutajaliidesega andmebaase.
Järgmises osas räägin teile relatsiooniliste andmebaaside omadustest.

3. Relatsiooniandmebaaside omadused.

Relatsiooniandmebaasid on mõeldud kiire salvestamine ja saamine suured mahud teavet. Allpool on mõned relatsiooniandmebaaside ja relatsiooniandmemudeli omadused.

Klahvide kasutamine.

Tabeli iga andmerida identifitseerib kordumatu "võti", mida nimetatakse primaarvõtmeks. Sageli on primaarvõti automaatselt kasvav (automaatselt suurenev) arv (1,2,3,4 jne). Erinevate tabelite andmeid saab võtmete abil omavahel siduda. Ühe tabeli primaarvõtme väärtused saab lisada teise tabeli ridadele (kirjetele), sidudes need kirjed omavahel.

Kasutades struktureeritud keel päringud (SQL), saab korraga valida andmeid erinevatest tabelitest, mis on võtmega seotud. Näiteks saate luua päringu, mis valib tellimuste tabelist kõik tellimused, mis kuuluvad kasutajate tabelist kasutajatunnusele 3 (Mike). Võtmetest räägime lähemalt järgmistes osades.

Selle tabeli id veerg on primaarvõti. Igal kirjel on kordumatu primaarvõti, sageli number. Kasutajarühma veerg on võõrvõti. Nime järgi otsustades viitab see ilmselt tabelile, mis sisaldab kasutajagruppe.

Andmete koondamine puudub.

Relatsiooniandmemudeli reegleid järgivas andmebaasi kujunduses salvestatakse iga teabetükk, näiteks kasutaja nimi, ainult ühes kohas. See välistab vajaduse töötada andmetega mitmes kohas. Dubleerivaid andmeid nimetatakse andmete koondamiseks ja seda tuleks vältida hea projekt Andmebaas.

Sisestuspiirang.

Relatsiooniandmebaasi abil saate määrata, milliseid andmeid on lubatud veerus salvestada. Saate luua välja, mis sisaldab täisarve, kümnendarvud, väikesed tekstitükid, suured tekstitükid, kuupäevad jne.

Andmebaasi tabeli loomisel esitate iga veeru jaoks andmetüübi. Näiteks varchar on andmetüüp väikeste tekstilõikude jaoks maksimaalne arv märgid on 255 ja ints on numbrid.

Lisaks andmetüüpidele võimaldab RDBMS veelgi piirata sisestatavaid andmeid. Näiteks piirake kirjete pikkust või sundige nende väärtuse kordumatust see veerg. Viimane piirang kasutatakse sageli väljade jaoks, mis sisaldavad registreerimisnimed kasutajad (sisselogimised) või aadressid Meil.

Need piirangud annavad teile kontrolli oma andmete terviklikkuse üle ja hoiavad ära järgmised olukorrad.

Aadressi (teksti) sisestamine väljale, kus eeldate numbrit
- piirkonnaindeksi sisestamine sama indeksi pikkusega sada tähemärki
- sama nimega kasutajate loomine
- sama meiliaadressiga kasutajate loomine
- sisestage kaal (number) sünnipäeva väljale (kuupäev)

Andmete terviklikkuse säilitamine.

Välja atribuutide kohandamise, tabelite linkimise ja piirangute konfigureerimisega saate suurendada oma andmete usaldusväärsust.

Õiguste loovutamine.

Enamik RDBMS-e pakub juurdepääsuõiguste sätteid, mis võimaldavad teil määrata konkreetseid õigusi teatud kasutajad. Mõned toimingud, mida saab kasutajale lubada või keelata: SELECT, INSERT, DELETE, ALTER, CREATE jne. Need on toimingud, mida saab teha struktureeritud päringukeele (SQL) abil.

Struktureeritud päringukeel (SQL).

Teatud toimingute tegemiseks andmebaasis, nagu andmete salvestamine, otsimine, muutmine, kasutatakse struktureeritud päringukeelt (SQL). SQL-i on suhteliselt lihtne mõista ja see võimaldab ... ja virnastatud valikud, näiteks seotud andmete toomine mitmest tabelist kasutades SQL-lause LIITU. Nagu varem mainitud, SQL-i selles õpetuses ei käsitleta. Keskendun andmebaasi kujundamisele.

Andmebaasi kujundamise viis mõjutab otseselt päringuid, mida peate andmebaasist andmete toomiseks käivitama. See on veel üks põhjus, miks peate mõtlema, milline peaks olema teie baas. Hästi läbimõeldud andmebaasiga võivad teie päringud olla puhtamad ja lihtsamad.

Kaasaskantavus.

Relatsiooniandmemudel on standardne. Järgides relatsioonilise andmemudeli reegleid, võite olla kindel, et teie andmeid saab suhteliselt lihtsalt teise RDBMS-i üle kanda.

Nagu varem öeldud, seisneb andmebaasi kujundamine andmete tuvastamises, nende seostamises ja otsuse tulemuste salvestamises. see küsimus paberile (või arvutiprogramm). Looge andmebaas, mis ei sõltu RDBMS-ist, mida kavatsete selle loomiseks kasutada.

Järgmises osas vaatleme esmaseid võtmeid lähemalt.

Märkus: See loeng alustab neljast loengust koosnevat sarja relatsiooniandmebaaside kujundamisest. Selles loengus räägime seoste diagrammide normaliseerimisest, võttes arvesse ainult funktsionaalseid sõltuvusi seose atribuutide vahel. Need normaliseerimise "esimesed sammud" loovad andmebaasi kujunduse, milles kõik suhtemuutujad on Boyce-Coddi tavakujul, mida üldiselt peetakse enamiku rakenduste jaoks rahuldavaks.

Sissejuhatus

Andmebaasi kujundamisel lahendatakse kaks peamist probleemi.

Kuidas kaardistada domeeniobjekte andmemudeli abstraktseteks objektideks nii, et see kaardistamine ei läheks vastuollu domeeni semantikaga ja oleks võimalusel parim (efektiivne, mugav jne)? Seda probleemi nimetatakse sageli probleemiks loogiline disain andmebaasid.
Kuidas tagada andmebaasi päringute täitmise efektiivsus, st kuidas, võttes arvesse konkreetse DBMS-i omadusi, korraldada andmeid välismälus, milliseid täiendavaid struktuure (näiteks indekseid) luua jne? Seda probleemi nimetatakse tavaliselt füüsilise andmebaasi kujundamise probleemiks.

Relatsiooniandmebaaside puhul on raske pakkuda mingeid üldisi retsepte füüsiliseks disainiks. Siin sõltub liiga palju kasutatavast DBMS-ist. Seetõttu piirdume loogiliste küsimustega relatsioonilise andmebaasi disain, mis on mis tahes relatsioonilise DBMS-i kasutamisel hädavajalikud.

Pealegi me väga ei puuduta oluline aspekt disain – terviklikkuse piirangute määratlemine üldine vaade(välja arvatud funktsionaalsete ja mitmeväärtuslikud sõltuvused , aga ka projektsiooni/liitumise sõltuvused). Fakt on see, et kui kasutada väljatöötatud terviklikkuse piiramise mehhanismidega DBMS-i (näiteks SQL-ile orienteeritud süsteemid), on terviklikkuse piirangute määratlemiseks keeruline universaalset lähenemisviisi pakkuda. Need piirangud võivad võtta meelevaldselt keerukaid vorme ja nende sõnastamine on ikkagi pigem kunsti kui inseneri küsimus. Kõige rohkem, mida kirjanduses selles osas soovitatakse, on automaatne kontroll terviklikkuse piirangute komplekti järjepidevus.

Seega selles ja järgmises loengus eeldame, et relatsiooniandmebaasi kujundamise probleem seisneb teadlike otsuste tegemises selle kohta, millistest suhetest andmebaas peaks koosnema ja millised atribuudid neil suhetel olema.

Selles ja järgmistes loengutes uuritakse klassikalist lähenemist, mille puhul kogu andmebaasi kujundamise protsess viiakse läbi relatsioonilise andmemudeli alusel, kasutades järjestikuste lähenduste meetodit rahuldavale seosmustrite komplektile. Lähtepunktiks on esitus ainevaldkondühe või mitme seose vormis ja igas disainietapis koostatakse teatud komplekt suhteskeeme, millel on "täiustatud" omadused. Disainiprotsess on normaliseerimisprotsess suhteskeemid, iga järgnevaga normaalne vorm on teatud mõttes paremad omadused kui eelmisel.

Iga normaalvorm on seotud teatud piirangute komplektiga ja seos on teatud normaalkujul, kui see rahuldab oma piirangute komplekti. Näiteks võiks olla piirang esimene normaalne vorm– kõigi seoste atribuutide väärtused on aatomi 1 Tuletage meelde 2. loengust, et aatomilisus väärtust tõlgendatakse selles mõttes, et väärtus kirjutatakse ja seda väärtust saab manipuleerida ainult vastavat andmetüübi operatsioonide abil.. Alates nõudest esimene normaalne vorm on klassikalise relatsiooniandmemudeli põhinõue, siis eeldame, et esialgne seoste kogum juba vastab sellele nõudele.

IN relatsiooniliste andmebaaside teooriad tavaliselt paistab silma järgmine jada Tavalised vormid: