- основная программная оболочка должна иметь интуитивно ясный дружественный интерфейс и не должна требовать от пользователей специальной подготовки, не связанной с их профессиональными обязанностями;
- система должна иметь возможность наращивания в программной части.
- система должна функционировать под управлением операционных систем Windows 95 и Windows NT.
3.3. Выбор системы проектирования и реализации.
Для технической реализации вышеуказанных задач с учетом поставленных требований была выбрана система управления базами данных «Microsoft Access».
Данная СУБД была выбрана по следующим причинам: . простота средств реализации, . легкость освоения инструментарием разработчика (VBA), . наглядность визуализации информации.
Базы данных созданные с помощью системы управления базами данных «Microsoft Access» полностью реализую реляционную модель построения данных. База данных «Microsoft Access» представляет собой набор групп объектов, таких как таблицы, запросы, формы, отчеты.
Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:
. один-к-одному;
. один–ко-многим;
. многие-к-одному;
. многие-ко-многим.
Структура организации таблиц позволяет создание первичных и внешних ключей. Имеется возможность изменения типа внутренних объединений для связанных таблиц.
Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
. загрузка модулей по требованию;
. оптимизация дерева вызовов;
. использование файлов MDE;
. автоматическая поддержка компилированного состояния;
. использование библиотек Windows API;
. индивидуальная настройка системы;
. эффективное использование индексов;
. встроенный оптимизатор запросов.
Применение пакета «Microsoft ADT» (расширенные средства разработчика) вводит новый уровень визуализации данных, засчет таких элементов, как «Tree View», «Tab Control» и других.
На начальном этапе реализации база данных проектировалась на СУБД «Microsoft Access 2.0».В дальнейшем с появлением новой версии «Microsoft Access 7.0» база данных была переведена на новую версию СУБД, так как в новой версии появились новые инструменты разработчика, улучшенный интерфейс и реальная 32-разрядность. При переходе были отлажены с некоторые проблемы связанные с несовместимостью программного кода различных версий, и так как отладка происходила по мере выявления ошибок, то в дальнейшем возможно возникновение проблем с совместимостью кода.
3.4. Проектирование структуры данных.
До технической реализации структуры базы данных была проанализирована структура взаимодействия отделов предприятия и составлены несколько вариантов бизнес–планов, характеризующие деятельность отделов по различным типам выполняемых работ. При анализе бизнес-планов учитывались критические моменты и проверки, важные с точки зрения обеспечения целостности данных. Также был произведен анализ типов отчетности по каждому из этапов бизнес- планов.
Данные для технической реализации проекта данные имеют следующую структуру, проиллюстрированную Схемой 2 (основные связи).
Основной является таблица с данными по организациям («Заказчики»), к ней отношениями один ко многим связанны таблицы с информацией по основным («ОсновныеСчета») и дополнительным («ДругиеСчета») счетам (у одной организации может быть много счетов как по основному направлению деятельности предприятия, так и по дополнительным направлениям), к таблицам по счетам отношением один ко многим связанны таблицы с информацией по заказам, входящим в данный счет (в один счет может входить несколько заказов). С другой стороны, к таблицам с данными по организациям отношением один-ко-многим связана таблица с данными по авансовому отчету.
Особенностью проектируемой системы является возможность учета денежных средств поступивших по авансовым платежам, что составляет основную долю прихода денежных средств. Структура данных по авансовым платежам построена с учетом того, что выборка по этим данным должна быть представлена в наиболее полном виде, и как можно в более короткое время. Более того, данная структура одинаково хорошо работает с обыкновенной схемой учета денежных средств, то есть списание денежных средств на реализацию без учета аванса.
Данная схема реализована с помощью двух таблиц, связанных отношением один-ко-многим. В главной таблице находятся данные с информацией по счету, такие как код номера счета, тип системы по позиции счета, количество месяцев сопровождения системы по позиции счета, информация о типе платежа (наличный или безналичный расчет).
В подчиненной таблице расписаны суммы авансовых платежей по месяцам. Таким образом, данная структура реализует быстрые выборки по авансовым задолжностям по конкретной организации, что имеет существенное значение при оценке эффективности деятельности предприятия и прогнозирования дальнейшей работы.
Политика расположения данных имеет критическое значение для приложения применительно к скорости работы. Данные, которые меняются нечасто или не меняются вовсе, названия систем семейства Консультант +, названия месяцев года и так далее, были вынесены локально в клиентские модули, так как скорость выборки данных с локального диска компьютера в несколько раз больше скорости выборки данных по запросу из базы данных расположенной на сетевом диске.
Примечание: Для связывания таблиц в дальнейшем рекомендуется, где возможно, применять поле с уникальным значением, но не поле счетчика (так как возможна ситуация с добавлением данных в таблицу, при этом изменяется значение счетчика и теряются связанные данные в подчиненных таблицах)
После реализации основной части проекта база данных была разделена на три отдельных модуля: . модуль для бухгалтерии (MdlByx.mdb), . модуль для отдела сопровождения (MdlClnt.mdb), . модуль данных (Data.mdb).
Организованная структура данных позволяет: . организовать клиент - серверную модель данных, . разработку и изменение модулей параллельно с работой ранее сконструированных, . уменьшает размер резервного файла,
В процессе технической реализации данных задач появились дополнительные задачи:
1. Изменение данных по авансовому отчету (корректировка распределения сумм по месяцам для организаций).
2. Общая результирующая информация по организациям, адресные и банковские реквизиты, счета, выписанные на организации, информация по системам для данной организации.
3. Обмен сообщениями между пользователями (использование для заказа счетов актов и так далее).
3.4.1. Описание структуры данных проекта.
В процессе разработки базы данных была выработана следующая иерархическая структура данных.
Часть 1. (листинг 2.1)
(таблицы «Заказчики», «СтатусЗаказчика»,«Курьеры»,«Примечания»,)
1. Связь таблицы «Заказчики» с таблицей «СтатусЗаказчика». Поле: «Код» в обеих таблицах
Тип связи: один ко многим без обеспечения целостности данных.
(один со стороны таблицы «СтатусЗаказчика»)
Связывание: мастер подстановок в таблице «Заказчики»
Примечания: данная связь заменяет повторяющееся текстовые значения типа организации соответствующим кодом из таблицы «СтатусЗаказчика».
2.Связь таблицы «Заказчики» с таблицей «Курьеры».
Поле: «КодКурьера» в обеих таблицах.
Тип связи: один ко многим с обеспечением целостности данных.
(один со стороны таблицы «Курьеры»)
Примечания: предусматривает добавление в структуру данных модуля «Курьеры».
3.Связь таблицы «Заказчики» с таблицей «Примечания».
Поле: «КодЗаказчика» в обеих таблицах.
Тип связи: один ко многим без обеспечением целостности данных.
(один со стороны таблицы «Заказчики»)
(возможно связывание один к одному)
Связывание: мастер подстановок в таблице «Примечания»
Часть 2. (листинг 2.2)
(таблицы «Заказчики», «КредитАванс», «ОсновныеСчета», «Дистрибутивы»,
«Системы»,
«ФормаОплаты», «ТипСистемы», «Платежки», «СчетаФактуры»,
«СчетаФактурыОсновные»)
1.Связь таблицы «Заказчики» с таблицей «ОсновныеСчета».
Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.
Связывание: мастер подстановок в таблице «ОсновныеСчета»
Примечания: у каждого заказчика может быть много счетов.
2.Связь таблицы «Заказчики» с таблицей «КредитАванс».
(возможно связывание один к одному?)
Связывание: мастер подстановок в таблице «КредитАванс»
3.Связь таблицы «Заказчики» с таблицей «СчетаФактуры».
Связывание: мастер подстановок в таблице «СчетаФактуры»
Примечания: у каждого заказчика может быть много счетов-фактур.
4. Связь таблицы «ОсновныеСчета» с таблицей «Дистрибутивы».
Поле: «КодСчета» в обеих таблицах.
(один со стороны таблицы «ОсновныеСчета»)
Связывание: мастер подстановок в таблице «Дистрибутивы»
Примечания: в каждый счет может входить много записей по заказам.
5. Связь таблицы «ОсновныеСчета» с таблицей «Платежки».
Примечания: в каждому счету может относится несколько платежных поручений.
(*Если платежное поручение оплачивает несколько счетов, то при внесении данных к счетам пишется одно и тоже платежное поручение, но суммы вносятся в соответствии с суммой счета)
6. Связь таблицы «ОсновныеСчета» с таблицей «СчетаФактурыОсновные».
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
