Таблицы соответствия

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

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

Пример: построить сравнительные графики показывающие динамику нагрузки преподавателя и динамику его з/п. В этом случае, запрос на выборку средней нагрузки преподавателя в секции where будет содержать условие lector_id = $id. А запрос к бухгалтерской базе будет содержать id in($id[0]…$id[n]).

13. Сущность с накоплением, паттерн «Промежуточные итоги».

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

Что бы ввести начальный остаток, нужно провести операцию по товару на дату начала учета, при этом в кол-во записать кол-во товаров по инвентаризации, а в сумму вычисленную среднюю сумму по складу.

Чтобы посчитать какой-то момент в будущем, остаток товаров на складе, необходимо построить запрос с агрегатом sum() по колонкам q_op и sum_op с группировкой по колонке id_good.

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

Для решения вводиться сущность – промежуточные итоги. По структуре она дублирует сущность с накоплением, но хранит не сведенья об операциях а остаток по объектам учета на границах операционных периодах.

Например: завершив квартал один раз проводится расчет остатков товаров на конец квартала, эти остатки вносятся в промежуточные итоги и в следующем квартале при расчете остатков делается агрегация лишь по датам текущего квартала и складывается с остатками на начало квартала.

Замечание: 1) промежуточные итоги требует дополнение к логике функционирования системы. Необходимо запретить ввод операций с датой более ранней, чем последнее. Либо, после ввода пересчитывать промеж итоги.

2) Временная метка, потому что операции введенные одной датой могут отличаться по времени введения, т.е. нужно соотносить операции с формированием промежуточных итогов с точностью до секунды.

14. Паттерн «Периодические реквизиты».

На практике часто встречается изменение значения атрибута относительно времени, предметная область предполагает при формировании выборки за период после изменения значения атрибута с новым его значением, а при формировании выборки за период до изменения значения атрибута результат с прежним значением.

Например: сотрудницей заключаются дополнительные соглашение по договору, в котором указываются её ФИО. В какой то момент, в результате замужества, она меняет фамилию, при этом при выводе доп. соглашения на период до замужества необходимо указывать девичью фамилию, а на период после – новую.

15. Паттерн «Документ с табличной частью».

На практике часто приходится хранить документы, имеющие заголовочную и табличную части, например счет. Документ может иметь несколько табличных частей. Каждая табличная часть документа определяет неявную сущность. Эта сущность хранит все строчки всех табличных частей документа. Рассмотрим на примере счета:

	СЧЕТ   Id_счета Dt Id_контрагента

∞∞

ПРИМЕР. Менеджер по продажам и отгрузкам.

Требуется спроектировать БД для автоматизированной системы предприятия, занимающиеся оптовой торговлей. На предприятии имеются со следующими ролями(подлежит автоматизации):

1. Менеджер по продажам – взаимодействует с клиентами, выписывает счета на поставку, контролирует оплату этих счетов. В случае частичной или полной оплаты счеты передает счет на отгрузку со склада.

2. Кладовщик – получив счет с отметкой степени оплаты, осуществляет отгрузку товаров со склада не более, чем на сумму приплат по счету.

3. Менеджер контролер – проверяющий оплаты отгрузки по счетам, формирующий отчет «взаиморасчеты с контрагентами». Отслеживающий отгрузки со склада по партиям. Т.е. следящий, чтобы одно и тоже наименование товара закупленное по различной цене было отгружено по закупочной цене. Отслеживает оплату на расчетный счет по выставленным счетам.

Фирма хочет сделать более эффективным труд менеджера по продажам и контролера и за счет их разгрузки сократить часть кладовщиков и всех менеджеров контролеров. Обязанности менеджера контролера автоматизировать и переложить на менеджера по продажам.

16. Пример проектирования БД: декомпозиция сущностей, циклы на ER-диаграммах.

Для демонстрации декомпозиции сущности на категории используются диаграммы категоризации. Такая диаграмма содержит общую сущность, две и более сущности-категории и специальный узел-дискриминатор, который описывает способы декомпозиции сущностей (см. рис).

17. Пример проектирования БД: функциональная декомпозиция.

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