База данных

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

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

    Создание банков данных обусловливает принципиально новый подход к организации интегрированной базы и предполагает использование специальной системы управления базами данных (СУБД).

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

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

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

• изменение модели предметной области, влекущее модификацию ключей отношений, хранящихся в базе данных;
• собственно модификация хранимых данных (редактирование значений, ввод новых данных и удаление существующих)
• формирование ответов на запросы к базе данных.

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

    При изменении модели предметной области, повлекшем изменение ключей отношений, в зависимости от характера последних можно различать:

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

- сжатие ключа  (исключение из него атрибутов);

- изменение состава  ключа (фактически, сочетание двух  предыдущих случаев).

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

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

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

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

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

    Что же касается формирования самих ответов на запросы, при которых приходится связывать различные отношения, что может приводить к ловушкам соединений, то для их блокировки в СУБД ORD имеется механизм построения запросов, учитывающий структуру связей объектов, определенную в базе. Этот механизм оказывается схожим с языком запросов QBE и блокирует получение формально верных ответов, не соответствующих действительности. Хотя возможность построения запроса со связью структур по произвольным атрибутам сохраняется, возлагая на пользователя ответственность за семантическую корректность получаемых ответов.