Хранилища данных на реляционном каркасе
Предложен новый поход к моделированию темпоральных баз данных. Показано, что классическая реляционная схема хранилища данных «снежинка» – частный случай реляционного каркаса. Введено понятие корректной модификации данных и метаданных. A new approach to designing temporal data is suggested. It is sho...
Gespeichert in:
| Veröffentlicht in: | Управляющие системы и машины |
|---|---|
| Datum: | 2013 |
| 1. Verfasser: | |
| Format: | Artikel |
| Sprache: | Russisch |
| Veröffentlicht: |
Міжнародний науково-навчальний центр інформаційних технологій і систем НАН та МОН України
2013
|
| Schlagworte: | |
| Online Zugang: | https://nasplib.isofts.kiev.ua/handle/123456789/83133 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Zitieren: | Хранилища данных на реляционном каркасе / Б.Е. Панченко // Управляющие системы и машины. — 2013. — № 1. — С. 71-84. — Бібліогр.: 19 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859993321024258048 |
|---|---|
| author | Панченко, Б.Е. |
| author_facet | Панченко, Б.Е. |
| citation_txt | Хранилища данных на реляционном каркасе / Б.Е. Панченко // Управляющие системы и машины. — 2013. — № 1. — С. 71-84. — Бібліогр.: 19 назв. — рос. |
| collection | DSpace DC |
| container_title | Управляющие системы и машины |
| description | Предложен новый поход к моделированию темпоральных баз данных. Показано, что классическая реляционная схема хранилища данных «снежинка» – частный случай реляционного каркаса. Введено понятие корректной модификации данных и метаданных.
A new approach to designing temporal data is suggested. It is shown that the classic relation scheme of a data warehouse «snowflake» is a special case of a relational framework. A new definition of correct modification of data and metadata is introduced.
Запропоновано новий підхід до моделювання темпоральних баз даних. Показано, що класична реляційна схема сховища даних «сніжинка» є окремим випадком реляційного каркасу. Введено поняття коректної модифікації даних та метаданих.
|
| first_indexed | 2025-12-07T16:33:09Z |
| format | Article |
| fulltext |
УСиМ, 2013, № 1 71
Информационные и коммуникационные среды
УДК 004.652
Б.Е. Панченко
Хранилища данных на реляционном каркасе
Предложен новый поход к моделированию темпоральних баз данных. Показано, что классическая реляционная схема хранилища
данных «снежинка» – частный случай реляционного каркаса. Введено понятие корректной модификации данных и метаданных.
A new approach to designing temporal data is suggested. It is shown that the classic relation scheme of a data warehouse «snowflake»
is a special case of a relational framework. A new definition of correct modification of data and metadata is introduced.
Запропоновано новий підхід до моделювання темпоральних баз даних. Показано, що класична реляційна схема сховища даних
«сніжинка» є окремим випадком реляційного каркасу. Введено поняття коректної модифікації даних та метаданих.
Введение. Потребность в моделировании тем-
поральности данных обусловлена динамическим
характером функционирования любой системы.
Исторически это было важной причиной раз-
деления всех приложений баз данных (БД) на
два типа – оперативные, в которых моделиро-
вание времени может быть минимизировано, и
исторические, где время имеет принципиальное
значение. Эти БД получили соответствующие
названия – «оперативные» (или «транзакцион-
ные») и «хранилища» (или «аналитические»).
Принцип хранилищ данных (ХД) и их опре-
деление предложил У. Инмон [1]. В его подходе
ХД – это «предметно-ориентированная, интег-
рированная, содержащая исторические данные,
целостная совокупность данных, предназначен-
ная для поддержки принятия управленческих
решений». В [1] дана и классификация ХД. Из
описанных типов, нас более всего будет инте-
ресовать виртуальное хранилище.
Виртуальное ХД [1] – это система, предостав-
ляющая интерфейсы и методы доступа к опера-
тивно-регистрирующей системе, которые эму-
лируют работу с данными, как с ХД. Это озна-
чает, что виртуальное ХД можно организовать,
создав ряд «обращений» (view) к БД либо при-
менив специальные средства доступа [2].
Главные достоинства такого подхода – про-
стота и низкая стоимость реализации, единая
платформа с источником информации и отсут-
Ключевые слова: схема реляционной базы данных, реля-
ционный каркас, темпоральные данные, хранилища дан-
ных, целостность данных, корректность модификаций.
ствие сетевых соединений между источником
информации и ХД. При этом хранилище, орга-
низованное в соответствии с каркасной схемой
БД, избавлено от большинства недостатков, опи-
санных в [3]. Схема такого ХД и приложения,
его обслуживающие, могут быть динамически
модифицируемы. А высокая производитель-
ность такой системы обеспечивается миними-
зацией операций соединения [4].
Следовательно, и модифицируемость схем
БД, и интеграция данных с другими источни-
ками, и отслеживание исторических измере-
ний, и подобие схем БД [5], и гарантии чисто-
ты данных [4], обеспечиваемые ограничениями
на домены и ключи, позволяют сделать вывод
о том, что объединение свойств оперативной
(OLTP) и архивной (OLAP) БД в одной каркас-
ной схеме возможно.
Постановка задачи
В [6] отмечено, что использование традици-
онной многомерной модели данных [1, 2] в мно-
гомерном ХД (МХД) сопряжено с определен-
ными трудностями. Для ее реализации требуется
больший объем памяти, так как при реализации
физической многомерности используется боль-
шое количество технической информации. По-
этому объем данных, поддерживаемый МХД,
обычно не превышает нескольких десятков ги-
габайт. При этом МХД труднее поддается мо-
дификации: при необходимости встроить еще
одно измерение требуется выполнить физиче-
скую перестройку всего многомерного куба.
Из этого следует, что применение систем хра-
нения, в основе которых лежит многомерное
72 УСиМ, 2013, № 1
представление данных, целесообразно только в
тех случаях, когда объем используемых данных
сравнительно невелик, а сама многомерная мо-
дель имеет стабильный набор измерений.
Реляционный каркас как шаблон для схем и
OLTP-БД, и OLAP-ХД позволяет иначе решить
эти вопросы. Проведем анализ возможности
организации ХД с использованием реляцион-
ного каркаса.
Причины появления ХД
Авторы [6] считают доказанным утвержде-
ние о том, что «… реляционная модель не есть
оптимальной с учетом задач анализа, посколь-
ку предполагает высокую степень нормализа-
ции, в результате чего снижается скорость вы-
полнения запросов». Однако, как показано в
[4, 7], при определенных условиях, этот вывод
не соответствует действительности. Скорость
выполнения запросов снижается не из-за нор-
мализации отношений, а из-за традиции проек-
тирования всех оперативных связей предметной
области (ПрО) только посредством запросов к
БД. Использование нормализованных по мето-
дике Кодда [8] отношений в произвольных за-
просах действительно требует значительного
числа операций соединения, что и приводит к
значительным временным затратам.
Высоконормализованные каркасные отноше-
ния (актуальные ячейки каркаса [4, 7]), избав-
ляющие пользователя от проектирования боль-
шинства оперативных запросов на соединение,
доказывают обратное утверждение.
Проанализируем основные мотивы [9] раз-
деления на оперативные БД и аналитические
ХД. А также сопоставим их со свойствами кар-
касной БД.
«Для проведения анализа данных требуется
привлечение внешних источников информации
(например, статистических отчетов), поэтому
ХД должно включать как внутренние корпора-
тивные данные, так и внешние данные».
Современные интернет-приложения позво-
ляют строить распределенные системы любой
вложенности. Поэтому приложения могут фор-
мировать и поддерживать в актуальном со-
стоянии все необходимые справочники непо-
средственно из «паутины». При этом объем та-
ких отношений-справочников будет значитель-
но меньшим в сравнении с объемом таблиц опе-
ративных данных.
«Для оперативной обработки требуются
данные за несколько последних месяцев, по-
этому объем аналитических БД как минимум
на порядок больше объема оперативных».
Работая с типизированной и унифицирован-
ной схемой БД, построенной на реляционном
каркасе, пользователь избавлен от проблемы со-
единений ЗНФ отношений, зависимых от те-
кущей семантики ПрО, посредством сложных
SQL-запросов разных типов. Поэтому большин-
ство операций на каркасной БД – это индекс-
ные выборки. При такой конфигурации БД ско-
рость реакции системы существенно повыша-
ется. И пользовательские приложения не кон-
курируют между собой, потому что работают с
разными фрагментами отношений.
«Оперативные БД могут содержать семан-
тически эквивалентную информацию, представ-
ленную в разных форматах, а иногда даже про-
тиворечивую. ХД должно содержать единооб-
разную и согласованную информацию, поэто-
му необходима компонента «очистки» инфор-
мации».
Однако строгость ограничений на домены и
ключи (взаимообусловленность данных [7]) не
дает возможности использовать данные от сущ-
ностей–объектов в виде омонимов и синонимов.
«Большинство запросов к оперативной БД
известно уже при проектировании, а набор за-
просов к ХД предсказать невозможно. Размеры
ХД стимулируют использование запросов с аг-
регатами – сумма, минимальное, максималь-
ное, среднее значение и т.д.».
В [10] показано, что каркасный анализ ПрО
позволяет предсказать большинство актуальных
связей в ПрО. И тем самым проектировать от-
ношения, накапливающие в своих шунтирую-
щих атрибутах все необходимые виды агреги-
рованных данных. А также интегрировать новые
запросы пользователей в новых отношениях.
Поскольку каркасная модель основана на буле-
ане связей, проектировщик имеет возможность
НФ – нормальная форма.
УСиМ, 2013, № 1 73
динамически интегрировать в хранимые отно-
шения данные для любого вновь возникшего
запроса.
Несложно показать, что даже при появлении
между агрегированными шунтирующими атрибу-
тами отношений дополнительных, необусловлен-
ных ограничениями на домены и ключи отноше-
ния, функциональными зависимостями (ФЗ),
нормальность формы отношений снижается лишь
до 5НФ, если изначально она была доменно-
ключевой (ДКНФ) [4].
Для монотонного агрегирования докажем это
утверждение в виде леммы. Атрибут S каркас-
ного отношения со схемой R(X, S), где X явля-
ется ключом, полученный произвольной моно-
тонной функцией F(Ri(Xi, Aij)) от произвольной
совокупности Ai,j неключевых атрибутов иных
каркасных отношений Ri, каждое из которых
удовлетворяет только особым ограничениям [4],
не является детерминантом отношения R.
Доказательство проведем от противного.
Пусть существует некоторая функция F такая,
что S = F(Ri(Xi, Aij)) – также детерминант от-
ношения R(X, S), как и X. Но тогда, поскольку
функция монотонна, для нее найдется обрат-
ная функция Z = F–1 такая, что Z(R(X, S)) = Aij .
Тогда атрибут Aij – также детерминант отно-
шения Ri(Xi, Aij), так как монотонная функция
не устраняет иных ФЗ атрибутов–аргументов,
в том числе и Aij Xi. Но такой ФЗ нет в явном
виде в особых ограничениях на домены и клю-
чи каркасного отношения [4] доминант. Такая
ФЗ должна оговариваться отдельно. Противо-
речие доказывает лемму. □
Из доказанного следует, что использование
в одном кортеже нескольких агрегированных
атрибутов от разных аргументов агрегирования
не приводит отношения к денормализации, так
как никаких «паразитных» ФЗ между агрегатами
не возникает. Но следует также и то, что исполь-
зование в одном кортеже нескольких агрегиро-
ванных атрибутов от одного аргумента агреги-
рования приведет к денормализации. В таком от-
ношении появятся транзитивные ФЗ в неключе-
вых шунтирующих агрегированных атрибутах.
С одной стороны, транзитивные ФЗ, которые
появляются между несколькими агрегированны-
ми шунтирующими атрибутами от общего аргу-
мента агрегирования, не являются критически-
ми, так как устраняются обычной декомпозици-
ей на несколько каркасных отношений, каждое
из которых может хранить необходимый един-
ственный агрегат. Но с другой стороны, хране-
ние значительного числа результатов агрегиро-
вания от громоздких функций может привести к
значительным временным затратам на операции
по отслеживанию целостности этих данных. По-
этому решение проектировщик принимает исхо-
дя из статистики запросов.
Интуитивно понятно, что при использовании
для агрегации более сложных вычислимых
функций [12], нежели монотонные, также не воз-
никнет неконтролируемых детерминантов. Но
такое утверждение требует более глубокого ис-
следования, которое выходит за рамки статьи.
Однако заметим, что вероятность появления у
пользователя потребности в усложненных алго-
ритмах агрегации крайне мала. Поэтому моно-
тонных арифметических функций достаточно
для моделирования большинства OLAP-потреб-
ностей пользователя.
«Схемы оперативных БД являются измен-
чивыми, а при малой изменчивости ХД нужны
быстрые методы индексации при массовой вы-
борке и хранении агрегированных данных».
Те СУБД, которые поддерживают унифици-
рованные схему оперативных и аналитических
БД, имеют равноправные операции динамиче-
ской модификации таких схем. Например, по-
зволяют применять единые процедуры индек-
сирования как оперативных, так и аналитиче-
ских отношений. А также процедуры отслежи-
вания целостности ключей и неключевых опе-
ративных и агрегированных данных.
Таким образом, как показывает практика, ни
один из перечисленных факторов не позволяет
однозначно сделать вывод о том, что нецеле-
сообразно эксплуатировать единое простран-
ство БД и как оперативное, и как аналитиче-
ское хранилище.
Основная причина такого разделения веро-
ятнее всего заключается в невозможности кор-
ректного совмещения совокупности 3НФ отно-
шений, которые навязаны большинством учеб-
74 УСиМ, 2013, № 1
ников по БД, и семантически-ориентированных
схем ХД типа многомерных кубов [1] или реля-
ционной звезды/снежинки [2]. Более того, по-
требность пользователей в таком объединении
общеизвестна. В [11] эта концепция описана в
разделах «Исчезновение отдельных хранилищ
данных» и «Хранилища данных в режиме реаль-
ного времени». А ранее аналогичная потреб-
ность была исследована и предложена в [13].
Дальнейшие внедрения этого подхода разными
пользователями подтвердили такой вывод.
Реляционный каркас и ХД
Рассмотрим представленную на рис. 1 клас-
сическую [2] схему ХД снежинка, заимствован-
ную из [6]. Представим ее в предикатной фор-
ме. При этом для атомарных сущностей–объ-
ектов учтем рекомендации большинства учеб-
ников по БД о присвоении не более чем унар-
ного ключа [14, 15]. Однако заметим, такой под-
ход к назначению ключей-отношений в данной
схеме возможен лишь потому, что уникальной
особенностью схемы снежинка является то, что
любое отношение–измерение моделирует только
или атомарные, или слабые сущности–объекты.
Рис. 1. Схема ХД «снежинка»
Имеем: ЛОКАЛИЗАЦИЯ (КодЛокал, Наиме-
нов), ПОКУПАТЕЛЬ (КодПокуп, Наименов),
ДАТА (НомГода, НомМес, НомДня), ТИП ГО-
РОДА (КодТипаГор, Наименов), ГОРОД (Код-
ТипаГор, КодГор, Наименов), ГРУППА ТОВА-
РОВ (КодГруппы, Наименов), ТОВАР (КодГруп-
пы, КодТовара, Наименов), ФАКТЫ (КодФакта,
Наименов, Значение).
Для получения итоговых документов необ-
ходимо посредством выполнения запросов к
ХД осуществить соединения указанных отно-
шений – некоторую совокупность декартовых
произведений. Тогда интересующие пользова-
теля отчеты будут иметь вид: ПОСТАВКА ТО-
ВАРОВ ЗА ГРУППУ МЕСЯЦЕВ НЕКОТОРО-
ГО ГОДА (НомГода, НомМес, КодТипаГор,
КодЛокал, КодГор, КодТовара, КодГрупТов, Ко-
личество, НаСумму), ПОСТАВКА ТОВАРОВ
НЕКОТОРОМУ ПОКУПАТЕЛЮ ЗА ГРУППУ
МЕСЯЦЕВ НЕКОТОРОГО ГОДА (НомГода,
НомМес, КодПокупат, КодТовара, КодГрупТов,
Количество, НаСумму) и др.
Тогда в общем виде отчет произвольной
вложенности будет подобен отношению
1 2 1 2( , )k nREPORT X X X A A A .
Таким образом, на базе произвольной совокуп-
ности отношений–измерений классической схе-
мы реляционного ХД снежинка всегда может
быть получено произвольное отношение–факт,
подобное актуальной ячейке реляционного кар-
каса [4].
Основным отличием снежинки от реляци-
онного каркаса есть полнота совокупности от-
ношений. Это дает возможность поддерживать
косвенные связи между отношениями по не-
полному соответствию ключей, моделировать
рекурсивные связи сущностей–объектов [10],
формировать в схеме БД не одну, а несколько
веток иерархических совокупностей отноше-
ний, а также поддерживать режим реального
времени. Дальше будет показано, что схема
ХД, построенная на реляционном каркасе, сво-
бодна и от недостатка низкой модифицируе-
мости, присущем МХД [6].
При этом семантически неактуальные кор-
тежи будут удалены. Это очень важное совпа-
дение позволяет сделать следующие выводы.
Схема реляционного ХД типа снежинка –
частный случай схемы БД, полученной на ре-
ляционном каркасе.
Схема ХД может быть подобной в смысле
[5] схеме оперативной БД, т.е. построена на
реляционном каркасе – и оперативные, и ана-
литические данные могут храниться в БД с
УСиМ, 2013, № 1 75
единой схемой и управляться приложениями,
синтезированными единым подходом.
В современных условиях хранить данные
в компактном виде нецелесообразно, так как
скорость получения отчетов – более важный
фактор, нежели цена хранения.
Причина разделения БД на OLTP и OLAP
заключается не в неудобстве использования, а
в неприспособленности нормализованных в
соответствии с алгоритмом [8] отношений к
OLAP-запросам.
Решето, отбраковывающее изоморфные
объекты
Для реляционного каркаса принципиально
важным есть его совпадение с методом рекур-
сивного решета. В [16] показано, что это метод
комбинаторного программирования, рассмат-
ривающий конечное множество и исключаю-
щий все элементы этого множества, не пред-
ставляющие интерес. Метод рекурсивного ре-
шета является логическим дополнением к про-
цессу поиска с возвращением, который пере-
числяет все неэквивалентные элементы мно-
жества.
Пусть из данного множества объектов необ-
ходимо исключить максимальное подмножест-
во попарно изоморфных объектов. Имеем мно-
жество объектов {a1, a2, a3, a4, a5, , an}. В со-
ответствии с алгоритмом решета находим все
ai = a1, i > 1 и вычеркиваем их. Для al1
– перво-
го, не вычеркнутого после a1, находим все
ai = al1
, i > l1 и вычеркиваем их. Продолжая да-
лее, получаем максимальное множество неэк-
вивалентных объектов. Таким образом, алго-
ритм решета, отбраковывающего изоморфные
объекты, подобен алгоритму исключения не-
актуальных ячеек каркаса [4, 7] из полной кар-
касной совокупности.
Сходство метода рекурсивного решета и ре-
ляционного каркаса позволяет утверждать, что
алгоритм поиска необходимой таблицы по кар-
касной совокупности будет вычислимым [12].
Модификация и деактуализация данных
Очевидно, что модификация БД может быть
двух типов – метаданных и данных. В связи с
возможностью объединения в каркасной БД и
оперативных, и аналитических (исторически-
архивных) данных, введем понятие корректной
модификации.
Под корректной модификацией метадан-
ных понимаем такое изменение схемы БД, ко-
торое не снижает степени нормализации ни
одного из отношений БД, а также не нарушает
целостность существующих данных.
Примером корректной модификации мета-
данных есть расширение поля для атрибута,
которое не меняет тип и значения существую-
щих в нем данных. Однако если модификация
атрибута затрагивает значения данных, она бу-
дет некорректной.
Добавление нового шунтирующего атрибу-
та, не являющегося детерминантом новой ФЗ,
не изменит степени нормализации каркасного
отношения. Но если в таком отношении суще-
ствуют данные, то для корректности модифика-
ции добавление еще одного шунтирующего ат-
рибута должно сопровождаться двумя действи-
ями: инициализацией незаполненных полей но-
вого атрибута данными, которые не разрушат
целостности иных данных, а также фиксацией
даты актуализации этих отношения и атрибута.
Для размещения даты актуализации мета-
данных и данных проектировщик использует
отдельные отношения–маски [10], которые свя-
зывают метаданные и данные. Очевидно, что
проектировщик должен заблаговременно поза-
ботиться о таких ситуациях и подобрать те
СУБД, которые поддерживают такие решения.
Отказ уполномоченного лица от заполнения
пустых полей нарушит целостность БД.
Более глубокие вопросы модификации ме-
таданных (схем БД) в статье не рассматрива-
ются. Однако необходимо отметить, что некор-
ректная модификация метаданных (редактиро-
вание схем задним числом) вызвана или плохим
предварительным анализом ПрО, или нацио-
нальными традициями ее функционирования.
Под корректной модификацией данных пони-
маем изменение значений одного или более ат-
рибутов, не вызывающее потери целостности БД.
Поскольку и приложение, и БД, разработан-
ные на основе каркасной модели, обладают уни-
версальными признаками – и оперативной сис-
76 УСиМ, 2013, № 1
темы, и ХД, примером некорректной модифи-
кации данных есть операция каскадного удале-
ния. Она вызвана, как правило, плохим анали-
зом ПрО, случайными ошибками проектиров-
щиков или некорректной эксплуатацией сис-
темы. Эта операция разрешена только некото-
рому числу уполномоченных пользователей.
Поэтому такое редактирование данных, моде-
лирующих, например, структуру ПрО (так на-
зываемых «справочников»), в каркасной схеме
БД должно быть сведено лишь к каскадной де-
актуализации кортежей.
Рассмотрим такой алгоритм на примере. Оче-
видно, что одной из групп данных, подвержен-
ных изменениям в ПрО, есть словесные наиме-
нования адресных категорий (улиц, переулков,
площадей и др.), периодически присваиваемые
и переименовываемые пользователями в соот-
ветствии со своими национальными традиция-
ми. В связи с этим в каркасном анализе ПрО на-
именования могут выступать как независимые
атомарные или слабые сущности–объекты. Рас-
смотрим процедуру модификаций и деактуа-
лизации этих данных в БД на примере модели-
рования составной сущности–объекта АДРЕСА
ПРОЖИВАНИЯ ФИЗЛИЦ. Фрагмент схемы БД
будет состоять из следующих отношений.
ТИПЫ АДРЕСНЫХ КАТЕГОРИЙ (КодТипа-
АдрКатег, Наименов, СокрНаимен, Код Акту-
альнТипаАдрКатег, ДатаАктуальнТипаАдрКа-
тег) – атомарная сущность–объект. Содержит
список наименований традиционных типов ад-
ресных категорий населенных пунктов городов,
поселков или сел без привязки к типу нацио-
нальной традиции и перечню государств: {буль-
вар, переулок, проспект, площадь, улица, …,
тупик, avenue, boulevard, …, square, street, …}.
Данный список может быть только попол-
няемым. Потребность в аннулировании любой
из этих категорий могла бы возникнуть лишь
при условии однозначного отказа от ее исполь-
зования во всех населенных пунктах всех на-
циональностей. Однако автору не известен слу-
чай полной отмены любой из категорий во всех
национальных традициях одновременно. Поэто-
му отношение, моделирующее эту атомарную
сущность–объект, вероятнее всего будет ста-
бильным длительное время эксплуатации при-
ложений.
СЛОВАРЬ НАИМЕНОВАНИЙ АДРЕСНЫХ
КАТЕГОРИЙ (КодТипаАдрКатег, КодНаимен-
АдрКатег, Наименов, СокрНаимен, Код Акт-
НаименАдрКатег, ДатаАктНаименАдрКатег) –
слабая сущность–объект. Содержит список соб-
ственных наименований традиционных объек-
тов адресных категорий, связанных с тради-
ционными типами, однако без привязки к кон-
кретным населенным пунктам: {…, Alexander, …,
Silver, …, Антонова, …, Перова, …, Туполева, …}.
Данный список также может быть только по-
полняемым. Потребность в аннулировании лю-
бой из этих записей могла бы возникнуть лишь
при условии однозначного отказа от использо-
вания данного наименования во всех населен-
ных пунктах всех национальностей. Отноше-
ние, моделирующее эту слабую сущность–объ-
ект, также будет стабильным.
АДРЕСНЫЕ КАТЕГОРИИ ГОРОДОВ ГО-
СУДАРСТВ (КодГосуд, КодОбл, КодРайона,
КодГорода, КодТипаАдрКатег, КодНаимен-
АдрКатег, КодАктАдресКатег, ДатаАктАдрКа-
тег, Примечан) – составная сущность–объект –
«справочник улиц в городах государств» с уче-
том истории изменений собственных наимено-
ваний.
Для понимания более полной схемы этого
фрагмента БД далее приведем иные отношения–
справочники, в которых представлены недос-
тающие данные. Рассмотрим, как работает ме-
ханизм корректного каскадного переименова-
ния, например, улицы, название которой уже
длительное время используется в адресах зна-
чительного числа объектов – зданий, сооруже-
ний, физических лиц и др.
В соответствии с предварительно настроен-
ным специализированным запросом приложе-
ние открывает группу отношений и их индек-
сов. Все необходимые связи между отношени-
ями по соответствующим одноименным частич-
ным ключевым полям также активизированы.
Под активизацией связи между отношениями
понимается строгое соответствие в буфере при-
ложения групп записей друг другу по значени-
ям ссылающихся ключей.
УСиМ, 2013, № 1 77
Уполномоченный пользователь (например,
системный администратор) посредством отдель-
ного пункта меню одного из приложений, ра-
ботающих с этой БД, из группы записей в от-
ношении АДРЕСНЫЕ КАТЕГОРИИ ГОРОДОВ
ГОСУДАРСТВ(), отфильтрованных именем вы-
бранного города в необходимом государстве,
посредством локального (дополнительного) по-
искового индекса выбирает ту запись, которая
посредством части ключа КодНаименАдрКатег
ссылается на необходимое прежнее наимено-
вание искомой адресной категории. Очевидно,
что поиск по наименованию может осуществ-
ляться в открытом отношении СЛОВАРЬ НАИ-
МЕНОВАНИЙ АДРЕСНЫХ КАТЕГОРИЙ() в
этом же пункте меню посредством обособлен-
ного окна поиска.
Визуально активизировав найденное новое
наименование, пользователь в текущей записи
отношения АДРЕСНЫЕ КАТЕГОРИИ ГОРО-
ДОВ ГОСУДАРСТВ() заменяет прежнее значе-
ние ключа КодНаименАдрКатег на новое. Ат-
рибут «наименование адресной категории» в
этом и следующих по иерархии отношениях от-
сутствует. Этот принцип исключает описанные
недостатки: избыточность данных, многознач-
ность форматов, разночтение терминов [9] и
др. Если же в отношении СЛОВАРЬ НАИМЕ-
НОВАНИЙ АДРЕСНЫХ КАТЕГОРИЙ() на мо-
мент такого поиска нового наименования еще
нет, то уполномоченный пользователь вносит
его посредством этого же окна поиска. Приложе-
ние посредством типовой процедуры предостав-
ляет новому наименованию соответствующее
новое значение ключа КодНаименАдрКатег.
По факту внесения такого изменения сраба-
тывает одна из каскадных процедур целостно-
го обновления взаимосвязанных данных во всех
отношениях, задекларированных в метаданных
приложения. Связь между этими отношениями
удерживается в активном состоянии по актив-
ным индексам одноименных ключей.
В схему каждого каркасного отношения вне-
сены, помимо прочих, еще и естественные шун-
тирующие атрибуты – даты и код актуальности
соответствующих связей. Под датой актуально-
сти понимается день (а если нужно, то и час–
минута этого дня) начала эксплуатации этой
связи, т.е. этой записи в конкретном отноше-
нии. А под кодом актуальности понимается би-
нарная пара {true; false} ({1; 0}). Очевидно, что
если значение этого атрибута – «ноль», запись
или группа записей текущей совокупности от-
ношений теряет актуальность.
Важной особенностью описанного редакти-
рования значения ключа КодНаименАдрКатег
в отношении АДРЕСНЫЕ КАТЕГОРИИ ГОРО-
ДОВ ГОСУДАРСТВ() (замены старого значе-
ния новым) есть то, что старое значение ключа
КодНаименАдрКатег фактически не редакти-
руется, а сама запись лишь деактуализируется.
То есть в данном пункте меню этого приложе-
ния запрос к отношению АДРЕСНЫЕ КАТЕ-
ГОРИИ ГОРОДОВ ГОСУДАРСТВ() настроен
так, что после выполнения редактирования в
этом отношении (а также во всех связанных с
ним отношениях по данной группе частичных
ключей) появляется новая запись, в которую
вносится новое значение ключа КодНаимен-
АдрКатег.
Атрибуты КодАктАдрКатег и ДатаАктАдр-
Катег этой новой записи получают соответ-
ствующие текущие значения, моделирующие ак-
туальность этой записи – символ актуальности
и текущую дату обновления. А в записи этого
же отношения со старым значением ключа
КодНаименАдрКатег (а также во всех группах
записей, во всех связанных с ним отношениях
по данной группе частичных ключей) в атри-
буте КодАктАдрКатег символ актуальности за-
меняется символом неактуальности. Атрибут
ДатаАктАдрКатег в этой «старой» записи не
изменяется.
Строгость отслеживания целостности дан-
ных требует хранения «дат деактуализации» в
отдельных отношениях–масках [10]. В фоно-
вом режиме в отдельных отношениях форми-
руются записи с соответствующими значения-
ми всех необходимых ключей и датой деактуа-
лизации. Такие дополнительные каркасные от-
ношения–маски имеют вид: ДЕАКТУАЛИЗИ-
РОВАННЫЕ НАИМЕНОВАНИЯ АДРЕСНЫХ
КАТЕГОРИЙ (КодТипаАдрКатег, КодНаимен-
АдрКатег, ДатаДеАктНаименАдрКатег), ДЕ-
78 УСиМ, 2013, № 1
АКТУАЛИЗИРОВАННЫЕ АДРЕСНЫЕ КАТЕ-
ГОРИИ ГОРОДОВ ГОСУДАРСТВ (КодГосуд,
КодОбл, КодРайона, КодГорода, КодТипаАдр-
Катег, КодНаименАдрКатег, ДатаДеАктАдр-
Катег), ДЕАКТУАЛИЗИРОВАННЫЕ АДРЕСА
ПРОЖИВАНИЯ ФИЗЛИЦ (ИдентНомерФизЛи-
ца, КодГосуд, КодОбл, КодРайона, КодГорода,
КодТипаАдрКатег, КодНаименАдрКатег, Ном-
Здания, Литера, СубНомЗдания, СубЛитера,
НомПомещен, Литера, ДатаДеАктАдреса).
Таким образом, в задекларированном в ме-
таданных приложения искомом «оперативном»
отношении АДРЕСА ПРОЖИВАНИЯ ФИЗ-
ЛИЦ(), ради корректного использования запи-
сей которого, по сути, и существуют все опи-
санные отношения–справочники, в фоновом
режиме все записи, ссылающихся на старое зна-
чение ключа КодНаименАдрКатег, будут де-
актуализированы. Также в фоновом режиме в
этом же отношении появятся новые записи с
новым значением ключа КодНаименАдрКатег.
Очевидно, что особенностью отношения АД-
РЕСА ПРОЖИВАНИЯ ФИЗЛИЦ() есть то, что
у каждого адресата может быть множество ад-
ресов проживания. И некоторая часть из них с
определенного момента может быть уже не ак-
туальной. Однако это не означает, что такие
записи должны быть удалены из отношения.
Принцип ХД подразумевает бессрочное хра-
нение всех исторических фактов в целостном
виде. Поэтому описанное редактирование мо-
делирует ситуацию, когда в ПрО искомые ад-
ресаты (например, физические лица) в массо-
вом порядке меняют адрес проживания. И в
отношении АДРЕСА ПРОЖИВАНИЯ ФИЗ-
ЛИЦ() обновление группы соответствующих
записей осуществляется автоматизированной
процедурой. В случае же моделирования си-
туации единичной смены адреса искомого ад-
ресата или появления у него дополнительного
адреса, соответствующие дополнительные за-
писи в это отношение вносятся вручную.
Таким образом, по факту выполнения подоб-
ного редактирования – замены в отношении
АДРЕСНЫЕ КАТЕГОРИИ ГОРОДОВ ГОСУ-
ДАРСТВ() старого значения атрибута КодНаи-
менАдрКатег на новое – процедуры каскадных
обновлений связанных с ним отношений, как и
АДРЕСА ПРОЖИВАНИЯ ФИЗЛИЦ(), могут вы-
полняться автоматически в режиме «квази-ре-
ального времени». Под термином «квази» по-
нимается задержка на выполнение всех необ-
ходимых операций обновления значительного
числа данных и генерации значительного чис-
ла записей. Однако эти процедуры построены
не на операциях соединения, а на менее ресур-
соемких индексных пробежках по группам от-
фильтрованных записей. В дальнейшем, как и
прежде, будем употреблять термин «реальное
время», понимая, что современные вычислитель-
ные системы позволяют пренебрегать временем
задержки на выполнение описанных процедур,
если такая задержка не является критичной и
это не оговорено.
Еще одной важной особенностью такого об-
новления отношения АДРЕСА ПРОЖИВАНИЯ
ФИЗЛИЦ() есть то, что появление записей с но-
выми значениями части ключа КодНаименАдр-
Катег не нарушит реляционной целостности
отношения. При этом никакого нового сурро-
гатного ключа типа ID_Address, который в не-
каркасных схемах БД традиционно отвечает за
такую целостность, не требуется. Это возмож-
но потому, что в каркасной совокупности от-
ношений все ключи автоматически обладают и
целостностью, и полнотой, и единственностью,
и семантичностью.
На описанном принципе может быть орга-
низовано целостное обновление любого ключа
или неключевого атрибута. Это означает, что у
пользователя каркасной БД имеется возмож-
ность моделировать одновременное обновление
всех задекларированных в метаданных групп
записей и значений их атрибутов в группах от-
ношений, связанных с редактируемой записью
в текущем отношении. Тогда для оперативной
обработки данных код актуальности играет роль
фильтра. А для операций аналитической обра-
ботки этот атрибут не есть определяющим.
Отметим, что иные каркасные отношения–
справочники от атомарных и слабых сущно-
стей–объектов фрагмента этой ПрО имеют
вид: ПЕРЕЧЕНЬ ГОСУДАРСТВ (КодГосуд,
Наименов, СокрНаимен, КодАктНаименГос,
УСиМ, 2013, № 1 79
ДатаАктНаименГос), СЛОВАРЬ НАИМЕНОВА-
НИЙ ОБЛАСТЕЙ (КодНаименОбл, Наименов,
СокрНаимен, КодАктНаименОбл, ДатаАктНа-
именОбл), СЛОВАРЬ НАИМЕНОВАНИЙ ГО-
РОДОВ (КодНаименГор, Наименов, СокрНаи-
мен, КодАктНаименГор, ДатаАктНаименГор),
СЛОВАРЬ НАИМЕНОВАНИЙ РАЙОНОВ (Код-
НаименРай, Наименов, СокрНаимен, КодАкт-
НаименРай, ДатаАктНаименРай), ОБЛАСТИ В
ГОСУДАРСТВАХ (КодГосуд, КодОбл, Код-
НаименОбл, КодАктОблГос, ДатаАктОблГос,
Примечан), РАЙОНЫ В ОБЛАСТЯХ В ГО-
СУДАРСТВЕ (КодГосуд, КодОбл, КодРай,
КодНаименРай, КодАктРайГос, ДатаАктРай-
Гос, Примечан), ГОРОДА В ГОСУДАРСТВАХ
(КодГосуд, КодОбл, КодРай, КодГорода, Код-
НаименГор, КодАктГроГос, ДатаАктГорГос,
Примечан).
Результаты экспериментальных исследо-
ваний
В работе над статьей проведен эксперимент,
основная характеристика которого – время до-
ступа к любому атрибуту отношения–маски ис-
следуемой БД. Как известно, самой ресурсо-
емкой операцией реляционной алгебры есть со-
единения отношений [17]. Эта операция приме-
няется при выполнении запросов к БД без ис-
пользования отношений–масок и более низкой
«нормальности» – не выше 3НФ. Особенность
каркасной схемы – большинство исследован-
ных связей моделируется в БД уже соединен-
ными отношениями. Поэтому отсутствие опе-
рации соединения приводит к значительной эко-
номии времени доступа к БД.
Для экспериментального исследования кар-
касного метода проектирования схемы БД и
проведения указанного численного эксперимен-
та выбрана ПрО «Городская поликлиника». Опи-
сываемое приложение БД разработано в г. Хмель-
ницком в одной из городских поликлиник с по-
мощью CASE-оболочки SWS [18] сторонними
пользователями этой инструментальной систе-
мы. Имеется соответствующий акт внедрения.
Как показано в [13, 19], само CASE-средство
SWS проектировалось в строгом соответствии с
каркасной моделью данных. При этом прило-
жения БД, синтезируемые с помощью SWS и
каркасной схемы БД, обладают высокой эффек-
тивностью.
Предметная область «Городская поли-
клиника»
На основании алгоритмов нормализации [8]
и каркасного синтеза схемы БД [4] были ис-
следованы:
семантика ПрО;
каркасная схема БД;
характеристики доступа к большим объе-
мам данных.
Рассмотрим фрагмент ПрО. Для этого при-
ведем список всех сущностей–объектов с ука-
занием их классификации и схемы. Курсивом
выделяются ключевые атрибуты. Подчеркива-
нием выделены вторичные ключи. Для примера
в некоторых отношениях приведены ключи–
ссылки на метаданные (выделены иным шриф-
том). Ценность столь подробного разделения
групп отношений на маски [10] особенно про-
является при поддержке приложения режима
реального времени [13, 19], когда превалиру-
ющее большинство запросов пользователей про-
ектируется заранее. Тогда на моменте ввода
любого данного в отношения, моделирующие
оперативное состояние ПрО, запускаются фо-
новые процедуры синтеза всех необходимых
«архивных» масок, в которых в режиме реаль-
ного времени обновляются соответствующие
кортежи, связанные по индексам соответству-
ющих ключей.
При такой конфигурации приложения потреб-
ность в написании большого объема листингов-
запросов, так или иначе зависящих от семантики
данных, значительно снижается. С целью эконо-
мии места в большинстве схем отношений атри-
буты, отвечающие за актуальность записей, не
приведены.
Реестры физических лиц по городам госу-
дарств (территориально-распределенная сис-
тема справочников)
ГОСУДАРСТВА (КодГосуд, Наименов, Сокр-
Наимен, …) – слабая сущность–объект;
СЛОВАРЬ НАИМЕНОВАНИЙ ОБЛАСТЕЙ
(КодНаименОбл, Наименов, СокрНаимен, …) –
атомарная сущность–объект;
80 УСиМ, 2013, № 1
СЛОВАРЬ НАИМЕНОВАНИЙ ГОРОДОВ
(КодНаименГор, Наименов, СокрНаимен, …) –
атомарная сущность–объект;
СЛОВАРЬ НАИМЕНОВАНИЙ РАЙОНОВ
(КодНаименРай, Наименов, СокрНаимен, …) –
атомарная сущность–объект;
ОБЛАСТИ В ГОСУДАРСТВАХ (КодГосуд,
КодОбл, КодНаименОбл, Примечан, …) – сла-
бая сущность–объект;
РАЙОНЫ В ОБЛАСТЯХ В ГОСУДАРСТВЕ
(КодГосуд, КодОбл, КодРайона, КодНаимен-
Рай, Примечан) – слабая сущность–объект;
ГОРОДА В ГОСУДАРСТВАХ (КодГосуд,
КодОбл, КодРайона, КодГорода, КодНаимен-
Гор, Примечан) – слабая сущность–объект;
МИКРОРАЙОНЫ ГОРОДОВ (КодГосуд, Код-
Обл, КодРайона, КодГорода, КодМикроР, Код-
НаименМикроР, Примечан) – слабая сущ-
ность–объект;
ТИПЫ АДРЕСНЫХ КАТЕГОРИЙ (КодТипа-
АдрКатег, Наименов) – атомарная сущность–
объект;
СЛОВАРЬ НАИМЕНОВАНИЙ АДРЕСНЫХ
КАТЕГОРИЙ (КодНаименАдрКатег, КодТипа-
АдрКатег, Наименов) – слабая сущность–объект;
АДРЕСНЫЕ КАТЕГОРИИ ГОРОДОВ (Код-
Госуд, КодОбл, КодРайона, КодГорода, КодТи-
паАдрКатег, КодАктуальнНаимен, КодНаимен-
АдрКатег, Примечан) – составная сущность–
объект – «справочник улиц городов» с учетом
истории изменений собственных наименований;
СЛОВАРЬ ФАМИЛИЙ (КодФам, Фамилия) –
атомарная сущность–объект;
СЛОВАРЬ ИМЕН (КодИмени, Имя) – ато-
марная сущность–объект;
СЛОВАРЬ ОТЧЕСТВ (КодОтч, Отчество) –
атомарная сущность–объект;
ФИЗИЧЕСКИЕ ЛИЦА (ИдентНомерФизЛи-
ца, КодГос, КодФам, КодИмени, КодОтч, Да-
таРожден, КодГородаРожден, Пол, …, При-
мечан) – атомарная сущность–объект – спра-
вочник «люди в государстве»;
АДРЕСА ПРОЖИВАНИЯ ФИЗЛИЦ (Идент-
НомерФизЛица, КодГос, КодОбл, КодРай, Код-
Города, КодТипаАдрКатег, КодНаименАдр-
Катег, НомЗдания, Литера, СубНомЗдания,
СубЛитера, НомПомещен, Литера) – слабая
сущность–объект;
ПЕРСОНАЛЬНЫЕ ТЕЛЕФОНЫ ФИЗЛИЦ
(ИдентНомерФизЛица, КодГос, НомТелефона,
КодТипаТелеф, Примечан) – слабая сущность–
объект;
ПЕРСОНАЛЬНЫЕ ЭЛЕКТРОННЫЕ АДРЕСА
ФИЗЛИЦ (ИдентНомерФизЛица, КодГос, Но-
мерЭлектрАдр, ИмяЭлектрПочты) – слабая
сущность–объект;
ПЕРСОНАЛЬНЫЕ БЛОГИ ФИЗЛИЦ (Идент-
НомерФизЛица, КодГос, НомерБлога, Имя бло-
га) – слабая сущность–объект;
КРАТКИЙ СПРАВОЧНИК ПРОФЕССИЙ
(КодПроф, Наименов) – атомарная сущность–
объект;
СПРАВОЧНИК СПЕЦИАЛЬНОСТЕЙ (Код-
Проф, КодСпец, Наименов) – слабая сущность–
объект;
СПРАВОЧНИК СПЕЦИАЛИЗАЦИЙ В СПЕ-
ЦИАЛЬНОСТЯХ (КодПроф, КодСпец, КодСпе-
циализ, Наименов) – слабая сущность–объект;
СПОСОБЫ ПРИОБРЕТЕНИЯ СПЕЦИАЛЬ-
НОСТИ (КодТипаПриобретения, Наименов) –
атомарная сущность–объект;
СПЕЦИАЛЬНОСТИ ФИЗЛИЦ (ИдентНомер-
ФизЛица, КодПроф, КодСпец, КодТипаПриоб-
ретения, Примечан) – слабая сущность–объект;
ОФИЦИАЛЬНЫЕ СПЕЦИАЛЬНОСТИ ФИЗ-
ЛИЦ (ИдентНомерФизЛица, КодПроф, Код-
Спец, НомДокумента, КодГородаВыдачи, Да-
таВыдачи) – слабая сущность–объект;
ПРОФЕССИИ ФИЗЛИЦ (ИдентНомерФиз-
Лица, КодПроф, Примечан) – слабая сущность–
объект;
СПЕЦИАЛИЗАЦИИ ФИЗЛИЦ (ИдентНомер-
ФизЛица, КодПроф, КодСпец, КодСпециализ,
Примечан) – слабая сущность–объект;
ТИПЫ СОБСТВЕННОСТИ (КодТипаСобств,
Наименов) – атомарная сущность–объект;
ОРГАНИЗАЦИОННО-ПРАВОВЫЕ ФОРМЫ
(КодТипаСобств, КодОргПравФормы, Наиме-
нов) – слабая сущность–объект;
НАИМЕНОВАНИЕ ДОЛЖНОСТЕЙ (КодДол-
жн, Наименов) – атомарная сущность–объект;
УСиМ, 2013, № 1 81
ОТРАСЛИ (КодОтр, КодПодотр, Наиме-
нов) – слабая сущность–объект;
РЕКОМЕНДОВАННЫЕ ДОЛЖНОСТИ В
ОТРАСЛЯХ (КодОтр, КодПодотр, КодОрг-
ПравФормы, КодДолжн, Примечан) – слабая
сущность–объект;
ОРГАНИЗАЦИИ ГОРОДА (КодГос, КодОтр,
КодПодотр, КодПредпр, КодТипаСобств, Ко-
дОргПравФормы, Наименов) – слабая сущ-
ность–объект;
РАБОЧИЕ МЕСТА ФИЗЛИЦА (КодГос,
ИдентНомерФизЛица, КодПредпр, НомГода-
Зачисл, НомМесЗачисл, ДеньЗачисл, КодОтр,
КодПодотр, КодДолжн, Примечан) – состав-
ная сущность–объект.
Штатный реестр в городской поликли-
нике в одном из городов
УЧАСТКИ В ГОРОДЕ (КодУчастка, Код-
Гос, КодОбл, КодРайона, КодГорода, Наиме-
нов) – слабая сущность–объект;
ЗДАНИЯ И ПОМЕЩЕНИЯ НА УЧАСТКАХ
В ГОРОДЕ (КодУчастка, КодГосуд, КодОбл,
КодРайона, КодГорода, КодТипаАдрКатег,
КодНаименАдрКатег, НомЗдания, НомПоме-
щения) – слабая сущность–объект;
СОТРУДНИК ПОЛИКЛИНИКИ (ТабНом-
СотрПоликл, КодТипаЗанятости, Примечан,
ИдентНомерФизЛица, КодГос) – маска на от-
ношение ФИЗИЧЕСКОЕ ЛИЦО – фильтр по
принадлежности к данной поликлинике (в шта-
те, по совместительству или по договору), где
ИдентНомерФизЛица, КодГос – вторичные
ключи, фильтрующие отношения, далее анало-
гичный прием;
СПИСОК ТИПОВ ЗАНЯТОСТИ (КодТипа-
Занятости, Наименов) – атомарная сущность–
объект;
СПИСОК ДОЛЖНОСТЕЙ В ПОЛИКЛИНИ-
КЕ (КодДолжнПоликл, Наименов) – маска на
отношение ОБЩЕГОСУДАРСТВЕННЫЙ РЕ-
ЕСТР ДОЛЖНОСТЕЙ – как атомарная сущ-
ность–объект;
ШТАТНОЕ РАСПИСАНИЕ ПОЛИКЛИНИ-
КИ (КодДолжнПоликл, НомГода, Вакантность,
НомМес, Примечан) – составная сущность–
объект – текущее состояние списка должно-
стей в поликлинике;
ДОЛЖНОСТЬ СОТРУДНИКА ПОЛИКЛИ-
НИКИ (ТабНомСотрПоликл, КодДолжнПоликл,
НомГодаЗачисл, НомМесЗачисл, НомДняЗачисл,
Примечан) – составная сущность–объект – те-
кущее состояние должностей сотрудников в
поликлинике;
ВРАЧ (КодВрача, Примечан, ТабНомСотр-
Поликл) – маска на отношение–связь СОТРУД-
НИК ПОЛИКЛИНИКИ (суб-маска на отноше-
ние ФИЗИЧЕСКИЕ ЛИЦА) – фильтр по при-
знаку «врач»;
СПИСОК КАБИНЕТОВ ПРИЕМА ВРАЧЕЙ
В ПОЛИКЛИНИКЕ (КодВрача, НомКорпуса,
НомКабин, Примечан) – слабая сущность–
объект;
УЧАСТКОВЫЙ ВРАЧ (КодВрача, Приме-
чан, ТабНомСотрПоликл) – маска на отноше-
ние СОТРУДНИК ПОЛИКЛИНИКИ (суб-
маска на маску ВРАЧ) – фильтр по признаку
«тип работы»;
ПРИНИМАЮЩИЙ ВРАЧ (КодВрача, При-
мечан, ТабНомСотрПоликл) – маска на отно-
шение СОТРУДНИК ПОЛИКЛИНИКИ (суб-
маска на маску ВРАЧ) – фильтр по признаку
«тип работы»;
ЛЕЧАЩИЙ ВРАЧ (КодВрача, Примечан,
ТабНомСотрПоликл) – маска на отношение
СОТРУДНИК ПОЛИКЛИНИКИ (суб-маска на
маску ВРАЧ) – фильтр по признаку «тип ра-
боты»;
ТИПЫ РАБОТЫ ВРАЧЕЙ (КодТипаРаботы,
Наименов, …) – атомарная сущность–объект
(возможно со ссылкой на метаданные);
СПЕЦИАЛИЗАЦИЯ ВРАЧА (КодСпециал-
Врача, Наименов) – атомарная сущность–объ-
ект (возможно со ссылкой на метаданные);
СПЕЦИАЛИЗАЦИИ ВРАЧЕЙ В ПОЛИКЛИ-
НИКЕ (КодВрача, КодСпециалВрача, Приме-
чан, КодТаблВрачей) – составная сущность–
объект, где КодТаблВрачей – ссылка на мета-
данные;
СПРАВОЧНИК ДИАГНОЗОВ (КодСпеци-
алВрача, КодДиагноза, Наименов) – слабая
сущность–объект;
СПРАВОЧНИК ИССЛЕДОВАНИЙ (Код-
СпециалВрача, КодИсследов, Наименов) – сла-
бая сущность–объект;
82 УСиМ, 2013, № 1
СПРАВОЧНИК ИССЛЕДОВАНИЙ ПО ДИ-
АГНОЗАМ (КодСпециалВрача, КодДиагноза,
КодИсследов, Наименов) – слабая сущность–
объект;
ПРЕЙСКУРАНТ УСЛУГ (КодТипаВизита,
КодВрача, КодСпециалВрача, КодУслуги, Ном-
Года, НомМес, Наименов, Цена, …) – слабая
сущность–объект;
Прием в городской поликлинике в одном
из городов
ПАЦИЕНТ (КодПациента, Примечан, Идент-
НомерФизЛица, КодГос) – маска на отношение
ФИЗИЧЕСКОЕ ЛИЦО – фильтр по потребно-
сти «посещать поликлинику»;
ЗАПИСЬ К СПЕЦИАЛИСТУ (КодПациен-
та, КодТипаВизита, КодВрача, КодСпециал-
Врача, КодУслуги, НомГода, НомМес, НомДня,
НомКорпуса, НомКабин, НомОчереди, Время,
Примечан, СуммаКОплате, ...) – составная сущ-
ность–объект, связь маски и сущности–объекта –
запись или к врачу на прием или на исследова-
ние, или к медперсоналу на процедуры или
манипуляции и т.д.;
ЗАКАЗ СПЕЦИАЛИСТА НА ДОМ (КодУча-
стка, КодПациента, КодВрача, КодСпециал-
Врача, КодУслуги, НомГода, НомМес, НомД-
ня, НомОчереди, Время, Примечан, СуммаК-
Оплате, …) – составная сущность–объект,
связь маски и сущности–объекта – заказ на
дом или врача, или лаборанта, или медсестры
для процедуры или манипуляции и т.д.;
ВИЗИТ К ВРАЧУ СТОМАТОЛОГУ (КодПа-
циента, КодТипаВизита, КодВрача, НомГода,
НомМес, НомДня, НомОчереди, КодПредвДи-
агноза, Время, Примечан, СуммаКОплате, …) –
составная сущность–объект;
НАЗНАЧЕНИЯ ИССЛЕДОВАНИЙ СТОМА-
ТОЛОГОМ (КодПациента, КодВрача, НомГо-
да, НомМес, НомДня, КодПредвДиагноза, Код-
Исследов, Примечан, СуммаКОплате, …) – со-
ставная сущность–объект;
РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЙ ДЛЯ СТО-
МАТОЛОГА (КодПациента, КодВрача, Ном-
Года, НомМес, НомДня, КодПредвДиагноза, Код-
Исследов, НомЗуба, КодОкончДиагноза, При-
мечан) – составная сущность–объект;
НАЗНАЧЕНИЯ КУРСА ЛЕЧЕНИЯ СТОМА-
ТОЛОГОМ (КодПациента, КодВрача, НомГо-
да, НомМес, НомДня, КодОкончДиагноза, Код-
Процедуры, Примечан, СуммаКОплате, …) –
составная сущность–объект;
РЕЦЕПТ СТОМАТОЛОГА (КодПациента,
КодВрача, НомГода, НомМес, НомДня, КодО-
кончДиагноза, КодЛекарства, Примечан) –
составная сущность–объект;
ЗАПИСИ В ЛИЧНОЕ ДЕЛО ПАЦИЕНТА
(КодУчастка, КодПациента, КодВрача, Код-
СпециалВрача, НомГода, НомМес, НомДня, Код-
ОкончДиагноза, КодРезульт, Примечан) – со-
ставная сущность–объект.
Маски как составные сущности–обекты
(для хранения статистических данных, сфор-
мированных фоновыми процедурами по факту
ввода данных в оперативные отношения в ре-
жиме реального времени – аналог отношений–
фактов в схеме ХД снежинка).
РАБОТА ВРАЧЕЙ ЗА ДЕНЬ (КодТипаРабо-
ты, КодВрача, НомГода, НомМес, НомДня,
СуммЧислоЧасов, …);
РАБОТА ВРАЧЕЙ ЗА МЕСЯЦ (КодТипаРа-
боты, КодВрача, НомГода, НомМес, Сумм-
ЧислоЧасов, …);
РАБОТА ВРАЧЕЙ ЗА ГОД (КодТипаРаботы,
КодВрача, НомГода, СуммЧислоЧасов, …);
РАБОТА ЛЕЧАЩИХ ВРАЧЕЙ ЗА ДЕНЬ (Код-
Врача, НомГода, НомМес, НомДня, СуммЧис-
лоЧасов, …);
РАБОТА ЛЕЧАЩИХ ВРАЧЕЙ ЗА МЕСЯЦ
(КодВрача, НомГода, НомМес, СуммЧислоЧа-
сов, …);
РАБОТА УЧАСТКОВЫХ ВРАЧЕЙ ЗА ДЕНЬ
(КодВрача, НомГода, НомМес, НомДня, Сумм-
ЧислоЧасов, …);
РАБОТА УЧАСТКОВЫХ ВРАЧЕЙ ЗА МЕ-
СЯЦ (КодВрача, НомГода, НомМес, СуммЧис-
лоЧасов, …);
ПРИЕМЫ ВРАЧЕЙ ЗА ДЕНЬ (КодВрача,
НомГода, НомМес, НомДня, СуммЧислоЧа-
сов, …);
ПРИЕМЫ ВРАЧЕЙ ЗА МЕСЯЦ (КодВрача,
НомГода, НомМес, СуммЧислоЧасов, ОбщЧис-
лоПац, …);
УСиМ, 2013, № 1 83
ПОЛИКЛИНИКА ЗА МЕСЯЦ (НомГода, Ном-
Мес, СуммЧислоЧасов, ОбщЧислоПац, Общ-
СуммаРеализации, …);
РЕГИСТРАТУРА ЗА МЕСЯЦ (НомГода,
НомМес, ОбщЧислоПац, …);
РЕНТГЕНОГРАФИЯ ЗА МЕСЯЦ (НомГода,
НомМес, КодРентгеногр, ЧислоПац, ОбщСум-
маРеализации, …);
ФЛЮРОГРАФИЯ ЗА МЕСЯЦ (НомГода,
НомМес, КодФлюрогр, ЧислоПац, ОбщСумма-
Реализации, …);
УЗИ ЗА МЕСЯЦ (НомГода, НомМес, Код
УЗИ, ЧислоПац, ОбщСуммаРеализации, …);
МАНИПУЛЯЦИОННАЯ ЗА МЕСЯЦ (Ном-
Года, НомМес, КодМанипул, ЧислоПац, Общ-
СуммаРеализации, …);
ДОВРАЧЕБНЫЙ КАБИНЕТ ЗА МЕСЯЦ
(НомГода, НомМес, КодДоврОбслед, Число-
Пац, ОбщСуммаРеализации, …);
ТЕРАПИЯ ЗА МЕСЯЦ (НомГода, НомМес,
ЧислоПац, ОбщСуммаРеализации, …);
Отношения, моделирующие итоговые дан-
ные за месяц по всем иным специализациям
(СТОМАТОЛОГИЯ, ГАСТРОЭНТЕРОЛОГИЯ,
ПЕДИАТРИЯ, КАРДИОЛОГИЯ, УРОЛОГИЯ,
ЭНДОКРИНОЛОГИЯ, ПУЛЬМАНОЛОГИЯ,
ОФТАЛЬМОЛОГИЯ, ОТОЛАРИНГОЛОГИЯ,
ГЕНИКОЛОГИЯ, ОРТОПЕДИЯ и др.), будут
аналогично сформированы по схеме: СПЕЦИ-
АЛИЗАЦИЯ ЗА МЕСЯЦ (НомГода, НомМес,
КодСпециализирУслуги, ЧислоПац, ОбщСумма-
Реализации, …).
Оперативные и аналитические отчеты
за день, месяц, год и более – номерки очереди,
счета к оплате, рецепты, направления на иссле-
дования, направления на процедуры, список раз-
носки личных дел пациентов по кабинетам вра-
чей, поврачебные списки адресов пациентов для
посещения на дому, наряд на обход, накладная
на получение лекарств на складе, накладная на
получение материалов на складе, статистические
отчеты по отделениям о посещении, отчеты по
расходам материалов и лекарств, отчет об уров-
не заболеваемости, отчет о прогнозах сезонной
заболеваемости, отчет о прогнозах сезонных эпи-
демий и др.
В приведенной схеме БД синтезировано 125
каркасных отношений. Скорость доступа к дан-
ным по типовым запросам повысилась на не-
сколько порядков в сравнении со схемой, раз-
работанной в соответствии с алгоритмом нор-
мализации Кодда [8].
а б
в г
Рис. 2. Изменение времени доступа к данным при: а – четырех
отношениях; б – восьми отношениях; в – 12 отношениях;
г – 16 отношениях
На рис. 2,а показаны графики, иллюстриру-
ющие увеличение времени (млсек) доступа к
данным при получении одной записи из увели-
чивающихся пачек записей при запросе на со-
единение четырех 3НФ-отношений (кривая 2).
И заметно меньше времени на индексную вы-
борку этой же записи из одного квартарного
каркасного отношения (кривая 1) при таком же
увеличении числа записей. Кривые совпали с
результатами работы [7]. Это подтверждает
подобие схем БД разных ПрО еще и при ис-
следовании скорости доступа к данным.
Рис. 2,б иллюстрирует еще меньший рост
времени доступа к декарному каркасному от-
ношению (кривая 1) с увеличением числа об-
рабатываемых записей. И значительный рост
времени выполнения этого же запроса при со-
единении 8-ми отношений в 3НФ (кривая 2).
Рис. 2,в и 2,г иллюстрируют значительные от-
личия в росте времени при 12-ти и 16-ти арных
отношениях. Для более выразительной иллю-
страции ось абсцисс рис. 2,г несколько сме-
щена в отрицательном направлении. Номера
кривых имеют тот же смысл. При этом все ре-
84 УСиМ, 2013, № 1
зультирующие отношения аналогично [7] фор-
мировались в среднем до 150–200 кортежей.
Заметим, что вид каркасной диаграммы опи-
санной ПрО полностью соответствует аналогич-
ной диаграмме из работы [7]. Поэтому с целью
экономии места диаграмму не приводим. Для
формирования унифицированного запроса к
БД, возвращающего группу данных для анали-
за документов (артефактов), таких как, напри-
мер, «Отчет о работе регистратуры» или «Счет
к оплате больному», применяется единствен-
ная операция выборка из отношения. Причем,
все соединения, присутствующие в отношени-
ях, моделирующих связи сущностей–объектов,
сформированы не по факту выполнения запро-
са пользователя к БД, а по факту внесения те-
кущих оперативных данных [18, 19].
Заключение. Таким образом, каркасная мо-
дель данных позволила обнаружить совпадение
описанного подхода с классическим результа-
том модели ХД снежинка [2]. Однако все пе-
речисленное дает возможность более общего
построения схемы БД, обладающей как OLTP-
свойствами, так и возможностями ХД. Унифи-
кация и типизация каркасной схемы БД позво-
ляет также минимизировать потребность в ре-
сурсоемких операциях соединения в большин-
стве запросов к БД, чем существенно упрощает
настройку приложения. Приводятся результа-
ты численного эксперимента доступа к БД.
1. Inmon W.H. Building the Data Warehouse. – New York:
John Willey & Sons, 2002. – 412 p.
2. Kimball R. The Data Warehouse Toolkit: Practical Tech-
niques for Building Dimensional Data Warehouses /
Ibid., 1996. – 491 p.
3. Стулов А.С. Особенности построения информаци-
онных хранилищ. – М.: Открытые системы, 2003. –
№ 4. – С. 82–89. – http://www.osp.ru/os/2003/ 04/182942/
4. Панченко Б.Е. Каркасное проектирование доменно-
ключевой схемы реляционной базы данных // Ки-
бернетика и системный анализ. – 2012. – № 3. –
C. 174–187.
5. Панченко Б.Е. Об алгоритме синтеза реляционного
каркаса. Постановка задачи и формализация // Ком-
пьютерная математика. – 2012. – № 1. – С. 84–93.
6. Орешков В.И., Паклин Н.Б. Бизнес-аналитика: от
данных к знаниям. – СПб.: Питер, 2009. – 624 с.
7. Панченко Б.Е. К вопросу о модифицируемости и
безаномальности схемы реляционной базы данных
// Проблемы программирования. – 2012. – № 1. –
С. 281–288.
8. Codd E.F. The Relational Model For Database Man-
agement, V. 2, Reading Mass. – New York: Addison-
Wesley Publ. Co, 1990. – 538 p.
9. Кузнецов С.Д., Артемьев В.А. Обзор возможностей
применения ведущих СУБД для построения храни-
лищ данных (DataWarehouse). – // http://citforum.ck.ua/
database/kbd98/glava15.shtml
10. Панченко Б.Е. Рекурсивне связи и темпоральность
в реляционном каркасе – маски сущностей–объек-
тов // Проблемы управления и информатики. – 2013. –
№ 2. – C. 92–104.
11. Хоббс Л., Хилсон С., Лоуренд Ш. Разработка и экс-
плуатация хранилищ данных (Oracle 9iR2). – М.:
Кудиц-образ, 2004. – 586 с.
12. Роджерс Х. Теория рекурсивных функций и эффек-
тивная вычислимость. – М.: Мир, 1972. – 624 с.
13. Панченко Б.Е., Гайдабрус В.Н., Церковицкий С.Л.
Сетевые вычислительные комплексы // Компьютеры
плюс программы. – 1994. – спец. вып. – С. 30–37.
14. Харрингтон Д.Л. Проектирование реляционных баз
данных. – М.: Лори, 2006. – 231 с.
15. Хернандес М.Д., Вьескас Д.Л. SQL-запросы для прос-
тых смертных. Там же. – 2003. – 460 с.
16. Рейнгольд Э., Нивергельт Ю., Део Н. Комбинатор-
ные алгоритмы. Теория и практика. – М.: Мир,
1980. – 476 с.
17. Ульман Д., Уидом Д. Основы реляционных баз дан-
ных. – М.: Лори, 2006. – 374 с.
18. Панченко Б.Е., Гайдабрус В.Н., Церковицкий С.Л.
CASE-генератор прикладных сетевых информаци-
онных комплексов – инструментальная система
SWS 1.0 // Свидетельство об официальной регистра-
ции программы для ЭВМ № 940165. – М.: РосААП,
1994. – 2 с.
19. Панченко Б.Е. Исследования доменно-ключевой
схемы реляционной базы данных // Кибернетика и
системный анализ. – 2012. – № 6. – С. 157–172.
Поступила 12.11.2012
Тел. для справок: +38 044 526-3603, 285-3346,
+38 067 449-3970 (Киeв)
E-mail: pr-bob@ukr.net
© Б.Е. Панченко, 2013
|
| id | nasplib_isofts_kiev_ua-123456789-83133 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 0130-5395 |
| language | Russian |
| last_indexed | 2025-12-07T16:33:09Z |
| publishDate | 2013 |
| publisher | Міжнародний науково-навчальний центр інформаційних технологій і систем НАН та МОН України |
| record_format | dspace |
| spelling | Панченко, Б.Е. 2015-06-15T14:58:58Z 2015-06-15T14:58:58Z 2013 Хранилища данных на реляционном каркасе / Б.Е. Панченко // Управляющие системы и машины. — 2013. — № 1. — С. 71-84. — Бібліогр.: 19 назв. — рос. 0130-5395 https://nasplib.isofts.kiev.ua/handle/123456789/83133 004.652 Предложен новый поход к моделированию темпоральных баз данных. Показано, что классическая реляционная схема хранилища данных «снежинка» – частный случай реляционного каркаса. Введено понятие корректной модификации данных и метаданных. A new approach to designing temporal data is suggested. It is shown that the classic relation scheme of a data warehouse «snowflake» is a special case of a relational framework. A new definition of correct modification of data and metadata is introduced. Запропоновано новий підхід до моделювання темпоральних баз даних. Показано, що класична реляційна схема сховища даних «сніжинка» є окремим випадком реляційного каркасу. Введено поняття коректної модифікації даних та метаданих. ru Міжнародний науково-навчальний центр інформаційних технологій і систем НАН та МОН України Управляющие системы и машины Информационные и коммуникационные среды Хранилища данных на реляционном каркасе Data Warehouses in the Relational Framework Сховища даних на реляційному каркасі Article published earlier |
| spellingShingle | Хранилища данных на реляционном каркасе Панченко, Б.Е. Информационные и коммуникационные среды |
| title | Хранилища данных на реляционном каркасе |
| title_alt | Data Warehouses in the Relational Framework Сховища даних на реляційному каркасі |
| title_full | Хранилища данных на реляционном каркасе |
| title_fullStr | Хранилища данных на реляционном каркасе |
| title_full_unstemmed | Хранилища данных на реляционном каркасе |
| title_short | Хранилища данных на реляционном каркасе |
| title_sort | хранилища данных на реляционном каркасе |
| topic | Информационные и коммуникационные среды |
| topic_facet | Информационные и коммуникационные среды |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/83133 |
| work_keys_str_mv | AT pančenkobe hraniliŝadannyhnarelâcionnomkarkase AT pančenkobe datawarehousesintherelationalframework AT pančenkobe shoviŝadanihnarelâcíinomukarkasí |