Организация баз данных
оставщика соответствует только одно имя. Взаимосвязь «один
ко многим» обозначается одинарной стрелкой в направлении к «одному» и
двойной стрелкой в направлении ко «многим».
Первоначальная схема данных
|Функциональная |Исследование токов |Данные выявленные в |
|модель |Данных |ходе разработки |
|Отдел обработки | |Заявки |
|заявок | | |
| | |Договора |
|Договоров | |Поставщики |
| | |Заказчики |
|Ведение счетов | |Счета |
|Погрузка | |Накладные |
| | |Товар |
| | |Инвентаризация |
| | |Справки |
Определение объектов
Выделим следующие объекты:
1. ТОВАР - (Т);
2. ЗАКАЗЧИК - (З);
3. ПОСТАВЩИК - (П);
4. СЧЕТА - (С);
5. ДОГОВОР - (Д);
6. НАКЛАДНЫЕ - (Н).
Первоначальное графическое представление концептуальной модели
| |Т | |
|З | |П |
| |С | |
|Н | |Д |
Задание первичных и альтернативных ключей, определение свойств объектов
Для каждого объекта определим свойства, которые будем хранить в БД. При
этом необходимо учитывать тот факт, что при переходе от логической к
физической модели данных может произойти усечение числа объектов. На самом
деле, как правило, значительное число данных, необходимых пользователю,
может быть достаточно легко подсчитано в момент вывода информации. В то же
время, в связи с изменением алгоритмов расчета или исходных величин,
некоторые расчетные показатели приходится записывать в БД, чтобы
гарантированно обеспечить фиксацию их значений. Выбор показателей, которые
обязательно следует хранить в БД, достаточно сложен. Нечасто можно найти
однозначное решение этой проблемы, и в любом случае оно потребует
тщательного изучения работы предприятия и анализа концептуальной модели.
Свойства, включаемые в состав БД для рассматриваемой модели, приведены в
табл.1.
Таблица 1. Свойства и первичные ключи объектов информационной модели.
|Объект |Первичный ключ |Свойства |
|ТОВАР |Уникальный ключ товара |Уникальный ключ товара |
| | |Наименование товара |
|ЗАКАЗЧИК |Уникальный ключ заказчика |Уникальный ключ заказчика |
| | |Наименование заказчика |
| | |Юридическая принадлежность |
| | |Ф.И.О. руководителя |
| | |Адрес |
| | |Телефон/факс |
| | |Наименование товара |
| | |Количество товара |
| | |Предполагаемая цена |
|ПОСТАВЩИК |Уникальный ключ поставщика|Уникальный ключ поставщика |
| | |Наименование поставщика |
| | |Юридическая принадлежность |
| | |Ф.И.О. руководителя |
| | |Адрес |
| | |Телефон/факс |
| | |Наименование товара |
| | |Количество товара |
| | |Дата изготовления |
| | |Акцизная марка |
| | |Расшифровка штрих-кода |
| | |Срок годности |
| | |Вес Брутто |
| | |Вес Нетто |
| | |Цена за единицу |
| | |Суммарная цена |
| | |Вид упаковки |
| | |Способ доставки |
|СЧЕТА |Номер счёта |Номер счёта |
| | |Дата продажи |
| | |Наименование поставщика |
| | |Адрес поставщика |
| | |Юридическая принадлежность п. |
| | |Наименование заказчика |
| | |Адрес заказчика |
| | |Юридическая принадлежность з. |
| | |Наименование товара |
| | |Количество товара |
| | |Сумма |
| | |НДС |
| | |Сумма к оплате |
|ДОГОВОР |Номер договора |Номер договора |
| | |Дата заключения |
| | |Номер счёта |
| | |Наименование поставщика |
| | |Адрес поставщика |
| | |Юридическая принадлежность |
| | |Наименование товара |
| | |Количество товара |
| | |Сумма |
| | |НДС |
|НАКЛАДНЫЕ |Номер накладной |Номер накладной |
| | |Дата накладной |
| | |Пометка об оплате |
| | |Номер счёта |
| | |Наименование заказчика |
| | |Адрес заказчика |
| | |Юридическая принадлежность |
| | |Наименование товара |
| | |Количество товара |
| | |Сумма |
| | |НДС |
Графическое представление первой таблицы
| | | |С | |
| | | | |З |
| | | |П | |
| |Т | | |Н |
| | | |Д | |
Приведение модели к требуемому 1 уровню нормальной формы
Приведение модели к требуемому уровню нормальной формы является основой
построения реляционной БД. В процессе нормализации элементы данных
группируются в таблицы, представляющие объекты и их взаимосвязи. Теория
нормализации основана на том, что определенный набор таблиц обладает
лучшими свойствами при включении, модификации и удалении данных, чем все
остальные наборы таблиц, с помощью которых могут быть представлены те же
данные. Введение нормализации отношений при разработке информационной
модели обеспечивает минимальный объем физической, то есть записанной на
каком-либо носителе БД и ее максимальное быстродействие, что впрямую
отражается на качестве функционирования информационной системы.
Нормализация информационной модели выполняется в несколько этапов.
Данные, представленные в виде двумерной таблицы, являются первой
нормальной формой реляционной модели данных. Первый этап нормализации
заключается в образовании двумерной таблицы, содержащей все необходимые
свойства информационной модели, и в выделении ключевых свойств. Очевидно,
что полученная весьма внушительная таблица будет содержать очень
разнородную информацию. В этом случае будут наблюдаться аномалии включения,
обновления и удаления данных, так как при выполнении этих действий нам
придется уделить внимание данным (вводить или заботиться о том, чтобы они
не были стерты), которые не имеют
| |  скачать работу |
Организация баз данных |
