Наиме-нование атрибута | Описание атрибута | Базовый ли атрибутФормула для вычислимого атрибута | |
Name | Наименование товара | Да | |
N | Количество | Да | |
P1 | Учетная цена товара | Да | |
S1 | Учетная сумма на все количество | S1 = N*P1 | |
PerSent | Процент наценки на единицу товара | Да | |
P2 | Наценка на единицу товара | P2 = P1*PerSent/100 | |
S2 | Сумму наценки на все количество | S2 = N*P2 | |
P3 | Цену товара с учетом наценки | P3 = P1+P2 | |
S3 | Сумму на все количество с учетом наценки | S3 = N*P3 | |
NDS | Процент НДС | Да | |
P4 | Сумма НДС на единицу товара | P4 = P2*NDS/100 | |
S4 | Сумма НДС на все количество | S4 = N*P4 | |
P5 | Цена товара с НДС | P5 = P3+P4 | |
S5 | Сумма на все количество с НДС | S5 = N*P5 |
Таблица 3 Атрибуты товара
Базовыми, т.е. требующими ввода данных являются всего 5 атрибутов (выделены серым цветом). Все остальные атрибуты вычисляются по базовым. Нужно ли хранить в отношении только базовые атрибуты, или желательно хранить все атрибуты, пересчитывая значения вычислимых атрибутов каждый раз при изменении базовых?
Решение 1. Пусть в отношении решено хранить только базовые атрибуты.
Достоинства решения:
Недостатки решения:
Решение 2. Предположим, что в отношении решено хранить все атрибуты, в том числе и вычислимые.
Достоинства решения:
Недостатки решения:
Как видим, оба решения имеют свои достоинства и недостатки. Важно то, что программный код, содержащий эти формулы, не исчезает ни в каком из этих решений (да и куда он денется, раз такова предметная область!). Только в одном случае код хранится в одном месте, а в другом может быть "размазан" по всему приложению.
На самом деле данный пример сильно упрощен, т.к. еще одной неприятной особенностью наших бухгалтерий является то, что все расчеты должны вестись с определенной точностью, а именно - до копеек. Возникает проблема округления, а это еще более усложняет формулы для расчетов цен. Простой пример - вычисление НДС содержит операцию деления, следовательно может приводить к бесконечным дробям типа 15,519999- Такую дробь необходимо округлить до 15.52. Если продается одна единица товара, то это не страшно, но если продается несколько единиц товара, то сумму НДС на все количество можно считать по разным формулам:
Лирическое отступление. Автор, как математик по образованию (к.ф.-м.н.), считает, что верной, безусловно, является первая формула. Действительно, вычисляя по первой формуле, мы получим одну и ту же сумму НДС независимо от того, продали мы одну партию товара, содержащую 50 единиц, или продали 50 партий по одной единице в каждой. При вычислениях по второй формуле сумма НДС в партии, состоящий из 50 единиц товара отличается от суммы НДС по 50 партиям по одной единице товара в каждой. Разработав несколько складских программ, автор получал разные ответы на этот вопрос в разных бухгалтерия, разные ответы на этот вопрос в одной бухгалтерии в разное время, и разные ответы на этот вопрос в разных налоговых инспекциях. В конечном итоге, автор пришел к грустному выводу, что для того, чтобы стать бухгалтером, его способностей и образования недостаточно.
Другие решения. Можно попытаться использовать и другие решения, для облегчения разработки и сопровождения в данном случае. Например, можно хранить в базовом отношении только базовые атрибуты, а для работы бухгалтерии использовать заранее подготовленные представления (динамические отношения, задаваемые оператором SQL). Тогда логика расчетов будет храниться в одном SQL-операторе, определяющем это представление. Другим вариантом может быть сохранение формул в виде хранимых процедур и функций базы данных.
Проверка ограничения. К моменту проверки ограничения кортежа должны быть проверены ограничения целостности атрибутов, входящих в этот кортеж.
Ограничение кортежа является немедленно проверяемым ограничением. Действительно, ограничение кортежа не зависит ни от каких других объектов базы данных, кроме атрибутов, входящих в состав кортежа. Поэтому никакие изменения в других объектах не могут повлиять на истинность ограничения.