7.5 Отримання попередніх відношень за методом “Суть – зв’язок”
Загальний підхід до проектування баз даних на основі ER-методу включає в себе такі основні кроки:
- побудова діаграми ER-типу, що включає в свій склад всі суті і зв'язки даної предметної області;
- побудова набору попередніх відношень з вказанням передбачуваного початкового ключа для кожного відношення ;
- підготовка списку всіх атрибутів, що викликають інтерес (котрі не були перераховані як ключі сутей), і призначення кожного з цих атрибутів одному з попередніх відношень такі, щоб всі ці попередні відношення знаходились в НФБК. Для виконання цієї задачі необхідно визначити всі міжатрибутні функціональні залежності. У випадку, якщо не вдається привести відношення до НФБК або деяким атрибутам не вдасться знайти логічно обґрунтованих місць, треба переглянути ER-діаграми на предмет видалення ускладнень, що виникли.
Попередні відношення формально генеруються з діаграми ER-типу на основі аналізу класу належності і ступені відношень сутей, на основі таких правил [14].
ПРАВИЛО 1. Якщо ступінь бінарних зв'язків 1:1 і клас належності обов'язковий для обох сутей, гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень. Тобто, у відношенні ніколи не буде ні порожньої інформації, ні груп надлишкових даних, що повторюються.
Проте якщо клас належності однієї з сутей стане необов'язковим, то одного відношення буде недостатньо, оскільки у всіх кортежах, що містять інформацію про екземпляри однієї суті, які не мають зв'язків з екземплярами другої суті, з'являться пробіли.
Дійсно, єдине відношення містить кортежі, кожен з яких повинен включати атрибути, що описують обидві суті. Відсутність зв'язку між екземплярами сутей приведе у цьому випадку до того, що в кортежі буде відсутня інформація про атрибути, які описують одну з сутей.
ПРАВИЛО 2. Якщо ступінь бінарного зв'язку 1:1 і клас належності однієї суті є обов'язковим, а іншої - необов'язковим, то необхідна побудова двох відношень. При цьому ключ суті повинен служити первинним ключем для відповідного відношення. Крім того, ключ суті, для якої клас належності є обов'язковим, додається як атрибут у відношення, що виділене для суті з необов'язковим класом належності.
Формування двох відношень, кортежі кожного з яких включають лише опис атрибутів відповідної суті, приводить до виключення пробілів в відношеннях. При цьому зв'язок між сутями буде притримуватися завдяки включенню в одно з відношень ключових атрибутів другої суті.
ПРАВИЛО 3. Якщо ступінь бінарного зв'язку 1:1 і клас належності обох сутей не є обов'язковим, то необхідно використовувати три відношення: по одному для кожної суті, ключі котрих служать первинні ключі відповідних відношень, і одне для зв'язку. Первинним ключем цього відношення може бути будь-яка з двох сутей. Серед своїх атрибутів відношення, що виділяється для зв'язку, повинно мати по одному ключу кожної суті.
Наявність в обох сутях "ізольованих" екземплярів приводить до того, що ні в одному з відношень не буде гарантовано знаходитися значуще значення атрибута, що служить для зв'язку між відношеннями, тобто знову виникає проблема наявності у відношенні пробілів. У відношенні, що породжене зв'язком, пробіли завжди відсутні, оскільки увійшовши у нього кортежі не відображають “ізольовані" екземпляри сутей.
Під час роботи з відношеннями для бінарних зв'язків ступені 1:N фактором, що визначає вибір правила для генерації відповідного набору попередніх відношень, є клас належності n- зв’язаної суті. Клас належності 1-зв'язаної суті у цьому випадку на кінцевий результат не впливає.
ПРАВИЛО 4. Якщо ступінь бінарного зв'язку 1:N, і клас належності n-зв'язної суті є обов'язковим, то досить використати по одному відношенню на кожну суть, при умові, що ключ кожної суті служить як первинний ключ для відповідного відношення. Додатково, ключ 1-зв'язаної суті повинен бути добавлений як атрибут у відношення, що відводиться n- зв’язній суті.
Очевидно, що використання двох відношень в цьому випадку дозволяє усунути дублювання інформації (багатократний опис атрибута 1-зв'язаної суті, зв'язаного з n атрибутами n-зв’язної суті). Крім того, аналогічно правилу 2 забезпечується видалення з відношень пробілів.
ПРАВИЛО 5. Якщо ступінь бінарного зв'язку 1:N і клас належності n-зв’язної суті є необов'язковими, то необхідно формування трьох відношень: по одному для кожної суті, причому ключ кожної суті служить як первинний ключ для відповідного відношення, і одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів ключ суті кожної з зв'язних сутей.
При ступені бінарного зв'язку M:N без залежності від класу належності сутей завжди необхідно використовувати три відношення.
ПРАВИЛО 6. Якщо ступінь бінарного зв'язку M:N, то для зберігання даних потрібні три відношення: по одному для кожної суті, причому ключ кожної суті служить як первинний ключ для відповідного відношення, та одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів і ключ суті кожної зі зв'язних сутей. Виявлення в предметній області тристоронніх зв'язків приводить до необхідності використання чотирьох відношень.
ПРАВИЛО 7. У випадку наявності тристороннього зв'язку завжди використовуються чотири відношення: по одному для кожної суті. Причому ключ кожної суті служить як первинний ключ для відповідного відношення, і одного відношення для зв'язку. Зв'язок повинен мати серед своїх атрибутів ключі суті кожної із зв'язних сутей.
Аналогічно для подання n-стороннього зв'язку необхідно використовувати n+1 попереднє відношення.
Використовуючи наведені правила, перерахунок атрибутів з універсального відношення та сформовану ER-модель предметної області, сформуємо попередні відношення, які описують задачу матеріального забезпечення заводу. Отримані попередні відношення зведемо в таблицю 7.
Таблиця 7 – Попередні відношення для опису предметної області “Контроль оплати по кредитах”
Ім'я зв'язку | Правило | Попередні відношення | Додаткові атрибути |
Бере | 4 | R1(ідентифікаційний код, …)
*R2(код кредиту, …)
| ПІБ, адреса, рік народження,
сума кредиту, дата надання, дата завершення, ідентифікаційний код |
Визначають | 4 | R3(річні проценти, …)
*R4 (код кредиту, …)
| назва кредиту, максимальна сума
сума кредиту, дата надання, дата завершення, ідентифікаційний код, річні проценти |
Оплачується | 4 | R5(код кредиту, …)
R6(дата, час, …) | сума кредиту, дата надання, дата завершення, ідентифікаційний код, річні проценти
сума, код кредиту |
У таблиці 7 наведено розподілення неключових атрибутів між отриманими попередніми зв'язками. Знаком “*” помічені відношення, які потрібно видалити. Відношення R2 виключається з розглядання, оскільки вони повністю містяться у відношенні R5. Відношення R4 виключається з розглядання, оскільки воно повністю збігається з R5.
Після видалення відношень позначених * залишились відношення:
- R1(<ідентифікаційний код>, ПІБ, адреса, рік народження);
- R3(<річні проценти>, назва кредиту, максимальна сума);
- R5(<код кредиту>, сума кредиту, дата надання, дата завершення, ідентифікаційний код, річні проценти)
- R6(<дата, час>, сума, код кредиту).
Кінцеві відношення, що описують базу даних “Контроль оплати по кредитах”, подані таким набором:
Особа (ідентифікаційний код , ПІБ, адреса, рік народження);
Види кредитів (річні проценти, назва кредиту, максимальна сума) ;
Кредит (код кредиту, сума кредиту, дата надання, дата завершення, річні проценти, ідентифікаційний код) ;
Щомісячна оплата (дата, час, сума, код кредиту).
- Методичні вказівки
- 1 Зміст та оформлення курсової роботи
- 2 Тематика курсового проектування
- 3 Методика виконання розділів проекту
- 3.1 Завдання на курсову роботу
- 3.2 Аналіз сучасного розвитку баз даних
- 3.3 Змістовне формування задачі
- 3.4 Постановка задачі та аналіз предметної області
- 3.5 Розробка еr- моделі предметної області
- 3.6 Розробка універсального відношення
- 5 Порядок захисту курсової роботи
- 6 Завдання на курсове проектування
- 7 Короткі теоритичн1 положення
- 7.1 Аналіз предметної області та постановка задачі
- 7.2 Розробка універсального відношення
- 7.3 Розробка er-моделі предметної області
- Тип суті 1 Зв’язки Тип суті 2 Екз.1 суті 1 Екз.1 суті 2 Екз.2 суті 1 Екз.2 суті2
- 7.4 Проектування нормалізованих відношень
- 7.5 Отримання попередніх відношень за методом “Суть – зв’язок”
- 7.6 Нормалізація відношень методом декомпозиції
- 7.7 Оцінка спроектованих нфбк-відношень
- 8 Реалізація запитів і вихідних форм
- 8.1 Аналіз реалізованих бд запитів
- 8.2 Розробка вихідних форм
- 9 Зразок оформлення додатків
- Додаток д
- Література
- Додаток а
- Додаток в Оформлення тексту пояснювальної записки
- 21021, М. Вінниця, Хмельницьке шосе, 95,
- 21021, М. Вінниця, Хмельницьке шосе, 95,