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

 

Данный раздел может содержать следующие подразделы:

1. Выбор средства управления данными.

2. Описание систем классификации и кодирования.

3. Разработка моделей данных.

4. Реализация базы данных.

5. Организация сбора и обработки информации.

 

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

Далее следует обосновать способ организации (архитектуру) информационной базы:

a) будет ли это "файл-серверная" или "клиент-серверная" архитектура;

b) будет ли это трехуровневая архитектура "клиент-сервер" со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

c) будет ли БД централизованной или распределенной, если БД будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;

d) будет ли БД однородной, то есть, будут ли все серверы БД продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если БД не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее, или разработанное специально в проекте);

e) будут ли для достижения должной производительности использоваться параллельные серверы БД (например, Oracle Parallel Server, DB2 UDB и т. п.);

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

Таблица 2.1 - Характеристики СУБД ____________

Название характеристики	СУБД1	СУБД2

 

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

 

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

Структура кодовых обозначений объектов также может быть оформлена в виде таблицы с таким содержанием колонок:

– наименование кодируемого множества объектов (например, кодов подразделений, табельных номеров и т. д.),

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

Пример описания классификаторов в виде таблицы:

Таблица 2.2 Структура классификаторов

Назв.	Значность кода	Система классификации	Система кодирования	Вид классификатора
КОАТУУ	8	многоаспектная	комбинационная	государственный
Код услуги	3	отсутствует	порядковая	локальный
УДК	10	иерархическая	комбинационная	международный

3. Разработка моделей данных. Целью этого подраздела является разработка информационных моделей данных двух типов - логической модели данных (ЛМД) и физической модели данных (ФМД). Эти модели в будущем будут использованы для создания базы данных (БД) как основы информационного обеспечения (ИО) подсистемы.

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

При проектировании рекомендуется использовать принцип "Один факт хранится в одном месте". Для этого надо выделить основные объекты предметной области и разместить их свойства как атрибуты по разным сущностям. Каждому входному первичному учетному документу ставится в соответствие одна обобщающая сущность. Далее, если документ имеет несколько "бумажных" таблиц в структуре, то он разбивается по принципу: каждая "бумажная" таблица – еще одна сущность. Например, документ «Накладная на товар» - это две сущности ("Накладная" и "Материалы по накладной"). Количество сущностей в модели зависит от предметной области, но должна быть не менее 10.

Далее формируется начальный набор сущностей МД. Рекомендуется свести имена и назначение сущностей в таблицу вида табл. 3.3.

Таблица 2.3 Сущности модели “_____________”

№	Сущность	Описание
1	Журнал измерений	Общая информация о проводимых измерениях
2	…	……...

 

Для каждой сущности надо описать ее атрибуты. Это можно сделать в виде таблицы:

Таблица 2.4 Атрибуты сущностей модели

№	Сущность	Атрибуты
1	Журнал измерений	Код измерения, дата, номер резервуара
2	…	……...

 

При определении ключей надо использовать действующие системы классификации и кодирования или вводить искусственные атрибуты типа счетчика.Таблицы 2.3-2.4 можно заменить обычным текстом, описывая каждую сущность отдельно, или использовать для описания язык инфологического моделирования.Логическая модель БД строится с помощью того программного CASE-пакета визуального моделирования. Дипломник должен кратко, в пределах двух-трех абзацев, обосновать выбор CASE-средства разработки модели данных.При разработке модели определяются сущности, их ключи и атрибуты, а также связи между сущностями. На этом этапе также необходимо выявить вычисляемые поля. Далее необходимо выполнить процедуру нормализации БД методом нормальных форм и устранить в таблицах:- частичные зависимости неключевых полей от ключа;- транзитивные зависимости неключевых полей от ключа;- многозначные зависимости.В случае необходимости, студент может обосновать и провести незначительную денормализацию модели, прежде всего руководствуясь критерием минимизации времени обработки запросов к БД и объемами БД.

Результат разработки ЛМД приводится в виде рисунка альбомной ориентации.

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

Таблица 2.5 Структура таблицы “Сотрудники” 

№	Имя поля	Тип	Размер	Длина, б
Всего

 

Для обмена информацией с пользователями в других организациях в проекте необходимо предусмотреть использование итоговых.dbf - файлов. Студент дает краткое описание этих файлов и файлов - классификаторов в виде свободных таблиц.

В записке приводится физическая модель в виде рисунка альбомной ориентации. Дипломник отмечает, что ФМД будет использована для формирования программы генерации основных объектов машинной БД в среде выбранной СУБД. Фрагмент этой программы для 3-5 основных связанных таблиц необходимо привести в приложении (до 2-3 стр., предварительно откорректировав текст). Рекомендуется отметить, что этот код может быть использован для реализации начального набора таблиц БД.

 

4. Реализация базы данных. Далее студент создает полностью спроектированную физическую БД в среде ранее выбранной СУБД, но описывает реализацию базы данных только для 3-5 основных связанных таблиц. При этом необходимо средствами СУБД уточнить структуру таблиц, для каждого поля следует привести основные свойства полей (формат, правила проверки, маски и т.п.). Рекомендуется описать эти свойства в таблице вида табл. 2.6

Таблица 2.6 Основные свойства полей таблицы "Сотрудники "

Поле	Подпись	Маска ввода	….	Правило проверки
Kod_sotr	Код сотрудника
........

 

Для сложных индексов необходимо привести их наименование и индексное выражение. Далее следует привести описание методов поддержки целостности данных в БД. В этом разделе дипломник также описывает другие объекты, входящие в БД (представления, встроенные процедуры, триггеры). Например, для основных таблиц надо сформулировать и реализовать процедуры на добавление и удаление записей, а также на восстановление данных. Перечень объектов можно привести в виде табл. 2.7Таблица 2.7 Перечень объектов БД

№ пп	Имя объекта	Назначение объекта
Представления
1	vПродукция_ Группы	информация о продукции по группам
Триггеры
1	ri_Insert1	поддержка целостности данных при добавлении новой записи
Хранимые процедуры
1	pИзмеренияМассаФакт	расчет фактической массы продукции
2	pСотрудники	Формирование ФИО сотрудников

В приложении студент должен привести SQL -команды или текст, хранимых процедур, а также результаты их выполнения.Если для получения какого-либо запроса или представления использовались другие объекты, то стоит в приложении привести весь каскад SQL -инструкций.

 

5. Организация сбора и обработки информации. В этом разделе необходимо провести расчет объема необходимой дисковой памяти. Этот расчет производится на примерный срок использования БД (пять лет). Расчет можно свести в таблицу вида табл.2.8Таблица 2.8 Расчет объема БД

Название таблицы	Объем заголовка	Объем 1-й записи	Количество записей	Объем записей	Общий объем
Всего

При расчетах надо оценить возможный объем всех остальных файлов БД (системных файлов, индексов и архивных таблиц).Рекомендуется привести схему сбора, обработки и передачи информации (или схему взаимодействия объектов БД) и дать ее описание. Описание схемы должен быть подробным. Например, фрагмент описания может выглядеть следующим образом – “Процесс начинается с приема входной информации <..>, которая сразу регистрируется в таблице <..>. После заполнения таблицы проводится проверка введенных данных <..> После этого выполняется запрос <..>, который используются для формирования выходного документ <..>”Пример построения фрагмента схемы сбора, обработки и передачи информации приведен на рисунке 2.6.

Рисунок 2.6- Фрагмент схемы сбора, обработки и передачи информации