СистемыСистема (от др.-греч. — «сочетание»)— множество взаимосвязанных элементов, обособленное от среды и взаимодействующее с ней, как целое. баз данных третьего поколения: Манифест

Майкл Стоунбрейкер, Лоуренс Роув, Брюс Линдсей, ДжеймсДжеймс (англ.James) — английские имя и фамилия. Вименах королей традиционно переводится нарусскийязык как«Яков»или «Иаков». Сокращенна форма — Джимми. Грей, Майкл Кери, Майкл Броуди, Филипп Бернштейн, Дэвид Бич
Перевод: М.Р. Когаловский

Источник: журнал Системы УправленияУправление— воздействие субъекта, направленное на достижение абстрактной (неконкретной), но вынужденно-корректируемой цели (задачи, идеи) в уже сложившихся рамках правил, которые неизбежно-совершенствуются когда субъект непротиворечивее познаёт реальность, с которой сосуществует. Базами Данных # 2/1995, издательский дом «Открытые системы»
Новая редакция: СергейСергей— мужское имя, происходит от римского родового имени Sergius в святцах: высокий, высокочтимый. КузнецовКузнецов (Кузнецова)— одна из самых распространённых русских фамилий. В «Списке общерусских фамилий», занимает 3 место. Самым распространённым сочетанием фамилии имени и отчества в России в XX веке считался Кузнецов Николай Иванович, 2009 г.

ОригиналОригинал(от лат. originalis - первоначальный) — первоначальный, подлинный.: Michael Stonebraker, Lawrence A. Rowe, Bruce Lindsay, James Gray, Michael Carey, Michael Brodie, Philip Bernstein, David Beech. Third-Generation Database System Manifesto. SIGMOD Record 19(3), September, 1990. Текст доступен здесь.

Содержание

1. Введение

2. Принципы СУБД третьего поколения

3. Тринадцать предложений

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

3.2. Предложения, касающиеся увеличения функциональных возможностей СУБД

3.3. Предложения, следующие из необходимости открытости системы

4. Заключение

Библиография

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

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

Сетевые и иерархические системы баз данных, широко распространенные в 70-е годы, следует называть – системами баз данных первого поколения. Действительно, это были первые системы, предлагавшие развитую функциональность СУБД в рамках единой системы, с языками определения и манипулирования данными для наборов записей.¹⁾ Типичными представителями первого поколения являются системы, основанные на предложениях CODASYLCODASYL (англ.COnference on DAta SYstems Language — Конференция по языкам систем обработки данных) — организация (название произносится «кодасил»), принимавшая активное участие в эволюции информационных технологий в 60-80-е годы XX века. Основана в 1959 для разработки стандартного языка программирования, этот язык получил название COBOL. В настоящее время конференция расформирована, архив был передан Институту имени Чарльза Бэббиджа. [CODA71] и IMS [DATE86].

В 80-е годы системы первого поколения были существенно потеснены современным семейством реляционных СУБД, которые мы называем системами баз данных второго поколения. Их появление стало важным шагом вперед для многих приложений, так как в этих системах использовались непроцедурные языки манипулирования данными и предусматривалась значительная степень независимости данных. Типичные представители систем второго поколения – DB2, INGRES, NON-STOP SQL, ORACLE и Rdb/VMS.²⁾

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

Однако критики реляционной модели не замечают главного. Системы второго поколения не особо хороши и для поддержки большинства приложений обработки бизнес-данных. Возьмем, например, страховое приложение, обрабатывающее требования о выплатах. Ему необходимы традиционные типы данных, такие как имя и размер выплаты каждому застрахованному человеку. Однако, желательно также хранить и образы фотографий события, к которому относится требование о выплате, и факсимилеФаксимиле (от лат.fac simile «делай подобное») — воспроизведение всякого графического оригинала — рукописи, рисунка, чертежа, гравюры, подписи, монограммы, — передающее его вполне точно, со всеми подробностями. оригинального рукописного требования о выплате. Подобные элементы данных неудобно хранить в СУБД второго поколения. Более того, вся информация, имеющая отношение к определенному требованию о выплате, объединяется в папку, содержащую традиционные данные, образы«Образы» — кинофильм. Приз МКФ (Канн). Не рекомендуется просмотр детям и подросткам моложе 16 лет. и, возможно, процедурные данные. Структура папки часто бывает настолько сложной, что в сравнении с ней элементы данных и агрегированные данные САПР- и CASE-систем кажутся довольно простыми.

Таким образом, почти всем требуется лучшая СУБД, и уже делалось несколько попыток сконструировать прототипы с продвинутыми функциями. Более того, большинство современных поставщиков СУБД работают над значительным расширением функций своих СУБД второго поколения. Удивительна степень единодушия в отношении желаемых возможностей систем следующего поколения, которое мы называем третьим поколением. В настоящей статье мы представим три основных принципа, которыми следует руководствоваться при создании систем третьего поколения. Кроме этого, будут приведены 13 предложений, в которых требования к новым системам будут обсуждены более детально. Целесообразно сопоставить нашу работу с публикациями [ATKI89, KIM90, ZDON90], где предлагаются другие наборы принципов.

2. Принципы СУБД третьего поколения

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

Принцип 1: Помимо традиционных услуг по управлению данными, СУБД третьего поколения обеспечат поддержку более развитых структур объектов и правил.

УправлениеУправление— воздействие субъекта, направленное на достижение абстрактной (неконкретной), но вынужденно-корректируемой цели (задачи, идеи) в уже сложившихся рамках правил, которые неизбежно-совершенствуются когда субъект непротиворечивее познаёт реальность, с которой сосуществует. данными относится к задачам, с которыми современные реляционные системы справляются вполне успешно. Имеется в виду обработка за секунду 100 транзакций с 1000 оперативных терминалов и эффективное выполнение шестипроходных соединений. Более развитая структура объектов характеризует средства, необходимые для хранения и манипулирования нетрадиционными элементами данных (тексты, пространственные данные). Помимо этого, создателям приложений следует предоставить возможность задавать группу правил, касающихся элементов данных, записей и коллекций.¹⁾ Ссылочная целостность в контексте реляционных баз данных – простой пример такого правила; однако существует множество более сложных правил.

Рассмотрим два простых примера, иллюстрирующих этот принцип. Вернемся к описанному ранее газетному приложению. Оно содержит множество нетрадиционных элементов данных, таких как текст, пиктограммы, карты и рекламные объявленияЭлектронная доска объявлений — первоначально это понятие относилось исключительно к BBS. Однако по мере распространения Интернета появилось множество сайтов, вполне аналогичных обычным бытовым доскам объявлений или же рекламным газетам. Они унаследовали название электронных досок объявлений (однако аббревиатура BBS в отношении подобных русскоязычных ресурсов употребляется редко). Их содержимое представляет собой набор объявлений коммерческого и/или некоммерческого характера и размещается как на платной, так и на бесплатной основе, в зависимости от конкретного сайта. Многие рекламные компании, имеющие бумажные издания и работающие в сфере теле- и радиорекламы, создают и поддерживают также собственные электронные доски объявлений.. Следовательно, для него требуются более развитые структуры объектов. Далее рассмотрим рубричные рекламные объявления. Помимо рекламного текста, имеется набор бизнес-информации, относящейся к обработке данных (расценки, количество дней, в течение которых объявление будет печататься, класс, адрес для отправки счета и т.д.). Любой программе автоматизации верстки газеты необходим доступ к этим данным, чтобы решить, какие именно рекламные объявления должны быть включены в подготавливаемый номер. Более того, продажа рубричных рекламных объявлений в крупной газете – это стандартное приложение, связанное с обработкой транзакций, для которого нужны традиционные услуги управления данными. Дополнительно есть множество правил, в соответствии с которыми готовится макет газеты. Например, рекламу Macy нельзя помещать на одну страницу с рекламой Nordstrom. Для перехода к полуавтоматическому и автоматическому проектированию требуется сформулировать и внедрить такие правила. Итак, наш пример показывает,что возникает необходимость управления правилами.

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

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

услугиУслуга— совершённое одним лицом (физическим или юридическим) в интересах другого лица действие или деятельность.

Перейдем ко второму фундаментальному принципу.

Принцип 2: СУБД третьего поколения должны включить в себя СУБД второго поколения.

Другими словами, системы второго поколения внесли решающий вклад в двух областях:

• непроцедурный доступ,
• независимость данных.

И эти достижения не должны быть отброшены системами третьего поколения.

Существует точка зрения, что есть приложения, которым никогда не потребуется выполнять запросы из-за присущей им простоты доступа к СУБД. В качестве примера часто предлагаются САПР [CHAN89]. Таким образом, будущим системам язык запросов не потребуется и, следовательно, необходимость включения систем второго поколения отпадает. Несколько авторов настоящей работы беседовали со многими разработчиками САПР, интересующимися базами данных, и все они отмечали необходимость языка запросов. Рассмотрим, например, механическую САПР, хранящую составные части какого-либо продукта, например, автомобиля. Помимо пространственной геометрии каждой детали, САПР необходимо хранить набор атрибутных данных, таких как стоимость детали, ее цвет, среднее время наработки на отказ, сведения о поставщике детали и т.д. САПР-приложениям язык запросов нужен для задания произвольных запросов к атрибутным данным, например:

Насколько вырастет стоимость автомобиля, если поставщик X повысит цены на Y процентов?

Таким образом, мы приходим к выводу, что язык запросов абсолютноАбсолютный (лат.absolutus — законченный, неограниченный, безусловный, совершенный) — абсолютный означает то, что рассматривается само по себе, без отношения к чему-либо другому, противопоставляется относительному. необходим.

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

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

Принцип 3: СУБД третьего поколения должны быть открыты для других подсистем.

Иными словами, любая СУБД, рассчитывающая на широкую сферу применения, должна быть оснащена языком четвертого поколения (4GL), разнообразными инструментами поддержки принятия решений, дружественным доступом из многих языков программирования, дружественным доступом из популярных подсистем, таких как LOTUS 1-2-3, интерфейсами с графическими бизнес-пакетами, возможностью запуска приложений из базы данных на другой машине и распределенной СУБД. Весь набор инструментов и СУБД должен эффективно функционировать на разнообразных аппаратных платформах с различными операционными системами.

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

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

3. Тринадцать предложений

Мы выдвигаем три группы детальных предложений, которым, по нашему мнению, должны следовать удачные образцы систем баз данных третьего поколения 90-х годов. Предложения первой группы следуют из принципа 1 и уточняют требования к управлению объектами и правилами. Во второйВторой — второй по счёту альбом песен Владимира Высоцкого в исполнении Григория Лепса, записанный и вышедший в 2007 году группе содержится набор предложений, являющихся следствием того, что системы третьего поколения должны включать в себя системы второго поколения. Наконец, в третью группу сведены предложения, исходящие из требования открытости систем третьего поколения.

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

Создатели СУБД не в состоянии предвидеть все виды элементов данных, которые могут потребоваться приложениям. Например, большая часть людей считает, что время измеряется в секундах и днях. Однако в приложениях по торговле облигациями все месяцыМесяц— единица времени, используемая в календарях и приблизительно равная периоду обращения Луны вокруг Земли. длятся 30 дней, в банках день заканчивается в 15:30, а в приложениях фондовой биржи "вчера" перескакивает через праздникиПраздник— день торжества, установленный в честь или в память кого-нибудь, чего-нибудь. День или ряд дней, отмечаемых церковью в память религиозного события или святого. Выходной, нерабочий день. День радости и торжества. День игр и развлечений. и выходные. Следовательно, СУБД третьего поколения должны управлять разнообразными объектами, и мы выдвигаем 4 предложения по управлению объектами, касающиеся конструкторов типов, наследования, функций и уникальных идентификаторов.

Предложение 1.1: Система типов СУБД третьего поколения должна быть богатой и разнообразной.

Все перечисленное является желательным:

1. система абстрактных типов данных для создания новых базовых типов
2. конструктор типа массив
3. конструктор типа последовательность
4. конструктор типа запись
5. конструктор типа множество
6. функции как тип
7. конструктор типа объединение
8. рекурсивная композиция всех перечисленных выше конструкторов

Первый механизмМеханизм (греч. mechan— машина)— это совокупность совершающих требуемые движения тел (обычно— деталей машин), подвижно связанных и соприкасающихся между собой. Механизмы служат для передачи и преобразования движения. позволяет конструировать новые базовые типы в дополнение к стандартному набору целых чисел, вещественных чисел и текстовых строк, имеющемуся в большей части систем. При помощи первого механизма можно конструировать битовые строки, точки, линии, комплексные числа и т.д. Второй механизм позволяет заводить массивы элементов данных, которые можно встретить, например, во многих научных приложениях. Обычным свойством массивов является отсутствие возможности вставить новый элемент в середину, сдвинув все последующие элементы. В некоторых приложениях (работающих, например, с текстовыми строками) такая вставка бывает необходимой, и конструктор третьего вида поддерживает подобные последовательности. Четвертый механизм позволяет группировать элементы данных в записи. Благодаря такому конструктору можно было бы, например, сформировать запись элементов данных о человеке, представляющем "старую гвардию" некоторого университета. Пятый механизм требуется для создания неупорядоченных коллекций элементов данных или записей. Конструктор типа множество требуется, например, для создания коллекции всех представителей старой гвардии. Шестой механизм – функции (методы) – подробно рассмотривается в предложении 1.3; желательно, чтобы в СУБД естественным образом поддерживались такие конструкции. Следующий механизм позволяет создавать элементы данных, которые могут принимать значения одного из нескольких типов. Примеры применения этого конструктора приведены в [COPE84]. Последний механизм позволяет рекурсивно комбинировать конструкторы типов для поддержки сложных объектов, обладающих внутренней структурой, например, документов, пространственных геометрических конструкций и т.д. Более того, в отличие от систем второго поколения, последний примененный конструктор типов не обязан быть конструктором множеств.

Помимо перечисленных конструкторов типов необходимо также расширить адекватными конструкциями используемый язык запросов. Рассмотрим, например, коллекцию SALESPERSON, в которой каждый продавец характеризуется именем и месячными квотами, объединенными в массив из 12 целочисленных элементов. Хотелось бы обладать простыми средствами, позволяющими запросить имена продавцов, апрельская квота которых превысила $5000. Подобный запрос мог бы выглядеть таким образом:

select name
from SALESPERSON
where quota[4] > 5000

Следовательно, язык запросов должен быть расширен средствами обращения к массивам. Прототип синтаксиса для различных конструкторов типов содержится в [CARE88].

Полезность перечисленных конструкторов типов понятна клиентам СУБД, которым требуется хранить данные с достаточно развитой структурой. Более того, подобные конструкторы типов облегчат реализацию языков программирования со стабильными данными, обсуждаемых в предложении 3.2. Возможно, со временем станут желательными и дополнительные конструкторы типов. Например, системы обработки транзакций управляют очередями сообщений [BERN90]. Следовательно, может возникнуть необходимость в конструкторе, создающем очереди.

Системы второго поколения обладают лишь частью перечисленных конструкторов типов, и сторонники объектно-ориентированных баз данных (object-oriented data bases, OODB) утверждают, что для поддержки всех этих возможностей должны появиться качественно новые СУБД. Мы придерживаемся другой точки зрения по этому вопросу. Существуют прототипы, демонстрирующие, как добавлять к реляционным системам большую часть рассматриваемых конструкторов типов. Например, в [STON83] показано, как добавлять последовательности записей, [ZANI83] и [DADA86] указывают, как создавать некоторые сложные объекты, а [OSBO86, STON86] демонстрируют, как включать системы с абстрактными типами данных (АТД). Мы утверждаем, что все обсуждаемые конструкторы типов можно добавить к реляционным системам как естественное расширение, и что технология этого расширения достаточно хорошо продумана.³⁾ Более того, коммерческие реляционные системы с некоторыми из перечисленных возможностей уже начали появляться.Наше следующее предложение по управлению объектами касается наследования.

Предложение 1.2: Наследование – хорошая идея.

Об этой конструкции было сказано немало, так что будем кратки. Возможность организации типов в иерархию наследования – хорошая идея. Более того, нам кажется, что существенно множественное наследование, так что иерархия наследования должна представляться ориентированным графом. Поддержка только единичного наследования оказывается недостаточной для адекватного моделирования подавляющего большинства ситуаций. Рассмотрим, например, коллекцию представителей типа PERSON. Пусть существуют две специализации типа PERSON – студент (STUDENT) и служащийСлужащие— социальная группа, включающая всех занятых по найму нефизическим трудом в промышленности (инженеры, бухгалтеры, секретари и т.д.), а также наемных работников в торговле и сфере услуг. (EMPLOYEE). Наконец, имеются студенты-служащие (STUDENT EMPLOYEE), которые должны наследовать свойстваСвойство (в философии, математике и логике)— атрибут предмета (объекта). Например, о красном предмете говорится, что он обладает свойством красноты. Свойство можно рассматривать как форму предмета самого по себе, притом, что он может обладать и другими свойствами. Свойства, следовательно, подпадают под действие парадокса Рассела и парадокса Греллинга-Нельсона. и студентов, и служащих. В каждом случае элементы данных, соответствующие коллекции, задаются при его определении, а прочие наследуются из родительских коллекций. Диаграмма этой ситуации, требующей множественного наследования, изображена на рис. 1.

Отметим, что хотя в работе [ATKI89] и защищается идея наследования, множественное наследование там приводится как необязательная возможность.

Желательно также иметь коллекции, для которых не определяются дополнительные поля. Например, коллекцию TEENAGER (подросток) можно было бы определить как коллекцию, состоящую из таких же элементов данных, что и PERSON, но обладающий ограничениями на возраст. Опять-таки, уже создавались прототипы, демонстрирующие, как добавлять эти возможно«Возможно» (фр.Peut-tre)— фильм режиссёра Седрика Клапиша 1999 года.сти к реляционным системам, и мы ожидаем, что коммерческие реляционные системы будут развиваться в этом направлении.

Наше третье предложение касается включения функций в СУБД третьего поколения.

Предложение 1.3: Функции, в том числе, процедуры и методыМетод (от греч. — «способ»)— систематизированная совокупность шагов, действий, которые необходимо предпринять, чтобы решить определенную задачу или достичь определенной цели. В отличие от области знаний или исследований, является авторским, то есть созданным конкретной персоной или группой персон, научной или практической школой. В силу своей ограниченности рамками действия и результата, методы имеют тенденцию морально устаревать, преобразовываясь в другие методы, развиваясь в соответствии с временем, достижениями технической и научной мысли, потребностями общества. Совокупность однородных методов принято называть подходом. Развитие методов является естественным следствием развития научной мысли. баз данных, а также инкапсуляция – хорошие идеи.

Поддержка системами второго поколения функций и инкапсуляции ограничена. Например, в SQL над таблицами возможны только операции, осуществляемые функциями create, alter и drop. Следовательно, абстракция таблицы доступна только путем выполнения одной из перечисленных функций.

Очевидно, выгоды, предоставляемые инкапсуляцией, должны стать доступными для разработчиков приложений, чтобы те могли ассоциировать функции с пользовательскими коллекциями. Например, функции HIRE(EMPLOYEE), FIRE(EMPLOYEE) и RAISE-SAL(EMPLOYEE) (соответственно нанять, уволить служащего и повысить ему зарплату) должны быть ассоциированы с уже знакомой коллекцией EMPLOYEE. Если пользователям не разрешен прямой доступ к коллекции EMPLOYEE, а вместо этого предоставлены упомянутые функции, то вся информация о внутренней структуре объектов класса EMPLOYEE инкапсулирована внутри этих функций.

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

В защищенных или распределенных системах применение инкапсуляции часто дает выигрыш в производительности. Например, функции HIRE(EMPLOYEE) в процессе выполнения несколько раз может потребоваться доступ к базе данных. Если HIRE(EMPLOYEE) задана как функция, которая должна быть выполнена менеджерМенеджмент (в максимально широком смысле)— означает разработку (моделирование), создание и максимально эффективное использование социально-экономических систем различных уровней. Менеджмент (в узком смысле слова) - управление социально-экономическими системами, в том числе производственными (англ.management, от лат. manu agere «указывать рукой» ср. рус.руководить).ом данных внутренним образом, между приложением и СУБД состоится только один цикл обмена сообщениями. С другой стороны, если функция запускается из программы пользователя, один цикл обмена сообщениями потребуется для каждого доступа. Повышение производительности благодаря переносу функций внутрь СУБД было также продемонстрировано популярным тестовым набором Debit-Credit [ANON85].

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

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

Время от времени появляется необходимость в функциях, которым требуется непосредственный доступ к внутренним интерфейсам СУБД. Реализация таких функций станет нарушением сформулированной выше заповедиЗаповедь— религиозно-нравственное предписание. Заповеди, данные Богом, составляют основу религии. Обычно это краткое назидание в виде изложения основных тезисов, но в иудаизме, например, свод обязательных правил настолько разросся, что слово «талмуд» даже стало нарицательным, обозначая свод разносторонних указаний, которым проблематично следовать. Можно считать их моральными советами., гласящей, что получать доступ к базе данных следует исключительно при помощи языка запросов. Пример такой функции приведен в [STON90]. Следовательно, прямой доступ к внутренностям системы должен стать допустимым, но крайне нежелательным способом написания функций.

ВторойВторой — второй по счёту альбом песен Владимира Высоцкого в исполнении Григория Лепса, записанный и вышедший в 2007 году комментарий касается понятия непрозрачных (opaque) типов. Некоторые энтузиасты идеи объектно-ориентированных баз данных утверждают, что должен быть только один способ, с помощью которого пользователь может получить доступ к коллекции – выполнение одной из функций, применимых к коллекции. Например, единственным способом получения доступа к коллекции EMPLOYEE был бы вызов функции типа HIRE(EMPLOYEE). Такое ограничение игнорирует потребности языка запросов, среде выполнения которого требуется непосредственный доступ к каждому элементу данных. Рассмотрим такой пример:

select *
from EMPLOYEE
where salary > 1000

Для обработки этого запроса среде выполнения необходим непосредственный доступ к элементам данных salary, а также все вспомогательные пути доступа (индексы) к ним. Таким образом, мы считаем, что необходим механизм, делающий типы прозрачными, чтобы к элементам данных этих типов можно было получить доступ через язык запросов. Возможно, этого можно достичь при помощи автоматически определяемой "функции доступа" к каждому элементу данных или еще каким-то способом. Очевидно, необходима система авторизации для контроля доступа к базе данных на основе языка запросов.⁴⁾

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

Наше последнее предложение по управлению объектами касается автоматического задания уникальных идентификаторов.

Предложение 1.4: Уникальные идентификаторы (UID) записей должны задаваться СУБД только в том случае, когда недоступен определенный пользователем первичный ключ.

СистемаСистема (от др.-греч. — «сочетание»)— множество взаимосвязанных элементов, обособленное от среды и взаимодействующее с ней, как целое.ми второго поколения поддерживается понятиеПонятие — отображённое в мышлении единство существенных свойств, связей и отношений предметов или явлений; мысль или система мыслей, выделяющая и обобщающая предметы некоторого класса по определённым общим и в совокупности специфическим для них признакам. Понятия суть «сокращения, в которых мы охватываем, сообразно их общим свойствам, множество различных чувственно воспринимаемых вещей» (Ф. Энгельс), а также нечувственных объектов, таких как другие понятия. Понятие не только выделяет общее, но и расчленяет предметы, их свойства и отношения, классифицируя последние в соответствии с их различиями. Так, понятие «человек» отражает и существенно общее (то, что свойственно всем людям), и отличие любого человека от всего прочего. первичного ключа – заданного пользователем уникального идентификатора. Если у коллекции существует первичный ключ, который никогда не изменится (например, номер социального обеспечения, регистрационный номер студента, номер служащего), то необходимости в дополнительных, присвоенных системой уникальных идентификаторах не возникает. Неизменный первичный ключ лучше присвоенного системой UID еще и потому, что обозначает нечто естественное, понятное человеку. При обмене данными или отладке это может быть значительным преимуществом.

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

Более того, как будет показано при обсуждении предложения 2.3, некоторые коллекции, например, представления, не обязательно обладают системно заданными UID, так что построение систем с принудительной уникальной идентификацией, вероятнее всего, окажется нежелательным. Мы завершим обсуждениеДиалог (греч. — первоначальное значение— разговор, беседа двух людей) в обыденном смысле— литературная или театральная форма устного или письменного обмена высказываниями (репликами) в разговоре между двумя и более людьми;— в философском и научных смыслах— специфическая форма и организация общения, коммуникации. Традиционно противопоставляется монологу. принципа 1 последним предложением, касающимся понятия правила.

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

Исследователи OODB обычно игнорировали необходимость правил, несмотря на то, что именно в языках программирования, использующих концепцию объекта, впервыеВселенная «Механоидов»— придуманная фантастическая реальность, существующая в компьютерной игре «Механоиды». появились активные значения данных и демоныДемон (др.-греч. , «божество»)— в мифологии собирательное название сверхъестественных существ, полубогов или духов, занимающих промежуточное состояние между людьми и богами. В ранних источниках различие между терминами «демон» и «бог» прослеживается не всегда, так же как не прослеживается связь демонов исключительно с силами зла или добра. Демоны могли иметь любую природу, в том числе и смешанную, то есть могли в равной степени творить как зло, так и добро. В христианской традиции, как и в иудаизме, произошла дальнейшая эволюция термина, после которой демонами стали именоваться все сверхъестественные существа и боги, принадлежащие языческой традиции и противящиеся единому Богу. К этой же категории были отнесены все зловредные духи. Духи, не отпавшие от Бога, называются ангелами. Отсюда же происходит христианское представление о демонах, как о падших ангелах, утративших благосклонность Господа.. На вопрос о правилах OODB-энтузиасты отвечали либо молчанием, либо предложением внедрять их путем включения кода для их поддержки в одну или несколько функций, работающих с коллекцией. Например, для поддержки того правила, что любой служащий должен зарабатывать меньше, чем его менеджер, потребуется вставить соответствующий этому ограничению код в две функции – HIRE(EMPLOYEE) и RAISE-SAL(EMPLOYEE).

При ассоциировании правил с функциями возникают две фундаментальные проблемы. Во-первых, при добавлении новой функции, например, PENSION-CHANGE(EMPLOYEE), изменяющей размеры пенсии, необходимо или проследить, чтобы был вызван метод RAISE-SAL(EMPLOYEE), или включить в новую функцию код для поддержки правила. Нельзя гарантировать, что программист не забудет это сделать, а, следовательно, нельзя гарантировать поддержку правил. Более того, код для поддержки правила должен быть помещен, по крайней мере, в две функции: HIRE(EMPLOYEE) и RAISE-SAL(EMPLOYEE). Это потребует удвоения усилий и сильно затруднит изменение правила.

Рассмотрим следующее правило:

Если изменяется зарплата Джо, необходимо таким же образом изменить зарплату Сэма.

По схеме OODB для внедрения правила требуется добавить соответствующий код к функциям HIRE и RAISE-SAL. Предположим, что добавилось еще одно правило:

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

Для внедрения этого правила понадобится добавить код к тем же функциям. К тому же второе правило связано с первым. Человеку, пишущему код для поддержки второго правила, будет нужно правильно осуществить взаимодействие двух правил, а для этого придется разбираться со всеми правилами, включенными в изменяемую функцию. Та же проблемаПроблема (др.-греч. ) — положение, причинность, условие, вопрос, объект, который создаёт затруднение, побуждает к действию и связан с избыточностью или недостатком чего либо для сознания субъекта,например: процессора (движителя, калькулятора, компьютера,специалиста), знаний, ресурсов, регламента (упорядоченности, алгоритма, программы) и побуждает к действию или ограничивает его и соответственно неразрешён или нежелателен. В природе, вне деятельности человека, проблемы находят естественное разрешение и в последовательности движения форм материи есть этап в наблюдениях формализуемый человеком. Отличие природного процесса, разрешение проблемы как результат законов природы. Сущность проблемы для человека такова, что требует анализа, оценки, формирования идеи, концепции для поиска ответа (решение проблемы) с проверкой и подтверждением опытом. В природе это: Вода течёт вниз. Ветер качает деревья. Вода камень точит. и др., что естественно и непротиворечиво. ПРОБЛЕМОЙ преимущественно называется вопрос, не имеющий однозначного решения (степень неопределённости). Неопределённостью проблема отличается от задачи. Совокупность возможных вопросов взаимосвязанных объектом рассмотрения называется проблематикой. появится при последующем удалении правил.

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

С нашей точки зрения, есть только одно разумноеРазумное— посёлок городского типа в Белгородском районе Белгородской области России. решение: правила должны поддерживаться СУБД, но не быть привязаны ни к какой функции и ни к какой коллекции. У этого утверждения имеются два следствия. Во-первых, парадигмаПарадигма (от греч. , «пример, модель, образец»)— совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов. Обеспечивает преемственность развития науки и научного творчества. OODB "все выражается методами" просто не применима к правилам. Во-вторых, нельзя предоставлять непосредственный доступ к внутренним интерфейсам СУБД ниже уровня активации правил (иначе пользователи смогут обходить систему, включающую правила в нужное время).

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

3.2. Предложения, касающиеся увеличения функциональных возможностей СУБД

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

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

В OODB-литературе, как правило, недооценивается критическая важность высокоуровневых языков доступа к данным, по выразительной силе не уступающих реляционному языку запросов. Например, в [ATKI89] выдвигается предложение, что СУБД должна предоставлять возможность интерактивного доступа к данным в любой удобной форме. Мы сделаемСделаем! (англ.Let's do it!)— глобальная акция по очистке Эстонии от мусора в 2008 году, породившая мировое движение под общей целью. более сильное утверждение: выразительная сила языка запросов должна присутствовать в любом интерфейсе программируемого доступа; других способов доступа к данным СУБД быть не должно. В перспективе такой сервис может быть обеспечен путем добавления конструкций языка запросов к различным языкам программирования со стабильным хранением данных (о них мы поговорим в предложении 3.2). В ближайшем будущем этот сервис может быть обеспечен путем встраивания языка запросов в обычные языки программирования.

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

Навигационная точка зрения была хорошо сформулирована Чарльзом Бахманом (Charles Bachman) в лекции при получении премии Тьюринга [BACH73]. Нам кажется, что 17 лет, прошедшие с того времени, показали, что подобные интерфейсы неудобны, и использовать их не следует. Далее мы обсудим лишь две из множества важных проблем, связанных с навигацией. Во-первых, когда программист осуществляет навигацию к искомым данным таким образом, он заменяет функции оптимизатора запросов написанными вручную вызовами более низкого уровня. История наглядно продемонстрировала, что хорошо написанный и хорошо настроенный оптимизатор почти во всех случаях добивается лучших результатов, чем написанные вручную вызовы. Следовательно, почти наверняка программист создаст программу с более низкой производительностью. Более того, ему придется решать гораздо более сложные задачи при написании кода для сложных низкоуровневых интерфейсов.

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

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

select *
from collection
where collection.key = value

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

dereference (pointerУказатель (поинтер, англ.pointer)— переменная, диапазон значений которой состоит из адресов ячеек памяти и специального значения— нулевого адреса. Значение нулевого адреса не является реальным адресом и используется только для обозначения того, что указатель в данный момент не может использоваться для обращения ни к какой ячейке памяти.)).

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

В SQL-представлении, пара

(имя-отношения, ключ) 

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

Последнее утверждение, которое часто делают энтузиасты OODB, заключается в том, что программисты, например, САПР, хотят собственноручно осуществлять навигацию, и, следовательно, система должна поощрять ее при помощи интерфейсов низкого уровня. Мы признаем, что некоторые программисты могут предпочитать навигацию. Были такие, которые отказывались переходить с ассемблера на языки высокого уровня, были и те, кто отказывался переходить к реляционным системам – на новых системах задачи были не столь сложными, а значит, работа не столь интересная. Эти программисты думали, что смогут работать лучше, чем компиляторы и оптимизаторы. Мы считаем, что аргументы против навигации достаточно убедительны и что некоторым программистам просто не мешает подучиться.

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

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

Предложение 2.2: Должно быть по крайней мере два способа спецификации коллекций: посредством перечисления членов и путем использования языка запросов для задания членов.

В литературе по OODB предлагается задание множеств перечислением, средствами связанного списка или массива идентификаторов членов [DEWI90]. Мы полагаем, что такая спецификация – не лучший выбор. В качестве иллюстрацииИллюстрация— визуализация, такая как рисунок, фотография или другая работа, создаваемая с целью выделить субъект, а не форму. Иллюстрации поясняют и декорируют текстовое содержимое книги, журнала, газеты. рассмотрим пример:

ALUMNI (name, age, address)
GROUPS (g-name, composition)

Мы имеем коллекцию выпускников некоторого университета и коллекцию групп выпускников. У каждой группы есть имя, например, "старая гвардия", "непослушные дети", "переростки", и т.д.; в поле composition (состав) указаны все выпускники, являющиеся членами группы. Конечно, можно задать состав как массивИндексный массив (в некоторых языках программирования также таблица, ряд)— именованный набор однотипных переменных, расположенных в памяти непосредственно друг за другом, доступ к которым осуществляется по индексу (в отличие от списка). указателей на соответствующих выпускников, однако такая спецификация окажется крайне неэффективной, так как множества окажутся довольно большими и будут значительно перекрываться. Более важно то, что когда новый человек добавляется к коллекции ALUMNI (выпускники), добавление его в соответствующую группу входит в обязанностиПравоотношение — урегулированное нормами права общественное отношение, участники которого обладают субъективными правами и являются носителями юридических обязанностей. прикладного программиста. Иными словами, различные множестваМножество— один из ключевых объектов математики, в частности, теории множеств и логики. выпускников задаются экстенсионально, перечислением членов, и принадлежность выпускника к какому-либо множеству определяется вручную прикладным программистом.

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

GROUPS (g-name, min-age, max-age,
         composition)

В этом случае состав задается интенсионально, при помощи следующего выражения SQL:

select *
from ALUMNI
where age > GROUPS.min-age
  and age < GROUPS.max-age

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

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

select g-name
from GROUPS
where composition.name = "Bill"

Этот запрос выявляет группы, членом которых является Билл. Здесь используется "вложенная точечная нотация" обращения к элементам множества, получившая распространение благодаря языку баз данных GEM [ZANI83]. Если составСостав — предмет (вещество), включающей в себя много частей (компонентов), а также описание качества, количества и иных характеристик частей такого предмета (вещества). задается массивом указателей, оптимизатор запросов может последовательно просматривать все записи GROUPS, и, переходя к каждому указателю, искать Билла. Оптимизатор запросов также может сначала узнать идентификатор Билла, а затем просматривать все поля композиции в поисках этого идентификатора. С другой стороны, если используется интенсиональное представление, приведенный запрос может быть преобразован оптимизатором следующим образом:

select g-name
from GROUPS, ALUMNI
where ALUMNI.name = "Bill"
  and ALUMNI.age > GROUPS.min-age
  and ALUMNI.age < GROUPS.max-age

Если имеются индексы на GROUPS.min-age или GROUPS.max-age, а также на ALUMNI.name, то такой запрос будет выполнен значительно производительнее двух первых запросов.

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

Кроме того, при интенсиональной спецификации оптимизатор запросов может производить семантические преобразования. Это позволяет выбирать пути доступа, лучшие для данного запроса. Никаких ограничений, наложенных структурами указателей, не существует. Таким образом, полномочия по принятию решений по вопросам физического представления делегируются администратору базы данных, туда, где они должны находиться. АдминистраторАдминистратор (лат. administrator - управитель) — распорядитель в учреждении, коллективе, а также специалист по обслуживанию баз данных и информационных систем. В Общероссийском классификаторе занятий (ОКЗ) администратор считается должностью. может решать, какие способы доступа следует поддерживать (например, связанные списки или массивы указателей) [CARE90].

Мы считаем, что требуются оба представления, но предпочтение должно отдаваться интенсиональному. С другой стороны, энтузиасты OODB, как правило, рекомендуют использовать лишь экстенсиональные методы. Вспомним, что в середине 70-х годов преимуществам автоматического задания множеств посвящалось немало внимания [CODD74]. Чтобы не сделать шаг назад, системы третьего поколения должны отдавать предпочтение автоматическим множествам.

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

Предложение 2.3: Существенно наличие обновляемых представлений.

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

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

Традиционным способом поддержки обновления представлений является механизм преобразований команд [STON75]. Чтобы в процессе обновления представления не было неоднозначности, при определении представления должна быть обеспечена дополнительная семантическая информация. Один из подходов заключается в требовании непрозрачности каждой коллекции, который позднее может стать представлением. В этом случае существует группа функций, посредством которых осуществляется весь доступ к коллекции [ROWE79], и автор определения представления должен вносить необходимые изменения в каждую из этих функций. Это повлечет за собой значительные расходы на сопровождение программ, а также не позволит выполнять обновление с помощью языка запросов. В качестве альтернативы такому подходу можно выдвинуть подходящую систему правил [STON90B]. Преимущество второго подхода заключается в том, что для обеспечения семантики обновления представления требуется задать только одно (или несколько) правил. Это куда проще, чем внесение изменений в набор функций.

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

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

Предложение 2.4: Показатели производительности не имеют почти ничегоНичто— категория, фиксирующая отсутствие, небытие определённой сущности, или отсутствие, отрицание бытия вообще, активное начало негации, негативности вообще. общего с моделями данных и не должны в них проявляться.

Вообще говоря, основными параметрами, по которым оценивается производительность работы с использованием как SQL, так и спецификаций более низкого уровня, являются:

• объем работ по оптимизации настройки СУБД с целью повышения ее эффективности
• использование в СУБД методов компиляции
• местонахождение буферного пула (в адресном пространстве клиента или СУБД)
• доступные типы индексирования
• производительность интерфейса клиент СУБД
• поддерживаемая кластеризация

Эти вопросы не имеют ничего общего с моделью данных или с использованием языков высокого уровня типа SQL вместо навигационного интерфейса низкого уровня. Например, тактика кластеризации связанных объектов представляется как важная черта OODB. Однако эта тактика использовалась в системах баз данных уже многие годы, например, являлась основным средством в большинстве методов доступа IMS. Следовательно, кластеризация является вопросом физического представления и не имеет ничего общего с модельМодель (фр.modle, от лат.modulus— «мера, аналог, образец»)— некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого объекта или явления (прототипа) и в достаточной степени повторяющий свойства, существенные для целей конкретного моделирования(опуская несущественные свойства, в которых он может отличаться от прототипа).ю данных СУБД. Аналогично, с моделью данных не связаны решения о том, должна ли система строить индексы для уникальных идентификаторов, и следует ли ей буферизовать записи базы данных на клиентской машине или даже в пользовательском пространстве прикладной программы.

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

• методы доступа к структурам данных с пространственной информацией, такие как R-деревья, hb-деревья или сеточные файлы
• буферный пул на рабочей станции инженера, а не на центральном сервере
• буферный пул в прикладной программе
• буферизацияБуферизация (от англ.buffer) — метод организации обмена, в частности, ввода и вывода данных в компьютерах и других вычислительных устройствах, который подразумевает использование буфера для временного хранения данных. При вводе данных одни устройства или процессы производят запись данных в буфер, а другие — чтение из него, при выводе — наоборот. Процесс, выполнивший запись в буфер, может немедленно продолжать работу, не ожидая, пока данные будут обработаны другим процессом, которому они предназначены. В свою очередь, процесс, обработавший некоторую порцию данных, может немедленно прочитать из буфера следующую порцию. Таким образом, буферизация позволяет процессам, производящим ввод, вывод и обработку данных, выполняться параллельно, не ожидая, пока другой процесс выполнит свою часть работы. Поэтому буферизация данных широко применяется в многозадачных ОС. данных в экранном формате, а не в формате СУБД

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

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

3.3. Предложения, следующие из необходимости открытости системы

До сих пор мы обсуждали характеристики СУБД третьего поколения. Теперь обратим внимание на интерфейс прикладного программирования (Application Programming Interface – API), посредством которого программа пользователя будет общаться с СУБД. В нашем первом предложении говорится об очевидной вещи.

Предложение 3.1: СУБД третьего поколения должны быть доступны из различных ЯВУ.

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

Во-первых, невозможно договориться, какой именно ЯВУ использовать. Приложения кодируются и будут кодироваться на различных ЯВУ, и на горизонте пока не видно языка программирования Esperanto. Отсюда следует необходимость в многоязычной СУБД.

Однако есть еще одна причина, по которой открытая СУБД должна быть многоязычной. СУБД должна предоставлять доступ для различных внешних прикладных подсистем, например, Lotus 1-2-3. Такие подсистемы будут кодироваться на различных языках программирования – вот еще один аргумент в пользу многоязычности.

В результате СУБД третьего поколения будут доступны для программ, написанных на различных языках. Отсюда однозначно следует, что система типов ЯВУ не обязательно будет совпадать с системой типов СУБД. Итак, мы приходим к предложению:

Предложение 3.2: Язык "X с поддержкой стабильных данных" (для различных X) – хорошая идея. Языки будут поддерживаться над единой СУБД благодаря расширенияРасширение имени файла (англ.filename extension, часто говорят просто расширение файла или расширение)— последовательность символов, добавляемых к имени файла и предназначенных для идентификации типа (формата) файла. Это один из распространённых способов, с помощью которых пользователь или программное обеспечение компьютера может определить тип данных, хранящихся в файле.м компилятора и (более или менее) сложной системе поддержки времени выполнения.

В интерфейсах систем второго поколения с языками программирования препроцессор использовался отчасти потому, что на ранней стадии разработчики СУБД не сотрудничали с разработчиками компиляторов. Более того, у сохранения независимости языка СУБД от языков программирования есть свои преимущества (например, СУБД и языки программирования можно независимо расширять и тестировать). Однако получавшиеся интерфейсы не отличались дружественностью и уже в 1977 году были охарактеризованы как "попытки приклеить яблоко к блину". Поставщики обычно концентрировали свои усилия на создании элегантного интерфейса между своими языками четвертого поколения и сервисСервис (от лат.servio— быть рабом (невольником), быть порабощённым, в рабстве; лат.ами баз данных. Очевидно, что не менее элегантные интерфейсы можно создать и для универсальных языков программирования.

Во-первых, очень важно установить более точное соответствиеМногозначная функция — обобщение понятия функции, допускающее наличие нескольких значений функции для одного аргумента. между системами типов (этому будет способствовать внедрение предложения 1.1). Именно в этом состоит основная проблема современных реализаций встроенного SQL, а не в синтаксиса SQL. Во-вторых, было бы хорошо предоставить возможность сделать любую переменную в программе пользователя стабильной (persistent). Значения стабильных переменных не утрачиваются даже после окончания работы программы. В последнее время проявляется большая заинтересованность в подобных интерфейсах [LISK82, BUNE86].

Для достижения хорошей производительности "X с поддержкой стабильных данных" должен поддерживать кэш элементов данных и записей в адресном пространстве программы и аккуратно управлять содержимым этого кэша, используя некоторый алгоритмАлгоритм, от имени учёного аль-Хорезми (перс. [al-Khwrazm])— точный набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное время. В старой трактовке вместо слова «порядок» использовалось слово «последовательность», но по мере развития параллельности в работе компьютеров слово «последовательность» стали заменять более общим словом «порядок». Это связано с тем, что работа каких-то инструкций алгоритма может быть зависима от других инструкций или результатов их работы. Таким образом, некоторые инструкции должны выполняться строго после завершения работы инструкций, от которых они зависят. Независимые инструкции или инструкции, ставшие независимыми из-за завершения работы инструкций, от которых они зависят, могут выполняться в произвольном порядке, параллельно или одновременно, если это позволяют используемые процессор и операционная система. замещения. Пусть некоторый пользователь определил элемент данных как стабильный, а затем увеличивал его 100 раз. Благодаря наличию кэша эти изменения потребуют всего несколько микросекунд. В противном случае потребовалось бы 100 обращений к СУБД через защищенную границу, и каждый вызов отнял бы миллисекунды. Следовательно, наличие кэша в пространстве пользователя приведет к повышению производительности в 100 – 1000 раз для программ с высокой степенью локальности ссылок на стабильные данные. Таким образом, система поддержки времени выполнения сначала должна проверить, есть ли сохраняемый элемент в кэше, а если нет, поместить его туда. Более того, система времени выполнения должна моделировать типы, присутствующие в "X с поддержкой стабильных данных", но отсутствующие в СУБД.

Как отмечалось ранее, функции должны кодироваться путем включения вызовов к СУБД, выраженных на языке запросов. Следовательно, и для "X с поддержкой стабильных данных" также требуются средства выражения на языке запросов. Такие запросы могут быть выражены в нотации, соответствующей ЯВУ, как показывает система ODE применительно к C++ [AGRA89]. Системы времени выполнения ЯВУ должны принимать и обрабатывать такие запросы и доставлять результаты обратно в программу.

Подобные системы поддержки времени выполнения будет более (или менее) трудно построить в зависимости от конкретного ЯВУ (при этом поднимаются вопросы числа типов, которые необходимо моделировать, и степени различия языков запросов СУБД и ЯВУ). Подходящей является система поддержки времени выполнения, обеспечивающая интерфейс с СУБД для множества ЯВУ. Один из нас на основе подобного подхода успешно построил CLOS с поддержкой стабильных данных над POSTGRES [ROWE90].

Будет создано множество разнообразных "X с поддержкой стабильных данных". Для каждого из них потребуются свои модификации компилятора и системы времени выполнения. Все системы времени выполнения будут подключены к общей СУБД. Очевиден вопрос "Как выражать запросы к этой общей СУБД?". Ответ дается в нашем следующем предложении.

Предложение 3.3: Хорошо это или плохо, но SQL становится интергалактическим языком данных.

На сегодня SQL – универсальный способ выражения запросов. При создании первых коммерческих объектно-ориентированных баз данных этот факт не учитывался, и потом пришлось встраивать в продукты поддержку SQL-запросов. К сожалению, многие продукты не дожили до окончания этой работы. Хотя перед SQL и стоит множество мелких проблем [DATE84], он необходим для коммерческой жизнеспособности. Любая компания-производитель объектно-ориентированных баз данных, желающая, чтобы ее продукт оказывал влияние на рынок, должна понять, что покупатели голосуют своими долларами за SQL. Более того, SQL является разумной кандидатурой для новых функций, предлагаемых в этой работе; прототипы синтаксиса для реализации некоторых новых возможностей исследованы в [BEEC88, ANSI89]. Конечно, для определенных приложений и ЯВУ могут оказаться адекватными и другие языки запросов.

Наше последнее предложение касается архитектуры, которой необходимо следовать, когда прикладная программа функционирует на одном компьютере, а СУБД находится на другом, серверном компьютере. Так как команды СУБД будут кодироваться с привлечением некоторой версии SQL, можно передавать SQL-запросы и получать искомые записи и/или сообщения о выполнении. Более того, консорциум поставщиков инструментов и СУБД (SQL Access Group) активно работает над определением и созданием прототипов основанных на SQL средств удаленного доступа к данным. Такие средства обеспечат интероперабельность инструментальных средств и СУБД, базирующихся на языке SQL. Альтернативой является обмен сообщениями между клиентом и сервером при помощи интерфейса более низкого уровня.

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

Предложение 3.4: Запросы и ответы на них должны образовывать нижний уровень коммуникаций между клиентом и сервером.

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

Если используются спецификации низкого уровня, такие как передача страницы или записи, то специфицировать протоколПротокол (от др.-греч. protos— «первый» и kolla— «клей»)— первый лист, приклеенный к свитку. На нем фиксировались титульная информация (например, дата написания, имя писателя) и краткое основное содержание свитка. принципиально труднее, так как возрастает число состояний; мешает и машинная зависимость. Более того, на нижнем уровне любой интерфейс, отличный от SQL-интерфейса, приведет к проигрышу в производительности [HAGM86, TAND88]. Следовательно, удаленные вызовы процедур и SQL-запросы обеспечивают адекватный уровень технологии интерфейсов.

4. Заключение

Есть много вопросов, по которым мы соглашаемся и с энтузиастами OODB[ATKI89]. Среди них выделим выгодность использования богатой системы типов, функций, наследования и инкапсуляции. Однако во многих областях мы придерживаемся противоположных мнений. Во-первых, нам кажется, что работа [ATKI89] слишком узко сфокусирована на вопросах управления объектами. Мы, наоборот, обращаемся к более широкому кругу вопросов обеспечения решений, поддерживающих управление данными, правилами и объектами, снабженных полным набором инструментов, включающем интеграцию СУБД и языка запросов в многоязычную среду. В связи с этим нам кажется, что предлагаемые многими энтузиастами OODB одноязычные системы, не поддерживающие SQL, привлекательны лишь для довольно узкого рынка.

Во-вторых, представляется, что доступ к СУБД должен осуществляться при помощи языка запросов, и почти 20 лет истории подтверждают правильность такой точки зрения. Физической навигации, выполняемой программами пользователей или происходящей внутри функций, следует избегать. В-третьих, необходимо всячески поощрять использование автоматических коллекций, так как они предоставляют массу преимуществ по сравнению с явно поддерживаемыми коллекциями. В-четвертых, свойство стабильности данных может быть добавлено ко многим языкам программирования. Так как не существует языка программирования, аналогичного эсперантоЭсперанто (Esperanto)— самый распространённый искусственный язык (точнее, плановый), созданный варшавским окулистом Лазарем (Людвигом) Марковичем Заменгофом в 1887 году после десяти лет работы. Первая опубликованная книга по эсперанто называлась «Lingvo internacia. Antaparolo kaj plena lernolibro» («Международный язык. Предисловие и полный учебник»). Псевдоним Заменгофа— Эсперанто («Надеющийся»)— очень скоро стал названием самого языка., этого следует достигать путем изменения компилятора и написания специфичной для языка системы времени выполнения, взаимодействующей с единой СУБД. Таким образом, языки программирования с поддержкой стабильных данных мало связаны с моделями данных. В-пятых, уникальные идентификаторы должны задаваться либо пользователем, либо системой (здесь мы вступаем в противоречиеПротиворечие— отношение двух суждений, каждое из которых является отрицанием другого. В формальной логике противоречие считается недопустимым согласно закону противоречия. Однако, как показали Кант (антиномии) и Гегель, противоречие есть необходимый этап и результат всякого реального мышления— познания. Если у Канта, и в метафизике вообще, логическое противоречие трактуется как феномен, появляющийся в мышлении в силу его несовершенства или его неправомерного использования (границы применимости), то у Гегеля, Маркса, в диалектике противоречие рассматривается как необходимая логическая форма, в которой осуществляется развитие мышления, познания вообще (см. диалектическое противоречие). с одним из принципПринцип или начало (лат.principium, греч. )— в теоретической философии то, чем объединяются в мысли и в действительности известная совокупность фактов.ов из работы [ATKI89]).

Основной вопрос, по которому мы расходимся во мнениях с большей частью сообщества OODB, – возможность естественной эволюции современных реляционных систем к системам, поддерживающим возможности, обсуждаемые в данной работе. Мы верим в такую возможность. Продукты агрессивных поставщиков реляционных систем уже удовлетворяют принципам 1, 2 и 3 и обеспечивают хорошую поддержку предложений 1.3, 1.4, 1.5, 2.1, 2.3, 2.4, 3.1, 3.3 и 3.4. Для превращения в СУБД третьего поколения в эти продукты осталось добавить наследование и дополнительные конструкторы типов и внедрить языки программирования с поддержкой стабильных данных. Существуют прототипы систем, указывающие пути включения и этих средств.

С другой стороны, современные системы, провозглашаемые объектно-ориентированными, обычно не соответствуют нашим принципам и поддерживают лишь предложения 1.1 (частично), 1.2, 1.3 и 3.2. Для превращения в подлинные СУБД третьего поколения таким системам не хватает языка запросов и оптимизатора запросов, системы правил, поддержки SQL в архитектуре клиент/сервер, поддержки представлений и языков программирования со стабильными данными. Кроме того, в них должны быть отменены любые жесткие требования наличия уникальных идентификаторов и прекращено поощрение навигации. Более того, в них необходимо построить языки четвертого поколения, внедрить поддержку распределенных баз данных и осуществить настройку системы для эффективного управления данными.

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

Библиография

сентябрьСентябрь (лат.September)— девятый месяц Григорианского календаря, один из четырёх григорианских месяцев с 30-ю днями. Сентябрь— начало осени в северном полушарии Земли и начало весны в южном.

ноябрьНоябрь (лат.November)— одиннадцатый месяц Григорианского календаря. Девятый месяц староримского года, начинавшегося до реформы Цезаря с марта. Название получил от лат.novem— девять. Последний месяц календарной осени в Северном полушарии, весны в Южном.

SmalltalkSmalltalk (произносится [смолток])— объектно-ориентированный язык программирования с динамической типизацией, разработанный в Xerox PARC Аланом Кэйем, Дэном Ингаллсом, Тедом Кэглером, Адель Голдберг, и другими в 1970-х годах. Язык был представлен как Smalltalk-80. Smalltalk продолжает активно развиваться и собирает вокруг себя сообщество пользователей.

PrototypeПрототип (от др.-греч. — первый и — отпечаток, оттиск)— прообраз, образец, оригинал.

FerrariFerrari S.p.A. (кратко: Ferrari— рус. «Феррари»)— итальянская компания, выпускающая спортивные автомобили, базирующаяся в Маранелло. Основана в 1928 году Энцо Феррари как Scuderia Ferrari, компания спонсировала гонщиков и производила гоночные машины до 1947 года. С 1947 года начала выпуск «уличных» (англ.street-legal) спортивных автомобилей под маркой «Ferrari S.p.A.». На протяжении всей своей истории, компания участвует в различных гонках, особенно в Формуле-1, где она имеет наибольший успех. Эмблема «Феррари»— вставший на дыбы жеребец на жёлтом фоне. Традиционный цвет автомобилей— красный.

январьЯнварь(лат.Jnurius mnsis «Янусов месяц»)— первый месяц года в юлианском и григорианском календарях, одиннадцатый месяц староримского года, начинавшегося до реформы Цезаря с марта. Один из семи месяцев, длиной в 31 день. Это, в среднем, самый холодный месяц года на большей части Северного полушария Земли (где январь является вторым месяцем зимы), и самый теплый месяц года на большей части Южного полушария (где январь— второй месяц лета, эквивалент июля Северного полушария).

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

LawrenceДжордж Ньюболд Лоуренс (англ.George Newbold Lawrence) — американский бизнесмен и орнитолог-любитель, который первым описал многие виды птиц.

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

²⁾ DB2, INGRES, NON-STOP SQL, ORACLE и Rdb/VMS – торговые марки соответственно IBM, INGRES CorporationКорпорация (от новолат.corporatio— объединение)— юридическое лицо, которое, являясь объединением физических лиц, при этом независимо от них (то есть самоуправляемо). В широком смысле под корпорацией можно понимать всякое объединение с экономическими целями деятельности., Tandem, ORACLE Corporation и Digital Equipment Corporation.

³⁾ Можно, конечно же, утверждать, что реляционная система со всеми этими расширениями уже не может называться реляционной, но дело не в этом. Дело в том, что такие расширения возможны и совершенно естественны.

⁴⁾ Этот комментарий отражает давний спор между сторонниками инкапсуляции данных и людьми, которые считают необходимой прозрачность данных при интерактивном доступе. Нужно отметить, что полного согласия нет ни в лагере сторонников направления третьего поколения БД, ни в лагере ООБД. Мне лично в обоих лагерях ближе сторонники инкапсуляции. – Прим. научн. ред.