Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции / Горбунов / УП_ОПТ2 / Р5_РОпер.doc
Скачиваний:
29
Добавлен:
16.04.2013
Размер:
1.17 Mб
Скачать
      1. Операции со схемами отношений.

Не желай невозможного...” ХИЛОН из Лакамедона, ок.VIв. до н.э.

При определении схемы реляционного отношения предполагается, что домены атрибутов уже описаны. На них определяется множество всех атрибутов простой РБД в каталогах petry(newAC). Напомним, что по одноименным атрибутом мы связываем между собой экземпляры реляционных отношений в словаре данных. Следовательно, любая схема есть именнованное подмножество атрибутов из newAC. Таким образом, если мы создаем новую схему, то возникает условие априорного определения всех её атрибутов.

В нашей простой БД последнее условие означает и априорное задание необходимых для атрибутов схемы доменов. Мы оказываемся в сильном затруднении, если нас спросят какой из вариантов (первый или второй) лучше для хранения метаданных. С одной стороны, первый проще и нагляднее (но избыточен), с другой стороны – второй более детален, но слишком сильно «связан» по операциям добавления и удаления данных. Очевидно, для построения оптимальной структуры метаданных системному аналитику необходимо:

  1. Уточнить, что значит «наилучший» и для этого исследовать запросы к метаданным и их частоту повторения (и возможные нештатные ситуации);

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

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

      1. Нереляционная операция добавление (add).

За порукой – расплата…” ХИЛОН из Лакамедона, ок.VIв. до н.э.

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

  1. Добавляемый кортеж не соответствует схеме реляционного отношения.

  2. Некоторые значения атрибутов нового кортежа не принадлежат заданным доменам.

  3. Ключ нового кортежа совпадает с уже имеющимся в экземпляре отношения кортежем.

При добавлении кортежа в реляционное отношение объязательно должны быть определены только ключевые атрибуты. Атрибуты – свойства сущности, могут определяться не все. Тогда в поле неопределённых атрибутов возникает значение NULL. Это особое значение, т.к. его совпадение в различных кортежах не есть одно и тоже значение, а означает только его отсутствие. Это может породить проблемы, т.к.NULL-значение есть агрегат многих понятий «отсутствия значений» в конкретном атрибуте.

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

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

Соседние файлы в папке УП_ОПТ2