Моделирование данных

Как уже говорилось, наиболее важная цель на стадии разработки технического задания — это создание модели данных пользователя (user data model), или моде­лирование данных (data modeling). Как бы это ни делалось — сверху вниз или

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

Моделирование данных как делание выводов

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

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

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

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

Моделирование в многопользовательских системах

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

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

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

Функции субд

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СУБД должна обладать способностью к интеграции с коммуникационным про­граммным обеспечением.

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

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

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

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

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

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

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

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

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