Введення в проектування реляційних баз даних [ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати. скачати Цілі проектування Тільки невеликі організації можуть усуспільнити дані в одній повністю інтегрованої бази даних. Найчастіше адміністратор баз даних (навіть якщо це група осіб) практично не в змозі охопити і осмислити всі інформаційні вимоги співробітників організації (тобто майбутніх користувачів системи). Тому інформаційні системи великих організацій містять кілька десятків БД, нерідко розподілених між кількома взаємопов'язаними ЕОМ різних підрозділів. (Так у великих містах створюється не одна, а кілька овочевих баз, розташованих у різних районах.) Окремі БД можуть об'єднувати всі дані, необхідні для вирішення однієї або декількох прикладних задач, або дані, пов'язані з будь-якої предметної області (наприклад, фінансів, студентам, викладачам, кулінарії тощо). Перші зазвичай називають прикладними БД, а другі - предметними БД (співвідносяться з предметами організації, а не з її інформаційними додатками). (Перші можна порівняти з базами матеріально-технічного постачання або відпочинку, а другі - з овочевими та взуттєвими базами.) Предметні БД дозволяють забезпечити підтримку будь-яких поточних і майбутніх додатків, оскільки набір їх елементів даних включає в себе набори елементів даних прикладних БД. Внаслідок цього предметні БД створюють основу для обробки неформалізованих, змінюються і невідомих запитів та програм (додатків, для яких неможливо заздалегідь визначити вимоги до даних). Така гнучкість і пристосованість дозволяє створювати на основі предметних БД досить стабільні інформаційні системи, тобто системи, в яких більшість змін можна здійснити без вимушеного переписування старих додатків. Засновуючи ж проектування БД на поточних і передбачуваних додатках, можна істотно прискорити створення високоефективної інформаційної системи, тобто системи, структура якої враховує найбільш часто зустрічаються шляху доступу до даних. Тому прикладне проектування до цих пір привертає деяких розробників. Однак у міру зростання числа додатків таких інформаційних систем швидко збільшується число прикладних БД, різко зростає рівень дублювання даних і підвищується вартість їх ведення. Таким чином, кожний з розглянутих підходів до проектування впливає на результати проектування в різних напрямках. Бажання досягти і гнучкості, і ефективності призвело до формування методології проектування, що використовує як предметний, так і прикладної підходи. У загальному випадку предметний підхід використовується для побудови початкової інформаційної структури, а прикладний - для її вдосконалення з метою підвищення ефективності обробки даних. При проектуванні інформаційної системи необхідно провести аналіз цілей цієї системи і виявити вимоги до неї окремих користувачів (співробітників організації) [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). Тепер при зміні назви постачальника "Полісся" на "Дніпро" виправляється єдине значення в таблиці Постачальники. І навіть якщо воно вводиться з помилкою ("Дніпро"), то це не може вплинути на зв'язок між постачальниками та продуктами (у сполучній таблиці Постачання використовуються номери постачальників і продуктів, а не їх назви).

Рис. 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 из первоначальной таблицы:

2. Таблица имеет первичный (возможный) ключ К, не являющееся возможным ключом поле F1, которое, конечно, функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. Решение здесь, по существу, то же самое, что и прежде – формируется другая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы:

Для любой заданной таблицы, повторяя применение двух рассмотренных правил, почти во всех практических ситуациях можно получить в конечном счете множество таблиц, которые находятся в "окончательной" нормальной форме и, таким образом, не содержат каких-либо функциональных зависимостей вида, отличного от 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. Синтаксис описания проектных решений

Для примера приведем описания таблиц "Блюда" и "Состав":

Рассмотренный язык описания данных, основанный на языке SQL [5], позволяет дать удобное и полное описание любой сущности и, следовательно, всей базы данных. Однако такое описание, как и любое подробное описание, не отличается наглядностью. Для достижения большей иллюстративности целесообразно дополнять проект инфологической моделью, но менее громоздкой, чем рассмотренная в главе 2.

Для наиболее распространенных реляционных баз данных можно предложить язык инфологического моделирования "Таблица-связь", пример использования которого приведен на рис. 4.7. В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени и типа сущности. Строки таблицы – это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, распологаются рядом и обводятся рамкой. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих.

Рис. 4.7. Инфологическая модель базы данных "Питание", построенная с помощью языка "Таблицы-связи"

Векторы . Представляйте векторы по столбцам, а не по строкам. Например, диаграмму продаж товаров x, y, ... за последние годы лучше представить в виде:

а не так, как показано ниже:

Одна из причин такой рекомендации заключается в том, что при этом значительно проще записываются обобщенные (параметризованные) запросы. Рассмотрите, например, как выглядит сравнение сведений из диаграммы продаж товара i в месяце с номером m со сведениями для товара j в месяце с номером n, где i, j, m и n – параметры.

Неопределенные значения . Будьте очень внимательны с неопределенными (NULL) значениями. В поведении неопределенных значений проявляется много произвола и противоречивости. В разных СУБД при выполнении различных операций (сравнение, объединение, сортировка, группирование и другие) два неопределенных значения могут быть или не быть равными друг другу. Они могут по разному влиять на результат выполнения операций по определению средних значений и нахождения количества значений. Для исключения ошибок в ряде СУБД существует возможность замены NULL-значения нулем при выполнении расчетов, объявление всех NULL-значений равными друг другу и т.п.