Обязательность и множественность

Ограничения обязательности отвечают на вопрос о том, должны ли значения некоторого атрибута (атрибутов) при­сутствовать во всех экземплярах некоторой сущности или агрегата. Например, у каждого студента имеются код, фа­милия, имя, отчество и они обязательно должны присут­ствовать в экземпляре сущности «Студент». Вместе с тем, в модели на рис. 1.6 для каждого студента предусмотрен многозначный атрибут «телефон» — сведения о контакт­ных телефонах студента. Для одного студента можно за­дать несколько значений «телефона». Возникает вопрос, допустимы ли экземпляры студентов, у которых вовсе от­сутствует значение этого атрибута? Вполне можно (хотя и с трудом) представить студента, у которого нет (физиче­ски) телефона, т. е. нечего записать в базу данных. Таким образом, необходимо иметь возможность отражать в моде­ли обязательные и необязательные атрибуты.

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

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

Интерпретация отсутствующих значений необязатель­ных атрибутов и агрегатов может быть различной. Чаще всего используются следующие два варианта:

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

• «значение невозможно» — реальный объект, кото­рый отражается в экземпляре сущности, принципиаль­но не может иметь значений у соответствующих атрибу­тов или агрегатов¹. Например, атрибут «контракт» (см. рис. 1.7) имеет смысл только для студентов-контрактни­ков и невозможен у студентов-бюджетников. Можно усло­виться, что отсутствие значения у атрибута «контракт» означает, что перед нами студент-бюджетник, иначе — студент-контрактник.

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

Значение по умолчанию, задаваемое для необяза­тельного атрибута, которое автоматически присваивается атрибуту в том случае, если ему не задано явным образом значение при занесении в базу данных, — распространен­ный способ решения проблем, связанных с необязательны­ми атрибутами. Условившись об определенных значениях, задаваемых по умолчанию, пользователи достаточно лег­ко могут контролировать отсутствующие атрибуты и упра­влять ими. Другой подход основан на использовании си­стемных Null-значений, поддерживаемых в большинстве современных СУБД. В этом случае экземпляр атрибута по­мечается системой как неопределенный и обрабатывается в соответствии с трехзначной логикой².

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

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

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

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

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

Домены

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

Задать домен, таким образом, это, значит, тем или иным способом очертить множество допустимых значений для атрибута так, чтобы можно было проверить, принадле­жит ли значение атрибута этому множеству. В простейшем случае это можно сделать путем прямого перечисления до­пустимых элементов множества. Например, выше рассма­тривался атрибут «категория», который может принимать одно из двух значений: «Б» и «К»; домен с именем «категорияСтудента» может быть задан как множество

DOMAIN категорияСтудента = {"Б", "К"}.

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

Стандартные ограничения при задании домена, чаще всего, следующие:

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

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

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

• условие допустимости (Validation Rule) — логическая функция, проверяющая значение атрибута и возвращаю­щая логическое значение «истина» (значение принадле­жит домену) или «ложь» (значение не принадлежит до­мену). Например, для домена «адрес электронной почты» можно составить программу-функцию, которая проверя­ет, что в строке символов, полученной в качестве аргу­мента, во-первых, внутри имеется в точности один символ «@», во-вторых, отсутствуют символы, запрещенные к ис­пользованию в электронном адресе.

¹ Гип также определяет набор операций, допустимых с данными (со строками можно выполнять операции сцепления, вырезания и т.д., с числами — сложения, вычитания, умножения, деления и т.д., с да­тами — вычитания, сложения с целым числом и т. д.).

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