40. БнД як автоматизована система. Види забезпечення.

9.3. БнД як автоматизована система. Види забезпечення

БнД у вузькому розумінні включає до складу дві основні компоненти:

• БД;

• СКБД - для реалізації централізованого керування даними, збереженими в базі, доступу до них, підтримання їх у стані, що відповідає стану ПО.

У широкому розуміні БнД - це АС (рис. 9.3.).

Рис. 9.3. Широке розуміння БнД

До обслуговуючого персоналу відносяться програмісти та адміністратори.

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

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

Розглядаючи дані як один з ресурсів АС, можна сказати, що БнД централізовано керує цим ресурсом в інтересах всієї системи. Наявність централізованого керування даними - головна відмінна риса БнД.

БнД - інформаційна система, що реалізує централізоване керування даних в інтересах всіх користувачів АС (засіб інтеграції даних).

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

41. Архітектура БнД.

9.4. Архітектура БнД

БнД забезпечує незалежність додатків від даних (насправді це перебільшено).

Архітектура з точки зору користувача - це те, що він може використовувати - перш за все, це інтерфейс. Кінцевого користувача не цікавить, як реалізована система. Нас, на відміну від кінцевого користувача, цікавить архітектура системи з позиції розробника.

Для нас архітектура виглядає як модель даних, а СКБД реалізує відображення (пряме і зворотнє) (рис. 9.4.).

Рис. 9.4. Відображення моделі даних у зберігаєму БД

В описі відображення, крім вказівки відповідностей між полями записів моделі та полями збережених записів, вказуються всі необхідні відомості про збережені дані: в якому коді вони представлені, як вони впорядковані, які існують індекси, де розташовані ті чи інші дані, з якими даними вони пов'язані, які методи доступу необхідно використовувати для маніпулювання збереженими даними тощо.

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

Рис. 9.5. Склад зберігаємої БД

В дійсності внутрішня модель представляє собою (рис. 9.6.):

• інфологічну модель;

• даталогічну модель.

Рис. 9.6. Склад внутрішньої моделі

Як відбувається наведене відображення? CASE-засоби підтримують інфологічну модель, а СКБД не підтримує. Даталогічна модель може робити відображення:

• СКБД робить повне відображення у БД;

• зазвичай СКБД відображає в структуру збереження операційної системи (ОС) і далі відображає у фізичну систему БД (рис. 9.7.).

Рис. 9.7. Взаємодія через файли ОС

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

На рис. 9.8. представлена архітектура БнД.

Рис. 9.8. Архітектура БнД

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

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