CC BY
20УДК 004.65
постреляционная система управления базой данных на основе словарной технологии
© уткин Г.С.1, жильцов С.А.2, Гананчян А.в.2, 2022
Мытищинский филиал МГТУ им. Н.Э. Баумана (МФ МГТУ) Ул. 1-я Институтская, 1, г. Мытищи, Московская обл., Российская Федерация, 141005,
e-mail: mgul@mgul.ac.ru
2Ракетно-космическая корпорация имени С.П. Королёва (РКК «Энергия») Ул. Ленина, 4А, г. Королёв, Московская обл., Российская Федерация, 141070,
e-mail: post@rsce.ru
Предстоящий этап преобразований по расширению границ применения информационных технологий в деятельности предприятий ракетно-космической отрасли подразумевает значительный рост потоков обрабатываемой информации. Для надёжного и безопасного хранения, передачи, классификации и последующего анализа информации различного вида необходимо располагать технологиями, способными поддержать не только внутреннюю деятельность предприятия, но и предоставить возможность прогнозирования стоимости и сроков выполнения опытно-конструкторских работ, основываясь на высоких требованиях к изделиям ракетно-космической техники и текущих производственных условиях.
Большие объёмы данных, а также их структурное разнообразие существенно влияют как на сложность проектирования реляционных баз данных, так и на скорость выполнения запросов. Отказ от однозначности полей в реляционной базе данных (отказ от требований первой нормальной формы) приводит к постреляционной модели данных. В постреляционной модели данных существенно сокращается количество таблиц (за счёт их вложения) при сохранении простоты структуры и возможности объектного подхода. При построении системы управления постреляционной базой данных возникает множество технических проблем, связанных с хранением и доступом к данным. Авторы предлагают их решение путём построения системы управления постреляционной базы данных на основе словарной технологии.
Разработанная авторами словарная технология обладает функциональной полнотой и высокой скоростью работы с информацией, представленной в лексикографическом виде. Блочное построение базы данных позволяет представить данные в виде многомерных кубов, что присуще многомерным базам данных. Хранение данных организовано в виде словарей, количество которых определяется количеством блоков, количеством атрибутов и способом представления таблиц с учётом возможности ведения вложенных таблиц. Управление большим количеством словарей реализовано в виде словарного диспетчера. Диспетчер на основе словаря организует доступ ко всем составляющим словарей базы данных. Построение словаря специальной структуры решает задачу пополнения базы данных без существенной перестройки словаря хранения данных, при этом нет необходимости использования процедур индексации. Структура данных описана в словаре-справочнике, что позволяет оперативно изменять структуру базы данных без необходимости коррекции хранения данных. Для выполнения запросов разработан словарный язык запросов, позволяющий задавать множество условий для отбора информации. Данный подход представляется перспективным в плане создания промышленных систем управления базами данных.
Ключевые слова: система управления базой данных, база данных, модели данных, постреляционная база данных, словарная технология.
EDN: WDQIUX
post-relational database
management system
based on dictionary technology
utkin G.S.1, Zhiltsov S.A.2, Gananchyan A.V.2
Mytishchi Branch of Bauman Moscow State Technical University
(MB MSTU)
1 1st Institutskaya st., Mytishchi, Moscow region, 141005, Russian Federation,
e-mail: mgul@mgul.ac.ru
2S.P. Korolev Rocket and Space Corporation Energia (RSC Energia) 4A Lenin st., Korolev, Moscow region, 141070, Russian Federation, e-mail: post@rsce.ru
The upcoming phase of transformations aimed at expanding the application of information technologies to the activities of companies in rocket and space industry involves a significant increase in the flow of processed data. To achieve reliable and safe storage, transmission, classification and subsequent analysis of various types of data, one needs to have technologies not only capable of supporting the internal activities of the company, but also providing the ability to predict the costs and time required for completion of research and development efforts based on stringent requirements set for rocket and space hardware and current manufacturing environment.
The large amount of data, as well as their structural diversity have a significant impact on both the complexity of designing relational databases and the query response time. Electing not to use unambiguous fields in the relational database (wavering the requirement of the first normal form) results post-relational data model. In post-relational data model the number of tables is significantly reduced (due to their nesting) while preserving simplicity of structure and the option of object orientation. Constructing a post-relational database management system entails a multitude of technical problems related to data access and storage. The authors propose to solve them through constructing the post-relational database management system based on dictionary technology.
The dictionary technology developed by the authors has functional completeness and high rate of handling the data presented in lexicographic form. The modular architecture of the database makes it possible to present data as multidimensional cubes, which is inherent in multidimensional databases. Data storage is organized in the form of dictionaries, the number of which is driven by the number of blocks, the number of attributes and the method of representing tables, taking into account the option to maintain nested tables. Managing a large number of dictionaries is implemented in the form of a dictionary manager. The dictionary-based manager organizes access to all the components of the database dictionaries. Constructing a dictionary with specialized structure solves the problem of augmenting the database without significant restructuring of the data storage dictionary, while obviating the need to use indexing procedure. The data structure is described in the reference dictionary, which makes it possible to quickly change the database structure without the need to update data storage. To execute queries, a dictionary query language was developed, which makes it possible to set multiple conditions for data selection. This approach seems promising in terms of development of industrial systems for database management.
Key words: database management system, database, data models, post-relational database, dictionary technology.
УТКИН Георгий Степанович — кандидат технических наук, доцент кафедры К1 космического факультета МФ МГТУ, e-mail: nmugs@mail.ru
UTKIN Georgy Stepanovich — Candidate of Science (Engineering), Associate professor at the K1 Department of MB MSTU, e-mail: nmugs@mail.ru
ЖИЛЬЦОВ Сергей Александрович — аспирант, старший аналитик-консультант РКК «Энергия», e-mail: sergey.zhiltsov@rsce.ru
ZHILTSOV Sergey Aleksandrovich — Postgraduate, Senior consulting analyst at RSC Energia, e-mail: sergey.zhiltsov@rsce.ru
ГАНАНЧЯН Алексей Витальевич — аспирант, ведущий программист РКК «Энергия», e-mail: aleksey.gananchyan@rsce.ru
GANANCHYAN Aleksey Vitalyevich — Postgraduate, Lead programmer at RSC Energia, e-mail: aleksey.gananchyan@rsce.ru
введение
В зависимости от модели данных, системы управления базой данных (СУБД) относят к определённому типу [1, 2]. Наибольшее распространение получили реляционные СУБД, опирающиеся на реляционную модель данных [3, 4]. Её основа была заложена британским учёным Эдгаром Коддом [5]. Эта модель данных имеет строгую математическую основу в виде реляционной алгебры и реляционного исчисления. Краткая и достаточно основательная сводка основных преимуществ реляционного подхода даётся в статье К. Дж. Дейта [6]. Увеличение объёмов и разнообразия информации в мире ставит задачу нахождения новых моделей и методов эффективной обработки данных. Это, в первую очередь, создание новых моделей данных, не требующих строго фиксированной структуры, и использование парадигмы объектно-ориентированного программирования.
Объектный подход при представлении данных стал использоваться в объектно-ориентированной модели [5, 7, 8]. Группой управления объектно-ориентированными данными был разработан стандарт
ODMG-93 [9]. В качестве недостатков объектно-ориентированной модели отмечаются высокая понятийная сложность и низкая скорость выполнения запросов, что является ограничением при использовании такого подхода для больших объёмов данных [10]. Принятие решений на основе обработки больших массивов данных, структурированных по многомерному принципу, определило создание систем аналитической обработки данных (online analytical processing — OLAP) [11, 12]. Создатель термина OLAP, Эдгар Кодд, предложил в 1993 г. «12 правил аналитической обработки в реальном времени» [13]. Если реляционные базы данных (БД) предназначались для систем оперативной обработки информации, то для аналитической обработки данных предназначались многомерные БД. Определённым развитием реляционных БД является постреляционная модель данных. Главным отличием постреляционной БД является допущение в модели представления данных многозначных полей. Это допущение существенно сказывается на модели представления данных и приводит к качественно новым возможностям.
При проектировании реляционной БД проектировщику необходимо осуществить нормализацию информации, т. е. разложить данные, содержащиеся в объектах, на множество таблиц, содержащих неделимые «атомарные» элементы информации. При установлении связей между таблицами проектировщику необходимо решить ряд проблем. Элементы данных реляционной модели, которые хранятся на пересечении строк и столбцов таблицы, должны быть неделимы и единственны. Если допустить, что значение данных может само состоять из подзначений, то в результате возникает понятие многозначного поля. О таблицах, содержащих многозначные поля, говорят, что они находятся в непервой нормальной форме, или NF2 (Non First Normal Form) [14]. При условии, что используемые поля подчиняются определённым правилам, позволяющим обращаться с ними, как с таблицами, встроенными в другие таблицы, форма NF2 не нарушает принципы реляционной алгебры.
В 1992 г. Дэвид Васкевич, директор департамента стратегических исследований фирмы Microsoft, написал статью [15], в которой анализировал различные направления развития СУБД и ставил вопрос: «Какой же будет СУБД после 2000 года?». Этот период он назвал постреляционным.
цель работы
Целью данной работы является определение возможности построения постреляционной системы управления БД, в которой механизмы хранения и поиска информации реализуются на основе словарной технологии [16, 17]. В работе предлагается рассмотреть основные задачи, возникающие при построении СУБД:
• представление постреляционной таблицы с учётом вложенных таблиц в словарном виде;
• управление хранением и отображением вложенных таблиц;
• хранение большого объёма данных и возможность использования многомерных кубов;
• словарное управление структурой БД;
• клиент-серверная реализация БД и возможность распределённого хранения;
• языки запросов и управления результатом выбора информации из БД и другие вопросы.
Методы решения поставленной задачи
Можно выделить большое количество разнообразных задач, где прослеживается следующая информационная структура:
• общая информация об объекте, которая редко изменяется, например: название, реквизиты, адреса и т. д.;
• постоянно меняющаяся информация, связанная с деятельностью объекта, например, ежедневный учёт операций, финансовые транзакции и т. д.
В этом случае при описании множества объектов возникает потребность включить меняющуюся информацию в объект, не перемешивая её с другой быстро меняющейся информацией другого объекта.
Использование вложенных таблиц в постреляционной БД успешно решает эту задачу. При этом сокращается количество таблиц, и в БД прослеживаются элементы объектного подхода. Это отмечается при рассмотрении постреляционной СУБД Cache [18]. При реализации постреляционной СУБД остаются достаточно сложными вопросы хранения и быстрого доступа к данным. Рассмотрим задачу построения постреляционной СУБД, сочетающей в себе возможности реляционной, объектно-ориентированной и многомерной моделей данных.
В качестве одного из возможных решений была разработана структура системы управления постреляционной БД, использующая словарную технологию. Название «словарная технология» было зарегистрировано как «Программа автоматизации работы с данными в словарном виде (словарная технология)» [16].
Словарная технология представляет собой набор программ эффективной работы с информацией, представленной в виде специальных динамических словарей [17]. Понятие «словарь» согласуется с определением, данным в книге Т. Кормена и др. [19]: «Словарь динамическое множество, поддерживающее операции вставки, удаления и принадлежности элемента множеству». Поддержка работы со словарями
имеется во многих языках программирования: Perl, PHP, Python, Ruby, Tcl, JavaScript и др. Для других языков имеются реализации в виде библиотек. У каждой реализации есть свои достоинства и недостатки. Реализация словаря в словарной технологии существенно отличается от всех известных реализаций. Некоторые особенности реализации словаря позволяют сделать работу с информацией более универсальной, а программирование с использованием такого представления словаря — более технологичным.
Реализация словаря в словарной технологии обладает следующими свойствами:
• используется естественное разбиение слов на узлы, фактически разбиением на узлы управляет сама информация;
• используется многоуровневое хранение информации в виде графа словаря с применением высокоскоростных алгоритмов доступа к данным, образ хранения — файл в оперативной памяти и на диске;
• хранение вместе со словами статистики — самое существенное отличие, которое превращает такое хранение в основу словарной технологии.
Подробно работа со словарями освещается в книге «Словарная технология» [17].
Структурные методы, развитые в словарной технологии, позволяют решить задачу построения постреляционной СУБД. В качестве одного из возможных решений рассмотрим модель постреляционной СУБД, которую будем называть TGRBD. Эта модель имеет полную программную реализацию в виде динамических библиотек. Управление данными осуществляется путём использования специальных словарей. Описание архитектуры БД и других особенностей реализации даётся в специальном словаре-справочнике. В предлагаемой модели данных используется разбиение записей таблицы БД на блоки, размер которых не превышает 900 000 записей.
Возможны различные стратегии разбиения БД на блоки:
• по количеству записей (если записи не умещаются в одном блоке);
• равномерное заполнение каждого блока;
• номер блока соответствует году хранения информации;
• по алфавиту названий записей с разбиением на блоки и отображением процента выполнения запроса при обработке каждого блока.
В модель была также заложена иерархическая структура, когда выбор блока определяется на более высоком уровне, обрабатывая несколько измерений (например: время, территория, количество).
Стратегия разбиения на блоки добавляет ещё один уровень представления данных, позволяет ввести дополнительные измерения, что соответствует многомерной модели данных. Для пользователя формат представления номера записи BBB.NNNNNN, где BBB — номер блока, NNNNNN — номер записи в блоке. Например, номер записи 023.002456 означает 2 456-ю запись в 23-м блоке.
В модель TGRBD заложены алгоритмы автоматизации ведения номеров записей при пополнении и удалении записей. Пользователю БД предоставлена ограниченная возможность по управлению номерами записей. В постреляционной таблице допускается повтор атрибутов. В реализации TGRBD допускается до 900 повторов каждого атрибута. Кроме повторов атрибутов допускаются также вложенные таблицы. В отличие от реляционной БД в постреляционной БД невозможно ограничиться для атрибута указанием только кода. Это приводит к требованию включения дополнительных параметров для управления позиционированием значений атрибутов при их повторе и, что особенно важно, при встраивании вложенных таблиц. В реализацию БД включено управление позиционированием атрибутов и их повторений.
Хранение данных в TGRBD реализовано в виде словарей. Для каждого блока используются три словаря:
C — словарь значений, хранит значение и код значения атрибута;
E — словарь прямой кодировки, хранит связку номера записи и кода значения атрибута;
F — словарь обратной кодировки, хранит связку кода значения атрибута с номером записи.
Массив номеров записей хранит
активные номера записей.
Максимальное число атрибутов в представлении одной таблицы ограничено
числом 900. Максимальное количество строк в одном блоке ограничено числом 900 000. Число блоков ограничено числом 900. Общее число записей в таблице не должно превышать 900x900 000 = 810 000 000.
Значения атрибута помещаются в отдельный специальный словарь (C) с автоматическим ведением кодировки слов. Каждому слову, помещённому в данный словарь, автоматически присваивается неизменяемый код. Все коды слов имеют тот же лексикографический порядок, что и слова в словаре.
Функции работы с таким словарём позволяют по любому слову выдать его код, по коду — слово (значение атрибута). Пополнение словаря и удаление из него слов не изменяют коды слов, находящихся в нём. Сохранение лексикографического порядка кодов, соответствующее порядку слов словаря, позволяет существенно упростить поисковые алгоритмы.
Механизмы, заложенные в словаре С, позволяют эффективно реализовать поиск информации, что фактически заменяет индексацию в БД.
Для восстановления записи по её номеру последовательно восстанавливаем код значения атрибута, и по словарю значений — значение атрибута.
Совокупность всех значений с учётом позиционирования составляет запись, используется словарь E (прямой кодировки). Номер записи начинается с номера блока, что позволяет определить словари E и C для восстановления записи. Позиция значения атрибута в записи также хранится в словаре E.
Для ведения номеров записей использование словаря нецелесообразно. Хранение номеров ведётся в массиве и с использованием маскировки и алгоритма сжатия.
Таким образом, для каждого атрибута и каждого блока создаются три словаря (C, E, F) и массив номеров записей (D). Управление хранением и доступом к информации осуществляется словарным диспетчером через функции поискового сервиса.
Даже для не очень больших таблиц число словарей может оказаться достаточно большим. Из реально существующих БД в TGRBD была построена таблица на несколько миллионов записей, для которой число словарей составило ~60 000.
Для решения задачи управления большим количеством словарей с сохранением скоростных возможностей словарного представления был построен словарный диспетчер. Он построен на словарном управлении, то есть хранением информации управляет словарь, построенный по той же словарной технологии.
Анализ словарного управления показал, что система обладает уникальным свойством сбалансированности хранения относительно данных. Это позволяет строить многомерные словарные системы и способствует реализации практически бесконечного по объёму словаря.
Алгоритм работы с графом словаря запрашивает блок для дальнейшей работы. Словарный диспетчер хранит адреса блоков всех словарей в виде словаря. Поэтому запрос блока приводит к словарному поиску необходимого блока и выдаче его в алгоритм работы с обычным словарём. То есть, работа с большим количеством словарей сводится к двухуровневому алгоритму работы с обычным словарём. Учитывая высокие скорости доступа к данным (более 1 000 000 слов в секунду) в алгоритмах словарной технологии, работа с большим количеством словарей происходит достаточно быстро. В зависимости от формата описания адресов хранения блоков словарей диспетчер может работать с одним или несколькими файлами, в последнем случае можно реализовать распределённое хранение.
Вся логика построения БД, описатели полей, различные справочники, связанные с конкретной БД, помещаются в один словарь-справочник. Тем самым хранение данных отделено от логики работы с данными. Смена логики работы становится простой — необходимо поправить описание в справочнике. Сам справочник реализован в виде большого количества словарей в одном файле.
На основе анализа стандартного языка SQL в TGRBD было разработано управление, учитывающее возможности расширения используемой модели данных и особенности словарной реализации БД.
Управление БД в TGRBD реализовано в виде двух функций и их перегружаемых модификаций:
• информационные сервисные функции;
• функции прямого управления БД.
Информационные сервисные функции позволяют:
• инициализировать БД;
• получать различную информацию по БД, обычно содержащуюся в справочнике БД, или статистическую информацию, содержащуюся непосредственно в БД;
• изменять информацию, содержащуюся в справочнике БД.
Функции прямого управления БД позволяют:
• внести изменения в БД (добавить, изменить, удалить запись);
• выполнить различные поисковые запросы;
• выполнить другие административные действия по ведению БД.
Поисковый сервис реализован через функции прямого управления БД. Для прямого управления БД используется функция int DWPROC (SLV*slkd, SLV*slin, SLV*slout, SLV*slerr, void (*drawProgress) (int a)), где:
• slkd — словарь действий, реализует управление выводом на языке вывода;
• slin — словарь условий, реализует запросы к БД на языке запросов;
• slout — словарь результата;
• slerr — словарь описания ошибок и вывода другой информации;
• drawProgress — отображение процента выполнения, позволяет прервать запрос.
Запрос к БД определяется содержанием двух словарей: словаря действий slkd и словаря условий slin. В словарь условий записываются команды, управляющие отбором информации, а результат запроса определяется содержанием словаря действий. Все действия выполняются над всей БД или над записями, которые определились в результате выполнения запросов, для которых логические условия отбора информации заданы в словаре условий. В одном обращении к функции DWPROC можно в словарном виде задать сразу множество действий. Отсутствие противоречий и ожидаемые результаты должен оценивать пользователь. Это же касается и разбора результата в словаре результата, где вся информация будет представлена в словарном виде.
Возможность задавать в одном словаре множество действий, а в другом — множество условий на отбор результатов порождает большое количество реализаций запросов к БД. Все случаи
при различных сочетаниях условий разобрать невозможно. В любом случае пользователь должен руководствоваться логикой запрашиваемой информации. В некоторых случаях можно упростить логику обработки результатов запросов, используя последовательность запросов, когда функция DWPROC вызывается несколько раз.
Способ представления постреляционной БД в словарной технологии определяет доступ к элементам данных:
• имя таблицы — второй атрибут БД «Таблица» (код P002), позволяющий использовать его как имя столбца;
• первичный ключ — набору ключевых полей соответствует номер записи, в данном случае это BBB.NNNNNN, где BBB — номер блока, NNNNNN номер записи в блоке;
• имя столбца — имени столбца соответствует код PKKK.
Если таблица постреляционная, с повтором полей или вложением таблиц, то при определении атомарного значения требуется указывать параметр позиционирования.
Для управления позиционированием значений атрибутов при встраивании вложенных таблиц вводим дополнительный параметр в формат BBB.NNNNNN.PPP.PKKK = <значение атрибута>, где PPP — позиция значения атрибута в записи.
Стандартным запросом на выборку информации из реляционной БД в языке SQL является инструкция SELECT. В предложении SELECT указывается список столбцов, которые должны быть возвращены инструкцией SELECT. В предложении FROM указывается список таблиц, которые содержат элементы данных, извлекаемые запросом. Далее задаётся дополнительная информация запроса, включающая условия отбора. Предложениям SELECT и FROM языка SQL соответствует информация, задаваемая в словаре действий slkd, условия отбора формируются в словаре условий slin.
В качестве технологии построения клиент-серверной реализации СУБД выбрана технология Indy (от англ. Internet direct) — набор интернет-компонентов, использующих модель сблокированных сокетов. Indy-технология хорошо решает задачи построения клиент-серверных приложений, использующих локальные сети
организации. Это обусловило выбор Indy-технологии для реализации клиент-серверной постреляционной СУБД. Для построения клиента и сервера используются стандартные компоненты Indy-технологии:
• IdTCPServer — серверный компонент, создающий для каждого клиента отдельный поток;
• IdTCPClient — клиентский компонент, использующий протокол TCP/IP.
Для реализации удалённых запросов были разработаны специальные транспортные словари. Транспортный словарь — специальное представление словаря в буфере.
Реализация словарного обмена в Indy-технологии была выполнена в виде динамической библиотеки IndyClient, где были реализованы функции выполнения удалённых запросов к постреляционной СУБД.
Для практической реализации БД предлагается использовать динамические библиотеки:
• словарной технологии;
• сервисных функций словарной технологии;
• диспетчера управления словарями;
• сервиса реализации запросов к БД;
• клиент-серверной реализации.
Пользователь может разрабатывать прикладные программы в среде визуального программирования на языке C++ и включать в свои программы работу с постреляционной БД на основе словарного управления. Для этого достаточно к своей программе подключить стандартным способом предлагаемые динамические библиотеки.
Результаты и обсуждение
Предложенная модель постреляционной СУБД сочетает в себе три модели данных: реляционной, объектно-ориентированной и многомерной. Словарная технология, лежащая в основе построения СУБД, позволяет эффективно решать вопросы хранения больших объёмов информации с обеспечением быстрого доступа к данным. Словарное управление структурой БД существенно упрощает администрирование. Кодирование информации в словарях кроме сжатия информации обеспечивает определённую защиту. Скоростные возможности работы с данными позволяют проводить аналитику путём
прямых запросов к БД. Так, в реально работающих БД в каждый результат запроса включается статистика (для каждого значения поля указывается количество значений, соответствующих данному запросу). Предложенные методы построения постреляционных БД были опробованы при реализации коммерческих баз данных в информационных агентствах и использовались в управлении учебным процессом: построена информационно-управляющая система кафедры, система работы с источниками информации, система архивации данных и другие системы.
Выводы
Построение постреляционной СУБД на основе словарной технологии можно рекомендовать для БД с большим количеством информации и при большом разнообразии атрибутов. Среди полученных решений следует отметить следующие:
• быстрое лексикографическое пополнение информации без перестройки словарей, фактически — отказ от дополнительной индексации;
• словарное управление (словарный диспетчер), когда словарь управляет работой других словарей с возможностью распределённого хранения;
• словарная реализация запросов, когда в отбор информации можно включать множество условий.
Данный подход представляется перспективным в плане создания технической среды сбора, обработки и анализа цифровых данных, порождаемых существующими информационными системами и отдельными цифровыми устройствами. Накопленные данные об изделии могут использоваться для научных исследований, задач усовершенствования конструкции, поиска новых конструкторских решений и эффективного применения существующих наработок по созданию ракетно-космической техники.
Список литературы
1. Когаловский М.Р. Энциклопедия технологий баз данных. М.: Финансы и статистика, 2002. 800 с.
2. Date C.J. Date on Database: Writings 2000-2006. Apress Berkeley, CA, 2006. 568 p.
3. Дейт К.Дж. Введение в системы баз данных. 8-е изд. М.: Вильямс, 2005. 1327 с.
4. Коннолли Т., Бегг К. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 3-е изд. М.: Вильямс, 2003. 1436 с.
5. Codd E.F. A Relational Model of Data for Large Shared Data Banks // Communications of the ACM. 1970. V. 13. № 6. P. 377-387.
6. Date C.J. Relational Database: Writings 1985-1989. Boston, MA, US: Addison-Wesley Longman Publishing Co., 1990. 528 p.
7. Won Kim. Object-oriented databases: definition and research directions // IEEE Trans. Knowl. Data Eng. 1990. V. 2. № 3. P. 327-341. Режим доступа: https://doi. org/10.1109/69.60796 (дата обращения 30.08.2022 г.).
8. Nierstrasz O. A survey of object-oriented concepts // In: Object-oriented concepts, databases and applications, ed. by W. Kim, F. Lochovski. ACM Press and Addison-Wesley, 1989. P. 3-21.
9. The Object Data Standard: ODMG 3.0. Ed. by R.G.G. Cattel, Douglas K. Barry. Morgan Kauffmann Publishers, 2000. 222 p.
10. Navathe S.B., Pillalamarri M.K. OOER: Toward Making the E-R Approach Object-Oriented // Proceedings of the Seventh International Conference on Enity-Relationship Approach: A Bridge to the User. November 1988. P. 185-206.
11. Alalouf C. Hybrid OLAP. St. Laurent, Canada: Speedware Corporation Inc., 1997.
12. Parsaye K. OLAP and Data Mining: Bridging the Gap // Database Programming and Design. 1997. № 2. P. 30-37.
13. Codd E.F. Providing OLAP (On-line Analytical Processing) to User-analysts: An IT Mandate. Codd & Associates, 1993. 26 p.
14. Roth M.A., Korth H.F., Silberschatz A. Extended algebra and calculus for nested relational databases // ACM Transactions on Database Systems. Dec. 1988. V. 13. Issue 4. P. 389-417. Режим доступа: https://doi.org/10.1145/49346.49347 (дата обращения 30.08.2022 г.).
15. Vaskevitch D. Two steps forward, one step back // BYTE. 1992. Issue 5. Р. 141-146.
16. Уткин Г.С., Поликарпова Д.А., Поликарпов Е.А. Программа автоматизации работы с данными в словарном виде (Словарная технология) // Хроники Объединённого фонда электронных ресурсов «Наука и образование». 2016. № 10(89). С. 9-10. Режим доступа: http://o fernio.ru/portal/newspaper/ ofernio/2016/10.pdf (дата обращения 30.08.2022 г.).
17. Уткин Г.С. Словарная технология. М.: Изд-во МГТУ им. Н.Э. Баумана, 2019. 215 с.
18. Кирстен В., Ирингер И., Рёриг Б., Шульте П. СУБД Cache: объектно-ориентированная разработка приложений. СПб: Питер, 2001. 384 с.
19. Кормен Т., Лейзерсон Ч, Ривест Р., Штайн К. Алгоритмы: построение и анализ. М.: Вильямс, 2005. 1296 с.
Статья поступила в редакцию 06.05.2022 г. Окончательный вариант — 03.06.2022 г.
References
1. Kogalovskiy M.R. Entsiklopediya tekhnologiy baz dannykh [Database Technology Encyclopedia]. Moscow, Finance and Statistics, 2002, 800 p. (in Russian).
2. Date C.J. Date on Database: Writings 2000-2006., Apress Berkeley, CA, 2006, 566 p.
3. Date C.J. [An Introduction to Database Systems], 8th Edition, Moscow, Williams Publ., 2005, 1328 p. (in Russian).
4. Connolly Th., Begg C.E. [Database systems. A Practical Approach to Design, and Management]. Moscow, Williams Publ., 2003, 1436 p. (in Russian).
5. Codd E.F. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 1970, vol. 13, no. 6, pp. 377-387.
6. Date C.J. Relational Database Writings 1985-1989. Boston, MA, US, Addison-Wesley Longman Publishing Co., 1990, 528 p.
7. Won Kim. Object-Oriented Databases: Definition and Research Directions. IEEE Trans. Data and Knowledge Eng., 1990, vol. 2, no. 3, pp. 327-341. Available at: https://doi.org/10.1109/69.60796 (accessed 30.08.2022).
8. Nierstrasz O. A Survey of Object-Oriented Concepts. In: W. Kim, F. Lochovski (editors) Object-Oriented Concepts, Databases and Applications. ACM Press and Addison-Wesley, 1989, pp. 3-21.
9. Cattel R.G.G., Barry D.K. (editors) The Object Data Standard: ODMG 3.0. Morgan Kauffmann Publishers, 2000, 222 p.
10. Navathe S.B., Pillalamarri M.K. OOER: Toward Making the E-R Approach Object-Oriented. Proceedings of the 7th International Conference on Entity-Relationship Approach: Bridge User, Rome, 1988, pp. 185-206.
11. Alalouf C. Hybrid OLAP. St. Laurent, Canada, Speedware Corporation Inc., 1997.
12. Parsaye K. OLAP and Data Mining: Bridging the Gap. Database Programming and Design, 1997, no. 2, pp. 30-37.
13. Codd E.F., Codd S.B., Salley C.T. Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate. Codd & Associates, 1993. 26 p.
14. Roth M.A., Korth H.F., Silberschatz A. Extended Algebra and Calculus for Nested Relational Databases. ACM Transactions on Database System, 1988, vol. 13, issue 4, pp. 390-417. Available at: https://doi.org/10.1145/49346.49347 (accessed 30.08.2022).
15. Vaskevitch D. Two Steps Forward, One Step Back. BYTE, 1992, issue 5, pp. 141-146.
16. Utkin G.S., Polikarpova D.A., Polikarpov E.A. Programma avtomatizatsii raboty s dannymi v slovarnom vide (Slovarnaya tekhnologiya) [Program for automation of work with data in a dictionary form (Dictionary Technology)]. Chronicles of the Joint Electronic Resources Foundation "Science and Education", 2016, no. 10 (89), pp. 9-10. Available at: http://ofernio.ru/portal/newspaper/ofernio/2016/10.pdf (accessed 30.08.2022) (in Russian).
17. Utkin G.S. Slovarnaya tekhnologiya [Dictionary Technology]. Moscow, BMSTU Publ., 2019, 215 p.
18. Kirsten V., Iringer I., Rerig B., Shul'te P. SUBD Cache: ob"ektno-orientirovannaya razrabotka prilozhenii [DBMS Cache: Object-Oriented Application Development]. St. Petersburg, Peter, 2001. 384 p.
19. Cormen T.H., Leiserson C.E., Rivest R.L., Stein C. [Introduction to algorithms], second edition, Moscow, Williams Publ., 2005, 1296 p.
