1.2 Логічне проектування
Створення локальної логічної моделі даних
Логічне проектування БД - процес конструювання на основі окремих концептуальних моделей цих користувачів загальної інформаційної моделі підприємства, яка є незалежною від особливостей реально використовуваної СУБД і інших фізичних умов [1].
Конструйована інформаційна модель або локальна логічна модель даних (ЛЛМД) :
створюється на основі концептуальної моделі;
залежить тільки від типу майбутньої СУБД (мережева, ієрархічна, реляційна, об'єктно-реляційна);
постійно тестується;
піддається корекції за допомогою нормалізації;
повинна забезпечувати підтримку транзакцій.
Етап 1. Перетворення локальної концептуальної моделі даних (ЛКМД) в локальну логічну модель даних (ЛЛМД) - це доопрацювання ЛКМД з метою видалення з них небажаних елементів, як які можуть бути.
Зв'язки типу N : M Для їх видалення необхідно ввести проміжну сутність
Складні зв'язки (більше двох сутностей) - необхідно вводити проміжні сутності.
Рекурсивний зв'язок
Для їх видалення також має бути введена проміжна сутність.
Зв'язки з атрибутами мають бути перетворені шляхом введення проміжної суті, в яку включаються ці атрибути.
Множинний атрибут також має бути видалений за рахунок введення проміжної сутності.
Повторна перевірка зв'язків 1:1, оскільки може бути були створені два об'єкти одного типу - тоді їх краще об'єднати.
Надмірні зв'язки. Необхідно видалити зв'язок, який повторює передачу однієї і тієї ж інформації, але робити це обережно, провівши ретельний аналіз.
Етап 2. Визначення набору відношень, виходячи з ЛЛМД.
Складання схем усіх відношень (ім'я відношення (атрибут1, атрибут2.), при цьому зв'язки враховуються за допомогою механізму первинних і зовнішніх ключів (створенням проміжної суті з атрибутами у вигляді ключів відношень, що зв'язуються, або включенням зовнішнього ключа в сутність); документування на мові опису даних з урахуванням нових атрибутів - зовнішніх ключів.
Етап 3. Перевірка моделі за допомогою правил нормалізації
Етап 4. Перевірка моделі відносно транзакцій користувачів.
Перелік транзакцій береться із специфікацій користувачів.
Здійснюється за допомогою ER -диаграммы, словника і зв'язків між первинними і зовнішніми ключами.
Шлях транзакції відзначається лініями на ER -диаграмме.
Етап 5. Створення діаграм
Це остаточний варіант ER -диаграмм з урахуванням нормалізації і перевірки транзакцій.
Підтримка цілісності даних
Етап 6. Визначення вимог підтримки цілісності даних.
Це обмеження, що дозволяють запобігти появі в базі суперечливих даних.
У конкретних СУБД вирішується по-різному.
Цей етап припускає теоретичне і повне вирішення цього питання, але не з опорою на конкретну СУБД.5 основних обмежень цілісності даних (на прикладі відношень )
Обов'язкові дані.
Обмеження для доменів атрибутів. Ці обмеження встановлюються і відбиваються в документах четвертого етапу концептуального проекту.
Цілісність сутностей. Первинний ключ не може містити порожнього значення - документація п'ятого етапу концептуального проекту.
Посилальна цілісність. Якщо участь в зв'язку часткова, то зовнішній ключ може мати значення NULL. Проте, в цьому випадку має бути аналіз: якщо С1 = NULL, то може бути М1 може отримувати книги минувши склад.
Вимоги цього підприємства. Це бізнес-правила підприємства.
Етап 7. Обговорення ЛЛМД з кінцевими користувачами
Обговорюються і діаграми і документація.
Глобальна логічна модель даних
Глобальна логічна МД будується з ЛЛМД (це уявлення окремих груп користувачів про підприємство) шляхом їх злиття.
Здійснюється перевірка ГЛМД правилами нормалізації і на можливість виконання транзакцій ,але тільки у тому випадку, якщо при злитті вносилися зміни по сутностям і зв'язкам.
При злитті доведеться враховувати конфлікти між окремими представленнями (ЛЛМД) і брати до уваги їх можливе перекриття.
Створення ГЛМД складається з п'яти етапів.
Етап 1. Злиття ЛЛМД в ГЛМД.
Найпростіший метод - спершу зливаються дві моделі, потім до них додається третя і так далі до останньої ЛЛМД.
Перед злиттям необхідно переконатися, що усі ЛЛМД були отримані в повній відповідності з попередніми етапами, починаючи з отримання КЛМД.
При злитті виконуються наступні дії.
Аналіз імен сутностей і їх первинних ключів, а також імен зв'язків :
у сутностей (зв'язків) одне ім'я, але вони відрізняються один від одного;
сутності (зв'язки) ідентичні, але мають різні імена.
Злиття загальних сутей з окремих ЛЛМД:
зливаються сутності з однаковими іменами і первинними ключами або однаковими іменами, але різними первинними ключами (але з однаковими потенційними ключами) або з різними іменами, ключами, але по суті однаковими;
при злитті включаються не співпадаючі атрибути і не дублюються співпадаючі;
після злиття в ГЛМД включаються усі інші сутності.
Злиття загальних зв'язків і включення інших.
Перевірка на наявність пропущених сутностей і зв'язків - як правило, шляхом додаткових опитувань.
Перевірка коректності зовнішніх ключів (якщо мінялися стосунки і зв'язки).
Перевірка дотримання обмежень цілісності.
Виконання креслення ГЛМД.
Оновлення документації.
Етап 2. Перевірка ГЛМД.
Виконуються дії з перевірок за допомогою правил нормалізації і відносно транзакцій користувачів.
Етап 3. Перевірка можливостей розширення моделі в майбутньому.
По можливості необхідно врахувати, що можуть з'явитися нові вимоги, які потрібно буде реалізувати з найменшими витратами.
Етап 4. Створення остаточного варіанту діаграми (сутність-зв'язок (
ГЛМД представляється як ER -диаграмма, записуються схеми стосунків, оформляється словник даних.
Етап 5. Обговорення ГЛМД з користувачами.
Після цього етапу приймається рішення на фізичну реалізацію БД в середовищі конкретної СУБД.
Після логічного проектування словник даних (Таблиця 2) та діаграма (Рис.2) уточнюється
Таблица 2 – Словник даних логичне проектування
№ з/п |
Назва атрибуту |
До якої сутності відноситься |
Тип даних атрибуту |
Набір значень атрибуту(домен) |
Прийняття атрибутом значення NULL |
1 |
2 |
3 |
4 |
6 |
7 |
|
|
Код сотрудника |
співробітник |
числовий |
|
Заборонено |
|
|
Ф.И. О. |
співробітник |
текстовий |
|
|
|
|
Дата народження |
співробітник |
дата/час |
|
|
Продовження таблиці 2 – Словник даних логичне проектування
1 |
2 |
3 |
4 |
6 |
7 |
|
|
Індекс |
співробітник |
числовий |
|
|
|
|
Місто |
співробітник |
текстовий |
|
|
|
|
Вулиця |
співробітник |
текстовий |
|
|
|
|
Телефон робітник |
співробітник |
числовий |
|
|
|
|
Телефон домашній |
співробітник |
числовий |
|
|
|
|
Розрахунковий рахунок |
співробітник |
грошовий |
|
|
|
|
Паспорт серія |
співробітник |
текстовий |
|
|
|
|
Паспорт номер |
співробітник |
числовий |
|
|
|
|
Код підприємства |
предприятие |
числовий |
|
Заборонено |
|
|
Назва |
предпреятие |
текстовий |
|
|
|
|
Ф.И. О. директори |
предпреятие |
текстовий |
|
|
|
|
Ф.И. О. представника |
предпреятие |
текстовий |
|
|
|
|
Індекс |
предпреятие |
числовий |
|
|
|
|
Місто |
предпреятие |
текстовий |
|
|
|
|
Вулиця |
предпреятие |
текстовий |
|
|
|
|
Телефон |
предпреятие |
числовий |
|
|
|
|
Факс |
предпреятие |
числовий |
|
|
|
|
Розрахунковий рахунок |
предпреятие |
лічильник |
|
|
|
|
Код товару |
продаж |
числовий |
|
Заборонено |
|
|
Назва |
продаж |
текстовий |
|
|
|
|
Ціна |
продаж |
грошовий |
|
|
|
|
Рівень співпраці |
продаж |
текстовий |
тимчасова або постійна |
|
|
|
Дата підготовки |
продаж |
числовий |
|
|
|
|
Вартість підготовки |
продаж |
числовий |
|
|
|
|
Дата відправки матеріалів |
продаж |
дата/час |
|
|
|
|
Сума винагороди |
контракт |
грошовий |
|
|
Продовження таблиці 2 – Словник даних логичне проектування
1 |
2 |
3 |
4 |
6 |
7 |
|
|
Дата виплати винагороди |
контракт |
дата/час |
|
|
|
|
Код контракту |
контракт |
числовий |
|
Заборонено |
|
|
Дата контракту |
контракт |
дата/час |
|
|
|
|
Сума контракту |
контракт |
грошовий |
|
|
|
|
Сума виплати |
контракт |
грошовий |
|
|
|
|
Дата виплати |
контракт |
дата/час |
|
|
|
|
Код товару |
договір |
числовий |
|
Заборонено |
|
|
Код контракту |
договір |
числовий |
|
Заборонено |
|
|
Код товару |
продажа |
числовий |
|
Заборонено |
|
|
Код сотрудника |
продажа |
числовий |
|
Заборонено |
|
|
Код сотрудника |
співробітництво |
числовий |
|
Заборонено |
|
|
Код підприемства |
співробітництво |
числовий |
|
Заборонено |