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

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

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

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

Задание диапазона значений, как правило, используется для числовых полей. Диапазон допустимых значений может быть ограничен с двух сторон (закрытый диапазон), а может с какой-то одной: верхней или нижней (открытый диапазон).

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

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

Проверка на уникальность значения какого-то поля позволяет избежать записей-дубликатов. Вряд ли будет удобно в справочнике клиентов иметь несколько записей для одного и того же лица.

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

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

2.3. Словарь данных

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

В этом параграфе мы познакомимся с тем, как правильно использовать возможности словаря данных при проектировании и эксплуатации БД.

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

ошибках, сбоях и неправильном вводе данных. Вы встречали человека, размахивающего листком с распечаткой и неустанно повторяющего как молитву фразу: Это я рассчитал на компьютере! Мы встречали, и не раз.

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

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

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

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

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

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

совместное использование данных с другими пользователями;

осуществление простого и эффективного управления элементами данных при вводе в систему новых элементов или изменении описания существующих;

уменьшение избыточности и противоречивости данных;

определение степени влияния изменений в элементах данных на всю базу данных;

централизация управления элементами данных с целью упрощения проектирования базы данных и ее расширения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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