Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Методологія проектування баз даних

В процесі розробки бази даних як складової частини інформаційної системи розробникам необхідно пройти ряд етапів, багато з яких описані в попередніх розділах і будуть розглядатися далі. Ці етапи складають методологію розробки бази даних, формуючи максимально повний опис технологій подання, зберігання і обробки даних комп'ютерними системами.

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

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

Кошти, виділені в розробці бази даних підходи: класичний (від документів) і функціонально-об'єктний (від функцій і об'єктів), - реалізують єдину методологію проектування бази даних, визначаючи, в залежності від обраного підходу, ключовий елемент аналізу - документ або об'єкт відповідно.

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

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

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

Основу функціонально-об'єктного підходу до розробки бази даних становить усвідомлення потреб користувачів системи у виконанні окремих функціональних завдань, які, як з цеглинок, складають комплексну функціональну середу діяльності користувача. Цей підхід, виділяючи окремі функції предметної області і розділяючи їх на основні та допоміжні, дає можливість розробнику підходити до процесу проектування, розглядаючи функції у вигляді самостійних блоків (чорний ящик) і об'єднуючи їх в "будова", що називається "інформаційна система". В результаті використання даного підходу процес проектування інформаційної системи представляється послідовністю, показаної на рис. 2.36.

image76

Мал. 2.36. Процес розробки інформаційної системи


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

Якщо розглядати цей процес у рамках використання інструментальних засобів розробки баз даних (наприклад, IBM InfoSphere Data Architect), то створюється одна область моделювання логічної моделі бази даних і в рамках цієї моделі для кожної функції створиться окрема діаграма. В результаті виходить, що всі створені в рамках однієї діаграми суті будуть доступні для інших діаграм цієї ж логічної моделі бази даних. Аналогічно даний процес представляється в інших засобах моделювання баз даних з можливою зміною назв окремих елементів, наприклад: в СА ERWin Data Modeler для побудови діаграм за функціями використовуються елементи, звані "робоча область".

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

image77

Мал. 2.37. Процес моделювання бази даних при функціонально-об'єктних підході


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

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

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

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

 
<<   ЗМІСТ   >>