3.Середовище бази даних. Трьохрівнева архітектура ansi-spark. Зовнішній рівень. Концептуальний рівень.

Трьохрівнева архітектура ANSI-SPARK

Перша спроба створення стандартної термінології та загальної архітектури СУБД б ла зроблена в 1971 році групою, званою DBTG. Вона була створена після конференції CODASYL (Conference on Data Systems and Languaguages - Конференція з мов і системам даних), що пройшла в цьому ж році. Група DBTG визнала необхід ність використання дворівневого підходу, побудованого на основі використання системного уявлення, тобто схеми (schema), і користувальницьких уявлень, тобто подсхем (subschema). Подібні термінологія та архітектура були запропоновані в 1975 році Комітетом планування стандартів і норм SPARC (Standards Planning and Requirements Committee) Національного Інституту Стандартизації США (American National Standard Institute- ANSI), ANSI / X3 / SPARC (ANSI, 1975). Комітет ANSI / SPARC визнав необхідність використання трирівневого підходу. У цих матеріалах відображені пропозиції, які були зроблені організаціями Guide / Share, що складаються з користувачів продуктів корпорації IBM, і опубліковані за кілька років до цього. Основна увага в них було сконцентровано на необхідності вопло щення незалежного рівня для ізоляції програм від особливостей подання дан -них на більш низькому рівні (Guide / Share, 1970). Хоча модель ANSI / SPARC не стала стан Дартом, проте вона все ще являє собою основу для розуміння деяких функціональних особливостей СУБД. В даному випадку для нас найбільш фундаментальним моментом у цих та подальших звітах дослідницьких груп є ідентифікація трьох рівнів абстракції, тобто трьох різних рівнів опису елементів даних. Ці рівні формують трехуров невую архітектуру, яка охоплює зовнішній, концептуальний і внутрішній рівні, як показано на рис. 2.1. Мета трирівневої архітектури полягає у відділенні користувальницького уявлення бази даних від її фізичного представлення. Нижче перераховано кілька причин, за якими бажано виконувати такий поділ.

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

тих же даних, використовуючи своє власне уявлення про них. Каж

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

ня про дані, причому ця зміна не повинно впливати на

інших користувачів.

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

стями фізичного зберігання даних в базі, як індексування і хеши

вання (додаток А, "Навчальний проект Wellmeadows Hospital "). Інакше кажучи, взаємодія користувача з базою не повинно залежати від осо бенностей зберігання в ній даних.

• Адміністратор бази даних (АБД) повинен мати можливість змінювати

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

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

ний фізичних аспектів зберігання інформації, як перемикання на але ше пристрій зберігання.

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

Рівень, на якому сприймають дані користувачі ,, називається зовнішнім рівнем (external level), тоді як СУБД і операційна система сприймають дані на внутрішньому рівні (internal level). Саме на внутрішньому рівні дані реально зберігаються з використанням всіх тих структур і файлової організації, які описані в додатку нии Б, "Структура даних у файлах з різною організацією".Концептуальний рівень (conceptual level) представлення даних призначений для відображення зовнішнього рівня на внутрішній і забезпечення необхідної незалежності один від одного.

Зовнішній рівень

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

Концептуальний рівень

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

♦ Спільне та однозначне тлумачення предметної області всіма зацікавленими особами. До розробки складної бази даних залучається великий колектив: експерти, системні аналітики, проектувальники, розробники, ті, хто займа­ється впровадженням і супроводом. Усі вони повинні однозначно розуміти, чим є ПО, в чому зміст використаних понять, як вони взаємопов'язані між со­бою, які обмеження висуваються до моделі ПО тощо. Спільність понять має забезпечувати концептуальна модель.

♦ Концептуальна схема відображує лише концептуально важливі аспекти ПО, виключаючи будь-які аспекти зовнішнього або внутрішнього відображення даних. Ця модель не повинна відображувати конкретні потреби окремих ко­ристувачів або застосувань. Вона має фіксувати, чим є ПО в цілому, а не з точ­ки зору інтересів або потреб користувачів. Для отримання цілісного уявлення про ПО її модель має інтегрувати думки, погляди та інтереси окремих корис­тувачів, але саме інтегрувати, а не виражати їхні конкретні побажання.

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

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

♦ Забезпечення незалежності даних. Наявність відображень концептуальний-зовнішній і концептуальний-внутрішній дає змогу вирішувати проблему логіч­ної та фізичної незалежності даних. Будь-які зміни в тій чи іншій зовнішній моделі не повинні спричиняти зміни в концептуальній або внутрішній моде­лях. У цьому випадку має змінитися тільки відповідне відображення «кон­цептуальний-зовнішній».

♦Централізоване адміністрування. Саме через концептуальну схему здійсню­ється адміністрування баз даних.