Tabuľky s riadkami a stĺpcami ako základ relačnej databázy

U_NRA_NAMEA_PREISA_STUECKDATUMV_NAMEV_ANSCH

1	Košeľa	39,80	40	24.06.1999	Meyer, Emil	Wendeweg 10, 2 800 Brémy
2	kabát	360,00	10	24.06.1999	Meier, Franz	Kohlstrasse 1, 2 800 Brém
3	Košeľa	44,20	70	24.06.1999	Meyer, Emil	Wendeweg 10, 2 800 Brémy
4	Košeľa	44,20	20	25.06.1999	Schulze, Fritz	Gemüseweg 3, 2 800 Brémy
5	kabát	360,00	35	25.06.1999	Meier, Franz	Kohlstrasse 1, 2 800 Brém
6.	nohavice	110,50	35	24.06.1999	Meyer, Emil	Wendeweg 10, 2 800 Brémy
7.	nohavice	110,50	5	24.06.1999	Schulze, Fritz	Gemüseweg 3, 2 800 Brémy
8.	Košeľa	39,80	10	24.06.1999	Schulze, Fritz	Gemüseweg 3, 2 800 Brémy
9	Košeľa	44,20	20	25.06.1999	Meyer, Emil	Wendeweg 10, 2 800 Brémy

Zdá sa, že tento príklad je štruktúrovaný pomerne jasne, aby bolo možné takúto denormalizovanú tabuľku rýchlo rozdeliť na tri tabuľky. Ak sa však vezmú do úvahy súčasné denné ceny, vyvstáva otázka, či je cena uvedená v tabuľke výrobkov alebo v tabuľke predaja. Príklad 2:

lfNrDelivery noDate Článok (E) EP číslo dodávateľa Článok (V) Príjemca EP číslo

1	24	15. februára 2003	Nohavice, modré	FA Muster-Liefer GbR, Norimberg	39,90	50
2	24	15. februára 2003	Nohavice, hnedé	FA Muster-Liefer GbR, Norimberg	39,90	50
3	27	16. februára 2003					Nohavice	Max Müller, Berlín	49,90	10
4	28	17. februára 2003	Košele	FA Groß-Handel AG, Hamburg	18,40	30
5	28	17. februára 2003	Košele	FA Groß-Handel AG, Hamburg	18,40	40
6.	35	18. februára 2003					Košele	Lisa Mayer, Mníchov	23,90	5

Vlastnosti a nevýhody úplne denormalizovanej tabuľky

• Na jednej strane možno každú informáciu evidentne triediť do tabuľky, ktorá je štruktúrovaná týmto spôsobom a má veľký počet stĺpcov. Ak sa majú archivovať ďalšie informácie, postačí pridať ďalšie riadky a v prípade potreby ich nechať prázdne. Teoreticky by každá databáza mohla mať obsah s jedinou tabuľkou štruktúrovanou podľa tohto vzoru. V najextrémnejšom prípade by tabuľka obsahovala jeden veľký stĺpec textu, v ktorom by boli všetky informácie uvedené v poradí. Na druhej strane má táto forma vnútorného znázornenia zjavné nevýhody, o ktorých sa bude diskutovať nižšie.
• Nadbytočnosť týchto príkladov je zrejmá. V prvom príklade sú viackrát uvedené rovnaké údaje o adrese, aby došlo k zmene jeden Bolo by treba vyhľadať a prepísať adresu niekoľkých rovnakých buniek. V takom prípade sa hovorí o jednom Aktualizovať anomáliu. Potom by mohli existovať dvaja rôzni ľudia s rovnakým menom a priezviskom, aby hľadanie pred aktualizáciou našlo niekoľko adries a potom ich zmenilo. Jednoznační ľudia by mali byť jasne charakterizovateľní.
• Ak sa v príklade 2 hľadajú všetky nohavice, musí sa použiť zástupné vyhľadávanie, ktoré vyhľadá výraz „pants *“ alebo „* pants *“ a použije zástupný symbol „*“. Pretože bunka „Nákup: Položka“ obsahuje niekoľko informácií súčasne. Ak je zaujímavá iba časť informácií, nie je známe, kde sa nachádzajú (na začiatku alebo v strede bunky), takže hľadaný výraz musí byť doplnený zástupným znakom z oboch strán. Podobný problém existuje aj pri hľadaní miest. Pri hľadaní miesta by sa našla osoba, ktorá má slovo ako priezvisko a ktoré sa tiež zadáva ako miesto.
• Zdá sa, že takáto tabuľka obsahuje iba text. To znamená, že text je možné zadať aj do bunky s dátumom alebo ako bodku v informácii o cene možno použiť čiarku ako oddeľovač, takže hodnotu už pri aritmetických operáciách nemožno správne použiť.
• Príklad 2 v súčasnosti zahŕňa iba objednávky a dodávky. Ak by dodávka pre „Lisu Mayer“ bola vymazaná alebo zrušená, informácie o adrese by tiež zmizli, aj keď môžu byť stále nevyhnutné. Toto sa volá Odstrániť anomáliu menovaný. Alternatívou by bolo zadať „Lisa Mayer“ bez dodávky. To znamená, že polia, ktoré sú absolútne nevyhnutné pre doručenie, nesmú byť deklarované s NOT NULL, DBMS nemôže zabezpečiť konzistenciu vstupu. Na druhej strane, ak by bola objednávka povinná, išlo by o príklad jednej Vložte anomáliu. Aj pri prípustnosti osoby bez objednávky nie je jasné, či by sa údaje mali uvádzať v stĺpci „Dodávateľ“ alebo „Príjemca“. Nakoniec je možné si predstaviť, že spoločnosť je dodávateľom aj príjemcom, alebo že sa tovar posiela osobe zaregistrovanej ako zamestnanec.
• Ak spoločnosť „Muster-Liefer“ dodáva nohavice v rôznych farbách, tieto informácie možno ignorovať. To znemožňuje členenie údajov o nákupe a predaji podľa farby nohavíc. Ak sú tieto informácie tiež uložené, musia sa tiež znova zadať všetky údaje adresy, aby sa zvýšila pravdepodobnosť vstupných chýb. Nesprávne napísané „FI Muster-Liefer“ by viedlo k zmiznutiu tohto záznamu údajov pri textovom vyhľadávaní „FA Muster-Liefer *“.
• Dve dodávky dňa 02.15.2003 sa týkajú rôznych článkov. Na druhej strane tieto dve dodávky od 2. 2. 2003 by sa dali spojiť do jednej dodávky so 70 kusmi, pretože hodnoty buniek sú identické, s výnimkou stĺpca „Množstvo“, a je logické pridať k množstvu dve informácie.

Je zrejmé, že takýto dizajn prináša rôzne problémy a nesprávne hodnotenia. Na rozdiel od archívu v papierovej podobe by bolo možné prehľadávať iba text. Výsledky by však museli byť znova skontrolované ručne; každý nesprávny vstup je možné určiť iba kontrolou pôvodnej bunky. Z tohto dôvodu by takýto denormalizovaný dizajn zničil všetky výhody archivácie dát počítačom.

Nasledujúce stránky sa preto zaoberajú typickými databázovými technikami na rozdelenie takto denormalizovanej tabuľky na niekoľko menších tabuliek.

---