Таблиці з рядками та стовпцями як основа реляційної бази даних
| 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" без доставки. Це означає, що поля, які є абсолютно необхідними для доставки, не повинні оголошуватися NOT NULL, СУБД не може забезпечити узгодженість вводу. З іншого боку, якби замовлення було обов’язковим, це було б прикладом такого Вставте аномалію. Навіть зважаючи на прийнятність особи без замовлення, незрозуміло, чи слід вводити дані у стовпець "Постачальник" або "Одержувач". Нарешті, можна подумати, що компанія є і постачальником, і одержувачем, або товари надсилаються особі, зареєстрованій як працівник.
- Якщо компанія Muster-Liefer постачає штани різних кольорів, цю інформацію можна проігнорувати. Це унеможливлює розподіл показників купівлі та продажу за кольором штанів. Якщо ця інформація також зберігається, усі адресні дані також повинні бути введені ще раз, щоб збільшилася ймовірність помилок введення. Помилка орфографії "FI Muster-Liefer" призведе до зникнення цього запису даних при текстовому пошуку для "FA Muster-Liefer *".
- Дві поставки 02.15.2003 стосуються різних статей. З іншого боку, дві доставки від 17.02.2003 можна об'єднати в одну доставку на 70 штук, оскільки значення комірок однакові, за винятком стовпця "Кількість", і має сенс додати дві частини інформації для кількості.
Отже, на наступних сторінках розглядаються типові методи баз даних для розбиття такої денормалізованої таблиці на кілька менших таблиць.