Izraz "relacijski" pomeni "temelji na razmerju". Relacijsko zbirko podatkov sestavljajo entitete (tabele), ki so med seboj povezane. Ime izhaja iz angleške besede relation.
Oblikovanje baze podatkov je sestavljeno iz dveh glavnih faz: logičnega in fizičnega modeliranja.
Med logičnim modeliranjem zbirate zahteve in razvijate model baze podatkov, ki je neodvisen od določenega DBMS (sistema za upravljanje relacijskih baz podatkov). To je kot ustvarjanje načrtov za vašo hišo. Vse bi lahko premislili in narisali: kje bo kuhinja, spalnice, dnevna soba. Ampak to je vse na papirju in v postavitvah.
Med fizičnim modeliranjem ustvarite model, ki je optimiziran za določeno aplikacijo in DBMS. Ta model se izvaja v praksi. Če se vrnemo k hiši iz prejšnjega odstavka, boste v tej fazi morali nekje zgraditi hišo - nositi hlode, opeko ...

Postopek oblikovanja baze podatkov je sestavljen iz naslednjih korakov:

• zbiranje informacij;
• opredelitev entitet;
• definiranje atributov za vsako entiteto;
• definiranje odnosov med subjekti;
• normalizacija;
• transformacija v fizični model;
• ustvarjanje baze podatkov.

Prvih 5 stopenj tvori fazo logičnega načrtovanja, preostali dve pa fazo fizičnega modeliranja.

Logična faza

Logična faza je sestavljena iz več faz. Vsi so obravnavani spodaj.

Zahteve za zbiranje

Na tej stopnji morate natančno določiti, kako bo baza podatkov uporabljena in katere informacije bodo v njej shranjene. Zberite čim več informacij o tem, kaj naj sistem počne in kaj ne.

Definicija entitete

Na tej stopnji morate definirati entitete, iz katerih bo zbirka podatkov sestavljena.

Entiteta je objekt v bazi podatkov, ki shranjuje podatke. Entiteta je lahko nekaj realnega (hiša, oseba, predmet, kraj) ali abstraktna stvar (bančna transakcija, oddelek podjetja, avtobusna pot). V fizičnem modelu se entiteta imenuje tabela.

Entitete so sestavljene iz atributov (stolpcev v tabeli) in zapisov (vrstic v tabeli).

Običajno so zbirke podatkov sestavljene iz več primarnih entitet, povezanih z velikim številom podrejenih entitet. Osrednje entitete se imenujejo neodvisne: niso odvisne od nobene druge entitete. Podrejene entitete se imenujejo odvisne: da ena od njih obstaja, mora obstajati glavna tabela, ki je z njo povezana.
V diagramih so entitete običajno predstavljene kot pravokotniki. Ime subjekta je navedeno znotraj pravokotnika:

Vsaka miza ima naslednje značilnosti:

• v njem ni enakih vrstic;
• vsi stolpci (atributi) v tabeli morajo imeti različna imena;
• elementi v istem stolpcu imajo isto vrsto (niz, številka, datum);
• vrstni red vrstic v tabeli je lahko poljuben.

Na tej stopnji morate identificirati vse kategorije informacij (entitete), ki bodo shranjene v bazi podatkov.

Definicija atributa

Atribut predstavlja lastnost, ki opisuje entiteto. Atributi so pogosto številka, datum ali besedilo. Vsi podatki, shranjeni v atributu, morajo biti iste vrste in imeti enake lastnosti.
V fizičnem modelu se atributi imenujejo stolpci.
Po definiranju entitet je potrebno definirati vse atribute teh entitet.
V diagramih so atributi običajno navedeni znotraj pravokotnika entitete. Na sliki je primer baze "Hiše", le da so sedaj določeni nekateri atributi za entitete iz te baze.


Vsak atribut določa vrsto podatkov, velikost, dovoljene vrednosti in morebitna druga pravila. Ti vključujejo obvezna, spremenljiva pravila in pravila edinstvenosti.
Obvezno pravilo določa, ali je atribut obvezen del entitete. Če je atribut izbirni del entitete, potem je lahko NULL, sicer ne.
Ugotoviti morate tudi, ali je atribut spremenljiv. Nekaterih vrednosti atributov ni mogoče spremeniti, ko je vnos ustvarjen.
In končno morate ugotoviti, ali je atribut edinstven. Če je tako, potem vrednosti atributa ni mogoče ponoviti.

Ključi

Ključ je niz atributov, ki enolično identificira vnos. Ključi so razdeljeni v dva razreda: enostavni in sestavljeni.
Preprost ključ je sestavljen iz samo enega atributa. Na primer, v zbirki podatkov »Potni listi državljanov države« bo številka potnega lista preprost ključ: navsezadnje ni dveh potnih listov z isto številko.
Sestavljeni ključ je sestavljen iz več atributov. V isti bazi podatkov "Potni listi državljanov države" je lahko sestavljeni ključ z naslednjimi atributi:
priimek, ime, patronim, datum rojstva. To je le primer, saj ta sestavljeni ključ teoretično ne zagotavlja zajamčene unikatnosti zapisa.
Obstaja tudi več tipov ključev, ki so opisani v nadaljevanju.

Možen ključ

Ključ kandidata je kateri koli nabor atributov, ki enolično identificira vnos v tabeli. Ključ kandidata je lahko preprost ali sestavljen.
Vsaka entiteta mora imeti vsaj en možni ključ, čeprav jih je lahko več kot en možni ključ. Noben od atributov primarnega ključa ne sme imeti vrednosti NULL.
Kandidatni ključ se imenuje tudi nadomestni ključ.

Primarni ključi

Primarni ključ je niz atributov, ki enolično identificirajo zapis v tabeli (entiteto). Eden od možnih ključev postane primarni ključ. V diagramih so primarni ključi pogosto prikazani nad glavnim seznamom atributov ali označeni s posebnimi znaki. Entiteta na sliki ima tako ključne kot običajne atribute.

Alternativni ključi

Vsak možen ključ, ki ni primarni ključ, se imenuje nadomestni ključ. Entiteta ima lahko več nadomestnih ključev.

Tuji ključi

Tuji ključ je zbirka atributov, ki se nanašajo na primarni ali nadomestni ključ druge entitete. Če tuji ključ ni povezan s primarno entiteto, potem lahko vsebuje samo ničelne vrednosti. Če je ključ tudi sestavljen, morajo biti vsi atributi tujega ključa nedefinirani.
V diagramih so atributi, ki so združeni v tuje ključe, označeni s posebnimi znaki. Slika prikazuje dve povezani entiteti (Hiše in njihovi lastniki) in tuje ključe, ki jih tvorita (navsezadnje je lahko ena oseba lastnik več kot ene hiše).

Ključi so logični konstrukti, ne fizični objekti. Relacijske baze podatkov imajo mehanizme za shranjevanje ključev.

Definiranje odnosov med entitetami

Relacijske baze podatkov vam omogočajo združevanje informacij, ki pripadajo različnim entitetam.
Razmerje je situacija, v kateri se ena entiteta nanaša na primarni ključ druge entitete. Tako kot na primer entiteti Hiša in Gospodar na prejšnji sliki.
Odnosi so definirani med postopkom osnovnega oblikovanja. Če želite to narediti, morate analizirati entitete in prepoznati logične odnose, ki obstajajo med njimi.
Vrsta razmerja določa število zapisov entitete, povezanih z drugim zapisom entitete. Odnosi so razdeljeni na tri glavne vrste, ki so opisane spodaj.

Ena proti ena

Vsak vnos prve entitete ustreza samo enemu vnosu druge entitete. In vsak zapis druge entitete ustreza samo enemu zapisu iz prve entitete. Na primer, obstajata dve entiteti: ljudje in rojstni listi. In ena oseba ima lahko samo en rojstni list.

Eden proti mnogo

Vsak zapis prve entitete lahko ustreza več zapisom iz druge entitete. Vendar vsak vnos druge entitete ustreza samo enemu vnosu prve entitete. Na primer, obstajata dve entiteti: Naročilo in Postavka naročila. In v enem naročilu je lahko veliko predmetov.

mnogo-proti-mnogim

Vsak zapis prve entitete lahko ustreza več zapisom iz druge entitete. Vendar lahko vsak zapis druge entitete ustreza več zapisom iz prve entitete. Na primer, obstajata dve entiteti: avtor in knjiga. En avtor lahko napiše veliko knjig. Toda knjiga ima lahko več avtorjev.
Po kriteriju obligacijskega razmerja se delijo na obvezna in fakultativna.

• Obvezno razmerje pomeni, da morajo za vsak vnos iz prve entitete obstajati povezani vnosi v drugi entiteti.
• Izbirno razmerje pomeni, da zapis iz prve entitete morda nima zapisa v drugi entiteti.

Normalizacija

Normalizacija je postopek odstranjevanja odvečnih podatkov iz baze podatkov. Vsak podatkovni element mora biti shranjen v bazi podatkov v enem in samo enem primerku. Obstaja pet pogostih oblik normalizacije. Baza podatkov je praviloma reducirana na tretjo normalno obliko.
Med postopkom normalizacije se izvedejo določena dejanja za odstranitev odvečnih podatkov. Normalizacija izboljša zmogljivost, pospeši razvrščanje in gradnjo indeksov, zmanjša število indeksov na entiteto ter pospeši operacije vstavljanja in posodabljanja.
Normalizirana zbirka podatkov je običajno bolj prilagodljiva. Pri spreminjanju poizvedb ali trajnih podatkov normalizirana zbirka podatkov običajno zahteva manj sprememb, spremembe pa imajo manj posledic.

Prva normalna oblika

Če želite pretvoriti entiteto v prvo običajno obliko, morate odstraniti podvojene skupine vrednosti in zagotoviti, da vsak atribut vsebuje samo eno vrednost, seznami vrednosti niso dovoljeni.
Z drugimi besedami, vsak atribut v entiteti mora biti shranjen samo v enem primerku.
Na sliki na primer entiteta House ni normalizirana. Vsebuje več atributov za shranjevanje podatkov o lastnikih hiše (entiteta Hiša ne ustreza prvi normalni obliki).

Če želite entiteto House prenesti v prvo normalno obliko, je treba odstraniti ponavljajoče se skupine vrednosti, to je odstraniti atribute Lastnik 1-3 in jih postaviti v ločeno entiteto. Rezultat (Entity House zmanjšana na prvo normalno obliko):

Druga normalna oblika

Tabela v drugi normalni obliki vsebuje samo podatke, ki veljajo zanjo. Vrednosti atributov entitete brez ključa so odvisne od primarnega ključa. Natančneje, atributi so odvisni od primarnega ključa, od celotnega primarnega ključa in samo od primarnega ključa.
Entitete morajo biti v prvi normalni obliki, da ustrezajo drugi normalni obliki.
Na primer, entiteta Hiša na sliki ima atribut Cena za liter bencina, ki nima nobene zveze s hišami. Ta atribut je odstranjen (lahko pa ga premaknete v drugo entiteto). Prav tako premaknemo atribut Župan v ločeno entiteto - ta atribut je odvisen od mesta, kjer se hiša nahaja, in ne od hiše.
Slika prikazuje esenčno hišo v drugi normalni obliki (Esenčna hiša reducirana na drugo normalno obliko).

tretja normalna oblika

Tretja normalna oblika izključuje atribute, ki niso odvisni od celotnega ključa. Vsaka entiteta, ki je v tretji normalni obliki, je tudi v drugi normalni obliki. To je najpogostejša oblika baze podatkov.
V tretji normalni obliki je vsak atribut odvisen od ključa, od celotnega ključa in od nič drugega kot od ključa.
Na primer, entiteta Lastnik hiše na sliki ima atribut znaka zodiaka, ki je odvisen od datuma rojstva lastnika hiše in ne od njegovega imena (ki je ključno).
Če želite prenesti entiteto Lastnik hiše, morate ustvariti entiteto Znaki zodiaka in tja prenesti atribut Znak zodiaka (Entiteta Lastnik hiše, zmanjšana na tretjo normalno obliko):

Omejitve

Omejitve so pravila, ki jih uveljavlja sistem za upravljanje baze podatkov. Omejitve določajo niz vrednosti, ki jih je mogoče vnesti v stolpec ali stolpce.
Na primer, ne želite, da je znesek naročila v vaši zelo kul trgovini nižji od 500 rubljev. Preprosto nastavite omejitev v stolpcu Znesek naročila.

Shranjeni postopki

Shranjene procedure so vnaprej prevedene procedure, shranjene v bazi podatkov. Shranjene procedure se lahko uporabljajo za definiranje poslovnih pravil in za izvajanje bolj zapletenih izračunov kot same omejitve.
Shranjene procedure lahko vsebujejo logiko poteka programa kot tudi poizvedbe po bazi podatkov. Sprejmejo lahko parametre in vrnejo rezultate kot tabele ali posamezne vrednosti.
Shranjene procedure so kot običajne procedure ali funkcije v katerem koli programu.

OPOMBA
Shranjene procedure se nahajajo v bazi podatkov in se izvajajo na strežniku baze podatkov. Na splošno so hitrejši od stavkov SQL, ker so shranjeni v prevedeni obliki.

Celovitost podatkov

Z organizacijo podatkov v tabele in definiranjem odnosov med njimi lahko domnevamo, da je ustvarjen model, ki pravilno odraža poslovno okolje. Zdaj moramo zagotoviti, da podatki, vneseni v bazo podatkov, dajejo pravilno predstavo o stanju zadeve. Z drugimi besedami, uveljaviti morate poslovna pravila in ohraniti celovitost baze podatkov.
Na primer, vaše podjetje se ukvarja z dostavo knjig. Malo verjetno je, da boste sprejeli naročilo od neznanega naročnika, saj potem naročila ne boste mogli niti dostaviti. Od tod poslovno pravilo: sprejemamo naročila samo od strank, katerih podatki so v bazi podatkov.
Pravilnost podatkov v relacijskih bazah zagotavlja niz pravil. Pravila celovitosti podatkov spadajo v štiri kategorije.

• Celovitost entitete- vsak zapis entitete mora imeti edinstven identifikator in vsebovati podatke. Navsezadnje morate nekako razlikovati med vsemi temi zapisi v bazi podatkov.
• Celovitost atributa- vsak atribut sprejema samo dovoljene vrednosti. Na primer, znesek nakupa zagotovo ne more biti manjši od nič.
• Referenčna integriteta- nabor pravil, ki zagotavljajo logično konsistentnost primarnih in tujih ključev pri vnašanju, posodabljanju in brisanju zapisov. Referenčna celovitost zagotavlja, da za vsak tuji ključ obstaja ustrezni primarni ključ. Vzemimo prejšnji primer z entitetama Lastnik doma in Dom. Recimo, da ste Vasya Ivanov in imate hišo. Spremenili ste svoj priimek v Sidorov in naredili ustrezne spremembe v entiteti Lastnik hiše. Vsekakor bi si želeli, da bi bila vaša hiša še naprej vaša pod vašim novim imenom in ne v lasti nekega Vasje Ivanova, ki ne obstaja več.
• Pravila integritete po meri- vsa pravila integritete, ki ne sodijo v nobeno od navedenih kategorij.

sprožilci

Sprožilec je analog shranjene procedure, ki se samodejno pokliče, ko se podatki v tabeli spremenijo.
Sprožilci so zmogljiv mehanizem za ohranjanje celovitosti baze podatkov. Sprožilci se kličejo pred ali po spremembi podatkov v tabeli.
S pomočjo sprožilcev ne morete samo razveljaviti teh sprememb, ampak tudi spremeniti podatke v kateri koli drugi tabeli.
Na primer, ustvarjate internetni forum in se želite prepričati, da seznam forumov prikazuje najnovejšo objavo na forumu. Seveda lahko vzamete sporočilo iz entitete Objave na forumu, vendar bo to povečalo kompleksnost vaše zahteve in čas njene izvedbe. Lažje je dodati sprožilec entiteti Objave na forumu, ki beleži zadnjo objavo, dodano entiteti Forumi, v atributu Zadnja objava. To bo zelo poenostavilo poizvedbo.

Poslovna pravila

Poslovna pravila določajo omejitve podatkov glede na zahteve podjetja (za katerega ustvarjate bazo). Poslovna pravila so lahko sestavljena iz niza korakov, potrebnih za dokončanje določene naloge, ali pa so preprosto preverjanja, ki preverjajo, ali so vneseni podatki pravilni. Poslovna pravila lahko vključujejo pravila celovitosti podatkov. Za razliko od drugih pravil je njihov glavni namen zagotoviti, da se poslovne transakcije izvajajo pravilno.
Na primer, v podjetju Very Tough Guys je morda običajno, da se za službeno uporabo kupujejo samo beli, modri in črni avtomobili.
Poslovno pravilo za atribut Barva vozila entitete Službena vozila bi potem bilo, da je vozilo lahko samo belo, modro ali črno.
Večina DBMS ponuja sredstva za:

• določiti privzete vrednosti;
• preveriti podatke pred vnosom v bazo podatkov;
• vzdrževati razmerja med tabelami;
• zagotoviti edinstvenost vrednot;
• za shranjevanje shranjenih procedur neposredno v bazi podatkov.

Vse te funkcije je mogoče uporabiti za izvajanje poslovnih pravil v bazi podatkov.

Fizični model

Naslednji korak po izdelavi logičnega modela je izgradnja fizičnega modela. Fizični model je praktična izvedba baze podatkov. Fizični model definira vse objekte, ki jih morate implementirati.
Pri prehodu iz logičnega modela v fizično entiteto se pretvorijo v tabele, atributi pa v stolpce.
Relacije med entitetami je mogoče pretvoriti v tabele ali pustiti kot tuje ključe.
Primarni ključi se pretvorijo v omejitve primarnega ključa. Možni ključi so v omejitvah edinstvenosti.

Denormalizacija

Denormalizacija- to je namerna sprememba strukture baze, ki krši pravila normalnih oblik. To se običajno naredi za izboljšanje zmogljivosti baze podatkov.
Teoretično si moramo vedno prizadevati za popolnoma normalizirano osnovo, v praksi pa popolnoma normalizirana osnova skoraj vedno pomeni padec zmogljivosti. Prekomerna normalizacija baze podatkov lahko povzroči dostop do več tabel ob vsakem pridobivanju podatkov. Običajno morajo v poizvedbi sodelovati štiri tabele ali manj.
Standardne tehnike denormalizacije so: združevanje več tabel v eno, shranjevanje istih atributov v več tabel in shranjevanje povzetkov ali izračunanih podatkov v tabeli.

Izraz "relacijski" pomeni "temelji na razmerju". Relacijsko zbirko podatkov sestavljajo entitete (tabele), ki so med seboj povezane. Ime izhaja iz angleške besede relation.
Oblikovanje baze podatkov je sestavljeno iz dveh glavnih faz: logičnega in fizičnega modeliranja.
Med logičnim modeliranjem zbirate zahteve in razvijate model baze podatkov, ki je neodvisen od določenega DBMS (sistema za upravljanje relacijskih baz podatkov). To je kot ustvarjanje načrtov za vašo hišo. Vse bi lahko premislili in narisali: kje bo kuhinja, spalnice, dnevna soba. Ampak to je vse na papirju in v postavitvah.
Med fizičnim modeliranjem ustvarite model, ki je optimiziran za določeno aplikacijo in DBMS. Ta model se izvaja v praksi. Če se vrnemo k hiši iz prejšnjega odstavka, boste v tej fazi morali nekje zgraditi hišo - nositi hlode, opeko ...

Postopek oblikovanja baze podatkov je sestavljen iz naslednjih korakov:

• zbiranje informacij;
• opredelitev entitet;
• definiranje atributov za vsako entiteto;
• definiranje odnosov med subjekti;
• normalizacija;
• transformacija v fizični model;
• ustvarjanje baze podatkov.

Prvih 5 stopenj tvori fazo logičnega načrtovanja, preostali dve pa fazo fizičnega modeliranja.

Logična faza

Logična faza je sestavljena iz več faz. Vsi so obravnavani spodaj.

Zahteve za zbiranje

Na tej stopnji morate natančno določiti, kako bo baza podatkov uporabljena in katere informacije bodo v njej shranjene. Zberite čim več informacij o tem, kaj naj sistem počne in kaj ne.

Definicija entitete

Na tej stopnji morate definirati entitete, iz katerih bo zbirka podatkov sestavljena.

Entiteta je objekt v bazi podatkov, ki shranjuje podatke. Entiteta je lahko nekaj realnega (hiša, oseba, predmet, kraj) ali abstraktna stvar (bančna transakcija, oddelek podjetja, avtobusna pot). V fizičnem modelu se entiteta imenuje tabela.

Entitete so sestavljene iz atributov (stolpcev v tabeli) in zapisov (vrstic v tabeli).

Običajno so zbirke podatkov sestavljene iz več primarnih entitet, povezanih z velikim številom podrejenih entitet. Osrednje entitete se imenujejo neodvisne: niso odvisne od nobene druge entitete. Podrejene entitete se imenujejo odvisne: da ena od njih obstaja, mora obstajati glavna tabela, ki je z njo povezana.
V diagramih so entitete običajno predstavljene kot pravokotniki. Ime subjekta je navedeno znotraj pravokotnika:

Vsaka miza ima naslednje značilnosti:

• v njem ni enakih vrstic;
• vsi stolpci (atributi) v tabeli morajo imeti različna imena;
• elementi v istem stolpcu imajo isto vrsto (niz, številka, datum);
• vrstni red vrstic v tabeli je lahko poljuben.

Na tej stopnji morate identificirati vse kategorije informacij (entitete), ki bodo shranjene v bazi podatkov.

Definicija atributa

Atribut predstavlja lastnost, ki opisuje entiteto. Atributi so pogosto številka, datum ali besedilo. Vsi podatki, shranjeni v atributu, morajo biti iste vrste in imeti enake lastnosti.
V fizičnem modelu se atributi imenujejo stolpci.
Po definiranju entitet je potrebno definirati vse atribute teh entitet.
V diagramih so atributi običajno navedeni znotraj pravokotnika entitete. Na sliki je primer baze "Hiše", le da so sedaj določeni nekateri atributi za entitete iz te baze.


Vsak atribut določa vrsto podatkov, velikost, dovoljene vrednosti in morebitna druga pravila. Ti vključujejo obvezna, spremenljiva pravila in pravila edinstvenosti.
Obvezno pravilo določa, ali je atribut obvezen del entitete. Če je atribut izbirni del entitete, potem je lahko NULL, sicer ne.
Ugotoviti morate tudi, ali je atribut spremenljiv. Nekaterih vrednosti atributov ni mogoče spremeniti, ko je vnos ustvarjen.
In končno morate ugotoviti, ali je atribut edinstven. Če je tako, potem vrednosti atributa ni mogoče ponoviti.

Ključi

Ključ je niz atributov, ki enolično identificira vnos. Ključi so razdeljeni v dva razreda: enostavni in sestavljeni.
Preprost ključ je sestavljen iz samo enega atributa. Na primer, v zbirki podatkov »Potni listi državljanov države« bo številka potnega lista preprost ključ: navsezadnje ni dveh potnih listov z isto številko.
Sestavljeni ključ je sestavljen iz več atributov. V isti bazi podatkov "Potni listi državljanov države" je lahko sestavljeni ključ z naslednjimi atributi:
priimek, ime, patronim, datum rojstva. To je le primer, saj ta sestavljeni ključ teoretično ne zagotavlja zajamčene unikatnosti zapisa.
Obstaja tudi več tipov ključev, ki so opisani v nadaljevanju.

Možen ključ

Ključ kandidata je kateri koli nabor atributov, ki enolično identificira vnos v tabeli. Ključ kandidata je lahko preprost ali sestavljen.
Vsaka entiteta mora imeti vsaj en možni ključ, čeprav jih je lahko več kot en možni ključ. Noben od atributov primarnega ključa ne sme imeti vrednosti NULL.
Kandidatni ključ se imenuje tudi nadomestni ključ.

Primarni ključi

Primarni ključ je niz atributov, ki enolično identificirajo zapis v tabeli (entiteto). Eden od možnih ključev postane primarni ključ. V diagramih so primarni ključi pogosto prikazani nad glavnim seznamom atributov ali označeni s posebnimi znaki. Entiteta na sliki ima tako ključne kot običajne atribute.

Alternativni ključi

Vsak možen ključ, ki ni primarni ključ, se imenuje nadomestni ključ. Entiteta ima lahko več nadomestnih ključev.

Tuji ključi

Tuji ključ je zbirka atributov, ki se nanašajo na primarni ali nadomestni ključ druge entitete. Če tuji ključ ni povezan s primarno entiteto, potem lahko vsebuje samo ničelne vrednosti. Če je ključ tudi sestavljen, morajo biti vsi atributi tujega ključa nedefinirani.
V diagramih so atributi, ki so združeni v tuje ključe, označeni s posebnimi znaki. Slika prikazuje dve povezani entiteti (Hiše in njihovi lastniki) in tuje ključe, ki jih tvorita (navsezadnje je lahko ena oseba lastnik več kot ene hiše).

Ključi so logični konstrukti, ne fizični objekti. Relacijske baze podatkov imajo mehanizme za shranjevanje ključev.

Definiranje odnosov med entitetami

Relacijske baze podatkov vam omogočajo združevanje informacij, ki pripadajo različnim entitetam.
Razmerje je situacija, v kateri se ena entiteta nanaša na primarni ključ druge entitete. Tako kot na primer entiteti Hiša in Gospodar na prejšnji sliki.
Odnosi so definirani med postopkom osnovnega oblikovanja. Če želite to narediti, morate analizirati entitete in prepoznati logične odnose, ki obstajajo med njimi.
Vrsta razmerja določa število zapisov entitete, povezanih z drugim zapisom entitete. Odnosi so razdeljeni na tri glavne vrste, ki so opisane spodaj.

Ena proti ena

Vsak vnos prve entitete ustreza samo enemu vnosu druge entitete. In vsak zapis druge entitete ustreza samo enemu zapisu iz prve entitete. Na primer, obstajata dve entiteti: ljudje in rojstni listi. In ena oseba ima lahko samo en rojstni list.

Eden proti mnogo

Vsak zapis prve entitete lahko ustreza več zapisom iz druge entitete. Vendar vsak vnos druge entitete ustreza samo enemu vnosu prve entitete. Na primer, obstajata dve entiteti: Naročilo in Postavka naročila. In v enem naročilu je lahko veliko predmetov.

mnogo-proti-mnogim

Vsak zapis prve entitete lahko ustreza več zapisom iz druge entitete. Vendar lahko vsak zapis druge entitete ustreza več zapisom iz prve entitete. Na primer, obstajata dve entiteti: avtor in knjiga. En avtor lahko napiše veliko knjig. Toda knjiga ima lahko več avtorjev.
Po kriteriju obligacijskega razmerja se delijo na obvezna in fakultativna.

• Obvezno razmerje pomeni, da morajo za vsak vnos iz prve entitete obstajati povezani vnosi v drugi entiteti.
• Izbirno razmerje pomeni, da zapis iz prve entitete morda nima zapisa v drugi entiteti.

Normalizacija

Normalizacija je postopek odstranjevanja odvečnih podatkov iz baze podatkov. Vsak podatkovni element mora biti shranjen v bazi podatkov v enem in samo enem primerku. Obstaja pet pogostih oblik normalizacije. Baza podatkov je praviloma reducirana na tretjo normalno obliko.
Med postopkom normalizacije se izvedejo določena dejanja za odstranitev odvečnih podatkov. Normalizacija izboljša zmogljivost, pospeši razvrščanje in gradnjo indeksov, zmanjša število indeksov na entiteto ter pospeši operacije vstavljanja in posodabljanja.
Normalizirana zbirka podatkov je običajno bolj prilagodljiva. Pri spreminjanju poizvedb ali trajnih podatkov normalizirana zbirka podatkov običajno zahteva manj sprememb, spremembe pa imajo manj posledic.

Prva normalna oblika

Če želite pretvoriti entiteto v prvo običajno obliko, morate odstraniti podvojene skupine vrednosti in zagotoviti, da vsak atribut vsebuje samo eno vrednost, seznami vrednosti niso dovoljeni.
Z drugimi besedami, vsak atribut v entiteti mora biti shranjen samo v enem primerku.
Na sliki na primer entiteta House ni normalizirana. Vsebuje več atributov za shranjevanje podatkov o lastnikih hiše (entiteta Hiša ne ustreza prvi normalni obliki).

Če želite entiteto House prenesti v prvo normalno obliko, je treba odstraniti ponavljajoče se skupine vrednosti, to je odstraniti atribute Lastnik 1-3 in jih postaviti v ločeno entiteto. Rezultat (Entity House zmanjšana na prvo normalno obliko):

Druga normalna oblika

Tabela v drugi normalni obliki vsebuje samo podatke, ki veljajo zanjo. Vrednosti atributov entitete brez ključa so odvisne od primarnega ključa. Natančneje, atributi so odvisni od primarnega ključa, od celotnega primarnega ključa in samo od primarnega ključa.
Entitete morajo biti v prvi normalni obliki, da ustrezajo drugi normalni obliki.
Na primer, entiteta Hiša na sliki ima atribut Cena za liter bencina, ki nima nobene zveze s hišami. Ta atribut je odstranjen (lahko pa ga premaknete v drugo entiteto). Prav tako premaknemo atribut Župan v ločeno entiteto - ta atribut je odvisen od mesta, kjer se hiša nahaja, in ne od hiše.
Slika prikazuje esenčno hišo v drugi normalni obliki (Esenčna hiša reducirana na drugo normalno obliko).

tretja normalna oblika

Tretja normalna oblika izključuje atribute, ki niso odvisni od celotnega ključa. Vsaka entiteta, ki je v tretji normalni obliki, je tudi v drugi normalni obliki. To je najpogostejša oblika baze podatkov.
V tretji normalni obliki je vsak atribut odvisen od ključa, od celotnega ključa in od nič drugega kot od ključa.
Na primer, entiteta Lastnik hiše na sliki ima atribut znaka zodiaka, ki je odvisen od datuma rojstva lastnika hiše in ne od njegovega imena (ki je ključno).
Če želite prenesti entiteto Lastnik hiše, morate ustvariti entiteto Znaki zodiaka in tja prenesti atribut Znak zodiaka (Entiteta Lastnik hiše, zmanjšana na tretjo normalno obliko):

Omejitve

Omejitve so pravila, ki jih uveljavlja sistem za upravljanje baze podatkov. Omejitve določajo niz vrednosti, ki jih je mogoče vnesti v stolpec ali stolpce.
Na primer, ne želite, da je znesek naročila v vaši zelo kul trgovini nižji od 500 rubljev. Preprosto nastavite omejitev v stolpcu Znesek naročila.

Shranjeni postopki

Shranjene procedure so vnaprej prevedene procedure, shranjene v bazi podatkov. Shranjene procedure se lahko uporabljajo za definiranje poslovnih pravil in za izvajanje bolj zapletenih izračunov kot same omejitve.
Shranjene procedure lahko vsebujejo logiko poteka programa kot tudi poizvedbe po bazi podatkov. Sprejmejo lahko parametre in vrnejo rezultate kot tabele ali posamezne vrednosti.
Shranjene procedure so kot običajne procedure ali funkcije v katerem koli programu.

OPOMBA
Shranjene procedure se nahajajo v bazi podatkov in se izvajajo na strežniku baze podatkov. Na splošno so hitrejši od stavkov SQL, ker so shranjeni v prevedeni obliki.

Celovitost podatkov

Z organizacijo podatkov v tabele in definiranjem odnosov med njimi lahko domnevamo, da je ustvarjen model, ki pravilno odraža poslovno okolje. Zdaj moramo zagotoviti, da podatki, vneseni v bazo podatkov, dajejo pravilno predstavo o stanju zadeve. Z drugimi besedami, uveljaviti morate poslovna pravila in ohraniti celovitost baze podatkov.
Na primer, vaše podjetje se ukvarja z dostavo knjig. Malo verjetno je, da boste sprejeli naročilo od neznanega naročnika, saj potem naročila ne boste mogli niti dostaviti. Od tod poslovno pravilo: sprejemamo naročila samo od strank, katerih podatki so v bazi podatkov.
Pravilnost podatkov v relacijskih bazah zagotavlja niz pravil. Pravila celovitosti podatkov spadajo v štiri kategorije.

• Celovitost entitete- vsak zapis entitete mora imeti edinstven identifikator in vsebovati podatke. Navsezadnje morate nekako razlikovati med vsemi temi zapisi v bazi podatkov.
• Celovitost atributa- vsak atribut sprejema samo dovoljene vrednosti. Na primer, znesek nakupa zagotovo ne more biti manjši od nič.
• Referenčna integriteta- nabor pravil, ki zagotavljajo logično konsistentnost primarnih in tujih ključev pri vnašanju, posodabljanju in brisanju zapisov. Referenčna celovitost zagotavlja, da za vsak tuji ključ obstaja ustrezni primarni ključ. Vzemimo prejšnji primer z entitetama Lastnik doma in Dom. Recimo, da ste Vasya Ivanov in imate hišo. Spremenili ste svoj priimek v Sidorov in naredili ustrezne spremembe v entiteti Lastnik hiše. Vsekakor bi si želeli, da bi bila vaša hiša še naprej vaša pod vašim novim imenom in ne v lasti nekega Vasje Ivanova, ki ne obstaja več.
• Pravila integritete po meri- vsa pravila integritete, ki ne sodijo v nobeno od navedenih kategorij.

sprožilci

Sprožilec je analog shranjene procedure, ki se samodejno pokliče, ko se podatki v tabeli spremenijo.
Sprožilci so zmogljiv mehanizem za ohranjanje celovitosti baze podatkov. Sprožilci se kličejo pred ali po spremembi podatkov v tabeli.
S pomočjo sprožilcev ne morete samo razveljaviti teh sprememb, ampak tudi spremeniti podatke v kateri koli drugi tabeli.
Na primer, ustvarjate internetni forum in se želite prepričati, da seznam forumov prikazuje najnovejšo objavo na forumu. Seveda lahko vzamete sporočilo iz entitete Objave na forumu, vendar bo to povečalo kompleksnost vaše zahteve in čas njene izvedbe. Lažje je dodati sprožilec entiteti Objave na forumu, ki beleži zadnjo objavo, dodano entiteti Forumi, v atributu Zadnja objava. To bo zelo poenostavilo poizvedbo.

Poslovna pravila

Poslovna pravila določajo omejitve podatkov glede na zahteve podjetja (za katerega ustvarjate bazo). Poslovna pravila so lahko sestavljena iz niza korakov, potrebnih za dokončanje določene naloge, ali pa so preprosto preverjanja, ki preverjajo, ali so vneseni podatki pravilni. Poslovna pravila lahko vključujejo pravila celovitosti podatkov. Za razliko od drugih pravil je njihov glavni namen zagotoviti, da se poslovne transakcije izvajajo pravilno.
Na primer, v podjetju Very Tough Guys je morda običajno, da se za službeno uporabo kupujejo samo beli, modri in črni avtomobili.
Poslovno pravilo za atribut Barva vozila entitete Službena vozila bi potem bilo, da je vozilo lahko samo belo, modro ali črno.
Večina DBMS ponuja sredstva za:

• določiti privzete vrednosti;
• preveriti podatke pred vnosom v bazo podatkov;
• vzdrževati razmerja med tabelami;
• zagotoviti edinstvenost vrednot;
• za shranjevanje shranjenih procedur neposredno v bazi podatkov.

Vse te funkcije je mogoče uporabiti za izvajanje poslovnih pravil v bazi podatkov.

Fizični model

Naslednji korak po izdelavi logičnega modela je izgradnja fizičnega modela. Fizični model je praktična izvedba baze podatkov. Fizični model definira vse objekte, ki jih morate implementirati.
Pri prehodu iz logičnega modela v fizično entiteto se pretvorijo v tabele, atributi pa v stolpce.
Relacije med entitetami je mogoče pretvoriti v tabele ali pustiti kot tuje ključe.
Primarni ključi se pretvorijo v omejitve primarnega ključa. Možni ključi so v omejitvah edinstvenosti.

Denormalizacija

Denormalizacija- to je namerna sprememba strukture baze, ki krši pravila normalnih oblik. To se običajno naredi za izboljšanje zmogljivosti baze podatkov.
Teoretično si moramo vedno prizadevati za popolnoma normalizirano osnovo, v praksi pa popolnoma normalizirana osnova skoraj vedno pomeni padec zmogljivosti. Prekomerna normalizacija baze podatkov lahko povzroči dostop do več tabel ob vsakem pridobivanju podatkov. Običajno morajo v poizvedbi sodelovati štiri tabele ali manj.
Standardne tehnike denormalizacije so: združevanje več tabel v eno, shranjevanje istih atributov v več tabel in shranjevanje povzetkov ali izračunanih podatkov v tabeli.

Atribut.

Predmetno področje.

Baza podatkov. Opredelitev.

DBMS. Opredelitev.

Baza podatkov. Opredelitev.

Tretja normalna oblika. Opredelitev. Primer.

Relacijska spremenljivka R je v tretji normalni obliki, če in samo če so izpolnjeni naslednji pogoji:

R je v drugi normalni obliki.

· noben neključni atribut R ni v tranzitivni funkcijski odvisnosti (tj. odvisnost ni izražena z drugim atributom) od potencialnega ključa R.

Neključni atribut relacije R je atribut, ki ne pripada nobenemu od kandidatnih ključev R.

Baza podatkov- to je ena ali več podatkovnih datotek, namenjenih shranjevanju, spreminjanju in obdelavi velikih količin medsebojno povezanih informacij, sistematiziranih na način, da je te materiale mogoče najti in obdelati z uporabo elektronskega računalnika (računalnika)

Sistem za upravljanje baz podatkov (DBMS) je programska oprema, ki uporabnikom omogoča definiranje, ustvarjanje in vzdrževanje baze podatkov ter obravnava klice baze podatkov iz aplikacij za končne uporabnike.

Baza podatkov- avtomatiziran informacijski sistem centraliziranega shranjevanja in zbirne uporabe podatkov. Banka podatkov vključuje eno ali več baz podatkov, imenik baz podatkov, DBMS ter knjižnice poizvedb in uporabniških programov.

Predmetno področje je del resničnega sveta, ki ga je treba preučiti, da bi ustvarili bazo podatkov za avtomatizacijo procesa upravljanja.

Atribut je najmanjša enota podatkovne strukture. Vsakemu elementu je dodeljeno edinstveno ime, ko je zbirka podatkov ustvarjena. Med obdelavo se sklicuje na to ime.

Esenca- vsak konkreten ali abstrakten predmet na obravnavanem predmetnem področju. Entitete so osnovne vrste informacij, ki so shranjene v bazi podatkov (v relacijski bazi podatkov je vsaki entiteti dodeljena tabela).

Navedite funkcije DBMS

Glavne funkcije DBMS:

1) Določitev strukture ustvarjene baze podatkov, njena inicializacija in začetno nalaganje.

2) Zagotavljanje uporabnikom možnosti manipulacije s podatki (izbira potrebnih podatkov, izvajanje izračunov, razvoj vhodno/izhodnega vmesnika, vizualizacija).

3) Zagotavljanje logične in fizične neodvisnosti podatkov.

4) Zaščita logične celovitosti baze podatkov – zanesljivost podatkov je lahko kršena pri vnosu le-teh v bazo ali ob nezakonitih dejanjih postopkov obdelave podatkov, ki sprejemajo in vnašajo napačne podatke v bazo. Za povečanje zanesljivosti podatkov v sistemu so deklarirane tako imenovane omejitve integritete.

5) Zaščita fizične celovitosti - orodja za obnovitev baze podatkov (transakcije).

6) Upravljanje uporabniških dovoljenj za dostop do baze podatkov.

7) Sinhronizacija dela več uporabnikov.

8) Upravljanje virov shranjevalnega okolja - DBMS dodeljuje pomnilniške vire za nove podatke, prerazporeja sproščeni pomnilnik, organizira čakalno vrsto zahtev za zunanji pomnilnik itd.

9) Podpora dejavnosti osebja sistema

Dokumentarni pristop, ki temelji na klasičnem upoštevanju predmetnega področja, vključuje ustvarjanje tipov entitet na podlagi atributov vsakega dokumenta, ki tvorijo splošen nabor takih tipov entitet (entitet atributov), ​​da njihova zveza predstavlja relacijo v prvi normalni obliki (slika 4.2).

V tem primeru je predhodna analiza dokumentov razkrila niz atributov, ki jih je treba predstaviti pri izdelavi modela baze podatkov. Moramo zgraditi model baze podatkov za oblikovanje dokumenta D1 "Naročilo". Dokument vsebuje 10 atributov, od katerih je vsak predstavljen z ločenim tipom entitete, ki vsebuje ustrezen atribut preprostega tipa. Vendar te predstavitve ni mogoče šteti za popolnoma pravilno, saj obstaja en atribut v dokumentu, ki ga ni primerno upoštevati, glede na to, da je smiseln samo znotraj dokumenta in označuje neko instanco razmerja v njegovi predstavitvi v dokumentu. Ta atribut je "Številka predmeta". Dejansko se njegova predstavitev v dokumentu, to kaže analiza dokumenta, izvaja v procesu odražanja naročenega blaga, številčenje pa se oblikuje glede na dokument kot predmet predmetnega področja in ne skladiščenje. prostor za informacije o naročenem blagu. Ker primer torej nima naloge shranjevanja informacij o objektu "Dokument" in njegove predstavitve uporabniku, je atribut "Številka artikla" z vidika odnosa do naročila in izdelka nesmiseln. Vendar ga zdaj ne bomo odstranili s seznama obravnavanih atributov in tipov entitet, saj ga obravnavamo kot atribut, ki označuje vrstni red blaga v naročilu.

Pri ekstrahiranju vrst entitet iz atributov dokumenta razvijalec doda še eno značilnost tistim, ki so že v dokumentu, in opis vrst entitet bo postal nekoliko bolj popoln (tabela 4.5), ob upoštevanju njihove poznejše predstavitve v modelu.

Tabela 4.5

Opis tipov entitet tip entitete Opomba Številka naročila Številka naročila datum naročila datum naročila Številka artikla Številka artikla Ime Cena izdelka Cena izdelka Cena Cena Izračunano: Cena Cena Izračunano: 511M(<7>) na zahtevo<1> Simbolično cena Simbolična vrednost naročila Nastane s prevajanjem številske vrednosti v simbolni izraz Količina Količina

Ta opis predstavlja značilnosti, ki so pomembne za model baze podatkov:

• tip podatkov - opis v smislu modela baze podatkov vrst shranjenih informacij, ki na ravni fizične izvedbe določajo načela predstavitve in obdelave v bazi podatkov;
• dimenzija - značilnost, ki se uporablja za nekatere tipe podatkov za določanje števila znakov (bajtov), ​​ki se uporabijo pri shranjevanju ustrezne vrednosti.

V predstavljeni tabeli z opisom tipov entitet stolpec »Dimenzija« za nekatere tipe podatkov vsebuje številsko vrednost v zavitih oklepajih. To se naredi zato, ker so celoštevilski, logični podatki ter datum in čas v bazah podatkov predstavljeni s standardnimi predstavitvenimi mehanizmi, velikost v bajtih pa je vedno znana za shranjevanje podatkov teh vrst.

Numerični podatkovni tipi in njim enak logični podatkovni tip imajo vedno fiksno dimenzijo:

• Boolean, Logical, Tinylnt, Bit - logični (Boolean, Logical) podatkovni kositer, ki vsebuje vrednosti "True" (true) in "False" (false), identične majhnemu celemu kositru (Tinylnt) ali bitu (Bit) z najmanjša dimenzija 1 bajt (1 bit, če je enak tipu bita) in vrednosti "0" ali "1";
• Bit je celoštevilski podatkovni tip, ki predstavlja vrednosti "0" ali "1", z dimenzijo 1 bit;
• Tinylnt je celoštevilski podatkovni tip z dimenzijo 1 bajt;
• SmallInt je celoštevilski podatkovni tip z dimenzijo 2 bajtov;
• Integer - celoštevilski podatkovni tip z dimenzijo 4 bajtov;
• BigInt, Long - celoštevilski tip velike dimenzije (8 bajtov);
• Datum - podatkovni tip datuma, predstavljen v znakovni različici, z dimenzijo 8 znakov (bajtov);
• Čas - podatkovni tip časa, predstavljen v obliki znakov, z dimenzijo 8 znakov (bajtov).

Pri podatkovnih vrstah s fiksno dimenzijo se stolpec »Dimenzija« običajno ne izpolni, kar pomeni, da je sama navedba podatkovne vrste že definirana in dodatna navedba ni potrebna. Za vse druge vrste podatkov je pomembno določiti največjo dimenzijo ob upoštevanju posebnosti vrednosti, ki so lahko prisotne v dokumentu. Za tipe številskih podatkov določite število bajtov, ki naj jih zavzame število, in število števk za decimalno vejico, kar določa natančnost realnega števila. Tipi znakovnih podatkov določajo število znakov, ki naj bodo shranjeni za ustrezni atribut. Vrsta znaka je lahko predstavljena na tri različne načine:

Besedilo, CLOB - besedilni podatkovni tip, ki predstavlja velike besedilne informacije, shranjene na poseben način, v tabeli podatkovne baze pa so prikazane kot niz prvih znakov, katerih število je dimenzija atributa tega tipa;

• - Znakovni - podatkovni tip niza, ki shrani točno toliko znakov, kot je določeno kot dimenzija, pri čemer se manjkajoči znaki na koncu niza zapolnijo s presledki;
• - Varchar - podatkovni tip niza spremenljive dolžine, za katerega dimenzija določa največje število znakov, ki jih lahko vsebuje shranjeni niz.

Tipa Character in Varchar sta si v bistvu zelo podobna, saj definirata vrsto nizovnih podatkov, vendar podrobnosti o predstavitvi podatkov določajo pogoje, pod katerimi se ta ali druga vrsta uporablja. Torej, za shranjevanje podatkov, ki imajo fiksno velikost (na primer TIN (identifikacijska številka davčnega zavezanca), BNK (bančna identifikacijska koda) banke, številka naročila, artikel izdelka itd.), se običajno uporablja vrsta znaka, saj tak podatki ne morejo obstajajo možnosti, ko se lahko število znakov razlikuje od tistih, navedenih v dimenziji atributa. Tip Varchar se uporablja v vseh drugih primerih, kjer ni treba shraniti natančnega števila znakov.

Model baze podatkov v katerem koli diagramu temelji na entitetah in odnosih, ki se nato pretvorijo v tabele in odnose baze podatkov. Entitete so ustvarjene, ko je ustvarjen diagram modela baze podatkov. Vizualna predstavitev modela je sestavni del zasnove baze podatkov, ker razvijalcu omogoča lažjo analizo nastajajočih netočnosti v modelu in model predstavi na način, ki je primeren za pregled stranke in drugih razvijalcev.

Za oblikovanje elementov diagrama se uporablja paleta elementov ("Paleta", slika 3.49), ki vsebuje območje "Podatki" s predmeti "Entity" (entiteta) in odnosi. Izbira elementa palete "Entity" bo uporabniku dala možnost, da ustvari objekt "Entity" v diagramu, za katerega bo moral uporabnik vnesti ime entitete.

Ustvarjanje entitet je možno izvesti tudi preko kontekstnega menija mape "Paket..." (paket...), kjer menijska točka "Dodaj podatkovni objekt/ Entiteto" (Dodaj nov objekt / Entiteto) ustvari entiteto v drevesu projekta in razvijalcu ponudite možnost, kot je prikazano na diagramu, vnesite ime subjekta (slika 3.50).

Prav tako je mogoče ustvariti entitete neposredno na diagramu z uporabo kontekstno občutljivega grafičnega menija. Če želite to narediti, premaknite kazalec miške na prazen prostor diagrama in ga nekaj časa ne premikajte, kar bo privedlo do pojava območja z ikonami, ki označujejo možnost ustvarjanja veljavnih elementov. Za model logične baze podatkov bo prikazana samo ena ikona, ki označuje, da je entiteto mogoče ustvariti. Če jo izberete, kot v prejšnjih primerih, bo ustvarjena nova entiteta s predlogom za vnos njenega imena.

V zavihku lastnosti entitete "Volumetries" (Meters) lahko razvijalec določi parametre za spreminjanje števila primerkov zadevne entitete (slika 3.51), vključno z:

• Začetno število vrstic (začetno število primerkov) - označuje količino podatkov (primerkov), ki jih je treba dodati takoj po izdelavi tabele;
• Rast vrstice na mesec (dodajanje primerkov na mesec) - označuje, koliko primerkov je treba dodati na mesec;
• Največje število vrstic – označuje največje število primerkov, ki jih je mogoče shraniti v tabeli, ki jo opisuje zadevna entiteta.

riž. "3.51. Nastavitev parametrov spremembe
kvantitativni kazalniki subjekta

V razdelku z lastnostmi entitete je med parametri zavihka »Splošno« (glavni) razvijalec povabljen, da nastavi dodatni parameter »Trajno« (stalno), ki določa možnost preoblikovanja entitete v tabelo pri prehodu iz logičen fizičnemu modelu baze podatkov. Toda vse informacije o strukturi bodoče baze podatkov so vgrajene v razmerja med entitetami in atributi, za katere je značilno veliko večje število parametrov. Z uporabo zavihka "Atributi" (atributi) lahko ustvarite atribute entitet in določite njihove glavne parametre.

Podobno kot pri ustvarjanju entitete, lahko tudi atribute ustvarite na različne načine (slika 3.52):

• - uporaba kontekstnega menija - uporablja se kontekstni meni entitete v projektnem drevesu, kjer je možno izbrati objekt za ustvarjanje - atribut, alternativni ključ, omejitev itd.;
• - z uporabo lastnosti entitete - področje lastnosti se uporablja v zavihku "Atributi" (atributi), kjer se s pomočjo tam razpoložljivih orodij kreirajo in določajo atributi;

z uporabo grafičnega menija diafragme - ob prehodu "miške" nad entiteto se uporablja grafični meni z ikonami, s pomočjo katerega se ustvari primarni ključ in enostavni atributi z možnostjo podajanja imena atributa.

slika 3.52. Primer ustvarjanja atributa
prek lastnosti entitete

Pri uporabi lastnosti entitete razvijalec v zavihku "Atributi" (atributi) z uporabo ikone z znakom "+" ustvari nove atribute, nato pa mora določiti glavne parametre ustvarjenega atributa:

• Ime (name) - ime atributa, ki določa smiselni pomen opisanih podatkov;
• Primarni ključ (primarni ključ) - znak, ki označuje, da je atribut element primarnega ključa in je zanj potrebno ustvariti ustrezne omejitve celovitosti;
• Nadomestni ključ (nadomestni ključ) - znak, ki označuje, da atribut ni element predmetnega področja, vendar je potreben za učinkovito delo z bazo podatkov in bo vseboval vrednosti, samodejno ustvarjene v skladu s pravili aritmetičnega napredovanja;
• Tip (tip) - podatkovni tip, ki opisuje vrednosti, ki jih predstavlja atribut;
• Dolžina / natančnost (velikost / natančnost) - številska vrednost, ki označuje število znakov (bajtov), ​​potrebnih za shranjevanje največje vrednosti za opisan atribut;
• Lestvica (lestvica) - številska vrednost, ki se uporablja za številske atribute, ki opisuje število znakov za decimalno vejico pri delu z realnimi števili;
• Zahtevano - znak nezmožnosti shranjevanja prazne vrednosti NULL po atributu;
• Izvedeno (izračunano) - znak potrebe po izračunu vrednosti z določenim izrazom z uporabo matematičnih, jezikovnih operacij in različnih funkcij jezika DBMS;
• Privzeta vrednost (privzeta vrednost) - vrednost, ki jo je treba zabeležiti, če pri dodajanju ali spreminjanju podatkov za atribut ni bila definirana;
• Izpeljava izraza (izračunani izraz) – izraz formule, ki ga je treba ovrednotiti pri dodajanju ali spreminjanju podatkov.

Pomembno je omeniti, da orodje omogoča razvrščanje atributov v entiteti v vrstnem redu, kot ga želi razvijalec. To se naredi s pomočjo kontrolnih ikon v obliki večsmernih puščic. Glede na to, da Coddova pravila določajo neodvisnost od vrstnega reda atributov, vrstni red ni nujen del modela baze podatkov. Obstajata dva razloga za ureditev potrebnega vrstnega reda atributov:

Enostavnost uporabe - pri urejanju vrstnega reda atributov po določenih pravilih (npr. najprej naj gredo atributi, ki označujejo primarni ključ, nato tuji ključi, nato alternativni ključ in enostavni atributi) je lažje brati diagram modela in identificirati nekatere težavne situacije, ki se lahko pojavijo pri praktičnem delu z bazo podatkov; uporaba posebnih tehnologij obdelave - pri dodajanju podatkov v jeziku SQL je možno, da seznama ne določite

tabele ničle, v katere se bodo vnašali v ukazu podani podatki, kar od razvijalca programske kode zahteva natančno poznavanje vrstnega reda polj v tabeli, ki se lahko določi na nivoju logičnega modela z razvrščanjem atributov.

Poleg nastavitvenih značilnosti za vsak atribut, vključno s podajanjem privzete vrednosti in izraza formule za izračun, ima lahko vsaka entiteta omejitve celovitosti, ki zagotavljajo, da je vrednost ustreznega atributa pravilno shranjena. Na primer, za atribut, ki shranjuje leta, bo morda treba omejiti najmanjšo vrednost. Ker na ravni izdelave logičnega modela razvijalec morda ne ve, kateri DBMS bo uporabljen za izvedbo, uporaba funkcij v katerem koli od programskih jezikov ne bo pravilna. Vendar pa orodje IBM InfoSphere Data Architect razvijalcu omogoča, da določi pogoj omejitve v več jezikih (slika 3.53):

• OCL (Object Constraint Language) - jezik objektnih omejitev, ki se uporablja v objektno usmerjeni predstavitvi podatkov in aplikacijskem programu, redko se uporablja pri izvajanju relacijskih baz podatkov, uporablja standardne logične izraze in sklicevanja na atribute entitet (na primer: Entity. Year>= 2000 ):
• SQL (Structured Query Language) je strukturiran poizvedovalni jezik, ki se uporablja pri obdelavi relacijskih baz podatkov, običajno je osredotočen na določen DBMS in ima številne funkcije, ki so edinstvene za izbrani DBMS, uporablja logične operacije (AND (AND), OR (ALI) , itd.) in jih uporabi na ravni atributa zadevne entitete (na primer: leto >= 2000 in leto
• Angleščina je naravni jezik, ki ga ni mogoče prevesti v programski jezik, običajno se uporablja za opis omejitve in jo nato predstavi v procesu programiranja z ustreznim logičnim izrazom (na primer: leto je predstavljeno z vrednostjo v območju )