МІНІСТЕРСТВО ОСВІТИ
Державна освітня установа
вищої професійної освіти
РОСІЙСЬКИЙ ДЕРЖАВНИЙ ГУМАНІТАРНИЙ УНІВЕРСИТЕТ
ІНСТИТУТ ІНФОРМАЦІЙНИХ НАУК І ТЕХНОЛОГІЙ БЕЗПЕКИ
Кафедра загальної інформатики
ГУБАРЄВ СЕРГІЙ ВОЛОДИМИРОВИЧ
КОНТРОЛЬНА РОБОТА З ДИСЦИПЛІНИ
«БАЗИ ДАНИХ»
Проектування реляційних баз даних
Екстерн 3 РОКИ НАВЧАННЯ (4-річного терміну навчання)
ГРУПА Б (інформаційна сфера)
Науковий керівник
викладач
Туляков С. П.
Москва
2005
ПЛАН
ВСТУП 3
ОСНОВНА ЧАСТИНА
1. Проектування реляційних баз даних
з використанням нормалізації 5
1.1. Друга нормальна форма 7
1.2. Третя нормальна форма 9
1.3. Нормальна форма Бойса-Кодда 10
1.4. Четверта нормальна форма 12
1.5. П'ята нормальна форма 13
2. Семантичне моделювання даних, ER-діаграми 15
2.1. Семантичні моделі даних 16
2.2. Основні поняття моделі Entity-Relationship
(Сутність-зв'язку) 17
2.3. Нормальні форми ER-схем 20
2.4. Більш складні елементи ER-моделі 20
2.5. Отримання реляційної схеми з ER-схеми 23
ВИСНОВОК 27
СПИСОК ЛІТЕРАТУРИ 28
ВСТУП
Управління інформацією завжди було основною сферою застосування комп'ютерів, і, треба думати, буде грати ще більшу роль у майбутньому. Бази даних та системи управління ними (СУБД, DBMS - Database Management System) протягом всього шляху розвитку комп'ютерної техніки вдосконалювалися, підтримуючи все більш складні рівні абстрактних даних, заданих користувачем, і забезпечуючи взаємодію компонентів, розподілених в глобальних мережах і поступово інтегруються з телекомунікаційними системами .
Історія розвитку комп'ютерної техніки - це історія безперервного руху від мови та рівня комунікації машини до рівня користувача. Якщо перші машини вимагали від користувача оформлення того, що йому потрібно (тобто написання програм), в машинних кодах, то мови програмування четвертого рівня (4 GLs) дозволяли кінцевим користувачам, які не є професійними програмістами, отримувати доступ до інформації без детального опису кожного кроку , але тільки з вбудованими зумовленими типами даних - наприклад, таблицями.
У разі реляційних баз даних важко представити які-небудь загальні рецепти по частині фізичного проектування. Тут надто багато залежить від використовуваної СУБД. Наприклад, при роботі з СУБД Ingres можна вибирати один із запропонованих способів фізичної організації відносин, при роботі з System R слід було б насамперед подумати про кластеризації відносин і необхідному наборі індексів і т.д. Тому я обмежуся питаннями логічного проектування реляційних баз даних, які істотні при використанні будь-якої реляційної СУБД.
Більш того, не буду торкатися дуже важливого аспекту проектування - визначення обмежень цілісності (за винятком обмеження первинного ключа). Справа в тому, що при використанні СУБД з розвиненими механізмами обмежень цілісності (наприклад, SQL-орієнтованих систем) важко запропонувати який-небудь загальний підхід до визначення обмежень цілісності. Ці обмеження можуть мати дуже загальний вигляд, і їх формулювання поки відноситься скоріше до галузі мистецтва, ніж інженерної майстерності. Найбільше, що пропонується з цього приводу в літературі, це автоматична перевірка несуперечності набору обмежень цілісності.
Кожній нормальній формі відповідає певний певний набір обмежень, і ставлення знаходиться в деякій нормальній формі, якщо задовольняє властивому їй набору обмежень. Прикладом набору обмежень є обмеження першої нормальної форми - значення всіх атрибутів відносини одна транзакція. Оскільки вимога першої нормальної форми є базовою вимогою класичної реляційної моделі даних, ми будемо вважати, що вихідний набір відносин вже відповідає цій вимозі.
У теорії реляційних баз даних звичайно виділяється наступна послідовність нормальних форм:
· Перша нормальна форма (1NF);
· Друга нормальна форма (2NF);
· Третя нормальна форма (3NF);
· Нормальна форма Бойса-Кодда (BCNF);
· Четверта нормальна форма (4NF);
· П'ята нормальна форма, або нормальна форма проекції-з'єднання (5NF або PJ / NF).
Основні властивості нормальних форм:
· Кожна наступна нормальна форма в деякому сенсі краще попередньої;
· При переході до наступної нормальної формі властивості попередніх нормальних властивостей зберігаються.
В основі процесу проектування лежить метод нормалізації, декомпозиція відносини, що знаходиться в попередній нормальній формі, в два або більше відносини, що задовольняють вимогам наступної нормальної форми.
Найбільш важливі на практиці нормальні форми відносин грунтуються на фундаментальному в теорії реляційних баз даних понятті функціональної залежності. Для подальшого викладу буде потрібно кілька визначень.
Визначення 1. Функціональна залежність
У відношенні R атрибут Y функціонально залежить від атрибуту X (X і Y можуть бути складовими) в тому і тільки в тому випадку, якщо кожному значенню X відповідає в точності одне значення Y: RX (r) RY
Визначення 2. Повна функціональна залежність
Функціональна залежність RX (r) RY називається повною, якщо атрибут Y не залежить функціонально від будь-якого точного підмножини X.
Визначення 3. Транзитивне функціональна залежність
Функціональна залежність RX (r) RY називається транзитивної, якщо існує такий атрибут Z, що є функціональні залежності RX (r) RZ і RZ (r) RY та відсутня функціональна залежність RZ -> RX (При відсутності останньої вимоги ми мали б "нецікаві "транзитивні залежності в будь-якому відношенні, що володіє декількома ключами.)
Визначення 4. Неключових атрибут
Неключових атрибутом називається будь-який атрибут відносини, що не входить до складу первинного ключа (зокрема, первинного).
Визначення 5. Взаємно незалежні атрибути
Два або більше атрибуту взаємно незалежні, якщо жоден з цих атрибутів не є функціонально залежним від інших.
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР (r) СПІВР_ЗАРП
СПІВР_НОМЕР (r) ВІД_НОМЕР
ВІД_НОМЕР (r) СПІВР_ЗАРП
СПІВР_НОМЕР, ПРО_НОМЕР (r) СПІВР_ЗАВДАН
Як видно, хоча первинним ключем є складовою атрибут СПІВР_НОМЕР, ПРО_НОМЕР, атрибути СПІВР_ЗАРП і ВІД_НОМЕР функціонально залежать від частини первинного ключа, атрибута СПІВР_НОМЕР. У результаті ми не зможемо вставити у відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ кортеж, що описує співробітника, який ще не виконує жодного проекту (первинний ключ не може містити невизначене значення). При видаленні кортежу ми не тільки руйнуємо зв'язок даного співробітника з даним проектом, але втрачаємо інформацію про те, що він працює в деякому відділі. При перекладі співробітника в інший відділ ми будемо змушені модифікувати всі кортежі, що описують цього співробітника, чи отримаємо неузгоджений результат. Такі неприємні явища називаються аномаліями схеми відношення. Вони усуваються шляхом нормалізації.
Визначення 6. Друга нормальна форма (в цьому визначенні передбачається, що єдиним ключем відношення є первинний ключ)
Відношення R знаходиться в другій нормальній формі (2NF) в тому і тільки в тому випадку, коли є 1NF, і кожен неключових атрибут повністю залежить від первинного ключа.
Можна провести наступну декомпозицію відносини СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ в два відношення СПІВРОБІТНИКИ-ВІДДІЛИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР)
Первинний ключ: СПІВР_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР (r) СПІВР_ЗАРП
СПІВР_НОМЕР (r) ВІД_НОМЕР
ВІД_НОМЕР (r) СПІВР_ЗАРП
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ: СПІВР_НОМЕР, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Кожне з цих двох відносин знаходиться в 2NF, і в них ліквідовані зазначені вище аномалії (легко перевірити, що всі зазначені операції виконуються без проблем).
Якщо припустити наявність кількох ключів, то визначення 6 прийме наступний вигляд:
Визначення 6 ~
Відношення R знаходиться в другій нормальній формі (2NF) в тому і тільки в тому випадку, коли воно знаходиться в 1NF, і кожен неключових атрибут повністю залежить від кожного ключа R.
Тут і далі ми не будемо наводити приклади для відносин з кількома ключами. Вони дуже громіздкі і відносяться до ситуацій, рідко зустрічається на практиці.
У результаті ми не зможемо занести до бази даних інформацію, що характеризує заробітну плату відділу, до тих пір, поки в цьому відділі не з'явиться хоча б один співробітник (первинний ключ не може містити невизначене значення). При видаленні кортежу, що описує останнього співробітника даного відділу, ми втратимо інформації про заробітну плату відділу. Щоб узгодженим чином змінити заробітну плату відділу, ми будемо змушені попередньо знайти всі кортежі, що описують співробітників цього відділу. Тобто щодо СОТРУДІКІ-ВІДДІЛИ як і раніше існують аномалії. Їх можна усунути шляхом подальшої нормалізації.
Визначення 7. Третя нормальна форма. (Знову визначення дається у припущенні існування єдиного ключа.)
Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо перебуває в 2NF і кожен неключових атрибут нетранзитивно залежить від первинного ключа.
Можна зробити декомпозицію відносини СПІВРОБІТНИКИ-ВІДДІЛИ в два відношення СПІВРОБІТНИКИ і ВІДДІЛИ:
СПІВРОБІТНИКИ (СПІВР_НОМЕР, ВІД_НОМЕР)
Первинний ключ: СПІВР_НОМЕР
Функціональні залежності: СПІВР_НОМЕР (r) ВІД_НОМЕР
ВІДДІЛИ (ВІД_НОМЕР, СПІВР_ЗАРП)
Первинний ключ: ВІД_НОМЕР
Функціональні залежності: ВІД_НОМЕР (r) СПІВР_ЗАРП
Кожне з цих двох відносин знаходиться в 3NF і вільно від зазначених аномалій.
Якщо відмовитися від того обмеження, що ставлення володіє єдиним ключем, то визначення 3NF прийме таку форму:
Визначення 7 ~
Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо перебуває в 1NF, і кожен неключових атрибут не є транзитивній залежним від будь-якого ключа R.
На практиці третій нормальна форма схем відносин достатня в більшості випадків, і приведенням до третьої нормальної формі процес проектування реляційної бази даних зазвичай закінчується. Хоча іноді продовжити процес нормалізації.
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, СОТР_ІМЯ, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Можливі ключі: СПІВР_НОМЕР, ПРО_НОМЕР СОТР_ІМЯ, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР (r) CОТР_ІМЯ
СПІВР_НОМЕР (r) ПРО_НОМЕР
СОТР_ІМЯ (r) CОТР_НОМЕР
СОТР_ІМЯ (r) ПРО_НОМЕР
СПІВР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
СОТР_ІМЯ, ПРО_НОМЕР (r) CОТР_ЗАДАН
У цьому прикладі передбачається, що особистість співробітника повністю визначається як його номером, так і ім'ям (це знову не дуже життєве припущення, але достатня для прикладу).
Відповідно до визначення 7 ~ ставлення СПІВРОБІТНИКИ-ПРОЕКТИ знаходиться в 3NF. Однак той факт, що є функціональні залежності атрибутів відносини від атрибута, що є частиною первинного ключа, призводить до аномалій. Наприклад, для того, щоб змінити ім'я співробітника з даним номером узгодженим чином, нам буде потрібно модифікувати всі кортежі, що включають його номер.
Визначення 8. Детермінант
Детермінант - будь-який атрибут, від якого повністю функціонально залежить деякий інший атрибут.
Визначення 9. Нормальна форма Бойса-Кодда
Відношення R знаходиться в нормальній формі Бойса-Кодда (BCNF) в тому і тільки в тому випадку, якщо кожен детермінант є можливим ключем.
Очевидно, що ця вимога не виконана для відносини СПІВРОБІТНИКИ-ПРОЕКТИ. Можна зробити його декомпозицію до відносин СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ (СПІВР_НОМЕР, СОТР_ІМЯ)
Можливі ключі: СПІВР_НОМЕР, СОТР_ІМЯ
Функціональні залежності:
СПІВР_НОМЕР (r) CОТР_ІМЯ
СОТР_ІМЯ (r) СПІВР_НОМЕР
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Можливий ключ: СПІВР_НОМЕР, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Можлива альтернативна декомпозиція, якщо вибрати за основу СОТР_ІМЯ. Отримувані відносини СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ знаходяться в BCNF, і їм не властиві зазначені аномалії.
ПРОЕКТИ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Ставлення ПРОЕКТИ містить номери проектів, для кожного проекту список співробітників, які можуть виконувати проект, і список завдань, передбачених проектом. Співробітники можуть брати участь у кількох проектах, і різні проекти можуть включати однакові завдання.
Кожен кортеж відносини пов'язує певний проект зі співробітником, які беруть участь у цьому проекті, і завданням, який співробітник виконує в рамках даного проекту (я припускаю, що будь-який співробітник, що бере участь у проекті, виконує всі завдання, передбачені цим проектом). Унаслідок сформульованих вище умов єдиним можливим ключем відношення є складовою атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, і немає ніяких інших детермінантів. Отже, ставлення ПРОЕКТИ знаходиться в BCNF. Але при цьому воно має недоліками: якщо, наприклад, деякий співробітник приєднується до даного проекту, необхідно вставити у відношення ПРОЕКТИ стільки кортежів, скільки завдань у ньому передбачено.
Державна освітня установа
вищої професійної освіти
РОСІЙСЬКИЙ ДЕРЖАВНИЙ ГУМАНІТАРНИЙ УНІВЕРСИТЕТ
ІНСТИТУТ ІНФОРМАЦІЙНИХ НАУК І ТЕХНОЛОГІЙ БЕЗПЕКИ
Кафедра загальної інформатики
ГУБАРЄВ СЕРГІЙ ВОЛОДИМИРОВИЧ
КОНТРОЛЬНА РОБОТА З ДИСЦИПЛІНИ
«БАЗИ ДАНИХ»
Проектування реляційних баз даних
Екстерн 3 РОКИ НАВЧАННЯ (4-річного терміну навчання)
ГРУПА Б (інформаційна сфера)
Науковий керівник
викладач
Туляков С. П.
Москва
2005
ПЛАН
ВСТУП 3
ОСНОВНА ЧАСТИНА
1. Проектування реляційних баз даних
з використанням нормалізації 5
1.1. Друга нормальна форма 7
1.2. Третя нормальна форма 9
1.3. Нормальна форма Бойса-Кодда 10
1.4. Четверта нормальна форма 12
1.5. П'ята нормальна форма 13
2. Семантичне моделювання даних, ER-діаграми 15
2.1. Семантичні моделі даних 16
2.2. Основні поняття моделі Entity-Relationship
(Сутність-зв'язку) 17
2.3. Нормальні форми ER-схем 20
2.4. Більш складні елементи ER-моделі 20
2.5. Отримання реляційної схеми з ER-схеми 23
ВИСНОВОК 27
СПИСОК ЛІТЕРАТУРИ 28
ВСТУП
Управління інформацією завжди було основною сферою застосування комп'ютерів, і, треба думати, буде грати ще більшу роль у майбутньому. Бази даних та системи управління ними (СУБД, DBMS - Database Management System) протягом всього шляху розвитку комп'ютерної техніки вдосконалювалися, підтримуючи все більш складні рівні абстрактних даних, заданих користувачем, і забезпечуючи взаємодію компонентів, розподілених в глобальних мережах і поступово інтегруються з телекомунікаційними системами .
Історія розвитку комп'ютерної техніки - це історія безперервного руху від мови та рівня комунікації машини до рівня користувача. Якщо перші машини вимагали від користувача оформлення того, що йому потрібно (тобто написання програм), в машинних кодах, то мови програмування четвертого рівня (4 GLs) дозволяли кінцевим користувачам, які не є професійними програмістами, отримувати доступ до інформації без детального опису кожного кроку , але тільки з вбудованими зумовленими типами даних - наприклад, таблицями.
У разі реляційних баз даних важко представити які-небудь загальні рецепти по частині фізичного проектування. Тут надто багато залежить від використовуваної СУБД. Наприклад, при роботі з СУБД Ingres можна вибирати один із запропонованих способів фізичної організації відносин, при роботі з System R слід було б насамперед подумати про кластеризації відносин і необхідному наборі індексів і т.д. Тому я обмежуся питаннями логічного проектування реляційних баз даних, які істотні при використанні будь-якої реляційної СУБД.
Більш того, не буду торкатися дуже важливого аспекту проектування - визначення обмежень цілісності (за винятком обмеження первинного ключа). Справа в тому, що при використанні СУБД з розвиненими механізмами обмежень цілісності (наприклад, SQL-орієнтованих систем) важко запропонувати який-небудь загальний підхід до визначення обмежень цілісності. Ці обмеження можуть мати дуже загальний вигляд, і їх формулювання поки відноситься скоріше до галузі мистецтва, ніж інженерної майстерності. Найбільше, що пропонується з цього приводу в літературі, це автоматична перевірка несуперечності набору обмежень цілісності.
1. Проектування реляційних баз даних З ВИКОРИСТАННЯМ нормалізації
Спочатку я розгляну класичний підхід, при якому весь процес проектування проводиться в термінах реляційної моделі даних методом послідовних наближень до задовільного набору схем відносин. Вихідною точкою є уявлення предметної області у вигляді одного або декількох відносин, і на кожному кроці проектування проводиться деякий набір схем відносин, що володіють кращими властивостями. Процес проектування являє собою процес нормалізації схем відносин, причому кожна наступна нормальна форма має властивості кращими, ніж попередня.Кожній нормальній формі відповідає певний певний набір обмежень, і ставлення знаходиться в деякій нормальній формі, якщо задовольняє властивому їй набору обмежень. Прикладом набору обмежень є обмеження першої нормальної форми - значення всіх атрибутів відносини одна транзакція. Оскільки вимога першої нормальної форми є базовою вимогою класичної реляційної моделі даних, ми будемо вважати, що вихідний набір відносин вже відповідає цій вимозі.
У теорії реляційних баз даних звичайно виділяється наступна послідовність нормальних форм:
· Перша нормальна форма (1NF);
· Друга нормальна форма (2NF);
· Третя нормальна форма (3NF);
· Нормальна форма Бойса-Кодда (BCNF);
· Четверта нормальна форма (4NF);
· П'ята нормальна форма, або нормальна форма проекції-з'єднання (5NF або PJ / NF).
Основні властивості нормальних форм:
· Кожна наступна нормальна форма в деякому сенсі краще попередньої;
· При переході до наступної нормальної формі властивості попередніх нормальних властивостей зберігаються.
В основі процесу проектування лежить метод нормалізації, декомпозиція відносини, що знаходиться в попередній нормальній формі, в два або більше відносини, що задовольняють вимогам наступної нормальної форми.
Найбільш важливі на практиці нормальні форми відносин грунтуються на фундаментальному в теорії реляційних баз даних понятті функціональної залежності. Для подальшого викладу буде потрібно кілька визначень.
Визначення 1. Функціональна залежність
У відношенні R атрибут Y функціонально залежить від атрибуту X (X і Y можуть бути складовими) в тому і тільки в тому випадку, якщо кожному значенню X відповідає в точності одне значення Y: RX (r) RY
Визначення 2. Повна функціональна залежність
Функціональна залежність RX (r) RY називається повною, якщо атрибут Y не залежить функціонально від будь-якого точного підмножини X.
Визначення 3. Транзитивне функціональна залежність
Функціональна залежність RX (r) RY називається транзитивної, якщо існує такий атрибут Z, що є функціональні залежності RX (r) RZ і RZ (r) RY та відсутня функціональна залежність RZ -> RX (При відсутності останньої вимоги ми мали б "нецікаві "транзитивні залежності в будь-якому відношенні, що володіє декількома ключами.)
Визначення 4. Неключових атрибут
Неключових атрибутом називається будь-який атрибут відносини, що не входить до складу первинного ключа (зокрема, первинного).
Визначення 5. Взаємно незалежні атрибути
Два або більше атрибуту взаємно незалежні, якщо жоден з цих атрибутів не є функціонально залежним від інших.
1.1. Друга нормальна форма
Розглянемо наступний приклад схеми відносини:СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ:
СПІВР_НОМЕР, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР (r) СПІВР_ЗАРП
СПІВР_НОМЕР (r) ВІД_НОМЕР
ВІД_НОМЕР (r) СПІВР_ЗАРП
СПІВР_НОМЕР, ПРО_НОМЕР (r) СПІВР_ЗАВДАН
Як видно, хоча первинним ключем є складовою атрибут СПІВР_НОМЕР, ПРО_НОМЕР, атрибути СПІВР_ЗАРП і ВІД_НОМЕР функціонально залежать від частини первинного ключа, атрибута СПІВР_НОМЕР. У результаті ми не зможемо вставити у відношення СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ кортеж, що описує співробітника, який ще не виконує жодного проекту (первинний ключ не може містити невизначене значення). При видаленні кортежу ми не тільки руйнуємо зв'язок даного співробітника з даним проектом, але втрачаємо інформацію про те, що він працює в деякому відділі. При перекладі співробітника в інший відділ ми будемо змушені модифікувати всі кортежі, що описують цього співробітника, чи отримаємо неузгоджений результат. Такі неприємні явища називаються аномаліями схеми відношення. Вони усуваються шляхом нормалізації.
Визначення 6. Друга нормальна форма (в цьому визначенні передбачається, що єдиним ключем відношення є первинний ключ)
Відношення R знаходиться в другій нормальній формі (2NF) в тому і тільки в тому випадку, коли є 1NF, і кожен неключових атрибут повністю залежить від первинного ключа.
Можна провести наступну декомпозицію відносини СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ в два відношення СПІВРОБІТНИКИ-ВІДДІЛИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, СПІВР_ЗАРП, ВІД_НОМЕР)
Первинний ключ: СПІВР_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР (r) СПІВР_ЗАРП
СПІВР_НОМЕР (r) ВІД_НОМЕР
ВІД_НОМЕР (r) СПІВР_ЗАРП
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Первинний ключ: СПІВР_НОМЕР, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Кожне з цих двох відносин знаходиться в 2NF, і в них ліквідовані зазначені вище аномалії (легко перевірити, що всі зазначені операції виконуються без проблем).
Якщо припустити наявність кількох ключів, то визначення 6 прийме наступний вигляд:
Визначення 6 ~
Відношення R знаходиться в другій нормальній формі (2NF) в тому і тільки в тому випадку, коли воно знаходиться в 1NF, і кожен неключових атрибут повністю залежить від кожного ключа R.
Тут і далі ми не будемо наводити приклади для відносин з кількома ключами. Вони дуже громіздкі і відносяться до ситуацій, рідко зустрічається на практиці.
1.2. Третя нормальна форма
Розглянемо ще раз ставлення СПІВРОБІТНИКИ-ВІДДІЛИ, що знаходиться в 2NF. Зауважимо, що функціональна залежність СПІВР_НОМЕР (r) СПІВР_ЗАРП є транзитивної; вона є наслідком функціональних залежностей СПІВР_НОМЕР (r) ВІД_НОМЕР і ВІД_НОМЕР (r) СПІВР_ЗАРП. Іншими словами, заробітна плата співробітника насправді є характеристикою не співробітника, а відділу, в якому він працює (це не дуже природне припущення, але достатня для прикладу).У результаті ми не зможемо занести до бази даних інформацію, що характеризує заробітну плату відділу, до тих пір, поки в цьому відділі не з'явиться хоча б один співробітник (первинний ключ не може містити невизначене значення). При видаленні кортежу, що описує останнього співробітника даного відділу, ми втратимо інформації про заробітну плату відділу. Щоб узгодженим чином змінити заробітну плату відділу, ми будемо змушені попередньо знайти всі кортежі, що описують співробітників цього відділу. Тобто щодо СОТРУДІКІ-ВІДДІЛИ як і раніше існують аномалії. Їх можна усунути шляхом подальшої нормалізації.
Визначення 7. Третя нормальна форма. (Знову визначення дається у припущенні існування єдиного ключа.)
Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо перебуває в 2NF і кожен неключових атрибут нетранзитивно залежить від первинного ключа.
Можна зробити декомпозицію відносини СПІВРОБІТНИКИ-ВІДДІЛИ в два відношення СПІВРОБІТНИКИ і ВІДДІЛИ:
СПІВРОБІТНИКИ (СПІВР_НОМЕР, ВІД_НОМЕР)
Первинний ключ: СПІВР_НОМЕР
Функціональні залежності: СПІВР_НОМЕР (r) ВІД_НОМЕР
ВІДДІЛИ (ВІД_НОМЕР, СПІВР_ЗАРП)
Первинний ключ: ВІД_НОМЕР
Функціональні залежності: ВІД_НОМЕР (r) СПІВР_ЗАРП
Кожне з цих двох відносин знаходиться в 3NF і вільно від зазначених аномалій.
Якщо відмовитися від того обмеження, що ставлення володіє єдиним ключем, то визначення 3NF прийме таку форму:
Визначення 7 ~
Відношення R знаходиться в третій нормальній формі (3NF) в тому і тільки в тому випадку, якщо перебуває в 1NF, і кожен неключових атрибут не є транзитивній залежним від будь-якого ключа R.
На практиці третій нормальна форма схем відносин достатня в більшості випадків, і приведенням до третьої нормальної формі процес проектування реляційної бази даних зазвичай закінчується. Хоча іноді продовжити процес нормалізації.
1.3. Нормальна форма Бойса-Кодда
Розглянемо наступний приклад схеми відносини:СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, СОТР_ІМЯ, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Можливі ключі: СПІВР_НОМЕР, ПРО_НОМЕР СОТР_ІМЯ, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР (r) CОТР_ІМЯ
СПІВР_НОМЕР (r) ПРО_НОМЕР
СОТР_ІМЯ (r) CОТР_НОМЕР
СОТР_ІМЯ (r) ПРО_НОМЕР
СПІВР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
СОТР_ІМЯ, ПРО_НОМЕР (r) CОТР_ЗАДАН
У цьому прикладі передбачається, що особистість співробітника повністю визначається як його номером, так і ім'ям (це знову не дуже життєве припущення, але достатня для прикладу).
Відповідно до визначення 7 ~ ставлення СПІВРОБІТНИКИ-ПРОЕКТИ знаходиться в 3NF. Однак той факт, що є функціональні залежності атрибутів відносини від атрибута, що є частиною первинного ключа, призводить до аномалій. Наприклад, для того, щоб змінити ім'я співробітника з даним номером узгодженим чином, нам буде потрібно модифікувати всі кортежі, що включають його номер.
Визначення 8. Детермінант
Детермінант - будь-який атрибут, від якого повністю функціонально залежить деякий інший атрибут.
Визначення 9. Нормальна форма Бойса-Кодда
Відношення R знаходиться в нормальній формі Бойса-Кодда (BCNF) в тому і тільки в тому випадку, якщо кожен детермінант є можливим ключем.
Очевидно, що ця вимога не виконана для відносини СПІВРОБІТНИКИ-ПРОЕКТИ. Можна зробити його декомпозицію до відносин СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ:
СПІВРОБІТНИКИ (СПІВР_НОМЕР, СОТР_ІМЯ)
Можливі ключі: СПІВР_НОМЕР, СОТР_ІМЯ
Функціональні залежності:
СПІВР_НОМЕР (r) CОТР_ІМЯ
СОТР_ІМЯ (r) СПІВР_НОМЕР
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР, СПІВР_ЗАВДАН)
Можливий ключ: СПІВР_НОМЕР, ПРО_НОМЕР
Функціональні залежності:
СПІВР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Можлива альтернативна декомпозиція, якщо вибрати за основу СОТР_ІМЯ. Отримувані відносини СПІВРОБІТНИКИ і СПІВРОБІТНИКИ-ПРОЕКТИ знаходяться в BCNF, і їм не властиві зазначені аномалії.
1.4. Четверта нормальна форма
Розглянемо приклад такої схеми відносини:ПРОЕКТИ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Ставлення ПРОЕКТИ містить номери проектів, для кожного проекту список співробітників, які можуть виконувати проект, і список завдань, передбачених проектом. Співробітники можуть брати участь у кількох проектах, і різні проекти можуть включати однакові завдання.
Кожен кортеж відносини пов'язує певний проект зі співробітником, які беруть участь у цьому проекті, і завданням, який співробітник виконує в рамках даного проекту (я припускаю, що будь-який співробітник, що бере участь у проекті, виконує всі завдання, передбачені цим проектом). Унаслідок сформульованих вище умов єдиним можливим ключем відношення є складовою атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, і немає ніяких інших детермінантів. Отже, ставлення ПРОЕКТИ знаходиться в BCNF. Але при цьому воно має недоліками: якщо, наприклад, деякий співробітник приєднується до даного проекту, необхідно вставити у відношення ПРОЕКТИ стільки кортежів, скільки завдань у ньому передбачено.
Визначення 10. Багатозначні залежності
У відношенні R (A, B, C) існує багатозначна залежність RA (r) (r) RB в тому і тільки в тому випадку, якщо безліч значень B, відповідне парі значень A і C, залежить тільки від A і не залежить від С . Стосовно ПРОЕКТИ існують наступні дві багатозначні залежності:
ПРО_НОМЕР (r) (r) ПРО_СОТР і ПРО_НОМЕР (r) (r) ПРО_ЗАДАН
Легко показати, що в загальному випадку відносно R (A, B, C) існує багатозначна залежність RA (r) (r) RB в тому і тільки в тому випадку, коли існує багатозначна залежність RA (r) (r) RC
Подальша нормалізація відносин, подібних відношенню ПРОЕКТИ, грунтується на наступній теоремі:
Теорема Фейджин: відношення R (A, B, C) можна спроектувати без втрат у відносини R1 (A, B) і R2 (A, C) в тому і тільки в тому випадку, коли існує MVD A (r) (r) B | C.
Під проектуванням без втрат розуміється такий спосіб декомпозиції відносини, при якому початкове ставлення повністю і без надмірності відновлюється шляхом природного з'єднання отриманих відносин.
Визначення 11. Четверта нормальна форма
Відношення R знаходиться в четвертій нормальній формі (4NF) в тому і тільки в тому випадку, якщо у випадку існування багатозначною залежності A (r) (r) B всі інші атрибути R функціонально залежать від A.
У нашому прикладі можна зробити декомпозицію відносини ПРОЕКТИ в два відношення ПРОЕКТИ-СПІВРОБІТНИКИ і ПРОЕКТИ-ЗАВДАННЯ:
ПРОЕКТИ-СПІВРОБІТНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТИ-ЗАВДАННЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Обидва ці відносини перебувають у 4NF і вільні від зазначених аномалій.
Розглянемо, наприклад, ставлення
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СПІВР_НОМЕР, ВІД_НОМЕР, ПРО_НОМЕР)
Припустимо, що один і той же працівник може працювати в декількох відділах і працювати в кожному відділі над кількома проектами. Первинним ключем цього відношення є повна сукупність його атрибутів, відсутні функціональні та багатозначні залежності.
Тому ставлення знаходиться в 4NF. Однак у ньому можуть існувати аномалії, які можна усунути шляхом декомпозиції в три відносини.
Визначення 12. Залежність з'єднання
Відношення R (X, Y, ..., Z) задовольняє залежності з'єднання * (X, Y, ..., Z) в тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y, ..., Z.
Визначення 13. П'ята нормальна форма
Відношення R знаходиться в п'ятій нормальній формі (нормальної формі проекції-з'єднання - PJ / NF) в тому і тільки в тому випадку, коли будь-яка залежність з'єднання в R випливає з існування деякого можливого ключа в R.
Введемо наступні імена складових атрибутів:
СО = {СПІВР_НОМЕР, ВІД_НОМЕР}
СП = {СПІВР_НОМЕР, ПРО_НОМЕР}
ВП = {ВІД_НОМЕР, ПРО_НОМЕР}
Припустимо, що відносно СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ існує залежність з'єднання: * (СО, СП, ВП)
На прикладах легко показати, що при вставках і видаленнях кортежів можуть виникнути проблеми. Їх можна усунути шляхом декомпозиції вихідного стосунки в три нових відносини:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, ВІД_НОМЕР)
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР)
ВІДДІЛИ-ПРОЕКТИ (ВІД_НОМЕР, ПРО_НОМЕР)
П'ята нормальна форма - це остання нормальна форма, яку можна отримати шляхом декомпозиції. Її умови досить нетривіальні, і на практиці 5NF не використовується. Зауважимо, що залежність сполуки є узагальненням як багатозначної залежності, так і функціональної залежності.
При цьому виявляється обмеженість реляційної моделі даних в таких аспектах:
· Модель не надає достатніх коштів для подання змісту даних. Семантика реальної предметної області повинна незалежним від моделі способом представлятися в голові проектувальника. Зокрема, це стосується згадуваної нами проблемі подання обмежень цілісності.
· Для багатьох додатків важко моделювати предметну область на основі плоских таблиць. У ряді випадків на самій початковій стадії проектування проектувальнику доводиться виробляти насильство над собою, щоб описати предметну область у вигляді однієї (можливо, навіть ненормалізованном) таблиці.
· Хоча весь процес проектування відбувається на основі врахування залежностей, реляційна модель не надає будь-яких засобів для подання цих залежностей.
· Незважаючи на те, що процес проектування починається з виділення деяких істотних для програми об'єктів предметної області ("сутностей") та виявлення зв'язків між цими сутностями, реляційна модель даних не пропонує будь-якого апарату для поділу сутностей і зв'язків.
Перш, ніж ми коротко розглянемо особливості однієї з поширених семантичних моделей, зупинимося на їх можливі застосування.
Найбільш часто на практиці семантичне моделювання використовується на першій стадії проектування бази даних. При цьому в термінах семантичної моделі проводиться концептуальна схема бази даних, яка потім вручну концептуальна схема перетвориться до реляційної (або який-небудь інший) схемою. Цей процес виконується під управлінням методик, в яких досить чітко обумовлено всі етапи такого перетворення.
Менш часто реалізується автоматизована компіляція концептуальної схеми в реляційну. При цьому відомі два підходи: на основі явного подання концептуальної схеми як вихідної інформації для компілятора і побудови інтегрованих систем проектування з автоматизованим створенням концептуальної схеми на основі інтерв'ю з експертами предметної області. І в тому, і в іншому випадку в результаті виробляється реляційна схема бази даних в третій нормальній формі (більш точно слід було б сказати, що авторові невідомі системи, що забезпечують більш високий рівень нормалізації).
Нарешті, третя можливість, яка ще не вийшла (або тільки виходить) за межі дослідницьких та експериментальних проектів, - це робота з базою даних у семантичній моделі, тобто СУБД, засновані на семантичних моделях даних. При цьому знову розглядаються два варіанти: забезпечення для користувача інтерфейсу на основі семантичної моделі даних з автоматичним відображенням конструкцій в реляційну модель даних (це завдання приблизно такого ж рівня складності, як автоматична компіляція концептуальної схеми бази даних в реляційну схему) і пряма реалізація СУБД, заснована на будь-якої семантичної моделі даних. Найбільш близько до другого підходу знаходяться сучасні об'єктно-орієнтовані СУБД, моделі даних яких за багатьма параметрами близькі до семантичних моделей (хоча в деяких аспектах вони більш потужні, а в деяких - слабші).
На використанні різновидів ER-моделі засновано більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі отримали широке поширення в системах CASE, що підтримують автоматизоване проектування реляційних баз даних. Серед безлічі різновидів ER-моделей одна з найбільш розвинених застосовується в системі CASE фірми ORACLE. Її ми і розглянемо. Більш точно, ми зосередимося на структурній частині цієї моделі.
Основними поняттями ER-моделі є сутність, зв'язок та атрибут.
Сутність - це реальний або представлений об'єкт, інформація про який повинна зберігатися і бути доступна. У діаграмах ER-моделі сутність представляється у вигляді прямокутника, що містить ім'я суті. При цьому ім'я сутності - це ім'я типу, а не деякого конкретного екземпляра цього типу. Для більшої виразності і кращого розуміння ім'я суті може супроводжуватися прикладами конкретних об'єктів цього типу.
Нижче зображено сутність АЕРОПОРТ з зразковими об'єктами Шереметьєво і Хітроу:
Кожен екземпляр суті повинен бути відрізнити від будь-якого іншого примірника тієї ж суті (ця вимога в деякому роді аналогічно вимогу відсутності кортежів-дублікатів в реляційних таблицях).
Зв'язок - це графічно зображається асоціація, що встановлюється між двома сутностями. Ця асоціація завжди є бінарною і може існувати між двома різними сутностями або між сутністю і їй же самій (рекурсивна зв'язок). У будь-якому зв'язку виділяються два кінці (відповідно до існуючої парою пов'язують сутностей), на кожному з яких вказується ім'я кінця зв'язку, ступінь кінця зв'язку (скільки екземплярів даної суті пов'язується), обов'язковість зв'язку (тобто чи будь-який примірник даної суті повинен брати участь в зв'язку з цим).
Зв'язок представляється у вигляді лінії, що зв'язує дві сутності або веде від суті до неї ж самої. При це в місці "стикування" зв'язку з сутністю використовуються триточковий вхід в прямокутник суті, якщо для цієї сутності у зв'язку можуть використовуватися багато (many) примірників суті, і одноточковий вхід, якщо у зв'язку може брати участь тільки один екземпляр сутності. Обов'язковий кінець зв'язку зображується суцільною лінією, а необов'язковий - переривчастою лінією.
Як і сутність, зв'язок - це типове поняття, усі примірники обох пар пов'язують сутностей підкоряються правилам зв'язування.
У зображеному нижче прикладі зв'язок між сутностями КВИТОК і ПАСАЖИР пов'язує квитки і пасажирів. При тому кінець сутності з ім'ям "для" дозволяє пов'язувати з одним пасажиром більше одного квитка, причому кожен квиток повинен бути пов'язаний з яким-небудь пасажиром. Кінець сутності з ім'ям "має" означає, що кожен квиток може належати тільки одному пасажиру, причому пасажир не зобов'язаний мати хоча б один квиток.
Лаконічній усній трактуванням зображеної діаграми є наступна:
· Кожен КВИТОК призначений для одного і тільки одного ПАСАЖИРА;
· Кожен ПАСАЖИР може мати один або більше КВИТКІВ.
На наступному прикладі зображена рекурсивна зв'язок, що зв'язує сутність ЛЮДИНА з нею самою. Кінець зв'язку з ім'ям "син" визначає той факт, що в одного батька може бути більш ніж один син. Кінець зв'язку з ім'ям "батько" означає, що не у кожної людини можуть бути сини.
Лаконічній усній трактуванням зображеної діаграми є наступна:
· Кожен ЛЮДИНА є сином одного і тільки одного ЛЮДИНИ;
· Кожен ЛЮДИНА може бути батьком для одного або більше ЛЮДЕЙ ("людина").
Атрибутом суті є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики або вираження стану сутності. Імена атрибутів заносяться в прямокутник, що зображає сутність, під ім'ям сутності і зображуються малими буквами, можливо, з прикладами.
Приклад:
Унікальним ідентифікатором суті є атрибут, комбінація атрибутів, комбінація зв'язків або комбінація зв'язків та атрибутів, унікально відрізняє будь-який екземпляр сутності від інших екземплярів сутності того ж типу.
У першій нормальній формі ER-схеми усуваються повторювані атрибути або групи атрибутів, тобто виробляється виявлення неявних сутностей, "замаскованих" під атрибути.
У другій нормальній формі усуваються атрибути, що залежать тільки від частини унікального ідентифікатора. Ця частина унікального ідентифікатора визначає окрему сутність.
У третій нормальній формі усуваються атрибути, які залежать від атрибутів, що не входять в унікальний ідентифікатор. Ці атрибути є основою окремої сутності.
2.4. Більш складні елементи ER-моделі
Ми зупинилися лише на самих основних і найбільш очевидних поняттях ER-моделі даних. До більш складних елементів моделі відносяться наступні:
· Підтипи і супертіпи сутностей. Як у мовах програмування з розвиненими типовими системами (наприклад, в мовах об'єктно-орієнтованого програмування), вводиться можливість наслідування типу сутності, виходячи з одного або декількох супертіп. Цікаві нюанси пов'язані з необхідністю графічного зображення цього механізму.
· Зв'язки "many-to-many". Іноді буває необхідно пов'язувати сутності таким чином, що з обох кінців зв'язку можуть бути присутні кілька примірників сутності (наприклад, всі члени кооперативу спільно володіють майном кооперативу). Для цього вводиться різновид зв'язку "багато-со-багатьма".
· Уточнюємо ступеня зв'язку. Іноді буває корисно визначити можливу кількість примірників суті, беруть участь у даній зв'язку (наприклад, службовцю дозволяється брати участь не більше, ніж у трьох проектах одночасно). Для вираження цього семантичного обмеження дозволяється вказувати на кінці зв'язку її максимальну або обов'язкову ступінь.
· Каскадні видалення екземплярів сутностей. Деякі зв'язки бувають настільки сильними (звичайно, у разі зв'язку "один-до-багатьох"), що при видаленні опорного примірника сутності (відповідного кінця зв'язку "один") потрібно видалити і всі екземпляри сутності, відповідні кінця зв'язку "багато хто". Відповідну вимогу "каскадного видалення" можна сформулювати при визначенні сутності.
· Домени. Як і у випадку реляційної моделі даних буває корисна можливість визначення потенційно допустимого безлічі значень атрибута сутності (домену).
Ці та інші більш складні елементи моделі даних "Сутність-Зв'язки" роблять її істотно більш потужною, але одночасно трохи ускладнюють її використання. Звичайно, при реальному використанні ER-діаграм для проектування баз даних необхідно ознайомитися з усіма можливостями.
Сутність може бути розщеплена на два або більше взаємно виключають підтипу, кожен з яких включає загальні атрибути та / або зв'язку. Ці загальні атрибути та / або зв'язку явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути та / або зв'язку. У принципі подтіпізація може тривати більш низьких рівнях, але досвід показує, що в більшості випадків виявляється достатньо двох-трьох рівнів.
Сутність, на основі якої визначаються підтипи, називається супертіп. Підтипи повинні утворювати повне безліч, тобто будь-який екземпляр супертіпа повинен ставитися до деякого підтипу. Іноді для повноти доводиться визначати додатковий підтип ІНШІ.
Приклад: супертіп ЛІТАЛЬНИЙ АПАРАТ
Як і належить це читати? Від супертіпа: ЛІТАЛЬНИЙ АПАРАТ, який повинен бути аеропланів, гелікоптерів, ПТІЦЕЛЕТОМ або інших літальних апаратів. Від підтипи: ВЕРТОЛІТ, який відноситься до типу літального апарата. Від підтипу, який є одночасно супертіпа: Аероплан, який відноситься до типу літального апарата і повинен бути планера чи моторний літак.
Іноді зручно мати два або більше різних розбиття сутності на підтипи. Наприклад, сутність ЛЮДИНА може бути розбита на підтипи за професійною ознакою (ПРОГРАММИСТ, доярки і т.д.), а може - за статевою ознакою (чоловіки, жінки).
2.5. Отримання реляційної схеми з ER-схеми
Крок 1. Кожна проста сутність перетворюється в таблицю. Проста сутність - сутність, яка не є підтипом і не має підтипів. Ім'я суті стає ім'ям таблиці.
Крок 2. Кожен атрибут стає можливим стовпцем з тим же ім'ям, може вибиратися більш точний формат. Стовпці, відповідні необов'язковим атрибутам, можуть містити невизначені значення; стовпці, що відповідають обов'язковим атрибутам, - не можуть.
Крок 3. Компоненти унікального ідентифікатора суті перетворюються на первинний ключ таблиці. Якщо є кілька можливих унікальних ідентифікаторів, вибирається найбільш використовуваний. Якщо до складу унікального ідентифікатора входять зв'язку, до числа стовпців первинного ключа додається копія унікального ідентифікатора суті, що знаходиться на далекому кінці зв'язку (цей процес може тривати рекурсивно). Для іменування цих стовпців використовуються імена решт зв'язків та / або імена сутностей.
Крок 4. Зв'язки багато-до-одного (і один-до-одного) стають зовнішніми ключами. Тобто робиться копія унікального ідентифікатора з кінця зв'язку "один", і відповідні стовпці складають зовнішній ключ. Необов'язкові зв'язку відповідають стовпцям, допускає невизначені значення; обов'язкові зв'язку - стовпцях, що не допускає невизначені значення.
Крок 5. Індекси створюються для первинного ключа (унікальний індекс), зовнішніх ключів і тих атрибутів, на яких передбачається в основному базувати запити.
Крок 6. Якщо у концептуальній схемі були присутні підтипи, то можливі два способи:
· Всі підтипи в одній таблиці (а)
· Для кожного підтипу - окрема таблиця (б)
При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертіпа, а для підтипів можуть створюватися подання. У таблицю додається принаймні один стовпець, що містить код ТИПУ, він стає частиною первинного ключа.
При використанні методу (б) для кожного підтипу першого рівня (для більш нижніх - подання) супертіп відтворюється за допомогою представлення UNION (з усіх таблиць підтипів вибираються загальні стовпці - стовпці супертіпа).
Крок 7. Є два способи роботи при наявності виключають зв'язків:
· Загальний домен (а)
· Явні зовнішні ключі (б)
Якщо залишаються зовнішні ключі все в одному домені, тобто мають загальний формат (спосіб (а)), то створюються два стовпці: ідентифікатор зв'язку та ідентифікатор сутності. Стовпець ідентифікатора зв'язку використовується для розрізнення зв'язків, що покриваються дугою винятку. Стовпець ідентифікатора суті використовується для зберігання значень унікального ідентифікатора суті на дальньому кінці відповідної зв'язку.
Якщо результуючі зовнішні ключі не належать до одного домену, то для кожного зв'язку, покривається дугою винятку, створюються явні стовпці зовнішніх ключів; всі ці стовпці можуть містити невизначені значення.
Альтернативні моделі сутностей:
Варіант 1 (поганий)
Варіант 2 (істотно краще, якщо підтипи дійсно існують)
Варіант 3 (годиться при наявності осмисленого супертіпа D).
ВИСНОВОК
При проектуванні бази даних вирішуються дві основні проблеми:
1. Яким чином відобразити об'єкти предметної області в абстрактні об'єкти моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості кращим (ефективним, зручним і т.д.)? Часто цю проблему називають проблемою логічного проектування баз даних.
2. Як забезпечити ефективність виконання запитів до бази даних, тобто яким чином, маючи на увазі особливості конкретної системи управління базами даних, розташувати дані у зовнішній пам'яті, створення якихось додаткових структур (наприклад, індексів) вимагати і т.д.? Цю проблему називають проблемою фізичного проектування баз даних.
Проблема проектування реляційної бази даних складається в обгрунтованому прийнятті рішень про те, з яких відносин повинна складатися база даних і які атрибути мають бути у цих відносин.
СПИСОК ЛІТЕРАТУРИ
1. Гончаров А. «Microsoft Access ХР». - СПб: Питер, 2003
2. Горєв А., Макашарипов С, Ахаян Р. Ефективна робота із СУБД. СПб, «Пітер», 2002
3. Джексон Г. Проектування реляціоннних баз даних для використання з ЕОМ: Переклад з англійської. М.: Мир, 1991,
4. Кирій В.Г. Інформатика. Навчальний посібник - К.: ІРГТ, 1998
5. Ковалевська Є.В., Волосков Н.І., Григоренко Г.П., Желнінскій Г.С., Технологія реалізації на ЕОМ регламентних задач АСУ - М.: 1983
6. Ломтадзе В.В., Шишкіна Л.П. Інформатика. Навчальний посібник. Іркутськ: ІРГТ, 1999
7. Подільський В.І., Григоренко Г.П., Щербакова Н.С., Дік В.В. Обробка облікової інформації на ПЕОМ - М.: МЕСИ, 1993
8. Потапкин А.В. MS Visual Basic для пакету Microsoft Office. М, «Еком», 2004
9. Симонович С.В. та ін Інформатика. Базовий курс - СПб: Видавництво «Пітер», 2003
У відношенні R (A, B, C) існує багатозначна залежність RA (r) (r) RB в тому і тільки в тому випадку, якщо безліч значень B, відповідне парі значень A і C, залежить тільки від A і не залежить від С . Стосовно ПРОЕКТИ існують наступні дві багатозначні залежності:
ПРО_НОМЕР (r) (r) ПРО_СОТР і ПРО_НОМЕР (r) (r) ПРО_ЗАДАН
Легко показати, що в загальному випадку відносно R (A, B, C) існує багатозначна залежність RA (r) (r) RB в тому і тільки в тому випадку, коли існує багатозначна залежність RA (r) (r) RC
Подальша нормалізація відносин, подібних відношенню ПРОЕКТИ, грунтується на наступній теоремі:
Теорема Фейджин: відношення R (A, B, C) можна спроектувати без втрат у відносини R1 (A, B) і R2 (A, C) в тому і тільки в тому випадку, коли існує MVD A (r) (r) B | C.
Під проектуванням без втрат розуміється такий спосіб декомпозиції відносини, при якому початкове ставлення повністю і без надмірності відновлюється шляхом природного з'єднання отриманих відносин.
Визначення 11. Четверта нормальна форма
Відношення R знаходиться в четвертій нормальній формі (4NF) в тому і тільки в тому випадку, якщо у випадку існування багатозначною залежності A (r) (r) B всі інші атрибути R функціонально залежать від A.
У нашому прикладі можна зробити декомпозицію відносини ПРОЕКТИ в два відношення ПРОЕКТИ-СПІВРОБІТНИКИ і ПРОЕКТИ-ЗАВДАННЯ:
ПРОЕКТИ-СПІВРОБІТНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТИ-ЗАВДАННЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Обидва ці відносини перебувають у 4NF і вільні від зазначених аномалій.
1.5. П'ята нормальна форма
У всіх розглянутих до цього моменту нормалізації проводилася декомпозиція одного відносини в два. Іноді це зробити не вдається, але можлива декомпозиція в більше число відносин, кожна з яких володіє кращими властивостями.Розглянемо, наприклад, ставлення
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СПІВР_НОМЕР, ВІД_НОМЕР, ПРО_НОМЕР)
Припустимо, що один і той же працівник може працювати в декількох відділах і працювати в кожному відділі над кількома проектами. Первинним ключем цього відношення є повна сукупність його атрибутів, відсутні функціональні та багатозначні залежності.
Тому ставлення знаходиться в 4NF. Однак у ньому можуть існувати аномалії, які можна усунути шляхом декомпозиції в три відносини.
Визначення 12. Залежність з'єднання
Відношення R (X, Y, ..., Z) задовольняє залежності з'єднання * (X, Y, ..., Z) в тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y, ..., Z.
Визначення 13. П'ята нормальна форма
Відношення R знаходиться в п'ятій нормальній формі (нормальної формі проекції-з'єднання - PJ / NF) в тому і тільки в тому випадку, коли будь-яка залежність з'єднання в R випливає з існування деякого можливого ключа в R.
Введемо наступні імена складових атрибутів:
СО = {СПІВР_НОМЕР, ВІД_НОМЕР}
СП = {СПІВР_НОМЕР, ПРО_НОМЕР}
ВП = {ВІД_НОМЕР, ПРО_НОМЕР}
Припустимо, що відносно СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ існує залежність з'єднання: * (СО, СП, ВП)
На прикладах легко показати, що при вставках і видаленнях кортежів можуть виникнути проблеми. Їх можна усунути шляхом декомпозиції вихідного стосунки в три нових відносини:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, ВІД_НОМЕР)
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР)
ВІДДІЛИ-ПРОЕКТИ (ВІД_НОМЕР, ПРО_НОМЕР)
П'ята нормальна форма - це остання нормальна форма, яку можна отримати шляхом декомпозиції. Її умови досить нетривіальні, і на практиці 5NF не використовується. Зауважимо, що залежність сполуки є узагальненням як багатозначної залежності, так і функціональної залежності.
2. Семантичного моделювання ДАНИХ,
ER-ДІАГРАМИ
Широке поширення реляційних СУБД та їх використання в найрізноманітніших додатках показує, що реляційна модель даних достатня для моделювання предметних областей. Однак проектування реляційної бази даних в термінах відносин на основі коротко розглянутого механізму нормалізації часто представляє собою дуже складний і незручний для проектувальника процес.При цьому виявляється обмеженість реляційної моделі даних в таких аспектах:
· Модель не надає достатніх коштів для подання змісту даних. Семантика реальної предметної області повинна незалежним від моделі способом представлятися в голові проектувальника. Зокрема, це стосується згадуваної нами проблемі подання обмежень цілісності.
· Для багатьох додатків важко моделювати предметну область на основі плоских таблиць. У ряді випадків на самій початковій стадії проектування проектувальнику доводиться виробляти насильство над собою, щоб описати предметну область у вигляді однієї (можливо, навіть ненормалізованном) таблиці.
· Хоча весь процес проектування відбувається на основі врахування залежностей, реляційна модель не надає будь-яких засобів для подання цих залежностей.
· Незважаючи на те, що процес проектування починається з виділення деяких істотних для програми об'єктів предметної області ("сутностей") та виявлення зв'язків між цими сутностями, реляційна модель даних не пропонує будь-якого апарату для поділу сутностей і зв'язків.
2.1. Семантичні моделі даних
Потреби проектувальників баз даних в більш зручних і потужних засобах моделювання предметної області викликали до життя напрямок семантичних моделей даних. При тому, що будь-яка розвинена семантична модель даних, як і реляційна модель, включає структурну, маніпуляційну і цілісну частини, головним призначенням семантичних моделей є забезпечення можливості вираження семантики даних.Перш, ніж ми коротко розглянемо особливості однієї з поширених семантичних моделей, зупинимося на їх можливі застосування.
Найбільш часто на практиці семантичне моделювання використовується на першій стадії проектування бази даних. При цьому в термінах семантичної моделі проводиться концептуальна схема бази даних, яка потім вручну концептуальна схема перетвориться до реляційної (або який-небудь інший) схемою. Цей процес виконується під управлінням методик, в яких досить чітко обумовлено всі етапи такого перетворення.
Менш часто реалізується автоматизована компіляція концептуальної схеми в реляційну. При цьому відомі два підходи: на основі явного подання концептуальної схеми як вихідної інформації для компілятора і побудови інтегрованих систем проектування з автоматизованим створенням концептуальної схеми на основі інтерв'ю з експертами предметної області. І в тому, і в іншому випадку в результаті виробляється реляційна схема бази даних в третій нормальній формі (більш точно слід було б сказати, що авторові невідомі системи, що забезпечують більш високий рівень нормалізації).
Нарешті, третя можливість, яка ще не вийшла (або тільки виходить) за межі дослідницьких та експериментальних проектів, - це робота з базою даних у семантичній моделі, тобто СУБД, засновані на семантичних моделях даних. При цьому знову розглядаються два варіанти: забезпечення для користувача інтерфейсу на основі семантичної моделі даних з автоматичним відображенням конструкцій в реляційну модель даних (це завдання приблизно такого ж рівня складності, як автоматична компіляція концептуальної схеми бази даних в реляційну схему) і пряма реалізація СУБД, заснована на будь-якої семантичної моделі даних. Найбільш близько до другого підходу знаходяться сучасні об'єктно-орієнтовані СУБД, моделі даних яких за багатьма параметрами близькі до семантичних моделей (хоча в деяких аспектах вони більш потужні, а в деяких - слабші).
2.2. Основні поняття моделі Entity-Relationship (Сутність-Зв'язку)
Далі ми коротко розглянемо деякі риси однієї з найбільш популярних семантичних моделей даних - модель "сутність-зв'язок" (часто її називають коротко ER-моделлю).На використанні різновидів ER-моделі засновано більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі отримали широке поширення в системах CASE, що підтримують автоматизоване проектування реляційних баз даних. Серед безлічі різновидів ER-моделей одна з найбільш розвинених застосовується в системі CASE фірми ORACLE. Її ми і розглянемо. Більш точно, ми зосередимося на структурній частині цієї моделі.
Основними поняттями ER-моделі є сутність, зв'язок та атрибут.
Сутність - це реальний або представлений об'єкт, інформація про який повинна зберігатися і бути доступна. У діаграмах ER-моделі сутність представляється у вигляді прямокутника, що містить ім'я суті. При цьому ім'я сутності - це ім'я типу, а не деякого конкретного екземпляра цього типу. Для більшої виразності і кращого розуміння ім'я суті може супроводжуватися прикладами конкретних об'єктів цього типу.
Нижче зображено сутність АЕРОПОРТ з зразковими об'єктами Шереметьєво і Хітроу:
Кожен екземпляр суті повинен бути відрізнити від будь-якого іншого примірника тієї ж суті (ця вимога в деякому роді аналогічно вимогу відсутності кортежів-дублікатів в реляційних таблицях).
Зв'язок - це графічно зображається асоціація, що встановлюється між двома сутностями. Ця асоціація завжди є бінарною і може існувати між двома різними сутностями або між сутністю і їй же самій (рекурсивна зв'язок). У будь-якому зв'язку виділяються два кінці (відповідно до існуючої парою пов'язують сутностей), на кожному з яких вказується ім'я кінця зв'язку, ступінь кінця зв'язку (скільки екземплярів даної суті пов'язується), обов'язковість зв'язку (тобто чи будь-який примірник даної суті повинен брати участь в зв'язку з цим).
Зв'язок представляється у вигляді лінії, що зв'язує дві сутності або веде від суті до неї ж самої. При це в місці "стикування" зв'язку з сутністю використовуються триточковий вхід в прямокутник суті, якщо для цієї сутності у зв'язку можуть використовуватися багато (many) примірників суті, і одноточковий вхід, якщо у зв'язку може брати участь тільки один екземпляр сутності. Обов'язковий кінець зв'язку зображується суцільною лінією, а необов'язковий - переривчастою лінією.
Як і сутність, зв'язок - це типове поняття, усі примірники обох пар пов'язують сутностей підкоряються правилам зв'язування.
У зображеному нижче прикладі зв'язок між сутностями КВИТОК і ПАСАЖИР пов'язує квитки і пасажирів. При тому кінець сутності з ім'ям "для" дозволяє пов'язувати з одним пасажиром більше одного квитка, причому кожен квиток повинен бути пов'язаний з яким-небудь пасажиром. Кінець сутності з ім'ям "має" означає, що кожен квиток може належати тільки одному пасажиру, причому пасажир не зобов'язаний мати хоча б один квиток.
Лаконічній усній трактуванням зображеної діаграми є наступна:
· Кожен КВИТОК призначений для одного і тільки одного ПАСАЖИРА;
· Кожен ПАСАЖИР може мати один або більше КВИТКІВ.
На наступному прикладі зображена рекурсивна зв'язок, що зв'язує сутність ЛЮДИНА з нею самою. Кінець зв'язку з ім'ям "син" визначає той факт, що в одного батька може бути більш ніж один син. Кінець зв'язку з ім'ям "батько" означає, що не у кожної людини можуть бути сини.
Лаконічній усній трактуванням зображеної діаграми є наступна:
· Кожен ЛЮДИНА є сином одного і тільки одного ЛЮДИНИ;
· Кожен ЛЮДИНА може бути батьком для одного або більше ЛЮДЕЙ ("людина").
Атрибутом суті є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики або вираження стану сутності. Імена атрибутів заносяться в прямокутник, що зображає сутність, під ім'ям сутності і зображуються малими буквами, можливо, з прикладами.
Приклад:
Унікальним ідентифікатором суті є атрибут, комбінація атрибутів, комбінація зв'язків або комбінація зв'язків та атрибутів, унікально відрізняє будь-який екземпляр сутності від інших екземплярів сутності того ж типу.
2.3. Нормальні форми ER-схем
Як і в реляційних схемах баз даних, в ER-схемах вводиться поняття нормальних форм, причому їх зміст дуже близько відповідає змісту реляційних нормальних форм. Зауважимо, що формулювання нормальних форм ER-схем роблять більш зрозумілим сенс реляційних схем. Ми наведемо лише дуже короткі й неформальні визначення трьох перших нормальних форм.У першій нормальній формі ER-схеми усуваються повторювані атрибути або групи атрибутів, тобто виробляється виявлення неявних сутностей, "замаскованих" під атрибути.
У другій нормальній формі усуваються атрибути, що залежать тільки від частини унікального ідентифікатора. Ця частина унікального ідентифікатора визначає окрему сутність.
У третій нормальній формі усуваються атрибути, які залежать від атрибутів, що не входять в унікальний ідентифікатор. Ці атрибути є основою окремої сутності.
2.4. Більш складні елементи ER-моделі
Ми зупинилися лише на самих основних і найбільш очевидних поняттях ER-моделі даних. До більш складних елементів моделі відносяться наступні:
· Підтипи і супертіпи сутностей. Як у мовах програмування з розвиненими типовими системами (наприклад, в мовах об'єктно-орієнтованого програмування), вводиться можливість наслідування типу сутності, виходячи з одного або декількох супертіп. Цікаві нюанси пов'язані з необхідністю графічного зображення цього механізму.
· Зв'язки "many-to-many". Іноді буває необхідно пов'язувати сутності таким чином, що з обох кінців зв'язку можуть бути присутні кілька примірників сутності (наприклад, всі члени кооперативу спільно володіють майном кооперативу). Для цього вводиться різновид зв'язку "багато-со-багатьма".
· Уточнюємо ступеня зв'язку. Іноді буває корисно визначити можливу кількість примірників суті, беруть участь у даній зв'язку (наприклад, службовцю дозволяється брати участь не більше, ніж у трьох проектах одночасно). Для вираження цього семантичного обмеження дозволяється вказувати на кінці зв'язку її максимальну або обов'язкову ступінь.
· Каскадні видалення екземплярів сутностей. Деякі зв'язки бувають настільки сильними (звичайно, у разі зв'язку "один-до-багатьох"), що при видаленні опорного примірника сутності (відповідного кінця зв'язку "один") потрібно видалити і всі екземпляри сутності, відповідні кінця зв'язку "багато хто". Відповідну вимогу "каскадного видалення" можна сформулювати при визначенні сутності.
· Домени. Як і у випадку реляційної моделі даних буває корисна можливість визначення потенційно допустимого безлічі значень атрибута сутності (домену).
Ці та інші більш складні елементи моделі даних "Сутність-Зв'язки" роблять її істотно більш потужною, але одночасно трохи ускладнюють її використання. Звичайно, при реальному використанні ER-діаграм для проектування баз даних необхідно ознайомитися з усіма можливостями.
Сутність може бути розщеплена на два або більше взаємно виключають підтипу, кожен з яких включає загальні атрибути та / або зв'язку. Ці загальні атрибути та / або зв'язку явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути та / або зв'язку. У принципі подтіпізація може тривати більш низьких рівнях, але досвід показує, що в більшості випадків виявляється достатньо двох-трьох рівнів.
Сутність, на основі якої визначаються підтипи, називається супертіп. Підтипи повинні утворювати повне безліч, тобто будь-який екземпляр супертіпа повинен ставитися до деякого підтипу. Іноді для повноти доводиться визначати додатковий підтип ІНШІ.
Приклад: супертіп ЛІТАЛЬНИЙ АПАРАТ
Як і належить це читати? Від супертіпа: ЛІТАЛЬНИЙ АПАРАТ, який повинен бути аеропланів, гелікоптерів, ПТІЦЕЛЕТОМ або інших літальних апаратів. Від підтипи: ВЕРТОЛІТ, який відноситься до типу літального апарата. Від підтипу, який є одночасно супертіпа: Аероплан, який відноситься до типу літального апарата і повинен бути планера чи моторний літак.
Іноді зручно мати два або більше різних розбиття сутності на підтипи. Наприклад, сутність ЛЮДИНА може бути розбита на підтипи за професійною ознакою (ПРОГРАММИСТ, доярки і т.д.), а може - за статевою ознакою (чоловіки, жінки).
2.5. Отримання реляційної схеми з ER-схеми
Крок 1. Кожна проста сутність перетворюється в таблицю. Проста сутність - сутність, яка не є підтипом і не має підтипів. Ім'я суті стає ім'ям таблиці.
Крок 2. Кожен атрибут стає можливим стовпцем з тим же ім'ям, може вибиратися більш точний формат. Стовпці, відповідні необов'язковим атрибутам, можуть містити невизначені значення; стовпці, що відповідають обов'язковим атрибутам, - не можуть.
Крок 3. Компоненти унікального ідентифікатора суті перетворюються на первинний ключ таблиці. Якщо є кілька можливих унікальних ідентифікаторів, вибирається найбільш використовуваний. Якщо до складу унікального ідентифікатора входять зв'язку, до числа стовпців первинного ключа додається копія унікального ідентифікатора суті, що знаходиться на далекому кінці зв'язку (цей процес може тривати рекурсивно). Для іменування цих стовпців використовуються імена решт зв'язків та / або імена сутностей.
Крок 4. Зв'язки багато-до-одного (і один-до-одного) стають зовнішніми ключами. Тобто робиться копія унікального ідентифікатора з кінця зв'язку "один", і відповідні стовпці складають зовнішній ключ. Необов'язкові зв'язку відповідають стовпцям, допускає невизначені значення; обов'язкові зв'язку - стовпцях, що не допускає невизначені значення.
Крок 5. Індекси створюються для первинного ключа (унікальний індекс), зовнішніх ключів і тих атрибутів, на яких передбачається в основному базувати запити.
Крок 6. Якщо у концептуальній схемі були присутні підтипи, то можливі два способи:
· Всі підтипи в одній таблиці (а)
· Для кожного підтипу - окрема таблиця (б)
При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертіпа, а для підтипів можуть створюватися подання. У таблицю додається принаймні один стовпець, що містить код ТИПУ, він стає частиною первинного ключа.
При використанні методу (б) для кожного підтипу першого рівня (для більш нижніх - подання) супертіп відтворюється за допомогою представлення UNION (з усіх таблиць підтипів вибираються загальні стовпці - стовпці супертіпа).
| Все в одній таблиці | Таблиця - на підтип |
| Переваги | |
| Всі зберігається разом Легкий доступ до супертіп і підтипів Потрібно менше таблиць | Більш зрозумілі правила підтипів Програми працюють тільки з потрібними таблицями |
| Недоліки | |
| Занадто спільне рішення Потрібна додаткова логіка роботи з різними наборами стовпців і різними обмеженнями Потенційне вузьке місце (у зв'язку з блокуваннями) Стовпці підтипів повинні бути необов'язковими У деяких СУБД для зберігання невизначених значень потрібна додаткова пам'ять | Занадто багато таблиць Баламутять стовпці в поданні UNION Потенційна втрата продуктивності при роботі через UNION Над супертіп неможливі модифікації |
· Загальний домен (а)
· Явні зовнішні ключі (б)
Якщо залишаються зовнішні ключі все в одному домені, тобто мають загальний формат (спосіб (а)), то створюються два стовпці: ідентифікатор зв'язку та ідентифікатор сутності. Стовпець ідентифікатора зв'язку використовується для розрізнення зв'язків, що покриваються дугою винятку. Стовпець ідентифікатора суті використовується для зберігання значень унікального ідентифікатора суті на дальньому кінці відповідної зв'язку.
Якщо результуючі зовнішні ключі не належать до одного домену, то для кожного зв'язку, покривається дугою винятку, створюються явні стовпці зовнішніх ключів; всі ці стовпці можуть містити невизначені значення.
| Загальний домен | Явні зовнішні ключі |
| Переваги | |
| Потрібно тільки два стовпці | Умови з'єднання - явні |
| Недоліки | |
| Обидва додаткових атрибуту повинні використовуватися у з'єднаннях | Занадто багато стовпців |
Варіант 1 (поганий)
Варіант 2 (істотно краще, якщо підтипи дійсно існують)
Варіант 3 (годиться при наявності осмисленого супертіпа D).
ВИСНОВОК
При проектуванні бази даних вирішуються дві основні проблеми:
1. Яким чином відобразити об'єкти предметної області в абстрактні об'єкти моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості кращим (ефективним, зручним і т.д.)? Часто цю проблему називають проблемою логічного проектування баз даних.
2. Як забезпечити ефективність виконання запитів до бази даних, тобто яким чином, маючи на увазі особливості конкретної системи управління базами даних, розташувати дані у зовнішній пам'яті, створення якихось додаткових структур (наприклад, індексів) вимагати і т.д.? Цю проблему називають проблемою фізичного проектування баз даних.
Проблема проектування реляційної бази даних складається в обгрунтованому прийнятті рішень про те, з яких відносин повинна складатися база даних і які атрибути мають бути у цих відносин.
СПИСОК ЛІТЕРАТУРИ
1. Гончаров А. «Microsoft Access ХР». - СПб: Питер, 2003
2. Горєв А., Макашарипов С, Ахаян Р. Ефективна робота із СУБД. СПб, «Пітер», 2002
3. Джексон Г. Проектування реляціоннних баз даних для використання з ЕОМ: Переклад з англійської. М.: Мир, 1991,
4. Кирій В.Г. Інформатика. Навчальний посібник - К.: ІРГТ, 1998
5. Ковалевська Є.В., Волосков Н.І., Григоренко Г.П., Желнінскій Г.С., Технологія реалізації на ЕОМ регламентних задач АСУ - М.: 1983
6. Ломтадзе В.В., Шишкіна Л.П. Інформатика. Навчальний посібник. Іркутськ: ІРГТ, 1999
7. Подільський В.І., Григоренко Г.П., Щербакова Н.С., Дік В.В. Обробка облікової інформації на ПЕОМ - М.: МЕСИ, 1993
8. Потапкин А.В. MS Visual Basic для пакету Microsoft Office. М, «Еком», 2004
9. Симонович С.В. та ін Інформатика. Базовий курс - СПб: Видавництво «Пітер», 2003