Информационный список документов

№ пор.	Название документа	Тип документа
1.	Таблица данных из каталогов товаров и рекламных проспектов (табл. 7)	Входной
2.	Таблица корзины заказов (табл. 8)	Выходной
3.	Карточка заказа (26)	То же

Рис.23 Схема существующего технологического процесса обрабатывания информации на фирме.

Таблица 8

Родовидовой список элементов данных выходных документов

№ пор.	Название элемента	Фактичний/вычислительный	Назначение
1.	Адрес фирмы	Фактический	Адрес фирмы поставщика
2.	Стоимость товара	Вычисляемый	Стоимость заказанных товаров
3.	Дата заказа	Фактический	Дата оформления заказа
...	...	...	...

Таблица 9

Родовидовой список элементов данных входных документов

№ пор.	Название элемента	Фактичний/вычислительный	Назначение
1.	Адрес фирмы	Фактический	Адрес фирмы поставщика
2.	Дата заказа	То же	Дата оформления заказа
3.	Скидка	_”_	Размер скидки (%) в зависимости от размера партии товара
...	...	...	...

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

Таблица 10

Словарь данных

№ пор.	Название элемента	Идентификатор	Тип и длина	Назначение
1.	Адрес фирмы	ADR_SUP	C(50)	Адрес фирмы-поставщика
2.	Дата заказа	DAT	D(8)	Дата оформления заказа
3.	Скидка	REBATE	N(2)	Размер скидки (%) в зависимости от размера партии товара
...	...	...	...	...

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

Для исключения элементов данных, которые дублируются, полезно разработать процедуру, которая выдает запрос на разрешение замены повторяемых данных. Таким образом, изымают элементы данных, которые дублируются, синонимы и омонимы.

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

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

Задача 1

Просмотр каталогов и рекламных проспектов и заполнение табл. 5. Блоки 1 и 2 (см. рис. 23). В задаче используются данные каталогов и рекламных проспектов. Цель - заполнить табл. 5.

Задача 2

Формирование корзины заказов (см. табл. 6). Блок 3 (см. рис 23). В задаче используются данные табл. 5 о товарах, фирмы-поставщики и количество товаров, которые заказываются. Цель — формирование списка товар - поставщик для реальных заказов.

Задача 3

Формирование карточек заказов конкретным фирмам-поставщикам согласно корзине заказов. Блок 4 (см. рис. 23). В задаче используют данные корзины заказов. Цель — формирование карточек заказов конкретным фирмам-поставщикам на конкретные товары.

Результаты анализа информационной системы сформированы в таблицу связи “Задачи - данные” (табл. 11).

Таблица 11

Таблица связи “Задачи — данные”

№ пор.	Название задачи	Тип	Частота выполнения	Объем	Отдел	Элементы данные
1.	Просмотр каталогов и рекламных проспектов заполнения табл. 7	Производственная	Ежедневно	100 строк	№1	1,3 - 5,7 - 10,12 - 18
2.	Формирование корзины заказов (см. табл. 8)	То же	Еженедельно	1 корзина	То же	1,3 - 10,12 - 18,
3.	Формирование карточек заказов (см. рис. 26)	То же	То же	20 карточек	_”_	1-18

Рис. 24. Схема существующего технологического процесса обработки информации на фирме с разбитием его на отдельные задачи

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

Первое локальное представление модели данных касается рядового служащего, который занимается обработкой каталогов и рекламных проспектов и заполнением табл. 5. Он же проверяет и исправляет данные во временном массиве. Редактирование данных в файлах самой базы выполняет ее администратор. В первом локальном представлении модели данных выделяют типы сущностей “Поставщик” и “Товар”. Атрибутами, которые идентифицируют экземпляры этих сущностей, являются их коды. Остальные атрибуты указанных сущностей имеют описательный характер. Связь между отмеченными типами сущностей имеет название “Предложение”. Тип ассоциации этой связи М:М. У связи есть собственные атрибуты (данные пересечению), которые одновременно принадлежат типам сущностей “Поставщик” и “Товар”. ER-диаграмма первого локального представления модели данных изображена на рис. 25.

Второе локальное представление модели данные касается эксперта, который формирует корзину заказов и проверяет правильность его заполнения. Здесь выделяются типы сущностей “Поставщик” и “Товар” с атрибутами, показанными на рис 26.

Третье локальное представление модели данных касается служащего, который оформляет заказ. Здесь к сущностям и связям первого представления модели данных добавляют новые, связанные с формированием корзины заказов. Тип сущности “Товар” в этом случае включает не все товары из табл. 5, а только те, которые выбраны экспертом для приобретения (отсюда и название “Выбранный товар”). ER-диаграмма третьего локального представления модели данных показана на рис. 27. Здесь тип сущности “Поставщик” включает не всех поставщиков из табл. 5, а только тех, которые поставляют отобранные для приобретения товары (отсюда и название “Выбранный поставщик”).

Объединение локальных информационных структур. При объединении локальных представлений из диаграммы изымают элементы данных, которые дублируются. В каждой связи оставляют лишь ему присущие атрибуты. Результат объединения первого и второго локальных представлений модели данных отображен на рис. 28. При объединении этой схемы из ER-диаграммы третьего локального представления модели данных учитывают то, что тип сущности “Выбранный товар” имеет те же атрибуты, что и тип сущности “Товар”, а тип сущности “Выбранный поставщик”- те же атрибуты, что и тип сущности “Поставщик”. Поэтому нецелесообразно выделять отдельные типы сущностей “Выбранный товар” и “Выбранный поставщик”. Метод обобщения при объединении указанных локальных представлений дает возможность оставить только типы сущностей “Поставщик” и “Товар”.

Глобальная ER-диаграмма (или глобальная инфологическая модель данных) показана на рис. 29.

Рис. 25. ER-диаграмма первого локального представления модели данных

Рис. 26. ER-диаграмма второго локального представления модели данных

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

Рис. 27. ER-диаграмма третьего локального представления модели данных.

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

Предполагаемый объем БД можно оценить таким образом. Существует временный файл TEMPOR с полями, которые отвечают структуре табл.5. Максимальное количество его строк — 10.

Предполагаемая емкость памяти для этого файла составляет:

10 ед. товара/день × 200 байт = 2 Кбайт.

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

100 строк/день ×3 дня ×4 недели × 3 мес. × 200 байт = 720 Кбайт.

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

200 ед. товара/неделю ×61 байт = 12,2 Кбайт.

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

2 + 720 + 12,2 = 734,2 Кбайт

Рис. 28. Результат объединения первого и второе локальных представлений модели данные.

Такую же емкость памяти занимают файлы страховой копии. Емкость памяти, необходимой для ключевых, индексных, других вспомогательных файлов, и памяти для процедур обработки данных, составляет приблизительно 200 Кбайт. Текстовый файл REP_ORD с данными отчета нуждается в емкости памяти максимум 20 Кбайт. Таким образом, предполагаемая максимальная емкость внешней памяти, нужной для разрабатываемой БД, составляет:

2 ×734,2 + 20 + 200 = 1690 Кбайт = 1,69 Мбайт

Рис. 29. Глобальная ER-диаграмма.

Разрабатываемая ИС будет функционировать в операционной среде, которая состоит, как правило, из таких компонентов:

• ОС;

• драйверов внешних периферийных устройств (CD-ROM, модем и др.);

• программ антивирусной защиты;

• программ архивации и упаковки файлов;

• текстовых редакторов;

• других вспомогательных программ обслуживания компьютера.

Программы организации рабочей среды под управлением OС Windows 98/2000 требуют приблизительно 170 Мбайт (минимальный комплект) емкости памяти компьютера.

Требования к техническому обеспечению. Эта ИС может быть реализована в автономном варианте даже на основе компьютера типа IBM PC/XT. Однако следует иметь в виду, что компьютер Pentium с тактовой частотой 300 Мгц и больше и емкостью оперативной памяти 64 Мбайт полностью доступен по стоимости даже для мелкой частной фирмы. Такой компьютер предоставляет пользователю Windows 98/2000 или Windows NT 4.0 использование широкого спектра программных продуктов Microsoft Office.

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

В данном случае можно остановиться на варианте компьютера Pentium II 300 Мгц с оперативной памятью емкостью 64 Мбайт и внешней памятью емкостью около 4 Гбайт, дисплеем SVGA и принтером типа Laser Jet HP.

Требования к ПЗ. Для решения рассматриваемой задачи с помощью выбранных технических средств целесообразно иметь OС Windows 98/2000 и типичный набор ПЗ фирмы Microsoft.

Для программной реализации задачи полностью подходит СУБД Visual Fox Pro 6.0 как одна из самых популярных при решении задач подобного класса благодаря высоким быстродействию, уровню автоматизации программирования и преемственности версий. В дальнейшем среда СУБД не будет нужной, поскольку задачу можно оформить как EXE-модуль.

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

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

Формулировки СУБД - ориентированной логической структуры, или даталогической концептуальной модели БД. На этом этапе выполняется превращение инфологической модели ПС на даталогическую модель.

Наличие связей между сущностями типа М:М дает возможность представить ER-диаграмму в виде сложной сетевой модели данных, показанной на рис. 30.

Для устранения связи типа М:М в модель данных вводят дополнительные записи. Данные пересечения, которые принадлежат обоим типам сущностей, будут атрибутами дополнительных записей. Благодаря этому сложная сеть сводится к простой сетевой модели. На рис. 31 изображена даталогическая простая сетевая модель данных. В этой модели каждой сущности отвечает отдельная запись. Кроме того, имеются записи-связи “Заказа” и “Цена-скидка”. В модели отсутствует зависимость от пути, каждая запись является автономной и может быть представлена как элемент реляционной даталогической модели данных.

Полученную даталогическую модель данных следует проанализировать на наличие отношений, которые нуждаются в нормализации. Отношение “Поставщик” имеет первичный ключ “Код фирмы-поставщика” и описательные атрибуты, которые функционально полно и нетранзитивно зависят от ключа. Поэтому это отношение находится в третьей нормальной форме. Вторая ключевая детерминанта представлена совокупностью атрибутов: “Название фирмы”, “Адрес фирмы”. Оба ключевых детерминанта является возможными ключами, другие ключевые детерминанты отсутствуют; поэтому отношение находится в третьей усиленной нормальной форме. Множественные связи между атрибутами отсутствуют. Отношение является таким, которое не сводится, и свободным от аномалий включения, исключения и корректировки данных.

Отношение “Товар” имеет первичный ключ “Код товара” и описательные атрибуты, которые функционально полно и нетранзитивно зависят от ключа. Поэтому это отношение находится в третьей нормальной форме. Вторая ключевая детерминанта представлена совокупностью атрибутов: “Название товара”, “Параметр 1”, “Параметр 2”, “Параметр 3”, “Параметр 4”. Оба ключевых детерминанта является возможными ключами, другие ключевые детерминанты отсутствуют; поэтому отношение находится в третьей усиленной нормальной форме. Множественные связи между атрибутами отсутствуют. Отношения являются такими, которые не сводятся, и свободным от аномалий включения, исключения и корректировки данных.

Отношение “Цена - скидка” находится в первой нормальной форме. Непервичный атрибут “Скидка” зависит от сложного ключа “Код товара + Код фирмы-поставщика + Количество, которое предопределяет скидку”, непервичный атрибут “Цена” - от части этого ключа “Код товара + Код фирмы - поставщика”. В этом случае нарушено требование второй нормальной формы о полной функциональной зависимости непервичных атрибутов от любого возможного ключа. Во время работы с этим отношением могут возникать аномалии операций включения, исключения и редактирования данных. Например, пока не будет внесен размер скидки на заказ, нельзя вносить информацию о цене товара. При исключении единственной записи с определенной скидкой будет изъята информация о цене товара поставщика. Такие же проблемы возникают при редактировании данных. Поэтому нужно выполнить проецирование этого отношения.

Рис. 30. Даталогическая сложная сетевая модель данных

Первая проекция — отношение ЦЕНА (Код товара, Код фирмы-поставщика, Цена) имеет первичный ключ “Код товара + Код фирмы-поставщика” и непервичный атрибут “Цена”, который функционально полно и нетранзитивно зависит от ключа.

Вторая проекция — отношение СКИДКА (Код товара, Код фирмы-поставщика, Количество/скидка, Скидка) имеет первичный ключ “Код товара + Код фирмы-поставщика + Количество/скидка” и непервичный атрибут “Скидка”, который функционально полно и нетранзитивно зависит от ключа.

Полученные отношения “Цена” и “СКИДКА” находятся во второй и третьей нормальных формах. Другие ключевые детерминанты, кроме первичных ключей, у них отсутствуют. Поэтому оба отношения находятся в усиленной третьей нормальной форме. В этих отношениях отсутствуют множественные связи между группами данных. Отношение “ЦЕНА” и “СКИДКА” являются такими, которые не сводятся, и лишены аномалий включения, исключения, редактирования.

Операция естественного соединения этих отношений дает возможность возобновить начальное отношение “Цена-скидка”, поскольку они имеют общие атрибуты “Код товара”, “Код фирмы-поставщика”, которые в отношении “ЦЕНА” составляют первичный ключ.

Рис. 31. Даталогическая простая сетевая модель данных

Отношение ЗАКАЗА (№ заказ, Код товара, Код фирмы-поставщика, Дата заказа, Количество в заказе) находится в первой, второй и третьей нормальных формах. Непервичный атрибут “Количество в заказе” зависит от двух возможных ключей: “Дата заказа + Код фирмы-поставщика + Код товара” и “Дата заказа + № заказ + Код товара, которые пересекаются по атрибутам “Дата заказа + Код товара”. Транзитивных зависимостей нет. Однако существует зависимость атрибута “№ заказа” от ключевой детерминанты “Код фирмы-поставщика + Дата заказа”. Следовательно, в отношении “Заказа” количество ключевых детерминантов превышает количество возможных ключей, потому оно не находится в третьей усиленной нормальной форме и нуждается в декомпозиции на такие проекции:

КОЛИЧЕСТВО ЗАКАЗА (Дата заказа, Код фирмы-поставщика, Код товара, Количество в заказе);

ЗАКАЗ (Дата заказа, Код фирмы-поставщика № заказ).

Атрибут “№ заказа” является суррогатным ключом — порядковым номером фирм-поставщиков в корзине заказов.

Ключом в отношении “Количество заказа” является “Датой заказа + Код фирмы-поставщика + Код товара”, а ключом в отношении “Заказ” - “Дата заказа + Код фирмы-поставщика”.

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

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

ПОСТАВЩИК (Код фирмы-поставщика, Название фирмы, Адрес, Имя менеджера, Телефон, Рейтинг);

ТОВАР (Код товара, Название товара, Параметр 1, Параметр 2, Параметр 3, Параметр 4);

ЦЕНА (Код товара, Код фирмы-поставщика, Цена);

СКИДКА (Код товара, Код фирмы-поставщика, Количество/ скидка, Скидка);

КОЛИЧЕСТВО ЗАКАЗА (Код товара, Код фирмы-поставщика, Дата заказа, Количество заказа);

ЗАКАЗ (Код фирмы-поставщика, Дата заказа № заказ);

ФАЙЛ (Имя файла, Количество записей, Размер, Дата создания, Имя разработчика);

ПОЛЕТ (Имя поля, Тип, Длина, Точность);

СВЯЗЬ (Имя файла, Имя поля).

В принятых в словаре данных обозначениях отмеченные отношения имеют такой вид:

ПОСТАВЩИК (COD_SUP, NAM_SUP, ADR_SUP, MANAGER, TEL_SUP, REP_SUP);

ТОВАР (COD_G, NAME_G, PAR1_G, PAR2_G, PAR3_G, PAR4_G) и так далее для всех отношений.