Проектирование схемы БД в среде ERwin. Проблема избыточности данных. Проблема обновления данных. Проблема удаления данных.

Страницы работы

Содержание работы

Стандарт выполнения Курсовая работа ИСАУ.

Проектирование схемы БД в среде ERwin

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

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

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

При использовании таблиц возникают следующие проблемы:

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

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

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

Проблема удаления данных. При удалении одной строки может быть потеряна нужная информация

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

Похожие материалы

Информация о работе