Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Информационные технологии в государственном и муниципальном управлении
Посмотреть оригинал

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

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

Инфологическая модель предметной области «Торговая фирма»

Рис. 3.7. Инфологическая модель предметной области «Торговая фирма»

Даталогическое проектирование выполняется в несколько этапов.

  • 1. Выбор СУБД.
  • 2. Формирование информационных структур данных с учетом выбранной СУБД и модели данных.
  • 3. Нормализация информационных структур.
  • 4. Представление даталогической модели.
  • 5. Модификация инфологической модели по результатам даталоги- ческого проектирования.

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

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

Реляционные СУБД довольно близки по своим функциональным

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

При проектировании реляционных БД формирование информационных структур сводится к отображению сущностей предметной области в двумерных таблицах, при этом:

  • • атрибуты отображаются в полях таблицы;
  • • определяются типы данных полей (текстовый, числовой, календарный и пр.);
  • • выделяются первичные и вторичные (внешние) ключи;
  • • определяются связи между таблицами.

Чтобы связать две реляционные таблицы, необходимо ввести в структуру первой таблицы внешний ключ — первичный ключ второй таблицы (рис. 3.8).

Информационные структуры базы данных «Торговая фирма»

Рис. 3.8. Информационные структуры базы данных «Торговая фирма»

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

Таблица «Товары» базы данных «Торговая фирма»

Рис. 3.9. Таблица «Товары» базы данных «Торговая фирма»

Например, для таблицы «Товары» характерны (рис. 3.9):

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

Решение этих проблем возможно на основе применения аппарата нормализации таблиц [30]. Каждая таблица должна удовлетворять условию, в соответствии с которым все данные должны иметь атомарное (далее неделимое) значение. Говорят, что такая таблица находится в первой нормальной форме (1НФ). Например, в таблице «Товары» (см. рис. 3.9) данные в поле «Менеджер» не атомарны и могут быть разделены на три группы данных: «Фамилия», «Имя», «Отчество». Аналогично, могут быть разделены данные в поле «Модель товара» на данные «Фирма» и «Модель».

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

Вид таблицы «Товары» после приведения в 1НФ показан на рис. 3.10.

Таблица «Товары» в первой нормальной форме

Рис. 3.10. Таблица «Товары» в первой нормальной форме

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Полная функциональная зависимость, по сути, является связью типа «Многое к одному». Все неключевые поля зависят только от ключевого поля и не находятся в зависимости ни от какой его части, если таблица имеет составной ключ. В таблице «Товары» ключевое поле (поле «№ ») не является составным. Можно считать, что таблица находится во второй нормальной форме, т.е. таблица «Товары» в 2НФ повторяет таблицу «Товары» в 1НФ.

Таблица находится в третьей нормальной форме (ЗНФ), если она удовлетворяет определению 2НФ и ни один из ее неключевых атрибутов не связан функциональной зависимостью с любым другим неключевым атрибутом.

В таких случаях говорят об отсутствии транзитивной зависимости. Для устранения транзитивной зависимости информационная структура расщепляется на две и более, если потребуется. Происходит декомпозиция исходного отношения — таблицы «Товары» в 2НФ (см. рис. 3.10) по схеме, приведенной на рис. 3.11. Полной декомпозицией таблицы называют такую совокупность произвольного числа проекций, соединение которых полностью совпадает с содержимым исходной таблицы. Нормализация таблиц решает проблемы избыточности и потенциальной противоречивости данных.

После процедуры нормализации формируется даталогическая модель с учетом появившихся новых информационных структур, например таблицы «Менеджеры». Определяются ключевые поля для них, устанавливаются связи и задаются типы данных полей. На завершающем этапе даталогического проектирования выполняется модификация инфологи- ческой модели предметной области с учетом появившихся новых сущностей и изменения состава атрибутов исходных сущностей (рис. 3.12).

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

 
Посмотреть оригинал
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

Популярные страницы