Технологическая часть. 
Проектирование информационной системы по работе с клиентами на предприятии

Разработка структуры БД

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

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

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

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

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

Каждый объект в конкретный момент времени характеризуется определенным состоянием. Это состояние описывается с помощью ограниченного набора свойств и связей (отношений) с другими объектами.

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

Модель типа «сущность — связь» (entity-relationship model) — это неформальная модель предметной области, которая используется на этапе инфологического проектирования базы данных. Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Относительная простота, применение естественного языка и легкость понимания позволяют использовать модель как инструмент для общения с будущими пользователями для сбора информации о предметной области для проектирования базы данных.

Основное назначение неформальной модели «сущность — связь» — семантическое описание предметной области и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в системе.

Существует несколько подходов к построению моделей типа «сущность — связь». Общим для всех подходов является использование трех основных конструктивных элементов для представления составляющих ПО — сущность, атрибут и связь.

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

Тип сущности определяет набор однородных объектов, а экземпляр сущности — конкретный объект в наборе. Каждый рассматриваемый в модели тип сущности должен быть поименован.

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

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

Эта модель основывается на некоторой важной семантической информации о реальном мире. Вводится специальный диаграммный метод (ER — диаграммы) как средство проектирования баз данных. ER-диаграмма разрабатываемой информационной системы представлена на рисунке 2.1.

Рис. 2.1 «ER-диаграмма информационной системы».

При планировании информационной системы «VP_Office» и определении состава входной информации была разработана структура базы данных. В базе данных содержится четырнадцать таблиц. В каждой таблице хранится информация об одном конкретном типе сущности:

• — в таблице COUPONS хранятся данные о каждом талоне, такие как его номер; идентификатор его статуса; идентификатор вида топлива и его номинала; идентификатор склада, которому он принадлежит; идентификатор АЗС, на которой талон реализован; идентификатор служащего, который произвел операцию.
• — в таблице CUSTOMER хранятся данные о каждом клиенте, такие, как название компании, ИНН, адреса и телефоны, идентификатор типа обслуживания, размер возможного кредита.
• — в таблице SERVICE хранится информация о типе работы с клиентом (работа в кредит или по предоплате).
• — в таблице STATUS хранится информация о возможных статусах талонов (не выдан/выдан/погашен/в стоп-листе).
• — в таблице SKLAD хранится информация обо всех складах ЗАО «ННВП», на которых могут храниться талоны.
• — в таблице GAS_COUPON хранится информация о типах талонов, т. е. о том, к какому типу бензина он относится и какой у него номинал (бензин А-76, Аи-92, Аи-95 по 20 литров и дизельное топливо по 40 литров).
• — в таблице AZS хранится информация о всех АЗС ЗАО «ННВП».
• — в таблице CARD хранятся данные о топливных картах: номер карты, идентификатор покупателя, которому она принадлежит, идентификатор текущего состояния карты.
• — в таблице GAS_CARD хранятся данные о типах топлива, находящихся на карте, и количестве литров каждого типа, идентификатор типа лимита и его величина.
• — в таблице CARD_PROPERTY хранится информация о текущем состоянии карты (выдана, изъята или карта находится в стоп-листе).
• — в таблице GAS_TYPE хранится информация о типах топлива (бензин А-76, Аи-92, Аи-95 и дизельное топливо).
• — в таблице TYPE_LIMIT хранится информация о типе лимита, установленном на карте (сутки, неделя, месяц).
• — таблица EVENT — журнал событий, содержит информацию о типе события, дате, типе топлива, его количестве (приобретенного, реализованного или возвращенного), цене за литр.
• — в таблице EVENT_TYPE хранится информация о всевозможных типах событий. Схема данных представлена на рисунке 2.2.

Рис. 2.2 «Схема данных»

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

• 1) Блок, отвечающий за работу с клиентами по талонам на бензин.
• 2) Блок, отвечающий за работу с клиентами по топливным картам.

Первый функциональный блок представлен на рисунке 2.3.

Рис. 2.3 «Блок, отвечающий за работу с клиентами по талонам на бензин»

Второй блок представлен на рисунке 2.4.

Рис. 2.4 «Блок, отвечающий за работу с клиентами по топливным картам»

Рассмотрим каждую таблицу подробнее:

Таблица 2.1 — COUPONS.

Таблица 2.2 — STATUS.

Таблица 2.3 — GAS_COUPON.

Таблица 2.4 — SKLAD

Таблица 2.5 — AZS.

Таблица 2.7 — CUSTOMERS.

Таблица 2.8 — CARD.

Таблица 2.9 — CARD_PROPERTY.

Таблица 2.10 — GAS_CARD.

Таблица 2.11 — TYPE_LIMIT.

Таблица 2.12 — GAS_TYPE.

Таблица 2.13 — SERVICE.

Таблица 2.14 — EVENT.

Таблица 2.15 — EVENT_TYPE