Перетворення er-моделі в реляційну
Концептуальні моделі дозволяють точніше представити предметну область, чим реляційні і інші моделі. Але в даний час існують небагато системи управління базами даних, що підтримують ці моделі. На практиці найбільш поширені системи, що реалізовують реляційну модель. Тому необхідний метод переведення концептуальної моделі в реляційну. Такий метод ґрунтується на формуванні набору попередніх таблиць з ER-діаграм.
Для кожної сутності створюється таблиця. Причому кожному атрибуту сутності відповідає стовпець таблиці.
Правила генерації таблиць з ER-діаграм спираються на два основні чинники - тип зв'язку і клас приналежності сутності. Викладемо їх.
Правило 1
Якщо зв'язок типу 1:1 і клас приналежності обох сутностей є обов'язковим, то необхідна тільки одна таблиця. Первинним ключем цієї таблиці може бути первинний ключ будь-якої з двох сутностей.
На ER-діаграмі зв'язку 1:1, на мал. 1.5, клас приналежності сутності менеджер, філіал є обов'язковим. Тоді згідно правила 1 повинна бути створена одна таблиця наступної структури:
МЕНЕДЖЕР-ФІЛІАЛ
НМ | СТАЖ | СПЕЦ | НФ | АДР_Ф
Первинним ключем цієї таблиці може бути і первинний ключ сутності менеджер -НМ.
Правило 2
Якщо зв'язок типу 1:1 і клас приналежності однієї сутності є обов'язковим, а інший - необов'язковим, то необхідно побудувати таблицю для кожної сутності. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Первинний ключ сутності, для якої клас приналежності є необов'язковим, додається як атрибут в таблицю для сутності з обов'язковим класом приналежності.
Уявимо, що на ER-діаграмі зв'язку 1:1, на мал. 1.5, клас приналежності сутності менеджер буде обов'язковий, а сутності філіал - необов'язковий. Тоді згідно правила 2 повинні згенеруватися дві таблиці наступної структури:
МЕНЕДЖЕР-ФІЛІАЛ
НМ | СТАЖ | СПЕЦ | НФ
ФІЛІАЛ
НФ | АДР_Ф
Сутність з необов'язковим класом приналежності (філіал) іменується батьківською, а з обов'язковим (менеджер) - дочірньою. Первинний ключ батьківської сутності (НФ), що поміщається в дочірню таблицю, називається зовнішнім ключем батьківської сутності. Зв'язок між вказаними таблицями встановлюється шляхом зв'язку первинного і зовнішнього ключа і має вигляд
Примітка. Якщо зовнішній ключ представляє зв'язок 1:1, то повинні бути заборонені його дублюючі значення.
Правило 3
Якщо зв'язок типу 1:1 і клас приналежності обох сутностей є необов'язковим, то необхідно побудувати три таблиці - по одній для кожної сутності і одну для зв'язку. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Таблиця для зв'язку серед своїх атрибутів повинна мати ключі обох сутностей.
Уявимо, що на ER-діаграмі зв'язку 1:1, на мал. 1.5, клас приналежності сутності менеджер, філіал буде необов'язковий. Тоді згідно правила 3 повинні згенеруватися три таблиці наступної структури:
МЕНЕДЖЕР
НМ | СТАЖ | СПЕЦ |
ФІЛІАЛ
НФ | АДР_Ф
МЕНЕДЖЕР-ФІЛІАЛ
НМ | НФ
При цьому здійснюється декомпозиція зв'язку 1:1 на два зв'язки 1:1 таким чином:
Отже, для зв'язку типу 1:1 існують три окремих правила формування попередніх таблиць з ER-діаграм.
Для зв'язку типу 1:Б існують тільки два правила. Вибір одного з них залежить від класу приналежності сутності на стороні М. Клас приналежності сутності на стороні 1 не впливає на вибір.
Правило 4
Якщо зв'язок типу 1:Б і клас приналежності сутності на стороні М є обов'язковим, то необхідно побудувати таблицю для кожної сутності. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Первинний ключ сутності на стороні 1 додається як атрибут в таблицю для сутності на стороні М.
На ER-діаграмі зв'язку 1:Б, на мал. 1.5, клас приналежності сутності рахунок є обов'язковим. Тоді згідно правила 4 повинні згенеруватися дві таблиці наступної структури:
ФІЛІАЛ
НФ | АДР_Ф
РАХУНОК-ФІЛІАЛ
НР |ОСТ |ТИП |НФ
Зв'язок між вказаними таблицями матиме вигляд
1 Б
НФ АДР_Ф НР ОСТ ТИП НФ
Примітка. Якщо зовнішній ключ представляє зв'язок 1:Б, то повинні бути дозволені його дублюючі значення.
Правило 5
Якщо зв'язок типу 1:Б і клас приналежності сутності на стороні М є необов'язковим, то необхідно побудувати три таблиці - по одній для кожної сутності і одну для зв'язку. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Таблиця для зв'язку серед своїх атрибутів повинна мати ключі обох сутностей.
Уявимо, що на ER-діаграмі зв'язку 1:Б, на мал. 1.5, клас приналежності сутності рахунок є необов'язковим. Тоді згідно правила 5 повинні згенеруватися три таблиці наступної структури:
ФІЛІАЛ
НФ | АДР_Ф
РАХУНОК
НР |ОСТ |ТИП
ФІЛІАЛ – РАХУНОК
НФ | НР
При цьому здійснюється декомпозиція зв'язку 1:Б на два зв'язки - 1:Б і 1:1 - наступним чином:
НФ АДР_Ф НР ОСТУ ТИП
1 1
Б 1
НФ НР
Для зв'язку типу M:N клас приналежності сутності не має значення.
Правило 6
Якщо зв'язок типу M:N, то необхідно побудувати три таблиці - по одній для кожної сутності і одну для зв'язку. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Таблиця для зв'язку серед своїх атрибутів повинна мати ключі обох сутностей.
ER-діаграма зв'язку M:N є на мал. 1.5. Згідно правила 6 на основі цієї ER-діаграми повинні згенеруватися три таблиці наступної структури:
КЛІЄНТ
НК |
ПІП_К |
СОЦ_П |
АДР_К |
РАХУНОК
НР |
ОСТ |
ТИП |
КЛІЄНТ-РАХУНОК
НК |
НР |
При цьому здійснюється декомпозиція зв'язку M:N на два зв'язки 1:М таким чином:
У таблиці КЛІЄНТ-РАХУНОК клієнтові, що має, наприклад, три рахунки відповідатимуть три рядки з одним і тим же номером клієнта. А рахунок, у якого, наприклад, два власники, представляється двома рядками з різними номерами клієнтів, що володіють цим рахунком.
До ER-моделі предметної області БАНК, на мал. 1.5, застосовні правила 1, 4, 6. Зв'язок МЕНЕДЖЕР – ФІЛІАЛ представляється (згідно правила 1) однією таблицею
таблиця А
НМ |
СТАЖ |
СПЕЦ |
НФ |
АДР_Ф |
Зв'язок ФІЛІАЛ – РАХУНОК представляється (згідно правила 4) зв'язком
Зв'язок КЛІЄНТ – РАХУНОК представляється (згідно правила 6) зв'язком
Аналіз складу атрибутів отриманих таблиць A, B, C, D, E, F показує, що таблиця В є складовою частиною таблиці А, таблиця Е – складовою частиною таблиці С. Тому таблиці В, Е можна виключити з розгляду. Таблиці, що залишилися, А, С, D, F можна зв'язати за допомогою зв'язку первинних і зовнішніх ключів як на мал. 1.7. В результаті отримаємо реляційну модель для ER-моделі предметної області БАНК.