Введение в системы БД (542480), страница 20
Текст из файла (страница 20)
Второй случай — это пример системы, которую обычно называют распределенной системой баз данных. Тема распределенных баз данных сама по себе весьма обширна. Подводя сказанное к некоторому логическому завершению, отметим сле- Часть 1 Основные понятия дующее: полная поддержка распределенных баз данных означает, что отдельное приложение может "прозрачно" обрабатывать данные, распределенные между множеством различных баз данных, управление которыми осуществляют разные СУБД, работающие на соединенных коммуникационными сетями машинах разных типов с различными операционными системами.
Здесь понятие "прозрачно" означает, что приложение выполняет обработку данных с логической точки зрения так, как будто управление данными полностью осуществляется одной СУБД, работающей на единственной машине. Предоставление такой возможности может показаться невероятно трудной задачей, но весьма желанной с практической точки зрения. Производители СУБД напряженно работают, чтобы сделать подобные системы реальностью. Подробнее распределенные базы данных рассматриваются в главе 20.
Рис. 2.8. Система, в которой каждая машина одновременно яв- ляется и клиентом, и сервером Глава 2. Архитектура системы баз Данных 2.13. Резюме В этой главе системы баз данных рассматривались с точки зрения их общей архитектуры. Здесь была описана архитектура АХБ1/БРАКС, которая делит систему баз данных на три уровня следующим образом; внутренний уровень, наиболее близкий к физическому хранению (т.е. рассматривающий способ, с помощью которого данные сохраняются физически); внешний уровень, наиболее близкий к пользователям (т.е. имеющий отношение к способу представления данных для отдельных пользователей); концептуальный уровень, который является промежуточным между двумя предыдущими (он предоставляет обобщенное представление данных). Восприятие данных на каждом из уровней описывается с помощью схемы (или нескольких схем в случае внешнего уровня). Отображения описывают соответствие между заданной внешней схемой и концептуальной схемой, а также между концептуальной и внутренней схемами.
Эти отображения служат основой для соответственно логической и физической независимости данных. Пользователи, т.е. конечные пользователи и прикладные программисты, работающие на внешнем уровне, взаимодействуют с данными с помощью подъязыка данных, который включает по крайней мере два компонента: язык определения данных и язык манипулирования данными. Подъязык данных встроен в базовый язык программирования.
Замечание. Границы, разделяющие базовый язык и подъязык данных, а также язык определения данных и язык обработки данных по своей природе, в основном, умозрительны. В идеале, они должны быть прозрачны для пользователя. Здесь также детально рассматривались функции администратора базы данных и СУБД. Кроме всего прочего, АБД несет ответственность за создание внутренней схемы (физическое проектирование базы данных).
В противоположность этому за создание концептуальной схемы (логическое или концептуальное проектирование базы данных) несет ответственность администратор данных. В функции СУБД входит также реализация запросов пользователей, написанных на языке определения данных или языке обработки данных. Функцией СУБД является и поддержка словаря данных. Системы баз данных удобно рассматривать как простую структуру, состоящую из сервера (собственно СУБД) и набора клиентов (приложений). Клиент и сервер могут выполняться и зачастую выполняются на отдельных машинах, обеспечивая таким образом простейший вариант распределенной обработки данных. В общем случае каждый сервер может обслуживать много клиентов, а каждый клиент может работать со многими серверами.
Если система обеспечивает полную прозрачность доступа (т.е. клиент работает так, как будто он имеет дело с одним сервером на единственной машине, невзирая на реальное физическое положение дел), то в таком случае мы имеем настоящую распределенную систему баз данных. Упражнения 2.1. Начертите схему архитектуры системы баз данных, представленной в этой главе (архитектуры АХБ1/БРАКС). 2.2. Дайте определения следующим терминам. базовый язык отображение "концептуальный- внутренний" Чагть 1 Огнонннза понятия внешний интерфейс внешний язык определения, схема, представление внутренний язык определения„схема, представление планируемый запрос подъязык данных пользовательский интерфейс распределенная база данных распределенная обработка реорганизация выгрузка-перезагрузка загрузка данных клиент концептуальный язык определения, схема, представление логический проект базы данных сервер система базы данных и передачи дан- ных машина базы данных словарь данных менеджер передачи данных непланируемый запрос определение структуры памяти отображение "внешний— концептуальный*' утилита физический проект базы данных язык манипулирования данными язык определения данных 2.11.
89 Глава 2. Архитектура системы баз данных 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 2.10. Опишите последовательность шагов, применяемых при выборке определенного эк- земпляра внешней записи. Перечислите главные функции, выполняемые СУБД. Укажите различия между логической и физической независимостью от данных. Как вы понимаете термин метаданные? Перечислите главные функции, выполняемые АБД. Укажите различия между СУБД и системой управления файлами. Приведите несколько примеров инструментальных средств, предоставляемых раз- личными поставщиками. Приведите несколько примеров утилит базы данных. Проанализируйте любую доступную вам систему баз данных. Попытайтесь представить ее в соответствии с архитектурой АМБ1/БРАКС, как описано в этой главе.
Полностью ли она поддерживает три уровня архитектуры? Как определены отображения между уровнями? С чем схожи различные языки определения данных (внешний, концептуальный и внутренний)? Какой подъязык данных поддерживает система? Какой язык является базовым? Кто выполняет функции АБД? Имеются ли какие-нибудь средства организации защиты и поддержания целостности данных? Существует ли в системе словарь? Описывает ли он сам себя? Какие приложения, предоставляемые поставщиками, поддерживает система? Какие утилиты входят в состав системы? Есть ли в системе отдельный компонент менеджера передачи данных? Имеются ли какие-либо возможности распределенной обработки? Список литературы 90 Чпеть 1 Основные понятия 2.1.
2.3. 2.4. Хотя некоторые из перечисленных ниже изданий были выпущены давно, в них можно найти полезную информацию, которая касается понятий, представленных в этой главе. АНБ1/хз/БРАКС Бсцс!у бгоцр оп Раса Вазе Мапайеспепс Бузсевз, 1псегпп Керогс // РРТ (АСМ Б1бМОР Ьц!!ес!и). — 1975.
— 7, № 2. Р!опуз1оз С. Тз!сЬг!са!з Р.С. апсС К!ц8 А. (есЬ). ТЬе АЫБ1/ХЗ/БРАКС Ргавесчог1с: Керогг оТ СЬе Бюсту бгоцр оп Рага Вазе Мапабевепг Бузгевз // !пТоппайоп Бумевз. — 1978. — 3. Эти два документа !2.11, 12.21 — соответственно предварительный и окончательный отчеты группы АНБ!/ХЗ/БРАКС Бшс)у бгоцр. Группа АЫБ!/ХЗ/БРАКС (полное название — Бщс!у бгоцр оп Раса Вазе Мапа8евепС Бумевз) была организована в 1972 году комитетом Бсапс!агс!з Р!аппш8 апс! Кес!ц!гевепсз Сопцп!пее !БРАКС) института Авепсап Ыас!опа! Бсапссагс!з !пзбшсе оп Соврцсегз апс! !пСоппас!оп Ргосезгйп8 (АЫБ1/ХЗ).
В задачи группы входило определение того, нуждаются ли какие-либо области технологии баз данных в стандартизации (если нуждаются, то какие именно), и выработка набора рекомендуемых действий в каждой из этих областей. В процессе работы нал поставленными задачами группа пришла к выводу, что единственный подходящий объект стандартизации — интерфейсы, и в соответствии с этим определила общую архитектуру, или фундамент, системы баз данных, а также указала на важную роль подобных интерфейсов.
В окончательном отчете представлено подробное описание архитектуры и некоторых из 42 (!) указанных интерфейсов. Предварительный отчет — это более ранний документ, который представляет опрелеленный интерес, так как в нем отдельные вопросы рассмотрены более детально. Чап бг!ебшузеп 1.1.
(ес1.). Сопсерсз апс! Теппшо!обу Тог сЬе Сопсерва! БсЬева апс! сйе 1пТоппассоп Вазе // 1псегпайопа! Огйапсаас!оп Тог Бсапс!асс!!гас!оп !1БО) ТесЬвса! Керогг !БО/ТК 9007. — Зц1у, 1987. Этот документ представляет собой отчет рабочей группы Международной организации по стандартизации (!псегпас!опа! Бсапссагс! Ог8ап!засел — !БО), в который включено "определение понятий для языков концептуальных схем".
В отчете рабочей группы предложено три альтернативных подхода (точнее, три еруппы подходов) к формализации концептуальной схемы. Каждый из подходов был применен к стандартному примеру, связанному с деятельностью гипотетического управления регистрацией машин. Три группы — это подходы "сущность — атрибут— связь", подходы "бинарных связей" и подходы "интерпретируемой предикатной логики".
В отчете обсуждаются фундаментальные понятия, лежащие в основе понятия концептуальной схемы, а также излагаются принципы реализации системы, которая должным образом поддерживает концептуальную схему. Это достаточно сложный, однако очень важный документ для всех, кто серьезно интересуется концептуальным уровнем системы. Кепс %. Раса апс! Кеайсу.— Авзсегс!ав, ЫесЬег1апс!з: ЫоссЬ-Но1!апсс; 14есч 'г'огас, Ы.'т'4 Е1зеч!ег Бс!епсе, 1978.
Искусственное и немного раздражающее описание природы информации, в частности концептуальной схемы. "Эта книга представляет философию, по которой жизнь и действительность являются, в сущности, аморфными, беспорядочными, противоречивыми, непоследовательными, нерациональными и нерепрезентативными" (цитата из последней главы). Книгу можно рассматривать как краткое руководство по решению реальных проблем, с которыми трудно справиться из-за сушествуюшего формализма в базах данных, в частности из-за формализма в структурах, подобных записям, используемым в реляционном подходе. Рекомендуется ознакомиться.
2.5. Одуззеаз О. Тзата1оз, Магм!в Н. Бо!ошол, апд Уаппй Е. 1оапп14!з. ТЪе ОМАР: А Четзагйе Тоо! Тот РЪтгйса! Паса 1лт1ерелделсе. Ртос. 201Ъ 1пт. СопГ. Оп Чету Еатйе Рата Вазез. — Бапйайо, СЫ!е. — БертешЪет, 1994. Сокрашение ОМАР означает обобщенный, многоуровневый путь доступа (Оепега!!гет! Мц!11-грече! Ассезз Ратй). Авторы статьи справедливо отмечают, что современные продукты баз данных "вынуждают пользователей составлять запросы в терминах логической схемы, которая непосредственно связана с физическими структурами" и поэтому усиливают зависимость от физических данных.
В этой статье предлагается язык отображения "концептуальный-внутренний" (по терминологии данной главы), который можно использовать для значительно большего количества видов отображений, чем обычно обеспечивается в современных продуктах. Предоставляются конкретная "логическая схема" и язык, основанный на реляционной алгебре (см. главу б), и, следовательно, описательный, а не процедурный по своей природе, что позволяет описать множество физических схем, которые формально образуются из такой логической схемы. Кроме всего прочего, подобные физические схемы могут включать вертикальное и горизонтальное разделения !глава 20), произвольное количество путей физического доступа, группирование и контроль избыточности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
