Введение в системы БД (542480), страница 15
Текст из файла (страница 15)
Тип записи определен с помощью обычного описания на языке СОВОЬ в соответствии с принятыми в нем стандартными правилами. 67 Глава 2. Архитектура системы баз данных Обратите внимание, что в каждом случае соответствующие элементы данных могут иметь различные имена. Например, к номеру сотрудника обращаются, как к полю ЕМР$ в представлении для языка РЫ и как к полю ЕМРМО в представлении для языка СОВО1.. Зтот же атрибут в концептуальном представлении имеет имя ЕМРЬОХЕЕ НОМВЕН, а во внутреннем представлении в нмя ЕМР$.
Конечно, системе должны быть известны все эти соответствия. Например, она должна знать, что поле ЕМРНО в представлении для языка СОВОЬ образовано из концептуального поля ЕМРЬОХЕЕ НОМВЕН, которое, в свою очередь, отвечает хранимому полю ЕМР$ во внутреннем прелставлении. Такие соответствия, или отображения (шарр1пЕ), явно н0 показаны на рис. 2.2 (дальнейшее обсуждение этих вопросов будет продолжено в разделе 2.6). В данном случае не имеет осо ого значения, является ли рассматриваемая система реляционной или какой-нибудь иной. Но было бы полезно вкратце рассказать, как эти три уровня архитектуры обычно реализуются именно в реляционных системах.
° Во-первых, концептуальный уровень в такой системе определенно будет реляционным в том смысле, что видимые на этом уровне объекты являются реляционными таблицами, а используемые операторы будут реляционными операторами (в частности, включая операторы выборки строк и столбцов, кратко рассмотренные в главе 1). ° Во-вторых, каждое внешнее представление, как правило, также будет реляционным или достаточно близким к нему. Например, объявления записей в РБД и СОВО(., представленные на рис.
2.2, упрощенно можно считать аналогами объявления реляционной таблицы в реляционной системе. Замечание. Между прочим, следует иметь в виду, что термин "внешнее представление" (часто — просто "представление") имеет, к сожалению, довольно специфический смысл в реляционном контексте, который не полностью совпадает со смыслом, приписанным ему в этой главе.
Выяснение реляционного смысла данного термина и его обсуждение приводятся в главах 3 и 9. ° В-третьих, внутренний уровень не будет реляционным, поскольку объекты на этом уровне не будут реляционными таблицами (сохраняемыми); наоборот, они будут объектами такого же типа, как и находящиеся на внутреннем уровне объекты любой другой системы (сохраняемые записи, указатели, индексы, хешированные значения н т.п.). В действительности реляционная модель как таковая не может сказать ничего существенного о внутреннем уровне. Она, как уже отмечалось в главе 1, имеет отношение лишь к тому, как воспринимает базу данных пользователь.
Теперь перейдем к более детааьному исследованию трех уровней архитектуры, начиная с внешнего уровня. На рис. 2.3 показаны основные компоненты архитектуры и их взаимосвязь. На этот рисунок мы будем часто ссылаться в данной главе. 2.3. Внешний уровень Внешний уровень — это индивидуальный уровень пользователя. Как было сказано в главе 1, пользователь может быть прикладным программистом или конечным пользователем с любым уровнем профессиональной подготовки.
(Особое место среди пользователей занимает администратор базы данных (АБД). В отличие от остальных пользователей, АБД интересует также концептуальный и внутренний уровни. Об этом еше будет говориться в следующих двух разделах.) У каждого пользователя есть свой язык общения. ° Для прикладного программиста это либо один из распространенных языков программирования (например, Р(Л, С++ илн )ача), либо специальный язык рассматриваемой системы. Такие оригинальные языки называют языками четвертого поколения на том (не вполне определенном!) основании, что машинный код, язык ассемблера и такие языки, как Р(./1, можно считать языками трех первых "поколений", а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера. Часть |.
Осиовкьге понятия ° Для конечного пользователя это или специальный язык запросов, нли язык специального назначения, который может быть основан на использовании форм и меню, разработан специально с учетом требований пользователя и интерактивно поддерживаться некоторым оперативным приложением (как указывалось в главе 1). Для нашего обсуждения важно, что все эти языки включают подъязык данных, т.е. подмножество операторов всего языка, связанное только с объектами баз данных и операциями с ними. Иначе говоря, подъязык данных встроен в базовый язык, который дополнительно обеспечивает различные не связанные с базами данных возможности (такие, как локальные (временные) переменные, вычислительные операции, логические операции и т.д.).
Система может поддерживать любое количество базовых языков и любое количество подъязыков данных. Однако существует один язык, который поддерживается практически всеми сегодняшними системами. Это язык БО), который кратко был представлен в главе !. Большинство систем позволяет использовать язык БРЕ и интерактивно, как самостоятельный язык запросов, и посредством внедрения его операторов в другие языки программирования, такие как РЕЛ и !ача. (Подробности приводятся в главе 4.) Хотя с точки зрения архитектуры удобно различать подъязык данных и включающий его базовый язык, на практике они могут быть неразличимы настолько, насколько это имеет отношение к пользователю.
Безусловно, с точки зрения пользователя предпочтительнее, чтобы они были неразличимы. Если онн неразличимы или трудноразличимы, их называют сильно связанными. Если они ясно и легко различаются, говорят, что эти языки слабо связаны. В то время как некоторые коммерческие системы (особеино объектные системы; см. главу 24) поддерживают сильную связь, большинство систем, в частности системы Б Н(, обычно поддерживают лишь слабую связь.
Системы с сильной связью могли бы предоставить пользователю более унифицированный набор возможностей, но, очевидно, они требуют больше усилий со стороны системных проектировщиков и разработчиков, которые, вероятно, рассчитывают на сохранение статус-кво. В принципе, любой подъязык данных является на самом деле комбинацией по крайней мере двух подчиненных языков — языка определения данных (база бейл!г!оп 1апйпайе — РРЕ), который поддерживает определения или объявления объектов базы данных, и языка обработки данных (г(а!а гпап!рп!аз!оп !апйцайе— РМЕ), который поддерживает операции с такими объектами или их обработку.
Например, рассмотрим пользователя языка РЬЛ (см. рис. 2.2). Подъязык данных этого пользователя включает определенные средства языка РЕЛ, применяемые для организации взаимодействия с СУБД. ° Язык определения данных включает некоторые описательные структуры языка РЫ1, необходимые для объявления объектов базы данных. Это сам оператор аЕСьлКЕ (ОСЬ), определенные типы данных языка Р!Л, а также возможные специальные дополнения для языка РЕЛ, предназначенные для поддержки новых объектов, которые не поддерживаются существующей версией языка Р!Л. ° Язык обработки данных состоит из тех выполняемых операторов языка Р1Л, которые передают информацию в базу данных и из нее; опять же, возможно, включая новые специальные операторы.
69 Глава 2. Архитектура системы баз данных с о 5 й $ о 2 с о 3 о 2 5 с о $з Е$$ О8 ~йй $ ~О олаф 8 $Я з с>, Е ( ~с о ь 3 6 И Е с3 о, Замечание. Из соображений точности следует отметить, что современный язык Р1Л на самом леле вообще не включает никаких особых средств для работы с базами данных.
Оператор "языка обработки данных" (оператор СййЬ), в частности, обычно просто обращается к СУБД (хотя такие обращения могут быть синтаксически скрыты, чтобы сделать их более дружественными по отношению к пользователю). Разговор о внедрении операторов языка БО будет продолжен в главе 4. Вернемся к архитектуре.
Как уже отмечалось, отдельного пользователя интересует лишь некоторая часть всей базы данных. Кроме того, представление пользователя об этой части будет, безусловно, чем-то абстрактным по сравнению с выбранным способом физического хранения данных. В соответствии с терминологией АХБРБРАКС представление отдельного пользователя называется внешним представлением. Таким образом, внешнее представление — это содержимое базы данных, каким его видит определенный пользователь (т.е. для каждого пользователя внешнее представление и есть та база данных, с которой он работает).
Например, пользователь из отдела кадров может рассматривать базу данных как набор записей с информацией об отделах плюс набор записей с информацией о служащих и ничего не знать о записях с информацией о материалах и их поставщиках, с которыми работают пользователи в отделе снабжения. В общем случае внешнее представление состоит из некоторого множества экземпляров каждого из многих типов внешних записей (которые вовсе не обязательно должны совпадать с хранимыми записями)з. Предоставляемый в распоряжение пользователя подъязык данных всегда определяется в терминах внешних записей. Например, операция выборки языка обработки данных осуществляет выборку экземпляров внешних, а не хранимых записей.
Замечание. Теперь мы видим, что термин "логическая запись'*, употреблявшийся в главе 1, на самом деле относится к внешним записям. Поэтому в дальнейшем мы будем избегать его использования. Каждое внешнее представление определяется посредством внешней схемы, которая, в основном, состоит из определений записей каждого из типов, присутствующих в этом внешнем представлении (см. рис. 2.2). Внешняя схема записывается с помощью языка определения данных, являющегося подмножеством подъязыка данных пользователя. (Поэтому язык определения данных иногда называют внешним языком определения данных.) Например, тип внешней записи о работнике можно определить как шестисимвольное поле с номером работника, плюс поле из пяти десятичных цифр, предназначенное для его зарплаты, и т.д. Кроме того, может потребоваться определить отображение между внешней и исходной концептуальной схемами (подробности — в следующем разделе).
Это отображение рассматривается в разделе 2.6. В данном случае предполагается, чта вся информация на внешнем уровне представлена в форме записей. На некоторые системы позволяют представлять информацию иначе: либо вместо записей, либо совместна с ними. Для использующих такие альтернативные методы систем все определения и пояснения этого раздела требуют соответствующих изменений. Эта замечание касается также концептуального и внутреннега уровней. Детальное обсуждение подобных вопросов в этой части книги было бы првэкдевременным, поэтому мы вернемся к ним позднее, в главах! 3 Рв особенности — в разделе кбписак литературы Э и 24.
Глава 2. Архитектура системы баз данных 2.4. Концептуальный уровень Концептуальное представление — это представление всей информации базы данных в несколько более абстрактной форме (как и в случае внешнего представления) по сравнению с физическим способом хранения данных. Однако концептуальное представление существенно отличается от представления данных каким-либо отдельным пользователем. Вообще говоря, концептуальное представление — это представление данных такими, какими они являются на самом деле, а не такими, какими их вынужден видеть пользователь в рамках, например, определенного языка или используемого аппаратного обеспечения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
