Архітектура СУБД

СУБД повинна надавати доступ до даних будь-яким користувачам, включаючи і тих, які практично не мають і (або) не хочуть мати уявлення про:

§ фізичне розміщення в пам'яті даних та описів;

§ механізми пошуку даних, що в процесі запиту;

§ проблеми, що виникають при одночасному запиті одних і тих же даних багатьма користувачами (прикладними програмами);

§ способи забезпечення захисту даних від некоректних оновлень і (або) несанкціонованого доступу;

§ підтримку баз даних в актуальному стані;

§ та безліч інших функцій СУБД.

При виконанні основних з цих функцій СУБД повинна використовувати різні описи даних. А як створювати ці описи?

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

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

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

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

Рис.5.6. Можливі типи зв’язку

Характер зв'язків між сутностями не обмежується переліченими. Існують і складніші зв'язки(Рис.5.7.):

Рис.5.7.Безліч зв'язків між однією і тією ж сутністю

(пацієнт, маючи одного лікаря, який його лікує, також може мати кількох лікарів-консультантів; лікар може лікувати одних пацієнтів, а також давати консультації кільком іншим)(Рис.5.8.);

Рис.5.8. Тринарні зв'язки

(лікар може дати направлення кільком пацієнтам здавати кілька аналізів, аналіз може бути призначений кількома лікарями кільком пацієнтам і пацієнт може бути призначений на кілька аналізів кількома лікарями);

§ зв'язки вищих порядків, семантика (значення) яких іноді дуже складна.

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

СУТЬ (атрибут 1, атрибут 2,..., атрибут n)

АСОЦІАЦІЯ [СУТЬ S1, СУТЬ S2,...]

(атрибут 1, атрибут 2,..., атрибут n)

де S – ступінь зв'язку, а атрибути, що належать до ключа, повинні бути виділені підкресленням.

Так, розглянутий вище приклад з безліччю зв'язків між суттю, може бути описаний на МІМ таким чином:

Лікар (Номер_лікаря, Прізвище, Ім'я, По батькові, Спеціальність)

Пацієнт (Реєстраційний_номер, Номер ліжка, Прізвище,

Ім'я, По батькові, Адреса, Дата народження, Стать)

Лікар, що лікує [Лікар 1, Пацієнт M]

(Номер_лікаря, Реєстраційний_номер)

Консультант [Лікар M,Пацієнт N]

Дата добавления: 2014-01-03