Архитектура построения баз данных - Разработка базы данных

СУБД имеют свою архитектуру. В процессе разработки и совершенствования СУБД предлагались различные архитектуры, но самой удачной оказалась трехуровневая архитектура, предложенная исследовательской группой ANSI/SPARC американского комитета по стандартизации ANSI (American National Standards Institute). Упрощенная схема архитектуры СУБД.

Архитектура ANSI/SPARC включает три уровня: внутренний, внешний и концептуальный. В общих чертах они представляют собой следующее.

    - внутренний уровень (также называемый физическим) наиболее близок к физическому хранилищу информации, т. е. связан со способами сохранения информации на физических устройствах. - внешний уровень (также называемый пользовательским логическим) наиболее близок к пользователям, т. е. связан со способами представления данных для отдельных пользователей. - концептуальный уровень (также называемый общим логическим или просто логическим) является "промежуточным" уровнем между двумя первыми.

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

Здесь отображено концептуальное представление простой базы данных о персонале, а также соответствующие ему внутреннее и два внешних представления (одно -- для пользователя, применяющего язык PL/I, а другое -- для пользователя, применяющего язык COBOL). Конечно, этот пример полностью гипотетичен и мало похож на реальные системы, поскольку в нем умышленно опущены многие не относящиеся к делу детали.

Рассматриваемый здесь пример нуждается в пояснениях.

На концептуальном уровне база данных содержит информацию о типе сущности с именем EMPLOYEE (служащий). Каждый экземпляр сущности EMPLOYEE включает атрибуты номера служащего EMPLOYEE_NUMBER (длиной шесть символов), номера отдела DEPARTMENT_NUMBER (длиной четыре символа) и зарплаты служащего SALARY (пять десятичных цифр).

На внутреннем уровне служащие представлены типом хранимой записи STORED_EMP, длина которой составляет 20 байт. Запись STORED_EMP содержит четыре хранимых поля: шестибайтовый префикс (возможно, содержащий управляющую информацию, такую как флаги или указатели) и три поля данных, соответствующие трем свойствам сущности, которая представляет служащего. Кроме того, записи STORED ЕМР индексированы по полю ЕМР# с помощью индекса ЕМРХ определение которого не показано.

Пользователь, применяющий язык PL/I, имеет дело с соответствующим внешним представлением базы данных. В нем каждый сотрудник представлен записью на языке PL/I, содержащей два поля (номера отделов не представляют интереса для данного пользователя, поэтому в представлении они опущены). Тип записи определен с помощью обычной структуры, соответствующей правилам языка PL/I.

Аналогично пользователь, применяющий язык COBOL, имеет дело с собственным внешним представлением базы данных, в котором каждый сотрудник представлен записью на языке COBOL, содержащей, опять же, два поля (в данном случае опущен размер оклада). Тип записи определен с помощью обычного описания на языке COBOL в соответствии с принятыми в нем стандартными правилами.

Нужно обратить внимание, что в каждом случае соответствующие элементы данных могут меть различные имена. Например, к номеру сотрудника обращаются, как к полю EMPt в представлении для языка PL/I и как к полю EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном представлении имеет имя EMPLOYEE_NUMBER, а во внутреннем представлении-- имя ЕМР#. Конечно, системе должны быть известны все эти соответствия. Например, она должна знать, что поле EMPNO в представлении для языка COBOL образовано из концептуального поля EMPLOYEE NUMBER, которое, в свою очередь, отвечает хранимому полю ЕМР# во внутреннем представлении.

В данном случае не имеет особого значения, является ли рассматриваемая система реляционной или какой-нибудь иной.

Внешний уровень -- это индивидуальный уровень пользователя. Пользователь может быть прикладным программистом или конечным пользователем с любым уровнем профессиональной подготовки. (Особое место среди пользователей занимает администратор базы данных (АБД). В отличие от остальных пользователей, АБД интересует также концептуальный и внутренний уровни.)

У каждого пользователя есть свой язык общения.

    - для прикладного программиста это либо один из распространенных языков программирования (например, PL/I, C или Java), либо специальный язык рассматриваемой системы. Такие оригинальные языки называют языками четвертого поколения на том (не вполне определенном!) основании, что машинный код, язык ассемблера и такие языки, как PL/I, можно считать языками трех первых "поколений", а оригинальные языки модернизированы по сравнению с языкам третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера. - для конечного пользователя это или специальный язык запросов, или язык специального назначения, который может быть основан на использовании форм и меню, разработан специально с учетом требований пользователя и интерактивно поддерживаться некоторым оперативным приложением.

Все эти языки включают подъязык данных, т. е. подмножество операторов всего языка, связанное только с объектами баз данных и операциями с ними. Иначе говоря, подъязык данных встроен в базовый язык, который дополнительно обеспечивает различные не связанные с базами данных возможности (такие, как локальные (временные) переменные, вычислительные операции, логические операции и т. д.). Система может поддерживать любое количество базовых языков и любое количество подъязыков данных. Однако существует один язык, который поддерживается практически всеми сегодняшними системами. Это язык SQL. Большинство систем позволяет использовать язык SQL и интерактивно, как самостоятельный язык запросов, и посредством внедрения его операторов в другие языки программирования, та кие как PL/I и Java.

Хотя с точки зрения архитектуры удобно различать подъязык данных и включающий его базовый язык, на практике они могут быть неразличимы настолько, насколько это имеет отношение к пользователю. Безусловно, с точки зрения пользователя предпочтительнее, чтобы они были неразличимы. Если они неразличимы или трудноразличимы, их называют сильно связанными. Если они ясно и легко различаются, говорят, что эти языки слабо связаны. В то время как некоторые коммерческие системы (особенно объектные системы) поддерживают сильную связь, большинство систем, в частности системы SQL, обычно поддерживают лишь слабую связь. Системы с сильной связью могли бы предоставить пользователю более унифицированный набор возможностей, но, очевидно, они требуют больше усилий со стороны системных проектировщиков и разработчиков, которые, вероятно, рассчитывают на сохранение статус-кво.

Любой подъязык данных является на самом деле комбинацией по крайней мере двух подчиненных языков -- языка определения данных (data definition language -- DDL), который поддерживает определения или объявления объектов базы данных, и языка обработки данных (data manipulation language -- DML), который поддерживает операции с такими объектами или их обработку. Например, рассмотрим пользователя языка PL/I. Подъязык данных этого пользователя включает определенные средства языка PL/I, применяемые для организации взаимодействия с СУБД.

Язык определения данных включает некоторые описательные структуры языка PL/I, необходимые для объявления объектов базы данных. Это сам оператор DECLARE (DCL), определенные типы данных языка PL/I, а также возможные специальные дополнения для языка PL/I, предназначенные для поддержки новых объектов, которые не поддерживаются существующей версией языка PL/I.

Язык обработки данных состоит из тех выполняемых операторов языка PL/I, которые передают информацию в базу данных и из нее; опять же, возможно, включая новые специальные операторы.

Отдельного пользователя интересует лишь некоторая часть всей базы данных. Кроме того, представление пользователя об этой части будет, безусловно, чем-то абстрактным по сравнению с выбранным способом физического хранения данных. В соответствии с терминологией ANSI/SPARC представление отдельного пользователя называется внешним представлением. Таким образом, внешнее представление-- это содержимое базы данных, каким его видит определенный пользователь (т. е. для каждого пользователя внешнее представление и есть та база данных, с которой он работает). Например, пользователь из отдела кадров может рассматривать базу данных как набор записей с информацией об отделах плюс набор записей с информацией о служащих и ничего не знать о записях с информацией о материалах и их поставщиках, с которыми работают пользователи в отделе снабжения.

В общем случае внешнее представление состоит из некоторого множества экземпляров каждого из многих типов внешних записей (которые вовсе не обязательно должны совпадать с хранимыми записями). Предоставляемый в распоряжение пользователя подъязык данных всегда определяется в терминах внешних записей. Например, операция выборки языка обработки данных осуществляет выборку экземпляров внешних, а не хранимых записей.

Каждое внешнее представление определяется посредством внешней схемы, которая, в основном, состоит из определений записей каждого из типов, присутствующих в этом внешнем представлении (рисунок 3.2). Внешняя схема записывается с помощью языка определения данных, являющегося подмножеством подъязыка данных пользователя. (Поэтому язык определения данных иногда называют внешним языком определения данных.) Например, тип внешней записи о работнике можно определить как шестисимвольное поле с номером работника, плюс поле из пяти десятичных цифр, предназначенное для его зарплаты, и т. д. Кроме того, может потребоваться определить отображение между внешней и исходной концептуальной схемами.

Концептуальное представление - это представление всей информации базы данных в несколько более абстрактной форме (как и в случае внешнего представления по сравнению с физическим способом хранения данных). Однако концептуальное представление существенно отличается от представления данных каким-либо отдельным пользователем. Концептуальное представление -- это представление данных такими, какими они являются на самом деле, а не такими, какими их вынужден видеть пользователь в рамках, например, определенного языка или используемого аппаратного обеспечения.

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

Концептуальное представление определяется с помощью концептуальной схемы, включающей определения для каждого существующего типа концептуальных записей (рисунок 3.2). Концептуальная схема использует другой язык определения данных -- концептуальный. Чтобы добиться независимости данных, нельзя включать в определения концептуального языка какие-либо указания о структурах хранения или методах доступа. Определения концептуального языка должны относиться только к содержанию информации. Это означает, что в концептуальной схеме не должно быть никакого упоминания о представлении хранимого файла, упорядоченности хранимых записей, индексировании, хеш-адресации, указателях или других подробностях хранения данных или доступа к ним. Если концептуальная схема действительно обеспечивает независимость данных в этом смысле, то внешние схемы, определенные на основе концептуальной, заведомо будут обеспечивать независимость данных.

Концептуальное представление -- это представление всего содержимого базы данных, а концептуальная схема -- это определение такого представления. Определения в концептуальной схеме могут включать большое количество различных дополнительных аспектов обработки данных, например таких, как ограничения защиты или требования поддержки целостности данных. В большинстве существующих систем концептуальная схема в действительности представляет собой нечто, что лишь немного больше простого объединения всех независимых внешних схем с привлечением дополнительных средств безопасности и поддержкой правил обеспечения целостности. Вероятно, со временем системы будут гораздо "интеллектуальнее" в поддержке концептуального уровня.

Третьим уровнем архитектуры является внутренний уровень.

Внутреннее представление-- это низкоуровневое представление всей базы данных как базы, состоящей из некоторого множества экземпляров каждого из существующих типов внутренних записей. Термин "внутренняя запись" относится к терминологии ANSI/SPARC и означает конструкцию, иначе называемую хранимой записью (в дальнейшем мы будем использовать именно этот термин). Внутреннее представление, так же как внешнее и концептуальное, отделено от физического уровня, поскольку в нем не рассматриваются физические записи, обычно называемые блоками или страницами, и физические области устройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее представление предполагает наличие бесконечного линейного адресного пространства. Особенности методов отображения этого адресного пространства на физические устройства хранения в значительной степени зависят от используемой операционной системы и по этой причине не включены в общую архитектуру.

Внутреннее представление описывается с помощью внутренней схемы, которая определяет не только различные типы хранимых записей, но также существующие индексы, способы представления хранимых полей, физическую упорядоченность хранимых записей и т. д. Внутренняя схема описывается с использованием еще одного языка определения данных -- внутреннего.

В некоторых исключительных ситуациях прикладные программы, в частности те, которые называются утилитами, могут выполнять операции непосредственно на внутреннем, а не на внешнем уровне. Но такая практика связана с определенным риском с точки зрения безопасности (правила безопасности игнорируются) и сохранения целостности данных (правила целостности тоже игнорируются). К тому же такая программа будет зависеть от обрабатываемых данных. Однако иногда подобный подход может быть единственным способом реализации требуемой функции или достижения необходимого быстродействия (так же, как пользователю языка высокого уровня иногда по тем же причинам необходимо прибегнуть к языку ассемблера).

Похожие статьи




Архитектура построения баз данных - Разработка базы данных

Предыдущая | Следующая