Обзор и анализ существующих методов решения задачи. 
Обоснование выбора метода решения или разработки нового

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

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

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

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

Система управления базами данных (СУБД) должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют или не хотят иметь представления о:

физическом размещении в памяти данных и их описаний;

механизмах поиска запрашиваемых данных;

проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод проектирования сверху вниз;

Метод потоков данных;

Объектно-ориентированное проектирование.

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

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

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

• · абстрагирование;
• · инкапсуляция;
• · модульность;
• · иерархия.

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

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

Модульность — свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

Иерархия — упорядочивание абстракций, расположение их по уровням.

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

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

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

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

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

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

При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

Необходимо использовать как можно меньше разрозненных данных в разных таблицах. Рекомендуется объединять связанные по смыслу данные в одну таблицу. Это повышает эффективность работы с такими данными.

Сведения на разные темы обрабатываются намного быстрее, если они находятся в разных таблицах. При необходимости обработки таких данных совместно, вводятся дополнительные поля, по которым записи «связываются».

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

При разработке полей для каждой таблицы необходимо помнить:

Каждое поле должно быть связано с темой таблицы.

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

В таблице должна присутствовать вся необходимая информация.

Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).

Задание индивидуального значения каждой записи Для того чтобы Delphi мог связать данные из разных таблиц, каждая таблица должна содержать поле или набор полей, которые будут задавать индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют «ключом» или ключевым полем.

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

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

Корректировка структуры базы данных После проектирования таблиц, полей и связей необходимо еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными. Если изменения структуры производить в таблицах, в которые уже занесена информация, то возможна порча или даже потеря данных.

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

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

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

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

Более подробно реализация будет рассмотрена в следующей главе.