Следует отметить, что это решение неэффективно, если необходимо осуществлять совместную обработку всех счетов (физических и юридическргх лиц).

Какое решение выбрагпь?

Итак, к какому же выводу относительно дуг мы пришли? Да фактически пока ни к какому. Мы рассмотрели несколько вариантов решения проблемы дуги, но какой из них лучший? На этот вопрос нельзя ответить, пользуясь только моделью данных. Для получения полной картины мы должны рассмотреть определения всех функций, которые будут использовать (и даже сопровождать) эти данные. Наша рекомендация в этом случае - проектируйте в пользу критичных или оперативных функций бизнеса. Если этот подход не позволяет полугить явно предпочтительный вариант, то примите решение простым большинством и зафиксируйте его как таковое. Если каждой функции присвоен вес, то для получения решения можно воспользоваться математической формулой. Это, по крайней мере, позволит избежать субъективности и влияния персональных гфедпочтений. Например, в распоряжении Ноя был только один ковчег (насколько мы знаем)!

Жизненные циклы сущностей и диаграммы потока данных

Описывая в главе 1, какие результаты анализа передаются на этап проектирования, мы отметили, что диаграммы жизненных циклов сущностей и диаграммы потока данных не являются обязательными. Это, конечно, так, однако эти диаграммы могут оказать большую помощь проектировщику. Как же они связаны с результатами, которые мы уже рассмотрели?

Диаграммы сущность-отношения и определения сущностей описывают данные.

Иерархии функций и их описания описывают процессы.

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

Жизненные циклы сущностей

Диаграммы жизненных циклов сущностей (ЖЦС) относятся к классу диаграмм, известных как диаграммы изменения состояний (ДИС). Их основная задача - иллюстрировать жизненный цикл сущности по мере перехода ее из исходного состояния в состояние покоя .

Жизненные циклы сущностей делают анализ более основательным и позволяют лучше понять смысл сущности. Если жизненные циклы входят в перечень результатов вашего проекта, обязательно укажите отдельный цикл Для каждой из основных сущностей в системе. Может существовать цикл для

каждой кардинальной сущности в модели. Как вы помните, кардинальная сущность - это сущность, которая представляет реальную вещь (в отличие от сущности, которая вводится для разрещения отношения многие ко многим ). Конечно, не всякая сущность в системе будет подвержена изменению состояния, выходящему за рамки двух неявных состояний создана и удалена (иногда с дополнительным состоянием сдана в архив ). Тем не менее, если у сущности есть атрибут с названием статус или что-то вроде того, то для нее должен быть указан жизненный цикл - в форме диаграммы или текста.

Существует множество способов представления диаграмм такого типа. На рис. 3.29 приведена позаимствованная у Джеймса Марта* диаграмма- изгородь , которая отражает жизненный цикл сущности Order ( Заказ ) в упрощенной системе ввода заказов (Order Entry System).

Размещен Проверен Подтвержден

Ш Отклонен Ожидает доставки Доставлен Возвращен

Отменен Сдан в архив

Рис. 3.29. Жизненный цикл заказа

Стрелки на диаграмме показывают допустимые изменения состояний. Например, заказ может переходить из состояния проверен в состояние подтвержден или из состояния проверен в состояние отклонен , но не может переходить из состояния проверен непосредственно в состояние доставлен .

Символ рядом со статусом отклонен обозначает состояние, которое может быть разложено на статусы, например, отклонен из-за низкой кредитоспособности , отклонен из-за отсутствия на складе и т.д.

Однако из этой диаграммы не видно, какие состояния являются допустимыми начальными точками в жизненном цикле заказа, а какие - допустимыми конечными состояниями. В рассматриваемом здесь примере состояние в верхней части диаграммы - единственное допустимое исходное

Marth, James and James Odell, Object-Oriented Analysis and Design, Prentice-Hall, 1992.

состояние заказа ( размещен ), а в нижней части - единственное допустимое конечное состояние ( сдан в архив ). Тем не менее, многие аналитики не учитывают архивацию, потому что это - процесс физ№1еский, системного типа. Если состояние сдан в архив удалить, то мы получим четыре возможных конечных состояния ( отклонен , доставлен , возвращен и отменен ).

Что же делать с диаграммами жизненных циклов сущностей проектировщикам (кроме того, что восхищаться тем, как красиво они смотрятся)? Больщей частью их работа связана с атрибутом, который есть у большинства сущностей и называется STATUS ( Статус ) или что-то вроде того. При реализации этого атрибута в виде столбца таблицы требуется ввести три правила:

1. Ограничение для столбца должно быть задано так, чтобы он содержал лишь значения, указанные как допустимые статусы.

2. Исходное значение столбца в новой строке должно быть допустимым исходным значением.

3. При обновлении столбца необходимо обеспечить допустимое изменение состояния.

Первое правило обычно лучше всего реализуется в виде ограничения CHECK на столбце STATUS. Второе правило обычно вводится при помощи запускающегося перед вставкой триггера уровня строки на таблице. Можно также присвоить этому столбцу значение по умолчанию, особенно если для строки существует только одно допустимое исходное состояние. Благодаря этому все приложения, создающие новые элементы этой таблицы, могут не обращать внимания на статус.

Третье правило обычно принимает вид запускающегося перед обновлением триггера уровня строки, который проверяет :old.STA TUS и :new.STA TUS на предмет допустимости сочетания. Допустимые сочетания могут быть жестко закодированы в триггере (или, что более вероятно, описаны в процедуре, вызываемой этим триггером). Лучший вариант - программно закодировать их в таблице. Если они хранятся в таблице, то можно (по соображениям производительности) рассмотреть возможность кэширования их в PL/SQL-таблице, объявленной как глобальная переменная пакета. Однако похоже, что в текущих промышленных редакциях Oracle? при таком подходе слишком интенсивно потребляются ресурсы. Как обычно, самый лучший выход - инкапсуляция. Мы пишем триггер для вызова процедуры пакета, а затем проверяем, какой метод является самым быстрым для этих данных, этой платформы и этих версий ПО. Если когда-нибудь потребуется изменить тактику, то достаточно будет изменить только эту процедуру. Ведь код триггера не знает о том, какой механизм используется для выдачи результата.

Чтобы проиллюстрировать сказанное, рассмотрим еще один пример, причем с другими условными обозначениями. На рис. 3.30 показан жизненный цикл чека, выданного вашим банком.

гпппп я \inf)i4iii>owiHue дант,1.\- 111