Описание на яод

В СУБД IMAGE/1000 реализован специальный ЯОД, подробное описание которого выходит за рамки курса. Приведенный фрагмент определения БД «Санатории» дает достаточное представление о характере этого языка. Пояснения приводятся в комментариях (ограничители комментариев – <<..>>).

$CONTROL: TABLE, ROOT, FIELD;

BEGIN DATA BASE: SANAT::29; <<Имя корневого файла и номер диска>>

LEVELS: <<Уровни доступа к данным>>

1 INSP <<Инспектор>>

10 MNGR <<Руководитель>>

11 ADM <<Администратор>>

ITEMS: <<Описание атрибутов:>>

<<имя, тип, длина, доступ по чтению и записи>>

NOM, X6(1,1); <<Номер>>

NAME, X34(1,1); <<Текст, соответствующий номеру>>

NOMLK, I1(1,1); <<Номер люкса (комнаты)>>

OFFICE, X6(1,1); <<Код учреждения>>

OFFNAM, X34(1,1); <<Название учреждения>>

POST, X6(1,1); <<Код должности>>

POSTNAM, X34(1,1); <<Название должности>>

SANAT, X6(1,1); <<Код санатория>>

SANAM, X34(1,1); <<Название санатория>>

PROFIL, I1(1,1); <<Код профиля санатория>>

PRONAM, X34(1,1); <<Название профиля санатория>>

ADDRESS, X80; <<Адрес>>

WAY, X80; <<Дорога в санаторий>>

NLUX, I1; <<Число люксов в санатории>>

NROOM, I1; <<Число комнат в санатории>>

NPAL, I1; <<Число коек в палатах санатория>>

. . .

SETS:

<< Владелец должности >>

NAME: NKPOS::29,A; <<Имя владельца; A – автоматический>>

ENTRY: <<Атрибуты>>

POST(4), <<Имя атрибута и количество ссылок>>

CAPACITY: 817; <<Размер набора (таблицы)>>

<< Номер люкса (комнаты) >>

NAME: NOLXKO::29,A;

ENTRY:

NOM(4),

CAPACITY: 817;

. . .

<< Описание люксов >>

NAME: NOLUX::29,D; <<Имя члена; D – детальный>>

ENTRY:

NOM(NOLXKO), <<Имя атрибута и ссылка на владельца>>

NOMLK,

SANAT(NKLPOS),

NMEST,

CATEG(NKLMN),

QUALIT,

CAPACITY: 101;

<< Описание должности >>

NAME: NOPOST::29,D;

ENTRY:

POST(NOLXKO),

POSNAM,

CAPACITY: 311;

<< Вид льготы >>

NAME: NOLGO::29,D;

ENTRY:

NOMORD,

NAME,

CAPACITY: 7;

. . .

END.

Лекция 5 Реляционная модель Принципы

Реляционная модель данных была предложена Коддом как альтернатива наиболее распространенной в то время сетевой модели. В основу модели Кодд положил три базовых принципа (или, по его словам, три стремления):

1. независимость данных на логическом и физическом уровнях – стремление к независимости;

2. создание структурно простой модели – стремление к коммуникабельности;

3. использование концепции языков высокого уровня для описания операций над порциями информации – стремление к обработке множеств.

Основной побудительной причиной исследований, результатом которой стало создание реляционной модели, стало желание четко разграничить логические и физические аспекты управления БД (первое стремление). В качестве дополнительного результата исследований предполагалась разработка теоретических основ организации и управления БД, то есть создание строгой математической модели.

Для реализации трех принципов пришлось отказаться от принятых ранее принципов структуризации данных (повторяющихся групп, связанных структур). В качестве структурной единицы выбрано отношение n-го порядка: при соответствующих операторах и концептуальном представлении в виде таблиц оно позволяет реализовать все три предложенных принципа. Отношение n-го порядка – математическое множество, в котором порядок строк не имеет значения. Заметим, что понятие реляционная БД несколько шире, чем табличная: во втором случае предполагается, что к строке можно добраться по номеру, следовательно, порядок строк имеет значение. Традиционно позиционирование данных определялось адресами в памяти, в реляционной модели адресный способ выбора данных заменен ассоциативным. Каждая единица информации в реляционных БД (РБД) ассоциируется с уникальной тройкой: именем отношения, значением ключа, именем атрибута. При таком подходе система должна сама (а) определить, где следует поместить фрагмент данных, (б) выбрать путь доступа при поиске.

Модель

Напомним, что модель данных – это не только структура, это комбинация, по крайней мере, трех составляющих:

• типов структур данных,

• операторов или правил вывода, применимых к правильным типам данных,

• общих правил целостности, который определяет множество непротиворечивых состояний БД и множество изменений ее состояний.

Структурная часть реляционной модели состоит из следующих компонент:

• доменов – совокупности однотипных значений данных;

• отношений неопределенного порядка, концептуально представленных таблицами;

• атрибутов – атомарных данных, определяющих столбцы таблицы;

• кортежей – строк таблицы,

• потенциальных (возможных) ключей – атрибутов, однозначно определяющих кортеж в отношении;

• первичных ключей – для отношения это один из возможных ключей.

Обрабатывающая часть состоит из операторов выбора, проекции, соединения и т.п., которые преобразуют отношения в отношения.

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

Кодд приводит критерии, по которым СУБД можно отнести к реляционным. Эти критерии следующие:

• СУБД должна поддерживать таблицы без видимых пользователю навигационных связей;

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

Если СУБД не удовлетворяет второму критерию, ее назвают табличной. Реляционные СУБД с минимальной возможностью реляционной обработки называются минимально реляционными, если же в СУБД в полной мере реализованы две последние составляющие реляционной модели,– это полностью реляционные СУБД. СУБД, реализующие полный набор реляционных операторов, называются реляционно полными.