Алгоритм получения действующего значения реквизита

На входе идентификатор экземпляра основной сущности (сотрудника) и дата, на которую нужно получить действующее значение атрибута ФИО (например, 01.03). Необходимо сделать выборку с фильтром по внешнему ключу основной сущности и датам, меньшим даты на входе. Выборка должна быть упорядочена по убыванию и у нее должен быть взят лишь первый элемент

Select ФИО FROM ФИОсотрудника

WHERE id=… AND(dt<01.09)

ORDER BY dt DESC

LIMIT 1 offset 0

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

Семантически это решение может оказаться неверным. По нашему примеру, как минимум, мы укажем ФИО человеку на дату до его рождения.

Второе решение: на уровне логики системы(программной логики, бизнес-логики) определять для каждого экземпляра сущности «нулевую дату» и запрещать все операции с более ранними датами для этой сущности. В нашем примере для сотрудника нулевой датой будет дата приема на работу. Первая заполненное значение будет отнесено к этой дате. А любые операции с более ранней датой будут запрещены.

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

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

		Содержание счета Id Id_счета Id_товара Цена колво
	СЧЕТ Id_счета Dt Id_контрагента

∞∞

\\\\

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-06-27