Táblázatok sorokkal és oszlopokkal, mint egy relációs adatbázis alapja

U_NRA_NAMEA_PREISA_STUECKDATUMV_NAMEV_ANSCH

1	Ing	39.80	40	1999.06.24	Meyer, Emil	Wendeweg 10, 2800 Bréma
2	kabát	360.00	10.	1999.06.24	Meier, Franz	Kohlstrasse 1, 2800 Bremen
3	Ing	44.20	70	1999.06.24	Meyer, Emil	Wendeweg 10, 2800 Bréma
4	Ing	44.20	20	1999.06.25	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
5.	kabát	360.00	35	1999.06.25	Meier, Franz	Kohlstrasse 1, 2800 Bremen
6.	nadrág	110,50	35	1999.06.24	Meyer, Emil	Wendeweg 10, 2800 Bréma
7.	nadrág	110,50	5.	1999.06.24	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
8.	Ing	39.80	10.	1999.06.24	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
9.	Ing	44.20	20	1999.06.25	Meyer, Emil	Wendeweg 10, 2800 Bréma

Úgy tűnik, hogy ez a példa viszonylag egyértelműen van felépítve, így az ilyen denormalizált táblázatot gyorsan három táblára lehet bontani. Ha azonban az aktuális napi árakat vesszük figyelembe, felmerül a kérdés, hogy az ár szerepel-e a cikk- vagy az értékesítési táblázatban. 2. példa:

lfNrDelivery-NrDate cikk (E) Szállítói EP-szám Cikkszám (V) Címzett EP-száma

1	24.	2003. február 15	Nadrág, kék	FA Muster-Liefer GbR, Nürnberg	39.90	50
2	24.	2003. február 15	Nadrág, barna	FA Muster-Liefer GbR, Nürnberg	39.90	50
3	27.	2003. február 16					Nadrág	Max Müller, Berlin	49.90	10.
4	28.	2003. február 17	Ingek	FA Groß-Handel AG, Hamburg	18.40	30-án
5.	28.	2003. február 17	Ingek	FA Groß-Handel AG, Hamburg	18.40	40
6.	35	2003. február 18					Ingek	Lisa Mayer, München	23.90	5.

A teljesen denormalizált asztal jellemzői és hátrányai

Egyrészt nyilvánvalóan minden információ egy ilyen módon felépített, sok oszlopot tartalmazó táblába rendezhető. Ha további információk archiválására van szükség, elegendő további sorokat felvenni, és ha szükséges, üresen hagyni. Elméletileg bármely adatbázis megelégedhet egyetlen táblával, amely e minta szerint strukturálódik. A legszélsőségesebb esetben a táblázat egyetlen nagy szövegoszlopot tartalmazna, amelyben az összes információ sorrendben szerepelne. Másrészt a belső képviselet ezen formájának nyilvánvaló hátrányai vannak, amelyeket az alábbiakban tárgyalunk.
E példák redundanciája nyilvánvaló. Az első példában ugyanazokat a címadatokat többször felsoroljuk, így ha változás történik egy Több azonos cellát kell megcímezni és át kell írni. Ilyen esetben az egyik beszél Anomália frissítése. Ezután két különböző személy lehet ugyanazzal az utó- és vezetéknévvel, hogy a frissítést megelőző keresés több címet találjon, majd megváltoztassa őket. Az egyértelmű embereknek egyértelműen jellemezhetőnek kell lenniük.
Ha az összes nadrágot a 2. példában keresik, akkor helyőrző keresést kell használni, amely a „Pants *” vagy „* Pants *” kifejezésre keres, és a „*” -t helyőrzőként használja. Mivel a 'Beszerzés: Tétel' cella egyszerre több információt tartalmaz. Ha csak az információ egy része érdekel, akkor nem ismert, hogy hol van (a cella elején vagy közepén), ezért a keresendő kifejezést mindkét oldal helyettesítőjének ki kell egészítenie. Hasonló probléma áll fenn a helyek keresésekor is. Az a személy, akinek vezetéknévként van szó, amelyet helyként is megadnak, megtalálható a hely keresésekor.
Úgy tűnik, hogy egy ilyen táblázat csak szöveget tartalmaz. Ez azt jelenti, hogy a dátum cellába szöveget is be lehet írni, vagy vesszőt lehet használni elválasztóként az árinformáció pontja helyett, így az érték már nem használható helyesen aritmetikai műveleteknél.
A 2. példa jelenleg csak megrendeléseket és szállításokat tartalmaz. Ha a „Lisa Mayer” részére történő kézbesítést törölnék vagy törölnék, a cím adatai is eltűnnek, bár szükség lehet rájuk. Ezt nevezik Törölje a rendellenességet nevezett. Alternatív megoldás lehet a „Lisa Mayer” beírása kézbesítés nélkül. Ez azt jelenti, hogy a szállításhoz feltétlenül szükséges mezőket nem szabad NULL értékkel deklarálni, a DBMS nem tudja biztosítani a bemenet konzisztenciáját. Másrészt, ha egy megrendelés kötelező lenne, akkor ez egy példa erre Helyezze be a rendellenességet. A megrendelés nélküli személy elfogadhatósága ellenére sem világos, hogy az adatokat a „szállító” vagy a „címzett” oszlopba kell-e beírni. Végül elképzelhető az az eset, hogy a vállalat egyszerre szállító és címzett, vagy az árukat elküldik egy alkalmazottként bejegyzett személynek.
Ha a Muster-Liefer cég különböző színű nadrágokat szállít, ezeket az információkat figyelmen kívül lehet hagyni. Ez lehetetlenné teszi a vásárlási és eladási adatok bontását a nadrág színe szerint. Ha ezeket az információkat is tárolják, akkor az összes címadatot is újra meg kell adni, így nő a beviteli hibák valószínűsége. A „FI Muster-Liefer” hibás írásakor a „FA Muster-Liefer *” szöveges keresés eltűnik ebben az adatrekordban.
A 2003. április 2-i két szállítás különböző cikkekre vonatkozik. A 2003. február 17-től érkező két kézbesítést viszont össze lehet egy 70 darabos szállítással, mivel a cellaértékek megegyeznek, kivéve a „Mennyiség” oszlopot, és célszerű két információt adni a mennyiséghez.

Nyilvánvaló, hogy egy ilyen kialakítás különféle problémákat és helytelen értékeléseket eredményez. Bármely papír formátumú archívummal ellentétben tiszta szöveg keresése lehetséges. Az eredményeket azonban újra kézzel kellene ellenőrizni, minden téves bejegyzést csak az eredeti cella ellenőrzésével lehet meghatározni. Emiatt egy ilyen denormalizált tervezés megsemmisítené a számítógéppel támogatott adatarchiválás összes előnyét.

A következő oldalak tehát egy tipikus adatbázis-technikákkal foglalkoznak egy ilyen denormalizált tábla több kisebb táblára bontására.