Аномалии обновления (UPDATE)

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

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

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

Аномалии удаления (DELETE)

При удалении некоторых данных может произойти потеря другой информации. Например, если закрыть проект "Космос" и удалить все строки, в которых он встречается, то будут потеряны все данные о сотруднике Петрове. Если удалить сотрудника Сидорова, то будет потеряна информация о том, что в отделе номер 2 находится телефон 33-22-11. Если по проекту временно прекращены работы, то при удалении данных о работах по этому проекту будут удалены и данные о самом проекте (наименование проекта). При этом если был сотрудник, который работал только над этим проектом, то будут потеряны и данные об этом сотруднике.

Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).

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

Задание для самостоятельной работы

1. На примере из базы данных Магазин, в которой хранится информация о продуктах, продавцах и поставщиках

рассмотреть аномалии БД.

2. Предложить изменения в БД «Объединение кооперативов» для исключения аномалий, рассмотренных в примере.

Контрольные вопросы

1. Определить понятие реляционной базы данных.
2. Каково назначение ключевых полей в базе данных?
3. Какие виды связей между отношениями возможны?
4. Как в реляционной базе данных можно обойти необходимость создания связей вида М:М?
5. Какие ограничения сущностной целостности реляционной базы данных существуют?
6. Какие ограничения ссылочной целостности реляционной базы данных существуют?

Тема 4. Проектирование БД

Для формального описания данных выявлено несколько уровней абстракции, каждый из которых отражает определенную точку зрения на данные. В литературе отмечают различное число уровней [1, 2]. Примем к рассмотрению трехуровневую модель представления данных:

Рис. 4. Соответствие абстрактных уровней и моделей представления данных

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

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

II-й уровень - концептуальный (логический), является обобщенным представлением данных всех пользователей в абстрактной форме. Концептуальная модель отображает предметную область в виде взаимосвязанных объектов без указания способов их физического хранения. Для представления данных на этом уровне служат разнообразные модели: модель “сущность - связь” (ER-модель, модель Чена), бинарные и инфологические модели, семантические сети. Концептуальные модели подробно изложены в кн. Цикритзис Д., Лоховски Ф. Модели данных. М:.Финансы и статистика, 1985г.

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

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

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