AD Blog

Určitě jste si všimli jedné nepříjemnosti: pokud máte vizitky od více zaměstnanců od jedné firmy, musíte stále znova a znova opisovat jméno a adresu firmy. A při tom děláte chyby. Možná by bylo lepší mít jméno firmy a adresu jako kombo box (rozbalovací nabídku).

To je skutečně dobrá myšlenka!

Samozřejmě napadla už někoho před námi (konkrétně to byl pan E.F.Codd teoretický matematik a nápad pochází z roku 1970, takže nic nového pod sluncem) a nazval proces „optimalizace datové základny“ normalizací. O co jde?

Počátečním bodem je nenormalizovaný soubor dat, který máme uvedený pod kódem vizitky (3). O něm můžeme prohlásit, že se nachází v normální formě 0.

Poznámka: o modelu vizitky (0) můžeme s humorem sobě vlastním prohlásit že se nachází v normální formě –1. Nepsal bych tady o tom, ale viděl jsem hodně, i profesionálních aplikací, které tuto náročnou specifikaci plně splňovali :-)).

Nejprve se podíváme na tabulku vizitky z hlediska prvního a druhého typu normalizace.

Definice:

První typ normalizace eliminuje periodické vstupy a umísťuje je do nových tabulek.

Druhý typ normalizace eliminuje nadbytečná data ze souborů do nových tabulek.

Třetí typ normalizace eliminuje nesouvisející data do nových tabulek.

Když se podíváme do naší tabulky vidíme hned horkého kandidáta na přesunutí do další tabulky: firma a její adresa, titul a pozice ve firmě. Takže vytvoříme nové tabulky firma, titul, pozice a upravíme tabulku vizitky (3):

firma (1)

• id INTEGER PRIMARY KEY
• firma VARCHAR (40)
• obec VARCHAR (30)
• psc VARCHAR (5)
• ulice VARCHAR (40)
• cislo_popisne VARCHAR (5)
• web VARCHAR (40)

titul (1)

• id INTEGER PRIMARY KEY
• titul VARCHAR (10)

pozice (1)

• id INTEGER PRIMARY KEY
• pozice VARCHAR (15)

vizitky (4)

• id INTEGER PRIMARY KEY
• jmeno VARCHAR (25)
• príjmení VARCHAR (25)
• titul_id INTEGER
• pozice_id INTEGER)
• firma_id INTEGER
• telefon VARCHAR (13)
• mobil VARCHAR (13)
• fax VARCHAR (13)
• email VARCHAR (25)
• poznamka TEXT

Při pohledu na tabulku firma (1) z hlediska druhého typu normalizace, vidíme dalšího kandidáta na eliminaci nadbytečně se vyskytujících dat: pole obec, upravme tedy tabulku firma (1):

firma (2)

• id INTEGER PRIMARY KEY
• firma VARCHAR (40)
• obec_id INTEGER (30)
• ulice VARCHAR (40)
• cislo_popisne VARCHAR (5)

obec (1)

• id INTEGER PRIMARY KEY
• obec VARCHAR (30)
• psc VARCHAR (5)

Vznikly tedy 4 nové tabulky, které můžeme nazývat číselníky.

Ještě bych se pozastavil u názvů polí v tabulkách. Neexistuje (nebo alespoň nevím) obecně přijímaná norma pro pojmenování polí v tabulkách. Je pravdou, že pokusy byly (Polská notace), ale nemám zprávy, že by se obecně ujaly. Je tedy na autorovy návrhu, jakým způsobem pole v tabulce pojmenuje. Já používám následující pravidla a dávám pt. čtenářstvu na zvážení, zda se budou řídit něčím podobným: pole nazývám českým významovým slovem bez diakritiky a místo pomlčky používám znak „_“ (podtržítko) primární klíč tabulky je vždy „id“, cizí klíče v tabulce jsou nazvány podle názvu podřízené tabulky se sufixem „_id“

Výsledek našeho snažení je vidět na následujícím obrázku:

Obrázek je vytvořen v case nástroji CASE studio 2

SQL skript pro vytvoření tabulek v prostředí MySQL:

Create table firma (

id int NOT NULL,

firma Varchar(40),

obec_id Int,

ulice Varchar(40),

cislo_popisne Varchar(5),

web Varchar(20),

UNIQUE (id)) ENGINE = InnoDB;

Create table titul (

id Int NOT NULL,

titul Varchar(20),

UNIQUE (id)) ENGINE = InnoDB;

Create table pozice (

id Int NOT NULL,

pozice Varchar(15),

UNIQUE (id)) ENGINE = InnoDB;

Create table obec (

id Int NOT NULL,

obec Varchar(30),

psc Varchar(5),

UNIQUE (id)) ENGINE = InnoDB;

Create table vizitky (

id Int NOT NULL,

jmeno Varchar(25),

prijmeni Varchar(25),

titul_id Int,

pozice_id Int,

firma_id Int,

telefon Varchar(13),

mobil Varchar(13),

fax Varchar(13),

email Varchar(25),

poznamka Text,

UNIQUE (id)) ENGINE = InnoDB;

Příště si nastavíme relace mezi tabulkami a nadefinujeme indexy.