Проектування баз даних
24


Розділ З. ДАТАЛОГІЧНЕ ПРОЕКТУВАННЯ

3.1. ПОНЯТТЯ ДАТАЛОГІЧНОГО ПРОЕКТУВАННЯ

На етапі даталогічного проектування здійснюється перехід від інфологічної моделі ПО до логічної (даталогічної) моделі, яка підтримується за­собами конкретної СУБД. Процес переходу від інфологічної до датало­гічної моделі називається відображенням.

Даталогічна модель являє собою базу даних, структуровану на логічному рівні й орієнтовану на конкретну СУБД. Перш ніж виконати даталогічне проектування, необхідно вибрати СУБД. Кожна конкретна СУБД накладає ряд обмежень на побудову логічної моделі даних, тому на­самперед необхідно вивчити специфіку і особливості СУБД, виявити всі фактори, які можуть вплинути на логічну модель БД.

Основними факторами, що впливають на даталогічне проектування з боку СУБД, є такі:

1. Тип логічної моделі, що його підтримує вибрана СУБД. Зараз най­поширенішими на ринку програмних засобів і в практиці автоматизації економічних розрахунків є реляційні СУБД. Крім реляційних моделей іс­нують ієрархічні й сіткові моделі баз даних.

2. Особливості фізичної організації даних у середовищі вибраної СУБД. Наприклад, у СУБД Paradox чи dBASE-системах база даних організована у вигляді набору взаємозв'язаних файлів форматів DT і DBF, усі інші об'єкти, такі як форми та звіти, також зберігаються в окремих фай­лах. У середовищі СУБД Microsoft Access усі дані та інструментальні засо­би роботи з ними зберігаються в єдиному файлі бази даних. Тому при проектуванні бази даних потрібно знати не лише правила побудови логічної, а й особливості фізичної організації бази даних.

3. Кількісні обмеження, які накладає СУБД (наприклад, кількість рівнів ієрархії в ієрархічних моделях, можлива кількість полів, записів, файлів тощо).

Усе ще не знайдено формалізованих методів, які б давали змогу одноз­начно виконати даталогічне проектування. Тому його результат багато в чому залежить від уміння та рівня кваліфікації спеціалістів, які здійснюють проектні розробки.

В результаті даталогічного проектування можна отримати кілька варіантів побудови логічної моделі даних. Тому важливим моментом є оцінка отриманих моделей і вибір найбільш оптимального варіанта. Отриманий результат передусім потрібно оцінити з точки зору відпо­відності наявним машинним ресурсам. У разі невідповідності цим обме­женням потрібно здійснити перепроектування БД. Крім того, на отриманій моделі необхідно перевірити умови виконання всіх запитів користувачів і вимог прикладних програм, тобто умову адекватності логічної моделі інформаційній моделі предметної області

3.2. ВІДОБРАЖЕННЯ НА РЕЛЯЦІЙНУ МОДЕЛЬ

Ураховуючи те, що даталогічне проектування — це проектування в середовищі конкретної СУБД, розглянемо цей процес для дуже поширених на практиці СУБД типу dBASE. У середовищі цього класу СУБД база да­них зберігається у вигляді файлів, що називаються реляційними відно­шеннями Тому при відображенні інфологічної моделі на реляційну інформаційні об'єкти потрібно трансформувати в реляційні відношення, врахувавши такий момент.

Якщо між об'єктами існує зв'язок 1-1 і клас членства підпорядкованого об'єкта обов'язковий і об'єкти семантичне споріднені, то теоретично мож­ливо об'єднати їх в одне реляційне відношення. Таке об'єднання зменшує обсяг пам'яті для зберігання відношення за рахунок виключення дублюван­ня ключових атрибутів, а також може прискорити пошук при реалізації запитів. Але цим засобом не слід зловживати, тому що проектувальник не може на сто відсотків бути впевненим, що кожний із цих об'єктів не знадо­биться окремо для реалізації якихось запитів, які з'являться в системі пізніше, що може ускладнити їх реалізацію.

Власне кажучи, при відображенні на реляційну модель перепро­ектовувати інформаційні об'єкти, якщо не було допущено помилок на етапі інфологічного проектування, не потрібно. Тобто інформаційні об'єкти інфологічної моделі стають реляційними відношеннями. Необхідно лише перевірити виконання таких умов.

1. Усі атрибути відношень мають бути атомарними, тобто неподіль­ними

2. Відношення не повинно мати дублюючих рядків і стовпчиків

3. Усі атрибути у відношенні повинні мати унікальні імена. При відображенні на реляційну модель слід ураховувати особливість конкретної реляційної СУБД. СУБД сім'ї dBASE не підтримують статич­них зв'язків між реляційними відношеннями, тому для таких систем недо­цільно будувати схему бази даних У середовищі таких СУБД зв'язки між відношеннями носять не статичний, а динамічний характер, тобто встанов­люються лише для розв'язування конкретної задачі та існують на період її розв'язування. Тому при відображенні інфологічної моделі на реляційну всі структурні зв'язки не описують у явному вигляді, а лише виконують пере­вірку на можливість установлення цих зв'язків Обов'язковою умовою встановлення зв'язку між двома реляційними відношеннями є наявність у них хоча б одного спільного атрибута, що є ключем, за яким виконується зв'язок.

Якщо вибрана СУБД підтримує зв'язки, то при відображенні інфологі­чної моделі на датологічну