Современная технология баз данных, основанная на применении реляционной модели Кодда, оказывает существенное влияние на характеристики систем обработки данных с помощью ЭВМ. Хотя системы управления базами данных (СУБД) - не носители спецификаций (алгоритмов) в системе управления, но они представляют собой универсальные средства для решения прикладных задач. Базы данных становятся определяющим фактором повышения производительности процесса обработки данных. В связи с этим анализ разработок, имеющихся на американском рынке баз данных[1],[2], интересен и для оценки положения с СУБД в ГДР.

 Положение с СУБД в стране складывается следующим образом. До 1992 г. ожидается значительный рост капиталовложений в развитие СУБД (ежегодно в среднем на 21%). Вклад в разработку систем для мини- и микроЭВМ будет еще больше. Для микроЭВМ среднегодовой темп капиталовложений составит 27.9%, для мини- ЭВМ - 30.1 %. Общий объем затрат на разработку СУБД по типам используемого программного обеспечения баз данных распределяется следующим образом: программное o6ecпечение реляционных баз данных - 50%; программное обеспечение иерархических баз данных - 35%; программное обеспечение распределенных баз данных - 15%.

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

Анализ большого количества отечественных и зарубежных источников позволил Хеллерингу утверждать в [4], что основные трудности в применении баз данных возникают из-за недостаточного изучения самого процесса проектирования СУБД и недостатка средств автоматизации проектирования.

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

Таблица 1

Хочется надеяться, что благодаря этим средствам разрыв между расширением использования СУБД и их недостаточным качеством из-за плохого проектирования баз данных будет быстро преодолен. Современные средства проектирования СУБД (особенно для ПЭВМ) для специалистов ГДР оказались недоступными. Потребность в быстром распространении баз данных для микроЭВМ и увеличении объемов работ в этом направлении потребовали создания прагматически ориентированной системы проектирования баз данных. Основой для среды проектирования такой системы и целевой СУБД послужила система REDABAS-3, совместимая с dBASEIII. Такой системой и стала dbDESIGN, основные характеристики и особенности которой рассмотрены ниже.

Концептуальное моделирование и нормализация

С момента опубликования в 1975 г. доклада ANSI/X3/SPARC о трехуровневой архитектуре СУБД не отрицается существование концептуального уровня для независимого описания данных и технических средств на логическом уровне. Особое внимание разработке этого уровня было уделено в работе NIJSSEN [11], в которой проанализировано пять различных подходов, позволяющих реализовать описание данных на логическом уровне. Для этой цели NIJSSEN предлагает использовать модель ENALIM, бинарную модель, нормализованный реляционный подход, подход к проектированию баз данных, рекомендуемый CODASYL, подход ANSI к проектированию СУБД.

Первые три рассматривались как самые перспективные.

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

 Таблица 2

Для dbDESIGN выбран график, соответствующий рекомендациям EROS [8] по крайней мере относительно совпадения этапов концептуального проектирования и нормализации.

Нормализация, вне зависимости от того, на каком этапе проектирования базы данных она осуществляется, свидетельствует о фундаментальности этого метода для структурирования данных. Невозможно, однако, точно указать, каков характер проявления нормализованных отношений в последовательных этапах проектирования. Даже если не рассматривать расширения классической реляционной модели Кодда (например, при подробном рассмотрении межреляционных отношений -сравните REBSAМEN [5], - или предположении отношений "не-первая" - нормальная форма - сравните BENECKE [12]), варианты такой модели различаются по двум показателям.

Во-первых, по уровню нормализации. Нормализация dbDESIGN распространяется до третьей нормальной формы (по Кодду). Для последующих работ по проектированию нормальные формы Кодда будут выигрывать в точности по сравнению с более ограниченными формами KENT. Согласно ZEHNDER ([13]) и VETTER ([14]), не требуется изучения нормальных форм высшего уровня, т.к. процент их практического применения невелик.

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

Методологические материалы в dbDESIGN

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

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

Функциональные зависимости

Понятие функциональной зависимости - одно из основных в теории нормализации. SCHMIDT определяет ее так: "В отношении rel атрибут aj (или совокупность атрибутов) функционально зависим от атрибута ai (или совокупности атрибутов), если предикат all r, s в rel ((r.ai = s.ai)=>(r.aj = s.aj)) всегда является истинным" [3], т.е. в rel не существует двух кортежей, у которых при совпадении значений ai не совпадали бы значения aj.

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

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

формирование ai. В соответствии с определением, ai может состоять из одного или, как следствие удаления иерархических структур, из нескольких атрибутов. Следует реализовать обе возможности.

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

Исключение любой зависимости атрибутов aj от двух атрибутов ai.

Нормализация по принципу декомпозиции

Анализируя доступные публикации ([5],[6]), молено выделить два основных принципа алгоритмического решения задачи нормализации:

принцип синтеза (восходящая стратегия);

принцип декомпозиции (нисходящая стратегия).

В dbDESIGN преобладает принцип декомпозиции, так как категоризация управляется стратегией принятия решения. Категоризация не исключает определения функциональной зависимости на уровне элементарных отношений, которые связываются друг с другом на основе принципов синтеза. Делаются попытки уменьшить определенные недостатки метода синтеза путем моделирования по принципу декомпозиции: "До тех пор, пока не найдены нее элементарные функциональные отношения, характерные для данной предметной области, вряд ли можно установить рабочие затраты на решение конкретных проблем" (SCHEER [15]).

 

Способу принятия решения, используемому в dbDESIGN, присущи следующие

черты:

1.      dbDESIGN представляет собой систему проектирования баз данных, ориентированную на практическое применение.

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

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

Если предметная область состоит из n атрибутов, эта процедура при использовании dbDESIGN сокращает количество вычислений на уровне элементарных отношений при использовании принципа синтеза от 2n до n-1

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

Описание этапов работы с dbDESIGN

ввод атрибутов предметной области. В самом начале разработчик должен решить, является ли атрибут возможным ключом (компонентом идентифицированного или внешнего ключа). Решение может быть принято после изучения первоначальной схемы, ориентированной на список. REBSAMEN [5] считает эту процедуру целесообразной сточки зрения практичности и стабильности проектирования.

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

Допустим, что:

атрибуты ключа помечены ki;

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

i = 1,2,3; j =1,...,7;

ki - это ключ, превосходящий но отношению к содержанию. После этапов 1 и 2 будем иметь следующую матричную схему:

k1 k2 k3 d1 d2 d3 ... d7

            k1

            k2

F=

d7

Оценка функциональной зависимости

Устранение иерархических структур.

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

Если, например, к1 и к2 включаются в иерархическую структуру, то нулевая матрица F( 0) вытекает из матричной схемы F; при этом выполняются следующие операции:

·         добавление одной строки для сцепленного ключа К4 = К1,К2;

·         удаление всех d-строк;

·         удаление всех столбцов атрибутов, образующих сцепленные ключи.

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

Основой для оценки изображения матрицы F(0) служит оценка функциональности между превосходящим ключом (классификатором первой строки) и атрибутами столбцов.

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

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

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

В результате оценки элементарных отношений F( 0) преобразуется в F( 1). Затем строки F(l) обеспечивают решение вопроса нормализации: каждая строка означает нормализованное отношение. Их идентифицированные ключи определяются классификатором строки, а функционально зависимые атрибуты - значениями 1 в соответствующих столбцах матрицы.

Возможная генерация файлов СУБД.

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

Пакет dbDESIGN предназначен для работы на компьютерах с 16-битовой архитектурой (АС 7150 (СМ 1910), ЕС 1834) под управлением REDABAS в среде операционной системы DCP. После адаптации расширений файлов возможна работа в среде совместимой системы. Разработчик должен хорошо знать функциональные возможности реляционной модели. Проникновение в сложные взаимосвязи данных предметной области - творческий процесс, который поддерживается и облегчается dbDESIGN. Знания REDABAS имеют большое значение тогда, когда предусматривается генерация данных из реляционного проекта.

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

 
Список литературы

In USA wird der Markt fur Datenbank-Management-Systeme ... Online (1987)10, S. 23. (German).

Relational Datenbanken: Letzte Hurde Leistungsfahigkeit. Online (1988)1, S. 6. (German).

LOCKEMANN, P.C. / SCHMIDT, J.W. (Hrsg.): Datenbank-handbuch. Berlin (West) / Heidelberg/ New York / London /Paris /Tokyo: Springer Verlag 1987. (German).

HoLLERING, Н.-Н.: Konzeptuelle Modellierung grober Datenbasen fur komplexe rechnergestutzte Informationssysteme. Dissertation В an der Martin-Luther-Universitat Halle-Wittenberg 1987. (German).

REBSAMEN, J.: Datenbankentwurf im Dialog - Integrierte BeschreibungvonStrukturen, Transaktionen und Konsistenzen. Dissertation an der Eidgenossischen Technischen Hochschule Zurich 1983. (German).

WITT, K.-U. / SCHWARZER, U.S.: Konzeption und Realisierung von Werkzeugen fur den Implementierungs-Entwurf relationaler Datenbanken. Angewandte Informatik 30(1988)8.

WITT, K.-U. / PREISING, C: Anforderungen an und Konzeption fur eine Design-Workstation fur relationale Datenbanken. Angewandte Informatik 29(1987)12.

ERoS. V. et al.i DECOS-Design Tool for Conceptual Schema. Proceedings of the 10th 1SDBMS. Cedzyna/ Poland, October 19-24, 1987.

VOSSEN, G.: uber eine effiziente Implementierungdes Synthese-Verfahrens zum Design relationaler Datenbank-Schcmata. Angewandte Informatik 24(1982)10. (German).

 
ROSENPFLANZER,.!.: Entwurf und Implementierung eines Data Dictionary fur ein Relationales Datenbasissystcm. Dissertation A an der Technischen Universitat Dresden 1988. (German).

NUSSEN, G.M.: On the gross architecture for the next generation Database Mangagement Systems. In: NAGLER-BREITENBACH, I./SCHAUER, H. (Hrsg.): Datenbanksysteme. Internationales Symposium 1977. Wien: Physika-Verlag 1978.

BENESKE, K.: A look to the three major database concepts through the spectacles of the algebraic founded hierarchical data model. Proceedings of the 9th ISDBMS Reinhardsbrunn / DDR, Nov. 30 - Dec. 5,1986.

ZEHNDER, С A.: Informationssysteme und Datenbanken. 4. Auflage. Zurich: Verlag der Fachvereine 1987. (German).