Russian Belarusian English German Japanese Ukrainian

Rashka.studio - игры и приложения для Android! Заходи, ждём тебя =)

Проблемы и подходы к проектированию

CuBook05

Проектирование реляционной БД заключается в разработке структуры данных, т.е. в определении состава таблиц и связей между ними. При этом структура данных должна быть эффективной и обеспечивать:
  • быстрый доступ к данным;
  • отсутствие дублирования (повторения) данных;
  • целостность данных.
Проектирование структуры данных (структуры БД) называют также логическим проектированием, или проектированием на логическом уровне.
 
При проектировании структур данных можно выделить три основных подхода:
  • сбор информации об объектах решаемой задачи в рамках одной таблицы (одного отношения) и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе нормализации отношений;
  • формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, а затем получение с помощью средств автоматизации разработки программного обеспечения (CASE-средств) схемы БД или прикладной информационной системы;
  • структурирование информации в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
Рассмотрим первый подход к проектированию структур данных, как исторически более ранний и являющийся классическим. Проиллюстрируем его на примере проектирования БД, содержащей сведения о сотрудниках фирмы.
 
Естественным является сбор информации об объектах решаемой задачи (в нашем случае о людях, работающих в одном институте) и размещение ее в одной глобальной таблице. Делается это просто: берется самый общий объект (работник института), для него выделяются атрибуты (характеризующие его свойства с учетом задач, стоящих перед БД) и все это организуется в единую таблицу (табл. 1.1).
 

Таблица 1.1. Сотрудники института

Фамилия, инициалы Должность Дата рождения Оклад по должности Ученая степень Надбавка за степень Телефон
Петров И. И. Директор 11.05.44 12 000 Д. т. н. 1500 990-42-90
Сидоров А. А. Зам, директора 12.07.48 8000 К. т. н. 900 777-12-88
Столяров И. И. Зав. лаб. 03.02.51 6000 Д. т. н. 1500 123-33-44
Орлов Г. Н. Научный сотрудник 06.11.68 2500 333-99-00
 
Недостатками такой уникальной таблицы являются:
  • жесткость (обязательная модификация самой таблицы при изменении постановки задачи, например, если потребуется хранить данные о количестве и именах детей сотрудников);
  • избыточность данных (под избыточностью понимают дублирование данных, содержащихся в БД) и, как следствие, потенциальная противоречивость и повышенный расход ресурсов.
При выполнении операций с данными избыточность приводит к различным аномалиям нарушению целостности БД. Выделяют следующие аномалии:
  • удаления;
  • обновления;
  • ввода.
Различают простое (неизбыточное) дублирование и избыточное дублирование данных.
Примером неизбыточного дублирования может служить список внутренних телефонов сотрудников организации (табл. 1.2). Такое дублирование является естественным и допустимым.
 
Таблица 1.2. Пример неизбыточного дублирования
Сотрудник Телефон
Иванов А. А. 12-36
Петров П. П. 12-36
Сидоров С. С. 45-62
Кузнецов К. К. 78-91
Васин В. В. 12-36
 
В приведенном примере три сотрудника имеют одинаковый номер телефона 12-36, это может быть, например, в случае, когда они находятся в. одной комнате. Таким образом, номер телефона в таблице дублируется, однако для каждого сотрудника этот номер является уникальным. В случае удаления одного из дублированных значений номера телефона (удаления соответствующей строки таблицы) будет потеряна информация о фамилии сотрудника Иванова А. А., Петрова П. П. или Васина В. В., что является аномалией удаления.
 
При смене номера телефона в комнате его нужно изменить для всех сотрудников, которые в ней находятся. Если для какого-либо сотрудника этого не сделать, например, для Петрова П. П., то возникает несоответствие данных, называемоеаномалией обновления.
 
Аномалия ввода заключается в том, что при вводе в таблицу новой строки для ее полей могут быть введены недопустимые значения. Например, значение не входит в заданный диапазон или не задано значение поля, которое в обязательном порядке должно быть заполнено (не может быть пустым).
 
Рассмотрим пример избыточного дублирования данных. Список телефонов (табл. 1.3) дополним номерами комнат, в которых находятся сотрудники. При этом номер телефона укажем только для одного из сотрудников в примере для Иванова А. А., который находится в списке первым. Вместо номеров телефонов других сотрудников этой комнаты поставлен прочерк. На практике кодировка прочерка зависит от особенностей конкретной таблицы, например, можно обозначать прочерк значением Null.
 

Таблица 1.3. Пример избыточного дублирования

Сотрудник Комната Телефон
Иванов А. А. 17 12-36
Петров П. П. 17 12-36
Сидоров С. С. 22 45-62
Кузнецов К. К. 8 78-91
Васин В. В. 17 12-36
 
При таком построении таблицы появляются проблемы. При определении номера телефона сотрудника необходимо произвести его поиск в другой строке таблицы (по номеру комнаты).
При запоминании таблицы для каждой строки отводится одинаковая память вне зависимости от наличия или отсутствия прочерков.
 
При удалении строки с данными сотрудника, для которого указан номер телефона комнаты (в примере Иванова А. А.), будет утеряна информация о номере телефона для всех сотрудников этой комнаты.
Если вместо прочерков указать номер телефона, то избыточное дублирование все равно остается. От него можно избавиться, например, с помощью разбиения таблицы на две новых (табл. 1.4 и 1.5). Разбиение (декомпозиция) - это процесс деления таблицы на несколько с целью поддержания целостности данных, т.е. устранения избыточности данных и аномалий. Таблицы связаны между собой по номеру комнаты. Для получения информации о номере телефона сотрудника из первой таблицы по фамилии сотрудника нужно считать номер его комнаты, после чего из второй по номеру комнаты считывается номер телефона.
 

Таблица 1.4. Список сотрудников и номеров комнат

Сотрудник Комната
Иванов А. А. 17
Петров П. П. 17
Сидоров С. С. 22
Кузнецов К. К. 8
Васин В. В. 17
 
Таблица 1.5. Список номеров комнат и телефонов
Комната Телефон
17 12-36
22 45-62
8 78-91
 
Рассмотренное разбиение таблицы на две является примером нормализации отношений. При этом избыточность данных уменьшилась, однако одновременно увеличилось время доступа к ним. Для получения номера телефона сотрудника теперь необходимо работать с двумя таблицами, а не с одной, как в предыдущем случае.
Отметим, что для сотрудников указывается номер комнаты, который приводит к неизбыточному дублированию данных. Как указано выше, такое дублирование является приемлемым для БД.
Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter

Добавить комментарий