Программирование >>  Хронологические базы данных 

1 ... 25 26 27 [ 28 ] 29 30 31 ... 348


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

И еще пара последних замечаний.

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

Во-вторых, безусловно, не было бы ошибкой, если бы мы использовали более описательные названия переменных-отношений, подобные SUPPLIERS (поставщики), PARTS (детали) и SHIPMENTS (поставки), вместо сокращенных названий S, Р и SP. Более того, на практике рекомендуется использовать именно такие описательные названия. Однако в нашем конкретном случае в последующих главах названия этих переменных-отношений будут употребляться так часто, что целесообразнее использовать именно короткие названия. Многократно употребляемые длинные названия зачастую способны вызвать раздражение.

3.10. Резюме

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

Реляционная база данных - это такая база данных, которая воспринимается ее пользователями как множество переменных, значениями которых являются отношения (те. переменных-отношений- relvars) или, менее формально, таблиц. Реляционная система - это система, которая поддерживает реляционные базы данных и операции над ними, включая, в частности, операцию выборки строк RESTRICT (иначе называемую SELECT), операцию выборки столбцов PROJECT (также называемую проекцией) и операцию соединения таблиц JOIN. Эти и подобные им операции выполняются на уровне множеств. Свойство замкнутости реляционных систем означает, что результат выполнения операции имеет тот же тип, что и объекты, над которыми проводилась операция (все они являются отношениями). А это, в свою очередь, позволяет использовать вложенные реляционные выражения. Значения переменных-отношений изменяются с помощью операций реляционного присвоения, причем привычные нам операции обновления INSERT, UPDATE и DELETE можно считать сокращенной формой записи операций реляционного присвоения определенных типов.



Формальная теория, положенная в основу реляционных систем, называется реляционной моделью данных. Реляционная модель изучает материал только на логическом уровне и не затрагивает физический уровень. В модели рассматриваются три принципиальных аспекта данных - их структура, сохранение их целостности и манипулирование данными. Структурный аспект касается собственно отношений, аспект целостности имеет отношение (помимо всего прочего) к первичным и внешним ключам, а аспект манипулирования данными связан с операторами (RESTRICT, PROJECT, JOIN и т.д.). Информационный принцип утверждает, что все информационное содержимое реляционной базы данных должно быть представлено одним и только одним способом, а именно - явным заданием значений, помешенных в позиции столбцов в строках отношений.

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

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

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

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



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

Транзакция - это логическая единица работы, которая обычно включает выполнение нескольких операций базы данных. Выполнение транзакции начинается с выполнения оператора BEGIN TRANSACTION и завершается выполнением оператора COMMIT (нормальное завершение) или ROLLBACK (аварийное завершение). Транзакции обладают свойствами атомарности, продолжительности и изолированности одна от другой. При чередующемся выполнении операций нескольких параллельно обрабатываемых транзакций обычно гарантируется, что выполнение этих операций будет упорядоченным.

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

Упражнения

3.1. Дайте определения следующим терминам, автоматическая навигация первичный ключ базовая переменная-отношение предикат внешний ключ представление выборка строк проекция

высказывание производная переменная-отношение

замкнутость реляционная база данных

каталог реляционная модель

операции на уровне множеств реляционная СУБД

оптимизация соединение

откат фиксация транзакции

3.2. Опишите содержимое переменных-отношений каталога TABLE и COLUMN для базы данных поставщиков и деталей.

3.3. Как пояснялось в разделе 3.6, каталог должен описывать самого себя, т.е. включать записи о переменных-отношениях самого каталога. Дополните рис. 3.6 так, чтобы он включал необходимые записи о самих переменных-отношениях TABLE и COLUMN.

3.4. Вот запрос для базы данных поставщиков и деталей.

RESULT := ( ( S JOIN SP ) WHERE P = P2 ) { St, CITY } ; Что получится в результате его выполнения?

Замечание. Здесь может возникнуть небольшое затруднение, касающееся типа данных столбца Р. Мы возвратимся к этому вопросу в разделе 5.2 главы 5 (подраздел Домены ). Аналогичное замечание относится и к следующему упражнению.



1 ... 25 26 27 [ 28 ] 29 30 31 ... 348

© 2006 - 2025 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки.
Яндекс.Метрика