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

Проектирование реляционных баз данных

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

Цели проектирования:

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

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

Проблема исключения избыточности в подобных случаях решается разложением одного отношения на два. Эта операция называется декомпозицией отношений, являющейся стандартной процедурой при проектировании БД. В рассматриваемом примере получим два отношения: СТУДЕНТЫ (ФИО, Номер группы) и ГРУППА (Номер группы, Специальность, Срок обучения).

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

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

Модель предметной области — это записанные знания об объектах реального мира, которыми необходимо управлять наиболее рациональным образом. Знания могут быть представлены как в чисто текстовом виде, так и с использованием методологий структурного функционального моделирования — SADT, IDEFO, IDEF3, методологий и стандартов описания состава, структуры и взаимосвязей используемой в деятельности предприятия информации — IDEF1, DFD и соответствующих инструментальных CASE-средств — BPWIN, АЮ WIN, ProCap, Prosin, SmartER. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные с помощью специализированных графических нотаций.

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

Информационный объект — это описание некоторой сущности предметной области — реального объекта, процесса, явления или события. Информационный объект образуется совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики сущности. Примерами информационных объектов могут быть: СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ОТДЕЛЕНИЕ и т.п. Информационные объекты могут быть выделены на основе описания предметной области путем определения функциональных зависимостей между реквизитами. Совокупность реквизитов информационного объекта должна отвечать требованиям нормализации, о которых будет рассказано в следующем разделе. Информационный объект имеет множество реализаций или экземпляров. Например, каждый экземпляр объекта СТУДЕНТ представляет конкретного студента.

Объект и экземпляр объекта могут быть определены следующим образом:

Объект: СТУДЕНТ (Номер студ. билета, ФИО, Дата рождения, Группа) Экземпляр объекта: (1234, Лялин Ф.И., 12.09.1992, Э-103).

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

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

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

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

Общее правило при выборе набора атрибутов — начинать с результата и стараться упрощать, а не усложнять модель. Первое, что нужно определить, — это на какие вопросы пользователей должна отвечать проектируемая база данных.

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

Кроме атрибутов для каждой сущности требуется установить также связи между сущностями. Связи формально определяются как ассоциации между участниками. Например, утверждение «Покупатели покупают продукты» указывает, что существует связь между сущностью ПОКУПАТЕЛИ и сущностью ПРОДУКТЫ.

Этапы проектирования базы данных

Рис. 2.11. Этапы проектирования базы данных

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

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

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

База данных — это совокупность схемы и самих данных. Она содержит представления, таблицы, запросы, хранимые процедуры, правила, которые используются механизмом СУБД для защиты данных.

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

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

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

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

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