Таблици с редове и колони като основа на релационна база данни
| 1 | Риза | 39,80 | 40 | 24.06.1999 | Майер, Емил | Wendeweg 10, 2800 Бремен |
| 2 | палто | 360,00 | 10 | 24.06.1999 | Майер, Франц | Колщрасе 1, 2800 Бремен |
| 3 | Риза | 44,20 | 70 | 24.06.1999 | Майер, Емил | Wendeweg 10, 2800 Бремен |
| 4-ти | Риза | 44,20 | 20-ти | 25.06.1999 | Шулце, Фриц | Gemüseweg 3, 2800 Бремен |
| 5 | палто | 360,00 | 35 | 25.06.1999 | Майер, Франц | Колщрасе 1, 2800 Бремен |
| 6-то | панталони | 110,50 | 35 | 24.06.1999 | Майер, Емил | Wendeweg 10, 2800 Бремен |
| 7-ми | панталони | 110,50 | 5 | 24.06.1999 | Шулце, Фриц | Gemüseweg 3, 2800 Бремен |
| 8-ми | Риза | 39,80 | 10 | 24.06.1999 | Шулце, Фриц | Gemüseweg 3, 2800 Бремен |
| 9 | Риза | 44,20 | 20-ти | 25.06.1999 | Майер, Емил | Wendeweg 10, 2800 Бремен |
Този пример изглежда структуриран съвсем ясно, така че човек може бързо да разбие такава денормализирана таблица на три таблици. Ако обаче се вземат предвид текущите дневни цени, възниква въпросът дали цената е въведена в таблицата на артикулите или в таблицата на продажбите. Пример 2:
| 1 | 24 | 15 февруари 2003 г. | Панталони, сини | FA Muster-Liefer GbR, Нюрнберг | 39,90 | 50 | ||||
| 2 | 24 | 15 февруари 2003 г. | Панталони, кафяви | FA Muster-Liefer GbR, Нюрнберг | 39,90 | 50 | ||||
| 3 | 27 | 16 февруари 2003 г. | Панталони | Макс Мюлер, Берлин | 49,90 | 10 | ||||
| 4-ти | 28 | 17 февруари 2003 г. | Ризи | FA Groß-Handel AG, Хамбург | 18.40 | 30-ти | ||||
| 5 | 28 | 17 февруари 2003 г. | Ризи | FA Groß-Handel AG, Хамбург | 18.40 | 40 | ||||
| 6-то | 35 | 18 февруари 2003 г. | Ризи | Лиза Майер, Мюнхен | 23,90 | 5 |
Характеристики и недостатъци на напълно денормализираната маса
- От една страна, всяка информация очевидно може да бъде сортирана в таблица, която е структурирана по този начин и има много колони. Ако трябва да се архивира допълнителна информация, достатъчно е да се добавят допълнителни редове и, ако е необходимо, да се оставят празни. На теория всяка база данни може да се задоволи с една таблица, структурирана според този модел. В най-крайния случай таблицата ще съдържа една голяма колона текст, в която цялата информация ще бъде изброена по ред. От друга страна, тази форма на вътрешно представителство има очевидни недостатъци, които ще бъдат обсъдени по-долу.
- Излишъкът на тези примери е очевиден. В първия пример едни и същи адресни данни са изброени няколко пъти, така че ако има промяна един Трябва да се търси и пренапише адрес на няколко идентични клетки. В такъв случай се говори за такъв Аномалия на актуализацията. Тогава може да има двама различни хора с еднакви име и фамилия, така че търсенето преди актуализацията да намери няколко адреса и след това да ги промени. Недвусмислените хора трябва да бъдат ясно характеризирани.
- Ако търсите всички панталони в пример 2, трябва да работите с търсене на заместител, което търси „Маркуч *“ или „* Маркуч *“ и използва „*“ като заместител. Тъй като клетката „Закупуване: артикул“ съдържа няколко части информация едновременно. Ако само част от информацията представлява интерес, не се знае къде се намира (в началото или в средата на клетката), така че изразът, който трябва да се търси, трябва да бъде допълнен от заместител от двете страни. Подобен проблем съществува при търсене на местоположения. Човек, който има дума като фамилия, която също е въведена като място, ще бъде намерен при търсене на мястото.
- Изглежда, че такава таблица съдържа само текст. С това текстът също може да бъде въведен в клетката за дата или запетая може да се използва като разделител вместо точката в ценовата информация, така че стойността вече не може да се използва правилно за аритметични операции.
- Пример 2 понастоящем включва само поръчки и доставки. Ако доставката до „Lisa Mayer“ бъде изтрита или анулирана, данните за адреса също ще изчезнат, въпреки че може да са необходими. Това се казва Изтрийте аномалията на име. Алтернатива би била да въведете „Lisa Mayer“ без доставка. Това означава, че полетата, които са абсолютно необходими за доставка, не трябва да бъдат декларирани с NOT NULL, СУБД не може да осигури последователността на входа. От друга страна, ако поръчката е била задължителна, това би било пример за такава Поставете аномалия. Дори при допустимостта на лице без поръчка не е ясно дали данните трябва да се въвеждат в колоната „Доставчик“ или „Получател“. И накрая, възможно е случаят да е, че дадена компания е едновременно доставчик и получател или стоките се изпращат на лице, регистрирано като служител.
- Ако фирмата „Muster-Liefer“ доставя панталони в различни цветове, тази информация може да бъде пренебрегната. Това прави невъзможно разбиването на данните за покупките и продажбите според цвета на панталона. Ако тази информация също се съхранява, всички адресни данни също трябва да бъдат въведени отново, така че вероятността от грешки при въвеждане да се увеличи. Погрешно изписване „FI Muster-Liefer“ би довело до изчезването на този запис на данни при търсене на текст за „FA Muster-Liefer *“.
- Двете доставки на 02.15.2003 г. се отнасят до различни статии. Двете доставки от 17.02.2003 г., от друга страна, биха могли да бъдат комбинирани в една доставка със 70 броя, тъй като стойностите на клетките са идентични, с изключение на колоната "Количество", и има смисъл да се добавят две части информация за количеството.
Следователно следващите страници разглеждат типичните техники на базата данни за разбиване на такава денормализирана таблица на няколко по-малки таблици.