Заключительные замечания

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

- Я объяснил, почему нас должны интересовать принципы, а не продукты, и почему (по крайней мере, в реляционных контекстах) я буду пользоваться формальной терминологией (отношения, кортежи, атрибуты) вместо «более дружественной» терминологии SQL.

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

- Я рассмотрел различные свойства отношений, ввел понятия заголовка, тела, кардинальности и степени. Отношение не может содержать кортежей-дубликатов, кортежи не упорядочены сверху вниз,

а атрибуты не упорядочены слева направо. Мы также обсудили различия между базовыми отношениями (точнее, базовыми переменными-отношениями) и представлениями.

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

- Я высказал утверждение о том, что SQL и реляционная модель – не одно и то же. Несколько различий между ними мы уже видели, на- пример: SQL допускает null-значения и строки-дубликаты; столбцы в таблицах SQL упорядочены слева направо; в SQL не проводится четкое разграничение между табличными значениями и табличными переменными (поскольку для того и другого употребляется один и тот же термин, таблица). А ниже мы встретимся и со многими другими различиями. Все эти вопросы будут подробно рассматриваться в последующих главах.

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

Примечание

Уже после того как предыдущий абзац был написан, мне сообщили, что по меньшей мере в одном широко известном SQL-продукте слово «декларативный» употребляется в том смысле, что система не выполняет предписанной работы! Иными словами, пользователю разрешается записать некое декларативное предписание (например, указать, что представление имеет ключ), но система ничего не делает для проверки этого ограничения, а лишь предполагает, что его будет проверять пользователь. Такая терминологическая неразбериха не способствует правильному пониманию. Caveat lector.

Автор : К. Дж. Дейт.

 

 








Дата добавления: 2017-01-17; просмотров: 690;


Поиск по сайту:

При помощи поиска вы сможете найти нужную вам информацию.

Поделитесь с друзьями:

Если вам перенёс пользу информационный материал, или помог в учебе – поделитесь этим сайтом с друзьями и знакомыми.
helpiks.org - Хелпикс.Орг - 2014-2024 год. Материал сайта представляется для ознакомительного и учебного использования. | Поддержка
Генерация страницы за: 0.003 сек.