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

Розглянемо питання створення і реалізації БД, які наведені в гл. 14 і 15, словесний опис дано в гл. 1 (приклади 1.1 і 1.2).

Мова піде про найбільш поширених реляційних операційних базах даних [27-37]. Створення об'єктно-орієнтованих баз даних має свою специфіку [38] і в цій роботі не розглядається.

Нагадаємо, що ці приклади характеризують відповідно традиційний і сучасний підходи до створення БД.

У даній главі детально обговорюється приклад 1.1 гл. 1 з його реалізацією в двох варіантах: в СУБД Access і в СУБД InterBase з використанням програмного продукту Delphi.

Перший, локальний, варіант призначений для початківців користувачів, другий, мережевий, - для "просунутих" користувачів, які знають основи програмування хоча б у рамках мови Pascal.

Другий варіант служить як би полігоном для кращого розуміння подальшої реалізації прикладу в гл. 15.

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

Відразу слід зазначити, що процедура проектування БД, як і будь-яка процедура проектування, характеризується великою кількістю неформальних факторів і тому неоднозначна. У даній роботі наводиться один із можливих варіантів проектування.

Послідовність етапів проектування показана на рис. 2.6. Розглянемо етапи більш докладно.

Аналіз вимог

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

Незабаром з'ясувалося, що БД є частиною більш складної системи, найчастіше - АСУ, тому вихідні дані слід отримувати при вивченні документообігу або при виявленні алгоритмів програми бази даних.

Перший етап отримав більш точні назви [1-6], найбільш вдалим з яких, на думку авторів, є [2] "планування бази даних".

При цьому виявилися [4] два підходи до проектування БД:

  • 1) традиційний (класичний), що сформувався в 80-і роки XX століття і вживаний досі в інформаційно-пошуковому режимі АСУ;
  • 2) сучасний, формування якого почалося в 90-і роки і триває до теперішнього часу з використанням в інформаційно-радять режимі систем підтримки прийняття рішень.

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

Другий підхід виходить з рішення задачі [44], т. Е. Від алгоритму додатки, на основі якого і створюється база даних. Під додатком розуміється програма або група програм, призначених для виконання певних однотипних робіт.

Зміна парадигми побудови БД пов'язано з тим, що побудова універсальної бази даних себе не виправдало. Розширення сфери застосування об'єктно-орієнтованого підходу і його гнучкість створили широкі можливості для інтеграції алгоритму програми та власне бази даних.

У другому підході сформувалася наступна технологія.

  • 1. Визначення мети проектування.
  • 2. Виявлення логіки додатка.
  • 3. Планування схеми зв'язків додатки (системи таблиць), іноді званої DLL-сценарієм.

Перший етап другого підходу має іншу спрямованість - побудова алгоритму додатки і системи даних для нього,

У будь-якому підході результатом першого етапу є технічне завдання (ТЗ), в якому фіксуються вимоги, пропоновані до БД. ТЗ є основою для роботи на подальших етапах проектування.

 
< Попер   ЗМІСТ   Наст >