Большинство перечисленных выше проблем порождается тем, что нормализованная модель считается неизменяемой. Однако на практике оказывается необходимым менять элементы модели для того, чтобы получить удобную схему базы данных. Изменение ролей атрибутов и значений приводит к перестройке исходной модели данных и, как следствие, к перестройке всех компонентов БД. Кроме того, практика показывает, что не каждый фрагмент предметной области можно описать единым отношением.
Поэтому современные СУБД, использующие в своем контуре SQL языки, все чаще включают в свои предложения конструкции, присущие обычным языкам проограммирования.
Создание банков данных обусловливает принципиально новый подход к организации интегрированной базы и предполагает использование специальной системы управления базами данных (СУБД).
На практике фирмы, разрабатывающие СУБД реляционного типа, не предоставляют средств, позволяющих автоматизировать процесс проектирования информационной модели выше, чем в 3НФ, оставляя тем самым разработчику трудно разрешимую теоретическую задачу.
В следующей части пособия [31] рассматривается особая методология идентификации информационных объектов в моделях данных, позволяющая устранить основные недостатки традиционного реляционного подхода. Эта методология положена в основу построения системы (СУБД) ORD, на официальном сайте которой и размещено настоящее пособие.
Резюмируя изложенное во второй и третьей главах, можно отнести проявления основных проблем и недостатков, свойственные традиционному реляционному подходу к трем базовым ситуациям:
При изменении модели предметной области, повлекшем изменение ключей отношений, в зависимости от характера последних можно различать:
Собственно, само по себе изменение ключей отношений, означает не что иное, как изменение функциональных зависимостей, заложенных в модель данных концептуального уровня. Причем расширение состава ключа, фактически увеличивает потенциальную мощность отношения (вне зависимости от того, присутствовал ли в нем ранее добавляемый атрибут), а сжатие ключа - напротив, уменьшает потенциальную мощность отношения (рассматриваемого как множество кортежей).
Вопросы модификации хранимых данных и связанных с этим аномалий (удаления, добавления, обновления, см. п. 2.4) и созданием потенциальных ловушек соединений, также основаны на неадекватном учете имеющихся в модели предметной области функциональных зависимостей. Определенный комментарий по этому поводу был дан в п. 2.5.2.
Что же касается формирования самих ответов на запросы, при которых приходится связывать различные отношения, что может приводить к ловушкам соединений, то для их блокировки в СУБД ORD имеется механизм построения запросов, учитывающий структуру связей объектов, определенную в базе. Этот механизм оказывается схожим с языком запросов QBE и блокирует получение формально верных ответов, не соответствующих действительности. Хотя возможность построения запроса со связью структур по произвольным атрибутам сохраняется, возлагая на пользователя ответственность за семантическую корректность получаемых ответов.