Разработка информационной системы садово – производственного кооператива

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

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

Модели данных

Иерархическая модель данных

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

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

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

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

Сетевая модель данных

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

Основной конструкцией сетевой модели данных является набор. Для каждого типа набора, определяемого в схеме, должен  быть указан определенный тип записи владельца набора, а так же произвольное число типов записи членов набора. Каждый экземпляр набора состоит из одного экземпляра-владельца и одного или более экземпляров записей-членов.

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

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

Реляционная модель данных

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

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

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

Основной недостаток реляционной модели данных связывается с низкой производительностью реляционной СУБД. Но разработка современных СУБД таких как, ORACLE, InterBase, Acsses и др. позволило преодолеть и этот недостаток.

Достоинства реляционной модели можно разделить на две группы:

1. достоинства для пользователя:

• реляционная БД представляет собой набор таблиц с которыми пользователь привык работать;

• не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;
• реляционные языки легки для изучения и освоения, в то время как языки общения с иерархической и сетевой моделями предназначены для программистов и мало пригодны для пользователей;

2. достоинства обработки данных реляционной БД:

• связность. Реляционное представление дает ясную картину взаимосвязей атрибутов из различных отношений;
• точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений [5], обеспечивающих наглядность и гибкость модели данных;
• гибкость. Операции проекции и объединения [17] позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме;
• секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа;
• простота внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур;
• независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений.

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

Выбор концептуальной модели

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

• семантическая модель;
• фреймы;
• модель “сущность-связь”.

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

• описание объектов предметной области происходит естественным языком;
• все записи, поступающие в БД накапливаются в относительно однородной структуре.

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

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

Модель “сущность-связь” описывается в терминах сущность, связь, значение. Сущность – понятие которое может быть идентифицировано. Связь – соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграма. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность – это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа "многие-ко-многим" или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграма – графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей – ромбом. Связи могут быть трех типов: “один к одному”, “один ко многим”, “многие ко многим” - данные типы связи присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы.

В связи с тем, что модель “сущность-связь” наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобна, то в качестве концептуальной модели выбрана модель “сущность-связь”.

Методы проектирования АСИС

Метод — это последовательный процесс создания моделей, которые описывают вполне определёнными средствами различные стороны разрабатываемой программной системы. Методы важны по нескольким причинам:

Во-первых, они упорядочивают процесс создания сложных программных систем.

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

Методы проектирования делятся на три основные группы;

• Метод проектирования сверху вниз;
• Метод потоков данных;
• Объектно-ориентированное проектирование.

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

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

Объектно-ориентированное проектирование (object-oriented design, OOD) - это подход в основе которого лежит представление о том, что программную систему нужно проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определённого класса, причём классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких как Object Pascal, C++, Smalltalk [23] и др. Для данного метода проектирования присущи четыре главных элемента: