Untitled - Vitajte na stránkach www.einsty.hostujem.sk

P R O G R A M U J E M E
druhej strane vz ahu. Takže ak sa dobre pozrieme na obr. è. 7, z ktorého pri implementácii
vychádzame, musíme vloži :
l ståpec Vydavatel_ID do tabu¾ky CD
l ståpec CD_ID do tabu¾ky PESNICKA
l ståpec Umelec_ID do tabu¾ky PESNICKA
Obr. 7
Ešte stále však nie sme v druhej normálnej forme. Preèo? Pretože atribút Vydavatel
je podobný problém ako atribút Kapela. Preto dekomponujeme atribút Vydavatel na samostatnú
entitu s jej parametrami, tak ako je to na obrázku è. 7. Koneène máme náš dátový
model v druhej normálnej forme.
TRETIA NORMÁLNA FORMA. O relácii hovoríme, že je v tretej normálnej
forme, ak je v druhej normálnej forme a zároveò všetky jej atribúty, ktoré netvoria primárny
k¾úè, sú od seba nezávislé. Keby existoval atribút, ktorý je závislý od iného atribútu,
musíme ho presunú do novej entity.
Ak sa pozrieme na náš dátový model a predpokladáme, že nás už bližšie nezaujímajú
ïalšie informácie o vydavate¾stve, môžeme poveda , že všetky atribúty v jednotlivých
entitách sú od seba navzájom nezávislé. (Ak by nás zaujímala aj presná adresa vydavate¾stva,
museli by sme v zmysle prvej normálnej formy rozpracova nové atribúty entity
VYDAVATEL, ako ulica, mesto, PSÈ a iné.) Takže môžeme poveda , že tento dátový model
spåòa túto podmienku a je v tretej normálnej forme.
Logická úroveò návrhu
Teraz máme kompletný logický návrh dátového modelu. Zhròme si zásady postupu:
l identifikácia a modelovanie entít
l identifikácia a modelovanie vz ahov medzi entitami
l identifikácia a modelovanie atribútov
l identifikácia a stanovenie identifikátorov (primárnych k¾úèov) pre každú entitu
l normalizácia
Dátový model, ktorý sme vytvorili, je skutoène jednoduchý. Zatia¾ je to všetko v teoretickej
rovine. Aby bol náš projekt aj funkèný, musíme pokroèi do implementaènej úrovne.
IMPLEMENTAÈNÁ ÚROVEÒ. Ako už vieme, v tejto úrovni pripravujeme dátový
model na konkrétne technické prostriedky. Po túto úroveò bola èinnos pre všetky
druhy serverov SQL rovnaká. Implementácia je vlastne preklad dátového modelu do konkrétneho
jazyka SQL. Teraz pristúpime na základe doterajších skúseností k implementácii
dátového modelu na server MySQL.
Aby sme sa nedopustili chýb, opíšme si základné pravidlá implementácie:
1. Entity sa stávajú tabu¾kami vo fyzickej databáze.
2. Atribúty sa stávajú ståpcami v tabu¾ke. Musíme zvoli príslušný dátový typ pre každý
ståpec.
3. Unikátne identifikátory sa stávajú primárnymi k¾úèmi v tabu¾ke.
4. Vz ahy sú modelované ako cudzie k¾úèe. (Objasníme neskôr.)
Ak budemem aplikova tieto pravidlá, dostaneme opis fyzickej databázy, ako je to v
tejto tabu¾ke:
Fyzická implementácia dátového modelu
Tabu¾ka Ståpec Dátový typ Poznámka
CD CD_ID INT primárny k¾úè
Nazov_CD
VARCHAR(50)
PESNICKA Piesen_ID INT primárny k¾úè
Nazov_Skladby VARCHAR(50)
Dlzka_Skladby
TIME
UMELEC Umelec_ID INT primárny k¾úè
Meno_Umelca
VARCHAR(50)
VYDAVATEL Vydavatel_ID INT primárny k¾úè
Nazov_Vydavatela VARCHAR(50)
V tabu¾ke è. 8 sú definované kroky 1 až 3 implementácie. Všimnime si, že sme primárne
k¾úèe deklarovali ako INT – my už vieme preèo. Ståpec Dlzka_Skladby bude uchováva
èasové informácie o dåžke každej skladby. Aj keï nepredpokladáme, že by sme niekedy
pracovali s týmto èasovým údajom, predsa sme ho deklarovali ako dátový typ TIME.
Ale spokojne sme ho mohli deklarova aj typu VARCHAR. Ostatné ståpce sme deklarovali
typu VARCHAR s maximálnou dåžkou 50 znakov, èo by mohlo vyhovova .
Ešte sme neimplementovali vz ahy. Tie sa definujú ako pridanie cudzích k¾úèov do
tabu¾ky, ku ktorej vz ah smeruje. Cudzí k¾úè – foreign key – je primárny k¾úè tabu¾ky na
Jednoducho povedané, kópiu primárneho k¾úèa každej tabu¾ky presunieme v smere
„vidlièky vz ahu“ do druhej tabu¾ky. Takto vytvoríme úplnú implementáciu dátového modelu:
Úplná implementácia dátového modelu
Tabu¾ka Ståpec Dátový typ Poznámka
CD CD_ID INT primárny k¾úè
Nazov_CD
VARCHAR(50)
Vydavatel_ID INT cudzí k¾úè
PESNICKA Piesen_ID INT primárny k¾úè
Nazov_Skladby VARCHAR(50)
Dlzka_Skladby TIME
CD_ID INT cudzí k¾úè
Umelec_ID INT cudzí k¾úè
UMELEC Umelec_ID INT primárny k¾úè
Meno_Umelca VARCHAR(50)
VYDAVATEL Vydavatel_ID INT primárny k¾úè
Nazov_Vydavatela VARCHAR(50)
Teraz máme kompletnú schému fyzickej databázy. Aby to bolo úplné, pomenujme
túto databázu ARCHIV.
Nakoniec zostáva už len napísa skript v jazyku SQL, ktorý zabezpeèí vytvorenie databázy
ARCHIV s príslušnými tabu¾kami na serveri MySQL (výpis è. 10).
Create Table CD (CD_ID INT NOT NULL,
NAZOV_CD VARCHAR(50),
VYDAVATEL_ID INT,
Primary Key (CD_ID));
Create Table PESNICKA PIESEN_ID INT NOT NULL,
NAZOV_SKLADBY VARCHAR(50),
DLZKA_SKLADBYC
CD_ID INT,
UMELEC_ID INT,
Primary Key (PIESEN_ID));
Create Table UMELEC (UMELEC_ID INT NOT NULL,
MENO_UMELCA VARCHAR(50),
Primary Key (UMELEC_ID));
Create Table VYDAVATEL (VYDAVATEL_ID INT NOT NULL,
NAZOV_VYDAVATELA VARCHAR(50),
Primary Key (VYDAVATEL_ID));
Samozrejme, nesmieme zabudnú najprv vytvori databázu ARCHIV, napríklad cez
program mysqladmin.
OSTATNÉ NORMÁLNE FORMY. Aby nás nezaskoèila informácia, že existujú
aj iné normálne formy, tak si ich iba spomenieme. Za tre ou normálnou formou nasleduje
tzv. Boyce/Coddova normálna forma. Je to urèitá variácia tretej formy. Používa sa
iba pri reláciách s viacerými kandidátnymi k¾úèmi.
Ešte existuje štvrtá normálna forma, ktorej základom je zákaz spojovania nezávislej
opakovanej skupiny, a koneène piata normálna forma, ktorá sa týka tzv. spojenej závislosti.
Ale to už je vysoká škola teórie databáz a v praxi vystaèíme s prvými tromi normálnymi
formami.
Sme na konci s teoretickým výkladom, aby som vás dlhšie nenudil. Prosím, vezmite si
túto teóriu k srdcu a vyhnete sa zbytoèným problémom. Tí, èo si myslia, že sú to len zbytoèné
blbosti (aj ja som bol taký!!!), mi dajú za pravdu neskôr.
Teraz už len zostáva navrhnú správne technologické okolie, aby sme nemuseli núti
našu kamarátku pracova v príkazovom riadku, a takto sa vraciame od teórie k praxi – k
navrhovaniu pekného oknoidného prostredia.
Nabudúce budeme pokraèova tam, kde sme pred týmto intermezzom skonèili.
Ukážeme si, ako dostaneme údaje z databázy na serveri SQL napr. do Excelu. Že to nejde?
Veï uvidíme...
Miroslav Oravec
152 PC REVUE 12/2001