6.3. Домены, отношения и типы данных

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

Для пояснения рассмотрим следующий пример, основанный на отношениях, приведенных на рис.6.1: пользователь может осуще­ствить запрос, основанный на операции сравнения SPO.SN = SPP.SN, так как атрибут SN в отношениях принадлежит одному до­мену и имеет один тип. Однако запрос, предполагающий сравнение SPO.OCENKA = SPP.PN, не является корректным - атрибуты при­надлежат разным доменам и СУБД не должна его выполнять.

Иногда проверку соответствия доменов необходимо отключать - это может быть связано с особенностями предметной области, о ко­торых в БД информация отсутствует. Примером такого вполне кор­ректного запроса (с предметной точки зрения) может служить вы­борка данных о студентах по номеру студенческого билета в отно­шении, в котором хранятся данные о заработной плате сотрудников: в принципе, студент может учиться и работать в ВУЗе. Однако в СУБД, для выполнения такого запроса, система проверки доменов должна быть неактивна - ведь табельный номер сотрудника и номер студенческого билета принадлежат разным доменам.

Более того, интересны моменты, связанные с проверкой принад­лежности тому или иному домену, возникающие и в более простых случаях, например, при выборке данных по условию SPO.OCENKA = 5. Атрибут SPO.OCENKA принадлежит домену оценок, а 5 - это целое число, т.е. значения принадлежат разным до­менам. По этой причине в СУБД в неявном виде происходит преоб­разование данных одного типа к одному домену, а значит, в нашем примере целое число преобразуется к домену оценок и только после этого происходят дальнейшие действия. Для этих целей в СУБД используются специальные функции приведения типов и при работе с аналогичными выражениями они неявно используются системой для отмены проверки доменов.

Таким образом, для упрощения работы СУБД на данные на­кладывают ограничение не на принадлежность тому или иному домену, а на принадлежность соответствующему типу данных. При этом система либо проверяет соответствие типов, либо ищет такую функцию преобразования, чтобы данные стали принадле­жащими одному типу.

При этом возникает еще одна сторона проблемы использова­ния типов данных и поддержки в полном смысле понятия домена: при манипуляциях с доменами ряд операций имеют смысл в предметной области, а некоторые операции бессмысленны. На­пример, выборки данных по условиям SPP.PN = "Физика" и SPP.PN > "Физика" с учетом вышесказанного корректны, но вто­рой случай смысла в предметной области не имеет.

Поэтому СУБД должно быть известно, какие выражения и операции являются корректными, а какие - нет, а множество всех доменов должно быть замкнутым, чтобы система знала к какому домену отнести те или иные данные. Из этого следует, что рас­смотренное выше требование скалярности данных в домене за­ключается в том, что они могут иметь достаточно сложную структуру, однако система не должна последнюю видеть.

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

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

Следовательно, операция соединения отношений А{А.Х, A.Y} и B{B.Y, B.Z} является вполне корректной, несмотря на то, что атрибуты Y имеют одинаковое имя и тип в обоих отношениях, но определены на различных доменах. При этом возникает интересный момент - в полученном в результате выполнения операции отношении С{С.Х, C.Y, C.Z} неясно, на каком домене определен атрибут Y. Из совместимости по типу доменов отношений А и В, на которых определен атрибут Y, следует, что их можно преобра­зовать один к другому, а в СУБД предусматривают домены с большим приоритетом.

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

Здесь необходимо еще раз остановиться на вопросах, связан­ных с наследованием типов, которые уже были рассмотрены вы­ше. Эти вопросы тесно связаны с понятиями подтипа и суперти­па. Тип X является подтипом типа Y, если каждый экземпляр типа X обязательно принадлежит типу Y. Соответственно, тип Y будет являться супертипом для типа X. Например, тип СТУ­ДЕНТ является подтипом типа УЧАЩИЙСЯ, а тип УЧАЩИЙСЯ является супертипом для типа СТУДЕНТ.

Эти понятия важны со следующей точки зрения: если СУБД знает, что экземпляр типа X является подтипом типа Y, то свой­ства Y присущи X. В таком случае говорят, что тип X наследует свойства типа Y, а пользователь имеет возможность применять данные типа X там, где можно применять данные типа Y - это называют принципом подстановки. Удобство наследования за­ключается и в том, что для типа можно многократно выполнять некое действие, которое применимо и для его подтипов без каких либо доработок.

Использование этих принципов для доменов связано с тем, что, несмотря на наследование свойств, внутренняя структура каждого типа, вообще говоря, может быть различна, но один тип можно привести к другому. Например, тип СТУДЕНТ можно привести к типу УЧАЩИЙСЯ, но при обратном преобразовании может возникнуть потеря информации - у типа СТУДЕНТ может существовать ряд специфических свойств (например, НАИМЕНОВАНИЕ_ВУЗА), которых в супертипе может и не быть.

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

Для пояснения концепции наследования типов применительно к отношениям рассмотрим пример, приведенный на рис.6.8.

Рис.6.8. Наследование типов в отношениях

В примере рассмотрено отношение SPP{SN, PN, NAME}, на основе которого создано отношение SPF{SN, PN, NAME, OCENKA}, содержащее информацию об успеваемости по физи­ке. При этом SPF от своего родителя унаследовало атрибуты SN, PN, NAME, а атрибут OCENKA добавлен при создании. Таким образом, полученное отношение SPF можно рассматривать как подтип отношения SPP, обладающим собственным свойством (атрибутом) OCENKA, причем над SPF можно выполнять те же операции и функции, что и над его супертипом.