Дополнительные аспекты реляционной технологии

Проблемы, требующие решения

Проблема 1. Реализация классов и подклассов.

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

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

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

Проблема 2. Хранение производных данных.

Производные данные могут быть получены из других данных с помощью соответствующих вычислений.

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

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

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

Проблема 3. Превращение домена в таблицу.

Существует множество значений, которые пользователи знают наизусть, например, номера месяцев. Надо ли создавать отдельную таблицу, где эти номера расшифровываются? С точки зрения реляционной модели – ответ "да". Решение на физическом уровне не столь очевидно. Общих рекомендаций нет.

Проблема 4. Моделирование времени.

Проблема моделирования времени возникает на концептуальном уровне. Методика концептуального моделирования, рассмотренная ранее, позволяет для решения задачи моделирования времени использовать сущности типа ДАТА или ВРЕМЯ. В этом случае на физическом уровне решается вопрос о необходимости физического создания таблиц для этих сущностей. В большинстве ситуаций сущности этого типа уже сыграли свою роль в процессе формирования модели: они обеспечили появление атрибутов, фиксирующих факты во времени. Поэтому нет смысла создавать для таких сущностей отдельные таблицы.

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

Независимо от используемой методики, способ моделирования времени определяет проектировщик базы данных.

Запросы

Современные СУБД обладают встроенными системами построения запросов (модификация данных, поиск данных, изменения в метаданных и др.).

Одним из наиболее распространенных вариантов является использование QBE (Queries By Example) – запрос по образцу. В этом случае запрос строится визуально путём связывания таблиц и выбора полей, которые следует отобразить в результате запроса.

В большинстве СУБД визуальное построение запроса приводит к генерации текста запроса на языке SQL (Structured Query Language).

Кроме того, запрос может быть непосредственно написан на языке SQL без использования визуальных средств.

Представления

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

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

Представление позволяет:

- скрывать служебную информацию (пользователям она не нужна и не интересна);

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

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

Механизм создания представлений аналогичен механизму создания запросов. Реально представление – это хранящийся в базе данных под каким-либо именем запрос.

Представление отличается от запроса тем, что при изменении данных в исходных таблицах схемы данных происходят изменения в представлениях, созданных на основании этих таблиц. Для того, чтобы увидеть результат изменения данных в запросе, его необходимо выполнить повторно.

Проектирование представлений – это одна из задач физического этапа проектирования баз данных, которая решается средствами СУБД на основании ранее принятых решений, согласованных с заказчиком.

Курсоры

Курсоры – это объекты, с которыми имеют дело, как правило, программисты при написании приложений, работающих с реляционными базами данных.

Курсор позволяет обрабатывать результаты запроса, которые представляют собой набор из строк и столбцов (dataset). В отличие от реляционной таблицы строки такого набора считаются упорядоченными и на них можно ссылаться с помощью специального указателя – курсора (cursor). В документации по СУБД часто сам набор строк называется курсором.

Большинство СУБД поддерживает двунаправленные курсоры (bi-directional cursor), позволяющие перемещаться по результирующему набору данных как вперёд, так и назад.

Обычно курсор предварительно объявляется под некоторым именем в виде запроса на языке SQL. В нужном месте программы курсор вызывается на выполнение, полученный при этом результат запроса может быть обработан программно.

Хранимые процедуры

Хранимая процедура – это специальный вид процедуры, который выполняется сервером баз данных, а не клиентом.

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

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

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

Триггеры

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

Триггер всегда связан с конкретной таблицей и выполняется тогда, когда при редактировании этой таблицы наступает событие, с которым он связан (вставка, обновление или удаление строк таблицы).

Большинство СУБД разрешает создавать несколько триггеров на одно событие, при этом задаётся порядок их выполнения.

Для создания триггеров используются средства DDL.