Главная » SQL, Базы данных » БАЗА ДАННЫХ ПОСТАВЩИКОВ И ДЕТАЛЕЙ

0

В настоящей книге в большинстве примеров используется база данных, известная под названием базы данных поставщиков и деталей. Назначение настоящего раздела — ознакомить читателя с этой базой данных, которая будет служить примером для ссылок в следующих главах. На рис. 3.9 показано  множество значений ее данных. Именно эти конкретные значения  будут  фактически  использоваться в дальнейшем  (где это  имеет смысл)8. На рис. 3.10 показано определение базы данных, для которого снова используется язык Tutorial D (в этом языке ключевое слово VAR означает переменная). Обратите внимание на то, что несколько столбцов имеют типы данных, которым присвоено название, аналогичное названию соответствующего столбца. Столбцы STATUS И CITY определены как имеющие не пользовательский, а встроенный тип  данных,  соответственно, INTEGER (целое) и CHAR (строка символов произвольной длины). Наконец, необходимо отметить, что применительно к значениям, показанным в столбцах на рис. 3.9, должно быть сделано одно важное замечание, однако мы еще не готовы к этому. Поэтому обсуждение упомянутого замечания будет отложено до главы 5, точнее, до конца подраздела

"Возможные форматы представления, селекторы и операторы ТНЕ_" в разделе 5.3.

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

■     Переменная отношения S представляет поставщиков (точнее, поставщиков, рабо тающих по контракту). Каждый поставщик имеет уникальный номер (s#); имя (SNAME), не обязательно уникальное (хотя оно может быть уникальным, как в слу чае, представленном на рис. 3.9); значение рейтинга или статуса (STATUS); место расположения (CITY). Предполагается, что для каждого поставщика может быть указан только один город.

■     Переменная отношения Р представляет детали (точнее, виды деталей). У каждого вида детали есть номер детали (Р#), который является уникальным; название дета ли (PNAME); цвет (COLOR); вес (WEIGHT); город, где находится склад с деталями этого вида (CITY). Предполагается, что если вес детали имеет значение, то он указан в фунтах (ознакомьтесь также с тем, что сказано о единицах измерения в главе 5,

8 Для тех читателей, которые знакомились с этими образцами данных в предыдущих изданиях, отметим, что деталь РЗ передана из Рима в Осло. Такое же изменение внесено на рис. 4.5 в следующей главе.

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

Рис. 3.9. База данных поставщиков и деталей (пример значений)

TYPE S# … ; TYPE NAME … ; TYPE P# … ; TYPE COLOR … ; TYPE WEIGHT …

; TYPE QTY … ;

VAR S BASE RELATION { S# S#,

SNAME NAME, STATUS INTEGER, CITY CHAR

PRIMARY KEY { S# } ;

VAR P BASE RELATION

{ P# P#,

COLOR COLOR, WEIGHT WEIGHT, CITY CHAR }

VAR SP BASE RELATION

{ S# S#,

P# P#,

QTY QTY }

PNAME NAME,

PRIMARY KEY { p# } ;

PRIMARY KEY {    S#, P# }

FOREIGN KEY {    S# } REFERENCES S

FOREIGN KEY {    P# } REFERENCES P ;

Рис. 3.10. База данных поставщиков и деталей (определение данных)

■   Переменная отношения SP представляет поставки. Она в известном  смысле служит для организации логической связи двух других переменных отношения. Например, первая строка переменной отношения  SP на рис. 3.9 связывает поставщика с номером S1 из переменной отношения S с соответствующей деталью, имеющей номер Р1 в переменной отношения Р, т.е. представляет факт поставки деталей типа Р1 поставщиком с номером S1 (а также указывает количество деталей — 300 штук). Таким образом, каждая поставка характеризуется номером поставщика (S#), номером детали (Р#) и количеством (QTY). Предполагается, что в одно и то же время может быть выполнено не больше одной поставки для одного поставщика и одного вида деталей, поэтому для каждой поставки  комбинация значений столбцов s# и Р# уникальна с точки зрения набора текущих поставок, представленных в переменной отношения SP. Обратите внимание на то, что на рис. 3.9 с одним из поставщиков (с номером S5), не связано ни одной поставки.

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

И еще несколько заключительных замечаний.

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

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

З.10. РЕЗЮМЕ

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

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

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

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

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

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии