Добавлен: 25.10.2018
Просмотров: 4945
Скачиваний: 3
54
СУБД, которые могут обеспечивать более быстрый, чем реляционные СУБД,
доступ к информации БД, недостатком является то, что их структура часто не
может быть изменена после ввода данных, тогда как для реляционных СУБД
структура может изменяться в любое время. Поэтому для небольших БД луч-
ше использовать реляционную модель данных, а для больших БД, структура
которых остается длительное время неизменной, и постоянно работающих с
ними приложений с интенсивными потоками запросов на обслуживание
именно иерархические и сетевые СУБД могут оказаться наиболее эффектив-
ными решениями. Как правило, в ВКР бакалавров реализуются реляционные
модели БД, в которых отношения представлены в виде таблиц, строки кото-
рых соответствуют кортежам или записям, а столбцы – атрибутам отношений,
доменам, полям.
Для разработки базы данных дипломнику требуется, прежде всего, по-
строить концептуальную и логические модели данных. Для этого на основа-
нии известных форм выходящей информации выделяются информационные
сущности, характеризующие предметную область, а затем устанавливается
информационная структура взаимосвязей сущностей предметной области (т.е.
связи один к одному, один ко многим или многие ко многим). На основании
этого анализа строят логическую модель данных в виде ER-диаграммы.
Необ-
ходимо напомнить, что логическая модель данных не зависит от конкретной
целевой СУБД, она создается с учетом выбранной модели хранения данных,
например реляционной, сетевой или иерархической.
Одни и те же данные могут группироваться в таблицы (отношения) раз-
личными способами, т.е. возможна организация различных наборов отноше-
ний взаимосвязанных информационных объектов. Определенный набор отно-
шений обладает лучшими свойствами при включении, модификации, удале-
нии данных, чем все остальные возможные наборы отношений, если он отве-
чает требованиям нормализации отношений. Нормализация отношений – это
формальный аппарат ограничений на формирование отношений (таблиц), ко-
торый позволяет устранить дублирование, обеспечивает непротиворечивость
55
хранимых в БД, уменьшает трудозатраты на еѐ ведение. Нормализации от-
ношений включает в себя процессы преобразования отношений в нормальные
формы 1НФ, 2НФ и 3НФ.
После выполнения нормализации следует его результаты представить в
виде таблицы «Перечень нормализованных отношений в реляционной модели
предметной области», в которой имеются три столбца: Имя отношения; Клю-
чевые атрибуты; Неключевые атрибуты.
Необходимо также представить
ER – диаграмму (схема нормализованных
отношений) после нормализации.
Раздел 2.3 Программное обеспечение
Данный раздел включает два следующих подраздела:
2.3.1 Разработка дерева функций и сценария диалога;
2.3.2 Характеристика базы данных.
Подраздел 2.3.1.Разработка дерева функций и сценария диалога
Этап формирования дерева функций является одним из наиболее ответ-
ственных как при анализе, так и при синтезе структуры системы. Ошибки на
этом этапе приводят к созданию систем, которые не способны к полной функ-
циональной адаптации с другими системами, конечными пользователями и
окружающей средой.
Дерево функций системы – это графическое описание декомпозиции еѐ
функций, которое формируется с целью детального исследования функцио-
нальных возможностей системы и анализа совокупности функций, реализуе-
мых на различных уровнях иерархии системы. На базе дерева функций систе-
мы осуществляется формирование структуры системы на основе функцио-
нальных модулей.
Все функции, реализуемые сложной системой, могут быть условно раз-
делены на три группы: целевая функция; базисные функции системы; допол-
56
нительные функции системы. Целевая функция системы отражает назначение,
сущность и смысл существования системы. Основные функции отражают ори-
ентацию системы и представляют собой совокупность макрофункций, реали-
зуемых системой. Эти функции обусловливают существование системы опре-
деленного класса. Основные функции обеспечивают условия выполнения це-
левой функции (прием, передача, хранение и др.). Дополнительные (сервис-
ные) функции расширяют функциональные возможности системы, способ-
ствуют улучшению еѐ показателей качества и обеспечивают условия выпол-
нения основных функций. Формулировка функции внутри вершин должна
включать 2 слова: глагол и существительное «Делать что».
На рисунке 3 приведен пример дерева функций ИС отдела планирова-
ния. На схеме детализированы два подмножества функций: служебные функ-
ции: вызов заставки и основных экранных форм; основные функции: ввод и
обработка первичной информации, форматирование результативных докумен-
тов.
Следует отметить, что в пояснительной записке следует не только при-
вести схему дерева функций, но и описать еѐ.
На основании разработанного дерева функций следует разработать сце-
нарий диалога, который позволяет определить состав кадров диалога, содер-
жание каждого кадра и их соподчиненность.
При разработке структуры диалога необходимо обязательно обеспечить
возможность работы с входной информацией, формирование выходных доку-
ментов, корректировки вводимых данных, просмотра настроек и конфигура-
ций системы, а также помощь конечному пользователю на всех этапах работы.
В некоторых сложных системах диалог не формализуется в структурной фор-
ме и тогда данный пункт может не содержать описанных схем. В случае, если
диалог реализуется с использованием контекстно-зависимого меню, то следу-
ет однозначно определить все уровни, на которых пользователь принимает
решение относительно следующего действия, а также обосновать решение
применения выбранной им технологии.
57
ИС отдела планирования
Основные функции
Служебные функции
Ведение
справочников
Справочник
«Виды продукции»
Просмотр
Ввод первичных
документов
Просмотр
Формирование
результативных
документов
Вызов заставки
Вызов экранных
форм
Просмотр
Прокрутка
Проверка пароля
Вызов справки
Файл «Отчѐт по
продажам»
Файл «Отчѐт по
производству»
Файл «Отчѐт по складу»
Файл «Отчѐт по
доставке»
Экранная форма «Отчет
по филиалам»
Экранная форма «Отчет
по видам продукции»
Экранная форма «Отчет
по складам»
Просмотр
Редактирование
Файл «Табель учета
рабочего времени»
Файл «Комплексный
отчет по складам»
Справочник
«Склады»
Справочник
«Филиалы»»
Справочник
«Клиенты»
Таблица «План продаж»
Таблица «План
производства»
Таблица «План
складирования»
Таблица «План доставки»
Просмотр
Файл «План продаж»
Файл «План
производства»
Файл «План
складирования»
Файл «План доставки»
Файл «Отчет по
филиалам»
Файл«Отчет по видам
продукции»
Файл «Отчет по складам»
Просмотр
Печать
Таблица «Продажи»
Таблица «Производство»
Таблица «Сток»
Таблица «Доставка»
Печать
Таблица «Коэффициенты
планирования»
Таблица «План продаж»
Таблица «План
производства»
Таблица «План
складирования»
Таблица «План
доставки»
Загрузка
Формирование
Импорт данных
Рисунок 3- Пример дерева функций ИС отдела планирования
В качестве примера для приведенного выше дерева функций на рис. 4
представлен сценарий диалога.
После описания сценария диалога и представления кадров экранных
форм необходимо сделать вывод, позволяет ли разработанный дипломником
сценарий диалога просто и удобно работать пользователю с программой, яв-
ляется ли он удобным и функционально не избыточным.
58
Заставка
Главное меню
Ввод имени
пользователя и
пароля
Справочники
Справочник «Виды
продукции»
Справочник
«Склады»
Справочник
«Филиалы»
Справочник
«Контракты»
Таблицы
Таблица
«Продажи»
Таблица
«Производство»
Таблица «Сток»
Файл «Отчет по видам
продукции»
Файл «Комплексный
отчет по филиалам»
Файл «Отчѐт по
производству»
Файлы и экранные
формы
Файл «План отчѐт по
продажам»
Файл «План-отчѐт по
складированию»
Экранная форма
«Отчѐт по видам
продукции»
Таблица «План
производства»
Таблица «План
складирования»
Файл «Отчет по
складам»
Таблица «План
продаж»
Таблица
«Доставки»
Таблица «План
доставки»
Файл «План -отчѐт по
производству»
Экранная форма
«Отчѐт по складам»
Файл «Табель учѐта
рабочего времени»
Файл «Отчѐт по
проадажам»
Экранная форма
«Отчѐт по филиалам»
Файл «Отчет по
доставке»
Файл «План-отчѐт по
доставке»
Таблица
«Коэффициенты
планирования»
Рисунок 4
- Сценарий диалога
Подраздел 2.3.2 Характеристика базы данных
Ранее были описаны (Подраздел 2.2.4 Разработка модели данных) и,
надеюсь, дипломником уже выполнены этапы концептуального и логического
проектирования БД. В данном подразделе будет описан этап физического
проектирования, основной целью которого является описание способа физи-
ческой реализации логического проекта базы данных. Такой подход к струк-