Модификация конфигурации кассового программного обеспечения

дипломная работа

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].

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

Делись добром ;)