Классика баз данных - статьи

Оператор выделения памяти под дескриптор

Оператор имеет следующий синтаксис:
::=ALLOCATE DESCRIPTOR [WITH MAX ] ::= ::=[] ::= GLOBAL | LOCAL ::=| |
Дескриптор - это динамически выделяемая часть памяти прикладной программы, служащая для принятия информации о результате или параметрах динамически подготовленного оператора SQL или задания параметров такого оператора. Смысл того, что для выделения памяти используется оператор SQL, а не просто стандартная функция alloc или какая-нибудь другая функция динамического запроса памяти, состоит в том, что прикладная программа может теперь не знать структуру дескриптора и даже его адрес. Это позволяет не привязывать SQL к особенностям какой-либо системы программирования или ОС. Все обмены информацией между собственно прикладной программой и дескрипторами производятся также с помощью специальных операторов SQL (GET и SET, см. ниже).
Далее возникает вопрос: зачем вообще выделять память под дескрипторы динамически? Это нужно потому, что в общем случае прикладная программа, использующая динамический SQL, не знает в статике число одновременно действующих динамических операторов SQL, описание которых может потребоваться. С этим же связано то, что имя дескриптора может задаваться как литеральной строкой символов, так и через строковую переменную включающего языка, т. е. его можно генерировать во время выполнения программы.
В операторе ALLOCATE DESCRIPTOR, помимо прочего, может указываться число описательных элементов, на которое он рассчитан. Если, например, при выделении памяти под дескриптор в разделе WITH MAX указано целое положительное число N, а потом дескриптор используется для описания M (M>N) элементов (например M столбцов результата запроса), то это приводит к возникновению исключительной ситуации.

Оператор объявления курсора над динамически подготовленным оператором выборки

Оператор определяется следующим синтаксисом:
::=DECLARE [INSENSITIVE] [SCROLL]CURSOR FOR
как определяется в новом стандарте, для всех операторов DECLARE CURSOR курсоры фактически создаются при начале транзакции и уничтожаются при ее завершении. Заметим, что в этом операторе и прямо (литерально) заданные идентификаторы.

Другая разновидность оператора

Для этого оператора действуют следующие синтаксические правила:
::=ALLOCATE [INSENSITIVE] [SCROLL]CURSOR FOR ::=[]
Курсоры, определяемые с помощью оператора ALLOCATE CURSOR, фактически создаются при выполнении такого оператора и уничтожаются при выполнении оператора DEALLOCATE PREPARE или при конце транзакции. В этом операторе имена курсора и подготовленного оператора SQL могут задаваться не только в литеральной форме, но и через переменные (т. е. может использоваться косвенное именование).
относится к области видимости имен: в пределах текущего модуля или в пределах текущей сессии.

Оператор открытия курсора, связанного с динамически подготовленным оператором выборки

Синтаксис оператора открытия курсора следующий:
::=OPEN []
По сути оператор открытия курсора, связанного с динамически подготовленным оператором SQL, отличается от статического случая только возможным наличием раздела using, в котором задаются фактические параметры оператора выборки. Кроме того, имя курсора может задаваться через переменную (т. е. косвенным образом).

Оператор чтения строки по курсору, связанному с динамически подготовленным оператором выборки

Синтаксис:
::=FETCH [[] FROM]
На самом деле оператор чтения по курсору, связанному с динамически подготовленным оператором SQL, отличается от статического случая только возможным наличием раздела using, в котором задается размещение значений текущей строки результирующей таблицы. Кроме того, имя курсора может задаваться через переменную.

Оператор закрытия курсора, связанного с динамически подготовленным оператором выборки

Оператор закрытия курсора определяется следующим синтаксическим правилом:
::=CLOSE
Оператор закрытия курсора, связанного с динамически подготовленным оператором SQL, отличается от статического случая только тем, что имя курсора может задаваться через переменную.

Оператор позиционного удаления

Синтаксис:
::=DELETE FROM WHERE CURRENT OF
Оператор позиционного удаления по курсору, связанному с динамически подготовленным оператором SQL, отличается от статического случая только тем, что имя курсора может задаваться через переменную.

Оператор позиционной модификации

Оператор определяется следующим синтаксическим правилом:
::=UPDATE
SET [{ }. . . ]WHERE CURRENT OF
Оператор позиционной модификации по курсору, связанному с динамически подготовленным оператором SQL, отличается от статического случая только тем, что имя курсора может задаваться через переменную.

Подготавливаемый оператор позиционного удаления

Синтаксис оператора:
::=DELETE [FROM
]WHERE CURRENT OF
Основной резон появления этого и следующего операторов состоит в том, что сочетание курсора, определенного на динамически подготовленном операторе выборки, и статически задаваемых операторах удаления и модификации по этому курсору, выглядит довольно нелепо. Поэтому в стандарте появились динамически подготавливаемые позиционные операторы удаления и вставки. Естественно, что выполняться они должны с помощью оператора EXECUTE.

Подготавливаемый оператор позиционной модификации

::=UPDATE [
]SET [{ }. . . ]WHERE CURRENT OF
См. .
Если внимательно сравнить средства динамического SQL СУБД Oracle V. 6и стандарта SQL/92, то видно, что Oracle практически вкладывается в стандарт, если не считать небольших синтаксических различий и (что существенно более важно) разного стиля работы с дескрипторами. Думается, что примерно такая же ситуация имеет место в других СУБД, поддерживающих динамический SQL.
Поэтому нашими рекомендациями при использовании динамического SQL в прикладных программах являются следующие (если, конечно, вы не хотите дождаться повсеместной и полной реализации SQL/92):
  • ограничиться подмножеством операторов динамического SQL, реализованным в Oracle V. 6;
  • локализовать части программы, связанные с работой с дескрипторами (т. е. как минимум не допускать прямой работы с полями области дескрипторов в стиле Oracle).


    • Оператор освобождения памяти из-под дескриптора

    Синтаксис оператора:
    ::=DEALLOCATE DESCRIPTOR
    Выполнение этого оператора приводит к освобождению памяти из-под ранее выделенного дескриптора. После этого использование имени дескриптора незаконно в любом операторе, кроме ALLOCATE DESCRIPTOR.

    Оператор получения информации из области дескриптора SQL

    Оператор определяется следующими синтаксическими правилами:
    ::=GET DESCRIPTOR ::=| VALUE [{ }. . . ] ::= COUNT ::= ::= ::= ::= ::=TYPE| LENGHT| OCTET_LENGHT| RETURNED_LENGHT| RETURNED_OCTET_LENGHT| PRECISION| SCALE| DATETIME_INTERVAL_CODE| DATATIME_INTERVAL_PRECISION| NULLABLE| INDICATOR| DATA| NAME| UNNAMED| COLLATION_CATALOG| COLLATION_SCHEMA| COLLATION_NAME| CHARACTER_SET_CATALOG| CHARACTER_SET_SCHEMA| CHARACTER_SET_NAME ::=|
    Оператор GET DESCRIPTOR служит для выборки описательной информации, ранее размещенной в дескрипторе с помощью оператора DESCRIBE (см. ). За одно выполнение оператора можно получить либо число заполненных элементов дескриптора (COUNT), либо информацию, содержащуюся в одном из заполненных элементов.

    Оператор установки дескриптора

    Оператор установки имеет следующий синтаксис:
    ::=SET DESCRIPTOR ::=| VALUE [{ }. . . ] ::=COUNT ::= ::= ::= ::=
    Оператор SET DESCRIPTOR служит для заполнения элементов дескриптора с целью его будущего использования в разделе USING. За одно выполнениеоператора можно поместить значение в поле COUNT (число заполненных элементов)либо частично или полностью сформировать один элемент дескриптора.

    Оператор подготовки

    Оператор определяется следующим синтаксисом:
    ::=PREPARE < SQL statement name>FROM < SQL statement variable>< SQL statement variable> ::= ::=| | | | ::=| | | | | | ::=< SQL schema statement> ::=< SQL transaction statement> ::=< SQL session statement> ::= ::=< SQL statement name> ::=| ::=[scope option] ::= [][] ::=FOR { READ ONLY | UPDATE [ OF ] } ::=| ::=SELECT []
    ::= DISTINCT | ALL
    Оператор PREPARE вызывает компиляцию и построение плана выполнения оператора SQL, заданного в текстовой форме. После успешного выполнения оператора PREPARE с подготовленным оператором связывается указанное (литерально или косвенно) имя этого оператора, которое потом может быть использовано в операторах DESCRIBE, EXECUTE, OPEN CURSOR, ALLOCATE CURSOR и DEALLOCATEPREPARE. Эта связь сохраняется до явного выполнения оператора DEALLOCATEPREPARE.

    Оператор отказа от подготовленного оператора

    Синтаксис оператора следующий:
    ::=DEALLOCATE PREPARE < SQL statement name>
    Выполнение этого оператора приводит к тому, что ранее подготовленный оператор SQL, связанный с указанным именем оператора, ликвидируется, и, соответственно, имя оператора становится неопределенным. Если подготовленный оператор являлся оператором выборки, и к моменту выполнения оператора DEALLOCATE существовал открытый курсор, связанный с именем подготовленного оператора, то оператор DEALLOCATE возвращает код ошибки. Если же для подготовленного оператора выборки существовал неоткрытый курсор, образованный с помощью оператора ALLOCATE CURSOR, то этот курсор ликвидируется. Если курсор объявлялся оператором DECLARE CURSOR, то такой курсор переходит в состояние, существовавшее до выполнения оператора PREPARE. Если с курсором был связан подготовленный оператор (динамический DELETE или UPDATE), то для этих операторов выполняется неявный оператор DEALLOCATE.

    Оператор запроса описания подготовленного оператора

    Оператор определяется следующим синтаксисом:
    ::=| ::=DESCRIBE INPUT < SQL statement name> ::=DESCRIBE [OUTPUT] < SQL statement name> ::=| ::={ USING | INTO } [{ }. . . ] ::= ::={ USING | INTO } SQL DESCRIPTOR ::=| ::= [] ::=[INDICATOR] ::= [] ::=[INDICATOR]
    При выполнении оператора DESCRIBE происходит заполнение указанного в операторе дескриптора информацией, описывающей либо результат ранее подготовленного оператора SQL (если это оператор выборки), либо количество и типы параметров подготовленного оператора. В полагается писать USING SQL DESCRIPTOR.

    Оператор выполнения подготовленного оператора

    Синтаксис оператора следующий:
    ::=EXECUTE < SQL statement name>[][] ::= ::=
    Оператор EXECUTE может быть применен к любому ранее подготовленному оператору SQL, кроме . Если это оператор , то оператор EXECUTE должен содержать раздел с ключевым словом INTO. В любом случае число фактических параметров, задаваемых через разделы using, должно соответствовать числу формальных параметров, определенных в подготовленном операторе SQL.

    Оператор подготовки с немедленным выполнением

    Синтаксис оператора:
    ::=EXECUTE IMMEDIATE < SQL statement variable>
    При выполнении оператора EXECUTE IMMEDIATE производится подготовка и немедленное выполнение заданного в текстовой форме оператора SQL. При этом подготавливаемый оператор не должен быть оператором выборки, не должен содержать формальных параметров и комментариев.

    существенно шире того, который

    Набор операторов динамического SQL в стандарте SQL/ 92 существенно шире того, который был реализован в Oracle V. 6. В основном это связано с тем, что введены операторы для работы с дескрипторами, а также появились подготавливаемые операторы позиционного удаления и позиционной модификации.

    Оператор подготовки

    Оператор PREPARE имеет синтаксис:
    ::=PREPARE FROM ::=
    Во время выполнения оператора PREPARE символьная строка, содержащаяся в host-string-variable, передается компилятору SQL, который обрабатывает ее почти таким же образом, как если бы получил в статике. Построенный при выполнении оператора PREPARE код остается действующим до конца транзакции или до повторного выполнения данного оператора PREPARE в пределах этой же транзакции.
    В отличие от операторов SQL, статически подставляемых в программу на обычном языке программирования, в которых связь с переменными включающей программы производится по именам (т. е. в соответствии со стандартом во встроенном операторе SQL могут употребляться просто имена переменных включающей программы), динамическая природа операторов, подготавливаемых с помощью оператора PREPARE, заставляет рассматривать эти имена как имена формальных параметров. Соответствие этих формальных параметров адресам переменных включающей программы устанавливается позиционно во время выполнения подготовленного оператора.

    РАЗДЕЛ FROM

    Результатом выполнения раздела FROM является расширенное декартово произведение таблиц, заданных списком таблиц раздела FROM. Расширенное декартово произведение(расширенное, потому что в качестве операндов и результата допускаются мультимножества) в стандарте определяется следующим образом:
    "расширенное произведение R есть мультимножество всех строк r, таких, что r является конкатенацией строк из всех идентифицированных таблиц в том порядке, в котором они идентифицированы. Мощность R есть произведение мощностей идентифицированных таблиц. Порядковый номер столбца в R есть n+s, где n - порядковый номер порождающего столбца в именованной таблице T, а s - сумма степеней всех таблиц, идентифицированных до T в разделе FROM". (Возможно, читатель не испытает особого восторга от приведенного абзаца, но таков стиль стандарта.)
    Как видно из синтаксиса, рядом с именем таблицы можно указывать еще одно имя "correlation name". Фактически, это некоторый синоним имени таблицы, который можно использовать в других разделах табличного выражения для ссылки на строки именно этого вхождения таблицы. (Одна и та же таблица может участвовать несколько раз в списке одного раздела FROM и/или входить в списки разделов FROM нескольких (под)запросов.)
    Если табличное выражение содержит только раздел FROM (это единственный обязательный раздел табличного выражения), то результат табличного выражения совпадает с результатом раздела FROM.

    СПЕЦИФИКАЦИЯ ЗАПРОСА

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

    Типы данных

    Набор встроенных типов данных предполагается расширить типами BOOLEAN и ENUMERATED. Хотя по причине поддержки неопределенных значений языку SQL свойственно применение трехзначной логики, тип BOOLEAN содержит только два возможных значения true и false. Для представления значения unknown рекомендуется использовать NULL, что, конечно, не вполне естественно. Перечисляемый тип ENUMERATED обладает свойствами, подобными свойствам перечисляемых типов в языках программирования.
    Расширены возможности работы с неопределенными значениями. Появился новый оператор CREATE NULL CLASS, позволяющий ввести именованный набор именованных неопределенных значений. При определении домена можно явно указать имя класса неопределенных значений, появление которых допустимо в столбцах, связанных с этим доменом. Смысл каждого неопределенного значения интерпретируется на уровне пользователей.
    Предполагается включение в язык возможности использовать определенные пользователями типы данных. Видимо, будут иметься возможности определения абстрактных типов данных с произвольно сложной внутренней структурой на основе таких традиционных спецификаций агрегирования и структуризации, как LIST, ARRAY, SET, MULTISET и TURPLE, а также возможности определения объектных типов с соответствующими методами в стиле объектно-ориентированного подхода.
    Появляется возможность использования принципов наследования свойств существующей таблицы (супертаблицы) при определении новой таблицы (подтаблицы). Подтаблица наследует от супертаблицы все определения столбцов и первичного ключа. Другая возможность - создать таблицу, "подобную " существующей в том смысле, что в новой таблице наследуются определения некоторых столбцов существующей таблицы.

    ТИПЫ ДАННЫХ

    Появилась возможность использования типа данных символьных строк переменной длины (т. е. при спецификации столбца указывается предельно допустимый размер хранимой строки в символах, а реально в базе данных хранится ровно столько символов, сколько их ввел пользователь). Введены типы данных битовых строк постоянной и переменной длины ( как они реально хранятся в базе данных, в стандарте не определяется). Наконец, стандартизованы темпоральные типы данных DATE (дата), TIME (время) и INTERVAL (временной интервал).

    ДИНАМИЧЕСКИЙ SQL

    В стандарте определены операторы динамического SQL. См. разд. .

    ВСТРОЕННЫЙ SQL

    как отмечалось в разд. 2. 5, стандарт SQL/89 формально не включал раздел, посвященный встраиванию конструкций SQL в программу на традиционном языке программирования. Этот раздел являлся приложением и, кроме того, не включал правил встраивания для языков Си и Ада. В SQL/92 полностью специфицированы правила встраивания для наиболее распространенных языков программирования(Ада, Си, Кобол, Фортран, MUMPS, Паскаль, ПЛ/1).

    ИНТЕРАКТИВНЫЙ (ПРЯМОЙ) SQL

    В SQL/92 специфицирован набор операторов SQL, которые должны поддерживаться в интерактивном режиме, хотя некоторые решения по-прежнему отдаются на откуп реализациям.
    Этим не исчерпываются расширения SQL/92 по сравнению с SQL/89. Однако не упомянутые выше новые возможности SQL не кажутся настолько важными, чтобы о них стоило писать в журнальной статье (может быть , я и ошибаюсь. . . ).

    ИНТЕРНАЦИОНАЛИЗАЦИЯ И НАЦИОНАЛИЗАЦИЯ

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

    ОПРЕДЕЛЕНИЕ СХЕМЫ БД И МАНИПУЛИРОВАНИЕ СХЕМОЙ БД

    Наконец-то появилась возможность создавать хранимые и представляемые таблицы и задавать или удалять привилегии доступа (операторы CREATE TABLE, CREATE VIEW, GRANT, REVOKE) в любой момент времени в любой транзакции вне оператора определения схемы. Появились операторы уничтожения таблиц (DROPTABLE и DROP VIEW), которые также можно выполнять внутри любой транзакции(при наличии соответствующих привилегий). Вообще, следует заметить, что в стандарте SQL/92 для любого оператора класса CREATE существует парный оператор класса DROP. Специфицирован также оператор ALTER TABLE, позволяющий динамически изменять характеристики ранее созданной таблицы (в частности добавлять к ней новые столбцы). Все упомянутые здесь операторы могут включаться в модуль SQL.

    ОГРАНИЧЕНИЯ ЦЕЛОСНОСТИ

    В добавление к возможностям SQL/89 определения ограничений целостности на уровне столбца и/или таблицы в SQL/92 допустимо отдельное определение ограничений, распространяющееся в общем случае на несколько таблиц.
    Появилась возможность определения отложенных (проверяемых при завершении транзакции) ограничений целостности.
    Расширены возможности определения ограничений внешнего ключа (ограничений ссылочной целостности).
    Введены средства определения (CREATE DOMAIN), изменения (ALTER DOMAIN)и отмены определения (DROP DOMAIN) домена. (На всякий случай напомним читателям, что домены имеют непосредственную связь с ограничениями целостности, поскольку домен определяет потенциально возможное множество значений некоторого типа данных, а при определении столбца таблицы можно указать, к какому домену будут относиться значения этого столбца. Тем самым другие значения допускаться не должны. )

    ПРЕДСТАВЛЕНИЯ

    В стандарте SQL/92 осмысленно ослаблены требования к изменяемым представлениям(в условии выборки допускаются подзапросы, не коррелирующие со столбцами таблицы разделы FROM основного запроса). Заметим, что множество изменяемых запросов SQL/92 по-прежнему не включает все представления, которые теоретически являются изменяемыми.
    Уточнен смысл конструкции WITH CHECK OPTION: введены ключевые слова LOCAL и CASCADE. При указании LOCAL контролируется, что измененная строка останется видимой в том представлении, для которого выполнялся оператор UPDATE. Если же указывается CASCADE, то изменение должно остаться видимым в данном представлении и во всех представлениях, которые определены над исходным представлением (на самом деле мы несколько упрощаем ситуацию, для полного анализа которой требуется длительное рассмотрение комбинаций наличия и отсутствия конструкции WITH CHECK OPTION у исходного представления и того, которое над ним определено).

    ТАБЛИЧНЫЕ ВЫРАЖЕНИЯ

    Появились возможности именования столбцов результирующей таблицы и самой таблицы. Именованные табличные выражения можно использовать, в частности, в разделе FROM запросов. (Раньше всегда было непонятно, почему табличное выражение, результатом которого по определению является таблица, нельзя использовать в качестве элемента списка раздела FROM. )
    Появился новый класс табличных выражений, называемых "табличными выражениями с соединениями " (join-table-expression), которые можно использовать только в разделе FROM. Такие табличные выражения строятся на основе базовых и/или представляемых таблиц на основе использования разных видов операции соединения: CROSS JOIN (Декартово произведение), INNER (обычное соединение), LEFT и LEFT OUTER (левое и левое внешнее соединение), RIGHT и RIGHT OUTER (правое и правое внешнее соединение), FULL и FULL JOIN (полное и полное внешнее соединение) и UNION (объединение). (Не уверен, что от появления этого класса табличных выражений потенциальным пользователям реализаций SQL/92 станет жить легче, хотя возможно станет легче формулировать запросы людям, привыкшим к алгебраическому стилю работы с базами данных. )

    ВЫРАЖЕНИЯ ЗАПРОСОВ

    При построении выражений запросов (формально, согласно синтаксису SQL/92, соответствующие конструкции не называются выражениями запросов; тем не менее мы предпочитаем сохранить этот термин для сближения с семантикой SQL/89), кроме операции теоретико-множественного объединения UNION, которая присутствовала в SQL/89, стало возможным использовать операции EXCEPT (теоретико-множественное вычитание) и INTERSECT (теоретико-множественное пересечение). Заметим для точности, что возможность получения в качестве результата запроса мультимножества строк (т. е. с дубликатами) не позволяет однозначно интерпретировать сразу все эти операции. Поэтому результат одного и того же выражения запросов в разных реализациях может быть разным.

    КУРСОРЫ

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

    УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ И УРОВНИ ИЗОЛЯЦИИ

    Известно, что в большинстве SQL-ориентированных реляционных СУБД поддерживаются несколько режимов изолированности транзакций. В стандарте SQL/92 специфицирован оператор SET TRANSACTION, который, в частности, позволяет явно установить один из следующих режимов, влияющих на уровень изолированности транзакции: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE.
    В соответствии со стандартом режим READ UNCOMMITTED допускает наличие чтения "грязных данных " (если транзакция T1 работает в этом режиме, то она может прочитать данные, обновленные транзакцией T2, которая заканчивается откатом; эти данные "грязные ", поскольку никогда не будут существовать в БД).
    При установке режима READ COMMITTED транзакция не сможет прочитать "грязные данные ", но в ней может возникнуть ситуация "неповторяющегося чтения " (пусть транзакция T1 работает в этом режиме и в ней выполняется выборка некоторой строки некоторой таблицы; после этого в транзакции T2срабатывает оператор, обновляющий эту строку; теперь в транзакции T1 снова выполняется оператор, выбирающий ту же строку, и прикладная программа или интерактивный пользователь с удивлением обнаруживают, что значения полей строки изменились).
    Если устанавливается режим REPEATABLE READ, "неповторяющиеся чтения "должны гарантированно отсутствовать, но возможно возникновение "строк-фантомов "(пусть транзакция T1 работает в этом режиме и выбирает некоторое множество строк некоторой таблицы в соответствии с заданным условием; после этого транзакция T2 заносит в ту же таблицу новую строку, удовлетворяющую условию выборки транзакции T1; теперь в транзакции T1 повторно срабатывает тот же самый оператор выборки, и прикладная программа или интерактивный пользователь с удивлением обнаруживают, что множество выбранных строк отличается оттого, как им оно было при первом выполнении оператора выборки).
    При установке режима SERIALIZABLE должно гарантироваться отсутствие всех перечисленных выше эффектов. В этом случае транзакция должна выполняться так, как если бы она выполнялась в отсутствии всех конкурирующих транзакций(другими словами, смесь транзакций, для которых требуется полная сериализация, должна обрабатываться системой так, чтобы суммарный эффект был эквивалентен некоторому последовательному выполнению этих транзакций). В соответствии со стандартом режим SERIALIZABLE должен являться режимом, устанавливаемым для транзакции по умолчанию (если в ней не встречается какой-либо оператор SET TRANSACTION).
    Кроме указания режима изоляции в операторе SET TRANSACTION можно указать, является ли транзакция только читающей базу данных (READ ONLY) или обновляющей(READ WRITE). По умолчанию любая транзакция считается обновляющей, если только не задан режим изоляции READ UNCOMMITTED. В последнем случае транзакция полагается только читающей. Другими словами, комбинация READ WRITE и READUNCOMMITTED является недопустимой.

    Предикат сравнения

    Синтаксис предиката сравнения определяется следующими правилами:
    ::= { | } ::== | <> | < | > | <= | >=
    Через "<>" обозначается операция "неравенства". Арифметические выражения левой и правой частей предиката сравнения строятся по общим правилам построения арифметических выражений и могут включать в общем случае имена столбцов таблиц из раздела FROM и константы (не обязательно литеральные; вместо литеральной константы может использоваться имя столбца таблицы, указанной в разделе FROM более внешнего подзапроса, или имя переменной программы, написанной на объемлющем языке). Типы данных арифметических выражений должны быть сравнимыми (например, если тип столбца a таблицы A является типом символьных строк, то предикат "a = 5" недопустим).
    Если правый операнд операции сравнения задается подзапросом, то дополнительным ограничением является то, что мощность результата подзапроса должна быть не более единицы. Если хотя бы один из операндов операции сравнения имеет неопределенное значение или если правый операнд является подзапросом с пустым результатом, то значение предиката сравнения равняется unknown.
    Заметим, что значение арифметического выражения не определено, если в его вычислении участвует хотя бы одно неопределенное значение. Еще одно важное замечание из стандарта SQL/89: в контексте GROUP BY, DISTINCT и ORDER BY неопределенное значение выступает как специальный вид определенного значения, т.е. возможно, например, образование группы строк, значение указанного столбца которых является неопределенным. Для обеспечения переносимости прикладных программ нужно внимательно анализировать специфику работы с неопределенными значениями в конкретной СУБД.

    Расширения языка

    В языке, определяемом стандартом SQL/92, содержится много свойств, которые отсутствовали в языке SQL/89. Ниже приводится краткая сводка этих свойств.

    Несовместимости

    В стандарте SQL/92 содержится приложение, в котором устанавливаются несовместимости между SQL/92 и SQL/89. Формально SQL/92 не включает в себя полностью SQL/89, т. е. некоторые конструкции SQL/89 не соответствуют стандарту SQL/92. Конечно, при переходе от SQL/89 к SQL/92 нужно внимательно отнестись к этим несоответствиям. Однако, во-первых, эти несоответствия являются слишком техническими и непринципиальными, чтобы описывать их в этой статье. Во-вторых, ни один производитель СУБД никогда не пойдет на то, чтобы с использованием его нового продукта перестали работать ранее разработанные прикладные системы. Поэтому можно быть почти уверенным (или уверенной), что в реализациях SQL/89 по-прежнему будет поддерживаться. Так что по поводу несоответствий мы отсылаем читателя к тексту стандарта SQL/92.

    Предикат between

    Предикат between имеет следующий синтаксис:
    ::=[NOT] BETWEEN AND
    По определению результат "x BETWEEN y AND z" тот же самый, что результат логического выражения "x >= y AND x <= z". Результат "x NOT BETWEEN y AND z" тот же самый, что результат "NOT (x BETWEEN y AND z)".

    Предикат in

    Предикат in определяется следующими синтаксическими правилами:
    ::= [NOT] IN{ | ()} ::={,}...
    Типы левого операнда и значений из списка правого операнда (напомним, что результирующая таблица подзапроса должна содержать ровно один столбец)должны быть сравнимыми.
    Значение предиката равно true в том и только в том случае, когда значение левого операнда совпадает хотя бы с одним значением списка правого операнда. Если список правого операнда пуст (так может быть, если правый операнд задается подзапросом) или значение "подразумеваемого" предиката сравнения x = y (где x - значение арифметического выражения левого операнда)равно false для каждого элемента y списка правого операнда, то значение предиката in равно false. В противном случае значение предиката in равно unknown (например, так может быть, если значение левого операнда есть NULL).По определению значение предиката "x NOT IN S" равно значению предиката "NOT (x IN S)".

    Предикат like

    Предикат like имеет следующий синтаксис:
    ::= [NOT] LIKE [ESCAPE ] ::= ::=
    Типы данных столбца левого операнда и образца должны быть типами символьных строк. В разделе ESCAPE должен специфицироваться одиночный символ.
    Значение предиката равно true, если pattern является подстрокой заданного столбца. При этом если раздел ESCAPE отсутствует, то при сопоставлении шаблона со строкой производится специальная интерпретация двух символов шаблона: символ подчеркивания ("_") обозначает любой одиночный символ; символ процента ("%") обозначает последовательность произвольных символов произвольной длины (может быть, нулевой).
    Если же раздел ESCAPE присутствует и специфицирует некоторый одиночный символ x, то пары символов "x_" и "x%" представляют одиночные символы "_" и "%", соответственно.
    Значение предиката like есть unknown, если значение столбца либо шаблона не определено.
    Значение предиката "x NOT LIKE y ESCAPE z" совпадает со значением "NOT x LIKE y ESCAPE z".

    Предикат null

    Предикат null описывается синтаксическим правилом
    ::= IS [NOT] NULL
    Этот предикат всегда принимает значения true или false. При этом значение "x IS NULL" равно true тогда и только тогда, когда значение х не определено. Значение предиката "x NOT IS NULL" равно значению "NOT x IS NULL".

    Предикат с квантором

    Предикат с квантором имеет следующий синтаксис:
    ::= ::= | ::= ALL ::= SOME | ANY
    Обозначим через x результат вычисления арифметического выражения левой части предиката, а через S результат вычисления подзапроса.
    Предикат "x ALL S" имеет значение true, если S пусто или значение предиката "x s" равно true для каждого s, входящего в S. Предикат "x ALL S" имеет значение false, если значение предиката "x s" равно false хотя бы для одного s, входящего в S. В остальных случаях значение предиката "x ALL S" равно unknown.
    Предикат "x SOME S" имеет значение false, если S пусто или значение предиката "x s" равно false для каждого s, входящего в S. Предикат "x SOMES" имеет значение true, если значение предиката "x s" равно true хотя бы для одного s, входящего в S. В остальных случаях значение предиката "x SOME S" равно unknown.

    Предикат exists

    Предикат exists имеет следующий синтаксис:
    < exists predicate> ::=EXISTS
    Значением этого предиката всегда является true или false, и это значение равно true тогда и только тогда, когда результат вычисления подзапроса не пуст.

    Одной из проблем реализации языка

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

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

    Что касается управления транзакциями, то происходит возврат к старой идее System R о возможности установки внутри транзакции точек сохранения(savepoints). В операторе ROLLBACK можно указать идентификатор ранее установленной точки сохранения, и тогда будет произведен откат транзакции не к ее началу, а к этой точке сохранения.

    как видно, можно ожидать наличия в SQL-3 многих интересных и полезных возможностей. Однако даже промежуточные проекты стандарта включают почтив два раза больше страниц, чем стандарт SQL/92. Поэтому трудно ожидать быстрой реализации этого стандарта после его принятия (а многие вообще сомневаются, что этот стандарт будет когда-либо реализован).

    Оператор получения описания подготовленного оператора

    Оператор DESCRIBE предназначен для того, чтобы определить тип ранее подготовленного оператора, узнать количество и типы формальных параметров(если они есть) и количество и типы столбцов результирующей таблицы, если подготовленный оператор является оператором выборки (SELECT). Мы не приводим синтаксис оператора DESCRIBE, поскольку этот синтаксис мало что проясняет.
    Действие оператора DESCRIBE состоит в том, что в указанную область памяти прикладной программы (структура этой области фиксирована и известна пользователям)помещается информация, характеризующая ранее подготовленный оператор с заданным именем.

    РАЗДЕЛ WHERE

    Если в табличном выражении присутствует раздел WHERE, то далее вычисляется он. Синтаксис раздела WHERE следующий:
    ::=WHERE ::=| OR ::=| AND ::=[NOT] ::= | ()
    Вычисление раздела WHERE производится по следующим правилам: пусть R- результат вычисления раздела FROM. Тогда условие поиска (search condition)применяется ко всем строкам R, и результатом раздела WHERE является таблица, состоящая из тех строк R, для которого результатом вычисления условия поиска является true. Если условие выборки включает подзапросы, то каждый подзапрос вычисляется для каждого кортежа таблицы R (в стандарте используется термин "effectively" в том смысле, что результат должен быть таким, как если бы каждый подзапрос действительно вычислялся заново для каждого кортежа R, хотя реально это требуется далеко не всегда).
    Заметим, что поскольку SQL/89 допускает наличие в базе данных неопределенных значений, то вычисление условия поиска должно производиться не в булевой, а в трехзначной логике со значениями true, false и unknown (неизвестно).Для любого предиката известно, в каких ситуациях он может порождать значение unknown. Булевские операции AND, OR и NOT работают в трехзначной логике следующим образом:
    true AND unknown = unknownunknown AND true = unknownunknown AND unknown = unknowntrue OR unknown = trueunknown OR true = trueunknown OR unknown = unknownNOT unknown = unknown
    Среди предикатов условия поиска в соответствии с SQL/89 могут находиться следующие предикаты: предикат сравнения, предикат between, предикат in, предикат like, предикат null, предикат с квантором и предикат exists. Сразу заметим, что во всех реализациях SQL на эффективность выполнения запроса существенно влияет наличие в условии поиска простых предикатов сравнения(предикатов, задающих сравнение столбца таблицы с константой). Наличие таких предикатов позволяет СУБД использовать индексы при выполнении запроса, т.е. избегать полного просмотра таблицы. Хотя в принципе язык SQL дает возможность пользователям не заботиться о конкретном наборе предикатов в условии выборки (лишь бы они были синтаксически и семантически правильны),при реальном использовании SQL-ориентированных СУБД такие технические детали стоит иметь в виду.

    В этом разделе содержится краткая

    В этом разделе содержится краткая сводка различий между SQL/92 и SQL/89. Синтаксические и семантические детали конструкций SQL/92 не приводятся. Еще раз подчеркнем, что в изложении мы следуем книге Дейта "Стандарт SQL ".

    ВЫРАЖЕНИЕ ЗАПРОСОВ

    Выражение запросов - это выражение, строящееся по указанным синтаксическим правилам на основе спецификаций запросов. Единственной операцией, которую разрешается использовать в выражениях запросов SQL/89, является операция UNION (объединение таблиц) с возможной разновидностью UNION ALL. К таблицам-операндам выражения запросов предъявляется то требование, что все они должны содержать одно и то же число столбцов, и соответствующие столбцы всех операндов должны быть одного и того же типа. Выражение запросов вычисляется слева направо с учетом скобок. При выполнении операции UNION производится обычное теоретико-множественное объединение операндов, т.е. из результирующей таблицы удаляются дубликаты. При выполнении операции UNION ALL образуется результирующая таблица, в которой могут содержаться строки-дубликаты.

    СЕМАНТИКА АГРЕГАТНЫХ ФУНКЦИЙ

    Агрегатные функции предназначены для того, чтобы вычислять некоторое значение для заданного множества строк. Таким множеством строк может быть группа строк, если агрегатная функция применяется к сгруппированной таблице, или вся таблица. Для всех агрегатных функций, кроме COUNT(*), фактический(т. е. требуемый семантикой) порядок вычислений следующий: на основании параметров агрегатной функции из заданного множества строк производится список значений. Затем по этому списку значений производится вычисление функции. Если список оказался пустым, то значение функции COUNT для него есть 0, а значение всех остальных функций null.
    Пусть T обозначает тип значений из этого списка. Тогда результат вычисления функции COUNT - точное число с масштабом и точностью, определяемыми в реализации. Тип результата значений функций MAX и MIN совпадает с T. При вычислении функций SUM и AVG тип T не должен быть типом символьных строк, а тип результата функции - это тип точных чисел с определяемыми в реализации масштабом и точностью, если T - тип точных чисел и тип приблизительных чисел с определяемой в реализации точностью, если T - тип приблизительных чисел.
    Вычисление функции COUNT(*) производится путем подсчета числа строк в заданном множестве. Все строки считаются различными, даже если они состоят из одного столбца со значением null во всех строках.
    Если агрегатная функция специфицирована с ключевым словом DISTINCT, то список значений строится из значений указанного столбца. (Подчеркнем, что в этом случае не допускается вычисление арифметических выражений!)Далее из этого списка удаляются неопределенные значения, и в нем устраняются значения-дубликаты. Затем вычисляется указанная функция.
    Если агрегатная функция специфицирована без ключевого слова DISTINCT(или с ключевым словом ALL), то список значений формируется из значений арифметического выражения, вычисляемого для каждой строки заданного множества. Далее из списка удаляются неопределенные значения, и производится вычисление агрегатной функции. Обратите внимание, что в этом случае не допускается применение функции COUNT!
    Замечание: оба ограничения, указанные в двух предыдущих абзацах, являются более техническими, чем принципиальными, и могут отсутствовать в конкретных реализациях. Тем не менее это ограничения стандарта SQL/89, и их нужно придерживаться при мобильном программировании.

    РЕЗУЛЬТАТЫ ЗАПРОСОВ

    Агрегатные функции можно разумно использовать в спецификации курсора, операторе выборки и подзапросе после ключевого слова SELECT (будем называть в этом подразделе все такие конструкции списком выборки, не забывая о том, что в случае подзапроса этот список состоит только из одного элемента), и в условии выборки раздела HAVING. Стандарт допускает более экзотические случаи использования агрегатных функций в подзапросах (агрегатная функция на группе кортежей внешнего запроса), но на практике они встречаются очень редко.
    Рассмотрим различные случаи применения агрегатных функций в списке выборки в зависимости от вида табличного выражения.
    Если результат табличного выражения R не является сгруппированной таблицей, то появление хотя бы одной агрегатной функции от множества строк R в списке выборки приводит к тому, что R неявно рассматривается как сгруппированная таблица, состоящая из одной (или нуля) групп с отсутствующими столбцами группирования. Поэтому в этом случае в списке выборки не допускается прямое использование спецификаций строк R: все они должны находиться внутри спецификаций агрегатных функций. Результатом запроса является таблица, состоящая не более чем из одной строки, полученной путем применения агрегатных функций к R.
    Аналогично обстоит дело в том случае, когда R представляет собой сгруппированную таблицу, но табличное выражение не содержит раздела GROUP BY (и, следовательно, содержит раздел HAVING). Если в предыдущем случае существовало два варианта формирования списка выборки: только с прямым указанием столбцов R или только с указанием их внутри спецификаций агрегатных функций, то в данном случае возможен только второй вариант. Результат табличного выражения явно объявлен сгруппированной таблицей, состоящей из одной группы, и результат запроса можно формировать только путем применения агрегатных функций к этой группе строк. Опять результатом запроса является таблица, состоящая не более чем из одной строки, полученной путем применения агрегатных функций к R.
    Наконец, рассмотрим случай, когда R представляет собой "настоящую" сгруппированную таблицу, т. е. табличное выражение содержит раздел GROUPBY и, следовательно, определен по крайней мере один столбец группирования. В этом случае правила формирования списка выборки полностью соответствуют правилам формирования условия выборки раздела HAVING: допускается прямое использование имен столбцов группирования, а имена остальных столбцов R могут появляться только внутри спецификаций агрегатных функций. Результатом запроса является таблица, число строк в которой равно числу групп в R, и каждая строка формируется на основе значений столбцов группирования и агрегатных функций для данной группы.

    Агрегатные функции и результаты запросов

    Агрегатные функции (в стандарте SQL/89 они называются функциями надмножествами) определяются следующими синтаксическими правилами:
    ::=COUNT(*) | | ::={ AVG | MAX | MIN | SUM | COUNT }(DISTNICT ) ::={ AVG | MAX | MIN | SUM }([ALL] )
    Как видно из этих правил, в стандарте SQL/89 определены пять стандартных агрегатных функций: COUNT - число строк или значений, MAX - максимальное значение, MIN - минимальное значение, SUM - суммарное значение и AVG -среднее значение.

    Оператор выполнения подготовленного оператора

    Оператор EXECUTE служит для выполнения ранее подготовленного оператора SQL типа "N" (не требующего применения курсора) или для совмещенной подготовки и выполнения такого оператора. Синтаксис оператора EXECUTE:
    ::=EXECUTE{ [USING ]| IMMEDIATE }
    Для выполнения подготовленного оператора служит первый вариант оператора EXECUTE. В этом случае должен задавать имя, употреблявшееся ранее в операторе PREPARE. Если в подготовленном операторе присутствуют формальные параметры, то в операторе EXECUTE должен задаваться список фактических параметров . Число и типы фактических параметров должны соответствовать числу и типам формальных параметров подготовленного оператора.
    Второй вариант оператора EXECUTE предназначен для совмещенной подготовки и выполнения оператора SQL типа "N". В этом случае параметром оператора EXECUTE является строка, которая должна содержать текст оператора SQL (эту строку разрешается также задавать литерально). Запрещается использование в этом операторе переменных включающей программы (формальных параметров).

    РАЗДЕЛ GROUP BY

    Если в табличном выражении присутствует раздел GROUP BY, то далее выполняется он. Синтаксис раздела GROUP BY следующий:
    < group by clause> ::=GROUP BY [{, }...]
    Если обозначить через R таблицу, являющуюся результатом предыдущего раздела (FROM или WHERE), то результатом раздела GROUP BY является разбиение R на множество групп строк, которое состоит из минимального числа таких групп, в которых для каждого столбца из списка столбцов раздела GROUP BY во всех строках каждой группы, включающей более одной строки, значения этого столбца совпадают. Для обозначения результата раздела GROUP BY в стандарте используется термин "сгруппированная таблица".

    РАЗДЕЛ ORDER BY

    Наконец, раздел ORDER BY позволяет установить желаемый порядок просмотра результата выражения запросов. Синтаксис ORDER BY следующий:
    ::=ORDER BY [{,}...] ::={ | }[ASC | DESC]
    Как видно из этих синтаксических правил, фактически задается список столбцов результата выражения запросов, и для каждого столбца указывается порядок просмотра строк результата в зависимости от значений этого столбца(ASC - по возрастанию (умолчание), DESC - по убыванию). Столбцы можно задавать их именами тогда и только тогда, когда (1) выражение запросов не содержит операций UNION или UNION ALL и (2) в списке выборки спецификации запроса этому столбцу соответствует арифметическое выражение, состоящее только из имени столбца. Во всех остальных случаях в разделе ORDER BY должен указываться порядковый номер столбца в таблице-результате выражения запросов.

    Оператор определения схемы

    В соответствии с правилами SQL/89 каждая таблица данной БД имеет простое и квалифицированное (уточненное) имена. В качестве квалификатора имени выступает "идентификатор полномочий" таблицы, который обычно в реализациях совпадает с именем некоторого пользователя. Квалифицированное имя таблицы имеет вид:
    <идентификатор полномочий>. <простое имя>
    Подход к определению схемы в SQL/89 состоит в том, что все таблицы с одним идентификатором полномочий создаются (определяются) путем выполнения одного оператора определения схемы. При этом в стандарте не определяется способ выполнения оператора определения схемы: должен ли он выполняться только в интерактивном режиме или может быть встроен в программу, написанную на традиционном языке программирования. (Собственно, поэтому трудно говорить о том, поддерживается ли в конкретной реализации стандарт SQL/89 в части средств определения схемы БД. )
    В операторе определения схемы содержится идентификатор полномочий и список элементов схемы, каждый из которых может быть определением таблицы, определением представления (view) или определением привилегий. Каждое из этих определений представляется отдельным оператором SQL/89, но все они, как уже говорилось, должны быть встроены в оператор определения схемы.
    Для этих операторов мы приведем синтаксис, поскольку это позволит более четко описать их особенности.

    ОПРЕДЕЛЕНИЕ СТОЛБЦА

    Оператор определения столбца описывается следующими синтаксическими правилами:
    ::= [][. . . ] ::=DEFAULT { | USER | NULL } ::=NOT NULL []| | CHECK ()
    Как видно, кроме обязательной части, в которой задается имя столбца и его тип данных, определение столбца может содержать два необязательных раздела: раздел значения столбца по умолчанию и раздел ограничений целостности столбца.
    В разделе значения по умолчанию указывается значение, которое должно быть помещено с строку, заносимую в данную таблицу, если значение данного столбца явно не указано. значение по умолчанию может быть указано в виде литеральной константы с типом, соответствующим типу столбца; путем задания ключевого слова USER, которому при выполнении оператора занесения строки соответствует символьная строка, содержащая имя текущего пользователя (в этом случае столбец должен иметь тип символьных строк); или путем задания ключевого слова NULL, означающего, что значением по умолчанию является неопределенное значение. Если значение столбца по умолчанию не специфицировано, и в разделе ограничений целостности столбца указано NOT NULL (т. е. наличие неопределенных значений запрещено), то попытка занести в таблицу строку с не специфицированным значением данного столбца приведет к ошибке.
    Указание в разделе ограничений целостности NOT NULL приводит к неявному порождению проверочного ограничения целостности для всей таблицы (см. п. 2. 4. 2. 2) "CHECK (C IS NOT NULL)" (где C - имя данного столбца). Если ограничение NOT NULL не указано, и раздел умолчаний отсутствует, то неявно порождается раздел умолчаний DEFAULT NULL. Если указана спецификация уникальности, то порождается соответствующая спецификация уникальности для таблицы.
    Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца (), то порождается соответствующее определение ограничения по ссылкам для таблицы: FOREIGN KEY(C) .
    Наконец, если указано проверочное ограничение столбца, то условие поиска этого ограничения должно ссылаться только на данный столбец и неявно порождается соответствующее проверочное ограничение для всей таблицы.

    Ограничение уникальности

    Каждое имя столбца в списке уникальности должно именовать столбец T и не должно входить в этот список более одного раза. При определении столбца, входящего в список уникальности, должно быть указано ограничение столбца NOT NULL. Среди ограничений уникальности T не должно быть более одного определения первичного ключа (ограничения уникальности с ключевым словом PRIMARY KEY).
    Действие ограничения уникальности состоит в том, что в таблице T не допускается появление двух или более строк, значения столбцов уникальности которых совпадают.

    Ограничение по ссылкам

    Ограничение по ссылкам от заданного набора столбцов CT таблицы T на заданный набор столбцов CT1 некоторой определенной, к этому моменту таблицыT1 задает условие на содержимое обеих этих таблиц, при котором ссылки можно считать корректными.
    Если список столбцов CT1 явно специфицирован в определении ограничения по ссылкам, то требуется, чтобы этот список явно входил в какое-либо определение уникальности таблицы T1. Если же список CT1 не специфицирован явно в определении ограничения по ссылкам таблицы T, то требуется, чтобы в определении таблицыT1 присутствовало определение первичного ключа, и список CT1 неявно полагается совпадающим со списком имен столбцов из определения первичного ключа таблицыT1. Имена столбцов списков CT и CT1 должны именовать столбцы таблиц T иT1, соответственно, и не должны появляться в списках более одного раза. Списки столбцов CT и CT1 должны содержать одинаковое число элементов, и столбец таблицы T, идентифицируемый i-м элементом списка CT должен иметь тот же тип, что столбец таблицы T1, идентифицируемый i-м элементом спискаCT1.
    По определению таблицы T и T1 удовлетворяют заданному ограничению по ссылкам, если для каждой строки s таблицы T такой, что все значения столбцов s, идентифицируемых списком CT, не являются неопределенными, существует строка s1 таблицы T1 такая, что значения столбцов s1, идентифицируемых списком CT1, позиционно равны значениям столбцов s, идентифицируемых списком CT. По-человечески это можно сформулировать так: ограничение по ссылкам удовлетворяется, если для каждой корректной ссылки существует объект, на который она ссылается. В привычной программистам терминологии, ограничение по ссылкам не позволяет производить "висячие" ссылки, не ведущие ни к какому объекту.

    Проверочное ограничение

    Проверочное ограничение специфицирует условие, которому должна удовлетворять в отдельности каждая строка таблицы T. Это условие не должно содержать подзапросов, спецификаций агрегатных функций, а также ссылок на внешние переменные или параметров. В него могут входить только имена столбцов данной таблицы и литеральные константы.
    Таблица удовлетворяет проверочному ограничению целостности в том и только в том случае, когда вычисление условия для каждой строки таблицы дает true.
    Замечание: в некоторых реализациях допускаются расширенные механизмы ограничений по ссылкам и проверочных ограничений. Следует быть внимательным, если не хотите выходить за пределы возможностей стандарта.

    ОПРЕДЕЛЕНИЕ ОГРАНИЧЕНИЙ ЦЕЛОСНОСТИ ТАБЛИЦЫ

    Раздел определения ограничений целостности таблицы обладает следующим синтаксисом:
    ::=| | ::= () ::=UNIQUE | PRIMARY KEY ::= [{, }. . . ] ::=FOREIGN KEY () ::=REFERENCES ::= ::=
    [()] ::= [{, }. . . ] ::=CHECK ()
    Для одной таблицы может быть задано несколько ограничений целостности, в том числе те, которые неявно порождаются ограничениями целостности столбцов. Стандарт SQL/89 устанавливает, что ограничения таблицы фактически проверяются при выполнении каждого оператора SQL.
    Замечание: наличие правильно подобранного набора ограничений БД очень важно для надежного функционирования прикладной информационной системы. Вместе с тем в некоторых СУБД ограничения целостности практически не поддерживаются. Поэтому при проектировании прикладной системы необходимо принять решение о том, что более существенно: рассчитывать на поддержку ограничений целостности, но ограничить набор возможных СУБД или отказаться от их использования на уровне SQL, сохранив возможность применения не самых современных СУБД.
    Далее T обозначает таблицу, для которой определяются ограничения целостности.

    Определение таблицы

    Оператор определения таблицы имеет следующий синтаксис:
    ::=CREATE TABLE
    (
    [{,
    }. . . ])
    ::=|

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

    Определение представлений

    Механизм представлений (view) является мощным средством языка SQL, позволяющим скрыть реальную структуру БД от некоторых пользователей за счет определения представления БД, которое реально является некоторым хранимым в БД запросом с именованными столбцами, а для пользователя ничем не отличается от базовой таблицы БД (с учетом технических ограничений). Любая реализация должна гарантировать, что состояние представляемой таблицы точно соответствует состоянию базовых таблиц, на которых определено представление. Обычно вычисление представляемой таблицы (материализация соответствующего запроса) производится каждый раз при использовании представления.
    В стандарте SQL/89 оператор определения представления имеет следующий синтаксис:
    ::=CREATE VIEW
    [()]AS [WITH CHECK OPTION] ::= [{, }. . . ]
    Определяемая представляемая таблица V является изменяемой (т. е. по отношению к V можно использовать операторы DELETE и UPDATE) в том и только в том случае, если выполняются следующие условия для спецификации запроса:
  • в списке выборки не указано ключевое слово DISTINCT;
  • каждое арифметическое выражение в списке выборки представляет собой одну спецификацию столбца, и спецификация одного столбца не появляется более одного раза;
  • в разделе FROM указана только одна таблица, являющаяся либо базовой таблицей, либо изменяемой представляемой таблицей;
  • в условии выборки раздела WHERE не используются подзапросы;
  • в табличном выражении отсутствуют разделы GROUP BY и HAVING.

    • Замечание: эти ограничения являются очень сильными. В реализациях они могут быть ослаблены. Но если стремиться к мобильности, не следует пользоваться расширенными возможностями.
    Если в списке выборки спецификации запроса имеется хотя бы одно арифметическое выражение, состоящее не из одной спецификации столбца, или если имя хотя бы одного столбца участвует в списке выборки более одного раза, определение представления должно содержать список имен столбцов представляемой таблицы. Более просто, нужно явно именовать столбцы представляемой таблицы, если эти имена не наследуются от столбцов таблиц раздела FROM спецификации запроса.
    Требование WITH CHECK OPTION в определении представления имеет смысл только в случае определения изменяемой представляемой таблицы, которая определяется спецификацией запроса, содержащей раздел WHERE. При наличии этого требования не допускаются изменения представляемой таблицы, приводящие к появлению в базовых таблицах строк, не видимых в представляемой таблице(т. е. таких строк, которые не удовлетворяют условию поиска раздела WHERE спецификации запроса). Если WITH CHECK OPTION в определении представления отсутствует, такой контроль не производится.

    Определение привилегий

    В соответствии с идеологией языка SQL контроль прав доступа данного пользователя к таблицам БД производится на основе механизма привилегий. Фактически, этот механизм состоит в том, что для выполнения любого действия над таблицей пользователь должен обладать соответствующей привилегией (реально все возможные действия описываются фиксированным стандартным набором привилегий). Пользователь, создавший таблицу, автоматически становится владельцем всех возможных привилегий на выполнение операций над этой таблицей. В число этих привилегий входит привилегия на передачу всех или некоторых привилегий по отношению к данной таблице другому пользователю, включая привилегию на передачу привилегий. Иногда поддерживается и обратная операция изъятия привилегий от пользователя, ранее их получившего.
    В SQL/89 определяется упрощенная схема механизма привилегий. Во-первых, "раздача" привилегий возможна только при определении таблицы. Во-вторых, пользователь, получивший некоторые привилегии от других пользователей, может передать их дальше только при определении схемы.
    Оператор определения привилегий обладает следующим синтаксисом:
    ::=GRANT ON
    TO [{, }. . . ][WITH GRANT OPTION] ::=ALL PRIVILEGES| [{, }. . . ] ::=SELECT | INSERT | DELETE| UPDATE [()]| REFERENCES [(] ::= [{, }. . . ] ::=PUBLIC |
    Эти синтаксические правила достаточно ясно показывают смысл механизма определения привилегий в SQL/89. Заметим лишь, что необходимо обладать привилегией REFERENCES по отношению к указанным столбцам таблицы T1, чтобы иметь возможность при определении таблицы T специфицировать ограничение по ссылкам между этой таблицей и существующей к этому моменту таблицейT1.
    Еще раз заметим, что, хотя в общем смысле во всех SQL-ориентированныхСУБД поддерживается механизм защиты данных на основе привилегий доступа, реализации могут различаться в деталях. Это опять то место, которое нужно локализовывать, если стремиться к созданию мобильной прикладной системы.

    Работа с динамическими операторами SQL через курсоры

    Для использования таких операторов используется расширение механизма курсоров стандарта SQL. Во-первых, при определении курсора можно указывать не только литеральную спецификацию курсора, но и имя оператора, вводимое с помощью оператора PREPARE (в этом случае оператор PREPARE должен текстуально находиться выше оператора DECLARE). Тем самым полный синтаксис оператора DECLARE становится следующим:
    ::=DECLARE CURSORFOR { | }
    Далее, поскольку для такого курсора в статике неизвестна информация о входных и выходных переменных включающей программы, то используется другая форма операторов OPEN и FETCH.
    Полный синтаксис этих операторов становится следующим:
    ::=OPEN [USING { | DESCRIPTOR }] ::=FETCH { INTO |USING |USING DESCRIPTOR }
    как видно, предлагается два способа задания фактических входных и выходных параметров: прямое с указанием в операторах OPEN и/или FETCH списков имен переменных включающей программы и косвенное, когда число параметров и их адреса сообщаются через дополнительную структуру-дескриптор.
    Первый способ предлагается использовать для работы с операторами выборки, для которых фиксирован набор формальных входных и выходных параметров. Точнее говоря, что касается выходных параметров, должны быть фиксированы число и типы элементов списка выборки.
    Второй способ работы с динамически откомпилированными операторами, требующими использования курсоров, состоит в использовании дескрипторов динамически формируемых списков параметров. В этом случае вся ответственность за соответствие типов фактических и формальных параметров ложится на программиста. В результате ошибки при формировании такого списка, в частности, может быть испорчена память Си-программы.

    РАЗДЕЛ HAVING

    Наконец, последним при вычислении табличного выражения используется раздел HAVING (если он присутствует). Синтаксис этого раздела следующий:
    ::=HAVING
    Раздел HAVING может осмысленно появиться в табличном выражении только в том случае, когда в нем присутствует раздел GROUP BY. Условие поиска этого раздела задает условие на группу строк сгруппированной таблицы. Формально раздел HAVING может присутствовать и в табличном выражении, не содержащем GROUP BY. В этом случае полагается, что результат вычисления предыдущих разделов представляет собой сгруппированную таблицу (правильнее сказать, псевдосгруппированную), состоящую из одной группы без выделенных столбцов группирования.
    Условие поиска раздела HAVING строится по тем же синтаксическим правилам, что и условие поиска раздела WHERE, и может включать те же самые предикаты. Однако имеются специальные синтаксические ограничения по части использования в условии поиска спецификаций столбцов таблиц из раздела FROM данного табличного выражения. Эти ограничения следуют из того, что условие поиска раздела HAVING задает условие на целую группу, а не на индивидуальные строки.
    Поэтому в арифметических выражениях предикатов, входящих в условие выборки раздела HAVING, прямо можно использовать только спецификации столбцов, указанных в качестве столбцов группирования в разделе GROUP BY. Остальные столбцы можно специфицировать только внутри спецификаций агрегатных функций COUNT, SUM, AVG, MIN и MAX, вычисляющих в данном случае некоторое агрегатное значение для всей группы строк. Аналогично обстоит дело с подзапросами, входящими в предикаты условия выборки раздела HAVING: если в подзапросе используется характеристика текущей группы, то она может задаваться только путем ссылки на столбцы группирования.
    Результатом выполнения раздела HAVING является сгруппированная таблица, содержащая только те группы строк, для которых результат вычисления условия поиска есть true. В частности, если раздел HAVING присутствует в табличном выражении, не содержащем GROUP BY, то результатом его выполнения будет либо пустая таблица, либо результат выполнения предыдущих разделов табличного выражения, рассматриваемый как одна группа без столбцов группирования.

    Средства определения схемы

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

    ОПРЕДЕЛЕНИЕ ПРОЦЕДУРЫ

    Процедуры в модуле SQL определяются в следующем синтаксисе:
    ::=PROCEDURE . . . ;< SQL statement>;::= | < SQLCODE parameter>< SQLCODE parameter> ::= SQLCODE< SQL statement> ::=| | | | | | | |
    WHERE CURRENT OF
    Если указанный в операторе курсор открыт и установлен на некоторую строку, и курсор определяет изменяемую таблицу, то текущая строка курсора удаляется, а он позиционируется перед следующей строкой. Таблица, указанная в разделе FROM оператора DELETE, должна быть таблицей, указанной в самом внешнем разделе FROM спецификации курсора.

    ОПЕРАТОР ПОЗИЦИОННОЙ МОДИФИКАЦИИ

    Оператор описывается следующими синтаксическими правилами:
    ::=UPDATE
    SET [{, }. . . ]WHERE CURRENT OF ::= ={ | NULL } ::=
    Если указанный в операторе курсор открыт и установлен на некоторую строку и курсор определяет изменяемую таблицу, то текущая строка курсора модифицируется в соответствии с разделом SET. Позиция курсора не изменяется. Таблица, указанная в разделе FROM оператора DELETE, должна быть таблицей, указанной в самом внешнем разделе FROM спецификации курсора.
    Замечание: требование указывать имя таблицы в операторах позиционного удаления и позиционной модификации является, очевидно, избыточным, поскольку до имени таблицы можно добраться через имя курсора. Единственной возможной причиной этой избыточности может быть упрощение реализации (хотя не очень понятно, что именно упрощается).

    ОПЕРАТОР ЗАКРЫТИЯ КУРСОРА

    Синтаксис этого оператора следующий:
    ::=CLOSE
    Если к моменту выполнения этого оператора курсор находился в открытом состоянии, то оператор переводит курсор в закрытое состояние. После этого над курсором возможно выполнение только оператора OPEN.

    Операторы, связанные с курсором

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

    ОПЕРАТОР ВЫБОРКИ

    Для удобства читателей мы повторяем синтаксис этого оператора еще раз:
    INTO
    WHERE []
    Таблица T, указанная в разделе FROM оператора DELETE, должна быть изменяемой. На условие поиска накладывается то условие, что на столбцы таблицы T не должны содержаться ссылки ни в как ом вложенном подзапросе предикатов раздела WHERE.
    Фактически, оператор выполняется следующим образом: последовательно просматриваются все строки таблицы T, и те строки, для которых результатом вычисления условия выборки является true, удаляются из таблицы T. При отсутствии раздела WHERE удаляются все строки таблицы T (обычно при выполнении поискового оператора DELETE без раздела WHERE в интерактивном режиме до удаления всех строк запрашивается подтверждение правильности такого действия).

    ОПЕРАТОР ПОИСКОВОЙ МОДИФИКАЦИИ

    Оператор обладает следующим синтаксисом:
    ::=UPDATE
    SET [{, }. . . ][WHERE ] ::= ={ | NULL } ::=
    Таблица T, указанная в операторе UPDATE, должна быть изменяемой. На условие поиска накладывается то условие, что на столбцы таблицы T не должны содержаться ссылки ни в как ом вложенном подзапросе предикатов раздела WHERE.
    Оператор фактически выполняется следующим образом: таблица T последовательно просматривается, и каждая строка, для которой результатом вычисления условия поиска является true, изменяется в соответствии с разделом SET. Если арифметическое выражение в разделе SET содержит ссылки на столбцы таблицы T, то при вычислении арифметического выражения используются значения столбцов текущей строки до их модификации.

    Одиночные операторы манипулирования данными

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

    Операторы окончания транзакции

    Текущая транзакция может быть завершена успешно (с фиксацией в базе данных произведенных изменений) путем выполнения оператора COMMIT WORK или аварийно (с удалением из базы данных изменений, произведенных текущей транзакцией) путем выполнения оператора ROLLBACK WORK. При выполнении любого из этих операторов производится принудительное закрытие всех курсоров, открытых к моменту выполнения оператора завершения транзакции.

    Набор операторов манипулирования данными

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

    А теперь про нечто полностью вычислительное

    К. Дж. Дейт
    Перевод -
    Оригинал: And Now for Something Completely Computational
    В некотором роде эта статья является продолжением, уточнением и развитием первой статьи цикла "Обсуждение некоторых критических замечаний в адрес Третьего Манифеста" «Гедель, Рассел, Кодд: Рекурсивная золотая чехарда». Что такое вычислительная полнота языка? Как связаны вычислительная полнота и неразрешимость? Полезна или вредна вычислительная полнота языка баз данных? Знал ли обо всех этих проблемах родоначальник реляционных баз данных Кодд? Обо всем этом в присущей ему полемической манере, но, как всегда, четко и убедительно пишет Крис Дейт.
    С.Д. Кузнецов
    И я когда-то к магам и святым

    Ходил, познанья жаждою томим,

    Я им внимал; но уходил всегда

    Чрез ту же дверь, как и являлся к ним.

    Эдвард Фитцджеральд. ХАЙЯМИАДА (поэма).
    Перевод: О. Румер

    Адаптеры объектов.

    Адаптер объектов - это первичный путь для обеспечения сервиса конкретной реализацией объекта. Предполагается, что имеется несколько адаптеров объектов, каждый из которых обеспечивает доступ к объектам определенного вида.
    Сервисы, которые обеспечиваются ORB-ом посредством адаптеров объектов часто включают: генерацию и интерпретацию ссылок на объекты, вызов методов, активацию и деактивацию реализаций объектов, а также регистрацию конкретных реализаций и отображение объектных ссылок и реализаций.
    Информация, которая находится в каждом из хранилищ может быть произвольно изменена в любой момент времени с помощью методов, обеспечиваемых реализацией ORB-а. Однако, неосторожное изменение, сделанное во время работы может привести нарушить целостность информации, находящейся в каждом из хранилищ и сделать невозможным дальнейшее функционирование ORB-а.

    Активные базы данных и системы правил

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

    Анализ вклада Кодда в Великий Спор

    An Analysis of Codd's Contribution to the Great Debate
    C.J. Date
    ()
    Великий Спор являлся спором между сторонниками реляционного и сетевого подходов. Он происходил во время ACM SIGMOD Workshop on Data Description, Access, and Control в 1974 г.; основными докладчиками были Эдгар Ф. Кодд в пользу реляционного подхода (поразительно!) и Чарльз В. Бахман в пользу сетевого подхода, или подхода CODASYL. В процессе подготовки обсуждения Кодд написал статью под названием "Интерактивная поддержка непрограммистов: реляционный и сетевой подходы" [1], и именно эта статья обсуждается в данной заметке.
    Замечание: официально авторами статьи числятся Кодд и Дейт, однако на самом деле статья целиком написана Коддом. (И наоборот, статья с соображениями о прикладном программировании [2], авторами которой числятся те же два автора, была написана Дейтом.)

    Аннотация

    В нашем с Хью Дарвеном Третьем Манифесте (для краткости, просто «Манифесте») устанавливается набор предписаний и запретов, которые касаются разработки языка программирования баз данных, называемого D (см. [9]). В частности, одно из предписаний – «ОО-предписание 3» – звучит следующим образом:
    D должен быть вычислительно полным. Это значит, что в D может поддерживаться механизм вызовов из так называемых основных (host) программ, написанных на языках, отличных от D (но эта поддержка не является обязательной). Аналогично, в D может поддерживаться использование других языков для реализации операций, определяемых пользователями (но эта поддержка не является обязательной).
    Однако в [1] утверждается, что из этого предписания следует серьезная ущербность Манифеста. В этом источнике говорится следующее:
    Придание вычислительной полноты языку Tutorial D является ошибочным решением, поскольку это приводит к созданию языка, логические выражения которого могут быть неразрешимыми, – хотя для любого логического выражения должен существовать алгоритм, позволяющий его вычислить.
    Замечание: В этой цитате упоминается Tutorial D, а не D как таковой, и поэтому я должен пояснить, как соотносятся Tutorial D и D. Начнем с того, что имя D является родовым – оно используется в [9] для обозначения любого языка, соответствующего принципам, заложенным в Третьем Манифесте. Таким образом, может иметься любое число различных языков, квалифицируемых как допустимый D. Подразумевается, что Tutorial D является одним из таких языков; он более или менее формально определяется в [9] и используется во всей этой книге (и в других публикациях) как основа примеров. В настоящей статье для определенности я сосредотачиваюсь (большей частью) на Tutorial D (как и автор [1]), но обсуждение и используемые аргументы применимы к любому допустимому D.

    Эта статья является ответом на некоторые критические замечания, которые были сделаны в адрес (a) Третьего Манифеста – см. [4] – и (b) языка Tutorial D, который используется в [4] для иллюстрации идей Третьего Манифеста. Эти критические замечания появились в [6] и могут быть кратко изложены следующим образом: В Третьем Манифесте вообще и в Tutorial D, в частности, допускается построение выражений, которые являются парадоксальными и потому неразрешимыми.


    Программное обеспечение (ПО) Domino и Notes компании Lotus Development, подразделение корпорации IBM, является одной из наиболее распространённых технологических платформ в качестве инструментария совместной работы (Groupware), и как ПО электронной передачи сообщений (Email), календарного планирования (Scheduling), корпоративной интегрированной среды функционирования Internet-приложений (Internet/Intranet application server). Однако, по мере роста зависимости организации от приложений, функционирующих в корпоративной среде Lotus Domino/Notes, и сложности самих приложений, стоимость поддержки и модернизации информационной системы (ИС) нелинейно повышается, а удовлетворенность ей на всех уровнях организационной иерархии и во всех подразделениях неуклонно снижается. В статье рассматриваются основные причины этого процесса, а также типичные ошибки при проектировании ИС вообще и в среде Lotus Domino/Notes в частности, которые приводят к снижению производительности труда пользователей, замедлению окупаемости ИС и т. д., то есть, в итоге, к финансовым потерям.
    Статья адресована разработчикам ИС, ПО в среде Lotus Domino/Notes и их заказчикам.


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


    В [1] два автора, именуемые далее Критиками A и B, критикуют Третий Манифест за поддержку реляционных переменных и реляционного присваивания. Эта статья является ответом на эту критику. Ожидается осведомленность читателей со следующими понятиями и терминам:
  • Реляционная переменная (relation variable, сокращенно relvar) – это переменная, допустимыми значениями которой являются значения отношений (для краткости, отношения).
  • Реляционное присваивание – это операция, при выполнении которой некоторое отношение r присваивается некоторой relvar R.
    В [14] эти понятия разъясняются подробно с использованием языка Tutorial D в качестве основы примеров.



  • Язык XQuery - это универсальный язык запросов к XML-данным, содержащий средства как для выборки, так и для трансформации XML-данных. В статье анализируется ограниченность средств трансформации XML-данных языка XQuery. Демонстрируется важный на практике класс запросов, для которых выражения на языке XQuery громоздки и сложны для эффективного вычисления.
    В данной работе для этого класса запросов предлагается расширение языка XQuery функциональными update-выражениями. Такие выражения близки по синтаксису к выражениям языков модификации XML-данных, но вычисляются без побочных эффектов, что позволяет естественным образом интегрировать их в среду XQuery.
    В статье демонстрируется выразительность расширенного языка и рассматриваются подходы к эффективной реализации предложенного расширения. В последнем разделе статьи обсуждается проблема интеграции языковых средств выборки и модификации XML-данных (проблема вложенных update-выражений). Мы показываем, каким образом идея функциональных update-выражений может быть применена для решения этой проблемы.

    Анотация

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

    Архитектура

    Рассмотрим классическую архитектуру, которая чаще всего реализована на корпоративных сайтах и информационных порталах. Такая архитектура изображена на рис. 1.
    Архитектура

    Рис.1
    Разберем по частям то, что изображено на рисунке. Существует клиентская вычислительная машина под управлением ОС Windows и существует Web-сервер под управлением UNIX-подобной ОС. На стороне клиента запущен типичный браузер, такой как Netscape. На стороне сервера запущен web сервер, который обслуживает запросы от браузера, передавая запросы презентационному слою понимающему CGI. Презентационный слой передает запросы к поисковому механизму в случае вызова услуги поиска или отображает наполнение ( content) сайта. При работе администратора презентационный слой также может передавать запросы на инициализацию механизма индексации нового контента, который еще не индексирован. Это необходимо по той причине, что пока текст не индексирован, поиск в нем с помощью поисковой машины невозможен.
    Идея заключается в следующем. Существуют мегабайты текстовой информации, и скорость поиска документов содержащих заданные ключевые слова отнимает очень много процессорного времени. Предположим, в 10 мегабайтах текстовой информации ключевое слово будет находиться в течение 10 секунд. И вот заходит посетитель на Ваш сайт, задает ключевые слова, вызывает услугу поиска и ждет 10 секунд, пока ваш сервер не выдаст ему результат. Предположим, случилось так, что одновременно запросило поиск 5 человек. Естественно, время ответа увеличится в 5 раз. Получается, что в среднем по 50 секунд пользователь будет ждать ответа от вашего сервера. Это не приемлемо, особенно если у Вас сотни мегабайт текстовой информации и время реакции системы будет катастрофически велико. Необходимо использовать другой подход при поиске ключевых слов в текстовой информации - время ответа сократить до миллисекунд.

    Архитектурная независимость.

    Спецификация GIOP делает минимальные предположения об архитектуре агентов, которые поддерживают обмен данными по этому протоколу. Спецификация GIOP считает ORB некой системой с неизвестной архитектурой.
    Подход конкретного ORB-а к обеспечению поддержки протокола GIOP/IIOP не определен. Например, ORB может принять IIOP в качестве внутреннего протокола, использовать его только для внешнего обмена, используя для обмена в рамках самого ORB-а какие-то дополнительные средства коммуникации или выбрать нечто среднее между этими двумя крайностями. Все что требуется от ORB-а - это чтобы существовало нечто способное принимать и отправлять сообщения по протоколу IIOP.

    Асиломарский отчет об исследованиях в области баз данных

    Фил Бернштейн, Майкл Броуди, Стефано Чери, Дэвит Девитт, Майк Франклин, Гектор Гарсиа-Молина, Джим Грей, Джерри Хелд, Джо Хеллерстейн, Х.М. Ягадиш, Майкл Леск, Дейв Майер, Джеф Науфтон, Хамид Пиранеш, Майк Стоунбрейкер, Джеф Ульман
    Перевод: Сергей Кузнецов
    Оригинал: Phil Bernstein, Michael Brodie, Stefano Ceri, David DeWitt, Mike Franklin, Hector Garcia-Molina, Jim Gray, Jerry Held, Joe Hellerstein, H.V. Jagadish, Michael Lesk, Dave Maier, Jeff Naughton, Hamid Piranesh, Mike Stonebraker, and Jeff Ullman.The Asilomar Report on Database Research, SIGMOD Record, V. 27, N. 4, December, 1998.

    Ассоциативные качества. Ссылки.

    Межобъектные ассоциации представляются в модели "объект-качество" точно так же как и любая другая информация об объектах, то есть как качество. В дальнейшем мы будем называть такое качество ассоциативным. На уровне представления такое ассоциативное качество в самом общем виде может быть описано как отношение Qa со схемой [DOID:ref1 .... DOID:refi, Dj,...,Dn] где ref1 .... refi атрибуты, содержащие OID ассоциированных объектов (т.е. эти атрибуты определены на домене DOID), а Dj,...,Dn - атрибуты содержащие другую информацию об этой ассоциации.
    Замечание. Поскольку OID представляют объекты, отношение Qa может интерпретироваться системой как ассоциация объектов со схемой [O:O1 .... O:Oi, Dj,...,Dn], где O1 .... Oi - ассоциируемые объекты принадлежащие множеству объектов O., и даже (если системой поддерживается такой контроль типов) как ассоциация объектов со схемой [c1:O1 .... сi:Oi, Dj,...,Dn] где O1 .... Oi - ассоциируемые объекты принадлежащие классам c1 … ci. В последнем случае классы c1 … ci рассматриваются как домены отношений. Таким образом, модель "объект-качество" не противоречит подходу предлагаемому Дейтом, где класс и домен рассматриваются как эквивалентные понятия.
    Обратим особое внимание на то, что речь идет о качестве, и, следовательно, существуют объекты, описываемые различными значениями этого качеством. Таким образом, ассоциативное качество подразумевает, что помимо ассоциируемых объектов существует объект, который может быть назван ассоциирующим. Это становиться ясным когда мы перейдем на уровень хранения и рассмотрим соответсвующее качеству Qa отношение Ra, которое будет иметь схему [DOID:OID, S, DOID:ref1 .... DOID:refi, Dj,...,Dn ]. Здесь атрибут OID (из K-части) как и везде содержит OID описываемого (ассоциирующего) объекта, а атрибуты refOID1 .... refOIDi (из Q-части) содержат OID связанных с ним ассоциируемых объектов.
    Атрибуты ref1 .... refi входящие в Q-часть отношения Rа могут и должны рассматриваться как внешние ключи, для которых в качестве первичного ключа выступает атрибут OID стержневого отношения R0.
    Следствием этого является существование ссылочной целостности, то есть невозможности уничтожить объект в том случае, если в системе существует ассоциативная запись (кортеж отношения со схемой Ra), содержащая OID этого объекта в одном из полей ref1 .... refi.

    Частным, но очень важным случаем ассоциаций является существующие в объектных системах ссылки. Любая ссылка в модели "объект-качество" рассматривается как значения качества (типа) "объектная ссылка". По сути дела речь идет о качестве Qref, которое на уровне представления в самом общем виде можно рассматривать как 1-арное отношение со схемой [DOID:ref], где единственный атрибут ref определен на домене DOID. Значением этого качества может являться OID одного из существующих в системе объектов.

    Интересным эффект возникает в связи с тем, что на уровне представления качество "объектная ссылка" содержит один единственный атрибут с именем ref. Для того, что бы обратиться к значению, содержащемуся в объектной ссылке, имя ref можно не указывать. Например, если объект o ссылается на другой объект посредством атрибута-ссылки r, то для записи этого вместо выражения вида o.r.ref, достаточно выражения вида o.r , который используется в традиционных объектных системах. Поскольку ссылки являются основным механизмом описания связей между объектами в традиционных объектных системах, то система, основанная на модели "объект-качество", должна по умолчанию поддерживать качество "объектная ссылка" а также особенности использования этого качества.

    Следует особо отметить, что ассоциация, являющаяся на объектном уровне направленной (ассоциирующий объект ссылается на ассоциируемые объекты), на уровне хранения (реляционном уровне) является симметричной. Например множество ссылок образует на уровне хранения отношение Rref со схемой [DOID:OID, S, DOID:ref]. Конечно мы по прежнему можем подразумевать, что один объект, OID которого содержится в поле "OID" (К-часть), ссылается на другой объект, OID которого содержится в поле "ref" (Q-часть).Однако фактически отношение Rref является симметричной ассоциации объектов, что позволяет описать связь (между объектами) как связь типа многие-ко-многим.

    Такой подход дает некоторые возможности, недоступные в традиционных объектных системах. Например, для любого объекта возможно определить объекты, ссылающиеся на него - для этого достаточно отобрать кортежи отношения Rref у которых в поле ref содержится OID данного объекта. В традиционных объектных системах для того, что бы получить такую информацию придется перебрать и проанализировать все существующие объекты, что представляется практически неосуществимым.

    Атрибуты

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



    Эти строки создают variable и value как два атрибута specification, так что они не обязаны появляться в виде отдельных элементов. Тогда данные из нашего примера выглядели бы следующим образом:







    98756

    basket

    each
    Заметим, что этот подход дает дополнительную возможность выбора проектировщику XML-документов. Каждый метод обладает своими преимуществами и недостатками.

    Bank.MoveMoney

    dim ctxObject As ObjectContext Set ctxObject = GetObjectContext() ... On Error GoTo ErrorHandler
    dim objAccount As Bank.Account Set objAccount = ctxObject.CreateInstance("Bank.Account") ... objAccount.Post(lngSecondAccount, lngAmount) objAccount.Post(lngPrimeAccount, 0 - lngAmount) ... ctxObject.SetComplete ... ErrorHandler: ctxObject.SetAbort ...
    Мы значительно сократили и упростили текст примера, оставив в нем иллюстрацию самых базовых моментов. Первое, на что нужно обратить внимание- это объект ctxObject, который носит название "контекст объекта". Каждый объект, размещенный в MTS, автоматически получает в соответствие такой объект на все время своей жизни. Контекст объекта управляет участием объекта в транзакциях под контролем MTS (см., например, методы SetComplete и SetAbort в примере) и предоставляет средства для программной проверки безопасности. Например, если поступает запрос на перевод крупной суммы, мы можем предусмотреть проверку на наличие у него соответствующих прав:
    If (lngAmount > 500 Or lngAmount < -500) Then If Not ctxObject.IsCallerInRole("Managers") Then Err.Raise Number:=ERROR_NUMBER, ... Description:= "Need 'Managers' role for amounts over $500"
    End If End If
    Установка самих ролей происходит в MTS Explorer. Ccылку на контекст объекта можно получить с помощью функции MTS API GetObjectContext(). В данном примере мы создаем объект Account от контекста объекта MoveMoney, в результате чего он будет выполняться внутри той же транзакции, что и объект MoveMoney. В общем случае это зависит от транзакционного атрибута компоненты, под которым она установлена в MTS. Возможны 4 варианта: supported- при создании нового объекта его контекст наследует клиентскую транзакцию, если же клиент исполняется вне транзакции, то новый контекст тоже не будет транзакционным; required- то же, что и в предыдущем случае, но в случае отстутствия транзакции у клиента MTS откроет новую транзакцию для объекта; requires new- объект не наследует транзакцию клиента, для него всегда открывается новая транзакция; not supported- транзакция никогда не будет открыта объекту вне зависимости от наличия транзакции на клиенте.

    Одной из отличительных черт MTS является чрезвычайно рачительное, я бы даже сказал, трепетное отношение к системным ресурсам. Его девизом является активизация по мере необходимости и как можно более быстрая деактивизация объектов. Когда MTS деактивизирует объект, тот не разрушается, а становится доступен для повторного использования другими объектами. По секрету скажу, что MTS зачастую наглеет настолько, что может деактивизировать созданный вами объект при живых клиентских ссылках. То есть если вы создали объект, а потом отошли кофейку попить, не удивляйтесь, что этот сквалыга уже спер ваш объект, деактивизировал его и загнал кому-нибудь на сторону. Сердиться на него за это не стоит, потому что когда вы вернетесь и скажете "эй, парень, гони взад мой объект", лучше подождать лишних пол-секунды, пока MTS создаст или утянет (что существенно быстрее) с очередного ленивого соединения такой же объект, чем получить сообщение типа "извини, брат, не могу- память кончилась". MTS деактивизирует объект при вызовах методов окончания транзакции SetComplete или SetAbort. В следующий раз при повторном обращении к этому объекту MTS по обыкновению вмешается в COMовский вызов, подсунет вам тот самый ваш (а может и не ваш) объект и вызовет у него затребованный вами метод. То же происходит при работе с базами данных. Так как одной из самых дорогих операций является установка соединения, то MTS склонен держать у себя пул ODBC-соединений, и если нужное вам соединение уже туда попало и является свободным, как вы думаете, что сделает MTS, когда вы его попросите соединиться с базой? Кинется бегом открывать новое соединение? Щас прям. В подавляющем большинстве случаев вы получите его из пула. Смех смехом, однако бережное расходование системных ресурсов является одним из необходимых условий высокой масштабируемости, и не обладай MTS такими возможностями, он едва ли сумел бы на обычной в общем-то конфигурации без особых наворотов, обработать миллиард транзакций в сутки.

    Иногда возникают ситуации, когда объект вынужден вернуть управление клиенту не будучи готовым завершить транзакцию.


    Пусть у нас есть объект, отвечающий за ввод одной бухгалтерской проводки. Нам нужно ввести серию проводок, скажем, за день и сверить сумму с итогом. Если они совпадают, то только тогда всю группу проводок можно фиксировать как единую транзакцию. Для этих целей контекст объекта имеет метод DisableCommit, который запрещает деактивизацию и сброс внутреннего состояния объекта. В нашем случае его должен вызвать объект ввода проводки. После выверки итогов объектом вызывается метод EnableCommit с последующей фиксацией или откатом транзакции.

    Итак все объекты, работающие в среде управления MTS, могут вызывать друг друга. В отличие от них базовым клиентом называется истинный клиент в рассмотренной нами в п.3 трехуровневой схеме, т.е. это приложение, работающее, очевидно, не под управлением MTS, основная цель которого обеспечивать пользовательский интерфейс и отображать запросы пользователя в вызовы компонент. Для управления работой объектов MTS базовый клиент использует объект TransactionContext. Несмотря на то, что схема его применения очень похожа на контекст объекта (методы CreateInstance, Complete и Abort), базовый клиент может только управлять транзакцией MTS, но не участвовать в ней. Например, он не может напрямую открыть соединение с базой данных и вставить операции над ней внутрь этой транзакции. Наверное, это правильно, потому что коль скоро бизнес-логика ушла из клиентской части, то участие в транзакциях middleware недопустимо для базового клиента.

    VB4 умел создавать только однопоточные компоненты. MTS обеспечивает их поддержку, хотя это самый медленный способ, чреватый взаимными блокировками. Предположим, объекты А и В последовательно исполняются на одном потоке управления. А блокирует запись Х и заканчивает работу, забыв сделать SetComplete. Управление получает объект В, которому тоже нужна запись Х, поэтому он простаивает в ожидании, пока А ее разблокирует. Но для этого А должен получить поток управления, который наглухо занял В. Имеем картину под названием "Приплыли".


    В VB5 можно создавать apartment- threaded компоненты, которые также поддерживает MTS, что уже легче. Каждому объекту внутри компоненты назначается отдельный поток на все время его жизни. Границы апартаментов определяются деятельностью (activity), которая, насколько я понимаю, означает "гирлянду" объектов, связанных последовательными вызовами. Таким образом, если два объекта принадлежат разным деятельностям, они могут выполняться параллельно независимо от того, принадлежат они одной или разным компонентам. Мне кажется, что логично было бы ввести в последующих версиях MTS модель рабочих потоков, так чтобы объекты не привязывались жестко к какому-то потоку, а могли свободно между ними перераспределяться и при этом не требовался бы кросс-поточный маршалинг.

    Административными единицами при размещении компонент в MTS служат пакеты. Считается, что компоненты внутри пакета полностью доверяют друг другу, поэтому взаимные права компонент в пакете не проверяются, кроме того они запускаются в одном процессе. Очевидно, что базовые вызовы имеют identity клиента, поэтому при доступе к компонентам внутри пакета проверяется user-id. Вызовы, идущие из пакета, уже имеют identity данного пакета, поэтому если пользователи обращаются к компонентам, а компоненты, в свою очередь,- к базе данных, то имеет смысл сгруппировать компоненты по пакетам в соответствии с правами пользователей на доступ к базе, в противном случае авторизацию придется прописывать ручками внутри компонент. Это своего рода издержки переходного периода к многоуровневым системам. Перестройте свое мышление в соответствии с новым подходом: вы уже выросли из системы "клиент-сервер", давайте права на базу, имея в виду не конечных пользователей, а компоненты. В конце концов, пользователь вообще теперь не работает с базой- это забота компонент. Администрирование пользовательского доступа к компонентам осуществляется из MTS Explorer.

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


    Глобальные переменные (свойства) организованы в группы, получить или создать которые можно с помощью SharedPropertyGroupManager. Аналогично внутри каждой группы можно получить или создать разделяемое свойство при помощи SharedPropertyGroup. Вернемся к нашему банковскому примеру в начале пункта. Предположим, что мы еще хотим протоколировать каждую проводку в журнале и присваивать ей согласованный уникальный номер. Вот как для этого могут использоваться разделяемые свойства:

    dim spmMgr As SharedPropertyGroupManager Set spmMgr = CreateObject("MTxSpm.SharedPropertyGroupManager.1")

    dim spmGroup As SharedPropertyGroup dim bResult As Boolean Set spmGroup = spmMgr.CreatePropertyGroup("Receipt", LockSetGet, _ Process, bResult)

    dim spmPropNextReceipt As SharedProperty Set spmPropNextReceipt = spmGroup.CreateProperty("Next", bResult)

    dim spmPropMaxNum As SharedProperty Set spmPropMaxNum = spmGroup.CreateProperty("MaxNum", bResult)

    dim objReceiptUpdate As Bank.UpdateReceipt If spmPropNextReceipt.Value >= spmPropMaxNum.Value Then Set objReceiptUpdate = ctxObject.CreateInstance("Bank.UpdateReceipt") spmPropNextReceipt.Value = objReceiptUpdate.Update(strResult) spmPropMaxNum.Value = spmPropNextReceipt.Value + 100 End If

    ' Get the next receipt number and update property

    spmPropNextReceipt.Value = spmPropNextReceipt.Value + 1

    Базовые типы как логическое понятие.

    Я не случайно старался использовать выражение "предопределенный тип" - оно является наиболее нейтральным и может обозначать как базовые, так и примитивные типы. Давайте различать эти понятия. Будем считать, что "базовый тип" - это логическое понятие описывающий тип данных, предопределенный в модели данных. "Примитивным типом" мы будем называть тип, реализуемый физической системой хранения и предопределенный в конкретной системе хранения данных.
    Почему это различие является важным? При подготовке этой статьи было просмотрено достаточно большое количество работ, в которых рассматривались и сравнивались различные варианты интересующей нас "объектной модели" данных. При их описании базовые типы вводятся как некая данность, существующая в системе по умолчанию. Речь идет об ограниченном числе примитивных типах вроде int, char и т.п., то есть базовые типы логической модели фактически рассматриваются как полный аналог примитивных, аппаратно-поддерживаемых типов. Насколько верна эта аналогия? нужна ли она? обсуждения этого вопроса мне обнаружить не удалось.
    Это очень интересный вопрос. Давайте предположим, что мы описываем некую систему типов (в дальнейшем - "описываемая" система типов) и что существует набор типов являющихся базовыми - мы вводим эти типы как уже существующие, предопределенные. Эти базовые типы не принадлежат к "описываемой" системе типов - мы предполагаем, что базовые типы не является классами. Следовательно, существует некая система типов, в которой описываются базовые типы (в дальнейшем - "базовая" система типов), и она отлична от "описываемой" системы типов, или, говоря по-другому, ортогональна ей. Я еще раз повторю, что здесь мы только предполагаем что "базовая" система типов существует, и это предположение основывается на том факте, что существует набор базовых типов не являющихся типами "описываемой" системы типов. В данном случае важен только тот факт, что базовые типы существуют.
    Каким образом базовые типы определены в "базовой" системе типов, что они из себя реально представляют, какие ограничения на них накладываются - это является внутренним делом именно "базовой" системы типов.

    Базовые типы современных объектных систем описываются в "базовой" системе типов аппаратно-зависимой линейной памяти. Она обладает очень серьезным ограничением - примитивные аппаратно-зависимые типы имеют совершенно конкретное воплощение в железе и их количество строго фиксировано. Однако это ограничение является ограничением именно "базовой" системы типов. Предположим, что на уровне железа появилась возможность работать с переменными нового типа (или типов - например, что-то типа verylong integer , или superpuperdouble, или что-нибудь еще). Естественно, этот тип сразу же появиться в списке типов являющихся базовыми для "описываемой" объектной системы типов. Эти рассуждения приводят нас к тому, что с точки зрения "описываемой" системы типов возможно существование произвольного числа базовых типов при условии, что эти типы будут поддерживаться "базовой" системой типов.

    Последнее утверждение повторяет на логическом уровне сделанное ранее предположение о существование произвольного числа разных типов значимых сущностей, для описания которых должна существовать абстракция отличная от абстракции "объект". Конечно же, говоря о неограниченном количестве базовых типов, мы уже не можем говорить о аппартно-зависимой памяти. Следовательно, речь может идти только о некой логической системе хранения информации. Для того, что бы выяснить, что это за система и какими свойствами она обладает, необходимо рассмотреть свойства значимых сущностей. А для этого надо понять, что же это такое - значимая сущность?

    Базы данных: дайджесты

  • (1998-1999гг.)
    Кузнецов С.Д.
  • (декабрь 1998г.)
    Кузнецов С.Д.


  • Сергей Кузнецов, Центр Информационных Технологий






  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • А.Эйзенберг, Дж.Мелтон

    Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий
  • (The Asilomar Report on Database Research)

    Фил Бернштейн, Майкл Броуди, Стефано Чери, Дэвит Девитт, Майк Франклин, Гектор Гарсиа-Молина, Джим Грей, Джерри Хелд, Джо Хеллерстейн, Х.М. Ягадиш, Майкл Леск, Дейв Майер, Джеф Науфтон, Хамид Пиранеш, Майк Стоунбрейкер, Джеф Ульман

    Перевод: Сергей Кузнецов, Центр Информационных Технологий
    (An Overview of Query Optimization in Relational Systems)

    Сураджит Чаудхари

    Перевод: Сергей Кузнецов, Центр Информационных Технологий


  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

  • Сергей Кузнецов, Центр Информационных Технологий

    Под редакцией Пола МакДжонса, перевод Сергея Кузнецова

  • Сергей Кузнецов, Центр Информационных Технологий


  • Обзор статьи журнала DBPD, С. Кузнецов, 21 мая 1998 г.

  • Сергей Кузнецов, Центр Информационных Технологий

    Базы данных реального времени

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

    Базы данных :: статьи



  • Таранов И. С., ИСП РАН


  • А.В. Коршунов, ИСП РАН


  • Сергей Кузнецов


  • Иппократис Пандис, Райан Джонсон, Никос Харадавеллас и Анастасия Айламаки

    Перевод: Сергей Кузнецов


  • Майкл Стоунбрейкер
    Перевод: Сергей Кузнецов

    Игорь Савчук, Blogerator.ru


  • Карло Курино, Эван Джонс, Янг Жанг и Сэм Мэдден

    Перевод: Сергей Кузнецов


  • А.Е.Васильев


  • Сергей Кузнецов


  • Сигалаев Г.Г., OCP
    Oracle CIS


  • Дэниел Абади и Александер Томсон

    Перевод: Сергей Кузнецов


  • Майкл Стоунбрейкер
    Перевод: Сергей Кузнецов


  • Майкл Стоунбрейкер
    Перевод: Сергей Кузнецов


  • Сергей Лизин, АНО «Информационная Мордовия» (Саранск)


  • Дональд Коссман, Тим Краска и Саймон Лоузинг

    Перевод: Сергей Кузнецов


  • Дэниел Абади и Александер Томсон

    Перевод: Юрий Кудрявцев

    Под редакцией Сергея Кузнецова


  • Ю Ксу, Пекка Костамаа, Лайк Гао

    Перевод: Сергей Кузнецов


  • Энтони Клив, Том Менс, Жан-Люк Эно

    Перевод: Сергей Кузнецов


  • Рафи Ахмед, Эллисон Ли, Эндрю Витковски, Динеш Дас, Хонг Су, Мохамед Зэйд, Тьерри Крюейнс
    Перевод Леонида Борчука

    Под ред. Сергея Кузнецова


  • Срикант Белламконда, Рафи Ахмед, Анжела Амор, Мохамед Зэйд
    Перевод Леонида Борчука

    Под ред. Сергея Кузнецова


  • Эван Джонс, Дэниэль Абади и Сэмуэль Мэдден

    Перевод: Сергей Кузнецов


  • Майкл Стоунбрейкер

    Перевод: Сергей Кузнецов


  • Майкл Стоунбрейкер

    Перевод: Сергей Кузнецов


  • Сергей Кузнецов


  • Олег Бартунов


  • Тим Краска, Мартин Хеншель, Густаво Алонсо, Дональд Коссман
    Перевод: Сергей Кузнецов


  • Азза Абузейд, Камил Байда-Павликовски, Дэниэль Абади, Ави Зильбершац, Александр Разин
    Перевод: Сергей Кузнецов


  • Майкл Стоунбрейкер, Дэниэль Абади, Дэвит Девитт, Сэм Мэдден, Эрик Паулсон, Эндрю Павло и Александр Разин
    Перевод: Сергей Кузнецов


  • Семенов В.А., Ильин Д.В., Морозов С.В., Сидяка О.В.


  • Пэт Хелланд, Дейв Кэмпбел
    Перевод: Сергей Кузнецов


  • Марк Риттман
    Перевод: Юрий Кудрявцев


  • Эрик Фридман, Питер Павловски, Джон Кислевич
    Перевод: Сергей Кузнецов


  • Сергей Кузнецов


  • Джулиан Хайд
    Перевод: Сергей Кузнецов


  • Сергей Кузнецов


  • Джеффри Коэн, Брайен Долэн, Марк Данлэп, Джозеф Хеллерстейн, Кейлэб Велтон

    БОГАТСТВО ВЫБОРА И ПРОБЛЕМА БУРИДАНОВА ОСЛА

    Существует большое количество средств и продуктов для
    Windows NT, поддерживающих взаимодействие с другими сетями и операционными системами.
    В первую очередь, это встроенные средства, входящие в стандартную поставку Windows NT
    Server и Windows NT Workstation, в числе которых NWLink, NetWare Compatible Service(NWCS),
    Gateway Service for NetWare, Directory Service Manager for NetWare для взаимодействия с сетями
    NetWare, протоколы IP, ICMP, TCP, UDP, ftp, telnet для взаимодействия с сетями TCP/IP.
    Microsoft выпускает и отдельные продукты межсетевого взаимодействия - например шлюзы для
    своей почтовой системы Microsoft Mail Server 3.5 или File and Print Services for NetWare-
    реализацию протоколов NCP и SAP в среде Windows NT. Появилось и большое количество
    продуктов третьих фирм для Windows NT, например BW-Connect NFS компании Beame &
    Whiteside, PathWorks for Windows NT компании DigitalEquipment, NFS connectivity services
    компании Intergraph, редиректор для сетей Banyan VINES, NetWare Client for Windows NT
    фирмы Novell.
    Этот список можно еще продолжать и продолжать.
    Какими же
    продуктами лучше пользоваться - встроенными или купленными специально? Если предпочесть
    первое, то какие продукты выбрать при конфигурировании, если второе, то неплохо бы знать,
    чей продукт и что мы приобретаем, платя дополнительные деньги за отдельный продукт. Увы,
    богатство выбора не только помогает создать хорошую сеть, но и создает "проблему
    Буриданова осла".
    Для того чтобы все-таки принять решение, да к тому же не
    самое плохое, на наш взгляд, следует учитывать следующие характеристики средств межсетевого
    взаимодействия:
    · способ реализации - мультиплексор протоколов или
    шлюз;
    · уровень и конкретный набор согласуемых протоколов - транспортные
    протоколы или протоколы прикладного уровня;
    · направление взаимодействия -
    согласование клиентских или серверных частей протоколов;
    · место размещения
    согласующих средств - на клиентской машине, на сервере либо на промежуточной машине-
    шлюзе, в среде одной либо другой операционной системы;
    · потребительские
    характеристики - стоимость, производительность, степень прозрачности, удобство инсталляции
    и обслуживания.

    Брокер Объектных Запросов.

    При определении конкретной архитектуры Брокер Объектных Запросов вовсе необязательно должен быть реализован как один компонент, но каждая реализация должна реализовывать три категории операций:
  • Операции, которые одинаковы для всех реализаций ORB-а.

  • Операции, специфичные для конкретного объектного типа.

  • Операции, специфичные для отдельных видов реализаций объектов.

    • Различные реализации ORB-а могут поддерживать различные виды реализаций, а различные адаптеры объектов могут обеспечивать различные наборы сервисов для клиента и реализаций.
    Ядро Брокера Объектных Запросов обеспечивает основные механизмы для манипуляций объектами и выполнения запросов. Спецификация CORBA предназначается для поддержки различных механизмов реализации объектов, поэтому структура ядра не определяется. Вместо этого задается набор интерфейсных функций, которые должны присутствовать в каждой реализации ORB-а и тем самым маскируют отличия между различными реализациями Брокеров Объектных Запросов.

    Будущие направления исследований в области баз данных: десять лет спустя

    Сергей Кузнецов
    В феврале 1988 г. 16 ведущих исследователей из США и Германии провели двухдневный симпозиум, посвященный обсуждений основных тем исследований в области баз данных в будущем. Симпозиум был организован университетом Беркли (Калифорния, США) и немецкой организацией GMD (Gesellschaft fur Mathematik und Datanvarebeitung) и проходил в Лагуна Бич недалеко от Лос-Анжелеса. После симпозиума в журнале SIGMOD Record (V. 18, No. 1, 1988) был опубликован отчет, который официально назывался Furure Directions in DBMS Research, но получил народное название Laguna Beach Report (к сожалению, до сих пор этот текст недоступен в Internet). Нам кажется, что спустя десять (с лишним) лет интересно вспомнить прогнозы и оценить их правильность (особенно в связи с новым отчетом, содержащем прогнозы на следующие десять лет). Комментарии и оценки выделяются курсивом. Далее мы будем следовать структуре отчета, кратко его пересказывая и давая свои оценки (конечно, полностью субъективные).

    Будущие приложения

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

    Быть или не быть значению переменной

    К. Дж. Дейт
    Перевод -
    Оригинал: To Be Is to Be a Value of a Variable
    Все три статьи этого цикла построены в виде полемики с двумя анонимными критиками Третьего Манифеста. Однако данная статья особенно полемична. Местами она напоминает мне одну из любимых книг моего детства – «Материализм и эмпириокритицизм» В.И.Ленина (хотя стиль Дейта является гораздо более интеллигентным). На самом деле, в статье обсуждаются вопросы, играющие важнейшую роль в реляционной модели данных, как она представляется Дарвеном и Дейтом в Третьем Манифесте: значения, проявления значений, переменные отношений, присваивания, равенство и т.д. Вся статья читается исключительно увлекательно, но основной сюрприз запрятан в самом конце. Самое смешное, что если вы сразу начнете читать статью с конца, то можете и не найти этот сюрприз. Вернее, вы может не понять всю каверзность этого сюрприза. Так что читайте уж с начала до конца. Обещаю, не пожалеете.
    С.Д. Кузнецов
    Автор просит прощения у Джорджа Булос и его книги «Логика, логика и логика» (я позаимствовал название этой статьи из одного из эссе, включенного в эту книгу)
    Если мы хотим, чтобы мир оставался таким, как есть,

    он должен изменяться
    Джузеппе Томази ди Лампедуза
    «Изменение» является научным понятием, а прогресс – понятием этическим,
    наличие изменения несомненно, а наличие прогресса можно оспаривать
    Бертран Рассел

    Cache' Server Pages (CSP).

    Основой концепции серверных страниц Cache' является автоматическое создание по запросу пользователя web-страниц, содержащих требуемую информацию из БД Cache'. Как видно из рис. 7., вся бизнес-логика CSP-приложений выполняется в непосредственной близости к хранилищу данных Cache', таким образом сокращается объем данных, которыми обмениваются web-сервер и сервер БД Cache', что приводит к выигрышу в производительности по сравнению с другими технологиями создания web-приложений. Для еще большего увеличения производительности CSP приложений при обмене данными между сервером Cache' и web-сервером используются высокоскоростные интерфейсы API.
    Cache' Server Pages (CSP).

    Рис.7. Сравнение web-технологий.
    Серверные страницы Cache' представляют собой текстовые HTML-файлы, расширяемые тегами приложений Cache' (Cache' Application Tags или CATs). Для создания CSP приложений можно воспользоваться стандартными средствами разработки HTML страниц (Cache' предоставляет add-in модуль для полной интеграции с Macromedia DreamWeaver) или, на крайний случай, обыкновенным текстовым редактором.
    В Листинге 1 приведен пример небольшого CSP-приложения, которое выводит значения свойств объекта, хранящегося в БД Cache'.
    Листинг 1.

    Стандартные теги приложений Cache' приведены в Таблице 1. Однако пользователь не ограничен только стандартными тегами. Cache' предоставляет также интерфейсы для создания пользовательских тегов приложений.
    Таблица 1. Стандартные теги CSP.

    Вставка данных:УправлениеИспользование Cache' ScriptЗапросы к БД
    #(а)#Вывод значения переменной/функции/метода
    ##(a)##тоже, но во время компиляции
    Unautorized!!! Условие
    Циклы
    Скрипт внутри страницы
    Метод CSP класса