Пример логического проектирования

Продолжим проектирование системы СКЛАД, используя прагматический подход. Будем ориентироваться на СУБД Access. Данная СУБД является реляционной, входит в состав офисных программ Microsoft. В данной СУБД имена полей можно задавать в русском алфавите. СУБД поддерживает достаточное количество типов полей.

Разработка таблиц

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

Логическая модель будет включать и связные таблицы Состав_Док_Внеш и Состав_Док_Внут. В этих таблицах помимо полей от связываемых сущностей (КодДок, КодМатериала, КодСклада) появятся поля атрибутов связи (Количество и Цена_Док).

Как уже указывалось, при уточнении модели на данном этапе могут появиться новые атрибуты, сущности. Так, по условиям задачи, документы могут быть приходными и расходными. Документы могут также различаться по другим критериям, например, оптовая продажа, продажа со скидкой и др. Поэтому модель требует некоторой доработки, а именно: введение сущности ВИД ДОКУМЕНТА, с атрибутами КОД_ВИДА, НАЗВАНИЕ_ВИДА, ТИП ВНЕШНИЙ/ВНУТРЕННИЙ, ТИП ПРИХОДНЫЙ/РАСХОДНЫЙ. А также введения связей новой сущности с сущностями ДОКУМЕНТ ВНУТРЕННИЙ и ДОКУМЕНТ ВНЕШНИЙ. Эти связи могут быть отображены в валентное свойство этих таблиц.

Форматы реквизитов берутся из табл. 5.2. Структуры таблиц приведены в табл. 6.1.

Таблица 6.1

Имя Таблицы	Имя Поля	Тип Поля	Размер
Группы_Материалов	КодГруппы	Длинное целое
	НазваниеГруппы	Текстовый
Виды_Документов	КодВида	Длинное целое
	НазваниеВид	Текстовый
	ТипВШ_ВН	Текстовый
	ТипПР_РХ	Текстовый
Документы_Внешние и	КодДок	Длинное целое
Документы_Внутренние	Номер	Текстовый
	ДатаДок	Дата/время
	КодКлиента	Длинное целое
	ВидДок	Длинное целое
	Виза	Логический
Материалы	КодМатериала	Длинное целое
	НазваниеМатериала	Текстовый
	СчетЧисловой	Длинное целое
	ГруппаЧисловой	Длинное целое
	ЦенаУчетная	Денежный
Подразделения	КодПодр	Длинное целое
	НазваниеПодр	Текстовый
	Ответственный	Текстовый
Поставщики	КодПоставщика	Длинное целое
	ИмяПоставщика	Текстовый
	Адрес	Текстовый
Счета_Материалов	КодСчета	Длинное целое
	КраткоСчет	Текстовый
	НазваниеСчета	Текстовый
Склады	КодСклада	Длинное целое
	НазваниеСклада	Текстовый
Состав_Док_Внеш и	КодДок	Длинное целое
Состав_Док_Внут	КодМатериала	Длинное целое
	Количество	С плавающей
	ЦенаДок	Денежный
	КодСклада	Длинное целое
Состав_Складов	КодСклада	Длинное целое
	КодМатериала	Длинное целое
	КоличествоНач	С плавающей
	КоличествоТек	С плавающей

Ориентировочный объем базы данных

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

Например, для таблицы Склад потребуется:

Для хранения одной записи 54 байта (4 байта – длинное целое, 50 байт строковое).

Для хранения таблицы из 10 записей (10 – число складов в организации) потребуется 540 байт.

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

Дата добавления: 2014-01-07