1.   Функции СУБД

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

1.1. Хранение, извлечение и обновление данных

 

Это самая фундаментальная функция СУБД. Из обсуждения, проводимого в раз­деле 2.1, ясно, что способ реализации этой функции в СУБД должен позволять скры­вать от конечного пользователя внутренние детали физической реализации системы (например, файловую организацию или используемые структуры хранения).

1.2.  Каталог, доступный конечным пользователям

 

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

•       имена, типы и размеры элементов данных;

•       имена связей;

•       накладываемые на данные ограничения поддержки целостности;

•       имена санкционированных пользователей, которым предоставлено право
доступа к данным;

•       внешняя, концептуальная и внутренняя схемы и отображения между ними
(см. раздел 2.1.4, "Схемы, отображения и экземпляры");

•       статистические данные, например частота транзакций и счетчики обраще­
ний к объектам базы данных.

Системный каталог позволяет достичь определенных преимуществ, перечислен­ных ниже.

•      Информация о данных может быть централизованно собрана и сохра­
нена, что позволит контролировать доступ к этим данным, как и к лю­
бому другому ресурсу.

•      Можно определить смысл данных, что поможет другим пользователям по­
нять их предназначение.

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

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

•      Внесенные в базу данных изменения могут быть запротоколированы.

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

•      Меры обеспечения безопасности могут быть дополнительно усилены.

•      Появляются новые возможности организации поддержки целостности
данных.

•      Может выполняться аудит сохраняемой информации.

Некоторые авторы, помимо системного каталога, выделяют каталог данных (data directory), в котором находится информация о месте и способе хранения данных. В этой книге термин "системный каталог" применяется в отношении всей информации о хранении данных. Более подробно системный каталог рассматривается в разделе 2.7, "Системные каталоги".

1.3. Поддержка транзакций

 

Транзакция представляет собой набор действий, выполняемых отдельным пользо­вателем или прикладной программой с целью доступа или изменения содержимого базы данных. Примерами простых транзакций в проекте DreamHome может служить добавление в базу данных сведений о новом сотруднике, обновление сведений о зар­плате некоторого сотрудника или удаление сведений о некотором объекте недвижи­мости. Примером более сложной транзакции может быть удаление сведений о со­труднике из базы данных и передача ответственности за все курируемые им объекты недвижимости другому сотруднику. В этом случае в базу данных потребуется внести сразу несколько изменений. Если во время выполнения транзакции произойдет сбой, например из-за выхода из строя компьютера, база данных попадает в противоречи­вое состояние, поскольку некоторые изменения уже будут внесены, а остальные — еще нет. Поэтому все частичные изменения должны быть отменены для возвращения базы данных в прежнее, непротиворечивое состояние. Более подробно обработка транзакций рассматривается в главе 17, "Управление транзакциями".

1.4. Сервисы управления параллельностью

 

Одна из основных целей создания и использования СУБД заключается в том, что­бы множество пользователей могло осуществлять параллельный доступ к совместно обрабатываемым данным. Параллельный доступ сравнительно просто организовать, если все пользователи выполняют только чтение данных, поскольку в этом случае они не могут помешать друг другу. Однако, когда два или больше пользователей од­новременно получают доступ к базе данных, конфликт с нежелательными последст­виями легко может возникнуть, например, если хотя бы один из них попытается об­новить данные. Рассмотрим параллельно выполняемые транзакции Т, и Т₂, последо­вательность выполнения которых представлена в табл. 2.3.

Таблица 2.3. Пример возникновения проблемы „потерянного обновления"

Время	Транзакция Т1	Транзакция Т2	Столбец balx
t1		Чтение (balx)	100
t2	Чтение (balx)	balx = balx + 100	100
t3	balx = Ьа1„ - 10	Запись (balx)	200
t4	Запись (balx)		90
t5			90

В транзакции ti 10 фунтов стерлингов снимается со счета, баланс которого сохра­няется в столбце bal_x, а в транзакции Т2 100 фунтов стерлингов помещается на этот же счет. Если бы транзакции выполнялись последовательно, т.е. одна за другой, без чере­дования отдельных операций, то в конечном итоге баланс был бы равен 190 фунтам стерлингов, независимо от порядка выполнения транзакций. В противном случае мо­жет возникнуть следующая ситуация. Допустим, что транзакции ti и Т2 стартовали практически одновременно и прочли исходное значение баланса, равное 100 фунтам стерлингов. Затем транзакция Т2 увеличивает это значение на 100 фунтов стерлингов (до 200 фунтов стерлингов) и сохраняет полученное значение в базе данных. Немедлен­но после этого транзакция T_t уменьшает свою копию считанного исходного значения на 10 фунтов стерлингов (до 90 фунтов стерлингов) и сохраняет полученное значение в ба­зе данных вместо только что записанного результата предыдущего обновления, вслед­ствие чего возникает эффект "потери" 100 фунтов стерлингов.

СУБД должна гарантировать, что при одновременном доступе к базе данных мно­гих пользователей подобных конфликтов не произойдет. Более подробно этот вопрос рассматривается в главе 17, "Управление транзакциями".

1.5. Сервисы восстановления

 

При обсуждении поддержки транзакций упоминалось, что при сбое транзакции база данных должна быть возвращена в непротиворечивое состояние. Подобный сбой может произойти в результате выхода из строя системы или запоминающего устрой­ства, ошибки аппаратного или программного обеспечения, которые могут привести к останову СУБД. Кроме того, пользователь может обнаружить ошибку во время вы­полнения транзакции и потребовать ее отмены. Во всех этих случаях СУБД должна предоставить механизм восстановления базы данных и возврата ее к непротиворечи­вому состоянию. Этот вопрос более подробно рассматривается в главе 17, "Управле­ние транзакциями".

1.6. Сервисы контроля доступа к данным

 

Нетрудно привести примеры, когда требуется скрыть некоторые хранимые в базе данных сведения от других пользователей. Например, менеджерам отделений компа­ний можно было бы предоставить всю информацию, связанную с зарплатой сотруд­ников, но желательно скрыть ее от других пользователей. Кроме того, базу данных следовало бы защитить от любого несанкционированного доступа. Термин безопас­ность относится к защите базы данных от преднамеренного или случайного несанк­ционированного доступа. Предполагается, что СУБД обеспечивает механизмы подоб­ной защиты данных. Более подробно меры по обеспечению безопасности рассматри­ваются в главе 16, "Защита баз данных".

 

 

1.7. Поддержка обмена данными

 

Большинство пользователей осуществляют доступ к базе данных с помощью терми­налов. Иногда эти терминалы подсоединены непосредственно к компьютеру с СУБД. В других случаях терминалы могут находиться на значительном удалении и обменивать­ся данными с компьютером, на котором располагается СУБД, через сеть. В любом слу­чае СУБД получает запросы в виде сообщений обмена данными (communications messages) и аналогичным образом отвечает на них. Все такие попытки передачи дан­ных управляются менеджером обмена данными. Хотя этот менеджер не является ча­стью собственно СУБД, тем не менее, чтобы быть коммерчески жизнеспособной, любая СУБД должна обладать способностью интеграции с разнообразными существующими менеджерами обмена данными. Даже СУБД для персональных компьютеров должны поддерживать работу в локальной сети, чтобы вместо нескольких разрозненных баз данных для каждого отдельного пользователя можно было бы установить одну центра­лизованную базу данных и использовать ее как общий ресурс для всех существующих пользователей. При этом предполагается, что не база данных должна быть распределе­на в сети, а удаленные пользователи должны иметь возможность доступа к централизо­ванной базе данных. Такая топология называется распределенной обработкой. Более подробно она рассматривается в разделе 19.1.1.

1.8. Службы поддержки целостности данных

 

Целостность базы данных означает корректность и непротиворечивость хранимых данных. Она может рассматриваться как еще один тип защиты базы данных. Поми­мо того, что данный вопрос связан с обеспечением безопасности, он имеет более ши­рокий смысл, поскольку целостность связана с качеством самих данных. Целост­ность обычно выражается в виде ограничений или правил сохранения непротиворе­чивости данных, которые не должны нарушаться в базе. Например, можно указать, что сотрудник не может отвечать одновременно более чем за десять объектов недви­жимости. В этом случае при попытке закрепить очередной объект недвижимости за некоторым сотрудником, СУБД должна проверить, не превышен ли установленный лимит, и в случае обнаружения подобного превышения запретить закрепление нового объекта за данным сотрудником.

Разумно было бы предположить, что помимо перечисленных выше восьми серви­сов, СУБД должна поддерживать еще два сервиса.

1.9. Службы поддержки независимости от данных

Понятие независимости от данных уже рассматривалось в разделе 2.1.5, "Незави­симость от данных". Обычно она достигается за счет реализации механизма под­держки представлений или подсхем. Физическая независимость от данных достига­ется довольно просто, так как обычно имеется несколько типов допустимых измене­ний физических характеристик базы данных, которые никак не влияют на представ­ления. Однако добиться полной логической независимости от данных сложнее. Как правило, система легко адаптируется к добавлению нового объекта, атрибута или связи, но не к их удалению. В некоторых системах вообще запрещается вносить лю­бые изменения в уже существующие компоненты логической схемы.

1.10.            Вспомогательные службы

 

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

•      Утилиты импортирования, предназначенные для загрузки базы данных из
плоских файлов, а также утилиты экспортирования, которые служат для
выгрузки базы данных в плоские файлы.

•      Средства мониторинга, предназначенные для отслеживания характеристик
функционирования и использования базы данных.

•      Программы статистического анализа, позволяющие оценить производи­
тельность или степень использования базы данных.

•      Инструменты реорганизации индексов, предназначенные для перестройки
индексов и обработки случаев их переполнения.

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

 

 

 

2.   Компоненты СУБД

 

СУБД является весьма сложным видом программного обеспечения, предназначенного для предоставления перечисленных в предыдущем разделе сервисов. Компонентную струк­туру СУБД практически невозможно обобщить, поскольку она очень сильно различается в разных системах. Однако при изучении систем баз данных полезно представлять себе ее обобщенную структуру в виде набора нескольких компонентов и определенных связей меж­ду ними. В этом разделе мы рассмотрим одну из возможных архитектур СУБД.

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

Основные программные компоненты среды СУБД представлены на рис. 2.6. На этой схеме также показано, как СУБД взаимодействует с другими программными компонента­ми, например с такими, как пользовательские запросы и методы доступа (т.е. методы управления файлами, используемые при сохранении и извлечении записей с данными). Файловая организация и методы доступа бегло рассматриваются в приложении Б, "Структура данных в файлах с различной организацией". Более полное описание этой темы можно найти в работах Тиори и Фрая (Teorey and Fry, 1982), Видерхольда (Weiderhold, 1983), Смита и Барнса (Smith and Barnes, 1987), а также Ульмана (Ullman, 1988).

На рис. 2.6 показаны следующие программные компоненты среды СУБД.

• Процессор запросов. Это основной компонент СУБД, который преобразует запросы в последовательность низкоуровневых инструкции для контролле­ра базы данных. Более полно функции этого компонента рассматриваются в главе 18, "Обработка запросов".

Рис. 2.6. Основные компоненты типичной системы управления ба­зами данных

•      Контроллер базы данных. Этот компонент взаимодействует с запущенны­
ми пользователями прикладными программами и запросами. Контроллер
базы данных принимает запросы и проверяет внешние и концептуальные
схемы для определения тех концептуальных записей, которые необходимы
для удовлетворения требований запроса. Затем контроллер базы данных
вызывает контроллер файлов Для выполнения поступившего запроса. Ком­
поненты контроллера базы данных показаны на рис. 2.7.

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

•      Препроцессор языка DML. Этот модуль преобразует внедренные в при­
кладные программы DML-операторы в вызовы стандартных функций базо­
вого языка. Для генерации соответствующего кода препроцессор языка
DML должен взаимодействовать с процессором запросов.

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

Контроллер словаря. Контроллер словаря управляет доступом к системно­му каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

Рис. 2.7. Компоненты контроллера базы данных

Ниже перечислены основные программные компоненты, входящие в состав кон­троллера базы данных.

•      Контроль прав доступа. Этот модуль проверяет наличие у данного пользо­
вателя полномочий для выполнения затребованной операции.

•      Процессор команд. После проверки полномочий пользователя для выпол­
нения затребованной операции управление передается процессору команд.

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

Ш Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса. Более подробно оптимизация запросов рассматрива­ется в главе 18, "Обработка запросов".

•      Контроллер транзакций. Этот модуль осуществляет требуемую обработку
операций, поступающих в процессе выполнения транзакций.

•      Планировщик. Этот модуль отвечает за бесконфликтное выполнение па­
раллельных операций с базой данных. Он управляет относительным по­
рядком выполнения операций, затребованных в отдельных транзакциях.

•      Контроллер восстановления. Этот модуль гарантирует восстановление ба­
зы данных до непротиворечивого состояния при возникновении сбоев. В
частности, он отвечает за фиксацию и отмену результатов выполнения
транзакций.

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

Последних четыре модуля подробно обсуждаются в главе 17, "Управление тран­закциями". Для воплощения базы данных на физическом уровне помимо перечис­ленных выше модулей нужны некоторые другие структуры данных. К ним относятся файлы данных и индексов, а также системный каталог. Группой DAFTG (Database Architecture Framework Task Group) была предпринята попытка стандартизации СУБД, и в 1986 году ею была предложена некоторая эталонная модель. Назначение эталонной модели заключается в определении концептуальных рамок для разделения предпринимаемых попыток стандартизации на более управляемые части и указания взаимосвязей между ними на очень широком уровне.

3.   Системные каталоги

В разделе 2.4 упомянуто, что СУБД должна иметь доступный конечному пользо­вателю системный каталог или словарь данных. В этом разделе мы познакомимся с системными каталогами более подробно.

Системный каталог СУБД является одним фундаментальных комцонентов системы. Многие перечисленные в разделе 2.5 программные компоненты строятся на использо­вании данных, хранящихся в системном каталоге. Например, модуль контроля прав доступа использует системный каталог для проверки наличия у пользователя полномо­чий, необходимых для выполнения запрошенных им операций. Для проведения подоб­ной проверки системный каталог должен включать следующие компоненты:

•      имена пользователей, для которых разрешен доступ к базе данных;

•      имена элементов данных в базе данных;

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

Другим примером могут служить средства проверки целостности данных, которые используют системный каталог для проверки того, удовлетворяет ли запрошенная операция всем установленным ограничениям поддержки целостности данных. Для выполнения этой проверки в системном каталоге должны храниться такие сведения:

•      имена элементов данных из базы данных;

•      типы и размеры элементов данных;

•      ограничения, установленные для каждого из элементов данных.

Как уже упоминалось ранее, термин "словарь данных" часто используется для программного обеспечения более общего типа, чем просто каталог СУБД. Система словаря данных может быть либо пассивной, либо активной. Активная система все­гда согласуется со структурой базы данных, поскольку она автоматически поддержи­вается этой системой. Пассивная система может противоречить состоянию базы дан­ных из-за инициируемых пользователями изменений. Если словарь данных является частью базы данных, то он называется интегрированным словарем данных. Изоли­рованный словарь данных обладает своей собственной специализированной СУБД. Его предпочтительно использовать на начальных этапах проектирования базы дан­ных для некоторой организации, когда требуется отложить на какое-то время при­вязку к конкретной СУБД. Однако недостаток этого подхода заключается в том, что после выбора СУБД и воплощения базы данных изолированный словарь данных зна­чительно труднее поддерживать в согласии с состоянием базы данных. Эту проблему можно было бы свести к минимуму, если преобразовать использовавшийся при про­ектировании словарь данных непосредственно в каталог СУБД. До недавнего времени никакого выбора не было вообще, но по мере развития стандартов словарей данных эта идея становится все более реальной. В следующем разделе кратко рассматривает­ся один из стандартов словарей данных.

3.1. Служба IRDS

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

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

Недавно была предпринята попытка стандартизовать интерфейс словарей данных для достижения большей доступности и упрощения их совместного использования. Ее результатом стала разработка службы словаря информационных ресурсов (Information Resource Dictionary System — IRDS). Служба IRDS представляет собой программный инструмент, предназначенный для управления информационными ре­сурсами организации, а также для их документирования. Она включает определение таблиц, содержащих словарь данных, и операций, которые могут быть использованы для доступа к этим таблицам. Упомянутые операции обеспечивают непротиворечи­вый метод доступа к словарю данных и способ преобразования определений данных из словаря одного типа в определения другого типа. Например, с помощью службы IRDS информация, хранимая в IRDS-совместимом словаре данных СУБД DB2, может быть передана в IRDS-совместимый словарь данных СУБД Oracle или направлена не­которому приложению системы DB2.

Одним из достоинств службы IRDS является способность расширения словаря данных. Так, если пользователь захочет сохранить определения нового типа инфор­мации в каком-то инструменте (например, определения отчетов об управлении про­ектом — в некой СУБД), то система IRDS в данной СУБД может быть расширена для включения этой информации. Определения IRDS были приняты в качестве стандарта Международной организацией стандартизации ISO (International Organization for Standardization) (ISO, 1990; 1993).

Стандарты IRDS определяют набор правил хранения информации в словаре дан­ных и доступа к ней, преследуя при этом три следующие цели:

•       расширяемость данных;

•       целостность данных;

•       контролируемый доступ к данным.

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

•       панельный интерфейс;

•       командный язык;

•       файлы экспорта/импорта;

•       прикладные программы.

Панельный интерфейс состоит из набора панелей или экранов, каждый из кото­рых предоставляет доступ к заранее описанному набору сервисов. Он несколько на­поминает язык QBE и позволяет пользователям просматривать и изменять словарь данных. Интерфейс командного языка состоит из набора команд или операторов, ко­торые позволяют выполнять манипуляции со словарем данных. Интерфейс команд­ного языка может вызываться интерактивно (с помощью терминала) или посредст­вом вйедрения операторов в программы на языках программирования высокого уровня. Интерфейс экспорта/импорта генерирует файл, который можно передавать между различными IRDS-совместимыми системами. Стандарт IRDS определяет и универсальный формат обмена информацией. Причем он не требует, чтобы база дан­ных, лежащая в основе словаря данных, соответствовала какой-то одной модели дан­ных. Именно поэтому интерфейс IRDS-сервисов способен объединять гетерогенные СУБД, как показано на рис. 2.12.

Рис. 2.12. Интерфейс IRDS-сервисов

Резюме

•      В архитектуре базы данных ANSI-SPARC используются три уровня абстрак­
ции: внешний, концептуальный и внутренний. Внешний уровень состоит из
пользовательских представлений базы данных. Концептуальный уровень яв­
ляется обобщенным представлением о структуре базы данных. Он определяет
информационное содержимое базы данных, не зависящее от способа хранения
информации. Внутренний уровень является компьютерным представлением
базы данных. Он определяет, как представлены данные, в какой последова­
тельности располагаются записи, какие созданы индексы и указатели, исполь­
зуется ли схема хеширования и какая именно.

•      Внешне концептуальное отображение преобразует запросы и результаты их
выполнения между внешним и концептуальным уровнями описания структу­
ры базы данных. Концептуально внутреннее отображение преобразует запросы
и результаты их выполнения между концептуальным и внутренним уровнями
описания структуры данных.

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

•      Подъязык данных состоит из двух частей: языка определения данных DDL
(Data  Definition   Language)   и   языка  управления   данными   DML   (Data
Manipulation Language). Язык DDL используется для описания структуры ба­
зы данных, а язык DML — для чтения и обновления самой базы данных.

•      Модель данных — это набор понятий, которые могут быть использованы для
описания множества данных, операций с данными, а также набора ограниче­
ний целостности данных. Их можно разбить на три широкие категории: объ­
ектные модели данных, модели данных на основе записей и физические моде­
ли данных. Первые две модели используются для описания данных на кон­
цептуальном и внешнем уровнях, а последняя — на внутреннем уровне.

К объектным моделям данных относятся модель "сущность-связь", семантиче­ская, функциональная и объектно-ориентированная модели, а к моделям дан­ных на основе записей — реляционная, сетевая и иерархическая модели. Концептуальное моделирование — это процесс определения архитектуры базы данных, не зависящей от таких подробностей ее реализации, как целевая СУБД, набор прикладных программ, используемые языки программирования или любые другие физические аспекты базы данных. Качество разработанной концептуальной схемы весьма критично для общего успеха создания системы, потому имеет смысл затратить необходимое количество времени и сил для подготовки максимально продуманного концептуального проекта системы. Понятие архитектуры "клиент/сервер" обозначает способ взаимодействия про­граммных компонентов (клиента и сервера), при котором клиентский процесс требует получения некоторого ресурса, а сервер его предоставляет. Обычно, клиент управляет пользовательским интерфейсом, а сервер — функциональной частью базы данных.

Системный каталог является одним из фундаментальных компонентов СУБД. Он содержит "данные о данных", или метаданные. Каталог должен быть дос­тупен пользователям. Служба IRDS (Information Resource Dictionary System) — это новый стандарт ISO, который определяет методы доступа к словарю дан­ных. При этом допускается их совместное использование и передача из одной системы в другую.

Вопросы

2.1.      Дайте определение понятию независимости от данных и объясните его значе­
ние в среде базы данных.

2.2.      Для обеспечения независимости от данных была разработана трехуровневая ар­
хитектура ANSI-SPARC. Дайте сравнительную характеристику этих уровней.

2.3.      Что такое модель данных? Дайте определение основным типам моделей данных.

2.4.      Поясните функции и общее значение концептуального моделирования.

2.5.      Опишите типы сервисов, которые должна предоставлять типичная многополь­
зовательская СУБД.

2.6.      Какие из перечисленных в ответе к упр. 2.5 сервисов не потребуются для
СУБД, функционирующей на отдельном персональном компьютере? Обоснуйте
свой ответ.

2.7.      Назовите основные компоненты СУБД и укажите соответствие между ними и
сервисами, указанными в ответе к упр. 2.5.

2.8.      Что означает термин «архитектура "клиент/сервер"»? Опишите преимущества,
которыми обладает эта схема. Сравните данную архитектуру с двумя другими
типовыми архитектурами построения СУБД.

2.9.      Опишите функции и общее значение системного каталога.