Избыточность данных и аномалии обновления

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

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

Этапы концептуального проектирования:

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

Охват предметной области данного предприятия.

· Определение типов сущностей.

Определение основных типов сущностей, которые требуются для конкретного представления.

· Определение типов связей.

Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе.

· Определение атрибутов и связывание их с типами сущностей и связей.

Связывание атрибутов с соответствующими типами сущностей или связей.

· Определение доменов атрибутов.

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

· Определение атрибутов, являющихся потенциальными и первичными ключами.

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

· Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

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

· Проверка модели на отсутствие избыточности.

Проверка на отсутствие какой-либо избыточности данных в модели.

· Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

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

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

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

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

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

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

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

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

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

В случае реляционной модели данных под этим подразумевается следующее:

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

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

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

Этапы методологии физического проектирования баз данных:

1. Перенос глобальной логической модели данных в среду целевой СУБД.

2. Проектирование основных отношений.

3. Разработка способов получения производных данных.

4. Реализация ограничений предметной области.

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

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

9. Определение требований к дисковой памяти.

10. Проектирование пользовательских представлений.

11. Разработка механизмов защиты.

12. Обоснование необходимости введения контролируемой избыточности.

13. Текущий контроль и настройка операционной системы.