22
документальный;
документальный с регистрацией на машинном носителе;
автоматический.
В проекте разрабатываемой ИС будет использоваться как первый, так и
второй способы регистрации информации. Ввод, обработка и выдача
информации производятся в диалоговом режиме.
В основе диалогового режима лежит динамическое взаимодействие
машины и человека посредством приема и передачи данных через устройства
ввода / вывода. При диалоговом режиме обеспечивается поиск необходимой
информации, быстрая обработка команд, сообщений, активное воздействие
пользователя на ход обработки данных.
Организация диалога осуществляется посредством установки связей
между данными, которые представляют собой информационные модели.
По способу установления связей между данными различают
реляционную, иерархическую и сетевую модели. Реляционная модель является
простейшей и наиболее привычной формой представления данных в виде
таблиц. Иерархическая и сетевая модели предполагают наличие связей между
данными, имеющими какой-либо общий признак. В иерархической модели
такие связи могут быть отражены в виде дерева-графа, в сетевой возможны
связи «всех со всеми».
В настоящее время реляционные системы лучше соответствуют
техническим возможностям персональных компьютеров. Скоростные
характеристики этих СУБД поддерживаются специальными средствами
ускоренного доступа к информации и- индексирование баз данных.
1.6.4 Обоснование проектных решений по технологическому обеспечению
От того насколько рационально будет спроектирован технологический
процесс, настолько гарантировано будет снижение стоимостных, трудовых
затрат.
23
Технологический процесс, как правило, состоит из нескольких этапов.
Целью первого этапа является сбор, регистрация, передача данных для
дальнейшей обработки. Результатом обычно является составление документа.
Цель второго этапа – перенос данных на машинные носители и первоначальное
формирование информационной базы. Третий этап включает операции
накопления, сортировки, корректировки и обработки данных.
При выборе варианта технологического процесса требуется учитывать
следующие требования:
обеспечение достоверности обрабатываемой информации;
решение задач в установленные сроки;
обеспечение минимальных трудовых и стоимостных затрат на
обработку данных;
наличие возможности обработки данных на ЭВМ;
возможность решения задачи в различных режимах.
Исходя из перечисленных выше требований целесообразно
проектирование АРМа, которое позволит децентрализовать процесс решения
задачи и повысить производительность.
При обработке данных желательно использовать массивы нормативно-
справочной информации. Это дает преимущества в скорости поиска, выбора,
сортировки и т.д. При этом необходима возможность просмотра полученных
результатов перед оформлением и передачей выходной информации. Очень
актуальным становится вопрос выбора режима: пакетный или диалоговый.
Пакетный режим позволяет уменьшить вмешательство пользователя в
процесс решения задачи и требует от него только выполнения операций по
вводу и корректировке данных, но вместе с этим появляется вероятность
полной загрузки ЭВМ, что не всегда удобно для пользователя.
Практика показывает, что использование АРМ с применением методов
построения модели на основе диалога обеспечивает более гибкую связь
пользователя с ЭВМ.
24
Диалоговый режим имеет ряд преимуществ: удобен при работе с базой;
обеспечение защиты при несанкционированном доступе; обеспечивает
непосредственное участие пользователя в процессе решения задачи;
управляемость процессом; быстрый доступ, поиск и выдача информации в
любой момент времени, выбор различных режимов работы; осуществление
быстрого перехода от одной операции к другой.
Существует несколько типов диалога: управляющие команды, запросы,
меню, диалог на ограниченном естественном языке.
В данной работе будет использоваться метод меню с многоуровневой
структурой.
25
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Информационное обеспечение задачи
Проектирование базы данных представляет собой последовательность
перехода от неформального словесного описания предметной области к
формализованному описанию объектов предметной области в терминах
некоторой модели. Основная цель проектирования базы данных - это
сокращение избыточности хранимых данных, а следовательно, экономия
объема используемой памяти, уменьшение затрат на многократные операции
обновления избыточных копий и устранение возможности возникновения
противоречий из-за хранения в разных местах сведений об одном и том же
объекте. При создании баз данных следует придерживаться методологии
нормализации отношений.
2.1.1 Структура процесса проектирования
Обследование предметной области. На этом этапе после первоначального
знакомства с предметной областью следует детальное изучение всех ее
фрагментов, каждый из которых характеризуется локальным пользовательским
представлением. Для каждого фрагмента определяются информационные
объекты, анализируются процессы, их использующие, и устанавливаются
явные ассоциации между информационными объектами.
Фрагменты предметной области исследуются последовательно. Причем
сведения об очередном фрагменте интегрируются с полученными при изучении
предшествующих фрагментов.
При выполнении данной работы изучение предметной области (отдела
реализации ИП Шафикова) проводилось в рамках преддипломной практики.
Результаты представлены в отчете по практике и в настоящей работе в
подглаве 1.4.
26
Выбор СУБД. Система управления БД – важнейший программный
компонент информационной системы, оказывающий существенное влияние на
многие параметры системы, в том числе:
• пользовательские интерфейсы;
• эффективность функционирования;
• стоимость разработки приложений;
• стоимость эксплуатации;
• гибкость системы.
Предлагаемая методика выбора СУБД позволяет: последовательно
выявить внешние ограничения, выделить СУБД-претенденты (на
использование), провести моделирование базы данных для каждой выделенной
СУБД и сравнительный анализ полученных моделей базы данных.
Выявление внешних ограничений. Под внешними ограничениями здесь
понимаются ограничения среды реализации информационной системы. Каждая
среда реализации отлична от идеальной. Она содержит множество
ограничений, среди которых наиболее важные для нас: технические,
программные и организационные.
Технические ограничения определяются конфигурацией вычислительной
системы, параметрами функционирования её компонентов, надёжностью их
работы и др.
Программные ограничения в первую очередь подразумевают
операционную систему и языки прикладного программирования.
К организационным ограничениям можно отнести требования к срокам
разработки, имеющиеся трудовые ресурсы. Возможности по подготовке
специалистов и т.п.
Выделение СУБД-претендентов. Проектировщику информационной
системы в настоящее время предоставляется достаточно большой выбор
СУБД, разработанных для разных конфигураций и типов ЭВМ.
Анализ основных параметров этих систем позволяет сразу же отвергнуть
ряд СУБД, заведомо непригодных к использованию в разрабатываемой
27
информационной системе, оставив для последующего рассмотрения несколько
(не более двух-трех) систем претендентов.
На выбор СУБД-претендентов наибольшее влияние оказывает
согласование ряда параметров среды реализации и СУБД. К таким параметрам
в первую очередь относятся:
• тип ЭВМ;
• операционная система;
• объемы оперативной памяти;
• конфигурация вычислительной системы и наличие реализаций СУБД
для нескольких типов ЭВМ.
Однако, в практике разработки малобюджетных проектов приходится
ориентироваться не на некоторый идеальный вариант СУБД, а на имеющееся в
наличии программное обеспечение. Немалое значение при этом имеет
накопленный разработчиками опыт и наработки. При всех преимуществах
СУБД клиент- серверной архитектуры, использование из в данном проекте
представляется нецелесообразным из- за высокой стоимости лицензирования и
сложностей в настройке и обслуживании. Подходящим вариантом
представляется использование Delphi и реализация доступа к данным через
BDE.
Моделирование базы данных. Для каждой из выделенных СУБД
моделируется база данных. Кроме определения структуры данных и стратегии
их хранения в памяти машины, проектировщик оценивает также затраты на
разработку программного окружения базы данных и в целом на реализацию и
эксплуатацию информационной системы.
По существу речь идет о преобразовании инфологической схемы
предметной области в схему базы данных, поддерживаемую СУБД.
Для моделирования необходимо знать выбранные СУБД. Если в
результате моделирования обнаружилось, что ни одна из выделенных СУБД не
позволила получить приемлемый вариант, то сокращается набор требований,
предъявляемых к информационной системе, либо используется самостоятельно
28
разработанная система управления БД, ориентированная на конкретное
применение. Если же получено несколько приемлемых моделей БД, то они
подлежат сравнительному анализу на следующем шаге проектирования.
Сравнительный анализ модели БД. Перед тем как приступить к
сравнительному анализу моделей БД (а, следовательно, и к окончательному
выбору СУБД), необходимо выделить набор факторов, по которым будут
оцениваться рассматриваемые варианты.
Проектирование реализации. Последний, третий этап проектирования
состоит из двух шагов: конструирования схемы базы данных, а также
разработка программного обеспечения и технологии ведения информационной
системы.
Конструирование схемы БД. На этом шаге проектирования окончательно
уточняются все параметры логической и физической организации БД.
Разработка технологии ведения ИС. Разрабатывается набор
технологических инструкций для службы администратора БД. Эти инструкции
охватывают все процессы, выполняемые на стадиях реализации и эксплуатации
информационной системы. В первую очередь это:
- ввод информации в систему;
- защита данных;
- управление использованием данных;
- управление эффективностью системы.
Программное обеспечение технологии ведения ИС составляют сервисные
средства, необходимые для выполнения большинства процессов, включенных в
технологию. Это могут быть стандартные программные продукты (из состава
СУБД или независимо поставляемые) либо оригинальные программные
разработки. Определяя программное обеспечение, оговаривается его состав, а
для оригинальных программ разрабатываются их алгоритмы. В качестве
рабочей методики проектирования выбрано т.наз. E-R проектирование или
проектирование в терминах «Сущность – Связь» (Entity – Relation). Модель
«сущность-связь» позволяет представлять объекты предметной области и
29
Договор
Товар
Экспедитор
Автомобиль
Договор –
покупатель
Договор –
Этап
Доставка
Покупатель
отношения между ними, т.е. позволяет описывать структуру предметной
области. Она определяется в терминах: сущность, атрибут, связь. Сущность -
представление (абстракция) реально существующего объекта, процесса или
явления. Наименование сущности должно быть уникально во всей модели.
Тип сущности - определяет набор однородных объектов, поддающихся
идентификации. Атрибут - свойство сущности (объекта). Его имя должно быть
уникально в рамках одной сущности.
2.1.2 Проектирование модели данных
Е-R проектирование начинается с выделения сущностей в предметной
области. На основании предварительного анализа документации выделим
следующие сущности:
Товар – номенклатурный перечень товаров, поставляемых ИП Шафикова.
Покупатель – физические лица, обращающиеся в магазин для закупки
товаров. Договор, заключенный с покупателем. Реквизитами договора
являются номер и дата заключения. Автомобиль – транспортное средство, на
котором осуществляется доставка товара по договору. Экспедитор –
ответственное лицо, осуществляющее транспортировку товара (доставку по
договору).
Рисунок 3 - Предварительная E-R диаграмма
30
Договор –
Этап
Проведем анализ сущностей и связей предварительной E-R диаграммы.
Связь Договор – покупатель. Один договор связан ровно с одним
покупателем; каждый покупатель может заключить несколько договоров.
Очевидно, что эта связь имеет тип «многие-ко-многим». Существование
договора без покупателя невозможно, в то же время, у сущности «покупатель»
могут существовать экземпляры, не связанные ни с одним договором.
Окончательно класс принадлежности обязателен для сущности «Договор» и
необязателен для сущности «Покупатель».
Рисунок 4 - Связь «Договор – Покупатель»
Связь Договор – товар показана на рисунке 5. Каждый договор может
содержать несколько наименования товара, каждый товар может входить в
несколько договоров, что позволяет говорить о типе связи M:N/ Класс
принадлежности обязателен для сущности «Договор» и необязателен для
сущности «Товар».
Рисунок 5 - Связь «Договор - товар»
Связь Договор – покупатель. Каждый договор связан ровно с одним
клиентом, в то же время каждый покупатель может работать по нескольким
договорам. Наличие реквизитов покупателя при оформлении договора
обязательно, но каждый из клиентов не обязан участвовать в связи. В итоге
Покупатель
Договор
Договор
Товар
Этап -
наименование
31
классифицируем эту связь как тип один ко многим, с обязательным классом
принадлежности для сущности «Договор» и необязательным – для сущности
«Покупатель». (рисунок 6)
Рисунок 6 - Связь «Договор – покупатель»
Связь «Доставка» соединяет сразу три сущности. Такие связи принято
называть тернарными. Анализ типа связи и классов принадлежности связанных
сущностей можно не проводить, т.к. независимо от этих параметров связи со
степенью выше 2 (тернарные, квадринарные и пр.) моделируются отдельным
отношением.
Проведенная классификация связей между сущностями позволяет
преобразовать предварительную E-R диаграмму (рисунок 3) в окончательную,
показанную на рисунке 8. С помощью несложных формальных правил,
приведенных в [19], окончательная диаграмма преобразуется в структуру
таблиц, т.е. на завершающем этапе проектирования базы данных получаем
готовую концептуальную модель предметной области.
Рисунок 7 - Окончательная Е-R диаграмма
Договор
Покупатель
Договор -
покупатель