Файл: Разработка проекта информационной системы для фирмы, торгующей автомобилями ( Теоретические аспекты разработки информационных систем).pdf

логическая модель и внутреннее представление – совокупность представлений системных программистов, администрирующих базу данных [16].

Рисунок 3. Уровни представлений о данных в базе данных [16]

При проектировании реляционных моделей данных разрабатываются ER-диаграммы, реляционная схема и сопроводительная документация. Для проверки корректности построенной логической модели данных используются правила нормализации. Нормализация является эффективным средством, которое позволяет удостоверить структурную согласованность, логическую целостность и минимальную избыточность выбранной модели данных [7, 9, 12].

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

1.3 Особенности применения технологической платформы 1С:Предприятие 8

Базовыми механизмами системы 1С:Предприятие 8 решается цель значительного ускорения и унификации как самой разработки прикладных решений, так и их сопровождения. Повышая уровень абстракции, четко разделяя систему на платформу и прикладное решение, создавая прикладное решение на основе метаданных, разработчик может перейти от технических и низкоуровневых понятий к более содержательным и высокоуровневым, а значит приблизить их к языку пользователей и специалистов в предметной области. Благодаря тому, что все прикладные решения строятся на основе определенной модели, решаются и традиционные задачи, связанные с производительностью, эргономикой, функциональностью [11].

Система программ «1С:Предприятие 8» содержит технологическую платформу и разработанные на ее основе прикладные решения. Единая концепция интерфейса всех прикладных решений 1С:Предприятия 8 основывается на использовании стандартных элементов, которые предоставляются платформой. Из этого следует, что пользователи какого-либо одного прикладного решения, вполне комфортно могут работать и с любым другим прикладным решением 1С:Предприятия 8 [1].

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

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

Механизмы, обеспечивающие формирование экономической и аналитической отчетности, являются комплексом средств, которые позволяют формировать не просто печатные формы, а интерактивные документы, тесно интегрированные в прикладное решение. Пользователи смогут не только вывести на печать отчет, но и работать с ним практически так же, как с любой экранной формой – изменять параметры отчета, перестраивать его, использовать «расшифровки» – возможность формирования дополнительных отчетов на основе отдельных элементов уже сформированного отчета [4, 11].

Перечислим основные механизмы, которые используются при создании экономических и аналитических отчетов [11, 18]:

Механизм запросов является эффективным способом доступа к данным, поддерживаемым платформой. С помощью этого механизма обеспечивается чтение и обработка данных, которые хранятся в информационной базе; изменение данных с помощью запросов невозможно [19].

Система компоновки данных является механизмом, основанным на декларативном описании отчетов. Он предназначается для построения отчетов, а также вывода информации со сложной структурой и содержащей произвольный набор таблиц и диаграмм. Система компоновки данных обеспечивает реализацию следующих возможностей [1, 17]: создание отчетов без программирования; использование автоматически генерируемых форм просмотра и настройки отчета, разбиение исполнения отчета на этапы; независимое использование отдельных частей системы компоновки данных и программное управление процессом выполнения отчета.

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

В систему компоновки данных входит несколько основных частей. Исходные данные для компоновки отчета (наборы данных и методы работы с ними) содержатся в самой схеме компоновки данных [18].

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

Процесс взаимодействия этих объектов выглядит следующим образом:

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

Таким образом, конфигуратор «1С:Предприятия 8» позволяет выполнять разработку и администрирование информационных баз, является удобным и эффективным средством разработки информационных систем.

2 Разработка информационной системы

2.1 Проектирование базы данных

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

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

На основе анализа предметной области продажи автомобилей выделим информационные объекты и их атрибуты. Выделяем объекты-сущности Покупатели, Сотрудники, Банки, Поставщики, Автомобили, Файлы, Цены, Розничные цены, Продажа автомобиля, Поступление авто, Оплата поставщику, Оплата от покупателя.

Рассмотрим атрибуты перечисленных объектов в таблице 1.

Таблица 1. Атрибуты объектов

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

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

Необходимо выполнить анализ каждого атрибута на наличие взаимосвязей с другими реквизитами объекта. Реквизит приобретает смысл, только в том случае, когда связывается с другими атрибутами, которые обладают смысловым единством [14].

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

Отношение «Покупатели» -> «Продажа автомобиля». «Покупатели» является главным объектом, а «Продажа автомобиля» подчинённым объектом. Определен тип связи «один ко многим» (Рисунок 4). Один Покупатель может участвовать в нескольких продажах автомобиля. Указанные объекты связываются между собой по атрибуту «Код покупателя».

Покупатели

Продажа автомобиля

1:M

Рисунок 4. Связь между объектами «Покупатели» и «Продажа автомобиля»

Аналогично определили отношения (взаимосвязи) и мощности отношений между другими объектами [7]. В результате сформирована таблица 2.

Таблица 2 – Отношения между таблицами

Центральными сущностями базы данных являются таблицы «Автомобили», «Продажа автомобиля», связанные с наибольшим количеством таблиц отношением один-ко-многим. Спроектированная в MS Visio инфологическая модель базы данных по методологии проектирования IDEF1X изображена на рисунке 5.

После того, как были выделены объекты предметной области и их атрибуты, затем обобщены все данные и определены связи между ними, первичные и внешние ключи. Это представлено в виде ER-диаграмм (диаграмм «сущность-связь»), наглядных и удобных для восприятия [9].

Рисунок 5. Инфологическая модель базы данных

Были определены типы данных для атрибутов каждой сущности (использовался переносимый тип данных) [7], так на рисунке 6 отображены атрибуты сущности «Сотрудники», предназначенной для хранения информации по сотрудникам. В качестве первичного ключа задан столбец «Код сотрудника». Аналогично были определены типы данных для атрибутов остальных сущностей.

Рисунок 6. Атрибуты сущности «Сотрудники»

2.2 Разработка базы данных информационной системы в конфигураторе 1С:Предприятие 8.2

В ходе этапа физического проектирования базы данных разработчик принимает окончательное решение о способах реализации создаваемой базы. Поэтому физическое проектирование необходимо производить, учитывая все особенности выбранной СУБД 1С:Предприятие 8.2 [1, 12].

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

В соответствии с разработанной ранее инфологической моделью базы данных произведено проектирование структуры:

• справочников: Покупатели, Сотрудники, Банки, Поставщики, Автомобили, Файлы;
• регистров сведений: Цены, Розничные цены;
• регистров накопления: Остатки авто, Продажи;
• документов: Продажа автомобиля, Поступление авто, Оплата поставщику, Оплата от покупателя.

Разработанный справочник «Покупатели» содержит следующие реквизиты:

Код (тип данных Число, длина 9);

Наименование (тип данных Строка, длина 50);

ФИО (тип данных Строка, длина 50);

Адрес (тип данных Строка, длина 100);

Телефон (тип данных Строка, длина 20);

E_mail (тип данных Строка, длина 50).

На рисунке 7 отображена созданная структура данных справочника «Покупатели». Аналогично были созданы структуры данных справочников «Сотрудники», «Банки», «Поставщики», «Автомобили», «Файлы».

Рисунок 7. Структура данных справочника «Покупатели»

Формы элементов справочников в пользовательском режиме создаются автоматически, и для большинства справочников не требуется проектировать форму элемента [1]. Но в справочнике «Автомобили» содержится много данных и их надо сгруппировать для более удобного восприятия пользователями. На рисунке 8 отображена разработанная форма элемента.