Главная » SQL, Базы данных » Архитектура системы баз данных

0

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

группой ANSI/SPARC (Study Group on Data Management Systems), — так  называемой архитектурой ANSI/SPARC [2.1], [2.2]. Однако здесь мы не будем придерживаться терминологии ANSI/SPARC во всех деталях.

Следует отметить, что материал этой главы подобен материалу предыдущей в  том

смысле, что он является основой, необходимой для полного понимания структуры и возможностей современных систем баз данных. По этой причине он также носит несколько абстрактный характер, следовательно, достаточно "академичен". Учитывая это, как и в случае изучения главы 1, предварительно можно бегло просмотреть настоящую главу, а затем, по мере освоения излагаемого в книге  материала, возвращаться к отдельным ее разделам, непосредственно связанным с той или иной изучаемой темой.

2.1.  ТРИ УРОВНЯ АРХИТЕКТУРЫ

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

Рис. 2.1. Три уровня архитектуры ANSI/SPARC

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

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

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

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

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

—  в терминах машинно-ориентированных конструкций наподобие битов и байтов.

Для лучшего понимания этих идей рассмотрим пример, представленный на рис. 2.2.

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

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

1.         На концептуальном уровне база данных содержит информацию о типе сущности с

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

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

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

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

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

Обратите внимание, что в каждом случае соответствующие элементы данных могут иметь различные имена. Например, к номеру сотрудника обращаются как к полю ЕМР# в представлении для языка PL/I и как к полю EMPNO В представлении для языка COBOL. Этот же атрибут в концептуальном представлении имеет имя  EMPLOYEE_NUMBER, а во внутреннем представлении — имя ЕМР#. Конечно, в системе должны быть известны все эти соответствия. Например, известно, что  поле EMPNO В  представлении для языка COBOL образовано из концептуального поля EMPLOYEE_NUMBER, которое, в свою очередь, отвечает хранимому полю ЕМР# ВО внутреннем представлении. Такие соответствия, или отображения (mapping), на рис. 2.2 явно не показаны (дальнейшее обсуждение этих вопросов будет продолжено в разделе 2.6).

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

■     Во-первых, концептуальный уровень в такой системе определенно будет реляци онным в том смысле, что видимые на этом уровне объекты являются реляцион ными  таблицами,  а  используемые операторы —  реляционными  операторами (включая операторы выборки строк и столбцов, кратко рассмотренные в главе 1).

■     Во-вторых, каждое внешнее представление, как правило, также будет реляцион ным или достаточно близким к нему. Например, объявления записей в PL/I и COBOL, представленные на рис. 2.2, упрощенно можно считать аналогами объяв лений таблиц в реляционной системе.

Примечание. Следует иметь в виду, что термин внешнее представление (часто — просто представление) в реляционном контексте имеет, к  сожалению, довольно специфический смысл, который не полностью совпадает со смыслом, приписанным ему в этой главе. Выяснению  реляционного смысла данного термина и его обсуждению посвящены главы 3 и (особенно) 10.

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

Теперь перейдем к более детальному исследованию трех уровней архитектуры, начиная с внешнего уровня. На рис. 2.3 показаны основные компоненты архитектуры и их взаимосвязь. На этот рисунок мы будем часто ссылаться в данной главе.

Рис. 2.3. Подробная схема архитектуры системы баз данных

2.2.  ВНЕШНИЙ УРОВЕНЬ

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

У каждого пользователя есть свой язык для работы с СУБД.

■  Для прикладного программиста это либо один из распространенных языков программирования (например, PL/I, C++ или Java), либо специальный  язык рассматриваемой системы. Такие оригинальные языки называют языками четвертого

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

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

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

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

В принципе, любой подъязык данных является на самом деле комбинацией по крайней мере двух подчиненных языков — языка определения данных (Data Definition Language — DDL), который позволяет формулировать определения или  объявления объектов базы данных, и языка манипулирования3  данными (Data  Manipulation Language — DML), который поддерживает операции с такими объектами или их обработку. Например, рассмотрим пользователя языка PL/I (см. рис. 2.2). Подъязык данных этого пользователя

2  В этом смысле языком программирования базы данных вполне можно назвать язык Tutorial D, ко торый будет использоваться в следующих главах в качестве основы для примеров (см. примечания на эту тему в предисловии к данной книге).

3  Термин "манипулирование" (буквально — выполнение действий вручную), не очень удачный,  но

получил широкое распространение и поэтому утвержден официально.

включает определенные средства языка PL/I, применяемые для организации взаимодействия с СУБД.

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

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

Примечание. В качестве уточнения следует отметить, что современный язык  PL/I на самом деле вообще не включает никаких особых средств для работы с базами данных. Оператор языка обработки данных (оператор CALL), в частности, обычно просто обращается к СУБД (хотя такие обращения могут быть синтаксически упрощены, чтобы они стали более дружественными по отношению к пользователю). Разговор о внедрении операторов языка SQL будет продолжен в главе 4.

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

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

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

4  В данном случае предполагается, что вся информация на внешнем уровне представлена в  форме записей. Но некоторые системы позволяют представлять информацию иначе: либо вместо записей, либо совместно с ними. Для использующих такие альтернативные методы систем все  определения и пояснения этого раздела требуют соответствующих изменений. Это замечание касается также концептуального и внутреннего уровней. Детальное обсуждение подобных вопросов в этой части книги было бы преждевременным, поэтому мы вернемся к ним позднее, в главах 14 (в особенности — в разделе "Список литературы") и 25. См. также приложение А (где приведена подробная информация о внутреннем уровне).

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

2.3.  КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ

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

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

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

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

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

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

2.4.  ВНУТРЕННИЙ УРОВЕНЬ

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

Внутреннее представление описывается с помощью внутренней схемы, которая определяет не только различные типы хранимых записей, но также существующие индексы, способы представления хранимых полей, физическую упорядоченность хранимых записей и т.д. (Соответствующий простой пример также приведен на рис. 2.2; см. также приложение Г.) Внутренняя схема формируется с использованием еще одного языка определения данных — внутреннего.

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

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

5 Многиесчитают,чтокэтойцелиближеподошлитак называемые системы,основанные наиспользовании делового регламента, или бизнес-правил(см.главы9и14).

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии