Главная » SQL, Базы данных » СРЕДСТВА ЯЗЫКА SQL

0

Явная поддержка наследования в языке SQL ограничивается (только) одинарным наследованием (только) для структурированных типов; в этом языке отсутствует явная поддержка наследования для сгенерированных типов, нет  явной поддержки для множественного наследования и вообще не поддерживается наследование для встроенных типов ИЛИ ТИПОВ DISTINCT14.

Ниже показан синтаксис определения структурированного типа (немного упро-.

щенный).

14  На основании этих замечаний можно сделать вывод, что в языке SQL имеется определенная неявная поддержка наследования сгенерированных типов и множественного наследования (и это также указано в предложениях, изложенных в [3.3], хотя последние предложения  предусматривают более широкую поддержку). Но в данной главе наше внимание ограничивается только одинарным наследованием и скалярными типами.

CREATE TYPE <type name>

[ UNDER <type name> ]

[ AS <representation> ]

[ [ NOT ] INSTANTIABLE ]

NOT FINAL [ <method specification commalist> ] ;

А здесь представлены примеры возможных определений SQL для типов

PLANE_FIGURE, ELLIPSE И CIRCLE.

CREATE  TYPE PLANE_FIGURE NOT INSTANTIABLE NOT FINAL   ;

CREATE  TYPE   ELLIPSE  UNDER PLANE_FIGURE AS   (  A  LENGTH,    В LENGTH,   CTR  POINT  ) INSTANTIABLE NOT  FINAL   ;

CREATE   TYPE   CIRCLE   UNDER ELLIPSE AS   (  R   LENGTH  )

INSTANTIABLE NOT  FINAL   ;

На основании приведенных определений можно сделать перечисленные ниже выводы

(некоторые из них взяты из главы 5).

1.         Ключевое слово NOT INSTANTIABLE означает, что рассматриваемый тип не имеет экземпляров, где под термином экземпляр (по большей части) подразумевается значение, для которого наиболее конкретным типом является рассматриваемый тип15. Иными словами, рассматриваемый тип представляет собой то, что в дан ной главе упоминается под названием объединенного типа. Ключевое слово INSTANTIABLE означает, что рассматриваемый тип имеет по меньшей мере один экземпляр; это означает, что он не представляет собой объединенный тип и поэтому существует по меньшей мере одно значение, наиболее конкретным типом которого является рассматриваемый тип. В данном примере тип PLANE_FIGURE определен как NOT    INSTANTIABLE, а ТИПЫ ELLIPSE И CIRCLE — Как INSTANTIABLE (по

умолчанию применяется ключевое слово INSTANTIABLE).

2.         Как было отмечено в главе 5, должно быть обязательно указано ключевое слово NOT FINAL (хотя в спецификации SQL:2003, по-видимому, вместо него будет раз решено задавать альтернативное ключевое слово FINAL). Ключевое слово NOT FINAL означает, что для рассматриваемого типа разрешено определять строгие подтипы, а ключевое слово FINAL, когда оно будет поддерживаться, должно озна чать обратное.

3.         Спецификация UNDER определяет непосредственный супертип данного типа (или, в терминологии SQL, прямой супертип — direct supertype), если он имеет ся. Поэтому, например, CIRCLE — это прямой подтип типа ELLIPSE и свойства,

15 В [4.23] экземпляр определен как "физическое представление значения" (?!).

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

а)  Здесь под "свойствами" (в отличие от предложенной автором модели наследо вания) не подразумеваются операторы и ограничения, и этим термином обо значаются операторы и структура (или представление). Иными словами, язык SQL поддерживает и наследование функций, и наследование структуры, по скольку внутренняя структура структурированных типов явно предоставляется в распоряжение пользователя (см. п. 5).

б)  Здесь под термином операторы (в отличие от предложенной автором модели наследования) не подразумеваются лишь операторы, предназначенные только для чтения; этим термином обозначаются все операторы. Иными словами, в языке SQL не проводится должным образом различие между значениями и пе ременными, и этот язык требует безусловного наследования не только опе раций обновления, но и операций только чтения. Из этого следует, что в этом языке, например, окружности могут оказаться некруглыми, квадраты — неквадратными и т.д. (Рассмотрим это замечание более подробно. Модель, предложенная автором, характеризуется следующим: если некоторое значение v относится к наиболее конкретному типу ELLIPSE, то оно определенно пред ставляет собой эллипс, а не окружность, а если оно относится к наиболее кон кретному типу CIRCLE, то определенно представляет собой эллипс, являю щийся окружностью, в том толковании, которое применяется в реальном мире. В отличие от этого, в языке SQL имеет место следующее: если значение v относится к наиболее конкретному типу ELLIPSE, ТО ОНО может фактически представлять собой окружность, а если оно относится к наиболее конкретному типу CIRCLE, то может фактически быть эллипсом, который не является окруж ностью; при этом также применяется толкование в терминах реального мира.)

в)  Рассматриваемые операторы подразделяются на три категории: функции, про цедуры и методы. Как было отмечено в главе 5, функции и процедуры пример но соответствуют операторам, предназначенным только для чтения, и операто рам обновления; методы действуют аналогично функциям, но вызываются с использованием другого синтаксического стиля. Кроме того, функции и про цедуры определяются с помощью отдельных операторов CREATE  FUNCTION и CREATE  PROCEDURE, а методы определяются в виде встроенных конструк ций в составе соответствующего оператора CREATE TYPE, как указано в син таксической структуре оператора CREATE TYPE (ДЛЯ упрощения в приведен ных здесь примерах спецификации методов не применяются). Связывание на этапе компиляции (т.е. связывание на основе только объявленных типов) при меняется к функциям и процедурам, а связывание на этапе прогона применя ется к методам, но осуществляется на основе только одного из существующих фактических параметров (как это обычно принято в объектных системах; см. главу 25).

4.         Аналогом  термина  корневой  тип  в  языке  SQL  является  максимальный  супертип (maximal supertype), поэтому в данном примере PLANE_FIGURE — это максимальный супертип. (Но, как ни странно, в языке SQL для обозначения листового типа

применяется термин не минимальный подтип, а листовой тип, поэтому в рассматриваемом примере тип CIRCLE — это листовой тип.)

5.         Опция <representation> с обозначением представления, если она задана, со стоит из разделенного запятыми списка определения атрибутов <attribute definition    commalist>,   заключенного   в   круглые    скобки,   где   атрибут

<attribute> состоит из имени атрибута <attribute name>, за которым сле дует имя типа <type   name>. Но следует отметить, что такое представление

<representation> является действительным физическим представлением для значений рассматриваемого типа, а не возможным представлением (и поэтому

пользователю предоставляется доступ к этим физическим представлениям, как

уже было отмечено в п. 3). В частности, заслуживает внимания то, что в языке SQL невозможно определить два или больше разных представлений <representation> для одного и того типа.

Примечание. Но, как было указано в главе 5, проектировщик типа может в конечном итоге скрыть тот факт, что представление <representation>  является физическим благодаря продуманному выбору и проектированию операторов.

6.         Для каждого атрибута <attribute> предусмотрены метод-наблюдатель (observer method) и метод-модификатор (mutator method), которые предоставляются авто матически и могут совместно использоваться для реализации функциональных возможностей, в определенной степени аналогичных возможностям операторов ТНЕ_, предусмотренным в языке Tutorial D (некоторые примеры на эту тему при ведены в главе 5). Операторы селекторов не предоставляются автоматически, но для каждого типа предусмотрена предоставляемая автоматически функция конст руктора, которая после ее вызова возвращает такое уникальное значение этого ти па, что для любого и каждого атрибута устанавливается применимое значение по умолчанию. Как было сказано в главе 5, это значение должно быть пустым для любого атрибута, который, в свою очередь, относится к типу, определяемому пользователем. Поэтому, например, следующее выражение возвращает "эллипс", в котором и А, и в имеют "пустую длину", a CTR является "пустой точкой" (ее не следует, безусловно, путать с такой точкой, где оба компонента, х и Y, являются пустыми).

ELLIPSE    ()

А приведенное ниже выражение возвращает эллипс, в котором длина полуоси а равна четырем, длина полуоси b — трем, а центр находится в начале координат.

ELLIPSE () . А ( LENGTH () . L ( 4.0 ) ) . В ( LENGTH () . L ( 3.0 ) ) . CTR ( POINT () . X ( 0.0 ) . Y ( 0.0 ) )

(Здесь предполагается, что тип LENGTH имеет представление, состоящее только из одного атрибута L типа FLOAT.)

7.         Следует отметить, что не существует способа определить множество допустимых значений данного типа; иными словами, не существует ограничений типа, за ис ключением тех априорных ограничений, которые определяются используемым

физическим  представлением.  На  основании  этого  можно  сделать  вывод  (в  силу самого указанного факта), что в языке SQL практически не  поддерживается наследование    ограничений!   Об   этом    уже    было    сказано    в   п.    3.    8.    Каждый структурированный  тип  имеет  связанный   с  ним  ссылочный  тип.  Но  мы  не рассматриваем ссылочные типы в этой главе, не считая того замечания, что, наряду с предусмотренной   в   нем   поддержкой   ссылочных   типов,   язык   SQL   включает поддержку для  подтаблиц и супертаблиц. Эти вопросы рассматриваются более ‘ подробно в главе 26.

Теперь перейдем к более подробному описанию поддержки наследования  типов в языке  SQL.  Прежде  всего,  необходимо  отметить,  что  язык  SQL  напоминает  модель, предложенную автором (по меньшей мере, в том, что эта модель относится только к одинарному наследованию), поскольку этот язык опирается на предположение о непересечении, равносильное предположению,  что наиболее конкретные типы являются уникальными. Кроме того, язык SQL  поддерживает заменяемость (но поскольку в нем не проводится должным образом различие между значениями и переменными, с одной стороны, а также операциями только чтения и операциями обновления — с другой, язык SQL не позволяет должным образом провести различие между заменяемостью значений и заменяемостью переменных). В языке SQL не используется термин полиморфизм.

В языке SQL поддерживаются аналоги предложенного автором оператора  TREAT DOWN и операторов проверки типов, например, как показано ниже.

■     Аналог в языке SQL оператора TREAT_DOWN_AS_CIRCLE   (E) — TREAT(E   AS CIRCLE).

■     Аналог в языке SQL оператора I S_CIRCLE  (E) — ТУРЕ  (Е)  IS OF   (CIRCLE).

■     Аналогом в языке SQL оператора

R  :   IS_CIRCLE   (   Е  )

является следующий оператор.

SELECT TREAT ( E AS CIRCLE ) AS E, F, G, …, H FROM R

WHERE TYPE ( E ) IS OF ( CIRCLE )

Здесь в состав атрибутов F,  G,  . . .,   н входят все атрибуты R, кроме Е.

А поскольку в языке SQL не поддерживаются ограничения типа, то в нем,  безусловно, отсутствует также поддержка уточнения или обобщения с помощью ограничений. Но следует отметить, что этот факт не означает отсутствие возможности изменения наиболее конкретного типа переменной, например, как показано ниже.

DECLARE E ELLIPSE ;

SET Е = СХ

; SET Е = EX ;

Здесь СХ и ЕХ— выражения, которые возвращают, соответственно, значения наиболее конкретного типа CIRCLE и ELLIPSE. Поэтому после первого  присваивания переменная Е (который имеет объявленный тип ELLIPSE)  характеризуется наиболее конкретным типом CIRCLE, а после второго присваивания она имеет наиболее конкретный

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

Наконец, напомним сказанное в главе 5, что любой конкретный структурированный тип не обязательно должен иметь связанный с ним оператор "=", и даже если для него

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

результат операции сравнения принял значение TRUE! ИЗ ЭТОГО следует, что если в сравнении участвует какой-либо структурированный тип, то даже нет гарантии должной поддержки в языке SQL операций соединения, объединения, пересечения и разности. Кроме

того, следует отметить, что эти критические замечания остаются справедливыми независимо от того, применяется ли в этом языке наследование того или иного типа.

Сравнение принципов наследования и делегирования

На данном этапе следует признать, что описание, приведенное выше в данном разделе, может привести к неправильным выводам в одном очень важном отношении. Дело в том, что механизм наследования типов языка SQL (в отличие от предложенной автором модели наследования) почти наверняка не  предназначен  для поддержки той идеи, что создание подтипов происходит в результате применения ограничений к супертипам. Еще раз рассмотрим определение эллипсов и окружностей, как показано ниже.

CREATE TYPE ELLIPSE UNDER PLANE_FIGURE

AS ( A LENGTH, В LENGTH, CTR POINT ) … ;

однородных систем будут проанализированы в разделе 21.6.

Рис. 21.1. Пример типичной системы распределенной базы данных Преимущества

Зачем нужны распределенные базы данных? Основная причина заключается в том, что сами предприятия обычно уже распределены, по крайней мере, логически, т.е. разбиты на подразделения, отделы, рабочие группы и т.д. Очень часто они распределены и физически, т.е. разделены на отдельно расположенные заводы, фабрики, лаборатории и т.д. Из этого следует, что данные также обычно распределены, поскольку каждая организационная единица на предприятии создает и обрабатывает собственные данные, относящиеся к ее деятельности. Таким образом, информация предприятия разбивается на отдельные автономные части, которые иногда называют островами информации. А распределенная система обеспечивает мосты для их соединения в единое целое. Иначе говоря, распределенная система позволяет структуре базы данных отображать структуру

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

Для того чтобы лучше в этом разобраться, приведем пример. Рассмотрим еще раз рис. 21.1. Для простоты предположим, что есть только два узла, Лос-Анджелес и СанФранциско, и что наша система — это банковская система. Данные о счетах  ЛосАнджелеса хранятся  в  Лос-Анджелесе, а данные о  счетах  Сан-Франциско  —  в Сан-Франциско.  Преимущества  подобной распределенной  системы очевидны:  эффективность обработки (данные хранятся в том месте, где доступ к ним требуется наиболее часто) и расширенные возможности доступа (при необходимости с помощью коммуникационной сети из Сан-Франциско можно получить доступ к счетам Лос-Анджелеса и наоборот).

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

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

Примеры распределенных систем

Для ссылок в дальнейшем мы кратко перечислим некоторые известные  реализации распределенных систем. Сначала рассмотрим прототипы. Среди многочисленных исследовательских систем наиболее известны три системы.  Во-первых, это система SDD-1, созданная в научно-исследовательском отделении  корпорации Computer Corporation of America в конце 1970-х и начале 1980-х годов [21.32]. Во-вторых, система R* (читается "R-star"  или  "R-звездочка")1,  распределенная  версия  системы-прототипа  System  R, созданная в исследовательском отделе компании IBM в начале 1980-х годов [21.37]. И в-третьих, система Distributed Ingres, распределенная версия прототипа системы Ingres, созданная также в начале 1980-х годов в Калифорнийском университете в Беркли [21.34].

Что касается коммерческих реализаций, то большинство современных продуктов SQL включает определенную поддержку распределенных баз данных, но, безусловно, с разными уровнями функциональных возможностей. Наиболее  известные среди них следующие: Ingres/Star (распределенный компонент базы  данных СУБД Ingres), версия для распределенных баз данных СУБД Oracle и  средства распределения данных для СУБД DB2.

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

все еще продолжают использоваться. Кроме того, этот список продуктов и прототипов

1 В данном обозначении звездочка — это так называемый "оператор Клина" (KJeene), а конструкция "R*" означает "от нуля или большеэкземпляровСУБД[System]R":

ни в коем случае не следует считать исчерпывающим; автор просто хотел упомянуть системы, которые по тем или иным причинам оказывали или оказывают  определенное влияние на развитие данной области либо представляют интерес благодаря своей внутренней структуре. Но, по крайней мере, следует указать,  что все перечисленные здесь системы, как прототипы, так и продукты, относятся к категории реляционных систем (в частности, во всех них поддерживается язык  SQL). В действительности, существует несколько конкретных причин, по  которым  для успешной реализации распределенная система должна быть реляционной. Реляционная технология — это необходимое условие для  эффективной  реализации распределенной технологии [15.6]. Некоторые причины такого положения дел будут рассмотрены ниже в этой главе.

Фундаментальный принцип

Теперь сформулируем утверждение, которое может рассматриваться как  фундаментальный принцип создания распределенных баз данных [21.13].

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

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

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

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

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

1.         Локальная независимость.

2.         Отсутствие зависимости от центрального узла.

3.         Непрерывное функционирование.

4.         Независимость от расположения.

5.         Независимость от фрагментации.

6.         Независимость от репликации.

7.         Обработка распределенных запросов.

8.         Управление распределенными транзакциями.

2  "Правила" — это термин, используемый в статье, в которой эти правила впервые были  представле ны [21.13]. Указанный "фундаментальный принцип" был назван "Правилом ноль". Однако на самом деле здесь более уместен термин "цели" — слово "правила" звучит слишком категорично. В этой главе будет использоваться более умеренное название — "цели".                                                                                    .

9.     Аппаратная независимость.

10.           Независимость от операционной системы.

11.           Независимость от сети.

12.           Независимость от типа СУБД.

Обратите внимание на то, что не все эти цели независимы одна от другой. Кроме того, они не исчерпывающие и не все одинаково важны (разные пользователи могут придавать различное значение разным целям в различных средах, и, кроме того, некоторые из этих целей могут быть вообще неприменимы в некоторых ситуациях). Но данные цели полезны как основа для понимания самой распределенной технологии и как общая схема описания функциональных возможностей конкретных распределенных систем. Поэтому мы будем использовать список этих целей как организационный принцип для большей части данной главы. В разделе 21.3 кратко обсуждается каждая из целей. В разделе 21.4 некоторые конкретные вопросы рассматриваются более подробно, а в разделе 21.5, как уже отмечалось,  приводится обсуждение систем "клиент/сервер". В разделе 21.6 мы детально обсудим некоторые конкретные проблемы, связанные с достижением независимости от СУБД. Наконец, раздел 21.7 посвящен поддержке языка SQL, а в разделе 21.8 содержится резюме и представлено несколько заключительных замечаний.

Рассмотрим последний дополнительный вопрос в этом разделе. Важно отличать истинные обобщенные системы распределенных баз данных от систем, которые предоставляют просто удаленный доступ к данным (кстати, это все, что на самом деле предоставляет пользователям система "клиент/сервер"). В системах удаленного доступа к данным конечный пользователь может оперировать данными на удаленном узле или даже данными на нескольких удаленных узлах одновременно, но ему будут видны все "швы". Пользователю, несомненно, в той или иной мере будет известно, что данные расположены не локально, и поэтому он должен действовать с учетом этого. В истинной системе распределенных баз данных, напротив, все швы скрыты. (Большая часть этой главы посвящена выяснению вопроса, что же означает выражение "все швы скрыты".) Далее термин распределенная система будет означать именно истинную обобщенную систему  распределенной базы данных (в противоположность обычной системе удаленного доступа к данным), если только явно не будет указано иное.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии