Image
17.5.2016 0 Comments

Databázy II / 6.časť

Späť na úvod >> Späť na seriál

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é?
- 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).
- Transakcie a zamykanie tabuliek na úrovni riadkov sú implicitnou súčasťou databázového stroja (systém InnoDB).
- 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).
- Úpravy na triedenie nemeckých jazykových sád
- Podpora autoinkrementácie ŕ la SYBASE (IDENTITY) a import databáz vrátane TRUNCATE TABLE (ako v Oracle).
- 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 zavisí 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 slú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á 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. Predstvame 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).

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:

  • 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.
  • Jeho hodnota nesmie byť prázdna (NULL) po celý čas existencie tabuľky.
  • 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 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é poč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čiek. Z teórie o vzťahoch 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ý.
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).

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:

  • identifikácia a modelovanie entít
  • identifikácia a modelovanie vzťahov medzi entitami
  • identifikácia a modelovanie atribútov
  • identifikácia a stanovenie identifikátorov (primárnych kľúčov) pre každú entitu
  • 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 tab. č. 8.

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 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ť:

  • stĺpec Vydavatel_ID do tabuľky CD
  • stĺpec CD_ID do tabuľky PESNICKA
  • stĺpec Umelec_ID do tabuľky PESNICKA

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 (tab. 9).

Ú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...

Zobrazit Galériu

Nechajte si posielať prehľad najdôležitejších správ emailom

Mohlo by Vás zaujímať

Ako na to

Ako funguje sandbox?

08.12.2016 15:36

Každá aplikácia môže pre operačný systém počítača či mobilného zariadenia predstavovať potenciálnu hrozbu, a to aj v prípade, ak neobsahuje žiadne bloky škodlivého kódu. Murphyho zákony neúprosne defi ...

Ako na to

Tipy a triky: Ako na snímku obrazovky na akomkoľvek počítači s Windows?

02.12.2016 00:13

Ak snímky obrazovky robíte často apotrebujete napríklad funkcie na posun stránok alebo snímanie zobrazenia pri vyššom rozlíšení displeja, zrejme používate nejakú špecializovanú aplikáciu. Väčšina použ ...

Ako na to 1

Tipy a triky: Ako aplikácii prednastaviť spúšťanie s administrátorskými právami?

30.11.2016 00:10

Väčšina aspoň trochu skúsenejších používateľov vie, že aj keď máte na operačnom systéme Windows vytvorený administrátorský účet, aplikácie pre bezpečnosť nefungujú vždy splnými administrátorskými práv ...

Žiadne komentáre

Vyhľadávanie

Kyocera - prve-zariadenia-formatu-a4-s-vykonom-a3

Najnovšie videá