12.3. Brosda V., Vossen g. Update and Retrieval Through a Universal Schema Interface // acm tods. — December, 1988. — 13, № 4.

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

12.4. Carlson C.R., Kaplan R.S. A Generalized Access Path Model and Its Application to a Relational Data Base System // Proc, 1976 ACM SIGMOD Intern. Conf. on Management of Data. — Washington, D.C., June, 1976.

См. аннотацию к [12.19].

12.5. Date c.J. Will the Real Fourth Normal Form Please Stand Up? // c. J. Date and Hugh Darwen. Relational Database Writings 1989-1991.— Reading, Mass.: Addison-Wesley, 1992.

В работе отмечается, что "существует несколько различных понятий в области проектирования баз данных, которые разные авторы называют одинаково — чет­вертая нормальная форма (4НФ)". Назначение данной работы — прояснить смысл

этого понятия. Здесь, вероятно, следует добавить, что единственно правильное оп­ределение 4НФ приводится в данной главе... Не верьте никаким другим!

12.6. Date C.J. The Normal Is So... Interesting (в двух частях) // DBP&D. — November- December, 1997. — 10, Nos. 11-12.

Обсуждение нормализации в разделе 12.5 взято из этой работы. Кроме того, следу­ет отметить некоторые дополнительные особенности.

• Даже в такой базе данных, которая используется только для чтения, необходи­мо задавать ограничения целостности, поскольку они определяют смысл дан­ных, а, как отмечается в разделе 12.4, отказ от денормализации предоставляет простой способ определения некоторых важных ограничений. Если же база данных используется не только для чтения, то исключение денормализации ее данных предоставляет простой способ реализации этих ограничений.

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

• В общем случае следует придерживаться такого правила: денормализацию (на логическом уровне) следует использовать в качестве тактики повышения про­изводительности "только в ситуации, когда все другие методы себя исчерпали".

12.7. Date C.J. The Final Normal Form! (в двух частях) // DBP&D. — January-February, 1998. — 11, Nos. 1-2.

Учебное пособие по зависимостям соединения и 5НФ.

8. Date C.J. What's Normal, Anyway? // DBP&D. — March, 1998. — 11, Nos. 3. Обзор некоторых "патологических" примеров нормализации, в частности примера с переменной-отношением USA из упр. 11.2 главы 11.

9. Date C.J. Normalization Is No Panacea // DBP&D. — April, 1998. — 11, Nos. 4. Обзор некоторых аспектов проектирования базы данных, когда применение теории нормализации не дает результата. Данную статью не следует рассматривать как критику этой теории.

12.10.Date C.J., Fagin R. Simple Conditions for Guaranteeing Higher Normal Forms in Relational Databases // C. J. Date and Hugh Darwen. Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992. (Работа также опубликована в ACM TODS. — September, 1992. — 17, № 3.)

В этой работе показано, что если переменная-отношение R находится в ЗНФ и все потенциальные ключи переменной-отношения R простые (т.е. состоят из одного атрибута), то переменная-отношение R автоматически находится в 5НФ. Иначе го­воря, в таком случае не стоит беспокоиться о разных относительно сложных во­просах, связанных с многозначными зависимостями, зависимостями соединения, 4НФ и 5НФ, которые обсуждались в данной главе.

Замечание. В статье также доказан другой результат, а именно: если переменная-отношение R находится в НФБК и хотя бы один из ее потенциальных ключей явля­ется простым, то переменная-отношение R автоматически находится в 4НФ, но не­обязательно в 5НФ.

12.ll.Date С. J., McGovern D. A New Database Design Principle // Relational Database Writings 1991-1994. — Reading, Mass.: Addison-Wesley, 1995.

12.12.Delobel C, Parker D.S. Functional and Multivalued Dependencies in a Relational Database and the Theory of Boolean Switching Functions // Tech. Report No. 142. — Dept. Maths. Appl. et lnformatique, Univ. de Grenoble, France. — November, 1978. В этой работе описанные в [10.3] результаты распространяются на многозначные зависимости по образу и подобию функциональных зависимостей.

12.13.Fagin R. Multivalued Dependencies and a New Normal. Form for Relational Databases // ACM TODS. — September, 1977. — 2, № 3.

Под упомянутой в заголовке этой статьи новой нормальной формой подразу­мевается 4НФ.

Здесь следует добавить замечание о внедренных многозначных зависимостях. До­пустим, что переменная-отношение СТХ, рассмотренная в этой главе, расширена дополнительным атрибутом DAYS, представляющим количество дней, затраченных на преподавание предмета по учебнику TEXT некоторым преподавателем TEACHER, ведущим некоторый курс обучения COURSE. Назовем такую расширенную перемен­ную-отношение именем CTXD и рассмотрим приведенный ниже пример ее данных.

CTXD

COURSE	TEACHER	TEXT	DAYS
Physics	Prof. Green	Basic Machanics	5
Physics	Prof. Green	Principles of Optics	5
Physics	Prof. Brown	Basic Machanics	6
Physics	Prof. Brown	Principles of Optics	4
Math	Prof. Green	Basic Machanics	3
Math	Prof. Green	Vector Analysis	3
Math	Prof. Green	Trigonometry	4

Комбинация атрибутов {COURSE, TEACHER, TEXT} в таком случае является потен­циальным ключом этой переменной-отношения, в которой имеет место следующая функциональная зависимость.

{ COURSE, TEACHER, TEXT } -> DAYS

Можно заметить, что данная переменная-отношение находится в 4НФ, поскольку не содержит никаких многозначных зависимостей, которые не являются одновременно и функциональными зависимостями (если вспомнить определения 4НФ и МЗЗ). Од­нако она содержит две внедренные многозначные зависимости (атрибута TEACHER от атрибута COURSE и атрибута TEXT от атрибута COURSE). Внедренная многозначная за­висимость атрибута В от атрибута А имеет место в переменной-отношении R, если в некоторой проекции переменной-отношения R выполняется "обычная" многозначная зависимость А —>-> В. Обычная многозначная зависимость является специальным случаем внедренной многозначной зависимости, но не все внедренные многозначные зависимости являются обычными многозначными зависимостями. Как иллюстрируется в данном примере, внедренные многозначные зависимости так­же предполагают избыточность, как и обычные МЗЗ, однако она не может быть ис­ключена с помощью разбиения на проекции. Представленную выше переменную­

отношение нельзя подвергнуть декомпозиции без потерь (она фактически находится не только в 4НФ, но и в 5НФ), поскольку атрибут DAYS зависит от всех трех атрибу­тов, COURSE, TEACHER и TEXT, и потому не может присутствовать в отношении без ка­кого-либо из этих атрибутов. Значит, две внедренные многозначные зависимости следует рассматривать как дополнительные явно заданные ограничения для данной переменной-отношения (подробности приводятся в последующих главах книги).

12.14.Fagin R. Normal Forms and Relational Database Operators // Proc. 1979 ACM SIGMOD Intern. Conf. on Management of Data. — Boston, Mass. — May-June, 1979. В статье представлена концепция проекционно-соединительной нормальной фор­мы (или 5НФ). Эта концепция также может рассматриваться как определение того, что можно назвать "классической" теорией нормализации, т.е. теорией декомпози­ции без потерь, основанной на проекции как операторе декомпозиции и на естест­венном соединении как соответствующем операторе композиции.

12.15.Fagin R. A Normal Form for Relational Databases That Is Based on Domains and Keys // ACM TODS. — September, 1981. — 6, № 3.

12.16.Fagin R. Acyclic Database Schemes (of Various Degrees): A Painless Introduction // IBM Research Report RJ3800. — April, 1983. (Переиздано: Proc. CAAP83 8th Colloquium on Trees in Algebra and Programming: Springer-Verlag Lecture Notes in Computer Science No. 159 (eds. G. Ausiello and M. Protasi).— New York, N.Y.: Springer-Verlag, 1983.)

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

Ацикличность удобно представить в следующем виде: как теория нормализации позволяет определить целесообразность реструктуризации отдельной переменной-отношения, так и теория ацикличности позволяет определить целесообразность ре­структуризации набора переменных-отношений. 12.17.Fagin R., Vardi M.Y. The Theory of Data Dependencies — A Survey// IBM Research Report RJ4321. — June, 1984. (Переиздано: Mathematics of Information Processing // Proc. Symposia in Applied Mathematics 34, American Mathematical Society, 1986.) В этой работе излагается краткая история теории зависимостей по состоянию на середину 1980-х годов (следует обратить внимание, что слово "зависимость" в данном случае относится не только к функциональным зависимостям). В частно­сти, в статье подытожены основные достижения в трех отдельных областях этой

теории с перечнями рекомендуемой литературы по каждой из тем. Эти три темы включают (1) проблему импликации, (2) универсальную реляционную модель и (3) ациклические схемы. Проблема импликации состоит в выяснении для заданного множества зависимостей D и некоторой отдельной зависимости d, будет ли зависи­мость d логическим следствием множества зависимостей D (подробности приво­дятся в разделе 10.7). Универсальная реляционная модель и ациклические схемы кратко обсуждаются в комментариях к [12.19] и [12.16] соответственно. 12.18.Fagin R., Mendelzon А.О., Ullman J.D. A Simplified Universal Relation Assumption and Its Properties // ACM TODS. — September, 1982. — 7, № 3. Здесь содержится предположение о том, что реальный мир всегда может быть представлен с помощью универсальной переменной-отношения [12.19], которая удовлетворяет точно одной зависимости соединения вместе с некоторым множе­ством функциональных зависимостей, а также обсуждаются следствия такого предположения.

12,19.Kent W. Consequences of Assuming a Universal Relation // Ibid. — December, 1981. —6, №4.

Здесь несколькими способами представлена концепция универсальной перемен­ной-отношения. В первом способе согласно порядку нормализации, описанному в последних двух главах, предполагается возможность задания исходного универ­сального отношения (а точнее, универсальной переменной-отношения), которое включает все атрибуты рассматриваемой базы данных. Затем демонстрируется, как такая переменная-отношение может последовательно заменяться "меньшими" про­екциями (т.е. отношениями меньшей степени) вплоть до достижения некоторой "приемлемой" структуры. Но является ли исходное предположение реальным или справедливым? В работе утверждается, что это не так с практической и теоретиче­ской точек зрения. В ответ на данную статью появилась публикация [12.32], а в от­вет на нее — [12.20].

Во втором способе, более существенном с практической точки зрения, концепция универсальной переменной-отношения выступает в качестве интерфейса пользо­вателя. Основная идея здесь совершенно ясна и действительно (с интуитивной точки зрения) весьма притягательна: пользователям следует составлять запросы не в терминах переменных-отношений и их соединений, а на основе одних только ат­рибутов, например так, как показано в приведенном ниже выражении, где требует­ся "получить статус всех поставщиков красных деталей".

RETRIEVE STATUS WHERE COLOR - 'Red'

В этой связи идея имеет две более или менее различающиеся интерпретации.

1. Одна возможность заключается в том, что система должна каким-то образом само­стоятельно определить, какому логическому пути нужно следовать для выполнения запроса (в частности, какие соединения ей необходимо создавать). Таков подход, предлагаемый в [12.4] (эта статья, по всей видимости, является первой статьей, по­священной возможности создания универсального интерфейса пользователя, хотя сам термин "универсальная переменная-отношение" в ней не упоминается). Этот подход в значительной степени зависит от правильного именования атрибутов. Та­ким образом, например, для двух атрибутов номера поставщика (в переменных­

отношениях S и SP соответственно) должны быть заданы одинаковые имена; и на­оборот, для атрибутов города, в котором находится поставщик, и города, в котором хранятся детали (в переменных-отношениях S и Р соответственно), должны быть за­даны разные имена. Если какое-либо из этих правил будет нарушено, то некоторые запросы могут быть выполнены не совсем корректно. 2. В другой, менее амбициозной, интерпретации все запросы рассматриваются в терминах предопределенного набора соединений — в действительности предо­пределенного представления, состоящего из соединения всех переменных-отношений в рассматриваемой базе данных. Хотя нет сомнений в том, что любой из представленных здесь подходов позволяет значительно упростить выражения при формулировании многих практических запро­сов (причем тот или иной вариант данного подхода будет весьма уместен в клиент­ских приложениях, поддерживающих естественный язык общения), ясно, что в об­щем случае система должна поддерживать и средства явного указания логического пути доступа. Для подтверждения данного тезиса рассмотрим следующий запрос.

RETRIEVE STATUS WHERE COLOR Ф 'Red'

Что означает запрос "Получить статус всех поставщиков не красных деталей" или "Получить статус всех поставщиков, которые не поставляют красные детали"? Ка­кой бы смысл из двух предложенных не был выбран системой, должен также су­ществовать способ формулировки и другого варианта запроса. (К тому же первый пример может иметь альтернативную интерпретацию: "Получить статус для по­ставщиков только красных деталей".) В качестве третьего примера можно привес­ти запрос "Получить имена поставщиков, находящихся в одном и том же городе", для которого, очевидно, придется явным образом задать соединение (поскольку в нем предусматривается соединение переменной-отношения S с самой собой).