Критические вопросы теории и практики систем - К. Эллис

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

Поэтому самое простое и, возможно, интуитивно очевидное правило "перевода", которое мы можем сформулировать, звучит следующим образом: "Если в интерпретационной модели данных существует идентифицированная когнитивная категория CI, то в дизайне хранилища данных будет существовать отношение RI вместе с некоторым атрибутом Rl-id, который выступает в качестве первичного ключа для этого отношения и однозначно идентифицирует отдельные кортежи этого отношения".

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

 

РАБОЧИЕ ОБЪЕДИНЕНИЯ

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

При переходе к проектированию хранилища необходимо учитывать временные факторы, фокусироваться на том, что уже произошло, а не на том, что может произойти, и делать записи о выполнении одной и той же рабочей группой множества различных заданий в течение определенного времени. Необходимость отношений, способных хранить исторические данные, удовлетворяется правилом: "Если в интерпретационной модели данных существуют две категории, CI и C2, и ассоциация действий, Ax, между C I и C2, то в проекте хранилища данных будут присутствовать: отношение RI, имеющее некоторый атрибут Rl-id, который выступает в качестве первичного ключа этого отношения; отношение R2, имеющее некоторый атрибут R2-id, который выступает в качестве первичного ключа этого отношения; и отношение R3, которое записывает событие выполнения действия Ax, причем первичным ключом R3 является конкатенация Rl-id, R2-id и даты/времени этого события".

Заметим, что в приведенном выше примере штамп даты/времени может быть излишним, но в других случаях он не нужен, и правила всегда должны учитывать наиболее общий случай. Избыточность может быть устранена при последующем уточнении схемы. Также следует отметить, что ассоциации действий не обязательно должны быть бинарными и могут включать более двух категорий; например, можно определить, что бригады рабочих выполняют спецификации заданий, используя материалы. Это можно сделать аналогично описанному выше, но в бинарном виде. Например, для ассоциации действий, включающей три категории, можно рассматривать ее как состоящую из двух отдельных бинарных ассоциаций, создав два дополнительных отношения, в каждом из которых ключ другой задействованной категории включен в качестве неключевого атрибута.

 

СПЕЦИАЛИЗИРОВАННЫЕ ОБЪЕДИНЕНИЯ

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

При интерпретационном анализе данных можно использовать ассоциации специализации для определения одной категории как специализированной подкатегории другой. Например, может показаться уместным провести различие между сотрудниками, работающими на постоянной основе, и сотрудниками, работающими по временным контрактам, несмотря на то, что оба типа сотрудников имеют, по большей части, схожие характеристики. Определено, что категории "ПОЛНЫЙ РАБОТНИК" и "РАБОТНИК ПО КОНТРАКТУ" являются подтипами категории "РАБОТНИК", при этом допускается более тонкое разграничение того, что каждый из них может делать или не делать по определению. Только работники, занятые полный рабочий день, могут делать пенсионные взносы.

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

Мы можем создавать отношения, соответствующие только подкатегориям или только суперкатегории. Для последнего варианта мы можем сформулировать правило, например: 'Если в интерпретационной модели данных идентифицированная когнитивная категория CI с ассоциацией специализации, такой, что когнитивная категория C2 является подтипом C I, то в проекте хранения данных будет существовать отношение R I вместе с некоторым атрибутом RI-id, который действует как первичный ключ для этого отношения, и RI должен иметь в качестве неключевого атрибута индикатор типа, причем "C2" является допустимым значением для этого индикатора типа". В соответствии с этим вариантом реляционный эквивалент рис. 2 будет иметь вид: EMPLOYE! {Employee-id, Employee-type, ~,_}.

В конкретных условиях это может быть вполне приемлемым преобразованием, но поскольку мы ничего не знаем о том, как будет использоваться схема в реальном мире, мы должны признать его неудовлетворительным. Она не содержит отношений, соответствующих подтипам, поэтому существование подтипов и их сущность скрыты в данных, а не явно выражены в структуре схемы. Мы можем зафиксировать, что конкретный сотрудник работает на полную ставку или по контракту, записав соответствующие значения в атрибут "тип сотрудника", но мы можем зафиксировать только текущий статус сотрудника; если сотрудник, работающий по контракту, станет работать на полную ставку, мы можем изменить индикатор типа, но при этом потеряем все записи о том, что он когда-либо работал по контракту. Если же для двух типов сотрудников необходимо записать различные факты, то мы будем вынуждены выделить место для их хранения в отношении 'employee', что может привести к появлению большого количества нулевых значений.

Вторая возможность заключается в следующем: "Если в интерпретационной модели данных существует идентифицированная когнитивная категория CI с ассоциацией специализации, такой, что когнитивная категория C2 является подтипом C I, то в проекте хранения данных будет присутствовать отношение R I вместе с некоторым атрибутом R l-id, который выступает в качестве первичного ключа для этого отношения, и отношение R2, имеющее в качестве первичного ключа ключ RI-id". Следуя этому правилу, реляционный эквивалент рис. 2 будет выглядеть следующим образом: EMPLOYEE {Employee-id, _, _ }, PERMANENHMPL.OYFE {Employee-id, _, -l, CONTRACT-EMPLOYE!- {Employee-id, _, _}

Это реляционное выражение иерархии обобщений (или отношений IS-A), рекомендуемое в стандартных текстах, таких как Kroenke (1992) или Batini et al (1992). Оно, безусловно, лучше, поскольку позволяет фиксировать различные факты о сотрудниках, работающих по контракту и на полную ставку, в отдельных отношениях, а общие