Ограничения предметной области

(Или условия, правила деятельности).

На данном этапе проектирования необходимо выявить все особенности и условия деятельности в рассматриваемой ПО. Эти условия будут являться исходными данными для:

· Обоснования выбора ключевых элементов для каждого информационного объекта (ИО) и

· Установления связей между ИО

на этапе информационно-логического проектирования, осуществляемого в разделе 3.

В результате проведённых исследований с учётом задания №21 были выявлены следующие особенности и условия деятельности:

· Конкретная продукция закреплена за одним складом готовой продукции, но может выпускаться несколькими цехами.

· У готового изделия только одна единица измерения.

· Один цех выпускает несколько наименований продукции.

· На одном складе хранится несколько наименований продукции.

· Количество продукции измеряется целым числом.

· Выпуск цехами готовой продукции планируется помесячно.

· Одно и тоже изделие может быть запланировано к выпуску в разные месяцы.

· Накладная цеха на сдачу готовой продукции на склад может содержать несколько наименований изделий. Ее номер уникален для данного цеха.

· Код присваивается изделию из последовательности чисел 1, 2, 3, и т.д. Каждое изделие имеет свой уникальный код.

· Нумерация месяцев в списке месяцев последовательная: 1, 2, 3, и т.д. Каждый месяц имеет, естественно, свой уникальный номер.

· Аналогичным образом нумеруются цеха и склады предприятия.

…Вы указываете свой номер задания и выбираете соответственно те ограничения из числа ограничений, представленных в разделе 6, которые соответствуют номеру Вашего индивидуального задания.

Ещё раз подчеркнём:

Эти ограничения при дальнейшей разработке информационной системы позволят:

1. Однозначно установить связи между объектами.

2. Обосновать выбор ключевых элементов.

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

2. Постановка задач

2.1. Организационно-экономическая сущность решаемых задач

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

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

В рамках реферата по заданию 21 необходимо " Произвести анализ выполнения финансового плана ЗАДАННЫМ цехом за ЗАДАННЫЙ месяц".

…… Здесь текст Вы должны подкорректировать под свой вариант. Вы должны указать свой номер задания и поставленную перед Вами задачу.

2.2. Описание выходной информации

На данном этапе проектирования необходимо:

· выявить всю совокупность выходных документов, формируемых информационной системой; и

· строго определить их формы (формы выходных документов).

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

Именно из этой совокупности информационных элементов будут формироваться ИО в разделе 3.1.

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

В соответствии с заданием № 21 система должна запрашивать у пользователя " Номер цеха" и " Номер месяца" и на основе полученной информации формировать следующий выходной документ:

Анализ выполнения финансового плана

цехом _________________ за ______________ месяц

(наименование) (наименование)

Наименование изделия	Код един. измер.	Сумма	Отклонение
По плану	Выполнено
	…	…	…	…
	Итого:	?	?	?

Вы должны представить слова и форму документа, соответствующие номеру Вашего индивидуального задания.

2.3. Описание входной информации

На данном этапе проектирования выявляется:

· вся совокупность документов, обеспечивающих человеческую деятельность в анализируемой области;

· алгоритм движения документов и порядок формирования.

Уточняется соответствие описаний реквизитов, встречающихся в выходных документах и входных.

Все используемые в рамках реферата документы и детальные описания их реквизитов представлены в таблице 1.2. Они выверены и уточнялись неоднократно.

Поэтому задачи данного этапа проектирования считаем выполненными.

3. Разработка информационного обеспечения

3.1. Анализ входной информации предметной области и выделение информационных объектов

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

Оптимальность при формировании ИО обеспечивается соблюдением принципов нормализации:

· каждый ИО объединяет функционально связанную группу ИЭ;

· исключается пересечение ИО по ИЭ;

· исключается дублирование информации о конкретных экземплярах объектов (в реляционных таблицах не должно быть одинаковых строк).

Для обеспечения наглядности процесса формирования ИО и математически строгого выполнения принципов нормализации строятся диаграммы (см.рис.3.1), наглядно обеспечивающие выполнение принципов нормализации:

· Исключение пересечения ИО по ИЭ достигается обеспечением изображения единственной стрелки напротив конкретного ИЭ. Стрелка указывает на принадлежность ИЭ конкретному ИО.

· Исключение дублирования информации о конкретных экземплярах ИО (исключение дублирования строк) достигается правильным выбором ключевых элементов для каждого вида ИО.

Текст ниже подкорректировать под свой вариант, - Точно такие же слова можно написать для документов Товаро-транспортная накладная и Платежное поручение. Вы должны рассмотреть документы, соответствующие Вашему индивидуальному заданию.

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

· Цеховая накладная;

разбита для хранения на две функциональные группы, на два ИО (информационных объекта):

· ЦН и Спецификация ЦН;

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

При выборе ключевых элементов руководствуемся результатами анализа ПО, - ограничениями ПО, т.е. условиями деятельности в рассматриваемой области (см.подраздел 1.3), например:

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

Для ИО «Изделия» выбираем в качестве ключевого элемента " Код изделия", поскольку согласно раздела 1.3 " ….. Каждое изделие имеет свой уникальный код.", а это означает, что данный элемент способен исполнить функцию ключа, которая как раз и состоит в обеспечении уникальности каждой строки реляционной таблицы (единственности информации о конкретном экземпляре ИО).

Для ИО ЦН в качестве ключевого элемента выбираем комбинацию реквизитов " номер ЦН" и " номер цеха", поскольку согласно раздела 1.3. " Её (ЦН) номер уникален только для данного цеха".

Для ИО " Спецификация ЦН" к ключевым реквизитам основного ИО добавляется " Код изделия", поскольку для данного документа в разделе 1.3 отмечено " … может содержать несколько наименований изделий".

Для ИО " План выпуска" в качестве ключевого элемента выбираем комбинацию из трёх реквизитов:

· Месяц выпуска;

· Код изделия;

· Номер цеха;

исходя из двух условий раздела 1.3:

· Одно и тоже изделие может быть запланировано к выпуску в разные месяцы.

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

На основании подобного анализа определены ключевые элементы для всех ИО. На рис.3.1 они изображены отрезками прямых линий (не стрелками), а в таблице 3.1., в пределах которой представлены текстовые описания ИО, ключевые реквизиты отмечены звездочкой.

Информационные объекты

Рис. 3.1. Формирование информационных объектов

Таблица 3.1. Информационные объекты и их реквизиты

Информационные объекты	Ключ	Реквизиты	Документы
Изделия	*	Код изделия	Список выпускаемых изделий
	Наименование изделия
	Код единицы измерения
	Цена
	Номер склада
Единицы измерения	*	Код единицы измерения	Справочник единиц измерения
	Наименование единицы измерения
Цеха	*	Номер цеха	Список выпус- кающих цехов
	Наименование цеха
Месяцы	*	Номер месяца	Список месяцев
	Наименование месяца
Цеховые накладные	*	Номер цеха	Список цеховых накладных
*	Номер цеховой накладной
	Дата сдачи
Спецификации к цеховым накладным	*	Номер цеха
*	Номер цеховой накладной
*	Код изделия
	Количество
План выпуска	*	Номер цеха	План выпуска изделий цехами
*	Месяц выпуска
*	Код изделия
	Количество

3.2. Определение связей информационных объектов и построение информационно-логической (ИЛМ) модели

Определение наличия связи между ИО и тип связи осуществляем исходя из анализа предметной области и выявленных там ограничений, например:

……Текст ниже подкорректировать под свой вариант ………

Между ИО " План выпуска" и ИО " Изделия" существует связь и это связь типа " Один ко Многим", поскольку в разделе 1.3 отмечено " … одно и то же изделие может быть запланировано к выпуску в разные месяцы". Это означает, что одно и то же изделие может встречаться в " Плане выпуска" многократно, а в таблице " Изделия" каждое из изделий записано один раз.

Между ИО " Спецификация ЦН" и основным ИО (" ЦН" ) существует связь и это связь типа " Один ко Многим", поскольку для документа " Цеховая накладная" в разделе 1.3 отмечено " … может содержать несколько наименований изделий", а в спецификации помещены элементы, описывающие количественные величины каждого вида изделий, содержащихся в документе " Цеховая накладная".

Между ИО " Спецификация ЦН" и ИО " Изделия" существует связь и это связь типа " Один ко Многим", поскольку в разделе 1.3 отмечено " … одно и то же изделие может быть запланировано к выпуску в разные месяцы", а это означает, что одно и то же изделие может встречаться в " Спецификации ЦН" многократно.

На основании подобного анализа определено наличие связи и тип связи между всеми выявленными ИО. Построенная в соответствии с этим информационно-логическая модель (ИЛМ) представлена на рис.3.2.

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

Повторяю: Текст выше следует подкорректировать под Ваш номер индивидуального задания, - под Ваши документы и ИО. Например, могут быть такие фразы:

Поскольку, согласно раздела 1.3, " …каждый договор заключается с конкретным заказчиком, но с одним заказчиком может быть заключено несколько договоров", между ИО Заказчики и Договора существует связь и это связь типа " Один ко Многим".

Поскольку, согласно раздела 1.3, " Документ об отгрузке готовой продукции относится к одному договору …", между ИО Договора и ТТН существует связь и, поскольку " По одному договору может быть несколько отгрузок", это связь типа " Один ко Многим".

Рис.3.2. Информационно-логическая модель системы

3.3. Определение логической структуры базы данных

Логическая структура БД представляет собой более детальное, чем ИЛМ, графическое изображение проектируемой информационной системы.

Каждому ИО ИЛМ ставится в соответствие реляционная таблица, совокупность столбцов которой однозначно соответствует совокупности атрибутов ИО.

В каждой реляционной таблице отмечены ключевые элементы.

Логические связи между реляционными таблицами соответствуют структурным связям ИЛМ, но изображаются с учетом конкретных реквизитов (информационных элементов), чаще всего – ключевых.

Построенная в соответствии с изложенным логическая структура информационной системы, изображена на рис. 3.3.

На основе разработанной логической структуры и ИЛМ достаточно легко выполняется физическая реализация ИС.

Рис.3.3. Логическая структура базы данных (символом * отмечены ключевые реквизиты)

4. Физическая реализация базы данных

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

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

4.1. Создание таблиц

Разработка структуры таблиц

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

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

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

Типы и размеры данных каждого из полей определяются описаниями реквизитов, полученными при исследовании ПО и представленными в таблице 1.2, например:

Текст ниже подкорректировать под свой вариант. Обосновать выбор типа и размера данных письменно не менее чем для трёх полей Ваших таблиц. Остальные типы и размеры данных также должны быть выбраны Вами обоснованно, но можно не описывать процедуру выбора. Ошибки обоснования будут зафиксированы преподавателем.

Поле " Номер ЦН" таблицы " ЦН" в соответствии с данными таблицы 1.2 может содержать числа в диапазоне от 1 до 485. Для хранения такого числа в поле таблицы, реализуемой в СУБД Access, может быть использовано либо текстовое поле размера 3 (3 символа содержит максимальное из хранимых в нем чисел), либо числовое поле формата " Целое" (формат " Байт" обеспечивает хранение чисел в диапазоне от 0 до 255, формат " Целое" обеспечивает хранение чисел в диапазоне от -32767 до +32768). При этом текстовое поле размера 3 занимает в памяти 3 байта емкости, а числовое поле вида " Целое" - 2 байта. С целью экономии ресурса (объема памяти) выбираем поле - " Числовое" вид – " Целое".

Поле " Код изделия" согласно таблице 1.2 может содержать числа в диапазоне от 1 до 9. Для хранения такого числа может быть использовано либо текстовое поле размера 1, либо числовое поле формата " Байт". С точки зрения расхода объема памяти оба варианта равноценны. Для определенности выбираем поле - " Числовое" вид – " Байт".

Поле " Наименование" таблицы " Изделия" согласно таблице 1.2 содержит текст до 18 символов. Для хранения такой информации может быть использовано либо текстовое поле размером 18, либо поле " MEMO". С точки зрения расхода памяти выбираем поле - " Тестовое" размер – 18.

На основании аналогичного анализа определены типы и размеры данных для всех полей и разработана структура всех таблиц проектируемой базы данных. Окончательные результаты представлены в таблице 4.1.

Таблица 4.1. Структура таблиц проектируемой базы данных

Обратите внимание, - в именах полей не должно быть точек. Вместо точек можете указывать нижнюю черту. Access не допускает использование символа точка в именах полей таблицы.

1 234 5