Использование автоматических транзакций в компонентах бизнес-объектов

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

Примечание: Если компонент бизнес-объекта не содержит бизнес-логики, требующей голосования за транзакции, то компонент может вообще игнорировать контекст транзакции. Тогда не требуется наследовать пользовательский компонент бизнес-объекта от класса ServicedComponent; контекст транзакции по-прежнему существует, но компонент бизнес-объекта его игнорирует.

Можно выделить два основных способа реализации механизма транзакций: Функциональность сохраняет данные во временный буфер. При удачном окончании транзакции данные копируются в основное хранилище. Например таким образом работают транзакции Microsoft SQL Server. Минус такого способа заключается в том, что функциональности придется явно указывать на то, что она подчиняется какой-то транзакции. Так, в общем-то, и происходит в ADO.NET. Однако, у этого способа есть и один неоспоримый плюс — если в момент транзакции вынуть вилку из розетки, то транзакционное поведение не будет нарушено. Кроме того, данный способ оптимален по производительности, так как копировать придется только те данные, которые действительно были изменены (если конечно временный буфер не представляет собой журнал событий, а транзакция не длится пол дня);

• Данные предварительно копируются во временный буфер. Функциональность вносит изменения непосредственно в основное хранилище. При неудачном окончании транзакции данные из временного хранилища копируются в основное. Этот способ реализован в паттерне «Transaction», и имеет зеркальную противоположность по достоинствам и недостаткам с предыдущим способом. Кроме того, только этот способ может быть реализован прозрачно для пользователя в языке C++.Производными атрибутами являются атрибуты, значения которых выведены или вычислены на основе значений одного или более других атрибутов. Например, «возраст» может быть определен по «дате рождения» и текущей дате, установленной на компьютере.Вопрос допустимости присутствия производных атрибутов в логической модели активно обсуждается. Некоторые эксперты считают, что поскольку значения производных атрибутов зависят от значений исходных атрибутов, производные атрибуты не должны быть представлены в логической модели, т.к. она предназначена для полного и точного представления требований к информации. Решение создать производные атрибуты на уровне физической модели принимается разработчиком в соответствие с требованиями к использованию.Хотя понятны аргументы в пользу исключения производных атрибутов, тем не менее, логическая модель - наилучшее место для введения имен и описаний всех атрибутов. Поэтому предпочтительнее включать производные атрибуты в логическую модель. Однако разработчикам моделей стоит отказаться от использования производных атрибутов в качестве первичных ключей или части составных первичных ключей. Также в описание производного атрибута необходимо включать правило его вывода.

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

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

• издержки на выполнение вычислений значений производных атрибутов при каждом обращении к ним – плюсы.

29.	Удаление нежелательных элементов на этапе логического проектирования реляционных БД