Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /var/www/nelvin/data/www/ebooktime.net/index.php:6) in /var/www/nelvin/data/www/ebooktime.net/index.php on line 7

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/www/nelvin/data/www/ebooktime.net/index.php:6) in /var/www/nelvin/data/www/ebooktime.net/index.php on line 7
5.1.2. Архітектура СУБД : Автоматизоване робоче місце менеджера : Бібліотека для студентів

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


Повернутися на початок книги
1 2 3 4 5 6 7 8 9 10 11 12 13 14 
15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 
45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 
60 61 62 63 64 65 66 67 68 69 

магниевый скраб beletage

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

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

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

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

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

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

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

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

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

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

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

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

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

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

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

Предметна область

(частина реального світу, яка відображується у базі даних)

Моделі та

описи, які

використову

є СУБД

{

Даталогічна модель даних

Опис на мові конкретної СУБД

--------и

Фізична модель даних

Опис даних, які зберігаються

тг

БАЗА ДАНИХ

.3.

Рівні моделей даних

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

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

Інфологічна модель відображає реальний світ в деякі зрозумілі людині концепції, повністю незалежні від параметрів середовища зберігання даних. Існує безліч підходів до побудови таких моделей: графові моделі, семантичні мережі, модель «суть-зв’язок» і т. ін. Найпопулярнішою з них виявилася модель «суть-зв’язок», яка буде розглянута нижче.

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

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

Мережеві моделі також створювалися для мало ресурсних ЕОМ. Це достатньо складні структури, що складаються з «наборів» — так званих дворівневих дерев. «Набори» з’єднуються за допомогою

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

«записів-зв’язок», утворюючи ланцюжки і т.ін. Один із розробників операційної системи ШІХ сказав «Мережева база — це найвірні-ший спосіб втратити дані».

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

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