Ограничения целостности

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

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

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

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

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

2. Значение внешнего ключа должно либо:

1. быть равным значению первичного ключа цели;

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

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

уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 2 до 5), принадлежность набору значений (пол "М" или "Ж").

О построении инфологической модели

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

Основная сложность восприятия рекомендаций, приведенных в четвертой главе и приложении Б, чисто психологического плана.

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

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

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

 четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);

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

 плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.

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

Проектирование баз данных - процесс решения класса задач, связанных с созданием баз данных.

Содержание

Вывод:

Основные задачи проектирования баз данных

Основные задачи:

* Обеспечение хранения в БД всей необходимой информации.

* Обеспечение возможности получения данных по всем необходимым запросам.

* Сокращение избыточности и дублирования данных.

* Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

Основные этапы проектирования баз данных

* Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Такая модель строится без ориентации на какую-либо конкретную СУБД.

Основные элементы данной модели:

1. Описание объектов предметной области и связей между ними.

2. Описание информационных потребностей пользователей (описание основных запросов к БД).

3. Описание алгоритмических зависимостей между данными.

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

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

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);

2. атрибуты объектов;

3. связи между объектами;

4. основные запросы к БД.

Нормализация

Основная статья: Нормальная форма

При проектировании реляционных баз данных обычно выполняется так называемая нормализация.

Модели «Сущность - Связь»

Основная статья: ER-модель данных

Модель «сущность-связь» (англ. “Entity-Relationship model”), или ER-модель, предложенная П. Ченом[1] в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow's Foot, Information Engineering и др.).

Основные преимущества ER-моделей:

* наглядность;

* модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

* ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

* объекты (сущности);

* атрибуты объектов;

* связи между объектами.

Сущность - любой объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

* типом связи (1:1, 1:М, М:М);

* классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности – обязательный, иначе – необязательный.

Семантические модели

Семантическая модель (концептуальная модель, инфологическая модель) – модель предметной области, предназначенная для представления семантики предметной области на самом высоком уровне абстракции. Это означет, что устранена или минимизирована необходимость использовать понятия «низкого уровня», связанные со спецификой физического представления и хранения данных.

Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006:

Семантическое моделирование стало предметом интенсивных исследований с конца 1970-х годов. Основным побудительным мотивом подобных исследований (т.е. проблемой, которую пытались разрешить исследователи) был следующий факт. Дело в том, что системы баз данных обычно обладают весьма ограниченными сведениями о смысле хранящихся в них данных. Чаще всего они позволяют лишь манипулировать данными определенных простых типов и определяют некоторые простейшие ограничения целостности, наложенные на эти данные. Любая более сложная интерпретация возлагается на пользователя. Однако было бы замечательно, если бы системы могли обладать немного более широким объемом сведений и несколько интеллектуальнее отвечать на запросы пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя.

…

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

Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).

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

Информационный объект — это описание некоторой сущности (явления, реального объекта, процесса) в виде совокупности логически связанных реквизитов. Например, информационный объект Студент описывает некоторую сущность — студент. Реквизитный состав этого информационного объекта, т. е. его структура, следующий: № группы, ФИО, № зачетной книжки, дата рождения. Информационный объект имеет множество реализаций — экземпляров.

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

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

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

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

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

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

* Для каждой таблицы определить ключевые поля; установить связи между таблицами; для каждой связи определить тип.

* Разработать структуру каждой таблицы: перечень полей, их типы и свойства.

* Заполнить таблицы данными.

* Разработать необходимые запросы к БД, входные и выходные формы и отчеты.

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

Литература

* Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4

* Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4

* Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4

* Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2

* Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4

* Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X

Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.

Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.

Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.

Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с.

Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.

Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.

Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.

Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990. – 386 с.

Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.

Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика,

1985. – 344 с.