Untitled - Vitajte na strÃ¡nkach www.einsty.hostujem.sk

More documents

Recommendations

Info

P R O G R A M U J E M E Malé ve¾ké databázy II. / 6. èas Dobrá správa! Práve vyšla MySQL verzia 4.0!!! Teda zatia¾ iba v alfa release, preto treba s ostrým nasadením ešte poèka . A èo je v nej nové? l Optimalizácia MYSQL kódu prináša zvýšenie rýchlosti hlavne v oblasti: viacnásobné Inserty, vyh¾adávanie, vytváranie fulltextových indexov, ako aj COUNT(DISTINCT) l Transakcie a zamykanie tabuliek na úrovni riadkov sú implicitnou súèas ou databázového stroja (systém InnoDB) l MySQL podporuje zabezpeèenú komunikáciu medzi klientom a serverom na úrovni protokolu SSL, èo znamená možnos umiestni DBS server aj mimo zabezpeèenej zóny (napríklad geograficky pred firewall) l Úpravy na triedenie nemeckých jazykových sád l Podpora autoinkrementácie `a la SYBASE (IDENTITY) a import databáz vrátane TRUNCA- TE TABLE (ako v Oracle) l Podpora Unionov (spojenie viacerých Selectov) Zároveò autori oznamujú, že sa pripravuje verzia 4.1, ktorá bude obsahova aj subselekty, uložené procedúry a ïalšie zlepšenia. Túto verziu môžeme oèakáva až zaèiatkom budúceho roka. Vrá me sa k našej teórii. ZOPAKOVANIE. Vieme, èo je entita, doména a relácia. Vieme, že každá relácia obsahuje entitu, ktorá má konkrétne atribúty. Poznáme aj vz ahy medzi entitami, ich kardinalitu a parcialitu, vieme ich prípadne dekomponova . Dokážeme nakresli E – R diagram, z ktorého vytvoríme relaènú schému. Nakoniec definujeme tabu¾ky a príkazy SQL na prácu s nimi. Tentoraz si povieme nieèo o funkènej závislosti a vysvetlíme si normalizáciu relácií. FUNKÈNÁ ZÁVISLOS . Aby sme sa vyhli zložitej matematike, iba povieme, že funkèná závislos je tvrdenie o reálnom svete. Napríklad plat zamestnanca závisí od toho, akú funkciu vykonáva, teda plat závisí od funkcie, zapisujeme FUNKCIA – PLAT. Druhým príkladom je cena cestovného, ktorá závisí od dåžky precestovanej trasy, teda DÅŽKA_TRASY – CENA_CESTOVNÉHO. Podobných príkladov by sme našli v reálnom živote nieko¾ko. ŠTUDIJNÝ PRÍKLAD. V predošlej èasti sme si povedali nieèo o troch úrovniach návrhu – konceptuálnej, logickej a implementaènej. Aby sme si to trochu objasnili a doplnili o nové znalosti prakticky, vytvoríme si tento študijný príklad: V nemenovanej štátnej inštitúcii je archív hudobných cédeèiek. Sleèna referentka (ktorá je naša kamarátka, lebo je ve¾mi fajn) sa v tom už nevyzná, a tak sme jej s¾úbili, že pre òu vytvoríme program, ktorý jej bude tieto cédeèká evidova . Keïže sa iba archivujú a sú iba po jednom kuse z každého, nie je potrebné rieši výpožièky, náklady ani niè podobné. Na prvý poh¾ad sa zdá táto úloha ve¾mi triviálna. Ale pozrime sa na to postupne. KONCEPTUÁLNA ÚROVEÒ. No, entitu by sme mali. Pomenujeme ju CD. A èo budeme o nej evidova ? Hádam názov, meno kapely, názov vydavate¾a a zoznam pesnièiek. Takže vytvoríme reláciu s požadovanými atribútmi, tak ako je to na obr. 1. Táto relaèná schéma je jednoduchá, však? Ale ešte sme neskonèili. V skutoènosti sme iba na zaèiatku. Máme síce pekný diagram pre náš projekt, ale cítime, že to ešte nie je to pravé orechové. Nastal èas zaobera sa normalizáciou. NORMÁLNE FORMY. Normalizácia je èinnos , ktorá Obr. 1 vedie k dobre navrhnutým tabu¾kám. Princípy normalizácie definoval už E. F. Codd a nie je to suchá teória. Boli overené praxou a za tie dlhé roky tvorby databázových aplikácií sa vypracovali urèité postupy tvorby tabuliek, ktoré sa nazývajú normálne formy. Najèastejšie sa používajú prvé tri normálne formy, ale existujú aj ïalšie, ako si spomenieme neskôr. Vrá me sa k nášmu príkladu a pokraèujme cestou normalizácie. (Pre tých skôr narodených: Prosím neasociova so 70. rokmi!) PRVÁ NORMÁLNA FORMA (1NF). O relácii (tabu¾ka) hovoríme, že je v prvej normálnej forme, ak sú všetky jej atribúty atomické, t. j. ïalej nedelite¾né. Inými slovami, každý atribút relácie môže ma iba jednu hodnotu, teda nemôže by jeho hodnotou ïalšia relácia. Pozrime sa ešte raz na našu tabu¾ku. Vidíme, že nespåòa ani prvú normálnu formu, lebo atribút Pesnièky nedosahuje iba jednu hodnotu, ale môže ich ma viac – pod¾a poètu skladieb na konkrétnom cédeèku. Predstavme si, že by naša kamarátka zrazu potrebovala zisti , na ktorom disku sa nachádza urèitá skladba. Keby sme ponechali tabu¾ku v tejto forme, mali by sme pri tvorbe selektu, ktorý by vyh¾adal konkrétnu skladbu, asi znaèné problémy. Tušíme, že atribút Pesnièky obsahuje ïalšie atribúty, ako názov alebo dåžka skladby. To znamená, že by to mohla by samostatná entita s týmito dvoma atribútmi. Preto vykonáme rozloženie na dve samostatné entity, ktoré budú tvori dve samostatné tabu¾ky (obr. è. 2). Obr. 2 Teraz sú Nazov_Skladby a Dlzka_Skladby atribúty entity PESNICKA, takže dátový model je v prvej normálnej forme (1NF). Naneš astie ešte nemáme opísané vz ahy medzi oboma entitami. Na to potrebujeme zadefinova akýsi unikátny identifikátor. UNIKÁTNY IDENTIFIKÁTOR. Každá entita potrebuje ma svoj identifikátor. Môžeme ho nazva aj ID. Bude to nový atribút entity, ktorý bude ma tieto vlastnosti: l Bude unikátny v celej tabu¾ke, opisujúcej danú entitu. To znamená, že sa v celej tabu¾ke nenájdu dva riadky, ktoré by mali rovnakú hodnotu tohto atribútu. l Jeho hodnota nesmie by prázdna (NULL) po celý èas existencie tabu¾ky. l Už raz zadaná hodnota tohto identifikátora sa nesmie v danom riadku tabu¾ky nikdy zmeni po dobu existencie tabu¾ky. My už v podstate tento identifikátor poznáme. Je ním nám dobre známy primárny k¾úè. Vra me sa k zaèiatkom seriálu a zopakujme si jeho podstatu. Základom úspechu je správne zvoli primárny k¾úè. Zaèiatoèníci robia èasto chybu v tom, že za Obr. 3 primárny k¾úè vyberú napr. priezvisko. My však vieme, že existujú ¾udia, ktorí majú rovnaké priezvisko. Existuje pravidlo, ktoré hovorí, že primárny k¾úè by mal by èo najmenší. Preto je ve¾mi vhodné zvoli ako primárny k¾úè èíslo. Primárny k¾úè môže by zložený aj z viacerých atribútov – to závisí od konkrétnej aplikácie. Upravíme diagramy tak, že do každej entity vložíme identifikátor, ktorý bude primárnym k¾úèom tabu¾ky (obr. è. 3). Primárne k¾úèe budeme oznaèova s príponou ID a v diagrame budú zvýraznené podèiarknutím. Aby bola schéma úplná, musíme nadefinova relaèné vz ahy. Ak to chceme vyjadri slovne, môžeme poveda , že na jednom cédeèku môže by jedna alebo viac pesni- Obr. 4 èiek. Z teórie o vz a- hoch je zrejmé, že v našom prípade ide o vz ah 1: n. Tento vz ah zakreslíme pomocou vidlièky, tak ako je to na obr. è. 4. Prvá normálna forma je kompletná. DRUHÁ NORMÁLNA FORMA (2NF). Tabu¾ka je v druhej normálnej forme, ak je v prvej normálnej forme a navyše každý atribút, ktorý nie je primárnym k¾úèom, je od primárneho k¾úèa úplne závislý. Obr. 5 Obr. 6 Pozrime sa na náš dátový model. V tabu¾ke CD je atribút Kapela, ktorý urèite nie je závislý od primárneho k¾úèa CD_ID, lebo sa môže nachádza na rôznych diskoch. Èo vlastne atribút Kapela opisuje? Opisuje hudobnú skupinu alebo všeobecnejšie umelca. A umelec je už samostatná entita so svojimi atribútmi. Preto vykonáme znova dekompozíciu schémy, kde vyjmeme atribút Kapela a nahradíme ho novou entitou s atribútmi Umelec_ID ako primárnym k¾úèom a Meno_Umelca ako ïalším atribútom (obr. è. 5). Aké budú vz ahy medzi entitami CD, PESNICKA a UMELEC? Pre jednoduchos predpokladajme, že jeden umelec môže naspieva viac pesnièiek, ale každá pesnièka je naspievaná iba jedným umelcom. V takom prípade ide o vz ah 1: n, ktorý zadefinujeme „vidlièkou“ (obr. è. 6). 12/2001 PC REVUE 151
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
Page 2 and 3:
E D I T O R I A L Na konci každéh
Page 4 and 5:
N O V I N K Y www.itnews.sk Výber
Page 6 and 7:
N O V I N K Y STV 2: premiéra - 17
Page 8 and 9:
Bude založený na technológiách
Page 10 and 11:
poskytne tabu¾ka è. 1. Z nej celk
Page 12 and 13:
R E V U E Výrobca Canon Canon Epso
Page 14 and 15:
R E V U E u PCR: Preèo nie je tát
Page 16 and 17:
R E V U E AthlonXP pod lupou PETER
Page 18 and 19:
R E V U E Aplikaèné testy Sysmark
Page 20 and 21:
R E V U E Windows XP Nový operaèn
Page 22 and 23:
R E V U E systému Windows 95 sa zv
Page 24 and 25:
R E V U E taèov, bežne sa zaèín
Page 26 and 27:
R E V U E ne vyriešili inými pros
Page 28 and 29:
R E V U E pri svojich pokusoch èer
Page 31 and 32:
H A R D W A R E TESTOVALI SME: FARE
Page 33 and 34:
H A R D W A R E tenciál voèi tone
Page 35 and 36:
H A R D W A R E de o malú sumu a z
Page 37 and 38:
H A R D W A R E Tab. 2 Namerané a
Page 39 and 40:
H A R D W A R E OKI C7400 NAJPPEPRA
Page 41 and 42:
H A R D W A R E Siemens ME45 Hoci f
Page 43 and 44:
Pretec CompactGPS Jednou z ve¾mi a
Page 45 and 46:
H A R D W A R E Na displeji môžet
Page 47 and 48:
H A R D W A R E Plextor PX-S88TU Ak
Page 49 and 50:
H A R D W A R E Olympus Camedia C-4
Page 51 and 52:
H A R D W A R E Sony Cyber-Shot DSC
Page 53 and 54:
H A R D W A R E Externý modul pôs
Page 55 and 56:
H A R D W A R E ScanMaker 3800 a 48
Page 57 and 58:
S O F T W A R E ké zberate¾ské h
Page 59 and 60:
Partition Magic 7.0 Ak ste niekedy
Page 61 and 62:
S O F T W A R E Jednoduché úètov
Page 63 and 64:
S O F T W A R E TESTOVALI SME: PROG
Page 65 and 66:
S O F T W A R E n FINEREADER 5.0 PR
Page 67 and 68:
S O F T W A R E šiestich stupòov
Page 69 and 70:
S O F T W A R E „Gavarite pa rusk
Page 71 and 72: S O F T W A R E ANASIL v2.2 Opis: p
Page 73 and 74: S O F T W A R E Vlastnosti: n prehr
Page 75 and 76: S O F T W A R E napriek svojej jedn
Page 77 and 78: S O F T W A R E HomePlanet 3.1 n Hv
Page 79 and 80: S O F T W A R E FreshDiagnose n Aby
Page 81 and 82: S O F T W A R E Samba / 10. èas Na
Page 83 and 84: S O F T W A R E DAV - jednoduchšia
Page 85 and 86: S O F T W A R E uložia absolútnu
Page 87 and 88: S O F T W A R E COMMON CONTROLS Tab
Page 89 and 90: I N F O W A R E u Nová generácia
Page 91 and 92: I N F O W A R E u Optické vlákna
Page 93 and 94: I N F O W A R E SERVERY NA POŽIADA
Page 95 and 96: I N F O W A R E vého skladu urèen
Page 97 and 98: I N F O W A R E ktorá sa dodáva z
Page 99 and 100: I N F O W A R E Obr. 2 Integrované
Page 101 and 102: I N T E R N E T Vytvárame WWW str
Page 103 and 104: I N T E R N E T NA POTULKÁCH S V E
Page 105 and 106: S E R V I S Vírusový radar Mnohí
Page 107 and 108: M E D I A C L U B - C D - R O M FIF
Page 109 and 110: S E R V I S Tipy a triky pre Window
Page 111 and 112: S E R V I S recenzia: DIVOKÉ KOÈK
Page 113 and 114: P R O G R A M U J E M E procedure T
Page 115 and 116: P R O G R A M U J E M E Assembler p
Page 117 and 118: P R O G R A M U J E M E { } LPTSTR
Page 119 and 120: P R O G R A M U J E M E Udalosti s
Page 121: P R O G R A M U J E M E K overen
Page 125: Šéfredaktor: Martin Drobný (mdro
show all

Untitled - Vitajte na strÃ¡nkach www.einsty.hostujem.sk

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?