|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 22.01.03 | |
| СТАТЬЯ |
22.01.03
|
Зайцев С.Л., к.ф.-м.н.
Ключевыми являются атрибуты, значения которых определяют значения других атрибутов. Значения ключевых атрибутов не зависят от значений никаких других атрибутов. Ключ может состоять из единственного атрибута или быть составлен из нескольких атрибутов. Эти атрибуты могут быть первичными ключами, составными первичными ключами, кандидатами в ключи, внешними ключами или альтернативными ключами.
Является ли первичный ключ единственным атрибутом или группой, его значения определяют значения всех других атрибутов.
Хороший первичный ключ будет обладать следующими признаками:
Искусственные первичные ключи - это атрибуты, созданные с единственной целью идентификации конкретных экземпляров сущности. В некоторых случаях не существует атрибута или группы, однозначно идентифицирующих экземпляр сущности. В других случаях, составной первичный ключ слишком громоздок, и его трудно сопровождать. Искусственный первичный ключ иногда называют псевдоключом или ключом, сгенерированным системой. Еще он известен под названием искусственный уникальный идентификатор, которое указывает на его назначение.
Искусственный первичный ключ часто формируется простой последовательной нумерацией каждого из экземпляров сущности. Дополнительным преимуществом таких искусственных ключей является то, что не нужно заботиться о смысле связанных с ними экземпляров сущности, кроме гарантии уникальности. Фактически, искусственные первичные ключи, созданные таким способом, гарантированно обладают особенностями хороших первичных ключей.
Обратите внимание, что большинство первичных ключей на Рисунке 3.5 являются искусственными. По большей части, первичный ключ является просто уникальным номером для каждого из экземпляров.
Кандидатом в ключи является атрибут или группа атрибутов, идентифицирующих конкретный экземпляр сущности. Кандидат в ключи представляет механизм определения потенциальных первичных ключей для идентификации конкретных экземпляров сущности.
Кандидат в ключи, который не выбран в качестве первичного ключа, еще называют альтернативным ключом. Альтернативный ключ - это атрибут или группа атрибутов, которые могут быть использованы при индексировании.
Внешним ключом является атрибут или группа атрибутов, составляющих первичный ключ другой сущности. Внешний ключ может быть, а может и не быть, ключевым атрибутом в связанной сущности. Обратите внимание на термин связанная сущность. Внешние ключи представляют связи между сущностями, которые более детально будут обсуждаться в следующей статье.
Внешние ключевые атрибуты являются атрибутами первичного ключа другой сущности, которые мигрировали в данную сущность через связь. Внешние ключи могут быть как идентифицирующими, так и неидентифицирующими. Идентифицирующие внешние ключи становятся частью первичного ключа в той сущности, в которую они мигрировали. Неидентифицирующие внешние ключи становятся не ключевыми атрибутами.
Неключевыми являются атрибуты, значения которых зависят от значений первичного ключа или составного первичного ключа. Эти не ключевые атрибуты должны зависеть от значения ключа, полного ключа, и ни от чего кроме ключа.
В своей книге Strategic Systems Development К. Финклештейн определяет несколько типов неключевых атрибутов:
Селективные, групповые и атрибуты повторяющейся группы не должны присутствовать в логической модели, приведенной к третьей нормальной форме. Селективные атрибуты должны стать частью первичного ключа, если они нужны для идентификации единственного экземпляра сущности. Групповые атрибуты являются многозначными. По моему мнению, групповые атрибуты лучше всего представлять в модели кодовыми или классификационными сущностями. Как отмечалось выше, повторяющиеся группы должны быть вынесены в подчиненные сущности.
В третьей нормальной форме не ключевые атрибуты должны быть простыми (основными) или производными атрибутами.
Простые атрибуты - это атрибуты, которые в результате декомпозиции были доведены до наивысшей степени детализации и, таким образом, их значения полностью зависят от первичного ключа и определены для каждого из экземпляров сущности. Они не являются критерием выбора и не могут служить для группировки сущностей. Они представляют простые атомарные факты, в которых заинтересована корпорация.
Производными атрибутами являются атрибуты, значения которых выведены или вычислены на основе значений одного или более других атрибутов. Вопрос допустимости присутствия производных атрибутов в логической модели активно обсуждается. Некоторые эксперты считают, что поскольку значения производных атрибутов зависят от значений исходных атрибутов, производные атрибуты не должны быть представлены в логической модели.
Логическая модель предназначена для полного и точного представления требований к информации. Вы можете принять решение создать производные атрибуты на уровне физической модели в соответствие с требованиями к использованию.
Хотя понятны аргументы в пользу исключения производных атрибутов, тем не менее, логическая модель - наилучшее место для введения имен и описаний всех атрибутов. Поэтому предпочтительнее включать производные атрибуты в логическую модель. Однако, разработчикам моделей стоит отказаться от использования производных атрибутов в качестве первичных ключей или части составных первичных ключей. Также не забудьте включить правило вывода в описание производного атрибута.
Область определения атрибута задает список разрешенных значений, которые атрибут может принимать в конкретном экземпляре сущности. Область определения включает, по меньшей мере, область определения универсального типа данных и может включать область определения, заданную пользователем. В завершенной логической модели вы должны найти область определения для каждого из атрибутов.
Можно сказать, что область определения атрибута должна содержать, как минимум, два значения. Атрибут, для которого всегда разрешено только одно значение, вероятно, некорректно отображен в модели. На Рисунке 3.5 присутствует два таких атрибута - Банан и Помадка.
В сущности БАНАНОВЫЙ ДЕСЕРТ присутствует атрибут Банан. Бизнес-правило утверждает, что каждый экземпляр сущности БАНАНОВЫЙ ДЕСЕРТ содержит банан. Поэтому у атрибута Банан может быть только одно значение и, вероятно, этот атрибут не является необходимым. Вместо этого описание сущности БАНАНОВЫЙ ДЕСЕРТ должно быть указание на то, что банан включается в каждый ее экземпляр. То же самое касается атрибута Помадка в сущности СЛИВОЧНАЯ ПОМАДКА.
В Таблице 3.1 приведены области определения логических типов данных сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ логической модели СМЕСЬ.
ТАБЛИЦА 3.1. Примеры логических типов данных.
|
Имя атрибута
|
Логический тип данных
|
| Идентификатор специального предложения | Number (число) |
| Идентификатор мороженого | Number (число) |
| Идентификатор вкуса | Number (число) |
| Начало специального предложения | Date (дата) |
| Конец специального предложения | Date (дата) |
Область определения типа данных определяет способ представления значений атрибута. В завершенной логической модели область определения типа данных требуется для каждого атрибута. В следующем списке приведено несколько примеров логических типов данных ERwin:
Многие из новых платформ баз данных поддерживают более развитые типы данных. Однако важно помнить, что эти сложные типы данных, за некоторым исключением, зависят от платформы. В любом случае, если пользователю нужен атрибут, он должен быть включен в модель, вне зависимости от его типа данных. Некоторые широко используемые расширенные типы данных приведены ниже:
Области определения, вводимые пользователем - специализированные области определения, которые уточняют набор значений, допустимых для атрибута. Эти области определения часто специфичны для организации и должны определяться и использоваться единообразно в пределах корпорации. Например, атрибут с областью определения типа данных Number может, кроме того, иметь введенную пользователем область определения, которая ограничивает возможные значения пределами от 1 до 100. Принцип целостности дает корпорации возможность внести изменения в одной сущности расширить область определения для каждого из атрибутов, который ее использует.
Значение атрибута может быть обязательным или нет. Если значение требуется, или обязательно, значение должно присутствовать в момент создания экземпляра. Если значение необязательно, вы можете создавать экземпляры без него.
В книге Information Engineering: Strategic Systems Development К. Финклештейн определяет свойство обязательности атрибута через серию "правил редактирования":
Внимательно следите за необязательными атрибутами. Если атрибут или набор атрибутов имеет значение только для конкретных экземпляров сущности, рассмотрите возможность его переноса в сущность, где значение будет существовать для каждого из экземпляров.
В Таблице 3.2 указано свойство обязательности для атрибутов сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ. Обратите внимание на тот факт, что при создании экземпляра сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ значения требуются для всех атрибутов кроме атрибута Дата окончания специального предложения.
Таблица 3.2. Примеры обязательности атрибутов
| Имя атрибута | Обязательность |
| Идентификатор специального предложения | Требуется |
| Идентификатор мороженого | Требуется |
| Идентификатор вкуса | Требуется |
| Начало специального предложения | Требуется |
| Конец специального предложения | Необязательно |
В таблице 3.2 представлено бизнес-правило, которое говорит, что для экземпляра сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ требуется следующая информация:
Дата окончания для каждого экземпляра сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ необязательна. Бизнес-правило утверждает, что СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ должно иметь начало, но не обязательно должно иметь конец.
Атрибуты, значения которых обязательны, не могут иметь пустых значений. Некоторые эксперты считают, что значение должно быть обязательным для каждого экземпляра сущности. Естественно, в предположении, что значение каждого атрибута экземпляра сущности найдено или известно, до того, как экземпляр создается.
Атрибуты, чьи значения необязательны, могут иметь пустые значения. Некоторые эксперты считают, что атрибут не должен присутствовать в сущности, если его значение недоступно для каждого из ее экземпляров. Одной из причин является сложность интерпретации пустых значений. Означает ли пустое значение, что это значение неизвестно для экземпляра, или оно просто не было получено?
|
Каждый атрибут должен иметь ясное, точное и непротиворечивое имя. Имя атрибута не должно конфликтовать с его описанием. Имя атрибута должно указывать на значения, собираемые для экземпляров атрибута. Имя атрибута должно быть понятным и общепринятым в корпорации.
|
Вероятно, что у вас в корпорации есть набор соглашений об именовании атрибутов, разработанные в вашей корпорации или при формировании корпоративной модели данных, которыми вы руководствуетесь. Использование соглашений именования атрибутов гарантирует, что имена конструируются единообразно в рамках корпорации, вне зависимости от того, кто конструирует имя.
Соглашения об именовании атрибутов важны, вне зависимости от того, в маленькой или большой организации вы работаете. Однако, в большой организации с несколькими командами разработчиков и большим количеством пользователей, соглашения об именовании существенно помогают при взаимодействии и понимании элементарных данных. В идеале, вы должны разработать и сопровождать соглашения об именовании атрибутов централизованно и затем документально оформить и опубликовать их для всей корпорации.
Ниже представлены некоторые положения для формирования начального набора соглашений об именовании атрибутов, просто на случай, если в вашей организации пока такой набор не разработан:
Разработчикам моделей предпочтительно использовать хорошие соглашения именования, если таковые существуют, или разработать их, если таких соглашений нет.
Форма объект/модификатор/класс - широко распространенное в отрасли соглашение об именовании атрибутов. Это соглашение побуждает использовать имена атрибутов, состоящие из трех частей. Часть объект иногда называют субъектом или основным словом. В качестве объекта обычно используется имя сущности.
Модификатор может быть одиночным термом или группой термов. Хотя списка стандартных модификаторов не существует, разработчикам моделей желательно формировать короткие осмысленные модификаторы. Использование модификаторов позволяет вам создавать наглядные осмысленные имена атрибутов. Если имя становится неприемлемо тяжеловесным для пользователей или широкого применения, как требуется в корпорации, вы можете пойти на компромисс, отказавшись от трехсложных имен атрибутов.
Базовой частью имени атрибута является класс, который определяет тип информации, представляемой атрибутом. Некоторые часто используемые классы:
В рамках корпорации всегда лучше использовать единообразные имена атрибутов. В Таблице 3.3 приведены примеры хороших и плохих имен для атрибутов. Обратите внимание, что слова в имени атрибута отделены пробелами, начинаются с заглавных букв и используют строчные символы для остальных.
ТАБЛИЦА 3.3. Имена атрибутов с пояснениями
|
Хорошее Имя
|
Неудачное имя
|
Пояснение
|
| Person First Name (Имя персоны) |
Name (Имя) |
Name (Имя) - название класса и нуждается в обозначении объекта Person (персона) и в модификаторе First (первое). |
| Ice Cream Sales Quantity (Объем продаж мороженого) |
The Quantity of Sales (Объем продаж) |
Quantity (Количество) - название класса и должно быть на последнем месте (в английском варианте имени атрибута). "The" и "of" не привносят дополнительного смысла. |
| Item Cost Amount (Величина стоимости позиции) |
Cost of Item (Стоимость позиции) |
"of" не привносит дополнительного смысла. Название класса "Amount" (величина) указывает пользователю, что должно быть в атрибуте. |
| Product Identifier (Идентификатор продукта) |
Product Identifiers (Идентификаторы продуктов) |
"Identifiers" (Идентификаторы) - множественное число. Имя атрибута должно быть существительным в единственном числе. |
| Point of Sale Location Code (Код местоположения точки продаж) |
POS Code (Код POS) |
"POS" - аббревиатура. Использованное название класса "Code" (код) нуждается в модификаторе. |
| Person Birth Date (Дата рождения персоны) |
Birthday (День рождения) |
Birthday (День рождения) не содержит названия класса Date (Дата). Включение модификатора и имени объекта проясняет смысл имени атрибута. |
Описание атрибута должно быть коротким пояснением смысла атрибута, а не того, как он используется. Описание атрибута не должно противоречить его имени и не должно быть простым повторением имени. Используйте название класса и объекта в утверждении для точного описания данных. Если атрибут выводится или рассчитывается, включайте правила вывода или формулы расчета. Следующие правила касаются описания атрибутов:
Разработчикам моделей рекомендуется давать хорошие описания для каждого из атрибутов. Хорошие описания атрибутов делают легким использование модели для всех. Те, кто использует модель, созданную хорошим разработчиком, испытывают удовольствие от хорошо сформулированных в модели требований к информации. Сравните примеры из таблицы 3.4.
Таблица 3.4. Имена и описания атрибутов с пояснениями.
|
Имя атрибута |
Хорошее описание |
Неудачное описание |
Пояснение |
|
Person First Name (Имяперсоны) |
Имя персоны, которое позволяет корпорации общаться с персоной, используя дружеские обращения. |
Поле с длиной в 40 символов. |
Не используется язык бизнеса. Применены технические термины. |
|
Ice Cream Sales Quantity (Объем продаж мороженого) |
Количество мороженого конкретного сорта, проданного в рамках конкретного мероприятия по продаже. |
Объем продаж. |
Не добавляет нового смысла, а просто перефразирует имя атрибута в расплывчатых терминах. |
|
Item Cost Amount (Величина стоимости позиции) |
Величина стоимости конкретной позиции в конкретный период времени. Представляет суммарную стоимость продажи и доставки. |
Шестизначное десятичное число с двумя знаками после запятой. |
Слишком техническое описание. Почти ничего не значит для пользователей элемента данных. |
|
Product Identifier (Идентификатор продукта) |
Искусственный уникальный числовой идентификатор для конкретного продукта. |
Идентификаторы продуктов. |
Простая перефразировка имени атрибута. |
|
Point of Sale Location Code (Код местоположения точки продаж) |
Уникальный код, идентифицирующий географическое положение точки продаж. |
Код POS. |
Использованный акроним может быть непонятен пользователям. Кроме того, в описании опущен важный модификатор. |
|
Person Birth Date (Дата рождения персоны) |
Дата рождения персоны. |
День рождения персоны. |
В описании опущено название класса “дата”. |
Этот раздел, посвященный распространенным ошибкам при моделировании атрибутов, не претендует на полноту. Цель его - указать на наиболее распространенные ошибки, которые встречаются у разработчиков моделей.
Иногда, при моделировании чего-либо определенным способом, разработчик модели делает сознательный выбор, руководствуясь вполне правильными принципами. Очень важно понимать всю причинно-следственную цепочку принимаемых решений и результаты, к которым они могут привести.
Что понимается под моделированием в терминах значений? Во время рабочей сессии пользователи могут сказать вам, что им нужен набор атрибутов, указывающих на возрастные категории экземпляра сущности ПЕРСОНА. В этом сценарии возникают, по меньшей мере, три проблемы:
|
Многозначными являются атрибуты, имеющие несколько значений для концепции. Проверьте описания атрибутов, которые указывают на наличие нескольких значений для одной и той же концепции.
Иногда эксперты из различных предметных областей в корпорации используют имя атрибута, которое пишется и произносится одинаково, но имеет разные значения для разных экспертов. Один из способов убедиться в том, что атрибуты с одинаковыми именами описывают одинаковые объекты, заключается в проверке описаний. Убедитесь, что значения атрибутов описывают единственную концепцию.
Например, вы можете создать искусственные коды путем соединения одного или нескольких кодов для связи прежде не связанных данных. Текстовые фрагменты могут скрывать множество ценных атрибутов и значений.
Неудачное разрешение многозначных атрибутов может привести к тому, что некоторые важные бизнес-правила останутся необнаруженными и недокументированными.
Избыточными являются атрибуты с разными именами, но содержащие информацию о сходных концепциях. Во всех языках существует много слов, представляющих одни и те же вещи. Один из способов найти избыточные атрибуты - просмотреть сущности с похожими атрибутами. Сравните описания всех атрибутов для проверки того, не содержат ли эти сущности данные о сходных концепциях. Избыточные атрибуты часто являются результатом тенденции к моделированию значений в качестве атрибутов. Например, сущности УПРАВЛЕНЕЦ и ИСПОЛНИТЕЛЬ могут содержать атрибуты Имя менеджера и Имя исполнителя. Так как и УПРАВЛЕНЕЦ, и ИСПОЛНИТЕЛЬ являются ролями, в которых может выступать экземпляр сущности ПЕРСОНА, вы можете переместить туда этот атрибут и назвать его Имя ПЕРСОНЫ.
Неясные, неоднозначные или неточные имена атрибутов усложняют для новых пользователей и команд разработчиков повторное использование или развитие существующей модели.
Не используйте аббревиатур или акронимов в качестве части имени атрибута. Аббревиатуры и акронимы открыты для неправильной интерпретации и даже могут иметь разное значение в разных предметных областях.
Не используйте имена собственные, указывающие на значение для конкретного экземпляра. Имя атрибута, использующее имя собственное - индикатор серьезных проблем при моделировании, заключающихся не только в неудачном выборе имени. Не включайте месторасположение в качестве части имени атрибута. Если значение существует для одного месторасположения, оно определенно существует и для другого месторасположения. Имя атрибута с указанием расположения является признаком того, что вы моделируете конкретный экземпляр вместо класса.
Не используйте описаний атрибутов, заимствованных только из словаря. Описания из словаря не будут включать информацию, значимую для бизнеса, которая делает атрибут важным для корпорации. Не используйте простое перефразирование имени атрибута. Не используйте имени атрибута в его описании.
Неясное, неопределенное описание атрибута, или что еще хуже - его отсутствие, затрудняет повторное использование или развитие существующей модели. Пользователи не смогут проверить, что модель содержит все требования к информации. Это так же повышает вероятность использования в модели вместо атрибутов конкретных значений и многозначных атрибутов.
Концепции, которые кажутся очевидными для всех участников рабочих сессий, могут перестать быть столь очевидными с течением времени, когда перед новой командой разработчиков будет поставлена задача развить существующую модель.
Сущности представляют собой факты, информацию о которых корпорация заинтересована накапливать и сопровождать. Они составляют существо модели и в основном выявляются во время рабочих сессий. Полное и точное отражение атрибутов в модели требует тщательного анализа, гарантирующего, что атрибуты точно соответствуют требованиям к информации. Атрибут должен присутствовать в модели в единственном экземпляре и должен представлять единственную концепцию бизнеса. Для помещения атрибутов в соответствующие сущности должны использоваться правила нормализации.
Атрибуты могут быть ключевыми и неключевыми. Ключ может быть единственным атрибутом или группой атрибутов. Первичные ключи выбираются из кандидатов в ключи, которые уникально идентифицируют экземпляр сущности. Атрибуты первичного ключа мигрируют из исходной сущности, чтобы стать внешними ключами вторичных сущностей. Значения неключевых атрибутов должны функционально зависеть от значения первичного ключа.
Область определения задает набор значений атрибута. Логические области определения могут быть простыми типами данных, такими как числа или строки. Они так же могут быть сложными типами данных, определяемыми пользователем, которые приспособлены для удовлетворения специфических требований корпорации. Новые СУБД поддерживают расширенные типы данных, такие как изображения и звук.
Значения атрибута могут быть требуемыми или необязательными. Если значение требуемое, атрибут не может иметь пустых значений. Атрибут должен иметь имя и описание. При именовании атрибутов рекомендуется использовать стандарт именования в форме объект/ модификатор/ класс. Каждый атрибут должен включать хорошее описание, использующее терминологию бизнеса для определения сущности атрибута, а не того, как он будет использоваться.
Сущности и отношения служат для группировки связанных атрибутов. В последующих статьях будет рассказано о роли отношений в процессе моделирования и о свойствах и типах отношений, там же вы найдете некоторые советы, помогающие избежать распространенных ошибок при моделировании отношений.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Обсудить на форуме Computer Associates
| INTERFACE Ltd. |
| ||||