Tabelele cu rânduri și coloane ca bază a unei baze de date relaționale

U_NRA_NAMEA_PREISA_STUECKDATUMV_NAMEV_ANSCH

1	Cămaşă	39,80	40	24.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen
2	palton	360,00	10	24.06.1999	Meier, Franz	Kohlstrasse 1, 2800 Bremen
3	Cămaşă	44,20	70	24.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen
Al 4-lea	Cămaşă	44,20	20	25.06.1999	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
5	palton	360,00	35	25.06.1999	Meier, Franz	Kohlstrasse 1, 2800 Bremen
Al 6-lea	pantaloni	110,50	35	24.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen
Al 7-lea	pantaloni	110,50	5	24.06.1999	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
A 8-a	Cămaşă	39,80	10	24.06.1999	Schulze, Fritz	Gemüseweg 3, 2800 Bremen
9	Cămaşă	44,20	20	25.06.1999	Meyer, Emil	Wendeweg 10, 2800 Bremen

Acest exemplu pare a fi structurat destul de clar, astfel încât s-ar putea rupe rapid o astfel de masă denormalizată în trei tabele. Cu toate acestea, dacă se iau în considerare prețurile zilnice curente, se pune întrebarea dacă prețul este introdus în tabelul articolelor sau în tabelul de vânzări. Exemplul 2:

lfNrDelivery noDate Articolul (E) Furnizorul numărul EP Articolul (V) Destinatarul numărul EP

1	24	15 februarie 2003	Pantaloni, albastru	FA Muster-Liefer GbR, Nürnberg	39,90	50
2	24	15 februarie 2003	Pantaloni, maro	FA Muster-Liefer GbR, Nürnberg	39,90	50
3	27	16 februarie 2003					Pantaloni	Max Müller, Berlin	49,90	10
Al 4-lea	28	17 februarie 2003	Cămăși	FA Groß-Handel AG, Hamburg	18.40	30
5	28	17 februarie 2003	Cămăși	FA Groß-Handel AG, Hamburg	18.40	40
Al 6-lea	35	18 februarie 2003					Cămăși	Lisa Mayer, München	23,90	5

Caracteristici și dezavantaje ale unei mese complet denormalizate

• Pe de o parte, fiecare informație poate fi evident sortată într-un tabel care este structurat în acest fel și are un număr mare de coloane. Dacă trebuie arhivate informații suplimentare, este suficient să adăugați alte linii și, dacă este necesar, să le lăsați goale. În teorie, orice bază de date ar putea fi conținută cu un singur tabel structurat în funcție de acest model. În cel mai extrem caz, tabelul ar conține o singură coloană mare de text în care toate informațiile ar fi listate în ordine. Pe de altă parte, această formă de reprezentare internă are dezavantaje evidente, care vor fi discutate mai jos.
• Redundanța acestor exemple este evidentă. În primul exemplu, aceleași date de adresă sunt listate de mai multe ori, astfel încât dacă există o modificare unu Adresa mai multor celule identice ar trebui căutată și rescrisă. Într-un astfel de caz se vorbește despre unul Actualizați anomalia. Apoi ar putea exista două persoane diferite cu același nume și prenume, astfel încât căutarea înainte de actualizare să găsească mai multe adrese și apoi să le schimbe. Oamenii fără echivoc ar trebui să fie în mod clar caracterizabili.
• Dacă toate căutările sunt căutate în exemplul 2, trebuie utilizată o căutare a substituentului care caută „Pantaloni *” sau „* Pantaloni *” și utilizează „*” ca substituent. Deoarece celula „Achiziție: articol” conține mai multe informații în același timp. Dacă doar o parte din informații este de interes, nu se știe unde se află (la începutul sau în mijlocul celulei), astfel încât expresia care trebuie căutată trebuie să fie completată de un substituent de ambele părți. O problemă similară există atunci când căutați locații. O persoană care are un cuvânt ca nume de familie care este, de asemenea, introdus ca loc ar fi găsită atunci când caută locul.
• Un astfel de tabel pare să conțină doar text. Cu aceasta, textul ar putea fi, de asemenea, introdus în celula de dată sau o virgulă ar putea fi utilizată ca separator în locul unui punct din informațiile despre preț, astfel încât valoarea să nu mai poată fi utilizată corect pentru operațiile aritmetice.
• Exemplul 2 include în prezent numai comenzi și livrări. Dacă livrarea către „Lisa Mayer” ar fi ștearsă sau anulată, detaliile adresei ar dispărea, deși ar putea fi necesare. Aceasta se numește Ștergeți anomalia numit. O alternativă ar fi să introduceți „Lisa Mayer” fără o livrare. Aceasta înseamnă că câmpurile care sunt absolut necesare pentru o livrare nu trebuie declarate cu NOT NULL, SGBD-ul nu poate asigura coerența intrării. Dacă, pe de altă parte, o comandă ar fi obligatorie, acesta ar fi un exemplu Introduceți anomalie. Chiar și cu admisibilitatea unei persoane fără o comandă, nu este clar dacă datele trebuie introduse în coloana „Furnizor” sau „Destinatar”. În cele din urmă, se poate imagina că o companie este atât furnizor, cât și destinatar sau bunurile sunt trimise unei persoane înregistrate ca angajat.
• Dacă compania „Muster-Liefer” livrează pantaloni în diferite culori, aceste informații pot fi ignorate. Acest lucru face imposibilă defalcarea cifrelor de cumpărare și vânzări în funcție de culoarea pantalonilor. Dacă și aceste informații sunt stocate, toate datele de adresă trebuie, de asemenea, introduse din nou, astfel încât probabilitatea erorilor de intrare crește. O greșeală de ortografie „FI Muster-Liefer” ar duce la căutarea textului pentru „FA Muster-Liefer *” în această înregistrare de date dispărând.
• Cele două livrări din 15.02.2003 privesc articole diferite. Cele două livrări din 17.02.2003, pe de altă parte, ar putea fi combinate într-o singură livrare cu 70 de bucăți, deoarece valorile celulei sunt identice, cu excepția coloanei „Cantitate”, și este logic să adăugați două bucăți de informații pentru cantitate.

Evident, un astfel de design produce diverse probleme și evaluări incorecte. Spre deosebire de orice arhivă sub formă de hârtie, ar fi posibilă o căutare în text pur. Cu toate acestea, rezultatele ar trebui verificate din nou manual; fiecare intrare incorectă poate fi determinată doar prin verificarea celulei originale. Din acest motiv, un astfel de design denormalizat ar distruge toate avantajele arhivării datelor asistate de computer.

Următoarele pagini tratează, prin urmare, tehnicile tipice de baze de date pentru descompunerea unui astfel de tabel denormalizat în mai multe tabele mai mici.

---