База данных

 

 

 

 

 

 

 

 

2.1   Функции СУБД

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

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

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

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

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

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

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

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

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

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

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

Поддержка обмена данными. СУБД должна обладать способностью к интеграции с коммуникационным программным обеспечением с целью организации доступа удаленных пользователей к централизованной БД (в рамках системы распределенной обработки).

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

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

Помимо перечисленных  возможностей, часто к СУБД предъявляются  требования поддержки еще двух сервисов, охарактеризованных ниже /Базы данных/.

Службы поддержки независимости  от данных. СУБД должна обладать инструментами поддержки независимости программ от структуры базы данных.

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

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

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

 

3. Архитектура  СУБД

СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:

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

и множестве других функций  СУБД.

При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как  создавать эти описания?

Естественно, что проект базы данных надо начинать с анализа  предметной области и выявления  требований к ней отдельных пользователей (сотрудников организации, для которых  создается база данных). Подробнее  этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

Рис. 1 Уровни моделей данных

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

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

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

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

Существует также Архитектура многопользовательских СУБД

Рассмотрим кратко различные  типовые архитектурные решения, используемые при реализации многопользовательских  СУБД, а именно: с телеобработкой, файл-серверными и клиент-серверными системами.

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

В настоящее время в  связи с развитием информационно-вычислительных сетей получили широкое распространение  файл-серверные и клиент-серверные  СУБД.

Рис 2 Топология архитектуры телеобработки

 

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