2. Фгаическое представление заданного скалярного значения, т.е. заданное значение заданного скалярного типа, может быть произвольно сложным. В частности, оно может быть составным (однако его компоненты не могут быть видимы пользователю). Например, при определенных обстоятельствах заданное скалярное значение может иметь физическое представление в виде массива стеков списков символьных строк.

3. Из-за того что скалярные типы не имеют видимых компонентов, их иногда называют инкапсулированными (скрытыми). Также иногда используется термин атомарный тип. Однако мы предпочитаем не употреблять подобные термины, поскольку в прошлом из-за них возникало множество недоразумений (поспешим добавить, что и по нашей собственной вине). В частности, путаница возникает при разграничении модели и ее реализации, а также при разграничении типа данных и его представления.

4. Как вы вскоре убедитесь, скалярные типы имеют так называемые допустимые представления, а допустимые представления, в свою очередь, обязательно имеют видимые компоненты. Обратите внимание на то, что в данном случае видимые компоненты являются компонентами не типа, а его допустимого представления. Тип данных всегда остается скалярным в смысле приведенного выше определения.

Определение типа

в этой книге мы часто будем использовать язык Tutorial D (вернее, некоторую его версию), впервые применявшийся в главе 3 для иллюстрации излагаемых в ней идей. В общих чертах язык Tutorial D напоминает язык Pascal. Мы будем знакомить вас с этим языком по мере его использования. Первое, для чего он нам потребуется, - для получения средства определения собственных типов.

TYPE <имя типа> <возможное представление>

В качестве примера рассмотрим определения типов для базы данных поставщиков и деталей (см. рис. 3.9).

TYPE S# POSSREP (CHAR) ;

TYPE NAME POSSREP (CHAR) ;

TYPE P# POSSREP (CHAR) ;

TYPE COLOR POSSREP (CHAR) ;

TYPE WEIGHT POSSREP (RATIONAL) ;

TYPE QTY POSSREP (INTEGER) ;

Пояснения

1. Поскольку из главы 3 следует, что атрибут поставщиков STATUS и атрибут поставщиков и деталей CITY определяется с помощью встроенных типов, а не типов, определенных пользователем, определение типов для указанных атрибутов отсутствует.

2. Как мы уже видели, физическое представление типа скрыто от пользователя. Соответственно приведенные выше определения типов не содержат никакой информации об их физическом представлении. Фактически эти представления должны задаваться как часть отображения концептуальный-внутренний (см. главу 2, раздел 2.6).

Обязательным является наличие у каждого типа данных хотя бы одного допустимого представления по причине, рассматриваемой в следующем разделе. Например, значения типов Si, NAME, Pi и COLOR можно представить в виде строк символов, а значение типа WEIGHT - в виде рационального числа.

Замечание. В этой книге (следуя рекомендациям из [3.3]) вместо привычного названия встроенного типа REAL будет использоваться более точное название - RATIONAL.

3. Здесь принимаются очевидные синтаксические соглашения, суть которых состоит в следующем: неименованные допустимые представления наследуют имя соответствующих типов, а компоненты неименованных допустимых представлений наследуют имена соответствующих представлений. Например, единственное допустимое представление, определенное для типа QTY, также называется QTY; то же самое относится к единственному компоненту данного возможного представления.

4. При определении нового типа система делает в каталоге запись, содержащую описание этого типа (чтобы вспомнить некоторые детали, касающиеся каталогов, возвратитесь к разделу 3.6 главы 3). То же самое происходит при определении оператора (об этом рассказывается в двух следующих разделах).

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

Если какой-либо тип данных больше не нужен, от него, конечно же, можно избавиться.

DROP TYPE <имя типа> ;

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

Замечание. Для простоты будем считать, что оператор DROP TYPE не выполняется, если удаляемый тип данных в текущий момент где-либо используется, например если на основе этого типа определен атрибут некоторого отношения.

Допустимые представления

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

TYPE POINT /* геометрические точки */

P0SSREP CARTESIAN ( X RATIONAL, Y RATIONAL ) POSSREP POLAR ( R RATIONAL, THETA RATIONAL ) ;

В первую очередь, следует отметить, что тип POINT имеет два разных допустимых представления, CARTESIAN и POLAR, отображающих тот факт, что точку на плоскости можно задать либо в декартовых, либо в полярных координатах. (Безусловно, физическое представление этого типа в конкретной системе на самом деле может быть выполнено в декартовых координатах, в полярных координатах или посредством некоторого

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

При каждом объявлении допустимого представления автоматически определяются два более или менее очевидных оператора.

Оператор выбора (selector) (с тем же именем, что и имя допустимого представления), который предоставляет пользователю средство задания или выбора значения рассматриваемого типа, осуществляемого посредством присваивания значений каждому компоненту данного допустимого представления.

Набор операторов ТНЕ (по одному оператору для каждого компонента допустимого представления), обеспечивающих доступ к соответствующему компоненту данного допустимого представления.

Рассмотрим на примере использование оператора выбора и оператора ТНЕ для типа POINT.

CARTESIAN ( 5.0, 2.5 ) /* Задает точку с координатами х = 5.0, у = 2.5 */

CARTESIAN ( XXX, YYY ) /* Задает точку с координатами х = XXX, у = YYY */

/* Здесь XXX и YYY - переменные типа RATIONAL */

POLAR ( 2.7, 1.0 ) /* Задает точку с г = 2.7 и theta = 1.0 */

ТНЕ Х ( Р ) /* Возвращает координату х точки Р */

/* Здесь Р - переменная типа POINT */

THE R ( Р ) /* Возвращает координату г точки Р */

Замечание. Очевидным является тот факт, что оператор выбора- это обобщение уже знакомого нам понятия литерал (literal).

Для того чтобы увидеть, как все вышесказанное работает на практике, будем считать, что физическим представлением значения типа POINT являются фактические декартовы координаты точки (хотя в общем случае физическое представление может быть произвольным). Кроме того, допустим, что для описания этого физического представления системой предоставляются специальные защищенные операторы (выделенные курсивом), которые затем будут использованы определителем типа для реализации операторов выбора CARTESIAN и POLAR, как, например, показано ниже,

OPERATOR CARTESIAN ( X RATIONAL, Y RATIONAL ) RETURNS ( POINT ) ; BEGIN;

VAR P POINT;

Х-компонент физического представления P := X ; Y-компонент физического представления Р := Y ;

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

Очевидно, что определитель типа является исключением из общего правила, гласящего, что пользователи не осведомлены о физическом представлении типа.