Выбор ключевых атрибутов

Задача выбора ключевых атрибутов встает перед разра­ботчиком в том случае, когда моделируемая сущность име­ет несколько идентификаторов. Лишь один из них может быть назначен в качестве первичного ключа¹. В основу вы­бора могут быть положены следующие принципы:

• простой ключ удобнее составного. Например, для сущ­ности «Студент» в качестве первичного ключа удобнее ис­пользовать атрибут «код», чем совокупность атрибутов «спец», «группа», «нпп» (см. рис. 1.5);

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

•ключи, значения которых формируются в базе дан­ных («номер по порядку» и т.п.), более удобны для кон­троля и управления чем те, у которых значения поступают извне («паспорт» и т. п.)²

• ключи, значения которых, помимо своей уникально­сти, несут некоторый смысл для пользователя, более удоб­ны для него, чем бессмысленный набор цифр или букв. Ключ «Сидоров» во многих ситуациях, по-видимому, боль­ше говорит пользователю, чем номер «015225»³.

Искусственное придание уникальности атрибуту ино­гда используется, чтобы сформировать ключ, удобный для пользователя. Например, используя фамилию сотрудника в качестве ключа, можно искусственно дополнять ее в слу­чае наличия однофамильцев: «Иванов-второй», «Петров-4» и т. п.

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

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

² Использование суррогатных ключей (см. сноску на с. 29) является крайним случаем применения этого принципа. Следует отметить, что такой подход, если его использовать на концептуальном уровне, ведет к появлению атрибутов, не обусловленных информационными потребно­стями пользователей. Многие авторитеты в области баз данных вообще не приветствуют идею суррогатных ключей.

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

Конструирование агрегатов

Группирование атрибутов в агрегаты — еще один вид проектных решений, возлагаемых на разработчика базы данных. Синтаксис модели допускает произвольное объ­единение в агрегат атрибутов и других агрегатов, находя­щихся на одном уровне иерархии. Разработчик может ис­пользовать эту возможность для повышения понятности или выразительности модели.

Соответствие агрега­тов классам объектов моделируемой предмет­ной области или их вза­имодействию — важный принцип, которым сле­дует руководствоваться при конструировании аг­регатов. Иными словами, нужно стремиться к тому, чтобы каждому агрегату модели в моделируемой предметной области со­ответствовал некоторый достаточно четко опреде­ленный для пользователя класс предметов, явлений, событий и т. п.

Пример. Во всех примерах, рассмотренных выше, мы старались сле­довать этому принципу. На (рис. 1.16) представлен расширенный при­мер, иллюстрирующий соответствие агрегатов и классов объектов пред­метной области. Слева на рисунке изображены классы объектов пред­метной области: «Студент», «Паспорт», «Телефон», «Предмет», изу­чаемый студентом. «Преподаватель», преподающий предмет, «Сдача» (зачета или экзамена), а справа — соответствующие агрегаты в виде ие­рархической модели.

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

¹ И это еще не все!» Введите агрегат, сделайте его необязательным, а входящие в него атрибуты — обязательными и вы будете контролиро­вать одновременность присутствия или отсутствия значений всех атри­бутов в экземпляре агрегата! Bay!

'При обратном преобразовании значения определенных атрибутов становятся именами атрибутов. Таблица, получающаяся в результате такого преобразования, относится к так называемым кросс-таблицам (Cross-Tables, Crostabs).

Обобщение атрибутов

Преобразование иерархической модели — предмет рас­смотрения данного раздела. До сих пор мы обсужда­ли вопросы о том, как адекватно отразить в модели информационные потреб­ности отдельных пользова­телей. Получающаяся при этом модель в максималь­ной степени ориентирована на представление данных, необходимое определенному пользователю. Предпола­гается, что в результате дальнейшего анализа множе­ство исходных моделей будет преобразовано, исходя из требований эффективного по­строения базы данных. Такое преобразование рассматрива­ется в последующих главах и базируется на других классах моделей, нежели «сложные таблицы». Однако кое-что можно преобразовать уже сейчас, в рамках иерархиче­ской модели. Имеется в виду так называемое обобщение атрибутов.

Обобщение атрибутов — преобразование модели, в ре­зультате которого несколько атрибутов заменяются одним многозначным агрегатом. Общая схема такого преобразо­вания приведена на рис. 1.17. Здесь исходные неключе­вые атрибуты «атр1», «атр2», «атрЗ» преобразуются с мно­гозначный агрегат «Обобщение» с атрибутами «имя» и «знач». Каждому экземпляру исходного атрибута в новой модели соответствует свой экземпляр многозначного агре­гата. Атрибут «имя» в качестве значения содержит имя ис­ходного атрибута, а атрибут «знач» — само значение.

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

—>экземпляр сущности с искомым ключом —> имя искомого атрибу­та —> значение искомого атрибута

превращается в четырехшаговую

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

Новая модель эквивалентна исходной, поскольку атри­бут «имя» является идентификатором агрегата «Обоб­щение», так как содержащиеся в нем имена атрибутов уникальны для каждого экземпляра исходной сущности и, следовательно, всегда имеется возможность однозначно определить значение исходного атрибута, зная его имя.

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

Пример. На рис. 18 иллюстрируется обобщение атрибутов в мо­дели, отражающей успеваемость студентов по различным предметам. Исходная модель включает атрибуты, содержащие оценки студента по отдельным предметам, а результирующая — обобщенный много­значный агрегат со сведениями об успеваемости. Для простоты в ис­ходной модели указаны три обобщаемых атрибута, в реальных усло­виях их может быть значительно больше (около сотни). В результате обобщения получилась, по-существу, модель сущности «Студент», которая много-

кратно обсуждалась выше. В исходной модели обобщае­мые атрибуты-имена предметов являются необязательными (студент может не иметь оценки по данному предмету — сейчас или никогда), поэтому много­значный агрегат «СдачаПредм» также является необязательным (отсутствие экземпляров означает, что студент не имеет оценок ни по одному предмету). Вместе с тем, атрибуты, входящие в многозначный агрегат, являются обязательны­ми (если присутствует название предмета, то должна присутствовать и оценка по предмету, и наоборот).

Особенности обобщения атрибутов, а также преимуще­ства их использования заключаются в следующем:

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

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

• обобщение агрегатов выполняется аналогично обоб­щению одиночных атрибутов. Пусть помимо полученной студентом оценки требуется отразить в модели и дру­гую информацию: дату сдачи, сведения о преподавате­ле, выставившем оценку и т. п. Тогда в исходной моде­ли атрибуты-предметы придется заменить соответствую­щими однозначными агрегатами и продублировать во всех из них атрибуты «оценка», «датаСдачи», «кодПреподава-теля» и т.д. (рис.19). Каждому экземпляру однозначно­го агрегата исходной модели соответствует свой экземпляр в многозначном агрегате обобщенной модели. Вместо сто­кратного дублирования достаточно добавить в многознач­ный агрегат по одному новому атрибуту;

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

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

Какие атрибуты / агрегаты обобщать? Этот вопрос ак­туален, поскольку формально (см. рис. 1.17) можно обоб­щить практически любые неключевые атрибуты (запрячь в одну телегу «коня и трепетную лань»). Ответ на этот вопрос лежит скорее в области здравого смысла, нежели формальной теории. Не доводить дело до абсурда, учиты­вать последствия применительно к конкретному случаю — вот принципы, которыми должен руководствоваться раз­работчик при принятии решения об обобщении атрибутов. Тем не менее, попытаемся сформулировать несколько об­щих положений:

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

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

• большое количество родственных атрибутов / агрега­тов является убедительным основанием для обобщения. Стоит ли «огород городить» из-за двух или трех атрибутов? Если же цена вопроса выражается десятками атрибутов, то решение упростить модель путем обобщения выглядит вполне обоснованным;

• большая обновляемость состава атрибутов или агре­гатов, т. е. возможность плохо предсказуемого появле­ния в будущем новых атрибутов / агрегатов, изменения или удаления существующих, также может служить осно­ванием для обобщения. Операции добавления, удаления или изменения атрибута требуют модификации структуры базы данных. В обобщенной модели эти операции сводятся к изменению содержимого базы данных. Изменение струк­туры требует больших затрат, нежели изменение содержи­мого.

При обратном преобразовании значения определенных атрибутов становятся именами атрибутов. Таблица получающая в результате такого преобразования, относятся к так называемым кросс-таблицам (Cross-Tables, Crostabs)