|
запросов по мере необходимости. Так, собственно, требует реляционная теория, стремящаяся свести избыточность к минимуму. В практике, однако, дело обстоит сложнее. Например, каждая строка реальной накладной может содержать следующие данные о товаре (см. таблицу 3). Таблица 7 Атрибуты товара. Наиме-нование атрибута Описание атрибута Базовый ли атрибут Формула для вычислимого атрибута Name Наименование товара Да N Количество Да Pl Учетная цена товара Да SI Учетная сумма на все количество S1 =ЖР1 PerSent Процент наценки на единицу ' товара Да P2 Наценка на единицу товара P2 = Pl*PerSent/100 S2 Сумму наценки па все количество S2 = N*P2 P3 Цену товара с учетом наценки РЗ = Р1+Р2 S3 Сумму на все количество с учетом наценки S3=N*P3 NDS Процент НДС Да P4 Сумма НДС на единицу товара P4 = P2*NDS/100 S4 Сумма НДС на все количество S4 = N*P4 P5 Цена товара с НДС P5 = P3+P4 S5 Сумма на все количество с НДС S5=N*P5 Базовыми, т.е. требующими вЗвезда данных являются всего 5 атрибутов. Все остальные атрибуты вычисляются по базовым. Нужно ли хранить в отношении только базовые атрибуты, или желательно хранить все атрибуты, пересчитывая значения вычислимых атрибутов каждый раз при изменении базовых? Решение 1. Пусть в отношении решено хранить только базовые атрибуты. Достоинства решения: • структура отношения полностью неизбыточна; 22 |
Пример 6. Атрибут "Возраст сотрудника" в таблице "Спецподразделение", может иметь дополнительное ограничение "Возраст сотрудника не менее 25 и не более 45", помимо того, что этот атрибут уже имеет ограничение, определяемое доменом "Возраст сотрудника не менее 18 и не более 65". Приведенное ограничение кортежа, по сути, является дополнительным ограничением на значения одного атрибута. В этом случае допустимы два решения. Можно объявить новый домен "Возраст сотрудника спецподразделения" и тогда ограничение кортежа становится ограничением домена и атрибута, либо рассматривать это ограничение именно как ограничение кортежа. Оба решения имеют свои положительные и отрицательные стороны. Замечание. Тут имеются некоторые возможности для оптимизации. Формально, при изменении значения данного атрибута необходимо проверить два ограничения ограничение атрибута и ограничение кортежа. Но в данном случае ограничение кортежа сильнее ограничения атрибута и достаточно проверить только ограничение кортежа. Разумно построенная СУБД могла бы выявлять такие случаи и уменьшать лишнюю работу. Пример 7. Для отношения "Сотрудники" можно сформулировать следующее ограничение: если атрибут "Должность" принимает значение "Директор", то атрибут "Зарплата" содержит значение не менее 1000$. Это ограничение связывает два атрибута одного кортежа. Пример 8. В накладной можно установить следующую взаимосвязь атрибутов "Цена*Количество=Сумма", связывающую атрибуты "Цена", "Количество", "Сумма". Данный пример кажется неестественным, т.к. сумма является явно избыточным атрибутом, значение которого просто выводятся из значений других атрибутов. Поэтому кажется, что лучше хранить только два базовых атрибута "Цена" и "Количество", а сумму вычислять во время выполнения запросов по мере необходимости. Так, собственно, требует реляционная теория, стремящаяся свести избыточность к минимуму. В практике, однако, дело обстоит сложнее. Например, каждая строка реальной накладной может содержать следующие данные о товаре: Наиме-нование атрибута Описание атрибута Базовый ли атрибут Формула для вычислимого атрибута 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. Предположим, что в отношении решено хранить все атрибуты, в том числе и вычислимые. Достоинства решения: Код, поддерживающий целостность кортежа (и содержащий формулы для вычислимых атрибутов), хранится в одном месте, например в триггере, связанном с данным отношением. При изменении логики вычислений, изменения в формулы требуется внести только в одном месте (в триггере). Запросы к базе данных содержат меньше формул и поэтому более просты. Легче формулировать нерегламентированные запросы, т.к. в запросе используются атрибуты, имеющие для бухгалтера конкретный смысл. Недостатки решения: |