логічне проектування
У запропонованій методології проектування баз даних весь процес розробки розділяється на три основні фази: концептуальне, логічне і фізичне проектування. Логічне проектування баз даних - це процес конструювання загальної інформаційної моделі підприємства на основі окремих моделей даних користувачів, яка є незалежною від особливостей реально ис-пользуемя СУБД і інших фізичних умов.
На попередньому етапі отримано набір локальних концептуальних моделей даних, що відбивають уявлення користувачів про предметну середовищі. Однак ці моделі можуть містити деякі структури даних, реалізація яких в звичайних типах СУБД буде утруднена. На цьому ця-пе подібні структури даних перетворюються в таку форму, яка не викличе труднощів при їх реалізації в середовищі існуючих СУБД. Може послідувати зауваження, що ці дії не є елементом логічного проектування баз даних. Однак пропонована процедура змушує розробника ретельніше обдумувати сенс кожного елемента даних, що позитивно позначається на точ-ності відображення в моделі особливостей того чи іншого підприємства. На даному етапі виконуються наступні дії:
1. Видалення зв'язків типу M: N.
2. Видалення складних зв'язків.
3. Видалення рекурсивних зв'язків.
4. Видалення зв'язків з атрибутами.
5. Видалення множинних атрибутів.
6. Повторна зв'язків типу 1: 1.
7. Видалення надлишкових зв'язків.
1. Видалення зв'язків типу M: N. Якщо в концептуальній моделі присутні зв'язку типу M: N ( "багато-до-мно-гим"), то їх слід усунути шляхом визначення деякої проміжної суті-сти. Зв'язок типу M: N замінюється двома зв'язками типу 1: М. устанав-Лівану з новоствореної сутністю.
Мал. 7. Зв'язки типу 1. M
2. Видалення складних зв'язків. Складною називається зв'язок, що існує між трьома і більше типами суті-стей. Якщо в концептуальній моделі присутня складна зв'язок, її слід усунути за допомогою проміжної сутності. Складна зв'язок замінює-ся необхідною кількістю бінарних зв'язків типу 1: М. встановлюваних з новоствореної сутністю. Наприклад, потрійний зв'язок "Здається в оренду" (зображується ромбом) відображає від-носіння, що існують між оформляють оренду працівником компанії, зе-Мельна ділянкою та орендарем (рис. 8).
^
Мал. 8. Складна зв'язок
Цю складну зв'язок можна спростити шляхом введення нової сутності і визначення бінарних зв'язків між нею і кожної з вихідних сутностей складної зв'язку.
У нашому прикладі зв'язок "Здається в оренду" можна усунути за допомогою введення нової слабкою суті з ім'ям Угоду. Новостворена сутність буде пов'язана з вихідними сутностями трьома новими бінарними зв'язками (рис. 9).
^
Мал. 9. Спрощення складної зв'язку
3. Видалення рекурсивних зв'язків. Рекурсивними називаються такі зв'язки, в яких сутність деякого типу взаємодіє сама з собою. Якщо концептуальна модель містить рекурсивні зв'язку, вони повинні бути усунуті за допомогою визначення неко-торою проміжної сутності. Наприклад, для відображення ситуації, коли один з працівників керує групою інших працівників, може бути встановлена ре-курсивний зв'язок типу "один-ко-многим" (1: М).
^ 4. Видалення зв'язків з атрибутами. Якщо в концептуальній моделі присутні зв'язку, які мають власні атрі-пляшок, вони повинні бути перетворені шляхом створення нової сутності. Наприклад, розглянемо ситуацію, коли потрібно фіксувати кількісних-під робочих годин, відпрацьованих тимчасовим персоналом кожного з відділень підпри-ємства. Зв'язок "Працює в" має атрибут з ім'ям "Відпрацьовано годин". Перетворимо зв'язок "Працює в" в сутність з ім'ям "Розподіл по відділам", якій призначимо атрибут "Відпрацьовано годин", після чого створимо дві нових зв'язку типу 1: М.
^ 6. Повторна зв'язків типу 1: 1. У процесі визначення сутностей могли бути створені дві різні сутності, які насправді представляють один і той же об'єкт в предметної області додатки. Наприклад, могли бути створені дві сутності "Відділ" і "Департамент", ко-торие насправді представляють один і той же тип об'єкта. Іншими словами, ім'я "Відділ" є синонімом імені "Департамент". У подібному випадку слід обсягів по-дініть ці дві сутності в одну. Якщо первинні ключі об'єднуються сутностей різні, виберіть один з них в якості первинного, а другий вкажіть як аль-тернатівний ключ.
^ 7. Видалення надлишкових зв'язків. Зв'язок є надлишковою, якщо одна і та ж інформація може бути отримана не тільки через неї, а й за допомогою іншого зв'язку. Завжди слід прагнути ство-вать мінімальні моделі даних, і тому, якщо надлишкова зв'язок не є очевидно необхідної, її слід видаляти. Встановити, що між двома сутностями-ми є більше одного зв'язку, досить просто. Однак з цього ще не випливає, що одна з двох зв'язків обов'язково є надмірною, оскільки обидві вони можуть представляти різні об'єднання, реально існуючі в організації.
При усуненні надмірності доступу велике значення мають тимчасові поки-затели. Наприклад, розглянемо ситуацію, коли необхідно змоделювати зв'язку між сутностями "Чоловік", "Жінка" і "Дитина". Очевидно, що між сутностями "Чоловік" і "Дитина" є два шляхи доступу: один - через безпосередній зв'язок "Є батьком" і інший - через зв'язку "Одружений на" і "Є матір'ю". На перший погляд показує-ся, що зв'язок "Є батьком" надлишкова. Однак це твердження може надати-ся помилковим з двох причин. По-перше, батько може мати дітей від попе-ного шлюбу, а ми моделюємо тільки поточний шлюб батька (через зв'язок 1: 1). По-друге, батько і мати можуть бути взагалі не одружені або батько може бути одружений на жінці, яка не є матір'ю даної дитини (або ж мати може бути одружена з чоловіком, який не є батьком дитини). Тому все сущест-ють взаємини не можуть бути змодельовані без використання зв'язку типу "Є батьком" (рис. 10).
^
фізичне проектування
Фаза, подальша за геологіч-ським проектуванням, називається фазою фізичного проектування. При логічному проектуванні не беруться до уваги специфічні функціональні можливості цільової бази даних і прикладних програм, однак враховуються особливості обраної моделі зберігання даних. Результатом логічного проектування є гло-бальна логічна модель даних і комплект описує її супровідній документації. У сукупності ці результати є вихідною інформацією для фази фізично-го проектування бази даних і надають її розробнику все необхідне для прийняття рішень, спрямованих на досягнення максимальної ефективності створюваного проекту.
Образно кажучи, при логічному проектуванні розробник зосереджується на тому, що треба зробити, тоді як при фізичному проектуванні він шукає спо-соб, як це зробити. У кожному разі потрібно наявність різних навичок. Так, фахівець з фізичного проектування баз даних повинен чітко уявляти, як та чи інша СУБД функціонує в комп'ютерній системі, а також добре знати всі функціональні можливості цільової СУБД. Оскільки функціональні можливості різних СУБД досить сильно відрізняються один від одного, фізич-ське проектування завжди тісно пов'язане з особливостями конкретної обраної системи. Однак етап фізичного проектування бази даних не є вдосконалення-шенно ізольованим від інших - як правило, між логічним і фізичним проектуванням є постійний зворотний зв'язок, часто охоплює і розроб-лення призначених для користувача додатків. Наприклад, рішення, прийняті на етапі фізкабінет-чеського проектування з метою підвищення продуктивності системи, можуть впливати на структуру її логічної схеми.
Методологія фізичного проектування баз даних включають-ет чотири основних етапи:
1. Розробка таблиць бази даних і установка необхідних обмежень цілісності даних.
2. Вибір схеми зберігання даних і визначення методів доступу до таблиць бази даних. Як правило, кожна СУБД надає кілька альтернативних варіантів схеми зберігання даних. Винятком є лише на-стольний СУБД для платформи IBM PC, в яких найчастіше використовується фікс-рова схема зберігання інформації. З точки зору користувача організація внутреннейструктури зберігання поміщених в таблиці даних повинна бути з-вершенно прозора - користувач повинен мати можливість отримувати доступ до будь-якої таблиці і окремим її рядках без необхідності вказівки способу зберігання цих даних. Це означає, що СУБД повинна забезпечувати повну неза-тість фізичного зберігання даних від їх логічної організації. Тільки в цьому випадку внесення змін до фізичну організацію бази даних не зробить ні-якого впливу на роботу користувачів. Відображення логічної моделі даних на структуру їх фізичної організації визначається внутрішньою схемою бази даних.
3. Проектування системи захисту бази даних від несанкціоноване-ванного доступу. Так само як прийняття рішень про методи реалізації кожної ло-кальной логічної моделі даних, а також про заходи контролю доступу до окремих таблиць бази.
4. Організація процесів моніторингу створеної сис-теми, завдання якого полягає у виявленні та усуненні будь-яких проблем, пов'язаних з продуктивністю додатків і випливають з особливостей реалізації проекту. Тут же здійснюється реалізація нових і змінюються вимог.
1. Файли даних (data file). Призначені для зберігання інформації, що знаходиться в таблицях бази даних. Крім того, в цих файлах також розміщені процедури, обмеження, тригери, індекси і інша інформація;
Будь-яка база даних повинна містити як мінімум один файл даних і один файл журналу транзакцій, тобто мінімальна кількість файлів, що складають базу даних, дорівнює 2. При необхідності адміністратор може додавати нові файли даних або файли журналу транзакцій.
^ Файли даних бувають двох типів:
- Primary File (основний, або головний, файл). Кожна база даних має один і тільки один головний файл. Якщо база даних включає в себе тільки один файл даних, то цей файл буде основним. Основний файл призначений для зберігання всіх системних таблиць, присутніх в будь-якій базі даних. В основному файлі зберігається інформація про структуру бази даних, створених в ній об'єктах, параметрах додаткових файлів і файлів журналу тран-ЗАКЦ. За замовчуванням основному файлу бази даних присвоюється розширення mdf (Master Data File);
- Secondary File (вторинний, або додатковий, файл). На відміну від основного файлу база даних може містити безліч додаткових фай-лов або не містити їх зовсім. У додаткових файлах може зберігатися тільки для користувача інформація. Зберігання будь-системної інформа-ції не допускається. В ході експлуатації бази даних адміністратор може додавати нові або видаляти вже існуючі додаткові файли.
Файли журналу транзакцій бувають тільки одного типу - Transaction Log File (файл журналу транзакцій), що служить для зберігання журналу транзакцій. У базі даних повинен бути як мінімум один файл журналу транзакцій. Для прискорення обробки транзакцій можна використовувати кілька журналів транзакцій, розташованих на різних фізичних дисках.