3.8.6. Более сложные ключи.

Для описания связей и объектов, изображенных на рис. 3.1, могут потребоваться более сложные иерархические ключи, например для того, чтобы идентифицировать объект "СОБСТВЕННОСТЬ". "СОБСТВЕННОСТЬ" здесь является вспомогательным объектом для объекта "УЛИЦА", который в свою очередь находится в таком же отношении к объекту "НАСЕЛЕННЫЙ ПУНКТ" и т.д. Для того, чтобы идентифицировать "СОБСТВЕННОСТЬ" уникальным образом, необходима комбинация кодов объектов "РЕГИОН", "ОКРУГ", "НАСЕЛЕННЫЙ ПУНКТ", "УЛИЦА" и "СОБСТВЕННОСТЬ". Коды первых четырех объектов являются атрибутами внешнего ключа, соответствующего первичному ключу объекта "СОБСТВЕННОСТЬ". Коды первых трех объектов - атрибутами внешнего ключа объекта "УЛИЦА" и т.д. вверх по иерархии.

Рис. 3.14. Пример составного ключа 'Заявление/Собственность'

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

Рассмотренный выше составной ключ может быть частью иерархического ключа и наоборот.

3.9. Использование метода в процессе проектирования

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

3.9.1. Выделение элементов ЛМД.

Существует много способов идентификации объектов, связей и атрибутов.

Перечислим основные из них:

• анализ форм документов, используемых в документопотоках анализируемой системы;

• анализ результатов открытых опросов и письменных источников, например, годовых отчетов;

• обследование;

• личные знания и суждения;

• структурированные опросы.

При разработке обобщенной ЛСД на этапе 110 в основном используются открытые и структурированные опросы. На этапах 140 и 320 используются различные комбинации всех пяти способов. При анализе форм полезно использовать реляционный анализ данных.

3.9.2.Идентификация объектов.

На этапах 110, 140 и 320 объекты идентифицируются в рамках метода логического моделирования данных. Та же задача решается, если это необходимо, и на этапах 340 и 360, но с использованием методов реляционного анализа данных и объектно-событийного (динамического) моделирования данных. Большинство трудностей возникает при решении задачи идентификации объектов путем опросов. Это обусловлено тем, что в процессе общения люди объясняются в терминах примеров и аналогий. Кроме того процесс осложняется использованием в речи синонимов и существованием в естественных языках омонимов. Поэтому аналитик обязан особое внимание уделить вопросам определения ролей элементов анализируемой системы, (в частности людей и организаций), выбрать названия объектов таким образом, чтобы они кратко и в то же время полно отражали сущность идентифицируемых объектов, а затем описать их в соответствии с требованиями используемого метода. Это помогает настроиться на мышление в терминах разрабатываемой системы обозначений для ключей, в окружении которых необходимо далее работать с предметной областью анализируемой системы.

Когда аналитик при анализе системы вводит новое "имя" или "ключ", то они должны быть понятиями, которые пользователь сможет четко отличить от других понятий похожего типа, т.е. объектов. Эти ключи должны идентифицировать группы данных, которые необходимо выделить в системе. Ключ, который существует в изоляции, не является точно объектом, но введение ключей, точно соответствующих объектам, может понадобиться на этапах 340 и 360 для уточнения требований к функционированию системы.

Объекты не должны идентифицироваться процессами. Наоборот необходимо тщательно определить имена объектов, чтобы с их помощью можно было хорошо описать процессы и внешние объекты на схемах потоков данных.