Модификация конфигурации кассового программного обеспечения
2.4 ER-модель связей между объектами метаданных
ER-модель (сущность-связь) - модель построения данных, описывающая предметную область на концептуальном уровне. Эта модель позволяет проектировать БД, предварительно определив ключевые сущности и установив связи между ними. Затем происходит преобразование ER-модели в конкретную схему данных (реляционную, иерархическую, сетевую и т.д.). Для визуализации ER-модели используются различные нотации (Чена, Crows foot и т.д.). Стандартной графической нотацией ER-модели считается ER-диаграмма. По сути ER-диаграмма является высокоуровневым отражением какой-либо предметной области [17].
Процесс создания ER-диаграммы состоит из:
1) Определение сущностей;
2) Определение атрибутов сущностей;
3) Определение ключевых атрибутов сущности по которым будет идентифицирован каждый экземпляр сущности;
4) Установление связей между сущностями.
ER-диаграмма построения связей между объектами метаданных представлена на рисунке 2.7.
Рисунок 2.7 - ER-диаграмма сущность-связь
1) Анализ предметной области показал, что сертификаты могут быть различной природы, отчего будет зависеть их настройка и требования к функционалу. Поэтому целесообразно определить сущность "Виды сертификатов". Также следует определить сущность "Сертификаты", описывающая каждый конкретный сертификат и сущность "Товары для продажи сертификатов". Добавление сущности "Товары для продажи сертификатов" является обязательным, т.к. каждый конкретный сертификат должен быть связан с товаром.
2) Определим атрибуты всех сущностей.
Сущность "Виды сертификатов" должна обладать следующими атрибутами:
- код вида сертификата (уникальный идентификатор);
- префикс (префикс кода сущности виды сертификатов);
- наименование;
- код группы;
- максимальное число сертификатов в группе;
- максимальное число товаров в чеке по сертификату;
- номер вида оплаты;
- начало действия акции;
- срок действия акции;
- номинал.
Сущность "Сертификаты" должна обладать следующими атрибутами:
- код сертификата (уникальный идентификатор);
- префикс кода (уникальный идентификатор);
- наименование;
- владелец;
- остаток;
- дата начала;
- дата окончания;
- статус.
Сущность "Товары для продажи сертификатов" должна обладать следующими атрибутами:
- код товара (уникальный идентификатор);
- наименование;
- владелец;
- цена;
- префикс кода.
3) Определение ключевых атрибутов сущности.
Каждый экземпляр сущности "Виды сертификатов" будет однозначно определятся за счёт родительского ключа "Код вида", данный атрибут числовой и будет автоматически генерироваться системой.
Родительский ключ сущности "Сертификаты" будет составным. Состоять он будет из двух атрибутов - "Код сертификата" и "Префикс кода".
Каждый отдельный экземпляр сущности "Товары для продажи сертификатов" будет идентифицирован с помощью родительского ключа "Код товара".
4) Установление связей между сущностями.
Каждый вид сертификата может иметь в себе много сертификатов, при том, что каждый сертификат единовременно может относиться только к одному виду сертификата. Поэтому устанавливаем связь между этими сущностями один-ко-многим.
То же справедливо и для связи между сущностями виды сертификатов и товары для продажи сертификатов. Каждый вид сертификата может иметь много товаров для продажи сертификатов, в то время как, каждый товар для продажи сертификатов относится только к одному виду сертификата. Также устанавливаем связь один-ко-многим.
При построении логической модели следует определить типы хранимых данных и способы доступа к ним.
В языке "1С: Предприятие 8" существуют как примитивные типы данных (число, строка, дата, булево), так и ссылочные типы данных (справочник-ссылка, документ-ссылка и т.д.). Очень часто при организации доступа к данным используется объектный подход. В объектной модели разработчик оперирует объектами встроенного языка. В этой модели обращение к объекту, например, документу, происходит как к единому целому - он полностью загружается в память, вместе с вложенными таблицами, к которым можно обращаться средствами встроенного языка [2,3].
Каждый объект хранится в БД "1С: Предприятие", как совокупность данных, на который существует уникальная ссылка, позволяющая однозначно идентифицировать этот объект в БД. Эта ссылка хранится в поле БД, вместе с остальными данными об объекте [2].
Одним из главных требований к ПО кассира является быстродействие конфигурации для обработки большого числа транзакций. Для удовлетворения данного требования логично было бы использовать доступ к данным, основанный на ссылочной целостности, обеспечивающий быстрый доступ к данным. Но данный подход не может быть реализован.