- •Министерство науки и образования Российской Федерации
- •Пояснительная записка
- •Введение
- •1 Постановка задачи
- •2 Выбор и обоснование субд
- •3 Описание информационных потоков
- •4 Нормализация базы данных
- •Описание ограничений целостности Информация об объектах предметной области сведена в таблицу 1. Описание объектов предметной области
- •6 Физическое проектирование
- •7 Принцип работы
- •Заключение
- •Список литературы
- •Приложение 1
- •Приложение 2
- •Приложение 2
- •Приложение 3
- •19 Декабря 2004 г. Страница 1 из 1 приложение 4
3 Описание информационных потоков
Для разработки БД была использована модель предметной области «сущность-связь». Выбор данной модели обусловлен ее простотой и наглядностью отображения объектов предметной области и информационных потоков.
На этапе информационно - логического моделирования предметной области часто используют модель "сущность - связь" (Entity - Relationship, ER), которая наглядно изображает структурные блоки информации и логические взаимосвязи между ними. Компонентами модели являются сущности, понятия и связи.
Для анализа информационных потоков возьмем следующий пример:
Допустим, фирма заключила контракт с определённым поставщиком. Всю необходимую информацию о нём необходимо занести в базу данных фирмы. На нового поставщика заводится формуляр, в котором записаны необходимые данные о нем. У поставщика производят закупки. В этом случае составляется договор о закупке, который фиксирует следующие необходимые данные: Код Заказа; Номер Заказа; Описание Заказа; Код Поставщика; Стоимость Доставки. Когда клиент приходит в фирму он заключает сделку. В этом случае составляется договор о закупке, который фиксирует следующие необходимые данные: Код Сделки; Код Товара; Код Заказа; Цена; Количество; Продано. По критериям «Цена» и «Количество» БД фирмы по продаже комплектующих, представляет данные о остатке товара на складе и об общей прибыли с одного комплектующего.
На основе представленных, на примере информационных потоков составляются необходимые элементы работы БД.
Общий порядок построения ER- модели:
1) в каждом внешнем представлении нужно выделить понятия и их свойства, при этом очень полезно использовать результаты анализа экономического документа;
2) обозначить понятия именами, которые должны быть краткими, понятными, привычными для пользователя;
3) выбрать ключевое свойство или ввести его искусственно для каждого понятия;
4) выявить связи между разными понятиями и определить их степень;
5) объединить модели, построенные для разных внешних представлений.
ER - диаграмма приведена в Приложении 1.
4 Нормализация базы данных
Процесс проектирования баз данных заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональной зависимости, устраняет соответствующие аномалии при работе с отношениями и сохраняет свойства предшествующих форм.
Процесс построения реляционных баз данных на основе нормальных форм предполагает удаление из исходного отношения следующие меж атрибутивные зависимости:
-
Частичной зависимости атрибутов от ключа (уровень второй нормальной формы);
-
Транзитивность зависимостей не ключевых атрибутов от ключа (удовлетворяет 3-ей нормальной форме);
-
Зависимости ключей от не ключевых атрибутов (удовлетворяет нормальной форме Байеса-Кодда) альтернативой этого подхода является метод ER-диаграмм (метод сущность-связь), которой применяется для проектирования больших баз данных и на нем реализованы средства проектирования баз данных.
Основное правило при создании таблиц сущностей – это каждой сущности желательно сопоставить отдельную таблицу. Поля таблиц сущностей могут быть ключевыми или не ключевыми. Введение ключей позволяет обеспечить уникальность значений в записи, ускорить обработку записи и выполнить обработку. Если в таблице есть значительное повторение по нескольким полям и их объем существенен, то лучше их выделить в отдельную таблицу. Новую сущность легко добавить и изменить, но при удалении следует уничтожить все ссылки на нее из таблиц связей, в противном случае возникает некорректность.
В данном курсовом проекте была проведена нормализация базы данных и достигнута нормальная форма Байеса-Кодда, то есть были устранены функциональные зависимости и исключена явная избыточность в таблицах. Также удалось избавиться от транзитивных зависимостей.
Таблица находится в НФБК, если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.
В результате процесса нормализации исходной таблицы была получена НФБК: