Фізичний рівень

Рис. 5.2.

Ієрархія схем і рівнів баз даних в інформаційних системах

Коло даних окремого користувача, тобто таблиць, з якими він має право працювати, утворює зовнішню схему БД. В ІС існує єдина концептуальна схема і декілька зовнішніх схем БД. Характерним є те, що концептуальна схема не є простим поєднанням зовнішніх

схем. Розраховані на велику кількість користувачів дані (ситуація з таблицею «С» на рис. 6.2.2) в концептуальній моделі відображаються одноразово з додатковими обмеженнями на допуск до даних (повно- важеннями). Крім того, в концептуальній схемі відображаються логічні взаємозв’язки (відносини) між елементами даних на рівні по- лів (елементів даних).

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

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

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

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

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

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

• способи забезпечення захисту даних від некоректних оновлень і

(або) несанкціонованого доступу;

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

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

При виконанні основних з цих функцій СУБД повинна викори-

стовувати різні описи даних. А як створювати ці описи?

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

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

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

Така людино-орієнтована модель повністю незалежна від фізи-

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

Решта моделей, зображених на рис. 5.3, є комп’ютерно-орієнто-

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

Оскільки зазначений доступ здійснюється за допомогою конк-

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