andbaryКогда начинается "Потеря целостности" проявляется множество проблемЦелостность может иметь место только в замкнутой системе. В открытой системе, да еще и в такой, где "транзакция" може длиться месяцами, целостность в стиле DRI отчасти теряет смысл. Представьте, что ваш бизнес-процесс взаимодействует с бизнес-процессом поставщика. Вы сослались на какую-то номенклатуру поставщика в отправленной ему заявке, и ждете 1 месяц, пока ее проработают. А тем временем у поставщика данную номенклатуру взяли и удалили из номенклатурного справочника. Или вы полагаете, что они не имели права это делать, не согласовав свои действия со всеми потенциальными клиентами?
Отдельный вопрос - что делать, если в обработку попадает заявка, в которой содержатся позиции, отсутствующие в текущей версии номенклатурного справочника. Однако, этот вопрос решается более детальным прописыванием бизнес-процесса таким образом, чтобы все возможные "а что если..." были бы предусмотрены.

Никто не предлагает отказаться от DRI в той части, где она действительно нужна. Но DRI - это по большей части схема ограничений без прописывания понятной пользователю реакции на его действия. В "голом" виде DRI почти не используются (за исключением MS Access, в котором в структуре данных содержатся элекменты пользовательского интерфейса), они обязательно "оборачиваются" каким-то пользовательским интерфейсом в котором сидит обработчик ошибки нарушения DRI, который и говорит пользователю Марье Иванне на понятном русском языке "Уважаемая Марья Иванна, пока вы заполняли платежку 15 минут 42 секуны 18 миллисекунд, много воды утекло. Получаетеля "ЗАО "Рога и копыта" на которого вы сослались в справочнике контрагентов 14 минут назад, какой-то нехороший человек (трах-тибидох) удалил из этого самого справочника. Если вас сильно интересует фамилия этого нехорошего человека, рекомендую вам обратиться по внутреннему телефону 1234 к ИТ-специалисту Головинкину Ё.Ё., который лишь только один разбирается в тонкостях журнализации всех действий пользователей. Он заглянет в журнал всех действий, отфильтрует в нем записи по нужным критериям, и сообщит вам, по возможности, на этой неделе. А сейчас вы должны попытаться ввести информацию повторно. Извините пожалуйста за причиненные неудобства...". Так вот, этот "интерфейс" - это реализация самобытными средствами тех частей бизнес-прочесса, которые должны отвечать за логическую целостность. Их вполне можно реализовать в самих бизнес-прочессах. А можно довериться некоей СУБД (если так больше нравится). В общем, больше - не меньше. Я же не призываю взять и отказаться от логической целостности. Просто допускаю, что когда внимание технического спецалиста целиком и полностью сосредоточено только на одной элекментарной операции и данных, с нею связанных, у него будет меньше шансов сломать мозги, нежели чем когда он смотрит на схему DRI мелким шрифтом и величиной с летное поле. Опять же, смотря где какие нюансы. Если схема не очень большая и громоздкая, то почему же ею не воспользоваться?

ARIS - это НЕ стандарт, если говорить в жестком понимании этого слова. Это "самоделка" одной конкретной фирмы. Но настолько удачная и получившая настолько широкое распространение, что многими уже рассматривается почти как стандарт.

6sBЕсли не трудно, скажите в каком номере? Я сам найду.Пошарил сейчас на полке - не нашел. Видимо, дома лежит. Номер примерно начала 2005 года или конца 2004. Пошукаю дома опосля.

2 andbary. Еще кое-какие соображения по поводу ссылочной целостности.
Пока база данных конкретного предприятия располагалась преимущественно на одной площадке где компьютеры были объединены в локальную сеть, ограничения DRI были очень и очень ценными. Аккумуляция всей (или почти всей) информации в рамках одного сервера одной локальной сети позволяла организовать контроль логической целостности непосредственно на нем. Но когда предприятия стали разрастаться и расползаться по территориально разнесенным площадкам, натужные попытки обеспечить непротиворечивость данных, "размазанным" по большому количеству территориально разнесенных площадок в виде, например, резко снижающей надежность системы репликации непосредственно обновляемых подписчиков, использующей MS DTC, как-то уже не стала пользоваться широким успехом. Многие светлые головы (и даже не очень светлые, вроде моей :) ) едва ли не костьми легли в борьбе с конфликтами репликации, которые, собаки, ну никак не хотели подчиняться глобальным требованиям логической целостности.
Самые простые "эстонские парни", не желавшие ложиться костьми в мировой войне с ветряными мельницами, потребовали, чтобы весь мир работал с единой глобальной базой данных с использованием клиента толщиной в 1 микробит. :) Стали гонять по глобальной сети киношки про то, как выглядит экран мнимого пользователя, ЯКОБЫ сидящего в локальной сети, назвав эти величашие достижения человеческой мысли терминальными сервисами (а я бы их назвал "мешком на голову Дон Кихота", который используется, чтобы последний не сильно волновался, проезжая мимо ветряных мельниц). Нет, я ничего не имею против терминальных сервисов, ради бога. Только сдается мне, что все-таки единой всемирной базы данных, к которой подключено с помощью терминальных сервисов всё человечество, случиться не дано. И проехав спокойно мимо десятка мельниц, все-таки придется заметить, что следующий десяток таки слишком нахально машет конечностями. Или заключить с этими чертовыми мельницами перемирие и попытаться найти с ними общий язык. XML - попытка найти такой язык, ПМСМ.

Наверное, я торможу... :)
Если честно говорить, я не совсем понял, что сказал 6sB. Я полагаю, что "бизнес" - это более широкое понятие, чем "бизнес-процесс". Поэтому при переходе от "реинжиниринга бизнеса" к "реинжинирингу бизнес-процессов" (я сейчас не обсуждаю вопрос, имел ли он вообще место) происходит не повышение, а понижение уровня абстракции. Толи это оговорка, толи не оговорка, а какая-то глубокая мысль, сути которой я пока не понял. Но приложу все усилия, чтобы понять... :)