Обзор и обоснование выбора инструментальных средств

Для обоснования выбора конкретной СУБД для разработки базы данных был проведен сравнительный анализ трех СУБД, результаты которого приведены в таблице 2.2 /7,8,9/.

Таблица 2.2 – Сравнительные характеристики СУБД

Продолжение таблицы 2.2

В качестве СУБД для разработки базы данных выбрана СУБД InterBase 7.5. Borland InterBase 7.5 – высокопроизводительный, кроссплатформенный сервер баз данных /10/. Он сочетает в себе легкость установки, автоматическое восстановление после сбоев и минимальную потребность в сопровождении, что очень важно для надежного функционирования распределенных, высокопроизводительных, критически важных бизнес-приложений.

Преимущества использования Borland InterBase 7.5:

- простота инсталляции и администрирования;

- поддержка платформ Windows, Linux и Solaris;

- запатентованные обработчики оповещений о событиях;

- поддержка сред разработки Borland Delphi, Kylix и других;

- совместимость со стандартом SQL92 и удобный SQL-интерфейс;

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

- адаптация для коммерческой деятельности;

- низкая совокупная стоимость владения и высокая рентабельность.

В Borland InterBase 7.5 внесены значительные улучшения, что приводит не только к повышению эффективности труда разработчиков, но и к увеличению производительности самих приложений. Среди новых возможностей Borland InterBase 7.5:

- поддержка SMP с применением архитектуры Multi-Generational, т.е. распараллеливания операций для увеличения производительности на многопроцессорном оборудовании (SMP), как для клиента, так и для сервера;

- мониторинг транзакций, подключений, пользователей и другого, для упрощения аудита и управления;

- драйвер JDBC 4, который упрощает распространение клиентских приложений и администрирование сервера.

Все эти качества делают Borland InterBase 7.5 наиболее подходящим решением для реализации базы данных.

Сравнительные характеристики средств разработки приложений АИС приведены в таблице 2.3 /7,11,12,13/.

Таблица 2.3 – Сравнительные характеристики средств разработки приложений

Продолжение таблицы 2.3

Язык С++ является основополагающим системным языком, его удобный, компактный, удобочитаемый синтаксис позаимствован многими другими языками: PHP, Perl, Java, C#, JavaScript и другими /14/. Библиотек на этом языке в Internet представлено огромное количество, что позволяет упрощать программирование практически любой предметной области. Из приведенных языков для реализации поставленной задачи выбран язык C++, как наиболее подходящий для программирования небольшой АИС.

В качестве среды разработки приложений автоматизированной информационной системы была выбрана Borland C++ Builder 6.0. Данная среда является мощной средой разработки приложений с широкими возможностями управления проектом. Предоставляется возможность разработки как визуальных, так и консольных приложений. Среда имеет большое число дополнительных компонент, поддерживает объектно-ориентированное программирование, позволяет быстро и удобно разрабатывать эффективные приложения, включая приложения для работы с базами данных /15/.

Разработка базы данных

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни ее архитектуры. Распространены два основных подхода к проектированию систем баз данных: нисходящий и восходящий /16/.

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

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

Таким образом, для проектирования базы данных выбран нисходящий метод, содержащий ряд этапов:

- анализ предметной области. На основе анализа предметной области получают описание внешнего уровня БД, являющееся исходными данными для следующего этапа;

- разработка инфологической модели (ИЛМ). По полученному на предыдущем этапе описанию строится модель данных «сущность-связь»;

- разработка даталогической модели (ДЛМ). На основе ИЛМ предметной области строится ДЛМ базы данных;

- нормализация. Этап представляет собой нормализацию полученной модели;

- формирование физической модели БД на языке определения данных СУБД. На заключительном этапе проектирования строится физическая модель данных с учетом особенностей используемой СУБД.

Инфологическая модель предметной области представлена в приложении А ER-диаграммой, построенной по методологии Ричарда Баркера. Даталогическая модель представлена в пункте 2.3.2.3 логической структурой базы данных. Описание физической модели базы данных рассматривается в пункте 2.3.3.

2.3.1 Описание внешнего уровня архитектуры базы данных

Описание внешнего уровня базы данных проводится на основе анализа предметной области. Внешний уровень – это обобщенное представление всех пользователей в системе.

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

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

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

- описание предметной области на уровне классов объектов (сущностей) и отношений (связей) между ними.

- состав пользователей системы БД и их уровни доступа к БД.

2.3.1.1 Иерархия функций

Иерархия функций разрабатываемой автоматизированной информационной системы представлена в таблице 2.4.

Таблица 2.4 – Иерархия функций

Продолжение таблицы 2.4

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

2.3.1.2 Формализованное описание предметной области

Выявленные классы объектов и их свойства представлены в таблице 2.5.

Таблица 2.5 – Классы объектов предметной области, свойства

Продолжение таблицы 2.5

Продолжение таблицы 2.5

Продолжение таблицы 2.5

Продолжение таблицы 2.5

В таблице 2.5 использованы сокращения: УИ – уникальный идентификатор, П – кандидат в первичный ключ (главный уникальный идентификатор), Г – генерация значения, Вв – ввод значения, Пр – просмотр значения, Об – обновление значения.

Связи между выявленными классами объектов представлены в таблице 2.6.

Таблица 2.6 – Связи между классами объектов (КО)

Продолжение таблицы 2.6

Продолжение таблицы 2.6

В таблице 2.6 использованы сокращения: 1 – тип связи «один», М – тип связи «много», «д.б.» – связь обязательная, «м.б.» – связь необязательная.

Далее связь проверяется путем чтения в обе стороны:

- каждому ТИПУ ТОВАРА может соответствовать один или более ТОВАРА. Каждый ТОВАР должен относиться к одному и только одному ТИПУ ТОВАРА;

- каждому ПРАЙСУ может соответствовать одна или более ПОЗИЦИЙ ПРАЙСА. Каждая ПОЗИЦИЯ ПРАЙСА должна относиться к одному и только одному ПРАЙСУ;

- каждой ЕДИНИЦЕ ИЗМЕРЕНИЯ может соответствовать одна или более ПОЗИЦИЙ ПРАЙСА. Каждая ПОЗИЦИЯ ПРАЙСА должна относиться к одной и только одной ЕДИНИЦЕ ИЗМЕРЕНИЯ;

- каждой ЕДИНИЦЕ ИЗМЕРЕНИЯ может соответствовать одна или более ПОЗИЦИЙ ВЕДОМОСТИ. Каждая ПОЗИЦИЯ ВЕДОМОСТИ должна относиться к одной и только одной ЕДИНИЦЕ ИЗМЕРЕНИЯ;

- каждому ТОВАРУ может соответствовать одна или более ПОЗИЦИЙ ПРАЙСА. Каждая ПОЗИЦИЯ ПРАЙСА должна относиться к одному и только одному ТОВАРУ;

- каждому ТОВАРУ может соответствовать одна или более ПОЗИЦИЙ ВЕДОМОСТИ. Каждая ПОЗИЦИЯ ВЕДОМОСТИ должна относиться к одному и только одному ТОВАРУ;

- каждой ДОЛЖНОСТИ может соответствовать один или более ДОГОВОРОВ О РАБОТЕ. Каждый ДОГОВОР О РАБОТЕ должен относиться к одной и только одной ДОЛЖНОСТИ;

- каждому ТИПУ СТРУКТУРНОЙ ЕДИНИЦЫ / ЮРИДИЧЕСКОГО ЛИЦА может соответствовать одна или более СТРУКТУРНЫХ ЕДИНИЦ / ЮРИДИЧЕСКИХ ЛИЦ. Каждая СТРУКТУРНАЯ ЕДИНИЦА / ЮРИДИЧЕСКОЕ ЛИЦО должна относиться к одному и только одному ТИПУ СТРУКТУРНОЙ ЕДИНИЦЫ / ЮРИДИЧЕСКОГО ЛИЦА;

- каждая СТРУКТУРНАЯ ЕДИНИЦА / ЮРИДИЧЕСКОЕ ЛИЦО может иметь в подчинении одну или более СТРУКТУРНЫХ ЕДИНИЦ / ЮРИДИЧЕСКИХ ЛИЦ. Каждая СТРУКТУРНАЯ ЕДИНИЦА / ЮРИДИЧЕСКОЕ ЛИЦО может подчиняться только одной вышестоящей СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ;

- каждой СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ может соответствовать один или более ДОГОВОРОВ О РАБОТЕ. Каждый ДОГОВОР О РАБОТЕ должен относиться к одной и только одной СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ;

- каждому ДОГОВОРУ О РАБОТЕ может соответствовать как менеджер одна или более ВЕДОМОСТЕЙ. Каждая ВЕДОМОСТЬ должна относиться как менеджер к одному и только одному ДОГОВОРУ О РАБОТЕ;

- каждому ДОГОВОРУ О РАБОТЕ может соответствовать как заведующий складом одна или более ВЕДОМОСТЕЙ. Каждая ВЕДОМОСТЬ должна относиться как заведующий складом к одному и только одному ДОГОВОРУ О РАБОТЕ;

- каждому ВИДУ ЦЕНЫ может соответствовать одна или более ПОЗИЦИЙ ПРАЙСА. Каждая ПОЗИЦИЯ ПРАЙСА должна относиться к одному и только одному ВИДУ ЦЕНЫ;

- каждому ТИПУ ВЕДОМОСТИ может соответствовать одна или более ВЕДОМОСТЕЙ. Каждая ВЕДОМОСТЬ должна относиться к одному и только одному ТИПУ ВЕДОМОСТИ;

- каждой СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ может соответствовать как склад одна или более ВЕДОМОСТЕЙ. Каждая ВЕДОМОСТЬ должна относиться как склад к одной и только одной СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ;

- каждой СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ может соответствовать как поставщик / покупатель одна или более ВЕДОМОСТЕЙ. Каждая ВЕДОМОСТЬ может относиться как поставщик / покупатель только к одной СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ;

- каждому ФИЗИЧЕСКОМУ ЛИЦУ может соответствовать одна или более ВЕДОМОСТЕЙ. Каждая ВЕДОМОСТЬ может относиться только к одному ФИЗИЧЕСКОМУ ЛИЦУ;

- каждой ВЕДОМОСТИ может соответствовать одна или более ПОЗИЦИЙ ВЕДОМОСТИ. Каждая ПОЗИЦИЯ ВЕДОМОСТИ должна относиться к одной и только одной ВЕДОМОСТИ;

- каждому ПОЛУ ФИЗИЧЕСКОГО ЛИЦА может соответствовать одно или более ФИЗИЧЕСКИХ ЛИЦ. Каждое ФИЗИЧЕСКОЕ ЛИЦО должно относиться к одному и только одному ПОЛУ ФИЗИЧЕСКОГО ЛИЦА;

- каждому ФИЗИЧЕСКОМУ ЛИЦУ может соответствовать один или более ДОГОВОРОВ О РАБОТЕ. Каждый ДОГОВОР О РАБОТЕ должен относиться к одному и только одному ФИЗИЧЕСКОМУ ЛИЦУ;

- каждому ТИПУ УЛИЦЫ может соответствовать одна или более УЛИЦ. Каждая УЛИЦА должна относиться к одному и только одному ТИПУ УЛИЦЫ;

- каждому ТИПУ НАСЕЛЕННОГО ПУНКТА может соответствовать один или более НАСЕЛЕННЫХ ПУНКТОВ. Каждый НАСЕЛЕННЫЙ ПУНКТ должен относиться к одному и только одному ТИПУ НАСЕЛЕННОГО ПУНКТА;

- каждой УЛИЦЕ может соответствовать один или более АДРЕСОВ. Каждый АДРЕС должен относиться к одной и только одной УЛИЦЕ;

- каждому НАСЕЛЕННОМУ ПУНКТУ может соответствовать один или более АДРЕСОВ. Каждый АДРЕС должен относиться к одному и только одному НАСЕЛЕННОМУ ПУНКТУ;

- каждая СТРУКТУРНАЯ ЕДИНИЦА / ЮРИДИЧЕСКОЕ ЛИЦО может иметь только один АДРЕС. Каждый АДРЕС может быть зафиксирован только для одной СТРУКТУРНОЙ ЕДИНИЦЫ / ЮРИДИЧЕСКОГО ЛИЦА;

- каждое ФИЗИЧЕСКОЕ ЛИЦО может иметь только один АДРЕС. Каждый АДРЕС может быть зафиксирован только для одного ФИЗИЧЕСКОГО ЛИЦА;

- каждому ТИПУ ТЕЛЕФОНА может соответствовать один или более ТЕЛЕФОНОВ. Каждый ТЕЛЕФОН должен относиться к одному и только одному ТИПУ ТЕЛЕФОНА;

- каждая СТРУКТУРНАЯ ЕДИНИЦА / ЮРИДИЧЕСКОЕ ЛИЦО может иметь один или более ТЕЛЕФОНОВ. Каждый ТЕЛЕФОН может относиться только к одной СТРУКТУРНОЙ ЕДИНИЦЕ / ЮРИДИЧЕСКОМУ ЛИЦУ;

- каждое ФИЗИЧЕСКОЕ ЛИЦО может иметь один или более ТЕЛЕФОНОВ. Каждый ТЕЛЕФОН может относиться только к одному ФИЗИЧЕСКОМУ ЛИЦУ;

- каждой ПОЗИЦИИ ПРАЙСА может соответствовать одна или более ПОЗИЦИЙ ВЕДОМОСТИ. Каждая ПОЗИЦИЯ ВЕДОМОСТИ должна относиться к одной и только одной ПОЗИЦИИ ПРАЙСА.

2.3.1.3 Пользователи АИС. Уровни доступа пользователей

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

- администратор базы данных (АБД), обладающий всеми правами – он может осуществлять все действия со значениями свойств классов объектов;

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

- конечный пользователь – менеджер по продажам, выполняющий операции добавления и обновления данных;

- конечный пользователь – заведующий складом.

Описание состава пользователей АИС и их уровни доступа представлены в таблице 2.7.

Таблица 2.7 – Уровни доступа к БД пользователей АИС