Табличное выражение

Стандарт SQL/89 рекомендует рассматривать вычисление табличного выражения как последовательное применение разделов FROM, WHERE, GROUP BY и HAVING к таблицам, заданным в списке FROM. Раздел FROM имеет следующий синтаксис:

<from clause> ::=FROM <table reference>[{,<table reference>}...]<table reference> ::=<table name> [<correlation name>]

Технология централизованных СУБД (Single Site DBMS)

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

Пожалуй, в прошедшие десять лет больше внимания компании-производители СУБД уделяли именно параллельным симметричным архитектурам. Достигнуты очень существенные (возможно, предельные) результаты. Что же касается основной и дисковой памяти, то рост объемов и снижение стоимости оказались не столь значительными, и соответствующие изменения в технологии теперь ожидаются в следующем десятилетии.

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

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

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

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

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

Эта область почти полностью перешла в промышленность. Компании сделали очень много за десять лет, и направления были угаданы почти точно. Единственное, что угадать не удалось, - это появление битовых индексов (Bit-Map Indexes), активно применяемых теперь в хранилищах данных.

Технология IntelliSense

Технология IntelliSense, или "подтверждение завершения", стало очень популярной функцией редакторов в таких продуктах, как Microsoft Visual Basic и Microsoft InterDev. IntelliSense делает написание кода более легким благодаря возможности автоматического завершения написания оператора, свойства или функции (то есть вы начинаете писать команду или параметр, а Foxpro предлагает возможные варианты, и вам остается только подтвердить один из вариантов Enter'ом). Это уменьшает количество вводимого вручную кода и позволяет разработчику не искать в документации параметры, свойства, методы нужной функции или объекта.

В этой версии Visual Foxpro IntelliSense содержит следующие функции:

Список объектов. Показывает выпадающий список допустимых дочерних объектов (свойств, событий методов) для указанного объекта. Для COM-объектов информация считывается из библиотеки типов. Быстрая подсказка. Показывает окно подсказки для команды, функции, свойства,метода или события. Информация в этом окне содержит список допустимых параметров или аргументов функции или команды. Список значений. Показывает выпадающий список допустимых значений для свойства объекта. Для примера, если тип Logical, то список будет содержать значения True или False.

Рисунок 1. Список объектов и быстрая подсказка

Рисунок 2. Список значений

Текущая ситуация и проблемы

Язык XQuery предназначен для описания запросов к XML-данным. На момент написания данной работы XQuery все еще не получил статус рекомендации консорциума W3C, но близок к этому, являясь кандидатом к рекомендации (candidate recommendation). К сожалению, языковые средства модификации XML-данных отстают от средств выборки данных. Консорциум W3C в настоящее время работает над языком для описания модификаций XML-данных, но пока что существует только документ с предварительными требованиями (facility requirements) к этому языку.

Параллельно с работой консорциума W3C по стандартизации языка XQuery опубликован ряд исследовательских работ, посвященных языковым средствам модификации XML-данных [, , ]. В существующих на сегодняшний день реализациях XML-СУБД, как правило, предлагаются средства как для запросов к XML-данным, так и для модификации XML-данных. Для описания запросов в большинстве случаев предоставляется некоторое подмножество языка XQuery. Для описания модификации XML-данных разработчики предоставляют различные вариации предложенных в исследовательской среде языков модификации XML-данных. При этом различия языков бывают достаточно серьезными и касающимися не только синтаксиса выражений, но и семантики их вычисления.

Общей чертой существующих на сегодняшний момент предложений языков модификации XML данных является их отчужденность от языка запросов к XML-данным XQuery. Если быть более точными, то необходимо отметить, что в некоторых работах [] затрагивается вопрос о связи между языком XQuery и языком модификации XML-данных, но полное решение этой проблемы в настоящее время не представлено.

Актуальность задачи тесной интеграции языка XQuery и языка модификации XML-данных проявляется при анализе требований практических предложений. Широко распространено мнение, что язык XQuery по отношению к XML-данным, занимает такое же положение, как язык SQL по отношению к реляционным данным. Мы полагаем, что это не совсем так, потому что язык XQuery во многих случаях претендует на большую роль.
Если выражения языка SQL в практических приложениях используются как средства доступа к базе данных из языка программирования общего назначения, то с языком XQuery ситуация нам представляется несколько иной. По нашему мнению, язык XQuery является самодостаточным для некоторых классов приложений, интенсивно обрабатывающих данные. Среди таких классов приложений мы видим Web-приложения, Web-сервисы, приложения класса управления контентом и ряд других. Язык XQuery содержит мощные средства выборки данных, средства трансформации данных, необходимые управляющие конструкции, что позволяет его использовать для описания бизнес-логики приложений. Главное преимущество такого подхода заключается в том, что разработка приложений ведется на одном языке в рамках одной модели данных, что позволяет избежать известной проблемы потери соответствия (impedance mismatch) [], заключающейся, применительно к XML-данным, в несоответствии модели данных языка программирования и модели данных XML.

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

Для решения подобных задач необходима возможность композиции выражений языка XQuery и языка модификации XML-данных. Именно это мы подразумеваем под тесной интеграцией языка XQuery и языка модификации XML-данных. Однако решение такой задачи "напрямую" порождает серьезные проблемы в силу функциональной природы языка XQuery.



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



I. Неинтегрированные решения.

Примером такого подхода является реализация языка модификации XML данных в XML-СУБД Sedna. Для выражения логики приложения разработчик может использовать любую последовательность из выражений языка XQuery и языка модификации XML-данных, но выражения их этой последовательности никак не связаны друг с другом. То есть, в сущности, это последовательное выполнение выражений из двух различных языков над одними XML-данными.



II. Интегрированные решения с ограниченной семантикой.

Такой подход реализован, например, с прирожденной XML-СУБД MarkLogic CMS []. В этой системе предлагается 'прямо' расширить язык XQuery конструкциями, модифицирующими состояние XML-данных. С точки зрения модели данных XQuery, такие конструкции возвращают пустую последовательность элементов, но их вычисление происходит с побочными эффектами, заключающимися в изменении состояния данных в базе XML-данных. Такое прямое внедрение в функциональную среду языка XQuery выражений с побочными эффектами приводит к ряду проблем. Суть этих проблем связана с тем, что выражения, модифицирующие XML-данные, могут непредсказуемо менять XML-данные, которые уже логически связаны с конструкциями языка XQuery, внешними по отношению к этим выражениям. Для преодоления этих проблем семантика интегрированного языка в XML СУБД MarkLogic CS ограничена следующим образом. Предполагается, что все изменения, связанные с update-выражениями, вступают в силу только по окончании вычисления всего выражения расширенного языка. То есть в пределах одного выражения доступно только исходное состояние данных. После вычисления выражения состояние данных меняется. Используя последовательность таких расширенных выражений языка XQuery, разработчик выражает логику обработки данных.

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

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

Тенденции в мире систем управления базами данных

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

Системы управления базами данных (СУБД) играют исключительную

роль в организации современных промышленных, инструментальных и

исследовательских информационных систем. Тематика СУБД поистине

безгранична. В предлагаемом коротком обзоре описываются наиболее

интересные направления исследований и разработок.

1. Реляционные системы

Хотя многие полагают, что реляционные СУБД, являясь наиболее

распространенным современным аппаратом построения информационных

систем, не представляют уже интереса в научном отношении,

остается еще много нерешенных или решенных не полностью проблем.

Об этом свидетельствует поток статей, посвященных тематике чисто

реляционных систем, а также активная деятельность

компаний-производителей коммерческих реляционных систем,

стремящихся улучшать свои продукты и придавать им новые качества.

Продолжающаяся работа исследователей затрагивают вопросы

оптимизации запросов, новых алгоритмов выполнения реляционных

операций, оптимизации структур хранения данных и другие аспекты,

непосредственно определяющие эффективность СУБД. Те же самые

вопросы занимают и разработчиков коммерческих СУБД, которые,

кроме того озабочены и более прикладными проблемами. Рассмотрим

немного более подробно (но без технических деталей) существо

некоторых из этих вопросов и то, каким образом они решаются в

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

1.1 Стандартизация языка SQL

Для всех современных коммерческих реляционных СУБД основным

языком доступа к базам данных является SQL. В 1989 г. появился

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

производителей СУБД объявляют свои системы соответствующими этому

стандарту. Но стандарт 1989 г. был довольно ограниченным

(например, в него не входили средства манипулирования схемой БД,

динамический SQL и т.д.), а многие вошедшие в стандарт аспекты

языка были специфицированы недостаточно строго. Поэтому разные

реализации различаются в достаточно важных вопросах.

В 1992 г.
был принят новый стандарт SQL-92. Этот язык существенно

более сложен, чем SQL-89, а конструкции SQL-92 специфицированы в

стандарте существенно более полно. Первой компанией, которая

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

компания Oracle со своей седьмой версией (это произошло прямо в

1992 г.). Теперь и все остальные компании обещают вскоре

выпустить продукты, соответствующие стандарту SQL-92.

Кроме того, как это бывает всегда, производители стремятся

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

стандарта. Например, современные версии Oracle и Ingres содержат

возможности определения триггеров (подробнее об этом см. ниже), в

системе uniVerse компании VMark поддерживается расширенная

ненормализованная реляционная модель и т.д. Другими словами,

компании стремятся смотреть в будущее, предвидя требования

следующего стандарта SQL (его условно называют SQL-3; ожидается

принятие этого стандарта в 1995 г.).

1.2 Использование мультипроцессорных организаций

Уже довольно давно развитые коммерческие СУБД основываются на

архитектуре "клиент-сервер". При этой организации наиболее

трудоемкие операции над базами данных выполняются на выделенном

компьютере-сервере, который должен быть достаточно мощным и

обладать соответствующим набором ресурсов основной и внешней

памяти. До поры серверная часть СУБД обладала простой

организацией: запросы, поступающие из клиентских частей системы,

обрабатывались последовательно с небольшой оптимизацией для

совмещения процессорной работы с работой устройств внешней

памяти.

Однако с появлением на рынке мультипроцессорных симметричных

аппаратных архитектур, производители СУБД были вынуждены

пересмотреть организацию своих серверов, допустив в них

внутреннюю параллельность. Естественно, это требует очень

основательного перепроектирования системы с ее существенным

усложнением. Заметим, что в большинстве случаев компании пошли на

это после появления в ОС UNIX механизма "легковесных" процессов



(threads).

О серьезности этой работы говорит тот факт, что, например, в

компании Informix было образовано новое подразделение,

занимающееся исключительно вопросами распараллеливания работы

серверов.

1.3 Интеграция и интероперабельность

Чтобы убедить новых потенциальных пользователей использовать

новые продукты, компании-производители должны обеспечить решение

проблемы использования старых баз данных. В принципе эта проблема

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

компонентов, которые не были на это рассчитаны с самого начала.

В большинстве случаев предлагаемые решения основываются на

использовании индустриальных стандартов распределенных объектных

систем (например, стандарта CORBA, разработанного OMG). Тем не

менее производители СУБД вынуждены решать многочисленные проблемы

для вхождения их систем в новые интегрированные среды.

2. Постреляционные системы

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

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

постреляционных систем, т.е. систем, относящихся к следующему

поколению (хотя термин next-generation DBMS зарезервирован для

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

2.1 Базы сложных объектов, реляционная модель с отказом от первой нормальной формы

Одним из основных положений реляционной модели данных является

требование нормализации отношений: поля кортежей могут содержать

лишь атомарные значения. Для традиционных приложений реляционных

СУБД - банковских систем, систем резервирования и т.д. - это

вовсе не ограничение, а даже преимущество, позволяющее

проектировать экономные по памяти БД с предельно понятной

структурой. Запросы с соединениями в таких системах сравнительно

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

соответствующие средства SQL.

Однако с появлением эффективных реляционных СУБД их стали

пытаться использовать и в менее традиционных прикладных системах

- САПР, системы искусственного интеллекта и т.д. Такие системы

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



реконструкции которых из плоских таблиц реляционной БД приходится

выполнять запросы, почти всегда требующие соединения отношений. В

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

приложений появилось направление исследований баз сложных

объектов. Это очень обширная область исследований, в которой

затрагиваются вопросы моделей данных, структур данных, языков

запросов, управления транзакциями, журнализации и т.д. Во многом

эта область соприкасается с областью объектно-ориентированных БД.

2.2 Активные базы данных

По определению БД называется активной, если СУБД по отношению к

ней выполняет не только те действия, которые явно указывает

пользователь, но и дополнительные действия в соответствии с

правилами, заложенными в саму БД.

Легко видеть, что основа этой идеи содержалась в языке SQL

времени System R. На самом деле, что есть определение триггера

или условного воздействия как не введение в БД правила, в

соответствии с которым СУБД должна производить дополнительные

действия? Плохо лишь то, что на самом деле триггеры не были

полностью реализованы ни в одной из известных систем, даже и в

System R. И это не случайно, потому что реализация такого

аппарата в СУБД очень сложна, накладна и не полностью понятна.

Среди вопросов, ответы на которые до сих пор не получены,

следующие. Как эффективно определить набор вспомогательных

действий, вызываемых прямым действием пользователя? Каким образом

распознавать циклы в цепочке "действие-условие-действие-..." и

что делать при возникновении таких циклов? В рамках какой

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

какого пользователя относить возникающие накладные расходы?

Масса проблем не решена даже для сравнительно простого случая

реализации триггеров SQL, а задача ставится уже гораздо шире.

По существу, предлагается иметь в составе СУБД продукционную

систему общего вида, условия и действия которой не ограничиваются

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



пользователя. Например, в условие может входить время суток, а

действие может быть внешним, например, вывод информации на экран

оператора. Практически все современные работы по активным БД

связаны с проблемой эффективной реализации такой продукционной

системы.

Вместе с тем, по нашему мнению, гораздо важнее в практических

целях реализовать в реляционных СУБД аппарат триггеров. Заметим,

что в проекте стандарта SQL3 предусматривается существование

языковых средств определения условных воздействий. Реализация и

будет первым практическим шагом к активным БД (как мы отмечали в

разд.1, уже появились соответствующие коммерческие реализации).

2.3 Дедуктивные базы данных

По определению, дедуктивная БД состоит из двух частей:

экстенциональной, содержащей факты, и интенциональной, содержащей

правила для логического вывода новых фактов на основе

экстенциональной части и запроса пользователя.

Легко видеть, что при таком общем определении SQL-ориентированную

реляционную СУБД можно отнести к дедуктивным системам.

Действительно, что есть определенные в схеме реляционной БД

представления как не интенциональная часть БД.

Основным отличием реальной дедуктивной СУБД от реляционной

является то, что и правила интенциональной части БД, и запросы

пользователей могут содержать рекурсию. Именно возможность

рекурсии делает реализацию дедуктивной СУБД очень сложной и во

многих случаях эффективно неразрешимой проблемой.

Мы не будем здесь более подробно рассматривать конкретные

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

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

определения интенциональной части БД являются логическими

(поэтому дедуктивные БД часто называют логическими). Имеется

прямая связь дедуктивных БД с базами знаний (интенциональную

часть БД можно рассматривать как БЗ). Более того, трудно провести

грань между этими двумя сущностями; по крайней мере, общего

мнения по этому поводу не существует.

Какова же связь дедуктивных БД с реляционными СУБД, кроме того,



что реляционная БД является вырожденным частным случаем

дедуктивной? Основным является то, что для реализации дедуктивной

СУБД обычно применяется реляционная система. Такая система

выступает в роли хранителя фактов и исполнителя запросов,

поступающих с уровня дедуктивной СУБД. Между прочим, такое

использование реляционных СУБД резко актуализирует задачу

глобальной оптимизации запросов.

При обычном применении реляционной СУБД запросы обычно поступают

на обработку по одному, поэтому нет повода для их глобальной

(межзапросной) оптимизации. Дедуктивная же СУБД при выполнении

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

запросов к реляционной СУБД, которые могут оптимизироваться

совместно.

Конечно, в случае, когда набор правил дедуктивной БД становится

велик и их невозможно разместить в оперативной памяти, возникает

проблема управления их хранением и доступом к ним во внешней

памяти. Здесь опять же может быть применена реляционная система,

но уже не слишком эффективно. Требуются более сложные структуры

данных и другие условия выборки. Известны частные попытки решить

эту проблему, но общего решения пока нет.

2.4 Темпоральные базы данных

Обычные БД хранят мгновенный снимок модели предметной области.

Любое изменение в момент времени t некоторого объекта приводит к

недоступности состояния этого объекта в предыдущий момент

времени. Самое интересное, что на самом деле в большинстве

развитых СУБД предыдущее состояние объекта сохраняется в журнале

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

Конечно, можно явно ввести в хранимые отношения явный временной

атрибут и поддерживать его значения на уровне приложений. Более

того, в большинстве случаев так и поступают. Недаром в стандарте

SQL появились специальные типы данных date и time. Но в таком

подходе имеются несколько недостатков: СУБД не знает семантики

временного поля отношения и не может контролировать корректность

его значений; появляется дополнительная избыточность хранения



( предыдущее состояние объекта данных хранится и в основной БД, и

в журнале изменений); языки запросов реляционных СУБД не

приспособлены для работы со временем.

Существует отдельное направление исследований и разработок в

области темпоральных БД. В этой области исследуются вопросы

моделирования данных, языки запросов, организация данных во

внешней памяти и т.д. Основной тезис темпоральных систем состоит

в том, что для любого объекта данных, созданного в момент времени

t1 и уничтоженного в момент времени t2, в БД сохраняются (и

доступны пользователям) все его состояния во временном интервале

[t1,t2).

Исследования и построения прототипов темпоральных СУБД обычно

выполняются на основе некоторой реляционной СУБД. Как и в случае

дедуктивных БД темпоральная СУБД - это надстройка над реляционной

системой. Конечно, это не лучший способ реализации с точки зрения

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

глубокие исследования.

Примером кардинального (но может быть, преждевременного) решения

проблемы темпоральных БД может служить СУБД Postgres. Эта система

является новым инструментом М.Стоунбрекера для исследований и

обучения студентов в университете г.Беркли, и он безбоязненно

идет в ней на самые смелые эксперименты.

Главными особенностями системы управления памятью в Postgres

является, во-первых, то, что в ней не ведется обычная

журнализация изменений базы данных и мгновенно обеспечивается

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

утратой состояния оперативной памяти. Во-вторых, система

управления памятью поддерживает исторические данные. Запросы

могут содержать временные характеристики интересующих объектов.

Реализационно эти два аспекта связаны.

Основное решение состоит в том, что при модификациях кортежа

изменения производятся не на месте его хранения, а заводится

новая запись, куда помещаются измененные поля. Эта запись

содержит, кроме того, данные, характеризующие транзакцию,

производившую изменения (в том числе и время ее завершения), и



подшивается в список к изменявшемуся кортежу. В системе

поддерживается уникальная идентификация транзакций и имеется

специальная таблица транзакций, хранящаяся в стабильной памяти.

Таким образом, после сбоев просто не следует обращать внимание на

хвостовые записи списков, относящиеся к незакончившимся

транзакциям. Синхронизация поддерживается на основе обычного

двухфазного протокола захватов.

Отдельный компонент системы осуществляет архивизацию объектов

базы данных. Он производит сборку разросшихся списков

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

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

только на чтение.

Система ориентирована на использование оптических дисков с

разовой записью и стабильной оперативной памяти (хотя бы

небольшого объема). При наличии таких технических средств она

выигрывает по эффективности даже при работе в традиционном режиме

по сравнению со схемой с журнализацией. Однако, возможна работа и

на традиционной аппаратуре, тогда эффективность системы слегка

уступает традиционным схемам.

Соответствующие возможности работы с историческими данными

заложены в язык Postquel (и в этом его главное отличие от

последних вариантов Quel). Возможна выборка информации,

хранившейся в базе данных в указанное время, в указанном

временном интервале и т.д. Кроме того, имеется возможность

создавать версии отношений, и допускается их последующая

модификация с учетом изменений основных вариантов.

2.5 Интегрированные или федеративные системы и мультибазы данных

Направление интегрированных или федеративных систем неоднородных

БД и мульти-БД появилось в связи с необходимостью

комплексирования систем БД, основанных на разных моделях данных и

управляемых разными СУБД.

Основной задачей интеграции неоднородных БД является

предоставление пользователям интегрированной системы глобальной

схемы БД, представленной в некоторой модели данных, и

автоматическое преобразование операторов манипулирования БД

глобального уровня в операторы, понятные соответствующим



локальным СУБД. В теоретическом плане проблемы преобразования

решены, имеются реализации.

При строгой интеграции неоднородных БД локальные системы БД

утрачивают свою автономность. После включения локальной БД в

федеративную систему все дальнейшие действия с ней, включая

администрирование, должны вестись на глобальном уровне. Поскольку

пользователи часто не соглашаются утрачивать локальную

автономность, желая тем не менее иметь возможность работать со

всеми локальными СУБД на одном языке и формулировать запросы с

одновременным указанием разных локальных БД, развивается

направление мульти-БД. В системах мульти-БД не поддерживается

глобальная схема интегрированной БД и применяются специальные

способы именования для доступа к объектам локальных БД. Как

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

выборка данных. Это позволяет сохранить автономность локальных

БД.

Как правило, интегрировать приходится неоднородные БД,

распределенные в вычислительной сети. Это в значительной степени

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

СУБД: управление глобальными транзакциями, сетевую оптимизацию

запросов и т.д. Очень трудно добиться эффективности.

Как правило, для внешнего представления интегрированных и

мульти-БД используется (иногда расширенная) реляционная модель

данных. В последнее время все чаще предлагается использовать

объектно-ориентированные модели, но на практике пока основой

является реляционная модель. Поэтому, в частности, включение в

интегрированную систему локальной реляционной СУБД существенно

проще и эффективнее, чем включение СУБД, основанной на другой

модели данных.

2.6 СУБД следующего поколения

Термин "системы следующего (или третьего) поколения" вошел в

жизнь после опубликования группой известных специалистов в

области БД "Манифеста систем баз данных третьего поколения".

Cторонники этого направления придерживаются принципа



эволюционного развития возможностей СУБД без коренной ломки

предыдущих подходов и с сохранением преемственности с системами

предыдущего поколения.

Частично требования к системам следующего поколения означает

просто необходимость реализации давно известных свойств,

отсутствующих в большинстве текущих реляционных СУБД (ограничения

целостности, триггеры, модификация БД через представления и

т.д.). В число новых требований входит полнота системы типов,

поддерживаемых в СУБД; поддержка иерархии и наследования типов;

возможность управления сложными объектами и т.д.

Одной из наиболее известных СУБД третьего поколения является

система Postgres, а создатель этой системы М.Стоунбрекер, по всей

видимости, является вдохновителем всего направления. В Postgres

реализованы многие интересные средства: поддерживается

темпоральная модель хранения и доступа к данным и в связи с этим

абсолютно пересмотрен механизм журнализации изменений, откатов

транзакций и восстановления БД после сбоев; обеспечивается мощный

механизм ограничений целостности; поддерживаются

ненормализованные отношения (работа в этом направлении началась

еще в среде Ingres), хотя и довольно странным способом: в поле

отношения может храниться динамически выполняемый запрос к БД.

Одно свойство системы Postgres сближает ее с

объектно-ориентированными СУБД. В Postgres допускается хранение в

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

типов. Это обеспечивает возможность внедрения поведенческого

аспекта в БД, т.е. решает ту же задачу, что и ООБД, хотя,

конечно, семантические возможности модели данных Postgres

существенно слабее, чем у объектно-ориентированных моделей

данных.

Хотя отнесение СУБД к тому или иному классу в настоящее время

может быть выполнено только условно (например, иногда

объектно-ориентированную СУБД O2 относят к системам следующего

поколения), можно отметить три направления в области СУБД

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

обозначать их именами наиболее характерных СУБД.



Направление Postgres. Основная характеристика: максимальное

следование (насколько это возможно с учетом новых требований)

известным принципам организации СУБД (если не считать

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

памятью).

Направление Exodus/Genesis. Основная характеристика: создание

собственно не системы, а генератора систем, наиболее полно

соответствующих потребностям приложений. Решение достигается

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

интерфейсами, причем идея распространяется вплоть до самых

базисных слоев системы.

Направление Starburst. Основная характеристика: достижение

расширяемости системы и ее приспосабливаемости к нуждам

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

управления правилами. По сути дела, система представляет собой

некоторый интерпретатор системы правил и набор модулей-действий,

вызываемых в соответствии с этими правилами. Можно изменять

наборы правил (существует специальный язык задания правил) или

изменять действия, подставляя другие модули с тем же интерфейсом.

В целом можно сказать, что СУБД следующего поколения - это прямые

наследники реляционных систем.

2.7 Объектно-ориентированные базы данных

Направление объектно-ориентированных баз данных (ООБД) возникло

сравнительно давно. Публикации появлялись уже в середине 1980-х

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

последние годы. С каждым годом увеличивается число публикаций и

реализованных коммерческих и экспериментальных систем.

Возникновение направления ООБД определяется прежде всего

потребностями практики: необходимостью разработки сложных

информационных прикладных систем, для которых технология

предшествующих систем БД не была вполне удовлетворительной.

Конечно, ООБД возникли не на пустом месте. Соответствующий базис

обеспечивают как предыдущие работы в области БД, так и давно

развивающиеся направления языков программирования с абстрактными

типами данных и объектно-ориентированных языков программирования.



Что касается связи с предыдущими работами в области БД, то

наиболее сильное влияние на работы в области ООБД оказывают

проработки реляционных СУБД и следующее хронологически за ними

семейство БД, в которых поддерживается управление сложными

объектами. Кроме того, исключительное влияние на идеи и концепции

ООБД и, как кажется, всего объектно-ориентированного подхода

оказал подход к семантическому моделированию данных (общее число

публикаций по семантическому моделированию поистине безгранично).

Достаточное влияние оказывают также развивающиеся параллельно с

ООБД направления дедуктивных и активных БД.

Среди языков и систем программирования наибольшее первичное

влияние на ООБД оказал Smalltalk. Этот язык сам по себе не

является полностью пионерским, хотя в нем была введена новая

терминология, являющаяся теперь наиболее распространенной в

объектно-ориентированном программировании. На самом деле,

Smalltalk основан на ряде ранее выдвинутых концепций.

Большое число работ не означает, что все проблемы ООБД полностью

решены. Как отмечается в Манифесте группы ведущих ученых,

занимающихся ООБД, современная ситуация с ООБД напоминает

ситуацию с реляционными системами середины 1970-х гг. При наличии

большого количества экспериментальных проектов (и даже

коммерческих систем) отсутствует общепринятая

объектно-ориентированная модель данных, и не потому, что нет ни

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

согласия о принятии какой-либо модели. На самом деле, имеются и

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

языков запросов, выполнением и оптимизацией запросов,

формулированием и поддержанием ограничений целостности,

синхронизацией доступа и управлением транзакциями и т.д.

Мы уже говорили, что основная практическая надобность в ООБД

связана с потребностью в некоторой интегрированной среде

построения сложных информационных систем. В этой среде должны

отсутствовать противоречия между структурной и поведенческой



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

сложными структурами данных во внешней памяти. С этой точки

зрения языковая среда ООБД - это объектно-ориентированная система

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

долговременными объектами. "Естественность" включения средств

работы с БД в язык программирования означает, что работа с

долговременными (хранимыми во внешней БД) объектами должна

происходить на основе тех же синтаксических конструкций (и с той

же семантикой), что и работа со временными, существующими только

во время работы программы объектами.

Эта сторона ООБД наиболее близка родственному направлению языков

программирования БД. Языки программирования ООБД и БД во многих

своих чертах различаются только терминологически; существенным

отличием является лишь поддержание в языках первого класса

подхода к наследованию классов. Кроме того, языки второго класса,

как правило, более развиты как в отношении системы типов, так и в

отношении управляющих конструкций.

Что же касается связи ООСУБД с реляционными системами, то, как

обычно, реляционные СУБД являются основным инструментом при

проведении исследовательских работ и прототипировании

объектно-ориентированных СУБД.

3. Распределенные СУБД

В теоретическом плане распределенные СУБД составляют еще одно

измерение в пространстве исследований и разработок систем

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

задачи, свойственные централизованным СУБД, но, как правило, в

более сложных постановках. Кроме того, в распределенных системах

возникают и специфические проблемы, от решения которых во многом

зависит эффективность, надежность и доступность систем БД. В

настоящее время большинство распределенных СУБД базируется на

реляционной модели данных и рассчитано на использование в

локальных сетях ЭВМ. Многие проблемы распространяются и на

распределенные СУБД в территориально разнесенных сетях, и почти

все проблемы сохраняются для распределенных СУБД, основанных на



других моделях данных.

3.1 Синхронизация доступа к данным

В централизованных системах БД очень распространено использование

двухфазного протокола синхронизационных захватов объектов БД. В

соответствии с этим протоколом объект БД автоматически

захватывается транзакцией в соответствующем режиме при первом

обращении, и все захваты данной транзакции освобождаются только

при ее завершении. В случае возникновения конфликта по

синхронизации транзакция блокируется, пока объект не будет

освобожден. Следование этому протоколу может привести к

возникновению синхронизационного тупика между двумя или более

транзакциями. Задача СУБД - распознать появление тупика и

разрушить его путем отката одной или нескольких транзакций.

Распознавание тупиков сводится к обнаружению циклов в графе

ожидания транзакций, что является трудоемкой задачей даже в

централизованных СУБД. В распределенных системах решение этой

задачи может потребовать неприемлемых накладных расходов (хотя

поиски алгоритмов с допустимыми затратами продолжаются).

Поэтому более часто в распределенных системах применяются

протоколы синхронизации, основанные на временных метках. Это

направление само по себе очень широко, имеются разные варианты и

даже комбинации с протоколом двухфазных захватов, но основной

проблемой реализации является отсутствие в распределенной системе

единого времени.

3.2 Управление транзакциями

В истинно распределенной СУБД транзакции естественно утрачивают

линейную структуру. Распределенная транзакция в общем случае

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

являются распределенные подтранзакции, а листья соответствуют

обычным линейным транзакциям локальных СУБД.

Основной проблемой управления транзакциями в этом случае является

корректное завершение (фиксация) распределенной транзакции.

Классическим решением является использование давно известного

протокола двухфазной фиксации. Однако прямое использование этого

протокола порождает значительное число служебных сообщений между



составляющими распределенную систему локальными СУБД. Большое

число исследований посвящено поискам более экономичных

протоколов.

3.3 Поддержание копий данных в нескольких узлах сети

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

запроса является пересылка данных между узлами сети. Одним из

способов сокращения этого накладного расхода является поддержание

копий наиболее часто используемых данных в нескольких узлах сети

с учетом порождаемых этим дополнительных накладных расходов по

поддержанию согласованности копий при модификации данных.

Другим основанием для поддержания копий является увеличение

уровня доступности данных при выходе из строя узлов сети или

коммуникационных линий, вследствие чего утрачивается связность

сети. Теоретически доступ к некоторому объекту БД может

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

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

изменениях объекта данных. Существует масса подходов к решению

этой проблемы от полного разрешения любого доступа к любой копии

объекта во всех разделах сети с проведением сложной процедуры

согласования копий после восстановления связности сети до

разрешения модификации объекта только в одном разделе. Для

обнаружения этого раздела обычно применяются различные варианты

алгоритма голосования.

3.4 Фрагментация объектов БД

Альтернативный подход, обеспечивающий максимальное

распараллеливание выполнения запроса к БД, состоит в том, что

отношение (если говорить в терминах реляционной модели данных)

разбивается на ряд вертикальных или горизонтальных фрагментов, и

эти фрагменты хранятся в разных узлах сети.

Понятно, что теоретически это может обеспечить убыстрение

выполнения запроса, затрагивающего фрагментированное отношение,

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

состоит в резком расширении пространства поиска вариантов

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

запросов.

Имеются предложения и исследования, связанные с комбинацией



поддержания копий и фрагментацией объектов БД. В этом случае

поддерживаются копии фрагментов, что, вообще говоря, решает обе

задачи, но еще больше усложняет реализацию.

3.5 Алгоритмы выполнения реляционных операций

Даже если говорить только про реляционные распределенные СУБД,

которые наиболее развиты в теоретическом и практическом

отношении, до сих пор проводится масса исследований в области

оптимизации алгоритмов выполнения реляционных операций (главным

образом, соединения удаленных отношений).

Таким образом, даже рассмотрев только небольшую часть проблем

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

большом количестве исследований и экспериментов. Начавшийся в

России переход к использованию локальных сетей дает практическую

возможность проведения таких работ.

4. Системы БД с многоуровневой защитой

Большинство реально используемых современных СУБД основано на

реляционной модели данных и языке баз данных SQL. Существенной

особенностью языка SQL, появившейся в нем с самого начала,

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

языка. Основная идея такого подхода состоит в том, что по

отношению к любому отношению БД и любому столбцу отношения

вводится предопределенный набор привилегий. С каждой транзакцией

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

она выполняется (способы связи и идентификации пользователей не

фиксируются в языке и определяются в реализации).

После создания нового отношения все привилегии, связанные с этим

отношением и всеми его столбцами, принадлежат только

пользователю-создателю отношения. В число привилегий входит

привилегия передачи всех или части привилегий другому

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

Технически передача привилегий осуществляется при выполнении

оператора SQL GRANT. Существует также привилегия изъятия всех или

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

переданы. Эта привилегия также может передаваться. Технически



изъятие привилегий происходит при выполнении оператора SQL

REVOKE. Проверка полномочности доступа к данным происходит на

основе информации о полномочиях, существующих во время компиляции

соответствующего оператора SQL.

Долгое время подход к защите данных от несанкционированного

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

распространяющимся использованием реляционных СУБД в

нетрадиционных приложениях все чаще раздается критика. Если,

например, в системе БД должна поддерживаться многоуровневая

защита данных, соответствующую систему полномочий весьма трудно,

а иногда и невозможно построить на основе средств SQL.

Вопросам организации систем БД с развитыми механизмами защиты в

последнее время уделяется очень большое внимание. Можно выделить

два основных подхода. Первый подход состоит в связывании с каждым

защищаемым объектом БД набора допустимых привилегий и связывании

с каждым пользователем некоторого набора прав доступа. Как

таковая, эта техника известна еще со времени первых ОС разделения

времени, но при ее применении в области БД требуются

дополнительный анализ, уточнения и дополнения. Второй подход к

защите данных основан на использовании методов криптографии. На

самом деле упрощенные криптографические методы тоже

использовались и используются в ОС для проверки прав доступа

пользователя (в частности, для кодирования паролей

пользователей). Развитые же методы кодирования в основном

применялись в информационных системах специального назначения.

Теперь же кодирование с открытыми ключами все чаще применяется в

системах общего назначения.

Типы данных

В языке SQL/89 поддерживаются следующие типы данных: CHARACTER, NUMERIC,DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION. Эти типы данных классифицируются на типы строк символов, точных чисел и приблизительных чисел.

К первому классу относится тип CHARACTER. Спецификатор типа имеет вид CHARACTER (length), где length задает длину строк данного типа. Заметим, что в SQL/89 нет типа строк переменного размера, хотя во многих реализациях они допускаются. Литеральные строки символов изображаются в виде "последовательность-символов"(например "example").

Представителями второго класса типов являются NUMERIC, DECIMAL (или DEC), INTEGER (или INT) и SMALLINT. Спецификатор типа NUMERIC имеет вид NUMERIC [(precision [, scale])]. Специфицируются точные числа, представляемые с точностью precision и масштабом scale. Здесь и далее, если опущен масштаб, то он полагается равным 0, а если опущена точность, то ее значение по умолчанию определяется в реализации.

Спецификатор типа DECIMAL (или DEC) имеет вид DECIMAL [(precision [,scale])]. Специфицируются точные числа, представленные с масштабом scale и точностью, равной или большей значения precision.

INTEGER специфицирует тип данных точных чисел с масштабом 0 и определяемой в реализации точностью. SMALLINT специфицирует тип данных точных чисел с масштабом 0 и определяемой в реализации точностью, не большей, чем точность чисел типа INTEGER.

Литеральные значения точных чисел в общем случае представляются в форме[+|-] <целое-без-знака> [.<целое-без-знака>].

Наконец, в классу типов данных приблизительных чисел относятся типы FLOAT, REAL и DOUBLE PRECISION. Спецификатор типа FLOAT имеет вид FLOAT[(precision)]. Специфицируются приблизительные числа с двоичной точностью, равной или большей значения precision.

REAL специфицирует тип данных приблизительных чисел с точностью, определенной в реализации. DOUBLE PRECISION специфицирует тип данных приблизительных чисел с точностью, определенной в реализации и большей, чем точность типа REAL.

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

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

Определены следующие основные (базовые) типы данных:

16 и 32 разрядные знаковые и беззнаковые целые типы; 32 и 64 разрядные типы с плавающей точкой в соответствии с IEEE; символьный тип в соответствии с ISO Latin-1 (8859.1); логический тип с множеством значений истина и ложь; 8 разрядный тип, который гарантированно не подвергается никаким изменениям при передаче между различными системами; перечислимые типы, состоящие из последовательности идентификаторов; строковый тип, состоящий из последовательности символов переменной длины, длина строки доступна во время выполнения программы; тип "any", который может принимать значения всех базовых и составных типов.

Также могут быть определены составные типы:

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

Параметры, представленные в запросе должны удовлетворять одному из перечисленных типов, за исключением типа интерфейс, как показано на рисунке 2-1.

Tks.shtml

Журнал "Технология Клиент-Сервер" (индекс 72133) издается с 1996 года и публикует материалы, посвященные использованию этой технологии в создании приложений для автоматизации управленческой и финансовой деятельности предприятия, а также информацию о новых продуктах и средствах разработки.

Copyright © АОЗТ "Аудит-Оптим"
Почтовый адрес: 129343, г.Москва, ул. Амундсена, 15-1-7

Телефон: (095)180-02-01

document.write('');

This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009

Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.

Заманчивое предложение - от надежной компании Городисский и Партнеры.

<

TMDM - многомерное ядро Cache', ориентированное на работу с транзакциями.

Данные в Cache' хранятся в виде разреженных массивов, носящих название глобалей. Количество индексов массива может быть произвольным, что позволяет описывать и хранить структуры данных произвольного уровня сложности. Индексы глобалей не типизированы, т.е. они могут быть любого литерального типа данных. Например, с помощью следующей глобали можно описать количество машин Mercedes SL600 черного цвета на складе:

^car("Mercedes","SL600","black")=10

Немного усложняя приведенную структуру описания данных, можно определить все доступные цвета для Mercedes SL600:

^car("Mercedes","SL600","colors")=3 ^car("Mercedes","SL600" ,"colors",1)="black" ^car("Mercedes","SL600" ,"colors",2)="blue" ^car("Mercedes","SL600" ,"colors",3)="white"

Применение разреженных массивов позволяет оптимизировать использование объема жесткого диска и сократить время, требуемое на выполнение I/O операций и извлечение данных.

В СУБД Cache' реализована развитая технология обработки транзакций и разрешения конфликтов. Блокировка данных производится на логическом уровне. Это позволяет учитывать особенность многих транзакций, производящих изменения небольшого объема информации. Кроме этого, в Cache' реализованы атомарные операции добавления и удаления без проведения блокировки, в частности, это применяется для счетчика ID объектов в базе данных.

Тонкая настройка MySQL (часть 1 )

Вадим Ткаченко, руководитель студии

Эта заметка, в основном, является переводом соответствующих разделов руководства по MySQL.

Здесь собраны возможные способы настройки и использования MySQL-сервера для достижения максимальной производительности. Все нижесказанное относится к версии 3.22 для Linux. Для других операционных систем некоторые из утверждений могут не выполняться.

Трансляция данных

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

В принципе, они были правы, потому что уже существовал протокол XDR (External Data Representation). Однако, насколько мне известно, позже к этой проблеме вернулись при разработке протокола IIOP (Internet Inter-ORB Protocol).

Транспорт для протокола GIOP.

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

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

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

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

Три основных недостатка современных хранилищ данных

Вон Ким

журнал , #02/2003

В последние несколько лет многие предприятия создают хранилища (и киоски) данных, чтобы выполнять над ними приложения. Используемые технологии хранилищ данных опираются, прежде всего, на средства ETL (extract-transform-load - >), моделирование и проектирование баз данных, а также на системы реляционных баз данных. Сегодняшним хранилищам данных присущи три основных недостатка. Это неудовлетворительная обработка > данных, неудовлетворительные производительность и масштабируемость при выполнении операций, основанных на сканировании, а также неудовлетворительный выбор источников данных для загрузки в хранилище данных. В статье анализируются эти три проблемные области и приводятся основные черты подходов к решению проблем.

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

Для создания хранилища данных предприятию в общем случае нужно выполнить следующие шаги:

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

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

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

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

Триггеры R*O-системы

Триггеры являются ключевым механизмом реализации активности данных, и способом поддержания их целостности. [1]

Исходя из того, что каждый элемент R*O-системы

1) является кортежем некоторого отношения (имеет определенный реляционный смысл) и

2) принадлежит объекту (имеет смысл в контексте этого объекта)

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

1) характерных для сущности, описывающей элемент (R-правила);

2) характерных для объекта, которому элемент принадлежит (O-правила).

R-триггеры являются прямым аналогом триггеров реляционной БД. Эти триггеры являются способом поддержания закономерностей, присущих некоторой сущности.

Пример: Для сущности "АДРЕС" можно определить следующее правило: "Если страна - Россия, то вводимый ZIP-код (индекс), должен содержать шесть цифр". Данное правило должно выполняться для любого кортежа отношения "АДРЕС", вне зависимости от смысла, который данный кортеж имеет в контексте объекта

O-триггеры - действия происходящие в ответ на определенные изменения объекта и служащие для поддержания закономерностей присущих классу этого объекта. Объект в R*O-системе существует как набор записей различных таблиц. Изменение объекта есть изменение этих записей. В ответ на операцию производимую с записью и основываясь на семантическом значении SID, поддерживаемую для этой записи, система вызывает описанный в классе процедуру, которую можно рассматривать как триггер на определенное действие производимое с соответствующим полем. Этот триггер может быть назван семантическим триггером поля этого класса.

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

Пример: для атрибута содержащего физический адрес клиента можно определить следующее правило - "Физический адрес обязательно должен содержать индекс (ZIP-код)". Для юридического адреса, имеющего чисто формальное значение, индекс можно и не указывать.

Умные данные унифицируют процессы и данные в системе баз данных

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

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

Второй аспект касается логики в традиционном смысле процедур в данном языке программирования. Популярным подходом к выражению такой логики является использование компонентов, и такие компоненты следует поддерживать внутри системы баз данных. К сожалению, еще не существует Эсперанто компонентного программирования. Могут стать популярными и CORBA, и OLE, и Enterprise Java Beans (EJB), и Jini. Поддержка нескольких (несовместимых) компонентных моделей внутри объектно-реляционной системы баз данных кажется устрашающей задачей.
Тем не менее, сообщество баз данных должно помочь развить эти модели для поддержки типов и процедур, хорошо интегрируемых с системой баз данных.

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

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

Унификация логики программ и систем баз данных

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

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

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

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

UNIX: достоинства, недостатки и эмоции

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

Зеленеет один,

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

Спелый каштан.

Мацуо Басе (1644-1694)

Начнем с эмоций. Теоретически я согласен, что некорректно

говорить "я люблю операционную систему UNIX". Всем известно, что

по-настоящему любят родителей, детей, женщин и других Божих

тварей. Тем не менее...

Люблю тебя (UNIX), но странною любовью... К сожалению, ее не

победит рассудок мой. Вы же знаете, как бывает с любимой

женщиной. Мы видим в ней массу недостатков. Мы знаем, какой бы

она должна быть. Но она существует (какая она есть), и мы ее

любим. Так и с UNIX. Неэмоциональный человек скажет, что это

всего лишь программа. Пока она его устраивает, он ей пользуемся.

Когда появляется лучшая операционная система (только вот где

она?), он начинает пользоваться ей. Наверное, это правильно, но

скучно, господа!

На мой взгляд, наиболее правильная комбинация человеческих

качеств включает жизненный опыт, теоретические знания, практику,

эмоциональный комплекс, привычки и способность критического

отношения к себе и к миру (и конечно же, чувство юмора). Мой

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

обсуждать достоинства UNIX и недостатки NT (другая точка зрения -

выдающиеся достижения Билла Гейтса и застой и прострацию в мире

UNIX). А что тут злиться? Главное, чтобы эмоции не перекрывали

здравый смысл и смягчались юмором.

Могу привести два примера. Год назад на факультете ВМиК

Московского университета мы со студентами проводили вечерний

абсолютно неформальный семинар под условным названием

"Операционная система UNIX". На самом деле, на этом семинаре

обсуждались разнообразные вопросы архитектурной организации

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

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

заражен вирусом "UNIX". Так вот, двое моих студентов внимательно

проштудировали одну из немногих хороших книг по архитектуре

Windows NT и сделали развернутый доклад часа на четыре.
Доклад

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

все остались очень довольны, получив представление об NT изнутри.

Другой пример. На заре NT в завершение семинара, целиком

посвященного ОС UNIX, было решено провести диспут (в стиле

революционных традиций первых годов Советской власти) на тему

"Придет ли NT на смену UNIX?". Мы с коллегой (тоже старым

UNIX-истом) договорились, что я буду представлять сторону UNIX, а

он - отстаивать преимущества NT. Естественно, мы оба хорошо знали

UNIX, а NT (в то время) представляли в лучшем случае на уровне

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

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

отношения и обладание чувством юмора к концу диспута мы

благополучно переругались. Довольная публика в зале не

наблюдалась.

Попробую умерить свои эмоции и немного более серьезно поговорить

о достоинствах и недостатках ОС UNIX, о прошлом, настоящем и

будущем этого явления.

Вы знаете, что и до и после появления ОС UNIX существовали

гораздо более элегантные операционные системы: например, Miltics,

Mach, Chorus и т.д. Красивые, основанные на единой идее,

проектировавшиеся и разрабатывавшиеся выдающими специалистами.

Мне нравятся эти ОС, я часто о них пишу, рассказываю студентам.

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

РАН, а затем в Институте системного программирования РАН в

составе группы опытных специалистов в области операционных систем

я участвовал в проектировании и разработки отечественной

объектно-ориентированной операционной системы КЛОС. Тоже была

очень красивая система.

Но только UNIX в своих разных ипостасях смог благополучно и с

большой пользой прожить более 25 лет. В чем причина такого

долголетия? Почему человек, вошедший в мир UNIX, не может, да и

не хочет его покинуть? Почему за весь период использования ОС

UNIX область применения этой ОС непрерывно расширялась? Чем, в

конце концов, объяснить феномен университетов Беркли и Хельсинки,



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

UNIX?

Краткий перечень ответов на эти вопросы (возможно, неполный):

простота

мощность базового набора средств

развитость интерфейсов

демократичность

открытость

переносимость

Прокомментируем этот список более подробно.

По моему мнению, исходным побуждение к разработке ОС UNIX было

стремление создать простую и понятную операционную среду.

Простота начальных версий ОС UNIX во многом явилась следствием

удачного выбора основных понятий, которые, с одной стороны,

отражали основные потребности пользователей, а с другой - были

интуитивно понятными: пользователь, терминал, программа, процесс,

файл с примитивной внутренней структурой. На пальцах любой из

этих понятий объясняется за считанные минуты. В среде

классической ОС UNIX очень легко проектировать, разрабатывать и

отлаживать программы. Создателям системы удалось найти удачный

компромисс между разумной ограниченностью доступных средств

(известно, что чем более ограничен средний программист, тем легче

ему жить) и достаточностью этих средств для разработки широкого

класса программ.

Базовый набор средств, опирающихся на эти понятия, оказался очень

мощным. В частности, комбинируя средства, поддерживающие

разработку программ, управление пользовательскими процессами,

перенаправление ввода/вывода на основе абстрактной трактовки

понятия файла, стало возможным динамически создавать сложные

программы со внутренней асинхронностью из простых и небольших по

размеру программных компонентов. Достаточно быстро в ядре ОС UNIX

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

процессов (именованные программные каналы, очереди сообщений,

программные гнезда). Это позволило решать в среде ОС UNIX задачи,

близкие по своему характеру к задачам "мягкого" реального

времени. Разработка в университете Беркли стека сетевых

протоколов TCP/IP, реализация этого стека в UNIX BSD.3 и

стыковка TCP/IP с механизмом программных гнезд привели к тому,



что ОС UNIX стала истинной сетевой операционной системой. Именно

тогда Билл Джой произнес свою знаменитую фразу "Сеть - это

компьютер". Протоколы TCP/IP положили основу Всемирной сети сетей

Internet, а их комбинация с механизмом программных гнезд во

многом способствовала становлению архитектурной концепции

"клиент-сервер".

Удачной находкой явилась идея использования развитого командного

языка в качестве базового интерфейса пользователя с операционной

системой. Командные языки использовались и в предшествовавших ОС

UNIX интерактивных операционных системах, но пользователи этих ОС

всегда испытывали по меньшей мере неудобства при написании

командных файлов (или, как принято называть их в теперешней

молодежной программистской среде, скриптов). Семейство командных

языков shell (Bourne-shell, C-shell, Korn-shell и т.д.)

предоставляет пользователям мощные средства текстовой обработки,

которые в сочетании с принятыми в ОС UNIX стандартными (и не

обременительными) правилами написания новых команд позволяют, не

выходя из сеанса взаимодействия с командным интерпретатором,

создавать команды, комбинировать существующие команды и т.д.

Конечно, по мере развития и удешевления аппаратуры графических

видеотерминалов, в ОС UNIX не могли не появиться графические

пользовательские интерфейсы. На сегодняшний день в основе

большинства таких интерфейсов лежит разработанная в

Массачусетском технологическом институте оконная система X (X

Window System). Конечно, графический интерфейс удобнее строчного.

Но тем не менее, значимость командных языков семейства shell от

этого не уменьшилась. Каким бы убогим не было терминальное

оснащение UNIX-компьютера, пользователь имеет все возможности

взаимодействия с системой. Более того, трудно найти программиста,

работающего в среде X, у которого хотя бы в одном окне экрана не

был вызван традиционный строчный интерпретатор shell.

Трудно (а может быть, и не нужно) различать демократичность ОС

UNIX и демократичность UNIX-сообщества. (Замечу, что под



UNIX-сообществом я понимаю сообщество технических специалистов,

связанных с использованием, разработкой, администрированием или

сопровождением ОС UNIX. Как правило, я не отношу к этому

сообществу продавцов. Обычно им достаточно все равно, чем

торговать, лишь бы получить большую прибыль. Хотя я знаком с

некоторым числом salesmen, давно уже торгующих ОС UNIX или

UNIX-компьютерами, но так и не излечившихся от вируса UNIX.)

Наверное, следует сказать так: демократичность UNIX-сообщества

существует благодаря демократичности UNIX. ОС UNIX демократична,

поскольку открывает любому квалифицированному пользователю или

разработчику возможности своего совершенствования.

UNIX-сообщество демократично, поскольку его члены имеют общую

цель (независимую от используемой аппаратуры, используемой версии

UNIX, конкретных требований нанимателя и т.д.) - получить более

удобную, более надежную, более мощную операционную систему. Как

правило, в мире UNIX существует очень небольшой объем скрываемого

"know how". Предметом гордости является возможность опубликовать

(в печати или в Сети) содержимое своей новой идеи или результаты

новой разработки.

UNIX-сообщество не могло бы быть демократичным, если бы сама

операционная система не была открытой. Под открытостью мы

понимаем публичную доступность спецификаций интерфейсов,

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

Открытость системы нужна пользователям (чтобы не испытывать

неприятных потрясений при смене варианта ОС), разработчикам

(чтобы иметь возможность внесения согласованных

усовершенствований), продавцам (чтобы иметь возможность четко

объяснить покупателю возможности его покупки). Спецификации

интерфейсов и протоколов ОС UNIX публикуются в документах SVID,

XPG, POSIX и частично приняты в качестве международных стандартов

мобильных операционных систем. Открытость UNIX имела по меньшей

мере два выдающихся последствия. Во-первых (это мое личное

мнение), она способствовала становлению и внедрению в практику



общей концепции Открытых Систем (грубо говоря и не вдаваясь в

детали, я бы сформулировал ее так: следуй правильно подобранному

набору признанных стандартов - и все будет хорошо). Во-вторых,

именно открытость UNIX позволила одновременно существовать двум

ветвям операционной системы: коммерческой ветви, развиваемой

такими компаниями, как Santa Cruz Operation, Sun Soft, Digital

Equipment, IBM, Hewlett Packard и т.д., и некоммерческой ветви,

представленной разными вариантами UNIX BSD (FreeBSD, BSDNet и

т.д.) и Linux. Феномен Linux вообще ошеломляет. Начиная с нуля,

бывший студент Хельсинского университета Линус Торвальдс смог

реализовать свое собственное ядро операционной системы, которое

привлекло к коллоборации (как любят говорить физики) громадное

число заинтересованных людей в Internet. Сегодня Linux - это

качественная, развитая ОС, способная конкурировать с

коммерческими вариантами ОС UNIX. Конференции по Linux собирают

тысячи людей, а Линус не менее популярен в мире UNIX, чем Деннис

Ритчи.

Переносимость следует понимать в двух смыслах. Во-первых,

правильно написанное ядро ОС UNIX само обладает свойством

простоты переноса на другую аппаратную платформу. Это стало

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

(1) Большая часть ядра (и все дополнительное программное

обеспечение) написана на машинно-независимом языке Си и сама

является машинно-независимой. (2) Та часть ядра, которая не может

быть машинно-независимой (включающая, например, компоненты,

связанные с управлением виртуальной памятью на аппаратном уровне)

обладает небольшими размерами и спроектирована в весьма модульной

манере. Перепись этой части с учетом особенностей аппаратуры

целевого компьютера не представляет собой неподъемную задачу. В

результате, фактически, стало возможным иметь одну и ту же

операционную среду (здесь я несколько идеализирую) на абсолютно

разных аппаратных платформах. Во-вторых, даже при наличии на

разных аппаратных платформах различающихся реализаций UNIX,



которые соответствуют открытым спецификациям, можно сравнительно

просто обеспечить переносимость прикладного программного

обеспечения. Для этого нужно всего лишь не выходить за пределы

специфицированных средств. Причем эти возможности

распространяются даже на такие сложные "над ядерные" системы как

СУБД. СУБД Oracle, предназначенная для использования на

UNIX-платформах, имеет (почти) один и тот же исходный текст для

любой конкретной платформы. Тексты СУБД Oracle, работающей в

среде NT, существенно отличаются.

Как всегда, я готов хвалить UNIX как угодно долго, и обычно у

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

операционную систему. Все-таки попробую.

Имеется две возможности ругать ОС UNIX. В каждом конкретном

варианте можно найти массу дефектов. Например, если говорить о

классических реализациях (например, ранних выпусках System V),

можно найти недостатки в организации механизма общесистемной

буферизации, управлении файлами и т.д. Но дело в том, что в

каждом следующем выпуске эти недостатки смягчаются или удаляются

вовсе. Так что анализ этих недостатков - это дело скорее

историков ОС UNIX, и мы на этом останавливаться не будем. Вторая

возможность сказать "гадость" по поводу UNIX относится к

некоторым абсолютным новшествам этой системы. Лично для меня

соответствующим основанием является внедрение в ОС UNIX механизма

"легковесных процессов" (в просторечии "threads"), т.е.

процессов, которые совместно выполняются в общей виртуальной

памяти. Не люблю я LWP (Light Weight Processes). Программисты

среднего и старшего поколения все это проходили. Программирование

с использованием LWP порождает многочисленные трудности, хотя и

является на сегодняшний день единственным способом использования

возможностей симметричных мультипроцессорных архитектур (SMP -

Symmetric Multi Processors).

Ну вот, я похвалил и немного поругал UNIX, не сказав ни одного

плохого слова про Microsoft. Да и нет в NT ничего плохого, кроме

того, что эта система не обладает

простотой

демократичностью

открытостью

(Не давайте мне много говорить про NT, я слишком эмоционален!)

Каково будущее UNIX? Я оптимист, и надеюсь, что в недалеком

будущем мы увидим 64-разрядные, высокомобильные,

стандартизованные, надежные реализации системы, наличие которых

позволит дожить операционной системе (надеюсь, вместе с нами) до

50 лет.

UNIX мертв, а я еще жив

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

На самом деле, как и в случае Б.Г., мы живы оба и, скорее всего,

он переживет меня :-( (как и рок-н-ролл явно переживет бедного

Боба). Живучая получилась операционная система. Причем, чем

дольше живет, тем больше сил набирается. Когда отдельные странные

люди говорят, что с приходом Windows NT (а до этого OS/2 и т.д.)

эпоха ОС UNIX закончилась, я тихо смеюсь про себя. В чем же

состоит жизненная сила операционной системы (а точнее, семейства

ОС) UNIX?

По-моему, наиболее важным фактором является то, что исторически

система не является принадлежащей какой-либо компании,

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

что на протяжении многих лет ОС UNIX занимались

телекоммуникационная компания AT&T (для которой средства

программного обеспечения всегда не являлись основным бизнесом) и

университеты. В результате технология операционной системы и даже

ее исходные тексты стали доступными для широкой публики, включая

академические и коммерческие ее части. Как говорил классик, идея

должна овладеть массами. В данном случае она ими овладела. Но в

чем же, собственно, состоит идея?

Она проста и заключается в том, что операционная система должна

опираться на небольшое число не связанных с конкретной

аппаратурой концепций, в совокупности обеспечивающих мобильную

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

на эти основные концепции. В их число входят интуитивно ясные

понятия пользователя, терминала, процесса и файла. Каждое из этих

понятий в среде ОС UNIX означает именно то, что прежде всего

приходит в голову. Пользователь - зарегистрированное в среде UNIX

лицо, которому после надлежащей проверки разрешается работа в

системе. Терминал - основное орудие пользователя для работы с

системой в интерактивном режиме. Процесс - акт выполнения заранее

подготовленной программы в отдельном адресном пространстве.

Наконец, файл - универсальная абстракция ОС UNIX, означающая, в

частности, именованную область внешней памяти со структурой -

последовательностью байт, а иногда служащая для направления

ввода и/или вывода пользовательского процесса с/на физические

устройства ввода/ вывода или для связи двух или более процессов.

Операционная система UNIX не идеальна. Можно найти примеры

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

обеспечивают более мощные средства программирования и т.д. (В

качестве моих любимых примеров можно указать предшествовавшую

UNIX ОС Multics или хотя бы VAX VMS.) Однако можно совершенно

определенно сказать, что эти операционные системы существенно

более сложны в понятийном отношении.

Кроме того, благодаря правильному подбору базовых концепций и

отчасти счастливому случаю операционную систему UNIX удалось

сделать мобильной. Это означает то, что с использованием исходных

текстов операционной системы и компилятора языка Си,

генерирующего коды целевой аппаратной платформы, можно достаточно

легко и быстро получить работающий вариант операционной системы.

Скорее всего, именно это качество прежде всего принесло успех

UNIX.

Многие люди были просто счастливы, обнаружив, что при

использовании ОС UNIX они имеют более или менее единообразную

операционную среду на разных аппаратных платформах. Вспомните как

мы мучались раньше при переходе от БЭСМ-6 к ЕС ЭВМ, а потом к СМ

ЭВМ и т.д. Операционные системы этих машин были настолько

различны, что иногда приходилось тратить несколько месяцев для

вхождения в новую ОС (я помню, как были потрачены около 3-х

месяцев времени квалифицированных специалистов в области

операционных систем - ваш покорный слуга в их числе - на чтение

документации, освоение и генерацию ОС RSX-11 компании DEC).

Именно ОС UNIX дала нам новую жизнь. Примитивная операционная

система, ограниченные возможности, но обеспечение стабильности.

Мы (разработчики операционных систем) плевались вначале, ругались

с Российскими фанами UNIX и, конечно же, были правы. Но мы не

понимали в то время, что иногда приходится жертвовать фигуру в

пользу качества.


Первые программы в среде ОС UNIX поражали своей

тривиальностью. Но как было интересно обнаружить, что эти

тривиальные программы действительно работают после повторной

компиляции совсем на других компьютерах.

Конечно, расцвет ОС UNIX в России стал возможен только после

окончательного краха Российской вычислительной техники. Это не та

ОС, которая снисходительна к отдельным недостаткам вычислительной

техники, в особенности к весьма уязвимым периферийным устройствам

(в свое время мне пришлось попробовать установить ОС Демос на ЭВМ

"Электроника-82, и должен заметить, что это принесло массу

головной боли и никакого удовольствия). После перехода на

использование качественной западной вычислительной техники мы

больше никогда не имели проблем с ОС UNIX. Более того, с каждым

годом использования этой ОС количество проблем уменьшается.

Операционная система UNIX дала жизнь концепции Открытых Систем.

Этот подход обеспечивает возможности разработки мобильных (легко

переносимых с одной аппаратной платформы на другую) приложений,

масштабируемости (возможности почти линейного наращивания

эффективности приложений при возрастании аппаратных

возможностей), интероперабельности (возможности совместного

использования независимо разработанных приложений). Хотя

проектировщики и разработчики ОС UNIX не ставили перед собой эту

задачу, счастливая звезда UNIX дала возможность этой ОС стать

практической основой Открытых Систем.

Но все ли так хорошо в жизни ОС UNIX? Конечно же, нет. Мое личное

мнение по этому поводу состоит в том, что UNIX, достигая в

последнее время возможностей наиболее развитых операционных

систем, в то же время приобретает их отрицательные качества -

перегруженность, чрезмерную сложность и т.д. В частности, в

последние годы в большинстве коммерческих версий ОС UNIX в

последние годы появился механизм легковесных процессов (threads).

С одной стороны, понятно, что такое решение было наиболее простым

для потенциального обеспечения использования возможностей

симметричных мультипроцессорных вычислительных систем (SMP).

Но с другой стороны, параллельное программирование с

использованием общей памяти возвращает нас к давно прошедшей

эпохе параллельного программирования с использованием общей

памяти и явных примитивов синхронизации. Для опытных

программистов очевидно, что этот стиль принесет много головной

боли и мучений и вряд ли обеспечит много выгод.

Посмотрим, что произойдет с UNIX в будущем... Мне было больно

слышать, как отрекался от своего детища Деннис Ритчи. "Это совсем

не та система, которую мы делали",- говорил он. С другой стороны,

мы видим сегодня замечательные примеры свободно распространяемых

вариантов ОС UNIX (FreeBSD, Linux), наблюдаем интересные опыты

более удачной структуризации системы (Mach, Chorus). Мне кажется,

что мы еще поживем...

Управление соединением.

Соединение двунаправленное в смысле потока данных, но оно не является симметричным в плане обмена сообщениями GIOP. Сообщения Request, LocateRequest и CancelRequest

могут посылаться только клиентом. Сообщения Reply, LocateReply

и CloseConnection - только сервером. Сообщение ErrorMessage

может быть послано обеими сторонами. Через соединение для обмена в соответствии с протоколом GIOP могут посылаться только сообщения GIOP.

Каждое сообщение типа Request

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

Соединение может быть либо закрыто в рамках протокола, либо разорваться. Закрытие соединения может инициироваться со стороны сервера посредством посылки сообщения CloseConnection

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

При получении сообщения CloseConnection

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

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

Уровни языка

До детального погружения в язык Alpha в [5] обсуждается общий вопрос уровней языка: "Системы баз [данных] могут классифицироваться в соответствии с моделью данных, с которой взаимодействует пользователь, и [уровнями] языка, обеспечивающими это взаимодействие пользователя". Моделями данных могут быть деревья, сети или отношения; уровень языка может быть низким (Кодд также называет этот уровень "процедурным"), промежуточным (основанным на алгебре) или высоким (основанным на исчислении). Снова заметим, что Кодд относится к модели и операциям как к разным вещам! Более того, он использует термин "модель данных" в смысле модели данных конкретной базы данных, а не в общем смысле.

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

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

Аргументы этого раздела статьи Кодда демонстрируют большой уровень предсказательности. Приведем краткую сводку этих аргументов.

Защитить пользователей от суматохи представлений: "Обеспечение концептуально четкой модели данных и мощного, концептуально четкого языка манипулирования относится не только к эстетике.
Если пользователи вынуждены выбирать и принимать решения относительно потенциально не требуемых деталей представления, последствия могут быть разнообразными и дорогостоящими … Это не только аргумент в пользу того, чтобы защитить пользователей от … низкоуровневых деталей физического представления; в равной степени этот аргумент против введения … надуманного, концептуально избыточного логического представления" (немного перефразировано). Эти аргументы сегодня настолько же сильны, действительны и правильны как во время их начального появления! Печально, что наша индустрия потеряла к ним внимание (конечно, я имею в виду бесчисленные попытки заменить реляционную модель некоторой разновидностью "объектной модели").

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

Понимание и модификация программ: Этот аргумент следует из двух предыдущих. "Важна ясность намерений, [особенно] когда требуется изменить прикладную программу [и в особенности тогда, когда это изменение должно производиться людьми], не писавшими эту программу." В связи с этим Кодд предлагает сравнить работу по изменению порядка двух кванторов в Alpha-программе c той работой, которая требуется для изменения Codasyl-программы для достижения того же результата. Хороший пример!

Эволюционное развитие методов поиска: "Применение подхода исчисления позволяет успешно совершенствовать общие алгоритмы поиска, которые могут внедряться в системы баз данных без затрагивания программ пользователей." (Я бы сказал, что то же относится и к алгебраическому подходу.) Другими словами, избавление пользовательских программ от заботы об эффективности означает, что эти программы автоматически выигрывают от эволюционного -- и даже революционного -- развития технологии физического доступа к данным.

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

Поддержка специализированных языков запросов и обновления: "Многим пользователям требуются … языки, специализированные для их приложений. Высокая стоимость поддержки [таких] языков … предполагает, что нужно распознать [настолько много общих функций, насколько это возможно] и запрограммировать их раз и навсегда … [Исследования в области процессоров запросов на естественных языках] показывают, что языки, основанные на исчислении, ведут к достижению этой цели." И снова это очень правильно. Кстати, собственная более поздняя работа Кодда над системой запросов на естественном языке Rendezvous добавляет вес этому аргументу.

УРОВНИ СОГЛАСОВАНИЯ

Средства межсетевого

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

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

приложениями, так и системными средствами. Поэтому требования к системным средствам

зависят от того, какой объем согласующих функций берут на себя приложения.

Крайним

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

согласованию, кроме тех, что могут быть выполнены только аппаратно, то есть сетевыми

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

соответствующей служебной информацией, и организуют надежную доставку таких пакетов с

помощью нумерации, упорядочения, вычисления и проверки контрольных сумм. Помимо

функций по оформлению и доставке сообщений приложения в этом случае выполняют и

функции по согласованию возможных различий в сервисах локальных операционных систем,

например различий в именовании файлов, интерпретации прав доступа к файлам, способов их

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

Два других варианта

распределения функций между приложениями и системными средствами более

реалистичны.

Первый вариант - системные средства берут на себя все функции по

передаче сообщений, согласуя три или четыре нижних уровня модели OSI. Приложения в этом

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

верхних уровней модели OSI - прикладного, представительного и сеансового. Приложения

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

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

как в среде Windows NT, так и в среде UNIX, непосредственно обращаясь для отправки и

получения сообщений к средствам сетевого уровня, например к протоколу TCP (через

соответствующий интерфейс, в частности, Berkeley Sockets). В соответствии с этим вариантом

построены и корпоративные СУБД, в том числе Oracle, Informix, Sybase.

Второй вариант

- приложения вообще не выполняют функции по согласованию неоднородностей

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

данном случае должны обеспечивать взаимодействие на всех уровнях модели OSI - от

физического до прикладного. На прикладном уровне довольно иметь средства согласования

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

основана на специальном почтовом сервисе, поддерживаемом операционной системой,

например SMTP или MHS, то при работе в неоднородной в отношении этого сервиса сети

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

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

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

средства согласования протоколов файлового сервиса.




Сервер File

and Print Services for NetWare и протокол NWLink превращают сервер Windows NT Server для

клиентов NetWare в сервер NetWare3.12.

Системные средства

могут реализовывать функции по согласованию стеков протоколов частями, с помощью

нескольких программных продуктов. Часто один продукт согласует только сервисы прикладного

уровня (или один из этих сервисов),а другой - только транспортные протоколы. Например,

продукт компании Microsoft File and Print Services for NetWare обеспечивает поддержку в среде

WindowsNT только прикладных протоколов файлового сервиса и сервиса печати NetWare, но не

выполняет функций согласования транспортных протоколов. Поэтому для его работы с

клиентами NetWare на сервере необходим компонент NWLink или другой продукт,

реализующий протокол Novell IPX.

В чем нуждается администратор БД?

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

Профилактический монитор:

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

Средства диагностики:

превращают младшего АБД в старшего, позволяя последнему сконцентрироваться на других задачах

Средства анализа:

помогают при планировании роста БД и будущих затрат

Средства технического обслуживания:

помогают при резервном копировании и восстановлении данных, сокращая время операции и уменьшая число ошибок помогают при реорганизациях, экономя время, уменьшая количество ошибок и длительность профилактических окон (maintenance window) способствуют высокой доступности данных, создавая “ незаметные ” с точки зрения системы профилактические окна и помогая при резервировании / восстановлении системы.

В каком направлении развивается реляционная модель?

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

Мне хочется закончить сводкой аргументов, который представил сам Кодд (под заголовком "Whther Database Management?") в статье про Великое Сражение, рассматривая возможные альтернативы будущего систем баз данных. Начнем с предположения наличия простейшего ориентированного на программиста интерфейса с базой данных (интерфейса на уровне записей). Тогда:

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

Заключение очевидно.

Варианты использования

MS SQL Server (далее - SQL Server) может принимать и отправлять сообщения по электронной почте, используя соединение с сервером почтовых сообщений. При этом SQL Server может использовать как службу SQL Server Agent, так и службу MSSQLServer (почтовый сеанс SQLMail).

SQL Server Agent (а точнее, SQLAgentMail) чаще всего связан с выполнением административных функций. Например, этой службой можно воспользоваться для отсылки почтового сообщения оператору при возникновении предупреждения (alert'a). Установка уведомления оператора производится в окне свойств предупреждения на вкладке Ответ (Response) (рис.1)

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

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

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

Необходимо отметить, что SQL Server Agent (SQLAgentMail) и MSSQLServer (SQL Mail) самостоятельно устанавливают соединение с почтовым сервером, хотя и тот и другой могут работать с серверами Microsoft Exchange, POP3 (Post Office Protocol 3) и Microsoft Windows NT Mail.

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

Версии системы и поддерживаемые платформы.

Последними версиями СУБД Cache' являются версии 4.0 и 4.1.1. На рынке высокопроизводительных СУБД Cache' позиционируется как eDBMS, т.е. как СУБД, ориентированная на работу в сетях Internet/Intranet. Разработчику предоставляется обширный набор функций, реализующих большинство стандартных протоколов Internet, таких как SMTP, HTTP, POP3 и др. Кроме этого, разработчику предоставляется развитая технология разработки динамических web-приложений CSP. Поэтому при установке проверяется наличие web-сервера и производится автоматическое конфигурирование подсистемы.

Утилиты администрирования и инструментарий разработки приложений в версиях 4.0. и 4.1.1. не отличаются, однако имеются существенные различия в формате хранения данных на диске и использовании ОЗУ компьютера временными библиотеками. Так, к примеру, в версии 4.1.1 блок данных, который считывается с диска, может быть равным 8 КБ, в то время, как в версии 4.0. максимальный размер блока равен 2КБ. Разумеется, при считывании блоков данных большего размера с жесткого диска сокращается количество I/O операций, что приводит к повышению производительности системы. Кроме этого, в версии 4.1.1. произведена оптимизация функций журналирования, использования блокировок и других функций.

Описание поддерживаемых СУБД Cache' платформ, языков, web-серверов и браузеров для Cache' версии 4.1.1. приводится в последующих таблицах.

Таблица 2. Поддерживаемые платформы.

ПлатформаОперационная системаUnicodeODBCSQL ШлюзNotes

Alpha	OpenVMS 7.2, 7.3	+
Alpha	Tru64 UNIX 5.1	+
HP	HP/UX 11i
IBM P Series	AIX 4.3.3, 5.1	+
Red Hat Linux (Intel)	7.1	+	+
Sun Solaris (SPARC)	2.8	+			64-bit only
SuSE Linux (Intel)	7.1	+	+
Windows 95, 98, ME, NT 4 (SP4, SP5, SP6), 2000		+	+	+

СУБД Cache' поддерживает множество национальных языков (Таблица 3.). Кроме поддержки языков, специальная утилита CNLS позволяет создавать собственные таблицы трансляции из одного набора символов в другой, задавать различные способы вывода непечатных символов и предоставляет ряд других возможностей.
При инсталляции под ОС Windows Cache' автоматически определяет региональные настройки операционной системы и устанавливает соответствующую схему локализации. Также предоставляется возможность установки Unicode (16bit) версии Cache'.

Таблица 3. Поддерживаемые национальные языки.

Язык8-Bit набор символовЛокализация утилит

Чешский	Latin 2	-
Голландский	Latin 1	+
Английский	Latin 1	+
Французский	Latin 1	+
Немецкий	Latin 1	+
Греческий	Latin G	-
Иврит	Latin H	-
Итальянский	Latin 1	+
Японский	N/A	+
Корейский	N/A	+
Польский	Latin 2	-
Португальский	Latin 1	+
Русский	Latin C	+
Испанский	Latin 1	+

Для русского языка поддерживаются обе таблицы кодировок: Windows-1251 и ISO 8859-5.

СУБД Cache' поддерживает архитектуру, в которой web-сервер и сервер БД могут находиться на разных компьютерах.

Таблица 4. Поддерживаемые Web-серверы

Web-серверПлатформа

Microsoft IIS / PWS	Windows 95, 98, NT, 2000
Apache 1.3.12	Alpha Tru64 UNIX FreeBSD (Intel) HP HP/UX IBM PowerPC AIX Red Hat Linux (Intel) Sun Solaris (SPARC) SuSE Linux (Intel) TurboLinux (Intel) Windows
Netscape / Sun iPlanet 4.0	Alpha Tru64 UNIX HP HP/UX IBM PowerPC AIX Red Hat Linux (Intel) Sun Solaris (SPARC)
Compaq Secure Web Server 1.0	Alpha OpenVMS 7.3

CSP поддерживает следующие браузеры:

Таблица 5. Поддерживаемые браузеры.

Web браузерВерсия

Netscape	3.0 4.0 4.7
Internet Explorer	4.0 5.0 5.5 6.0

Как было сказано ранее, Cache' может выступать в роли шлюза к реляционным базам данных (РБД). Официально поддерживаются следующие РБД:

Таблица 6. Поддерживаемые РБД.

РБДВерсия

Microsoft SQL Server	7.0 2000
Oracle	8 9i

Виды окружений ИС Oracle

Тип и размер центра сильно зависит от величины и возможностей компании. Маленькие центры, такие как dot-coms (.com - организации, имеющие только сайт в Интернете - прим.ред .) , небольшие производственные фирмы, или даже крупные отделы, только-только переходящие на Oracle, вполне могут обойтись одним АБД, выполняющим весь спектр задач. С одной стороны это хорошо: ясно к кому обращаться, кто за все отвечает. С другой стороны не все так однозначно. АБД в одних вопросах более копметентны нежели в других в зависимости от подготовки, поэтому иногда нелегко найти специалиста, который бы одновременно хорошо разбирался в администрировании приложений и был на “ ты ” с "железом" и средствами резервирования\восстановления данных Oracle. Кроме того, возлагая всю ответственность на одного человека, следует учитывать его склонности к обучению, сверхурочной работе и т.п.

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

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

Visual Foxpro 7: высокопроизводительное средство разработки баз данных

В России Microsoft Foxpro долгое время был самым популярным инструментом для создания баз данных. В настоящее время его несколько потеснили такие средства разработки как Delphi, MS Access и MS Visual Basic. Но и сейчас Foxpro остается самым популярным инструментом для разработки баз. На нем написано БОЛЬШЕ ВСЕГО бухгалтерских, экономических и других приложений, связанных с расчетами и хранением информации. И вот почти вышла очередная, седьмая версия Visual Foxpro (сейчас идет тестирование beta-версии). Чем Visual FoxPro 7 отличается от предыдущих версий?

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

Новые дополнения включают:

Технологию IntelliSense

Расширения редактора

Закрепление окон

События на объект Database Container (DBC)

Поддержка Active Accessibility

Список задач

Просмотр объектов

Внешние соединения

В ANSI SQL внешние объединения реализованы посредством расширенной формы предложения FROM:

SELECT * FROM tab1 FULL JOIN tab2 ON col1=col2 - полное внешнее объединение SELECT * FROM tab1 LEFT JOIN tab2 ON col1=col2 - полное левое объединение SELECT * FROM tab1 RIGHT JOIN tab2 ON col1=col2 - полное правое объединение

В Oracle не реализовано расширенное предложение FROM для реализации внешних соединений (начальный уровень ANSI SQL этого не требует) как это сделано в ANSI. Однако реализован свой собственный синтаксис для получения левых и правых внешних объединений. Полные внешние объединения в Oracle не реализованы.

Для реализации левого внешнего объединения используется оператор (+) в предложении WHERE, который ставиться справа от столбца, по которому осуществляется соединение, справа от знака =. Аналогично для правого объединения оператор (+) ставиться справа от столбца слева от знака равенства.

SELECT * FROM tab1 LEFT JOIN tab2 ON col1=col2 - аналогичен запросу: SELECT * FROM tab,tab2 WHERE col1=col2 (+)

SELECT * FROM tab1 RIGHT JOIN tab2 ON col1=col2 - аналогичен запросу: SELECT * FROM tab,tab2 WHERE col1 (+)=col2

Возражения Критика A

Relvar и присваивание критикуются в длинном ряде сообщений Хью Дарвену от Критиков A и B [1]. Весь обмен сообщениями был вызван вопросом по теме, которая лишь отдаленно относится к обсуждаемой нами проблеме (и поэтому далее я буду игнорировать суть этой темы). В своем ответе на этот вопрос Критик A сказал следующее:

Мы с [Критиком B] не соглашаемся с relvar и думаем, что и Кодд не согласился бы.

Хью ответил:

Меня ставит в тупик ваше несогласие с relvar … Может быть, вы не согласны и с INSERT, DELETE, UPDATE и реляционным присваиванием? Кодд точно их признавал. Целевым операндом для всех этих операций является реляционная переменная (для краткости, relvar).

На это Критик A ответил:

Более точно, мы не согласны с явными relvar, и Кодд использовал «изменяемые во времени отношения», чтобы избежать этого понятия … Принимая во внимание, что одной из основных целей Кодда была простота, мы думаем, что он мог сознательно отказаться от введения понятия relvar. Очевидно, он был осведомлен о временном измерении баз данных, однако, насколько нам известно, он никогда не включал семантику изменения во времени в свою формальную модель. Если бы он это сделал, то язык множеств и математических отношений был бы деформирован, поскольку, как отмечает сам Дейт, у каждого объекта в языке имеется фиксированное значение. Поскольку связи внутри отношений Кодда и между ними вычисляются в фиксированной точке времени, становится возможным использование семантики множеств … Хотя концептуально «отношения, изменяемые во времени» Кодда должны быть в чем–то похожи на relvar, их «толкование» позволило Кодду придерживаться простых множеств (которые не могут изменяться) и при этом справляться с обновлениями … Возможно, существенным является то, что позже в своей статье про RM/T он называл insert-update-delete «правилами перехода» («transition rules»), а не операциями.

И в следующем электронном сообщений он (Критик A) продолжил:

Пожалуйста, обратите внимание, что не утверждается отсутствие relvar.
Утверждается только то, что наличие их в явном виде в языке данных не является хорошей идеей, поскольку это порождает трудности из-за проблем с не фиксированными множествами. Трудно поверить, что Кодд не думал о переменных, и что он использовал термин «отношение, изменяемое во времени» необдуманным образом.

В этом месте я хотел бы вставить некоторые собственные подробные ответы на различные замечания Критика A. Для удобства ссылок я повторяю и переномеровываю эти замечания. Более точно, мы не согласны с явными relvar.

Как кажется, это утверждение означает, что Критик A соглашается с «неявными» relvar, какими бы они не были. Следовательно, похоже, что relvar плохи, только если они являются явными. Я не понимаю эту позицию. Кодд использовал «отношения, изменяемые во времени», чтобы избежать [явных переменных].

Это замечание можно интерпретировать двумя способами. Первая интерпретация: Кодд использовал понятие «отношений, изменяемых во времени», чтобы избежать потребности в понятии relvar (явных или каких-либо других). Если имелась в виду эта интерпретация, то мне хотелось бы точно знать, в чем состоит разница между этими двумя понятиями; наши критики утверждают, что это различие существует, но они никогда не говорят, в чем оно состоит.

Вторая интерпретация: Кодд использовал термин «отношение, изменяемое во времени», чтобы избежать потребности в использовании термина «relvar» (опять же явных или каких-либо других). Если имеется в виду эта интерпретация, то я просто ей не верю. Я работал с Коддом много лет, хорошо его знал и много раз обсуждал с ним именно этот вопрос. Хотя я не думаю, что полностью знаком с его позицией по этому поводу, могу с достаточной уверенностью заявить, что у него отсутствовали какие-либо скрытые намерения относительно использования термина «отношение, изменяемое во времени»; это был всего лишь используемый им термин, и я не думаю, что он придавал этому термину слишком большое значение.

Более детально (вопреки обеим приведенным выше возможным интерпретациям замечания Критика A), статьи [3-4], в которых Кодд впервые использовал данный термин, не содержат ни малейшего указания на то, что он ввел этот термин, чтобы избежать обсуждаемых переменных и/или обновлений.


Напротив, в действительности, в обеих этих статьях он явно обсуждал вопрос реляционного обновления. Процитирую: «Вставки принимают форму добавления новых элементов к объявленным отношениям … Удаления … принимают форму удаления элементов из объявленных отношений». Более того (на случай, если вам непонятно, какой смысл вкладывал Кодд в термин объявленное отношение), и в [3], и в [4] явно говорилось, что объявленное отношение является именованным отношением (конечно, «изменяемым во времени»), которое (a) явно объявляется системе, (b) описывается в системном каталоге, (c) может обновляться (так что объявленное имя в разное время обозначает разные отношения – т.е. разные значения отношений), и (d) ссылки на него могут использоваться в запросах (и, вероятно, в ограничениях). По мне, это выглядит как relvar, причем явная relvar. Принимая во внимание, что одной из основных целей Кодда была простота, мы думаем, что он мог сознательно отказаться от введения понятия relvar.

Я не нахожу никаких доказательств в работах Кодда в пользу того, что он намеревался пойти на что-то подобное; на самом деле, я нахожу много доказательств в пользу обратного – не только в процитированных замечаниях про вставки, удаления и объявленные отношения, но и в многочисленных замечаниях из других его работ. Очевидно, он был осведомлен о временном измерении баз данных, однако, насколько нам известно, он никогда не включал семантику изменения во времени в свою формальную модель.

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



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

Фразы «семантика множеств» и «теоретико-множественная семантика» появляются в [1] неоднократно, но я плохо понимаю, что они означают. На основе других замечаний из [1] я могу догадываться, что имеется в виду нечто, включающее такие операции над множествами, как объединение и пересечение, но не включающее присваивание; но почему тогда нет речи про (например) «семантику арифметики», означающую нечто, включающее такие арифметические операции, как «+» и «*», но не включающее присваивание? (Я не буду повторять эти вопросы каждый раз при появлении непонятных фраз; пусть этому будет посвящен только один этот пункт.) В общем, я не думаю, что это замечание Критика A означает что-то иное, кроме того, что в каждый заданный момент времени значением relvar является отношение (тело которого, конечно, является множеством: а именно, множеством кортежей). Если имеется в виду именно это, то, конечно, я согласен, но я не могу считать этот факт очень существенным. Хотя концептуально «отношения, изменяемые во времени» Кодда должны быть в чем–то похожи на relvar, их «толкование» позволило Кодду придерживаться простых множеств (которые не могут изменяться) и при этом справляться с обновлениями.

Я согласен с ответом Хью на это замечание. Цитирую:

Хорошо, но кто-нибудь должен объяснить мне, в чем состоит разница [между relvar и «отношением, изменяемым во времени»] … Если кто-то ходит, как утка, плавает, как утка, летает, как утка, и крякает, как утка, то кто это на самом деле?

См. также мои собственные предыдущие комментарии на ту же тему. Замечание: Я мог бы добавить, что, на самом деле, я не понимаю, что здесь означает и термин «толкование» («gloss»), но, видимо, это не важно. Возможно, существенным является то, что позже в своей статье про RM/T он называл insert-update-delete «правилами перехода» («transition rules»), а не операциями.



Нет, он этого не делал. На самом деле, он говорил следующее [6]:

Все вставки в отношения, модификации отношений и удаления из отношений ограничиваются следующими двумя правилами [и он приступает к формулировке определений правил целостности сущности и ссылок. Затем он явно утверждает, что реляционная модель включает эти два правила, и называет их обобщенно] правилами insert-update-delete.

Отметим явное упоминание «вставок в отношения, модификаций отношений и удалений из отношений»! (Кстати, целевой объект таких операций в этой статье по-прежнему называется «отношением, изменяемым во времени».) Пожалуйста, обратите внимание, что не утверждается отсутствие relvar. Утверждается только то, что наличие их в явном виде в языке данных не является хорошей идеей, поскольку это порождает трудности из-за проблем с не фиксированными множествами.

Насколько я понимаю эти замечания (а я их понимаю не слишком хорошо), они выглядят всего лишь как протянутая мне рука. См. мой ответ на замечание Критика A no. 1. Трудно поверить, что Кодд не думал о переменных, и что он использовал термин «отношение, изменяемое во времени» необдуманным образом.

Нет, это не так. См. мои ответы на замечания Критика A no. 2 и 4.

Я уже цитировал часть ответа Хью на замечания Критика A. Далее в этом ответе говорится:

Я думаю, что «реляционное присваивание» является термином Кодда и одним из его двенадцати правил … Описания Кодда присваивания, вставки, модификации и удаления, приведенные на стр. 87-94 книги о RM/V2, выглядят неотличимыми от Tutorial D ...

Да, я могу подтвердить, что Кодд использовал термин реляционное присваивание в «книге о RM/V2» [8], хотя, на самом деле, не в статье о «двенадцати правилах» [7]. (Одно из этих правил действительно относится к INSERT, DELETE и UPDATE, но нет правила, относящегося к присваиванию как таковому.) Но он определенно включил понятие присваивания и явный синтаксис для этого понятия в существенно более ранние работы – в статью про RM/T (которая появилась в 1979 г.), а может быть, в еще более ранние публикации.



Отклоняясь от темы, я должен сказать, что совсем не очевидно то, что средства RM/V2 в этой области являются «неотличимыми от средств Tutorial D» (и на самом деле, это не так; например, в RM/V2 выполнение некоторых операций удаления приводит к появлению в базе данных неопределенных значений, и в то же время не поддерживается множественное присваивание). Более того, в тексте книги о RM/V2 на стр. 87-94 содержится много материала, не имеющего непосредственного отношения к семантике операций, включая многие детали, вообще не относящиеся к абстрактной модели – например, «Когда СУБД запрещает вставку строк (чтобы избежать появления в результате дублирующих строк), включается индикатор строк-дубликатов)»; «Если для целевого отношения существуют один или несколько индексов, то СУБД будет автоматически обновлять эти индексы для поддержки вставленных строк» и т.д. Имеется также несколько предписаний, непосредственно конфликтующих с Третьим Манифестом – например, «Домен любого столбца T, в котором значения порождаются посредством функции, определяются [в каталоге] как порождаемые функцией (function-derived), поскольку СУБД обычно не может быть более конкретной»; «Реляционная модель включает в некоторые манипуляционные операции опцию каскадирования (cascading option) и т.д. При всем этом я, конечно, согласен с Хью в том, что общие функциональные возможности, определяемые в этой части книги про RM/V2, по существу, аналогичны соответствующим возможностям Tutorial D.

В дополнение ко всему сказанному выше замечу, что еще в 1971 г. Кодд предлагал явную поддержку INSERT, DELETE и UPDATE (хотя и не присваивания как такового; я имею в виду его статью про «Подъязык данных ALPHA» [5], в которой 12 примеров (из 32-х, т.е. почти 40%) являлись примерами операций обновления.

Возражения Критика B

После обсуждавшегося выше обмена сообщениями между Критиком A и Хью к переписке подключился Критик B (по сути дела, принявший дела у Критика A, который в переписке больше не участвовал). В своем первом сообщении, помимо прочего, Критик B сказал следующее:

Объединение теоретико-множественного языка (в котором имеется только операция эквивалентности) и вычислительного языка (в котором имеются как операция присваивания, так и операция эквивалентности) приводит к путаной семантике, которую ни Хью, ни Крис не обсуждали и даже не подтверждали. Кроме того, как кажется, к Третьему Манифесту не применялись какие-либо результаты из обширной литературы, посвященной неразрешимости и неполноте.

Да, действительно в Третьем Манифесте предписываются, а в Tutorial D (подобно любому известному мне императивному языку) поддерживаются «как операция присваивания, так и операция эквивалентности». На самом деле, в Манифесте предписываются, а в Tutorial D поддерживаются три следующие операции:

• Логическая эквивалентность: Если p и q – предикаты, то эквивалентность (p) EQUIV (q) – используется не реальный синтаксис Tutorial D – это также предикат, при вычислении которого получается TRUE в том и только в том случае, когда при вычислении p и q получается одно и то же истинностное значение.

•       Равенство значений «=»: Значения v1 и v2 являются равными в том и только в том случае, когда они являются одним и тем же значением.

•       Присваивание «:=» (реляционное или иное): Присваивание приводит к тому, что заданное значение v присваивается заданной переменной V (требуется, чтобы после этого результатом сравнения V = v было TRUE).

Я хотел бы особенно тщательно разъяснить сравнение значений, потому что некоторые дальнейшие замечания Критика B наводят на мысль о наличии некоторого разрыва в коммуникации в этой области. Как я уже говорил, значения v1 и v2 являются равными в том и только в том случае, когда они являются одним и тем же значением (и я замечу мимоходом, что для этого понятия вместо термина равенство можно было бы разумным образом использовать слово тождество (identity)).
Наша позиция, отраженная в Манифесте, состоит в том, что любое значение – например, целое число 3 – существует (a) всегда и (b) в точности одно во вселенной (и всегда существовало), но одновременно может существовать много различных местонахождений (occurrence), или проявлений (appearance) этого значения, во многих разных местах. И если в двух таких «местах» в одно и то же время содержатся проявления одного и того же значения, то сравнение этих двух «мест» в этот момент времени на равенство выдаст TRUE (они «уподобятся равным»). Вот некоторый текст из [10], проясняющий общую ситуацию:

<цитата>

Заметим, что имеется логическое различие между значением как таковым и проявлением этого значения – например, проявлением в качестве текущего значения некоторой переменной или значения некоторого атрибута внутри текущего значения некоторой relvar. Каждое такое проявление внутренне состоит из некоторого физического представления данного значения (и у различных проявлений одного и того же значения могут иметься разные физические представления). Таким образом, также имеется логическое различие между проявлением значения, с одной стороны, и физическим представлением этого проявления, с другой стороны; может иметься даже логическое различие между физическими представлениями, используемыми для различных проявлений одного и того же значения. Однако при всем этом обычно вместо оборота физическое представление проявления значения используется сокращенная форма проявление значения, или (чаще) просто значение, если это не приводит к двусмысленности. Заметим, что проявление значения является модельным понятием, а физическое представление проявления является понятием реализационным – например, пользователям, конечно, могло бы понадобиться знать, содержат ли две переменные проявления одного и того же значения, но им не нужно знать, используется ли в этих проявлениях одно и то же физическое представление.

Пример: Пусть N1 и N2 – это переменные типа INTEGER. Тогда после следующих присваиваний и N1, и N2 будут содержать проявление целого значения 3.


Соответствующие физические представления могут быть, а могут и не быть одинаковыми (например, для N1 могло бы использоваться двоичное представление, а для N2 – упакованное десятичное представление), но это никак не затрагивает пользователя.

N1 := 3 ;

N2 := 3 ;

</цитата>

Есть ли что-нибудь неправильное в представленной выше ситуации? Замечание: Если (как это говорится в следующем утверждении Критика B) ответ на этот вопрос состоит в том, что такой подход приводит к неразрешимости, то я уже занимался этой проблемой в двух сопутствующих статьях [11-12] и не хотел бы больше ее здесь обсуждать. Но на основе приведенной выдержки из сообщений Критика B я не могу точно заключить, что имелась в виду именно эта проблема.

Мне также хотелось бы знать, в чем состоит «путаность» семантики Tutorial D. Хью задавал тот же вопрос:

Пожалуйста, покажите на конкретных примерах на Tutorial D, где наша семантика является «путаной». Пожалуйста, объясните также, что, по Вашему мнению, делает семантику путаной. Я понимаю под этим недетерминированность (обнаруживаемую, например, в SQL), но я полагаю, что у нас ее нет.

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

Ваша просьба, чтобы разъяснил ошибки Tutorial D на основе примеров, представленных на Tutorial D, является абсурдной! Ни на каком языке вы не можете привести примеры того, что этот язык НЕ позволяет делать!

Я вернусь к этим замечаниям Критика B немного позже.

Так или иначе, Хью написал пространный ответ на протест Критика B. Вот выдержка из этого ответа:

<цитата>

Если в языке баз данных отсутствуют именованные relvar, то как в нем выражаются обновления и ограничения? И как выражаются запросы? … Ответы должны сопровождаться примерами, представленными в некотором конкретном синтаксисе. Это требование является обязательным, и я мог бы не реагировать на ответ, в котором не предпринимается попытка выполнить это требование. Синтаксис должен основываться (там, где это уместно) на реляционной алгебре …



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

</цитата>

Критик B снова вступил в перепалку:

<цитата>

Для ясности: я НЕ предлагал избавиться от понятия переменных отношений как таковых …

Ваш вопрос затрагивает суть огромного различия в семантике теоретико-множественных и вычислительных языков … Теоретико-множественным аналогом семантики «обновления» являются два множества (например, {A} и {B}), соединенные правилом «преобразования множеств», или «перехода». С семантической точки зрения, это ОЧЕНЬ отличается от того, что {A} становится {B} путем выполнения некоторой операции обновления, поскольку – в теоретико-множественных языках – {B} не заменяет {A}, и поэтому нет никакого присваивания значений некоторой переменной. Вместо этого оба множества всегда существуют и связываются некоторым известным образом.

Проблема, порождаемая объединением семантики теоретико-множественного и вычислительного языков некоторым полностью неопределенным образом, делает Третий Манифест настолько же дефектным, насколько дефектен SQL по причине наличия проблемы неопределенных значений!

Ваша просьба, чтобы я разъяснил ошибки Tutorial D на основе примеров, представленных на Tutorial D, является абсурдной! Ни на каком языке вы не можете привести примеры того, что этот язык НЕ позволяет делать!

Я не знаю, как в Tutorial D интерпретировать «эквивалентность» – иногда, как кажется, вам требуется теоретико-множественное понятие (т.е. установление тождественности), а иногда – вычислительное понятие (установление эквивалентности значений). Если отказаться от первого понятия, то как в Tutorial D будет поддерживаться вывод? А если не отказываться, то как согласовать это с присваиванием, являющимся чуждым для теоретико-множественной семантики, в которой отсутствует понятие переменной?



</цитата>

На все это у меня имеются собственные подробные ответы:

Для ясности: я НЕ предлагал избавиться от понятия переменных отношений как таковых.

Это утверждение кажется родственным замечанию Критика A о том, что (по-видимому) явные relvar являются плохими, а с неявными relvar все в порядке. Я по-прежнему не могу понять, о чем здесь говорится.

Ваш вопрос затрагивает суть огромного различия в семантике теоретико-множественных и вычислительных языков.

Я полагаю, что имеется в виду вопрос, в котором Хью спрашивал, как выполнять обновления без поддержки relvar; в противном случае я не понимаю это предложение.

Теоретико-множественным аналогом семантики «обновления» являются два множества (например, {A} и {B}), соединенные правилом «преобразования множеств», или «перехода».

Замечу, что Критик A также ссылался на правила перехода (хотя его ссылка была неправильной).

С семантической точки зрения, это ОЧЕНЬ отличается от того, что {A} становится {B} путем выполнения некоторой операции обновления, поскольку – в теоретико-множественных языках – {B} не заменяет {A}, и поэтому нет никакого присваивания значений некоторой переменной. Вместо этого оба множества всегда существуют и связываются некоторым известным образом.

Во-первых, в Третьем Манифесте никогда не используется оборот «одно множество становится другим»; в нем говорится о переменной, у которой имеется одно значение в один момент времени и другое значение в другой момент. Во-вторых, в Манифесте никогда не говорится, что одно множество заменяет другое; поскольку все значения «существуют всегда», «всегда существуют» и все множества (в действительности, множества являются значениями). Однако в Манифесте действительно говорится об обновлении переменной, когда проявление одного значения (в этой переменной) заменяется проявлением другого значения. На самом деле, мы очень стремились добиться в Манифесте четкости в изложении этих аспектов – в частности, четкости в проведении логического различия между значением как таковым и проявлением этого значения в некотором контексте, что я и пытался разъяснить несколькими страницами выше.


Меня искренне расстраивает такое полное непонимание. В целом, в этих двух предложениях Критик B пытается смутно сформулировать то, что формулируется в Манифесте предельно четко.

Проблема, порождаемая объединением семантики теоретико-множественного и вычислительного языков некоторым полностью неопределенным образом, делает Третий Манифест настолько же дефектным, насколько дефектен SQL по причине наличия проблемы неопределенных значений!

Что это в Третьем Манифесте является «полностью неопределенным»? Вот в приведенном замечании неопределенным является смысл «семантики вычислительных языков» – не говоря уже про «теоретико-множественную семантику», понятие, которое я уже комментировал. Кроме того, что означает фраза «настолько же дефектным, насколько дефектен SQL по причине наличия проблемы неопределенных значений»? Неопределенные значения ведут к появлению многозначной логики, которая в большинстве авторитетных источников признается ужасной проблемой; но мне неизвестно, каким образом настойчивое требование Манифеста наличия «семантики вычислительных языков» порождает потребность отхода от традиционной двухзначной логики. Так что ссылка на неопределенные значения – это всего лишь отвлекающий маневр, а утверждение о том, что Манифест «настолько же дефектен, насколько дефектен SQL по причине наличия проблемы неопределенных значений» похоже на сравнение яблок с апельсинами.

Замечание, добавленное позже: Мне пришло на ум, что фраза «проблема, порождаемая объединением семантики теоретико-множественного и вычислительного языков» может относиться к тому, что мы категорически запрещаем: к возможности присваивания некоторой переменной нового значения в процессе вычисления некоторого выражения, включающего эту переменную. Мы согласны, что допущение такой возможности может привести к вредным последствиям (хотя в некоторых языках она допускается). По этой причине от любого языка, соответствующего Третьему Манифесту, требуется, помимо прочего, удовлетворение следующим предписаниям (и, конечно, Tutorial D удовлетворяет этим предписаниям): С синтаксической точки зрения, никакое присваивание не является выражением; в более общем смысле, никакой вызов операции обновления не является выражением. Следовательно, с синтаксической точки зрения, никакое выражение (в частности, никакое реляционное выражение) не может включать присваивание или, в более общем смысле, вызовов операции обновления любого вида. В отличие от этого, выражение (в частности, реляционное выражение) может включать вызов операции только чтения.


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

Из всего этого следует, что если заданное реляционное выражение exp включает какие-либо ссылки на некоторую relvar R, то в ходе вычисления exp все эти ссылки обозначают одно и то же: отношение r, являющееся значением R перед началом вычисления exp.

Ваша просьба, чтобы разъяснил ошибки Tutorial D на основе примеров, представленных на Tutorial D, является абсурдной! Ни на каком языке вы не можете привести примеры того, что этот язык НЕ позволяет делать!

Я думаю, что речь идет о том (см. [11-12]), что в Tutorial D допускаются выражения, которые невозможно вычислить. Если это так, то должна иметься возможность привести пример такого выражения. Я согласен, что это может быть трудно сделать – в том смысле, что может получиться очень сложное выражение, – но Критик B говорит, что это невозможно. Так что, по-видимому, имеется в виду что-то другое, являющееся «неправильным» в Tutorial D. Скорее всего, это именно так, поскольку далее Критик B упоминает нечто такое, что язык «НЕ позволяет делать», а как раз формулировать выражения, которые невозможно вычислить, он позволяет (по крайней мере, по мнению Критика B).

Теперь, после всего сказанного, мне хотелось бы знать, почему аналогичные критические замечания не предъявлялись к оригинальным статьям Кодда [3-4] или его языку ALPHA [5]? И если я прав в том, что подобные замечания применимы к работами Кодда, то мне хотелось бы увидеть язык, к которому они не применимы.

Я не знаю, как в Tutorial D интерпретировать «эквивалентность» – иногда, как кажется, вам требуется теоретико-множественное понятие (т.е. установление тождественности), а иногда – вычислительное понятие (установление эквивалентности значений). Если отказаться от первого понятия, то как в Tutorial D будет поддерживаться вывод? А если не отказываться, то как согласовать это с присваиванием, являющимся чуждым для теоретико-множественной семантики, в которой отсутствует понятие переменной?



Боюсь, что я далек от полного понимания этих замечаний. Я думаю, что Критик B называет здесь «установлением тождественности» то, что мы называем равенством. Я думаю, что Критик B называет здесь «установлением эквивалентности значений» то, что я ранее упоминал (в сноске) под условным названием «равенства проявлений». Я уже пытался пояснить эти конструкции (а именно, равенство и «равенство проявлений») и полагаю, что в Манифесте совершенно явно написано, когда и где они используются, и в чем состоит их семантика. Что касается «поддержки вывода [в Манифесте]», то я думаю, что Критик B имеет здесь в виду процесс определения значения реляционного выражения (в частности, процесс формирования ответа на запрос). Если это действительно так, в Манифесте то этот процесс описан совершенно явным образом.

Более того, я не вижу, в каком качестве на этой картине фигурируют присваивание и «понятие переменной», поскольку – как я постараюсь пояснить немного позже – ни то, ни другое не играет никакой роли в этом процессе.

В одном из последующих сообщений Критик B говорит следующее:

Мое пожелание состоит не в том, чтобы ввести язык баз данных без имен переменных и т.д., а в том, чтобы в Tutorial D явным образом разделялась теоретико-множественная и вычислительная семантика. Вы стремитесь к единому языку с обоими видами семантики, а я не уверен, что это возможно хотя бы потому, что (например) эквивалентность истинностных значений отличается от эквивалентности кардинальных и ординальных значений.

Как я говорил ранее, в Tutorial D имеется логическая эквивалентность (которая, возможно, является тем же самым, что Критик B называет здесь эквивалентностью истинностных значений), а также равенство значений, а также присваивание (которое ранее Критик B также выдвигал в качестве некоторой разновидности эквивалентности). Теперь он говорит еще и об «эквивалентности кардинальных и ординальных значений». Я не знаю, относится ли эта эквивалентность к одному из трех видов, поддерживаемых в Tutorial D; я не знаю, один или два вида эквивалентности соответствуют «эквивалентности кардинальных и ординальных значений»; я даже не знаю, положительно или отрицательно оценивает поддержку в Tutorial D (если она имеется) этого вида (или этих видов) эквивалентности.


Так или иначе, Хью ответил следующее:

Я объяснил, что мы имеем в виду под «равенством», в ответ на несколько Ваших утверждений, показывающих, что Вас беспокоит наличие к нас двух разных видов. (Я не понимаю оба этих вида, но наша единственная разновидность равенства – это, по-видимому, именно то, наличие чего Вы желаете. См. RM-предписание 8.)

Здесь Хью называет «нашим единственным видом» именно равенство значений, семантика которого точно определена в RM-предписании 8 Третьего Манифеста. На это Критик B ответил следующим образом:

Я осознаю Ваше непонимание того, что имеются два вида «равенства» (на самом деле, много видов) … В лучшем случае, я могу предположить, что в разговорах про Tutorial D у Вас блокируется способность к мышлению в чисто теоретико-множественном духе. Позвольте мне просто сказать, что эквивалентность значений – это не то же самое, что тождественность. Значение имеет отношение к сравнению измерений количественных свойств, в то время как тождественность относится к тому, что математики часто называют сущностями («вещами»).

Хорошо, я вынужден повторить некоторые вещи, которые уже говорил (и я приношу извинения за многословность) … но эти замечания заставляют меня заподозрить, что Критик B не понял, какой смысл вкладывается в Третьем Манифесте в термин значение. Я также подозреваю, что он называет «эквивалентностью значений» то, что мы имеем в виду, говоря про равенство различных проявлений одного и того же значения (а в этом случае мы сказали бы, что – по определению – имеется только одно значение как таковое). Еще я подозреваю, что это его непонимание (нашего использования терминов) приводит его к необоснованной критике. Я также думаю, в противоположность тому, что говорит здесь Критик B, что наша «эквивалентность значений» (раньше я использовал термин «равенство значений») является «тем же самым, что и тождественность»: два проявления являются равными («равными по значению»?) тогда и только тогда, когда они являются проявлениями тождественных значений.


Теперь насчет того, что имеется много видов равенства: Может быть, действительно можно определить много видов равенства (на самом деле, я не знаю этого), но я думаю, что важным является то, которое мы определяем в RM-предписании 8 – и именно к этому виду сравнения мы обращаемся (явно или неявно), когда говорим о равенстве в контексте Третьего Манифеста.

В этом же сообщении Критик B также сказал следующее:

Я не определяю, как, по моему мнению, должны выражаться обновления базы данных, за исключением того, что мы можем безопасно использовать теоретико-множественное представление, для которого имеются и «канонический» метод, и «каноническая» семантика. Я возражаю против присваивания, поскольку считаю его чуждым теоретико-множественному представлению и заимствованному из «семантики ‘до и после’», являющейся в своей основе процедурной.

Мои ответы: Я не определяю, как, по моему мнению, должны выражаться обновления базы данных.

Как я говорил раньше (цитируя Хью), в предложении по отказу от переменных отношений должны демонстрироваться две важные вещи: во-первых (и это наиболее важно), альтернативный способ обновления базы данных; во-вторых, преимущества этого альтернативного способа над присваиваниями relvar. Меня просто расстраивает, когда нам говорят снова и снова, что наш подход не работает – в особенности, когда при этом явным образом не говорят, почему он не работает; в особенности, когда, по существу, тот же самый подход поддерживается во всех императивных языках с момента появления языков программирования, – и в то же время не предлагают никакого альтернативного подхода, который бы работал.

Мы можем безопасно использовать теоретико-множественное представление, для которого имеются и «канонический» метод, и «каноническая» семантика.

Мне неясен смысл этих наблюдений.

Я возражаю против присваивания, поскольку считаю его чуждым теоретико-множественному представлению и заимствованному из «семантики ‘до и после’», являющейся в своей основе процедурной.

Предположим в целях дискуссии, что (a) в теории множеств действительно нет понятия присваивания, и (b) имеется потребность в обновлениях. (Со своей стороны я не испытываю трудностей в принятии этих предположений.) Тогда очевидным выводом является не врожденная дефектность присваивания; скорее, можно счесть, что сама теория множеств не подходит в качестве теоретической основы языков программирования баз данных.


Однако Критик B утверждает, что присваивание и теория множеств (или «теоретико-множественное представление») не согласуются друг с другом – т.е. они действительно конфликтуют, и если мы поддерживаем одно из них, то не можем поддерживать другое. Если это утверждение истинно, то тем хуже для теории множеств; но, честно говоря, я не вижу причин, по которым это может быть правдой. Замечание: замените в приведенных выше замечаниях «теорию множеств» на «логику», и я подпишусь и под этой формой своего заключительного довода.

Более того, понятие «семантики ‘до и после’» на самом деле подразумевается наличием присваивания. Однако более важно то, что она подразумевается тем, как работает время в нашей вселенной – лучше сказать, порождается основными свойствами времени! (Я думаю, что и «врожденная процедурность» порождается свойствами времени в нашей вселенной, если мы согласимся, что «процедурность» означает всего лишь выполнение одного действия за другим, последовательно; однако здесь проблема состоит в том, что ярлык «процедурности» обычно применяется в смысле «низкоуровневой процедурности» и поэтому почти всегда используется с уничижительным оттенком.) Если теория множеств не может справиться с «семантикой ‘до и после’», то тем хуже для теории множеств. Замечание: замените в приведенных выше замечаниях «теорию множеств» на «логику», и я подпишусь и под этой формой своего заключительного довода.

Вспомогательная таблица

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

create table DepartmentsAncestors ( Department int not null references Departments(Id), Ancestor int not null references Departments(Id) constraint DepartmentAncestor primary key (Department, Ancestor) )

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

DepartmentsAncestors
Department	Ancestor
2	1
3	1
4	2
4	1
5	3
5	1
6	3
6	1

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

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

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

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

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

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

create table Departments ( Id int not null identity primary key, Parent int not null references Departments(Id), Name varchar(32) not null, Level int not null, Terminal bit not null defaul(1) )

Departments
Id	Parent	Name	Level	Terminal
1	0	A1	1	0
2	1	B1	2	0
3	1	B2	2	0
4	2	C1	3	1
5	3	C2	3	1
6	3	C3	3	1

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

В статье содержатся некоторые рекомендации,

В статье содержатся некоторые рекомендации, направленные на то, чтобы облегчить создание мобильных прикладных информационных систем, опирающихся на использование реляционных систем управления базами данных (СУБД), которые поддерживают международный стандарт языка баз данных (БД) SQL. Чтобы лучше прояснить смысл статьи, необходимо сделать несколько предварительных замечаний.
Под мобильностью прикладной системы мы понимаем не только возможность ее простого переноса на другую аппаратную платформу, но и возможность сравнительно легкого приспособления к использованию другой СУБД. Мы не рассматриваем в этом документе проблемы переносимости, связанные с особенностями операционных систем. Заметим, что в общем случае проблемы переноса будут существенно проще, если целевыми аппаратными средствами являются UNIX-компьютеры, причем в качестве операционной системы используются современные версии ОС UNIX, соответствующие международным стандартам (например системы семейства System V Release 4.x), а в качестве языка программирования используется хорошо стандартизованный язык (далее мы предполагаем использование языка ANSI Си). Конечно, при некоторых дополнительных ограничениях на программирование(если это позволяет специфика прикладной системы) иногда можно добиться возможности несложного переноса прикладной системы в среду другой операционной системы.
Когда мы говорим о возможности приспособления прикладной системы к использованию различных СУБД, то, конечно, имеем в виду не произвольные СУБД, а системы, поддерживающие международный стандарт языка SQL. Другими словами, мы предполагаем прямое использование языка SQL при разработке прикладной системы, а также то, что все взаимодействия с системой БД производятся только с использованием этого языка. На самом деле, это существенно ограничивает возможный набор СУБД. Например, если в некоторой СУБД поддерживается доступ к БД на основе некоторого подмножества SQL, из этого не следует автоматически, что прикладная система может быть легко приспособлена к использованию этой СУБД.

Вычислительная полнота

В [1] утверждается, что именно вычислительная полнота Tutorial D делает этот язык неразрешимым:

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

Так что же означает вычислительная полнота языка?

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

Вычислимой функцией называется функция, которая может быть вычислена машиной Тьюринга за конечное число шагов [11]. Вычислимая функция – это функция, которую можно закодировать с использованием циклов WHILE [12].

Вычислительная полнота влечет неразрешимость

Как я уже говорил, в [1] утверждается, что именно вычислительная полнота Tutorial D делает его неразрешимым. Вот расширенный вариант выдержки, которая приводилась в начале предыдущего раздела:

Проблема попросту состоит в следующем: Если некоторый язык включает логику предикатов и является вычислительно полным, то логическим следствием является то, что в набор синтаксически правильных выражений этого языка будут входить самоссылающиеся выражения, и некоторые из них будут неразрешимыми. Это именно то, что показал Гедель в процессе построения своей первой теоремы о неполноте… Значит, если Tutorial D является вычислительно полным, то набор синтаксически правильных выражений Tutorial D включает самоссылающиеся неразрешимые выражения. Я просто применяю теорему Геделя к Tutorial D.

Автор [1] аппелирует и ко второй теореме Геделя. Вот расширенный вариант выдержки, которая приводилась в аннотации к данной статье:

Придание вычислительной полноты языку Tutorial D является ошибочным решением, поскольку это приводит к созданию языка, логические выражения которого могут быть неразрешимыми, – хотя для любого логического выражения должен существовать алгоритм, позволяющий его вычислить (см. вторую теорему Геделя о неполноте). Имеется ли в Tutorial D пример, более убедительный, чем доказанная теорема? Кодд предусмотрительно избежал этой ловушки, а Третий Манифест – нет!

Я вернусь к вопросу о том, «избежал» ли Кодд «этой ловушки» в следующем разделе. Однако сначала позвольте мне сформулировать две теоремы Геделя. Замечание: В действительности эти теоремы могут формулироваться во многих разных видах; приводимые здесь варианты являются несколько упрощенными – на самом деле, чрезмерно упрощенными, – но в данной ситуации этого достаточно. Заметим также, что в целях данного обсуждения я считаю термины выражение и утверждение взаимозаменяемыми, хотя они обычно не считаются таковыми в контексте традиционных языков программирования.

Первая теорема Геделя о неполноте: Пусть S – это непротиворечивая формальная система, являющаяся не менее мощной, чем элементарная арифметика; тогда система S является неполной в том смысле, что в S существуют утверждения, которые являются истинными, но это невозможно доказать, оставаясь внутри S. Вторая теорема Геделя о неполноте: Пусть – это непротиворечивая формальная система, являющаяся не менее мощной, чем элементарная арифметика; тогда непротиворечивость системы S невозможно доказать, оставаясь внутри S.

Признаюсь, что я не вижу непосредственной связи второй теоремы с аргументами, приводимыми в [1], но очевидно, что первая теорема поддерживает эти аргументы. Более того, поскольку доказательство Геделя своей первой теоремы (a) включает явное построение самоссылающегося утверждения – в сущности, арифметического аналога утверждения «Данное утверждение невозможно доказать в S», а затем доказывает, что это утверждение невозможно доказать в S (и, следовательно, данное утверждение является истинным!), из этого следует, что множество неразрешимых выражений в S включает некоторые самоссылающиеся выражения. И поэтому, если язык Tutorial D вычислительно полон, то он является неразрешимым в том смысле, что в число его выражений входят самоссылающиеся и неразрешимые выражения.

MS SQL Server 2000 предоставляет

MS SQL Server 2000 предоставляет богатые возможности по уведомлению лиц (администратора и операторов СУБД), ответственных за состояние баз данных и всего сервера в целом, о проблемах или событиях, происходящих с данными на сервере. Используя различные способы уведомлений (по электронной почте, на пейджер или же сообщения по сети), можно постоянно держать руку "на пульсе" этой несомненно популярной системы управления базами данных. И, несмотря на некоторую сложность настройки электронной почты SQL Server, возможно, именно вовремя пришедшее сообщение позволит вам оперативно отреагировать на возникшую проблему и предотвратить потерю ваших данных.
document.write('');

This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009

Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.

Взгляд компании Oracle на объектно-реляционный подход

Компания обещает предоставить своим пользователям

объектно-реляционные возможности с 1992 г. Пятилетняя эволюция

серверных продуктов происходила виде компромисса между

потребностями рынка и необходимостью переписи частей системы в

разумном порядке.

В Oracle6 были внесены изменения в архитектурные компоненты

нижнего уровня с целью повышения производительности (например,

средства распараллеливания и блокировок уровня записи). В Oracle7

были модифицированы компоненты верхнего уровня с целью внедрения

новых функциональных возможностей, таких как хранимые процедуры и

двухфазная фиксация распределенных транзакций. Выпущенная в

первом квартале 1996 г. версия Oracle 7.3 была первой, которую

компания назвала "универсальным сервером", поскольку в этой

версии поддерживались улучшенные средства документального поиска

(ConText Option) и пространственные типы данных (Spatial Data

Option). В теперешний выпуск Oracle8 включены основные

архитектурные изменения, затрагивающие не только

объектно-реляционные возможности, но также средства копирования и

восстановления и новые качества масштабирования для поддержки

сверхбольших баз данных.

Общая стратегия компании представляет собой интересную смесь

консерватизма и инновации. Прагматический подход Oracle к

объектно-реляционной технологии является относительно

консервативным, хотя NCA представляет собой одно из первых

действительно существенных решений ведущего независимого

производителя программного обеспечения. основанного на

распределенной объектной технологии CORBA. Кроме того, решение

компании об использовании Oracle8 для поддержки репозитория ее

собственных средств разработки приложений обеспечивает лучшую

среду для проектирования приложений, чем конкурирующие

объектно-реляционные системы.

Стратегия Oracle кажется исключительно разумной. Исследования и

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

1996 г. рынок мало нуждался в объектно-реляционной технологии. В

результате, когда Informix и IBM начали в середине 1996 г.

воздвигать профиль объектно-реляционной технологии, компания

Oracle казалась настроенной строго. Это впечатление подтверждали

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

Возникало впечатление, что компания Oracle стремилась

дискредитировать конкурирующую технологию, которуя сама компания

предложить не могла. Объектно-реляционная технлология,

появившаяся в Oracle8, категорически опровергает эту точку зрения.

Oracle по-прежнему полагает, что требования улучшенной

масштабируемости не менее важны, чем объектно-реляционная

технология, и что хотя требования к последней в настоящее время

возрастают, исключительно важно сохранить стоимость перехода на

низком уровне.

Кроме того, компания считает, что бизнес-логика не относится

исключительно к серверу баз данных; многие компоненты более

естественно расположить на сервере приложений. Oracle

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

архитектурам, предлагаемым в Informix Universal Server и DB2

Universal Database компании IBM.

Взгляд на собственное предложение Кодда по поводу реляционного языка

В статье прошлого месяца я упоминал тот факт, что Кодд первоначально сам предложил язык баз данных -- "Подъязык данных Alpha" -- основанный на реляционном исчислении. Он описал этот язык (хотя только неформально) в 1970-м г. [1] и потом более полно в 1971-м г. [2]; в действительности, язык Alpha, вероятно, был первым реляционным языком, описанным кем бы то ни было и где бы то ни было. Хотя сам язык Alpha никогда не был реализован, он оказал очень большое влияние на разработку последующих языков, включая, в частности, QUEL и, в меньшей степени, SQL. Более того, язык Alpha также включал некоторые полезные идеи (такие, как частичные запросы), которые сегодня все еще не поддерживаются в широком масштабе. Мне хочется взглянуть на некоторые выдающиеся свойства Alpha. В качестве основного ресурса я буду использовать [2] (называя ее в дальнейшем "статьей про Alpha" или иногда просто "статьей Кодда"); я буду упоминать [1] только в связи с некоторыми интересными идеями, которые не вошли в [2].

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

Web изменяет все

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

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

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

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

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

Эти тенденции создают благоприятные возможности для применения знаний исследователей баз данных к решению новых проблем.

Will Oracle8 Be Universal?

, October 1997, David Wells,

A senior consultant at Ovum, an international technology and telecommunications analyst group
Перевод - , ЦИТ

После выпуска в июне 1997 г. продукта Oracle8 маркетинговая

политика компании ориентирована на улучшенную масштабируемость

системы и значение сетевой вычислительной архитектуры (NCA -

Network Computing Architecture). Однако Oracle8 обладает

существенным набором объектно-реляционных средств, о которых

компания говорит несправедливо мало.

Windows NT как зеркало межсетевого взаимодействия.

Наталья Олифер и Виктор Олифер

Одной из основных целей, которую компания Microsoft преследовала, создавая

операционную систему нового поколения (NT - New Technology), было завоевание рынка

сетевых ОС для корпоративных серверов, который тогда прочно удерживала (и в той или иной

степени продолжает это делать по сей день) сетевая ОСNovell NetWare. Так как одна из

основных особенностей корпоративной сети- это ее неоднородность, то Windows NT в качестве

претендента на роль лидерасреди серверных сетевых операционных систем просто обязана была

поддерживать кроме родного стека коммуникационных протоколов NetBEUI/SMB и другие

наиболее популярные стеки, среди которых TCP/IP или IPX/NCP, а также обеспечивать

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

WINDOWS NT МУЛЬТИПЛЕКСИРУЕТ НА ВСЕХ УРОВНЯХ

Windows NT позволяет использовать для работы с разнородными

сетями как мультиплексоры, так и шлюзы. Мультиплексирование может осуществляться на

каждом из трех уровней коммуникационных средств: на нижнем уровне драйверов сетевых

адаптеров, на уровне сетевых протоколов и на прикладном уровне.

Мультиплексирование протоколов: взаимодействие компьютера с тремя

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

Для

того чтобы один сетевой протокол мог использовать несколько канальных протоколов

(реализованных в виде драйверов сетевых адаптеров) и, наоборот- один драйвер сетевого

адаптера мог работать с несколькими сетевыми протоколами, в Windows NT на нижнем уровне

используется мультиплексор NDIS (NetworkDriver Interface Specification), новая 32-разрядная

версия которого 3.0 была разработана специально для Windows NT. NDIS выполняет не только

функции мультиплексора, но и функции программной среды, изолирующей драйвер сетевого

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

драйвера функции управления сетевым адаптером, например функции ввода/вывода или

обработки прерываний, что делает код драйвера более мобильными переносимым. Windows NT

поддерживает драйверы сетевых адаптеров не только в стандарте NDIS, но и в популярном

стандарте ODI, используемом в сетях Novell NetWare.

На среднем уровне Windows NT

вводит свой стандарт на интерфейс транспортных протоколов - TDI (Transport Driver Interface).

"Наличие слова Driver" свидетельствует о том, что в Windows NT эти протоколы

реализованы в виде драйверов системы ввода/вывода. Если редиректоры и транспортные

протоколы написаны в соответствии с правилами TDI, то они могут образовывать произвольные

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

функциям транспортного уровня Windows NT предлагает два популярных API - NetBIOS и

Windows Sockets, которые, в свою очередь, обращаются к транспортным протоколам через

MUP

анализирует ответы редиректоров и, если один из них распознал ресурс, передает ему запрос

приложения для выполнения. Одновременно MUP кэширует соответствие имени сетевого

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

поступлении запроса к этому ресурсу.

Реализован MUP в виде драйвера, в чем можно

убедиться, просматривая список их имен в группе Devices утилиты Control Panel.

В

соответствии со вторым сценарием доступа приложение предварительно отображает сетевой

ресурс на локальный (устанавливает соединение), а затем обращается к нему как к локальному

ресурсу. Например, сначала разделяемый каталог \\tandem\C$ отображается на локальный

дисковод F:, а затем приложение обращается к файлу F:\Ann\article.doc как к локальному файлу.

Процедура установления соединения в общем случае состоит из двух

этапов:

· просмотр пользователем разделяемых сетевых ресурсов и выбор

нужного ресурса;
· отображение выбранного ресурса на локальный

ресурс.

Просмотр сетевых ресурсов необязателен, но в большой сети он может

существенно облегчить жизнь пользователю, которому в этом случае незачем помнить имена

всех серверов и разделяемых каталогов. В различных сетях сервис просмотра ресурсов

организован по-разному. В сетях Novell NetWare 3.x, например, редиректор собирает список

доступных серверов с помощью широковещательного протокола SAP, а в сетях NetWare 4.x

редиректор для этой цели обращается с запросами к централизованной справочной службе NDS.

В сетях Microsoft Windows NT список доступных серверов предоставляет специальный

компонент- Computer Browser, а список разделяемых каталогов выясняется в результате диалога

редиректора и сервера по протоколу SMB. В сетях TCP/IP при использовании сервисов ftp, telnet

или www услуга по просмотру сетевых ресурсов вообще не предусмотрена, и пользователь

должен явно задавать символьные имена хостов ftp или www, на которых хранятся нужные ему

данные.

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



в Windows NT с участием еще одного мультиплексора прикладного уровня - маршрутизатора

поставщиков услуг MPR (Multiple Provider Router). MPR, реализованный в виде динамической

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

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

Connect Network Drive утилиты File Manager перечень поддерживаемых сетей, набор имеющихся

в них серверов и список разделяемых каталогов на серверах отображаются с помощью одних и

тех же графических иконок, независимо от того, сеть ли это NetWare или Microsoft Windows.

Также показательна и процедура дополнительной аутентификации при подключении к новой

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


Мультиплексирование в Windows

NT.

Другой основной функцией MPR является

мультиплексирование связей между приложением и несколькими редиректорами. Если

приложение не делает запрос на доступ к сетевому ресурсу в явном виде по UNC-имени, а хочет

сначала просмотреть и/или отобразить ресурсы, то такой запрос попадает сначала в MPR,

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

с каким типом сети нужно работать - в этом случае MPR просто передает запрос указанному

редиректору. Если же в запросе тип сети не указан, то MPR поступает так же, как и MUP, - он

передает запрос для опознания ресурса всем редиректорам и ждет от них ответы.

MPR

взаимодействует с редиректорами не непосредственно, а через промежуточные компоненты,

называемые сетевыми поставщиками услуг (network provider). Эти промежуточные компоненты

обеспечивают согласование исходного интерфейса каждого редиректора с единым стандартным

интерфейсом, с помощью которого MPR общается с редиректорами. Таким образом, для

включения в Windows NT нового типа сети нужно разработать два компонента - редиректор и

сетевой поставщик услуг.

Разделение обязанностей между сетевым поставщиком услуг и



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

интерфейс с MPR. Встроенный поставщик сети Microsoft для получения списка доменов,

рабочих групп и компьютеров обращается к сервису Computer Browser, а список разделяемых

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

каталога на локальный дисковод, например \\tandem\C$ на F:, поставщик услуг сам создает в

дереве имен объектов Windows NT новый объект - символьную связь с именем F:, которая

указывает на редиректор сети Microsoft. После создания такой связи работа мультиплексора

MPR по поддержке доступа к файлам (и подкаталогам) каталога F:\ закончена. Теперь эти

обращения будут обрабатываться системой ввода/вывода Windows NT, которая, разбирая имя

файла, обнаружит, что диск F: - это не реальное устройство, а символьная связь, и вызовет для

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

XML: What is It, Anyway?

David Hay

()

Аббревиатура XML теперь распространена повсеместно. Она не означает "eXtra Medium Large" для размера майки. Скорее она имеет отношние к Web. Кое в чем помогает работать с метаданными. Но что это такое?

Расширяемый язык разметки (eXtensible Markup Language - XML) - это язык описания документов, во многом похожий на язык разметки гипертекста (HyperText Markup Language - HTML), повсеместно используемый для конструирования Web-страниц. Однако он является гораздо более универсальным, чем HTML, и глубоко влияет на наши представления о Web и на то, чего может достичь эта технология.

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

многим читателям эта статья показалась

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

Заключительные замечания

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

"Таким пользователям, очевидно, требуется простое понятие организации данных, чтобы проще было формулировать запросы или операции модификации". "Следует упомянуть отсутствие в сетевом подходе операций уровня алгебры или исчисления, поскольку такие операции жизненно важны для поддержки действий [случайного пользователя] … Особенно печально отсутствие в [предложениях CODASYL] каких-либо намерений по поддержке работы не-программистов". "Поддержка общего назначения для таких пользователей должна обеспечивать реляционно полную возможность выборки без потребностей в ветвлениях, явных циклов или курсоров. Понятно, как можно реализовать эту возможность с использованием реляционного подхода -- неважно, с применением формального или неформального языкового интерфейса. Непонятно, каким образом этой цели можно достичь на основе сетевого подхода, поскольку принципиальная схема [с наборами CODASYL] обладает свойством информационной существенности".

И сегодня эти наблюдения нуждаются лишь в незначительных корректировках.

Я хотел бы завершить это обсуждение языка Кодда Alpha двумя замечаниями.

В статье про Alpha упоминаются несколько запланированных статей: "Цель [этой статьи] состоит в том, чтобы обеспечить основу последующих статей по принципам авторизации, тактике поиска и методов представления данных" (стр. 2). "Детальному обсуждению [каталога] будет посвящена другая статья" (стр. 35). "Желательны дополнительные возможности … [включая] блокировки, авторизацию доступа, поддержку целостности, виртуальные атрибуты, литеральные вставки … Умышленно опущены возможные типы ошибок и … информация обратной связи. Эти аспекты будут обсуждаться в следующей статье" (стр. 41). Печально, но ни одно из этих обещаний не было в действительности исполнено! Вместе со своими тремя коллегами Кодд впоследствии работал над проектом низкоуровневой подсистемы Gamma-0, которая должна была стать основой реализации Alpha-подобного языка высокого уровня [2]. Более точно, Gamma-0 должна была стать основой реализации другого интерфейса, немного более высокого уровня, называвшегося Gamma-1, а уже Gamma-1 должна была явиться основой реализации Alpha-подобного языка высокого уровня. Принципиальным различием Gamma-0 и Gamma-1 было то, что Gamma-0 обеспечивала только однопользовательский интерфейс, а Gamma-1 - многопользовательский. Конечно, они проектировались согласованно: "Существенные аспекты Gamma-1 принимались во внимание и влияли на проектирование Gamma-0" [2].

Gamma-0 и Gamma-1 совместно демонстрируют большое сходство с подсистемой хранения System R [1], называемой RSS (Relational Storage System). Поэтому не удивительно, что один из коллег Кодда Ирв Трейджер позже был менеджером проекта RSS.

Я хотел бы завершить статью парой наблюдений: Прежде всего (и это самое главное), позиция Критиков A и B по поводу relvar остается исключительно неясной. Как кажется, они считают понятие relvar дефектным по своей сути, но в то же время желают их сохранить, по крайней мере, «неявно» (?). Они также не могут объяснить, в чем состоит логическое различие между relvar как таковыми и «изменяемыми во времени отношениями».

Верно, что некоторые языки программирования – конкретно, так называемые логические языки (например, Prolog) и функциональные языки (например, LISP) – умудряются существовать без присваивания: на самом деле, вообще без понятия «постоянной памяти» («persistent memory»). Однако, насколько мне известно, все такие языки «ловчат», когда требуется обновить базу данных; в действительности, они выполняют некоторую разновидность присваивания, возможно, в качестве побочного эффекта, хотя присваивание не является частью логического или функционального стиля.

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

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

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

Язык UML принадлежит объектному миру. Этот мир гораздо сложнее реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего, что угодно, в нем содержится масса различных понятий, терминов и вариантов использования, совершенно избыточных с точки зрения проектирования реляционных БД. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.

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

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

Еще одним доводом в пользу простых приложений может служить то, что ПО трех названных групп внедряется по разным законам. Рост затрат на внедрение ПО первой группы соответствуют примерно такому графику:

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

Для ПО второй группы график роста стоимости внедрения примерно таков:

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

Отличия в графиках для первой и второй групп легко объяснимы: ПО первой группы обычно внедряется "прямо из коробки", при этом, как правило, не проводится ни обучение пользователей, ни разработка и внедрение дополнительных функций. В случае необходимости создания своих собственных функций стоимость внедрения начинает расти, и, так как ПО первой группы не сильно ориентировано на допрограммирование, то чем больше функций добавляется, тем больше стоимость и тем быстрее она растет.

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

Для Lotus Domino и Notes, как и для любого ПО третьей группы график роста затрат на внедрение выглядит приблизительно так:

Характерный излом между линиями A и B объясняется следующим образом: ряд функций уже встроен в ПО Lotus Domino и Notes, и программирование и обучение для них не требуется - это график на участке левее A (подобный графику для ПО первой группы).
На участке между A и B происходит ( или должно происходить) та самая разработка, отладка и внедрение приложений, обучение пользователей и т. д., которые не требовались ранее. На участке кривой, расположенном правее B, Lotus Domino/Notes ведет себя как ПО второй группы - действительно, пользователи уже обучены, приложения функционируют, накоплено значительное количество пригодного для повторного использования программного материала и т. д.

Проблемой очень часто является как раз преодоление "ступеньки" A-B. Ее высота напрямую зависит от того, насколько успешно решены названные выше проблемы. К сожалению, лишь небольшое число проектов преодолевает ее. Большая часть застревает посередине, то есть пользователи получают незаконченное ПО, которое требует дополнительных финансовых затрат. К тому же, в силу того, что обычно вышеперечисленным вопросам в процессе разработки приложений и внедрения Lotus Notes изначально не уделяется достаточного внимания, преодоление ступеньки возможно только при отказе от ряда уже созданных компонентов и приложений (то есть, при возврате в точку A).

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

Кроме перечисленных ранее ошибок, характерных для ПО третьей группы, при разработке, внедрении, эксплуатации и поддержке ИС с использованием Lotus Domino/Notes часто допускаются ошибки, характерные для разработки в области ИТ в целом, то есть для ПО всех трех групп. К ним относятся: отсутствие планирования жизненного цикла ПО, недостаточное внимание к аспектам производительности, безопасности и масштабируемости, отсутствие единой концептуально-целостной технической архитектуры ИС (Enterprise-Wide Technical Architecture - EWTA) и т.


д. Мы не будем подробно останавливаться на них, так как их рассмотрение выходит за рамки данной статьи и их влияние на Lotus Domino и Notes аналогично влиянию на любую другую ИС.

Хочется отметить, однако, что из-за двойственности, свойственной Lotus Domino/Notes, очень часто возникает соблазн уклониться от решения этих проблем на первом этапе внедрения ИС, так как, якобы, в это время Domino ведет себя как ПО первой группы. Это, конечно, не так. Подобная практика приводит только к росту высоты ступеньки A-B, что, в свою очередь, может привести к краху внедрения. Избежать этого роста можно единственным способом: предвидеть и предупредить появление названных проблем, то есть принять меры к планированию сети, разработке политики безопасности, согласовать и официально принять EWTA и т. д.

Конечно, подобная практика потребует дополнительных финансовых затрат и усилий от разработчика на первом этапе внедрения ИС, что несколько снижает финансовую привлекательность Lotus Domino по сравнению с ПО второй группы. В данном случае важно не обманывать себя и заказчика. Либо внедрение остановится на первом этапе и не пойдет дальше, либо ступеньку придется преодолеть, что приведет к росту стоимости внедрения и владения ИС.

Закрепление окон

Когда разработчики работают с несколькими окнами, такими как Command,Properties и окном редактора, свободного места на экране становится очень мало. Чтобы разрешить эту ситуацию, Foxpro предоставляет возможность закрепления окон.

Технология закрепления окно позволяет:

Помещать окно на любой край экрана Создавать сдвоенные окна. Для примера, вы можете установить Command-окно и Properties-окно в одно окно-контейнер и привязать его к правому краю экрана.

Рисунок 3. Сдвоенные окна

Замечание относительно упорядоченности

Понятие существенности позволяет мне объяснить, почему важно то, что строки отношений не упорядочены. В упорядоченном файле порядок сам по себе может быть существенным в упомянутом выше смысле. Например, файл регистрации температуры мог бы поддерживаться в том порядке, в котором производились наблюдения. Этот порядок уже несет информацию, которая может быть потеряна при другом устройстве файла -- точно так же, как если уронить колоду карт, то мы потеряем информацию о предыдущем порядке карт в колоде. (Если вы чересчур молоды, чтобы что-нибудь знать о колодах карт и их порядке, вы можете проигнорировать этот пример.) И для существенного порядка, равно как и для существенных связей требуются дополнительные операции -- "найти n-тую запись", "вставить запись между n-той и (n+1)-ой и т.д. По этой причине упорядоченность не допускается в реляционной модели.

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

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

Замечание по поводу Третьего Манифеста

Хотя парадокс Эпименида по своей сути слишком прост для иллюстрации этого факта, в общем случае идея «предикатов, ссылающихся на предикаты» в реляционной терминологии соответствует отношениям, значениями атрибутов которых являются отношения (relation-valued attributes, RVA). В частности, непосредственно самоссылащийся предикат – т.е. предикат, включающий прямую ссылку на самого себя – соответствует отношению некоторого типа T, содержащему атрибут того же типа T. Такой тип отношения T называется рекурсивно определенным типом. В [4] по этому поводу говорится следующее:

<цитата>

Открытым остается вопрос о том, можно ли определять тип отношения рекурсивно, напрямую или косвенно, в терминах его же самого. Более точно, пусть RELATION{H} является типом отношения, и пусть S(1), S(2), ... – это последовательность множеств, определяемая следующим образом:

S(1) = {t : t является типом некоторого атрибута в {H}}

S(i) = {t : t является типом некоторого компонента в некотором возможном представлении некоторого скалярного типа или типом некоторого атрибута некоторого типа отношения в S(i-1) }

(i > 1)

Если существует некоторое n (n > 0) такое, что RELATION{H} – элемент S(n), то этот тип RELATION{H} является рекурсивно определенным. (Это определение нуждается в небольшом расширении, если поддерживается наследование типов, но эта деталь нас здесь не задевает.) Таким образом, открытый вопрос состоит в том, следует ли допускать рекурсивно определяемые типы. Наша модель не настолько зависит от ответа на этот вопрос, чтобы мы чувствовали себя обязанными уделить ему отдельное внимание; однако в данной книге мы следуем Принципу осторожного проектирования [3] и полагаем (там, где это существенно), что такие типы не допускаются.

</цитата>

Мне кажется, что аргументы, представленные в настоящей статье, делают желательным усиление приведенной позиции. Более точно, теперь я полагаю, что рекурсивно определяемые типы отношений следует явно запретить.
Вот что следует из этой позиции:
Примите к сведению, что я не призываю полностью запретить RVA. Я говорю об этом потому, что многие люди критиковали Третий Манифест за поддержку RVA на том основании, что допущение таких отношений выводит нас в сферу логики второго (или более высокого) порядка. Последнее утверждение, по-видимому, является верным, но никто еще не смог продемонстрировать какую-либо конкретную проблему, порождаемую этим фактом (т.е. только этим фактом) – по крайней мере, никто не продемонстрировал такую проблему нам, авторам [4]. В приведенной выше цитате из [4] говорится, что в этой книге мы полагаем, что рекурсивно определяемые типы не допускаются. Однако в описанном в этой же книге языке Tutorial D определение таких типов допускается (возможно, косвенным образом). Вот простой пример:

VAR RX BASE RELATION { A1 INTEGER, A2 SAME_TYPE_AS ( RX ) };

Более сложный пример:

VAR RX BASE RELATION { A1 INTEGER, A2 SAME_TYPE_AS ( RY ) };
VAR RY BASE RELATION { A3 INTEGER, A4 SAME_TYPE_AS ( RX ) };

Поэтому, возможно, языку Tutorial D в том виде, в котором он описывается в [4], свойственно отсутствие разрешимости. Однако я полагаю, что можно было бы создать реализацию, в которой бы отвергалась любая попытка использования этой «возможности» путем предотвращения (желательно, во время компиляции) любой попытки определения (напрямую или косвенным образом) типа T с использованием его же самого – примерно так же, как система должна предотвращать любую попытку определения ограничения, при вычислении которого во время определения не может быть получено значение TRUE.

Замечания по поводу Tutorial D

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

VAR R { } KEY { } ;

CONSTRAINT EPIMENIDES COUNT ( R ) = 0 ;

Более конкретно, можно было бы подумать, что ограничение EPIMENIDES является формальным выражением предиката P («Отсутствуют истинные инстанциации предиката P», или, эквивалентно, «Число истинных инстанциаций предиката P равняется нулю»). Но это не так. И причина состоит не в том, что к ограничениям не применима гипотеза о замкнутом мире. В гипотезе о замкнутости мира (говоря вольно) утверждается, что relvar R в данный момент времени должна содержать те и только те кортежи, которые в этот момент удовлетворяют предикату переменной R. Но в Tutorial D не поддерживается и не может поддерживаться знание предикатов relvar; в этом языке могут быть известны только ограничения relvar. И нет – и не может быть – такого требования, что relvar R в данный момент времени содержит те и только те кортежи, которые удовлетворяют в этот момент ограничениям, применимым к R. Так что тот факт (в примере), что relvar R всегда является пустой, сам по себе не приводит ни к какому парадоксу.

Попробуем подойти по-другому. Вот еще одна попытка сформулировать парадокс Эпименида в терминах Tutorial D:

VAR R { } KEY { } ;

CONSTRAINT EPIMENIDES

IF COUNT ( R ) = 1 THEN COUNT ( R ) = 0 AND

IF COUNT ( R ) = 0 THEN COUNT ( R ) = 1 ;

Здесь ограничение EPIMENIDES логически эквивалентно следующему:

Если в relvar R существует кортеж, то relvar R должна быть пустой, а если relvar R является пустой, то в ней должен существовать кортеж.

Другими словами, это ограничение является противоречием. (Заметьте, пожалуйста, что я использую здесь термин противоречие в его формальном логическом смысле, имея в виду предикат, любой вызов которого гарантированно приводит к результату FALSE вне зависимости от того, какие аргументы поставлены в соответствие его параметрам.) Но если ограничение является противоречием, то, прежде всего, отсутствует – или, по крайней мере, должна отсутствовать – какая-либо возможность добавления его к системе! Более точно, если какой-либо пользователь пытается определить некоторое новое ограничение для некоторой базы данных, то система, прежде всего, должна проверить, что база данных в настоящее время удовлетворяет этому ограничению.
Если эта проверка не удается, то ограничение, очевидно, должно быть отброшено; и если это ограничение является противоречием, то база данных ни коем образом не может удовлетворять ему в настоящее время.
Конечно, здесь я в целях обсуждения предполагаю, что система действительно может обнаружить тот факт, что база данных не удовлетворяет некоторому предлагаемому ограничению. В сопутствующей статье [1] обсуждается, что происходит при недействительности этого предположения. Однако для полноты я привожу здесь краткий набросок того, что должно происходить в правильно организованной системе, когда некоторый пользователь пытается определить некоторое новое ограничение базы данных DC:
Система вычисляет логическое выражение ограничения DC над текущим состоянием базы данных. Если результатом вычисления является TRUE, то система принимает DC, как допустимое ограничение, и с этого момента обеспечивает его соблюдение (до тех пор, пока в некоторый момент времени оно не будет отменено). Если результатом вычисления является FALSE, то система отвергает DC как ограничение, не допустимое в данное время. Если вычисление не заканчивается в течение некоторого преопределенного периода времени, возникает тайм-аут, и система отвергает DC – не потому, что это ограничение является недопустимым, а из-за того, что оно является слишком сложным, чтобы система могла им управлять.

Запросы.

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

Защита файлов в операционной системе UNIX

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

С самого начала ОС UNIX замышлялась как интерактивная система.

Другими словами, UNIX предназначен для терминальной работы. Чтобы

начать работать, человек должен "войти" в систему, введя со

свободного терминала свое учетное имя (account name) и, возможно,

пароль (password). Человек, зарегистрированный в учетных файлах

системы и, следовательно, имеющий учетное имя, называется

зарегистрированным пользователем системы. Регистрацию новых

пользователей обычно выполняет администратор системы.

Пользователь не может изменить свое учетное имя, но может

установить и/или изменить свой пароль. Пароли хранятся в

отдельном файле в закодированном виде. Не забывайте свой пароль,

снова узнать его не поможет даже администратор!

Все пользователи ОС UNIX явно или неявно работают с файлами.

Файловая система ОС UNIX имеет древовидную структуру.

Промежуточными узлами дерева являются каталоги со ссылками на

другие каталоги или файлы, а листья дерева соответствуют файлам

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

соответствует некоторый каталог файловой системы, который

называется "домашним" (home) каталогом пользователя. При входе в

систему пользователь получает неограниченный доступ к своему

домашнему каталогу и всем каталогам и файлам, содержащимся в нем.

Пользователь может создавать, удалять и модифицировать каталоги и

файлы, содержащиеся в домашнем каталоге. Потенциально возможен

доступ и ко всем другим файлам, однако он может быть ограничен,

если пользователь не имеет достаточных привилегий.

Поскольку ОС UNIX с самого своего зарождения задумывалась как

многопользовательская операционная система, в ней всегда была

актуальна проблема авторизации доступа различных пользователей к

файлам файловой системы. Под авторизацией доступа понимаются

действия системы, которые допускают или не допускают доступ

данного пользователя к данному файлу в зависимости от прав

доступа пользователя и ограничений доступа, установленных для

свой пароль. Имеется специальная программа /bin/passwd,

изменяющая пароли. Однако пользователь не может сделать это даже

с помощью этой программы, поскольку запись в файл /etc/passwd

запрещена. В системе UNIX эта проблема разрешается следующим

образом. При выполняемом файле может быть указано, что при его

запуске должны устанавливаться идентификаторы пользователя и/или

группы. Если пользователь запрашивает выполнение такой программы

(с помощью системного вызова exec), то для соответствующего

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

соответствующий идентификатору владельца выполняемого файла и/или

идентификатор группы этого владельца. В частности, при запуске

программы /bin/passwd процесс получит идентификатор

суперпользователя, и программа сможет произвести запись в файл

/etc/passwd.

И для идентификатора пользователя, и для идентификатора группы

реальный ID является истинным идентификатором, а действующий ID -

идентификатором текущего выполнения. Если текущий идентификатор

пользователя соответствует суперпользователю, то этот

идентификатор и идентификатор группы могут быть переустановлен в

любое значение системными вызовами setuid и setgid. Если же

текущий идентификатор пользователя отличается от идентификатора

суперпользователя, то выполнение системных вызовов setuid и

setgid приводит к замене текущего идентификатора истинным

идентификатором (пользователя или группы соответственно).

Как и полагается делать в многопользовательской операционной

системе, в UNIX поддерживается единообразный механизм контроля

доступа к файлам и справочникам файловой системы. Любой процесс

может получить доступ к некоторому файлу в том и только в том

случае, если права доступа, описанные при файле, соответствуют

возможностям данного процесса.

Защита файлов от несанкционированного доступа в ОС UNIX

основывается на трех фактах. Во-первых, с любым процессом,

создающим файл (или справочник), ассоциирован некоторый

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



дальнейшем можно трактовать как идентификатор владельца вновь

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

получить некоторый доступ к файлу, связана пара идентификаторов -

действующие идентификаторы пользователя и его группы. В-третьих,

каждому файлу однозначно соответствует его описатель - i-узел.

На последнем факте стоит остановиться более подробно. Важно

понимать, что имена файлов и файлы как таковые - это не одно и то

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

файлом несколько имен файла реально представляют один и тот же

файл и ассоциированы с одним и тем же i-узлом. Любому

используемому в файловой системе i-узлу всегда однозначно

соответствует один и только один файл. I-узел содержит достаточно

много разнообразной информации (большая ее часть доступна

пользователям через системные вызовы stat и fstat), и среди этой

информации находится часть, позволяющая файловой системе оценить

правомочность доступа данного процесса к данному файлу в

требуемом режиме.

Общие принципы защиты одинаковы для всех существующих вариантов

системы: Информация i-узла включает идентификаторы текущего

владельца файла (немедленно после создания файла идентификаторы

его текущего владельца устанавливаются соответствующими

действующим идентификатором процесса-создателя, но в дальнейшем

могут быть изменены системными вызовами chown и chgrp). Кроме

того, в i-узле файла хранится шкала, в которой отмечено, что

может делать с файлом пользователь - его владелец, что могут

делать с файлом пользователи, входящие в ту же группу

пользователей, что и владелец, и что могут делать с файлом

остальные пользователи.

Мелкие детали реализации в разных вариантах системы различаются,

однако в целом именно такова общая картина защиты файлов в ОС

UNIX.

Завершая обсуждение подъязыка Alpha

Data Sublanguage Alpha

C.J. Date

()

В предыдущей заметке мы обратились к подъязыку данных Кодда Alpha и привели обзор основных средств определения данных и операций манипулирования данными. Как и раньше, я использую в качестве основного первоисточника [5] (статью, которая ниже именуется "статьей про Alpha" или иногда просто "статьей Кодда"). Ссылки на [3] присутствуют только в тех случаях, когда этот материал имеет отношение к [5].

Неявные переменные с областью определения: В языке Alpha поддерживается очевидная сокращенная форма, допускающая использование имен отношений вместо явных имен переменных в тех случаях, когда это не приводит к двусмысленности. Используемое таким образом имя отношения обозначает неявную переменную с областью определения, значениями которой являются кортежи данного отношения. Таким образом, можно выразить запрос из заметки предыдущего месяца ("выдать имена поставщиков и названия их городов для поставщиков, поставляющих все детали") следующим образом:

GET W1 (S.SNAME, S.CITY) : ALL P SOME SP ( SP.S# = S.S# AND SP.P# = P.P# )

Но важно понимать, что здесь имя "S" не представляет отношение поставщиков S; это имя означает переменную S, определенную на отношении с тем же именем (то же касается имен P и SP). Такая сокращенная форма используется и в QUEL, и в SQL.

Дуальный подход: В [2] Кодд явно говорит о том, что теперь называется принципом дуального подхода. Любая операция над базой данных, которую можно выполнить в интерактивном режиме, может быть также вызвана из прикладной программы. "Язык [Alpha] направлен на то, чтобы быть подъязыком … языков, используемых всеми конечными пользователями" - пишет Кодд. "Этот язык ориентирован также на то, чтобы служить подъязыком таких основных языков программирования как PL/1, COBOL и FORTRAN". И это снова в первый раз, по моему мнению.

Каталог: В статье про Alpha явно демонстрируется признание Коддом понятия каталога. Утверждается, что сам каталог должен быть структуризован как набор отношений: "Каталог … может быть сам частью баз данных и должен состоять из … отношений".
И дальше: "Вся информация, относящаяся к новому отношению -- имя отношения, имена атрибутов и доменов, спецификация первичного ключа и т.д. -- должна быть связана с отношениями, каталогизирующими отношения базы данных" (слегка перефразировано). И: "Ограничения авторизованного доступа должны составлять те отношения, которые описывают эти ограничения … Для новых отношений должно быть выбрано представление хранения (включающее решение о том, какие атрибуты следует индексировать), и эта описательная информация должна храниться в соответствующих отношениях".

Косвенные ссылки: Язык Alpha включает операцию "разыменования" (dereference), называемую PER, в соответствии с которой (например) операция

GET W2 PER (W1.X)

Выбирает в рабочее пространство W2 отношение, имя которого задается компонентом рабочего пространства W1. В языке QUEL имеется в чем-то похожее свойство; в SQL такой возможности не было до появления "динамического SQL".

Миграция доменов: В [3] имеются некоторые замечания, касающиеся того, что называется миграцией доменов. (Лучше было бы называть это миграцией атрибутов.) Основная идея состоит в том, что некоторый атрибут, говоря нестрого, может "мигрировать" из одного базового отношения в другое, и мы хотели бы иметь возможность корректного продолжения использования запросов и приложений при таких изменениях.

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

Трехзначная логика: В статье про Alpha -- очень неудачно, по моему мнению -- допускается операция выборки с уточнением MAYBE_TOO, относящимся к тем кортежам, для которых условие выборки вырабатывает значение uknown (это истинностное значение в статье называется maybe), а также к тем кортежам, для которых значением условия является true.Другими словами, Кодд полагал, что система должна основываться на трехзначной логике и должна поддерживать некоторый род неопределенных значений (в статье они называются "отсутствующими значениями"). Он не развивает эту идею, кроме a) простого примера вставки кортежей с неспецифицируемыми компонентами ("сама система [внесет] отсутствующее значение [этих неспецифицированных компонентов]") и b) замечания относительно того, что "более подробная разработка [этого подхода] не является уместной".

Думаю, что это наблюдение правильно. Постоянные читатели этой серии знают, что мы с Коддом абсолютно не согласны с подходом неопределенных значений и трехзначной логики, и я сожалею о том, что он просто упомянул об этой возможности в 1971 г. Он ничего не делал по этому поводу до 1979 г. [7]; другими словами, реляционная модель прекрасно работала без неопределенных значений в течение десяти лет.

Значения и переменные базы данных

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

Мы стремимся к тому, чтобы иметь возможность обновлять базу данных. Ранее я говорил, что «обновляемость» и «возможность присваивания» означают одно и то же; я также говорил, что присваивать можно только переменной, и для каждой переменной имеется возможность присваивания. Не следует ли из этих замечаний, что и база данных является переменной? И поскольку понятие переменных, содержащих переменные, является логически абсурдным, следует ли из этого, что база данных, будучи переменной, не может содержать переменные отношений?

В действительности, на оба вопроса я отвечаю да. База данных является переменной, и она не может содержать другие, вложенные в нее переменные (ни переменные отношений, ни какие-либо другие). Вот выдержка из Приложения D к [14]:

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

После некоторой конкретизации этих замечаний в Приложении D к [14] говорится следующее:

Теперь мы отказываемся от этого плохого решения! Оглядываясь в прошлое, мы видим, что нужно было «стиснуть зубы» и использовать более корректные с точки зрения логики термины значение базы данных и переменная базы данных (или dbvar), несмотря на подрыв дружеских отношений.

И далее демонстрируется, что (a) переменная базы данных – это в действительности кортежная переменная с одним атрибутом (со значениями-отношениями) для каждой «переменной отношения», содержащейся в этой переменной базы данных; (b) переменные отношений в действительности являются псевдопеременными, позволяющими операциям обновления «затирать» («zap») индивидуальные компоненты объемлющей переменной базы данных. В [1] Хью говорит следующее:

Мы с Крисом обдумывали идею представления базы данных в виде единственной переменной, [но] не могли придумать удобный синтаксис для необычных видов … обновления, которые ожидались (присваивание всей базе данных для каждого требуемого обновления считалось невообразимым). Мы смогли добиться удобного синтаксиса только путем разделения базы данных на именованные «части», которые назвали переменными отношений.

Я упоминаю об этом только для полноты и для отражения возможных нападок на нашу позицию со стороны некоторых читателей. Хотя база данных в действительности является переменной, а relvar – это в действительности псевдопеременные, по моему убеждению, это ни коим образом не делает недействительными все аргументы, приведенные мною ранее в этой статье.

---

---