Обобщенное понятие аномалии в рбд

Мы предлагаем неформально определить аномалию как противоречие между концептуальной схемой ПрО и схемой БД. Концептуальная схема - это способ представления знаний о моделируемой ПрО. Схема БД - это формальный способ представления знаний о ПрО средствами выбранной СУБД. Аномалии возникают в том случае, когда наши знания о ПрО оказываются, по каким-то причинам, невыразимыми в схеме БД или входящими в противоречие с ней. Частным случаем является подход, рассмотренный в предыдущем параграфе. Схема отношения у Фейджина соответствует концептуальной схеме ПрО, а ограничения, поддерживаемые СУБД, - схеме БД. Аномалии возникают из-за того, что ограничения, входящие в схему отношения, невозможно выразить через ограничения, поддерживаемые СУБД.

Таким образом, чтобы дать более точное определение аномалии, нам надо выбрать достаточно общее понятие концептуальной схемы. Этим целям вполне соответствует подход к стандартизации понятий "концептуальная схема ПрО" и "информационная база", введенный в работах группы ISO/TC97/SC5/WG3 [7; 8]. В этих работах развита лингвистическая точка зрения на моделирование ПрО. Предметная область (Universe of Discourse) понимается как набор интересующих нас обьектов, которые существовали, существуют или потенциально могут существовать. Все знания о ПрО фиксируются в виде набора предложений естественного языка, выражающих утверждения об объектах, их взаимосвязях, классификации объектов, правилах и ограничениях. (Этот подход имеет много общего с работами в области моделирования бизнес-правил Б. фон Халле [9; 10].)

Под концептуальной схемой (КС) ПрО понимается согласованный набор предложений, выражающих утверждения, истинные для любого состояния ПрО.

Примеры предложений КС: "Сотрудник имеет рабочее место в комнате"; "В комнате находится телефон"; "Сотрудник имеет рабочее место ровно в одной комнате"; "В одной комнате находится не более одного телефона". Последние два предложения выражают наличие функциональной зависимости между объектами предметной области. Согласованность предложений КС означает, что не допускаются предложения, противоречащие друг другу. Например, предложения "Студент слушает не менее 6 курсов в семестре" и "Студент слушает не более 5 курсов в семестре" не могут одновременно входить в КС.

Информационная база (ИБ) - это набор предложений, согласованных друг с другом и с КС, выражающих утверждения, истинные для данного состояния ПрО и не входящие в КС.

Примеры предложений ИБ: "Сотрудник Безруков Д.И. имеет рабочее место в комнате 113"; "В комнате 113 находится телефон [phone]".

При проектировании информационной системы КС отображается в схему БД, а ИБ - в состояние БД. Этот процесс графически представлен на рис 1. Построение "хорошего" отображения - основная задача проектировщика БД.

Рисунок 1.
Общая архитектура информационной системы.

Пусть L - множество всех возможных предложений ИБ. Каждому предложению приписывается оценка истинности (Истина или Ложь). Правила, входящие в КС, выделяют подмножество допустимых предложений ИБ L". Другими словами, L" - это множество предложений, которым в некотором состоянии ПрО может быть приписана оценка Истина. Предложения из L\L" являются тождественно ложными. На рис. 1 и 2 эта область изображена темным квадратом. Множество предложений, которым в текущем состоянии ПрО приписана оценка Истина, называются актуальными предложениями ИБ. Обозначим их LA. Предложения, принадлежащие множеству L"\LA, называются неактуальными предложениями ИБ. Движение пунктирной линии (1) на рис. 1 соответствует изменению состояния ИБ.

Пусть S - множество всех возможных предложений (записей) БД, описывающих ПрО. Ограничения в схеме БД, индуцированные КС, выделяют подмножество S" допустимых предложений БД. Предложения из подмножества S\S" (недопустимые предложения) изображены на рис. 1 и 2 темным квадратом.

Пусть SA - множество предложений БД, которым в текущем состоянии БД приписана оценка Истина. Предложения, принадлежащие SA, называются актуальными предложениями БД.

Предложения, принадлежащие множеству S"\SA, называются неактуальными предложениями БД.

Движение пунктирной линии (2) на рис. 1 и 2 соответствуют изменению состояния БД. Отображение КС в схему БД индуцирует отображение, которое переводит предложения ИБ в предложения БД.

Главный тезис настоящей работы - понятие аномалии неразрывно связано с понятием концептуальной схемы ПрО и ее информационной базы. Аномалия - это противоречие, возникающее при отображение информационной базы в базу данных, которое состоит в том, что некоторое допустимое состояние ИБ отображается в недопустимое состояние БД или обратное отображение переводит допустимое состояние БД в недопустимое состояние ИБ.

Подчеркнем, что аномалии возникают в результате операций над базой данных. Всякое изменение состояния ПрО приводит к необходимости внести изменение в БД, что и выполняется через операции.

Рисунок 2.
Типы аномалий.

Определение 4. Аномалией первого рода будем называть такое отображение ИБ в БД, при котором допустимое предложение ИБ отображается в недопустимое предложение БД.

Стрелка (1) на рис. 2 соответствует аномалии первого рода.

Аномалии первого рода возникают в том случае, когда корректные операции над данными невозможно выполнить из-за ограничений в схеме БД. В примере 1 из предыдущего раздела такой тип аномалий возникает при попытке добавить запись в отношение.

Определение 5. Аномалией второго рода будем называть такое отображение, при котором образ допустимого актуального предложения ИБ является допустимым актуальным предложением БД, а обратное отображение переводит его в неактуальное предложение ИБ. Стрелка (2) на рис. 2 соответствует аномалии второго рода.

Аномалии второго рода возникают в том случае, когда данные введены правильно, но операции над БД могут привести к неправильным результатам. Иллюстрацией этого рода аномалий является пример 2 из предыдущего раздела. Удаляя данные о сотруднике из БД, мы нарушаем ограничения КС, которые не поддерживаются СУБД.

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

Отметим, что в системах управления базами знаний концептуальный уровень и уровень БД объединяются в один. Как следствие не возникает аномалий. Пример - системы, написанные на языке ПРОЛОГ.

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

Заключение

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

1) Выбрать концептуальную модель, с помощью которой будет построена концептуальная схема.

2) Построить точное описание семантических ограничений, поддерживаемых выбранной СУБД.

Для Oracle такая работа в настоящее время проводится [11;12].

3) Построить отображение выбранной концептуальной модели в модель данных, поддерживаемую СУБД.

4) Определить, что такое хорошая схема и описать методику ее построения.

Практическая методика построения хороших схем реляционных БД должна быть создана для каждой пары: концептуальная модель - СУБД.

Из всего сказанного можно сделать еще один практический вывод: нельзя вполне полагаться на мнение сторонников CASE-средств, утверждающих, что эти средства позволяют автоматически генерировать хорошие (нормализованные) схемы баз данных для промышленных СУБД, поддерживающих стандарт SQL.

Литература

1. Fagin R. A. Normal Form for Relational Databases That is Based on Domains and Keys// ACM Transactions on Database Systems.- 1981.- V.6, #.3.- pp.387-415.
2. Цаленко М.Ш. Моделирование семантики в базах данных. - М.: Наука, 1988.
3. Codd E.F. Normalized Data Base Structure: A Brief Tutorial//Proc. of 1971 ACM-SIGFIDET Workshop on Data Description, Access and Control.- N.-Y.: ACM, pp.1-17.
4. Ульман Дж. Основы систем баз данных.- М.: Финансы и статистика, 1983, 334с.
5. Date C.J. An Introduction to Database Systems.- Addison-Wesley, Sixth edition, 1995
6. Codd E.F. Further Normalization of the Data base Relational Model // Data Base Systems.- N.J.: Prentice-Hall, 1972, pp.33-64.
7. Jardine D.A. Concepts and Terminology for the Conceptual Schema and Information Base// Computers and Standards, 1984, V.3, pp.3-17.
8. Jardine D.A., Reuber A.R. Information Semantics and the Conceptual Schema // Information Systems.- V.9, # 2.- 1984, pp.147-156.
9. B. von Halle Back to Business Rule Basics //Database Programming & Design, 1994, v. 7, #.10, pp.15-18.
10. B. von Halle In Pursuit of Good Behavior // Database Programming & Design, 1996, v. 9, #.5, pp.11-15.
11. Kopelaars T. Business Rules: Classification and Implementation.- Proc. of International Oracle User Week, 1994, Paper 10, pp. 1-10.
12. Kopelaars T. Business Rules: Guidelines for Deferred Checking.- Proc. of European Oracle User Group Conference, 1995, Florence, Italy, v. 4, pp. 3-14.

 

___________________________________________________