Главная
страница 1страница 2страница 3страница 4
УДК 004.652
исследования дОменно-ключевой схемы РЕЛЯЦИОННОЙ базы данных
Ключевые слова: схема реляционной базы данных, реляционный каркас, доменно-ключевая нормальная форма, произвольная предметная область, синтез ДКНФ-схемы
Введение

Семантический анализ произвольных предметных областей (ПрО) и современное проектирование схемы реляционной базы данных (БД) осуществляется в основном с использованием модели П. Чена «сущность-связь» [1] или расширенной реляционной модели Э. Кодда [2]. Хороший обзор методов проектирования дан в классических учебниках по БД Д.М. Кренке [3] и С.Д. Кузнецова [4]. Однако модель «сущность-связь» обладает некоторыми недостатками – она не дает строгих формальных определений сущности и атрибута сущности, а также не учитывают функциональных требований к приложению на стадии проектирования схемы БД.

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

Существующий классический подход к проектированию схемы БД имеют следующие недостатки.



  1. Сложность и трудоемкость идентификации функциональных зависимостей (ФЗ);

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

  3. Проблема идентификации сущностей и атрибутов сущностей;

  4. Модифицируемость схемы БД;

  5. Отсутствие четких технологий получения высоко-нормализованных схем БД.

При значительном количестве классов сущностей и атрибутов количество всевозможных ФЗ существенно возрастает. Как правило, на практике все ФЗ не рассматриваются. И практически все отношения из-за экономии времени проходят процесс нормализации не выше 3НФ, что приводит к значительным сбоям и ошибкам на этапе эксплуатации. Очевидно, что для их устранения требуются значительные затраты временных и человеческих ресурсов.

Указанные недостатки и проблемы определяют актуальность разработки метода проектирования схемы БД, устраняющего ошибки проектирования, соответствующего практическим реалиям и значительно снижающего трудозатраты. На наш взгляд, именно модифицируемость схемы БД [5,6] является одним из самых важных критериев качества внедряемых приложений. Однако это свойство невозможно реализовать на низко-нормализованных схемах. В [7] обоснован алгоритм синтеза схемы БД, находящихся в ДКНФ [8] так, что одновременно удовлетворяются и критерии безаномальности, и высокой модифицируемости.



Некоторые контр-выводы относительно ДКНФ

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

По мнению автора работ [9,10] проблема заключается в возможности доказательства факта следствия всех ограничений каждого отношения схемы и ограничений на домены и ключи этих отношений. «Не ясно, как выявить все ограничения целостности. Учитывая, что ограничений много, для каждого нужно привести доказательство. Получается очень трудоемкий процесс… в идентификации ФЗ».

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

- обусловленность доменов и ключей подмножества бинарных, тернарных, квартарных и т.д. отношений-связей доменами и значениями ключей унарных (базовых) отношений, а также их ограничениями, которые строго определяются особыми ограничениями, исследованными в [6],

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

- наличие единственной ФЗ шунтирующих неключевых атрибутов каждого отношения-связи только от своих составных ключевых атрибутов.

Эти свойства обеспечивают «ретрансляцию без искажений» любых ограничений, которые не противоречат особым.

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

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

Описанные свойства схем БД, построенных на каркасе, позволяют приложению осуществлять отслеживание процедур ссылочной целостности в режиме квази-реального времени, когда ввод/редактирование данных в ДКНФ-схему на любой совокупности параллельных терминалов синхронизировано с механизмами контроля и проверки.

Автор [9,10] утверждает, что «в СУБД используются триггеры и транзакции, которые не рассмотрены Р. Фейджиным. Например, при вставке записи в таблицу водительских прав должен сработать триггер, который запретит вставку, если данный пользователь присутствует в группе наркоманов. Перевод денег со счета на счет может выполняться исключительно в виде транзакции. Следовательно, уже рассуждения о ДКНФ не применимы в полной мере к современным СУБД».

Однако описанные ситуации могут быть выражены ограничениями на домены ключей соответствующих связей сущностей-объектов. В схему БД вносится отношение-связь, моделирующее существующую в ПрО связь ЗДОРОВЬЕ ПРЕТЕНДЕНТА (КодПретендента, КодКатегорииЗдоровья,…), которая ограничивает домен ключа для многоарного отношения-связи ПРЕТЕНДЕНТЫ НА ПОЛУЧЕНИЕ ПРАВ (КодПретендента, КодКатегорииЗдоровья, КодСдачиЭкзаменов, КодКатегорииТранспСредства, …, ) по ключу КодПретендента при условии, что КодКатегорииЗдоровья эквивалентен значениям НАРКОМАНЫ, ПЬЯНИЦЫ, ЦВЕТОАНОМАЛЫ и т.п. Ссылочная же целостность отслеживается не триггерами, а универсальными процедурами СУБД.

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

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

Действительно, далеко не все производители современных СУБД заинтересованы предоставлять проектировщику свободу манипулирования данными, что было характерно для инструментальных средств-ровесников работы [8]. Тем не менее, в ситуациях, где возникают конфликты, ДКНФ дает достаточно объективный ориентир. В том числе и для принятия решения о приобретении конкретной СУБД.

Там же, в [11], приведен и красноречивый пример – схема отношения СОТРУДНИК(КодСотр, НомКом, НомТел), которая рассматривается автором как «претендент» на безаномальную схему, хотя и обладает аномалиями. Ограничения задекларированы следующие: атрибут КодСотр (уникальный табельный номер сотрудника) – ключевой атрибут отношения, НомКом (номер комнаты, в которой находится рабочее место сотрудника) – уникальный неключевой атрибут, а НомТел (номер телефона, установленного в этой комнате) – также уникальный неключевой атрибут для исследуемого отношения; две ФЗ: КодСотрНомКом и НомКомНомТел.

Покажем причины этой аномалии. Для этого проведем подробный анализ данного отношения. Прежде всего, определим, что схема приведеного отношения согласно Кодду [12] может быть отнесена лишь к 2НФ – она обладает транзитивной ФЗ. Ключевой атрибут отношения КодСотр является детерминантом одной ФЗ, а не ключевой НомКом – детерминантом иной ФЗ. Как известно, аномалия исключается декомпозицией отношения на два отношения по «неключевой» ФЗ. Поэтому, автором [11] приведенное отношение некорректно отнесено к категории «высоко-нормализованных».

Однако целесообразно провести более подробный анализ возможных зависимостей в указанном отношении-связи (с некорректным наименованием, присвоенным ему автором [11]) СОТРУДНИК (КодСотр, НомКом, НомТел), где присутствуют три атрибута, которые в общем случае представляют независящие друг от друга атомарные сущности-объекты из ПрО.

Из практики проектирования схем БД известно, что в подобном отношении может присутствовать четыре различных варианта зависимостей между атрибутами, по аналогии с [8] называемые нами ограничениями ПрО. Опишем их формально и дадим неформальные комментарии.

1. Транзитивная ФЗ. КодСотрНомКом (F:1), НомКомНомТел (F:1). Формируется избыточная ФЗ КодСотрНомТел (F:1). Эту классическую ситуацию и привел в примере автор [11].

Таблица 1 показывает, что отношение находится в 2НФ. Должно быть декомпозировано на два бинарных отношения: СОТРУДНИКИ+КОМНАТЫ, КОМНАТЫ+ТЕЛЕФОНЫ. А отношение СОТРУДНИКИ+ТЕЛЕФОНЫ может быть получено запросом - потерь информации при этом не будет. Причем, даже если исходное тернарное отношение - важный для ПрО отчет, которой пользователь формирует регулярно, его аномалия не может быть шунтирована, потому что такая «связь» не может иметь атрибутов. Действительно, формально вставить неключевой атрибут в такое отношение невозможно, потому, что весь его кортеж (схема предиката связи) является ключом лишь формально, как дополнение к первичному ключу КодСотр. Это означает, что произвольный атрибут связи может быть лишь суррогатным. Но и он будет зависеть не от всей совокупности, а лишь первичного ключа КодСотр. И при этом аномалия не будет аннулирована – ее причина в несоответствии ограничений на ключ, так как дополнительное ограничение – «вторая» ФЗ – не является следствием ключа. Поэтому ограничения не являются следствием особых ограничений - не могут моделироваться шунтированным каркасным отношением.

Однако заметим, что это и не нужно – в каркасной схеме БД, аналогично традиционной практике, помимо трех атомарных «справочников» СОТРУДНИКИ(КодСотр, …), КОМНАТЫ(НомКом, …) и ТЕЛЕФОНЫ(НомТел, …) имелось бы два бинарных отношения-связи: СОТРУДНИКИ+КОМНАТЫ, КОМНАТЫ+ТЕЛЕФОНЫ. Отношение-связь СОТРУДНИКИ+ТЕЛЕФОНЫ синтезировалось бы автоматически. Причем, для каждой из этих схем несложно обеспечить условия соответствия ДКНФ.
Таблица 1 СОТРУДНИКИ+КОМНАТЫ+ТЕЛЕФОНЫ (2НФ)


КодСотр

НомКом

НомТел

001

13

22

002

13

22

003

14

22

004

14

22

005

15

23

006

16

23

2. МЗ. Возникает тогда, когда одна (условно, «центральная») сущность-объект (ее единственный атрибут или группа составных атрибутов) функционально зависит от каждой иной («соседней») сущности-объекта (одного или группы атрибутов). А между собой эти «соседние» сущности-объекты (атрибуты) не зависят.

Хотя обозначать это принято по иному – правая часть ФЗ многозначно определяет ее детерминант: НомКомКодСотр (1:H) и НомКомНомТел (1:H). А между атрибутами КодСотр и НомТел зависимость отсутствует (F:H).

Неформально это описывается так - к любому из телефонов, установленных в данной комнате (по несколько разных номеров, но не подключенных параллельно с телефонами в иных комнатах!), может подойти любой сотрудник из этой (или иной) комнаты.

В подобной ситуации «пользователи» вносят в ПрО еще одно ограничение – внутри комнат номера телефонов закрепляются за конкретными сотрудниками. Появляется ФЗ КодСотрНомТел (F:1), после чего МЗ в отношении пропадает. Но появляется уже описанная транзитивная зависимость.

Хотя, говоря неформально, на практике такое ограничение ПрО – очень условно для абонента, заинтересованного не в конкретном номере телефона, а в абоненте, если закрепленный за ним номер в этот момент занят.

Таблица 2 показывает, что отношение находится в БКНФ, но не в 4НФ (и не в ДКНФ). Должно быть декомпозировано на два бинарных отношения: КОМНАТЫ+СОТРУДНИКИ и КОМНАТЫ+ТЕЛЕФОНЫ - потерь информации при этом не будет. Или шунтировано атрибутами этой связи.
Таблица 2 СОТРУДНИКИ+КОМНАТЫ+ТЕЛЕФОНЫ (МЗ)


НомКом

КодСотр

НомТел

13

001

22

13

001

23

13

002

22

13

002

23

14

003

24

14

003

25

14

004

24

14

004

25

15

005

26

15

006

26

3. ЗПС. Может возникать тогда, когда от некоторой «первой» сущности-объекта (ее атрибутов) зависит лишь одна («вторая») сущность-объект (ее атрибуты), но от нее не зависит «третья» сущность-объект (ее атрибуты). А также между собой не зависят «вторая» и «третья».

Формально: КодСотрНомКом (F:1), но НомКом−/→НомТел (F:H) и КодСотр−/→НомТел (F:H). Это - наиболее часто встречающийся тип ограничения ПрО на связи между независимыми сущностями-объектами.

Таблица 3 показывает, что отношение находится в 4НФ. Однако, не сложно убедиться, что оно имеет аномалии и удовлетворяет ЗПС. Поэтому должно быть декомпозировано на три бинарных: КОМНАТЫ+СОТРУДНИКИ, КОМНАТЫ+ТЕЛЕФОНЫ и СОТРУДНИКИ+ТЕЛЕФОНЫ - потерь информации при этом не будет. Или шунтировано атрибутами этой связи.


Таблица 3 СОТРУДНИКИ+КОМНАТЫ+ТЕЛЕФОНЫ (ЗПС)

НомКом

КодСотр

НомТел

13

001

22

14

002

23

15

003

23

14

004

24

16

005

25

16

005

23

15

006

26

17

008

27

17

009

28

18

010

27

4. ДЗ. Возникает тогда, когда ни одна сущность-объект (ее атрибуты) не зависят ни от одной иной сущности-объекта. Эта зависимость введена и обоснована в [6].

Формально: НомКом−/→КодСотр (F:H), НомКом−/→НомТел (F:H) и КодСотр−/→НомТел (F:H).

Причем очевидно, что отсутствует еще и зависимость КодСотр−/→(НомКом+НомТел), т.е., в одной комнате может быть много телефонных номеров, что означает, что уникальному значению атрибута КодСотр соответствует не уникальное значение конкатенации атрибутов (НомКом+НомТел), и наоборот. Иными словами, означает полную независимость ТЕЛЕФОНОВ и от КОМНАТ, и от СОТРУДНИКОВ, а также СОТРУДНИКОВ от КОМНАТ. А отношение моделирует полную связь всех сущностей-объектов между собой. Таблица не приведена в связи с ее объемом и тривиальностью. Аналогичная таблица приведена для сущности-объекта «экзамен» в [5].

ПрО с такими связями встречается крайне редко, однако, все же встречается. Это такие ПрО, как «биржа», «библиотека», «выставочный центр», «супермаркет» и т.д., где распределение некоторых групп сотрудников по помещениям и телефонам осуществляется или по сменам, или вообще случайным образом. Очевидно, что в этой ПрО ситуативно может возникнуть единственная ФЗ КодСотрНомКом, которая также будет условной. В общем случае любой сотрудник может находиться в любой комнате и быть приглашенным к любому аппарату, находящемуся в любой комнате. Иными словами, в 5-й, 6-й и 7-й комнатах параллельно подключено 6 телефонных номеров, а работает в них посменно - то по 10 сотрудников, то по 30, то по 2… Тогда очевидно, что данное отношение является тернарной связью атомарных сущностей-объектов со степенью связи F:H:O.

Требование наличия в отношении единственной ФЗ обуславливает особое ограничение – ключом отношения должен быть не атрибут КодСотр, а конкатенация всех атрибутов (КодСотр+НомКом+НомТел), то есть весь кортеж. Тогда необходимо отыскать в ПрО функционально зависящий атрибут такой связи от этого ключа, который и переведет данное отношение к 5НФ.

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

Эти аномалии обнаруживаются потому, что автор [11] в одно отношение внес два высказывания. Приведенное отношение – это и не «многоарное» высказывание-связь с темой: «сотрудники на рабочих местах с телефонами», и не «унарное» высказывание с темой: «сотрудники». Все это означает, что автор [11] не определился, связь чего с чем приведена в отношении.

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

Поскольку в каркасной совокупности формируется строгая иерархия доменов, описанные в [9,10,11] ситуации не могут возникнуть, так как доменами для ключевых атрибутов кортежей бинарных отношений выступают ключевые атрибуты кортежей унарных отношений. Для тернарных – ключевые атрибуты кортежей или унарных, или бинарных, для квартарных – аналогично, и т.д.



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

В работе [7] приведен ряд работ, в которых авторы, так или иначе, касались вопросов, поднятых тут. Но отдельно хотелось бы перечислить совпадения более важные и перспективные.



следующая страница >>
Смотрите также:
Исследования дОменно-ключевой схемы реляционной базы данных Ключевые слова
432.17kb.
4 стр.
Курсовая работа Дисциплина Информационные системы и технологии
236.07kb.
1 стр.
Практические занятия к теме №3 задача 1 Задание Создание базы данных
83.93kb.
1 стр.
Материал из Semantic Future
425.22kb.
2 стр.
Темы дипломных проектов специальности 230105 Базы данных
122.96kb.
1 стр.
Отчет по результатам работы по программе усовершенствования базы данных по сортам растений и изложить предложения по усовершенствованию базы данных по сортам растений
712.53kb.
4 стр.
Лермонтов в тюркоязычном мире (к вопросу о диалоге литератур) Ключевые слова
179.47kb.
1 стр.
Доклад февраль Подготовка материалов по описанию базы данных проекта с использованием anova
38.33kb.
1 стр.
Лекция №1 по дисциплине «Базы данных» базы данных и системы управления базами данных план лекции
219.44kb.
1 стр.
Исследование архитектуры базы данных Oracle Архитектура базы данных Oracle Взаимодействие с базой данных Oracle
107.74kb.
1 стр.
Дисциплина. «Базы данных и субд»
127.3kb.
1 стр.
Сша-кнр: соперничество в юго-восточной азии обостряется я. В. Лексютина — Кандидат политических наук, доцент спбГУ. Ключевые слова
260.16kb.
1 стр.