2.7.2. Логическая модель потоков данных (лмпд)

Цель построения такой модели состоит в устранении дублирования в обработке и хранении данных, а также перегруппировке в соответствии с требованиями пользователей к низовым процессам функциональных областей. ЛМПД создается на базе МПД СС путем выполнения особых процедур.

2.7.2.1. Процедуры приведения мпд сс к логической мпд

Эти действия состоят в следующем:

• рационализация хранилищ данных;

• рационализация низовых процессов;

• перегруппировка низовых процессов;

• проверка ЛМПД на содержательность и полноту.

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

2.7.2.2. Рационализация хранилищ данных

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

Главные логические хранилища данных

Хранилища этого типа выделяются на ЛМД СС. Главные хранилища данных на ЛСПД должны отражать семантику данных для объектов ЛМД СС. Следовательно, вход в систему потока данных, содержащего, например, «НОМЕР СОБСТВЕННОСТИ», «НАИМЕНОВАНИЕ СОБСТВЕННОСТИ» и «ОСОБЕННОСТИ СОБСТВЕННОСТИ», подразумевает наличие в ЛМД объекта с такими атрибутами, отправляющего в хранилище данных то, что представляет собой результат обработки входа. Каждое главное хранилище данных должно соответствовать объекту или группе объектов на ЛСД.

Если группирование по объектам не очевидно, тогда рассматривают те объекты, которые:

• связаны между собой отношениями;

• созданы одновременно;

• выделены при анализе одних и тех же входов и выходов системы;

• могут быть описаны одним термином (например, бухгалтерия).

Возможно создание отдельного хранилища данных для каждого объекта в ЛМД, но лучше сохранить в СПД группирование данных на сокращенном уровне изложения, т.к. детальное определение данных содержится в ЛМПД.

Каждое главное хранилище данных должно ссылаться на объект или группу объектов ЛМД СС.

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

Связи между объектами и хранилищами данных документируются в «Таблице перекрёстных ссылок Логическое хранилище данных/Объект».

В хранилищах существующей системы, вероятно, будет большое количество дублируемых данных. Например, одинаковые данные находятся в «Папке главных нанимателей жилья», «Главной папке жилищной задолженности» и «Голубой папке нанимателей жилья». Такое дублирование устраняется при описании логических хранилищ данных в ЛМПД.

ЛСД для «Жилищной системы» показана на рис. 2.18. Здесь группирование выделено контурами. Для этих группирований, применяем следующие правила:

• D7: два объекта «Районная цена отопления» и «Расходы на отопление» связаны между собой отношениями, что вполне очевидно;

• D2: объекты «Наниматель жилья», «Члены семьи» и «Счет» созданы одновременно, при возникновении объекта «Местожительство»;

• D3: «Новое заявление» на жилье и «Заявление на передачу» попадают в список ожидающих сходными путями. Вероятно, они хранятся одинаковое время. Список ожидающих является главным выходом системы. Все объекты, которые включены в это хранилище данных, используются для составления и печати списка ожидающих;

• D5: эти объекты могут быть описаны основным термином «Местонахождение».

Перечисленные выше группирования регистрируются «Таблице перекрёстных ссылок. Хранилище данных/Объект» так, как показано в приложении 1. Рис. 2.19 иллюстрирует запись для D1.

Рис. 2.19. Пример записи в „Таблице перекрестных ссылок. Логическое хранилище данных/Объект”

Декомпозированные хранилища данных

Декомпозированные на СПД СС хранилища данных остаются и на ЛСПД, если они не были удалены при рационализации. Декомпозиция хранилища данных может привести к появлению новых величин в описании объекта. Но она также может показываться на главном объекте различными деталями со взаимоисключающими отношениями. В нашем примере было бы разумно иметь отдельные хранилища данных для "Новых заявлений" и "Заявлений на передачу", связанных между собой так, как это показано на рис. 2.20.

Рис. 2.18. определение логических хранилищ данных

Рис. 2.20. Декомпозиция хранилища данных на нижнем уровне

В этом примере для сохранения верхнего и нижнего уровней связи должны быть записаны в "Таблицу перекрёстных ссылок Логическое хранилище данных/Объект** (это исключение из правила, т.к. в этой таблице объекту должно соответствовать только одно главное хранилище данных).

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

Логические хранилища временных данных

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

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

Этот вывод не так ясен, как может показаться, потому что копии объектов могут храниться в хранилищах временных данных. Например, хранилище данных «Неподтвержденные платежи» будет содержать записи, которые имеют одинаковое содержание с главным хранилищем «Дебет-Кредит». Различие состоит в том, записи в хранилище временных данных «Неподтвержденные платежи» не сохраняя в главном (они хранятся во временном месте до тех пор, пока они не просуммированы с главными данными). Если получение и подтверждение платежей имеет место одновременно, то либо два процесса объединятся, либо поток данных будет иметь вид «процесс-процесс», без использования хранилища временных данных. Хранилище временных данных характеризуется тем, что каждое «чтение» из него действительно уничтожает в нём данные. Другими словами, входящий во временное хранилище поток может рассматриваться как удаляемый потоком, выходящим из хранилища. Из этого следует, что временные данные могут использоваться только один раз. Если требуется читать данные более одного раза то данные должны рассматриваться как главные, и должны быть связаны с объектами в ЛМД.

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

Данные, собранные во временном хранилище, не могут в нём храниться, результаты их обработки могут заноситься в главное хранилище.

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

Использование хранилищ временных данных в ЛМПД

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

Включение в схему хранилищ временных данных производится:

• если, например, есть задержка между поступлением данных и их последующим подтверждением, т.е. имеется риск, что главные данные 'устареют к моменту их обработки и запросы по состоянию частичного подсчета не покажут, что некоторые данные были получены, хотя по этому факту и не было получено подтверждение;

•если это вытекает из требований безопасности, надзора и контроля. Процедуры восстановления главных данных не охватывают промежуточные данные, т.е. они теряются при системном сбое, а по этому иногда могут потребоваться специальные средства для защиты некоторых промежуточных данных. Это является причиной возникающих проблем, т.к. запись неподтвержденных данных теряются, если была системная ошибка. Следовательно, спецификация требований защиты и восстановления для системы становится более полной, если временные хранилища представляются, как зашита промежуточных данных и рассматриваются в совокупности со средствами защиты главных данных;

•если при физическом проектировании необходимо модифицировать промежуточные файлы для выполнения в дальнейшем сравнения их содержимого с содержимым главных хранилищ данных, что может в дальнейшем существенно упростить получение проектных модификаций по главным данным;

•в инструментальной среде, у которой отсутствует контроль по индикаторам состояния, т.к. контроль изменения главных данных производится путем их сравнения с заданными в «Истории жизни объекта» значениями индикаторов состояния, а для промежуточных данных, такой точный контроль не используется;

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

Следует избегать использования хранилищ временных данных, если этого не требует реальная проектная ситуация.

Перекрестные ссылки между логическими и физическими хранилищами данных

После того, как новые главные логические хранилища данных идентифицированы, нужно связать их ссылками на физические хранилища данных в МПД СС, используя при этом рабочий документ «Таблица перекрестных ссылок Логические/Физические хранилища данных».

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