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

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

Содержание счета

Id

Id_счета

Id_товара

Цена

колво

СЧЕТ

Id_счета

Dt

Id_контрагента

∞∞

1

\\\\

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

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

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

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

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

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

Ограничения.

1)предметная область подразумевает наличие сущности «накладная». Можно сделать эту сущность хранимой в неявном виде. Это позволит убрать одно звено связи между содержимым накладной и счета и позволит нормализовать хранящиеся данные ограничениями внешних ключей. Однако. Такая неявная сущность сделает систему менее гибкой и затруднит её дальнейшую масштабируемость. Логичнее всего оставить структуру с явной формализацией сущностей, а для контроля целостности хранимых данных ввести 6 триггеров эквивалентных ограничениям внешнего ключа через транзитную сущность.

Триггер 1 – до вставки в таблицу содержимое накладной определить номер счета основания и узнать если в этом счете строка с отгружаемым товаром. Если нет – запретить вставку.

Триггер 2 – эквивалентен 1ому, но срабатывает до изменения строки таблицы «содержимое накладной»

Триггер 3 – до удаления строки «содержимое счета» проверить есть ли во всех накладных, связанных с этим счетом товаров из удаляемой строчки. И если есть, то запретить удаление.

Триггер 4 – эквивалентен 3ему, но срабатывает до изменения строки таблицы «содержимое счета»

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