Трьохрівнева архітектура 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) представлення даних призначений для відображення зовнішнього рівня на внутрішній і забезпечення необхідної незалежності один від одного.