Введення в проектування реляційних баз даних

Введення у проектування реляційних баз даних Цілі проектування

Тільки невеликі організації можуть усуспільнити дані в одній повністю інтегрованої бази даних. Найчастіше адміністратор баз даних (навіть якщо це група осіб) практично не в змозі охопити і осмислити всі інформаційні вимоги співробітників організації (тобто майбутніх користувачів системи). Тому інформаційні системи великих організацій містять кілька десятків БД, нерідко розподілених між декількома взаємозалежними ЕОМ різних підрозділів. (Так у великих містах створюється не один, а кілька овочевих баз, розташованих у різних районах.)

Окремі БД можуть об'єднувати всі дані, необхідні для вирішення однієї або кількох прикладних завдань, або дані, що відносяться до якої-небудь предметної області (наприклад, фінансів, студентам, викладачам, кулінарії і т.п.). Перші зазвичай називають прикладними БД, а другий - предметними БД (співвідносяться з предметами організації, а не з її інформаційними додатками). (Перші можна порівняти з базами матеріально-технічного постачання чи відпочинку, а другі - з овочевими та взуттєвими базами.)

Предметні БД дозволяють забезпечити підтримку будь-яких поточних і майбутніх додатків, оскільки набір їх елементів даних включає в себе набори елементів даних прикладних БД. Внаслідок цього предметні БД створюють основу для обробки неформалізованих, що змінюються і невідомих запитів та програм (додатків, для яких неможливо заздалегідь визначити вимоги до даних). Така гнучкість і пристосованість дозволяє створювати на основі предметних БД досить стабільні інформаційні системи, тобто системи, в яких більшість змін можна здійснити без вимушеного переписування старих додатків.

Засновуючи ж проектування БД на поточних і передбачуваних додатках, можна істотно прискорити створення високоефективної інформаційної системи, тобто системи, структура якої враховує найбільш часто зустрічаються шляху доступу до даних. Тому прикладне проектування до цих пір привертає деяких розробників. Однак у міру зростання числа програм таких інформаційних систем швидко збільшується число прикладних БД, різко зростає рівень дублювання даних і підвищується вартість їх ведення.

Таким чином, кожний з розглянутих підходів до проектування впливає на результати проектування в різних напрямках. Бажання досягти і гнучкості, і ефективності призвело до формування методології проектування, що використовує як предметний, так і прикладної підходи. Загалом випадку предметний підхід використовується для побудови початкової інформаційної структури, а прикладним - для її вдосконалення з метою підвищення ефективності обробки даних.

При проектуванні інформаційної системи необхідно провести аналіз цілей цієї системи і виявити вимоги до неї окремих користувачів (співробітників організації) [2, 3, 4, 6, 8, 9, 10]. Збирання даних починається з вивчення сутностей організації і процесів, які використовують ці сутності (докладніше в додатку Б). Сутності групуються по "подібності" (частоті їх використання для виконання тих чи інших дій) і за кількістю асоціативних зв'язків між ними (літак - пасажир, викладач - дисципліна, студент - сесія і т.д.). Сутності або групи сутностей, що володіють найбільшим схожістю та (або) з найбільшою частотою асоціативних зв'язків об'єднуються в предметні БД. (Нерідко сутності об'єднуються в предметні БД без використання формальних методик - по "здоровому глузду".) Для проектування та ведення кожної предметної БД (декількох БД) призначається АБД, який далі займається детальним проектуванням бази.

Далі будуть розглядатися питання, пов'язані з проектуванням окремих реляційних предметних БД.

Основна мета проектування БД - це скорочення надмірності збережених даних, а отже, економія обсяг використаної пам'яті, зменшення витрат на багаторазові операції оновлення надлишкових копій та усунення можливості виникнення суперечностей через зберігання в різних місцях відомостей про одне і тому ж об'єкті. Так званий, "чистий" проект БД ( "Кожен факт в одному місці") можна створити, використовуючи методологію нормалізації відносин. І хоча нормалізація повинна використовуватися на завершальній перевірочної стадії проектування БД, ми почнемо обговорення питань проектування з розгляду причин, які змусили Кодда створити основи теорії нормалізації. Універсальне відношення

Припустимо, що проектування бази даних "Харчування" (мал. 3.2) починається з виявлення атрибутів і підбору даних, зразок яких (частина страв виготовлених і реалізованих 1/9/94 р.) показано на рис. 4.1.

Цей варіант таблиці "Харчування" не є ставленням, тому що більшість її строк не атомарний. Атомарними є лише значення полів Блюдо, Вид, Рецепт (хоча він і великий), Працюй і Дата_Р інші ж поля таблиці мал. 4.1 - множинні. Для надання таких даних форми відносини необхідно реконструювати таблицю. Найпростіше це зробити за допомогою простого процесу вставки, результат якої показано на рис. 4.2. Однак таке перетворення призводить до виникнення великого обсягу надлишкових даних. Блюдо Вид Рецепт Порцій Дата Р Продукт Калорійність Вага (г) Постачальник Місто Країна Вага (кг) Ціна ($) Дата П Лобіо Закуска Лом. 158 1/9/94 Квасоля 3070 200 "Хуанхе" Пекін Китай 250 0.37 24/8/94 Цибуля 450 40 "Наталка" Київ Україна 100 0.52 27/8/94 Масло 7420 30 "Лайма" Рига Латвія 70 1.55 30/8/94 Зелень 180 10 "Даугава" Рига Латвія 15 0.99 30/8/94 Харчо Суп ... 144 1/9/94 М'ясо 1660 80 "Наталка" Київ Україна 100 2.18 27/8/94 Цибуля 450 30 "Наталка" Київ Україна 100 0.52 27/8/94 Томати 240 40 "Полісся" Київ Україна 120 0.45 27/8/94 Рис 3340 50 "Хуанхе" Пекін Китай 75 0.44 24/8/94 Масло 7420 15 "Полісся" Київ Україна 50 1.62 27/8/94 Зелень 180 15 "Наталка" Київ Україна 10 0.88 27/8/94 Шашлик Гаряче ... 207 1/9/94 М'ясо 1660 180 "Юрмала" Рига Латвія 200 2.05 30/8/94 Цибуля 450 40 "Полісся" Київ Україна 50 0.61 27/8/94 Томати 240 100 "Полісся" Київ Україна 120 0.45 27/8/94 Зелень 180 20 "Даугава" Рига Латвія 15 0.99 30/8/94 Кава Десерт ... 235 1/9/94 Кава 2750 8 "Хуанхе" Пекін Китай 40 2.87 24/8/94

Рис. 4.1. Дані, необхідні для створення бази даних "Харчування"
Таблиця на рис. 4.2 являє собою примірник коректного ставлення. Його називають універсальним ставленням проектованої БД. В одне універсальне ставлення включаються всі представляють інтерес атрибути, і воно може містити всі дані, які передбачається розміщувати в БД в майбутньому. Для малих БД (що включають не більше 15 атрибутів) універсальне відношення може використовуватися як відправну точку при проектуванні БД.       Блюдо          Вид          Рецепт          Порцій          Дата Р          Продукт          Калорійність          Вага (г)          Постачальник          Місто          Країна          Вага (кг)          Ціна ($)          Дата П         Лобіо         Закуска         Лом.         158         1/9/94         Квасоля         3070         200         "Хуанхе"         Пекін         Китай         250         0.37         24/8/94         Лобіо         Закуска         Лом         108         1/9/94         Цибуля         450         40         "Наталка"         Київ         Україна         100         0.52         27/8/94         Лобіо         Закуска         Лом         108         1/9/94         Масло         7420         30         "Лайма"         Рига         Латвія         70         1.55         30/8/94         Лобіо         Закуска         Лом         108         1/9/94         Зелень         180         10         "Даугава"         Рига         Латвія         15         0.99         30/8/94         Харчо         Суп         ...         144         1/9/94         М'ясо         1660         80         "Наталка"         Київ         Україна         100         2.18         27/8/94         Харчо         Суп         ...         144         1/9/94         Цибуля         450         30         "Наталка"         Київ         Україна         100         0.52         27/8/94         Харчо         Суп         ...         144         1/9/94         Томати         240         40         "Полісся"         Київ         Україна         120         0.45         27/8/94         Харчо         Суп         ...         144         1/9/94         Рис         3340         50         "Хуанхе"         Пекін         Китай         75         0.44         24/8/94         Харчо         Суп         ...         144         1/9/94         Масло         7420         15         "Полісся"         Київ         Україна         50         1.62         27/8/94         Харчо         Суп         ...         144         1/9/94         Зелень         180         15         "Наталка"         Київ         Україна         10         0.88         27/8/94         Шашлик         Гаряче         ...         207         1/9/94         М'ясо         1660         180         "Юрмала"         Рига         Латвія         200         2.05         30/8/94         Шашлик         Гаряче         ...         207         1/9/94         Цибуля         450         40         "Полісся"         Київ         Україна         50         0.61         27/8/94         Шашлик         Гаряче         ...         207         1/9/94         Томати         240         100         "Полісся"         Київ         Україна         120         0.45         27/8/94         Шашлик         Гаряче         ...         207         1/9/94         Зелень         180         20         "Даугава"         Рига         Латвія         15         0.99         30/8/94         Кава         Десерт         ...         235         1/9/94         Кава         2750         8         "Хуанхе"         Пекін         Китай         40         2.87         24/8/94
Рис. 4.2. Універсальне відношення "Харчування" Чому проект БД може бути поганим?
Начинающий проектувальник буде використовувати відношення "Харчування" (мал. 4.2) як завершеною БД. Дійсно, навіщо розбивати відношення "Харчування" на декілька більш дрібних відносин (див. наприклад, рис. 3.2), якщо воно містить в собі всі дані? А розбивати треба тому, що при використанні універсального відносини виникає кілька проблем:
1. Надмірність. Дані практично всіх стовпців багаторазово повторюються. Повторюються і деякі набори даних (Блюдо-Вид-Рецепт, Продукт-Калорійність, Постачальник-Місто-Країна). Небажано повторення рецептів, деякі з яких набагато більше рецепту "лобіо" (див. рис. 2.3). І вже зовсім погано, що всі дані про страву (включаючи рецепт) повторюються щоразу, коли це блюдо включається в меню.
2. Потенційна суперечливість (аномалії оновлення). Внаслідок надмірності можна оновити адресу постачальника в одному рядку, залишаючи його незмінним в інших. Якщо постачальник кави повідомив про свій переїзд в Харбін і була оновлена рядок з продуктом кави, то у постачальника "Хуанхе" з'являється дві адреси, один з яких не актуальне. Отже, при оновлення необхідно переглядати всю таблицю для знаходження і зміни всіх відповідних рядків.
3. Аномалії включення. В БД не може бути записаний новий постачальник ( "Нярінга", Вільнюс, Литва), якщо що поставляється їм продукт (Огірки) не використовується ні в одній страві. Можна, звичайно, помістити невизначені значення в стовпці Блюдо, Вид, Працюй і Вага (г) для цього постачальника. Але якщо з'явиться блюдо, в якому використовується цей товар, не забудемо ми видалити рядок з невизначеними значеннями?
З аналогічних причин не можна ввести і новий продукт (наприклад, Баклажани), який пропонує існуючий постачальник (наприклад, "Полісся"). А як ввести нову страву, якщо в ньому використовується новий продукт (Краби)?
4. Аномалії видалення. Зворотній проблема виникає при необхідності видалення всіх продуктів, що поставляються даними постачальником або всіх страв, використовують ці продукти. За таких видалення будуть втрачені відомості про такий постачальника.
Багато проблем цього прикладу зникнуть, якщо виділити в окремі таблиці відомості про страви, рецептах, витраті страв, продукти та їх постачальників, а також створити сполучні таблиці "Склад" та "Постачання" (мал. 4.3).      Страви                     Блюдо                Вид                       Лобіо               Закуска                       Харчо               Суп                       Шашлик               Гаряче                       Кава               Десерт                       ...               ...                          Рецепти                     Блюдо                Рецепт                       Лобіо               Ламану очищу                       ...               ...                          Витрата                     Блюдо                Порцій                Дата_Р                       Лобіо               158               1/9/94                       Харчо               144               1/9/94                       Шашлик               207               1/9/94                       Кава               235               1/9/94                       ...               ...               ...                          Продукти                     Продукт                Калор.                       Квасоля               3070                       Цибуля               450                       Масло               7420                       Зелень               180                       М'ясо               1660                       ...               ...                          Склад                     Блюдо                Продукт                Вага (г)                       Лобіо               Квасоля               200                       Лобіо               Цибуля               40                       Лобіо               Масло               30                       Лобіо               Зелень               10                       Харчо               М'ясо               80                       ...               ...               ...                          Постачальники                     Постачальник                Місто                Країна                       "Полісся"               Київ               Україна                       "Наталка"               Київ               Україна                       "Хуанхе"               Пекін               Китай                       "Лайма"               Рига               Латвія                       "Юрмала"               Рига               Латвія                       ...               ...               ...                          Постачання                     Постачальник                Місто                Продукт                Вага (кг)                Ціна ($)                Дата_П                       "Полісся"               Київ               Томати               120               0.45               27/8/94                       "Полісся"               Київ               Масло               50               1.62               27/8/94                       "Полісся"               Київ               Цибуля               50               0.61               27/8/94                       "Наталка"               Київ               Цибуля               100               0.52               27/8/94                       ...               ...               ...               ...               ...               ...
Рис. 4.3. Перетворення універсального відносини "Харчування" (перший варіант)
Включення . Простим додаванням строк (Постачальники; "Нярінга", Вільнюс, Литва) та (Поставки; "Нярінга", Вільнюс, Огірки, 40) можна ввести інформацію про нового постачальника. Аналогічно можна ввести дані про новий продукт (Продукти; Баклажани, 240) і (Поставки; "Полісся", Київ, Баклажани, 50).
Видалення . Видалення відомостей про деякі постачання або стравах не приводить до втрати відомостей про постачальників.
Оновлення . У таблицях рис. 4.3 все ще багато повторюваних даних, що знаходяться в сполучних таблицях (Склад і Поставки). Отже, в даному варіанті БД збереглася потенційна суперечливість: для зміни назви постачальника з "Полісся" на "Дніпро" доведеться змінювати не тільки рядок таблиці Постачальники, але і безліч рядків таблиці Постачання. При цьому не виключено, що в БД будуть одночасно зберігатися: "Полісся", "Палесі", "Дніпро", "Дніпро" та інші варіанти назв.
Крім того, що повторюються текстові дані (такі як назва страви "Рулет з телячей грудинки з сосисками і гарніром з різнобарвного пюре "або продукту" Ковбаса московська сирокопчена ") суттєво збільшують обсяг збережених даних.
Для виключення посилань на довгі текстові значення останні зазвичай нумерують: нумерують страви у великих кулінарних книгах, товари (продукти) в каталогах і т.д. Скористаємося цим прийомом для виключення надмірного дублювання даних і появи помилок при копіюванні довгих текстових значень (рис. 4.4). Тепер при зміні назви постачальника "Полісся" на "Дніпро" виправляється єдине значення в таблиці Постачальники. І навіть якщо воно вводиться з помилкою ( "Дніпро"), то це не може вплинути на зв'язок між постачальниками та продуктами (в сполучною таблиці Постачання використовуються номери постачальників і продуктів, а не їх назви).      Страви                     БЛ                Блюдо                Вид                       1               Лобіо               Закуска                       2               Харчо               Суп                       3               Шашлик               Гаряче                       4               Кава               Десерт                       ...               ...               ...                          Рецепти                     Блюдо                Рецепт                       Лобіо               Ламану очищу                       ...               ...                          Витрата                     Блюдо                Порцій                Дата_Р                       Лобіо               158               1/9/94                       Харчо               144               1/9/94                       Шашлик               207               1/9/94                       Кава               235               1/9/94                       ...               ...               ...                          Продукти                     ПР                Продукт                Калор.                       1               Квасоля               3070                       2               Цибуля               450                       3               Масло               7420                       4               Зелень               180                       5               М'ясо               1660                       ...               ...               ...                          Склад                     БЛ                ПР                Вага (г)                       1               1               200                       1               2               40                       1               3               30                       1               4               10                       2               5               80                       ...               ...               ...                          Постачальники                     ПОС                Постачальник                Місто                Країна                       1               "Полісся"               Київ               Україна                       2               "Наталка"               Київ               Україна                       3               "Хуанхе"               Пекін               Китай                       4               "Лайма"               Рига               Латвія                       5               "Юрмала"               Рига               Латвія                       ...               ...               ...               ...                          Постачання                     ПОС                ПР                Вага (кг)                Ціна ($)                Дата_П                       1               6               120               0.45               27/8/94                       1               3               50               1.62               27/8/94                       1               2               50               0.61               27/8/94                       2               2               100               0.52               27/8/94                       ...               ...               ...               ...               ...
Рис. 4.4. Перетворення універсального відносини "Харчування" (другий варіант) Про нормалізації, функціональних і багатозначних залежності
Нормалізація - це розбиття таблиці на дві або більше, що володіють кращими властивостями при включенні, зміну і видалення даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечливості збережених даних.
Як зазначалося в п. 3.1, кожна таблиця в реляційної БД задовольняє умові, відповідно до якого в позиції на перетині кожного рядка і стовпця таблиці завжди знаходиться єдине атомарному значення, і ніколи не може бути безлічі таких значень. Будь-яка таблиця, яка задовольняє цій умові, називається нормалізованому (див. таблиці мал. 4.2 - 4.4). Фактично, ненормалізованние таблиці, тобто таблиці, що містять повторювані групи (див. рис. 4.1), навіть не допускаються в реляційної БД.
Всяка нормалізована таблиця автоматично вважається таблицею в першу нормальної формі, скорочено 1НФ. Таким чином, строго кажучи, "нормалізована" і "що знаходиться в 1НФ" означають одне й те ж. Однак на практиці термін "нормалізована" часто використовується у більш вузькому сенсі - "повністю нормалізована", який означає, що в проекті не порушуються жодні принципи нормалізації.
Тепер в додаток до 1НФ можна визначити подальші рівні нормалізації - другу нормальну форму (2НФ), третю нормальну форму (3НФ) і т.д. По суті, таблиця знаходиться в 2НФ, якщо вона знаходиться в 1НФ і задовольняє, крім того, деякого додаткового умові, суть якого буде розглянута нижче. Таблиця знаходиться в 3НФ, якщо вона знаходиться в 2НФ і, крім цього, задовольняє ще інші додаткові умови і т.д.
Таким чином, кожна нормальна форма є в певному сенсі більш обмеженою, а й більш бажаною, ніж попередня. Це пов'язано з тим, що "(N +1)-я нормальна форма" не має деякі непривабливими рисами, властивим "N-й нормальній формі". Загальний зміст додаткової умови, що накладається на (N +1)-ю нормальну форму по відношенню до N-й нормальній формі, складається у виключенні цих непривабливих особливостей. У п. 4.3 ми виявляли непривабливі особливості таблиці мал. 4.2 та для їх вилучення виконували "інтуїтивне нормалізацію".
Теорія нормалізації грунтується на наявності тієї чи іншої залежності між полями таблиці. Визначено два види таких залежностей: функціональні та багатозначні.
Функціональна залежність. Поле У таблиці функціонально залежить від поля А тієї ж таблиці в тому і тільки в тому випадку, коли в будь-який заданий момент часу для кожного з різних значень поля А обов'язково існує тільки одне з різних значень поля В. Відзначимо, що тут допускається, що поля А і В можуть бути складними.
Наприклад, в таблиці Блюда (рис. 4.4) поля Блюдо і Вид функціонально залежать від ключа БЛ, а в таблиці Постачальники рис. 4.3 полі Країна функціонально залежить від складного ключа (Постачальник, Місто). Однак остання залежність не є функціонально повною, так як Країна функціонально залежить і від частини ключа - поля Місто.
Повна функціональна залежність. Поле У перебуває у повній функціональної залежності від складного поля А, якщо воно функціонально залежить від А і не функціонально залежить від будь-якої підмножини поля А.
Багатозначні залежність. Поле А багатозначне визначає поле В той же таблиці, якщо для кожного значення поля А існує добре певний безліч відповідних значень В.
Навчання       Дисципліна          Викладач          Підручник         Інформатика         Шипілов П.А.         Форсайт Р. Паскаль для всіх         Інформатика         Шипілов П.А.         Уейт М. та ін Мова Сі         Інформатика         Голованівський Г.Л.         Форсайт Р. Паскаль для всіх         Інформатика         Голованівський Г.Л.         Уейт М. та ін Мова Сі         ...         ...         ...
Рис. 4.5. До ілюстрації багатозначних залежностей
Для прикладу розглянемо таблицю "Навчання" (мал. 4.5). У ній є багатозначна залежність "Дисципліна-Викладач": дисципліна (у прикладі Інформатика) може може читатися кількома викладачами (у прикладі Шипілова і Голованівський). Є й інша багатозначна залежність "Дисципліна-Підручник": при вивченні Інформатики використовуються підручники "Паскаль для всіх" та "Мова Сі". При цьому Викладач і Підручник не связнифункціональной залежністю, що призводить до появи надмірності (для додавання ще одного підручника доведеться ввести в таблицю два нових рядка). Справа поліпшується при заміні цієї таблиці на дві: (Дисципліна-Викладач і Дисципліна-Підручник). Процедура нормалізації
Як вже говорилося, нормалізація - це розбиття таблиці на декілька, що володіють кращими властивостями при оновленні, включення і видалення даних. Тепер можна дати й інше визначення: нормалізація - це процес послідовної заміни таблиці її повними декомпозиції до тих пір, поки всі вони не будуть знаходитися в 5НФ. На практиці ж досить навести таблиці до НФБК і з великою гарантією вважати, що вони знаходяться в 5НФ. Зрозуміло, цей факт потребує перевірки, однак поки що не існує ефективного алгоритму такої перевірки. Тому зупинимося лише на процедурі приведення таблиць до НФБК.
Ця процедура грунтується на тому, що єдиними функціональними залежностями в будь-якій таблиці повинні бути залежності виду K-> F, де K - первинний ключ, а F -- деяке інше поле. Зауважимо, що це випливає з визначення первинного ключа таблиці, відповідно до якого K-> F завжди має місце для всіх полів цієї таблиці. "Один факт в одному місці" говорить про те, що не мають сили ніякі інші функціональні залежності. Мета нормалізації складається саме в тому, щоб позбутися від усіх цих "інших" функціональних залежностей, тобто таких, які мають інший вигляд, ніж K-> F.
Якщо скористатися рекомендацією п. 4.5 та підмінити на час нормалізації коди первинних (зовнішніх) ключів на вихідні ключі, то, по суті, слід розглянути лише два випадки:
1. Таблиця має складовою первинний ключ виду, скажімо, (К1, К2), і включає також поле F, котра функціонально залежить від частини цього ключа, наприклад, від К2, але не від повного ключа. У цьому випадку рекомендується сформувати іншу таблицю, яка містить К2 і F (первинний ключ - К2), і видалити F з первісної таблиці: Замінити T (K1, K2, F), первинний ключ (К1, К2), ФЗ К2-> F на T1 (K1, K2), первинний ключ (К1, К2), і T2 (K2, F), первинний ключ К2 .
2. Таблиця має первинний (можливий) ключ К, яка не є можливим ключем поле F1, яке, звичайно, функціонально залежить від K, й інше неключових поле F2, яке функціонально залежить від F1. Рішення тут, по суті, те ж саме, що і раніше - формується інша таблиця, яка містить F1 і F2, з первинним ключем F1, і F2 видаляється з первісної таблиці: Замінити T (K, F1, F2), первинний ключ К, ФЗ F1-> F2 на T1 (K, F1), первинний ключ К, і T2 (F1, F2), первинний ключ F1.
Для будь-якої заданої таблиці, повторюючи застосування двох розглянутих правил, майже у всіх практичних ситуаціях можна отримати в кінцевому рахунку безліч таблиць, які знаходяться в "остаточної" нормальній формі і, таким чином, не містять будь-яких функціональних залежностей виду, відмінного від K-> F.
Для виконання цих операцій необхідно спочатку мати в якості вхідних даних будь-які "великі" таблиці (наприклад, універсальні відносини). Але нормалізація нічого не говорить про те, як отримати ці великі таблиці. У наступному розділі буде розглянута процедура отримання таких вихідних таблиць, а тут наведемо приклади нормалізації.
Приклад 4.1 . Застосуємо розглянуті правила для повної нормалізації універсального відносини "Харчування" (мал. 4.2).
Крок 1. Визначення первинного ключа таблиці.
Припустимо, що кожна страва має унікальну назву, відноситься до єдиного вигляду і готується за єдиним рецептом, тобто назву страви однозначно визначає його вигляд і рецепт. Припустимо також, що назва організації постачальника унікально для того міста, в якому він розташований, і назви міст унікальні для кожної з країн, тобто назва постачальника і місто однозначно визначають цього постачальника, а місто - країну його перебування. Нарешті, припустимо, що постачальник може здійснювати в один і той же день тільки одну поставку кожного продукту, тобто назва продукту, назва організації постачальника, місто та дата поставки однозначно визначають вагу і ціну поставленого продукту. Тоді як первинний ключ відносини "Харчування" можна використати такий набір атрибутів: Блюдо, Дата_Р, Продукт, Постачальник, Місто, Дата_П.
Крок 2. Виявлення полів, функціонально залежних від частини состваного ключа.
Поле Вид функціонально залежить тільки від поля Блюдо, тобто Блюдо-> Вид.
Аналогічним чином можна отримати залежності: Блюдо-> Рецепт (Блюдо, Дата_Р) -> ПорційПродукт-> Калорійність (Блюдо, Продукт) -> ВесГород-> Країна (Постачальник, Місто, Дата_П) -> Ціна
Крок 3. Формування нових таблиць.
Отримані функціональні залежності опредляют склад таблиць, які можна сформувати з даних універсального відносини: Блюда (Блюдо, Вид) Рецепти (Блюдо, Рецепт) Витрата (Блюдо, Дата_Р, Порцій) Продукти (Продукт, Калорійність) Склад (Блюдо, Продукт, Вага (г)) Міста (Місто, Країна) Постачання (Постачальник, Місто, Дата_П , Вага (кг), Ціна).
Крок 4. Коректування вихідної таблиці.
Після виділення з складу універсального відносини зазначених вище таблиць, там залишилися лише відомості про постачальників, для зберігання яких доцільно створити таблицю Постачальники (Постачальник, Місто),
тобто використовувати частина вихідного первинного ключа, тому що інші його частини вже нічого не визначають.
Таким чином, процедура послідовної нормалізації дозволила отримати проект, кращий, ніж наведено на рис. 4.3.
Приклад 4.2 . Для поліпшення проекту, наведеного на рис. 4.4, потрібно визначити первинні ключі таблиць і виявити, чи немає в таблицях полів, що залежать лише від частини цих ключів. Таке поле є тільки в одній таблиці. Це поле Країна в таблиці Постачальники. Виділяючи його разом з ключем Місто в таблицю Країни, отримаємо проект, наведений на рис. 3.2. Процедура проектування
Процес проектування інформаційних систем є досить складним завданням. Він починається з побудови інфологіческой моделі даних (п. 2), тобто ідентифікації сутностей. Потім необхідно виконати наступні кроки процедури проектування даталогіческой моделі.
1. Представити кожен стержень (незалежну сутність) таблицею бази даних (базовою таблицею) і специфікувати первинний ключ цієї базової таблиці.
2. Представити кожну асоціацію (зв'язок виду "многие-ко-многим" або "многие-ко-багатьом-ко-многим" і т.д. між сутностями) як базову таблицю. Використовувати в цій таблиці зовнішні ключі для ідентифікації учасників асоціації та специфікувати обмеження, пов'язані з кожним з цих зовнішніх ключів.
3. Представити кожну характеристику як базову таблицю із зовнішнім ключем, що ідентифікує сутність, описувану цією характеристикою. Специфікувати обмеження на зовнішній ключ цієї таблиці та її первинний ключ - цілком ймовірно, комбінації цього зовнішнього ключа і властивості, яке гарантує "унікальність в рамках описуваної суті ".
4. Представити кожне позначення, яке не розглядалося в попередньому пункті, як базову таблицю із зовнішнім ключем, що ідентифікує що позначається сутність. Специфікувати пов'язані з кожним таким зовнішнім ключем обмеження.
5. Представити кожне властивість як поле в базовій таблиці, що представляє сутність, що безпосередньо описується цією властивістю.
6. Для того щоб виключити в проекті ненавмисні порушення будь-яких принципів нормалізації, виконати описану в п. 4.6 процедуру нормалізації.
7. Якщо в процесі нормалізації було вироблено поділ будь-яких таблиць, то слід модифіковані інфологіческую модель бази даних і повторити перераховані кроки.
8. Вказати обмеження цілісності проектованої бази даних і дати (якщо це необхідно) короткий опис отриманих таблиць та їх полів.
На рис. 4.6 показаний синтаксис пропозиції, що пропонується для реєстрації прийнятих проектних рішень.

Рис. 4.6. Синтаксис опису проектних рішень
Для прикладу наведемо опису таблиць "Страви" і "Склад": Створити таблицю Страви * (Стрижнева сутність) ПЕРВИННИЙ КЛЮЧ (БЛ) ПОЛЯ (БЛ Ціле, Блюдо Текст 60, Вид Текст 7) ОБМЕЖЕННЯ (1. Значення поля Блюдо повинні бути унікальними; при порушенні висновок повідомлення "Таке блюдо вже є". 2. Значення поля Вид повинні належати набору: Закуска, Суп, Гаряче, Десерт, Напій; при порушенні висновок повідомлення "Можна лише Закуска, Суп, Гаряче, Десерт, Напій"); Створити таблицю Склад * (Зв'язує Страви і Продукти) ПЕРВИННИЙ КЛЮЧ (БЛ , ПР) ЗОВНІШНІЙ КЛЮЧ (БЛ З Страви NULL-значення Не допустимо ВИДАЛЕННЯ З Страви КАСКАДІРУЕТСЯОНОВЛЕННЯ Блюда.БЛ КАСКАДІРУЕТСЯ) ЗОВНІШНІЙ КЛЮЧ (ПР З Продукти NULL-значення Не допустимо ВИДАЛЕННЯ З Продукти ОБМЕЖУЄТЬСЯ ОНОВЛЕННЯ Продукти.ПР КАСКАДІРУЕТСЯ) ПОЛЯ (БЛ Ціле, ПР Ціле, Вес Ціле) ОБМЕЖЕННЯ (1. Значення полів БЛ і ПР повинні належати набору значень з відповідних полів таблиць Страви і Продукти; при порушенні висновок повідомлення "Такого страви немає" або "Такого продукту немає". 2. Значення поля Вага має лежати в межах від 0.1 до 500 р.);
Розглянутий мову опису даних, заснований на мові SQL [5], дозволяє дати зручне і повний опис будь-якої суті і, отже, всієї бази даних. Однак таке опис, як і будь-яке докладний опис, не відрізняється наочністю. Для досягнення більшої ілюстративності доцільно доповнювати проект інфологіческой моделлю, але менш громіздкою, ніж розглянута в розділі 2.
Для найбільш поширених реляційних баз даних можна запропонувати мова інфологіческого моделювання "Таблиця-зв'язок", приклад використання якого наведено на рис. 4.7. У ньому все сутності зображуються одностолбцовимі таблицями із заголовками, що складаються з імені та типу сутності. Рядки таблиці - це перелік атрибутів суті, а ті з них, які становлять первинний ключ, розташовуються поруч і обводяться рамкою. Зв'язок між сутностями вказуються стрілками, спрямованими від первинних ключів або їх складових.

Рис. 4.7. Інфологіческая модель бази даних "Харчування", побудована з допомогою мови "Таблиці-зв'язку" Різні поради та рекомендації
Вектори . Представляйте вектори по стовпцях, а не по рядках. Наприклад, діаграму продажів товарів x, y, ... за останні роки краще представити у вигляді: ТОВАР МІСЯЦЬ КІЛЬКІСТЬ ----- ------- ------ x 100 x СІЧЕНЬ ЛЮТИЙ 50 ... ... ... x ГРУДЕНЬ 360 y СІЧЕНЬ 75 y ЛЮТИЙ 144 ... ... ... y ГРУДЕНЬ 35 ... ... ...
а не так, як показано нижче: ТОВАР КІЛЬКІСТЬ КІЛЬКІСТЬ КІЛЬКІСТЬ СІЧЕНЬ ЛЮТИЙ ... ГРУДЕНЬ ----- ------- ------- ------- x 100 50 ... 360 y 75 144 ... 35 ... ... ... ... ...
Одна з причин такої рекомендації полягає в тому, що при цьому значно простіше записуються узагальнені (параметризрвані) запити. Розгляньте, наприклад, як виглядає порівняння відомостей з діаграми продажу товару i в місяці з номером m з відомостями для товару j в місяці з номером n, де i, j, m і n - параметри.
Невизначені значення . Будьте дуже уважні з невизначеними (NULL) значеннями. У поведінці невизначених значень виявляється багато свавілля і суперечливості. У різних СУБД при виконанні різних операцій (порівняння, об'єднання, сортування, групування і