Системы управления базами данных (субд), классификация и критерии их выбора.
Типичная структура СУБД
Среди программных компонентов современной СУБД можно выделить внутреннюю часть – ядро СУБД (Database Engine), компилятор с языка БД, интерпретатор и набор утилит. Ядро СУБД обычно представляет собой резидентную программу, работающую на сервере, надстройку над его файловой системой. Ядро управляет буферами оперативной памяти, транзакциями и журнализацией; оно обладает собственным интерфейсом, не доступным посторонним программистам напрямую, но используемым в остальных компонентах СУБД. Второй компонент – компилятор – транслирует инструкции языка баз данных, но обычно не в машинный код, зависящий от операционной системы, а в платформенно-независимый код, выполняющийся третьим компонентом СУБД – интерпретатором. Необходимость в четвёртом компоненте – утилитах СУБД – возникает вследствие низкой скорости выполнения через язык баз данных некоторых глобальных операций над БД (например, репликации (импорта/экспорта) данных, резервного копирования (backup), проверки целостности БД, переноса её на новую версию СУБД).
Если СУБД поддерживает интерфейсы доступа, основанные на другой модели данных, нежели её ядро, то в состав программных компонентов СУБД входят также отдельные серверы для каждого из этих интерфейсов. Они преобразуют запросы и их результаты между форматами СУБД и клиентских приложений: например, в объектно-реляционной СУБД обычно имеется несколько объектных серверов (отдельно для ActiveX, Java и т.п.), а в СУБД с Web-интерфейсом выделяется специальный модуль, формирующий HTML-страницы.
Среди данных СУБД, которые она хранит в файловой системе, обычно выделяются:
структурные метаданные (прежде всего, имена логических объектов БД);
метаданные-правила (ограничения целостности, процедуры, триггеры, представления);
основные данные;
данные журнала и транзакций;
параметры настроек БД.
Первый и второй тип данных (метаданные) также называют словарём данных (Data Dictionary), а второй и третий типы вместе относятся к пользовательским данным.
Стратегическое планирование БД
Переход от состояния, когда данные разрознены и находятся в личном пользовании, к совместному использованию данных значительно легче описать на словах, чем выполнить. Для достижения успеха необходимо, чтобы данные воспринимались как корпоративный ресурс. Планирование БД – стратегическая попытка определить информационные потребности организации на продолжительный период в будущем.
Операционные базы данных являются непосредственным следствием бизнес-планов.
Стратегическое планирование БД инициируется руководителями высшего уровня. Они распределяют ресурсы и назначают сотрудников, которые будут участвовать в проекте. На протяжении работы над проектом его участники взаимодействуют с руководителями всех групп пользователей. Главные конечные пользователи определяют основные процессы, виды деятельности и объекты, используемые в ручной или автоматической обработке информации. Участники проекта синтезируют эти данные в корпоративную информационную модель, которая становится частью подробного плана БД.
Жизненный цикл БД
Жизненный цикл БД – процесс проектирования, реализации и управления БД.
Жизненный цикл БД состоит из
сбора информации для определения информационных потребностей пользователей;
создания схемы базы данных (логической структуры);
выбора СУБД для поддержания БД;
выбора компьютерных программ для работы с БД;
повторного обзора потребностей пользователей в контексте созданной БД.
Являясь корпоративным ресурсом значительной ценности, БД требуют контроля и защиты. Обычно ответственность за это лежит на администрации БД. Администрация БД должна:
контролировать процесс проектирования БД;
обучать пользователей работать с базой данных;
поддерживать целостность данных;
обеспечивать удовлетворительное быстродействие системы.
Жизненный цикл системы (ЖЦС) – процедура создания системы. ЖЦС подчеркивает отождествление функции бизнеса и создания прикладных систем, выполняющих эти функции. Как замечает Мейер (Meyer, 1988) методы ЖЦС основаны на функционально-ориентированном подходе. Это означает, что система рассматривается с точки зрения тех функций, которые она выполняет, а не сточки зрения данных, которыми она оперирует. Уделяя внимание функциям, эти методы пренебрегают данными и, особенно, структурой данных, которыми оперирует система. В результате, Мейер говорит, система дает кратковременную выгоду, принося в жертву долговременные потребности пользователей. Это происходит из-за того, что вскоре после установки системы выполняемые функции оказываются лишь частью того, что в действительности нужно пользователям. Почти сразу же пользователи обнаруживают, что они хотели бы от системы еще множество дополнительных возможностей. Это требует неоднократного пересмотра и переделки.
Подход, ориентированный на данные основное внимание уделяет анализу данных, необходимых для выполнения функций. Элементы данных являются значительно более стабильной частью системы, чем выполняемые ее функции.
Этапы проектирования БД
Состоит из 6 этапов:
Предварительное планирование;
Проверка осуществимости;
Определение требований;
Концептуальное проектирование;
Реализация;
Оценка работы и поддержка БД.
Жизненный цикл создания БД
Предварительное планирование. Собирается информация:
сколько используется прикладных программ, и какие функции они выполняют;
какие файлы связаны с каждым из этих приложений;
какие новые приложения и файлы находятся в процессе создания.
Информация документируется в виде обобщенной концептуальной модели данных.
Проверка осуществимости – часть ЖЦ БД, определяющая технологическую, операционную и экономическую осуществимость плана создания БД.
Определение требований включает выбор целей БД, выяснение информационных потребностей различных отделов и руководителей компании, и требований к оборудованию и программному обеспечению. Информационные потребности выясняются с помощью анкет, опросов работников компании, а также отчетов и форм, которыми компания пользуется в текущий момент.
На этапе концептуального проектирования создаются подробные модели пользовательских представлений данных.