Типовая организация современной субд

Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному набору функций. Вспомним, что мы выделили следующие основные функции СУБД:

• управление данными во внешней памяти;

• управление буферами оперативной памяти;

• управление транзакциями;

• журнализация и восстановление БД после сбоев;

• поддержание языков БД.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть – ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

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

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

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

Планирование, проектирование и разработка баз данных

Типичная информационная система обычно включает такие компоненты, как:

• база данных;

• программное обеспечение баз данных;

• прикладное программное обеспечение;

• аппаратное обеспечение, в том числе устройства хранения;

• персонал, использующий и разрабатывающий эту систему.

База данных является фундаментальным компонентом информационной системы. Жизненный цикл информационной системы обычно состоит из нескольких этапов: планирование, сбор и анализ требований, проектирование, разработка, преобразование данных, эксплуатация и сопровождение.

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

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

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

• определение бизнес-планов и целей организации с последующим выделением ее потребностей в информационных технологиях;

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

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

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

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

2. Определение требований к системе. Сбор и анализ требований пользователей – определение диапазона действия и границ приложения БД, состава его пользователей и областей применения.

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

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

4. Проектирование базы данных – процесс создания базы данных, предназначенной для поддержки функционирования предприятия и способствующей достижению его целей.

Основные цели проектирования:

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

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

• разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы – например, ко времени реакции системы.

Проектировщик на основании выходных данных анализа составляет:

- схему БД, которая содержит описание всех объектов БД: таблиц, представлений, столбцов, индексов, ограничений и т.д.;

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

Спецификации должны быть подробными и содержать:

• название модуля;

• язык программирования;

• сложность;

• интерфейс вызова;

• описание - какие функциональные возможности реализует, и по какому алгоритму.

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

Результаты этапа проектирование оформляются в единый проектный документ – техническую спецификацию.

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

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

Любой проект связан с риском, поэтому желательно эти риски выявить на раннем этапе проектирования и наметить план их устранения или минимизации.

Лекция 3. Модели данных, сетевая, иерархическая, реляционная модели данных. Постреляционные и объектно-ориентированные модели данных. Обзор основных современных СУБД. Взаимодействие типа клиент-сервер. Архитектура клиент-сервер, основные принципы и характеристики.