Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
BSBD_k_ekzamenu / материал_к_билетам_14-21 / Билет_15_вопрос_2 / Уровни_архитектуры_баз_данных.doc
Скачиваний:
20
Добавлен:
05.06.2015
Размер:
1.47 Mб
Скачать

10

ТРИ УРОВНЯ АРХИТЕКТУРЫ СИСТЕМЫ БАЗ ДАННЫХ (Дейт, 8-е изд-е, глава 2)

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

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

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

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

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

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

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

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

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

Конечно, этот пример полностью гипотетичен и мало похож на реальные сис­темы, поскольку в нем умышленно исключены многие не относящиеся к делу детали.

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

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

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

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

  2. Аналогично, пользователь, применяющий язык 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. Внешний уровень

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

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

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

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

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

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

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

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

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

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

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

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

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

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