Розділ З. ДАТАЛОГІЧНЕ ПРОЕКТУВАННЯ
3.1. ПОНЯТТЯ ДАТАЛОГІЧНОГО ПРОЕКТУВАННЯ
На етапі даталогічного проектування здійснюється перехід від інфологічної моделі ПО до логічної (даталогічної) моделі, яка підтримується засобами конкретної СУБД. Процес переходу від інфологічної до даталогічної моделі називається відображенням.
Даталогічна модель являє собою базу даних, структуровану на логічному рівні й орієнтовану на конкретну СУБД. Перш ніж виконати даталогічне проектування, необхідно вибрати СУБД. Кожна конкретна СУБД накладає ряд обмежень на побудову логічної моделі даних, тому насамперед необхідно вивчити специфіку і особливості СУБД, виявити всі фактори, які можуть вплинути на логічну модель БД.
Основними факторами, що впливають на даталогічне проектування з боку СУБД, є такі:
1. Тип логічної моделі, що його підтримує вибрана СУБД. Зараз найпоширенішими на ринку програмних засобів і в практиці автоматизації економічних розрахунків є реляційні СУБД. Крім реляційних моделей існують ієрархічні й сіткові моделі баз даних.
2. Особливості фізичної організації даних у середовищі вибраної СУБД. Наприклад, у СУБД Paradox чи dBASE-системах база даних організована у вигляді набору взаємозв'язаних файлів форматів DT і DBF, усі інші об'єкти, такі як форми та звіти, також зберігаються в окремих файлах. У середовищі СУБД Microsoft Access усі дані та інструментальні засоби роботи з ними зберігаються в єдиному файлі бази даних. Тому при проектуванні бази даних потрібно знати не лише правила побудови логічної, а й особливості фізичної організації бази даних.
3. Кількісні обмеження, які накладає СУБД (наприклад, кількість рівнів ієрархії в ієрархічних моделях, можлива кількість полів, записів, файлів тощо).
Усе ще не знайдено формалізованих методів, які б давали змогу однозначно виконати даталогічне проектування. Тому його результат багато в чому залежить від уміння та рівня кваліфікації спеціалістів, які здійснюють проектні розробки.
В результаті даталогічного проектування можна отримати кілька варіантів побудови логічної моделі даних. Тому важливим моментом є оцінка отриманих моделей і вибір найбільш оптимального варіанта. Отриманий результат передусім потрібно оцінити з точки зору відповідності наявним машинним ресурсам. У разі невідповідності цим обмеженням потрібно здійснити перепроектування БД. Крім того, на отриманій моделі необхідно перевірити умови виконання всіх запитів користувачів і вимог прикладних програм, тобто умову адекватності логічної моделі інформаційній моделі предметної області
3.2. ВІДОБРАЖЕННЯ НА РЕЛЯЦІЙНУ МОДЕЛЬ
Ураховуючи те, що даталогічне проектування — це проектування в середовищі конкретної СУБД, розглянемо цей процес для дуже поширених на практиці СУБД типу dBASE. У середовищі цього класу СУБД база даних зберігається у вигляді файлів, що називаються реляційними відношеннями Тому при відображенні інфологічної моделі на реляційну інформаційні об'єкти потрібно трансформувати в реляційні відношення, врахувавши такий момент.
Якщо між об'єктами існує зв'язок 1-1 і клас членства підпорядкованого об'єкта обов'язковий і об'єкти семантичне споріднені, то теоретично можливо об'єднати їх в одне реляційне відношення. Таке об'єднання зменшує обсяг пам'яті для зберігання відношення за рахунок виключення дублювання ключових атрибутів, а також може прискорити пошук при реалізації запитів. Але цим засобом не слід зловживати, тому що проектувальник не може на сто відсотків бути впевненим, що кожний із цих об'єктів не знадобиться окремо для реалізації якихось запитів, які з'являться в системі пізніше, що може ускладнити їх реалізацію.
Власне кажучи, при відображенні на реляційну модель перепроектовувати інформаційні об'єкти, якщо не було допущено помилок на етапі інфологічного проектування, не потрібно. Тобто інформаційні об'єкти інфологічної моделі стають реляційними відношеннями. Необхідно лише перевірити виконання таких умов.
1. Усі атрибути відношень мають бути атомарними, тобто неподільними
2. Відношення не повинно мати дублюючих рядків і стовпчиків
3. Усі атрибути у відношенні повинні мати унікальні імена. При відображенні на реляційну модель слід ураховувати особливість конкретної реляційної СУБД. СУБД сім'ї dBASE не підтримують статичних зв'язків між реляційними відношеннями, тому для таких систем недоцільно будувати схему бази даних У середовищі таких СУБД зв'язки між відношеннями носять не статичний, а динамічний характер, тобто встановлюються лише для розв'язування конкретної задачі та існують на період її розв'язування. Тому при відображенні інфологічної моделі на реляційну всі структурні зв'язки не описують у явному вигляді, а лише виконують перевірку на можливість установлення цих зв'язків Обов'язковою умовою встановлення зв'язку між двома реляційними відношеннями є наявність у них хоча б одного спільного атрибута, що є ключем, за яким виконується зв'язок.
Якщо вибрана СУБД підтримує зв'язки, то при відображенні інфологічної моделі на датологічну