PERSONNEL (PERS TYPE)

UNDER

REPS (SALES TYPE)

UNDER

ENGINEERS (ENGR TYPE)

under

under

technicians

(TECH TYPE)

managers

(MGR TYPE)

Рис 23.3. Иерархия таблиц Informix с табличным наследованием vs. Тщ

Когда таблица создается подобным образом, она наследует не только набор столбцов исходной таблицы, но и целый ряд других ее характеристик: первичный и внешние ключи, условия ссылочной целостности и офаничения на значения, фиг-геры, индексы, области хранения данных и другие специфические для Informix характеристики. При этом наследуемые характеристики в инсфукции create table можно заменять новыми определениями.

Иерархическая связь таблиц оказь(вает влияние на то, как Informix Universal Server интерпретирует их сфоки. Иерархически связанные таблицы уже не являются самостоятельными наборами записей - теперь это вложенные наборы записей (рис. 23.4). Когда сфока добавляется в иерархию таблиц, она по-прежнему добавляется в конкретную таблицу. Например, Джо Джонс (Joe Jones) является технологом (запись о нем входит в таблицу technicians), тогда как Сэм Уилсон (Sam Wilson) - разработчик (таблица engineers), а Сью Марш (Sue Marsli) - рядовая служащая (таблица personnel). А вот SQL-запросы теперь действуют совершенно иначе. Когда вы выполняете запрос к одной таблице иерархии, он возвращает сфоки не только из этой таблицы, но также из всех ее подчиненных таблиц. Например, следующий запрос:

select *

from personnel

возвращает сфоки из таблицы personnel, а также из таблиц engineers, technicians, managers и reps. Аналогичным образом запрос

select *

from engineers;

вернет сфоки из таблиц engineers, technicians и managers. СУБД интерпретирует таблицы как вложенные наборы записей, и запрос к любой из них возврашает все записи, входящие в соответствующий ей набор. Если же вам нужны только записи из таблицы верхнего уровня, включите в запрос ключевое слово only:

select *

from only(engineers);

Ту же логику СУБД применяет и в отношении запросов на удаление. Например, следующая инсфукция delete:

delete from personnel where empl num = 1234;

успешно удаляет запись о служащем с идентификатором 1234 независимо от того, в какой таблице иерархии она находится на самом деле. СУБД интерпретирует эту инст17укцию гак: Удалить из набора записей personnel все строки, соответствующие заданному условию . Если же вы хотите удалить только те строки, которые хранятся в конкретной таблице иерархии, например в таблице engineers, но не в ее подчиненных таблицах, тотда, как и в случае с запросами на выборку, вам нужно воспользоваться ключевым словом only:

DELETE FROM ONLY(ENGINEERS) WHERE EMPL NUM = 12 34;

Та же логика применяется и к инструкциям update. Например, следующая инструкция изменяет фамилию служащего независимо от того, в какой таблице иерархии хранится его запись:

UPDATE PERSONNEL

SET L N.s.ME = Harrison WHERE EMPL NUM = 1234;

Если же нужно офаничить область действия инструкции update одной таблицей, то, как и в предыдущих примерах, можно воспользоваться ключевым словом only.

Набор запксой PERSONNEL

Набоо

i: NGINE

Sa Wilso 1

VWatsony

Набор записей TECHNICIANS

Cj°e / Georae j° es v. Nye

Набор записей MANAGERS

we таблицы в иерарщи наспедования

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

DELETE FROM PERSONNEL WHERE SALARY < 20000.00;

поскольку в таблице personnel, расположенной на верхнем уровне иерархии, нет столбца salary. Этот столбец определен для некоторых ее подчиненных таблиц. А вот такая инсфукция вполне допустима:

delete from managers where salary < 20000.00;

поскольку на этом уровне иерархии столбец salary определен.

Объектно-реляционные технологии в Informix Universal Server выходят далеко за рамки обычных реляционных баз данных. Пуристы реляционной архитектуры считают операции, выполняемые в приведенных выше примерах, опасными и нелошч-ными. Почему, - спрашивают они, - добавление строки в одну таблицу вызывает ее неожиданное появление в двух других таблицах? Почему после выполнения запроса на удаление, условию которого не соответствует ни одна строка указанной в нем таблицы, вдруг исчезают строки из других таблиц? Ответ прост: иерархия таблиц не является строго реляционным набором независимых таблиц, она ведет себя совершенно иначе и обладает рядом характеристик иерархии классов. Тем, кто хочет работать с ОРБД, нужно принять новый взгляд на вещи и понять, что они имеют дело с иначе построенной моделью мира - поведение ее объектов нельзя оценивать с точки зрения логики реляционной модели. И первое время нужно будет внимательно следить за тем, чтобы не делать реляционных предположений о результатах выполнения инструкций SQL.

Множества массивы и коллекции

в реляционной базе данных таблица является единственной информационной структурой. Например, множество инженеров в нашей базе данных представлено строками в таблице engineers. Предположим, что каждый инженер имеет ряд ученых степеней (бакалавр естественных наук в Массачусетском технологическом институте, доктор философии в университете штата Мичиган и т.д.), информация о которых хранится в базе данных. Количество степеней у каждого инженера свое - их может не быть вовсе, а может быть и до полудюжины. В строго реляционной базе данных существует только один правильный способ добавления этой информации в модель данных: должна быть создана новая таблица degrees (рис. 23.5). Каждая строка этой таблицы представляет одну ученую степень одного инженера. Первый столбец каждой строки таблицы degrees содержит идентификатор инженера, степень которого описывается этой строкой, и служит внешним ключом к таблице engineers, образуя между таблицами отношение предок/потомок. Остальные столбцы описывают саму степень.

Реляционную структуру таблиц, изображенную на рис. 23.5, вы видели в этой книге уже 1\[ножесгво раз - именно так с самого начала строились все реляционные базы данных. Однако у этой схемы есть определенные недостатки. Прежде всего, в построенной на ее основе базе данных обычно оказывается очень много таблиц и межтабличных связей на основе внешних ключей, в результате чего ее структура становится громоздкой и сложной для понимания. Во-вторых, многие типичные запросы требуют объединения трех, четырех и более таблиц. В-третьих, в большинстве СУБД объединения реализованы таким образом, что чем больше таблиц объединяется в запросе, тем медленнее он выполняется.

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