Правильная ссылка на эту страницу
http://az-design.ru/Support/DataBase/SQL/SQL92/SQL92-1ch_2.shtml

Глава I
Общее представление SQL
(2)

Азбука реляционных баз данных

       В основе реляционных баз данных (и стандарта SQL) лежит несколько простых правил и принципов:
       1. Все значения данных состоят из простых типов данных. В отличие от языков, с которыми вы можете быть знакомы, в SQL отсутствуют массивы, указатели, векторы и другие сложные типы данных.
       2. Все данные в реляционной базе изображаются в форме двухмерных таблиц (на языке математики — "отношений"). Каждая таблица содержит некоторое число строк (в том числе 0), называемых "картежами" и один или несколько столбцов, называемых "атрибутами". Все строки в таблице имеют одну и ту же последовательность столбцов, в которых записаны различные значения, однако наборы значений в столбцах отличаются. На рис.I.1 приведена простейшая таблица такого типа.
       3. После того, как данные введены в БД, можно сравнивать значения в различных столбцах (в том числе и для разных таблиц) или объединять строки, в которых найдено совпадение. Это позволяет соотносить между собой строки и производить очень сложные операции обработки над всеми данными, находящимися в базе.
       4. Все операции определяются только логикой, а не положением строки в таблице. Например, можно запросить все строки, где (х=3), и невозможно запросить первую, третью или пятую строку. Строки в реляционной базе данных расположены в произвольном порядке и порядок, в котором они записаны, необязательно соответствует тому порядку, в котором они были введены или в котором они хранятся на диске.
       5. Поскольку невозможно определить строку по ее положению (порядку в таблице), необходимо иметь один или несколько столбцов с уникальным значением для идентификации каждой строки. Эти столбцы называются первичными ключами таблицы. В примере на рис.I.1 это первый столбец.
       Рассмотрим, что означают эти правила на практике.
       Одним из преимуществ реляционного подхода к построению БД является отсутствие необходимости заботиться о таких деталях, как способы представления данных или их физическое размещение в самой базе. Старые иерархические и сетевые базы данных, в которых приходилось иметь дело с подобными вопросами реализации, имели громоздкую структуру и были сложными в управлении. Однако, если вы уже привыкли к подобным системам, вам придется адаптироваться к новому подходу к обработке данных в мире реляционных баз данных.

C l i e n t s

ID_NUM

NAME

CITY

STATE

1809

Stoklas

San Francisco

CA

1996

Abril

New York

NY

1777

Vencera

Portland

OR

Рис.I.1 Таблица простейшей реляционной базы данных

Примечание
       Иногда в современной практике для строки используется термин "запись", а для столбца термин "поле". Такая терминология заимствована из старых систем и, в действительности, относится к тому, как организовано хранение информации на диске. Хотя во многих реляционных базах данных применяются термины дисковой организации: "запись" и "поле", в этой терминологии нет никакой необходимости и ее нельзя признать наилучшей.

Создание базы данных

       Одно из достоинств реляционного подхода — это его простота. Все данные могут быть представлены и переданы на любые устройства для вывода информации в одной и той же простой форме: в виде таблиц. Проблемы возникают тогда, когда подобным способом нужно смоделировать достаточно сложную ситуацию, однако такие случаи встречаются в современном мире достаточно редко.
       Что же случится, если один столбец будет содержать несколько значений для одной строки? Предположим, мы хотим добавить в таблицу столбец с телефонным номером. Большинство людей имеет, как минимум, два телефона: дома и на работе. Человек может иметь и другие средства связи: факс, пейджер, электронную почту, автоответчик, устройство передачи сообщений и т.п. Одной из основных особенностей реляционной модели является требование, чтобы каждое значение в столбце являлось атомарной величиной, т.е. в каждом столбце для кажюй строки может содержаться только одно значение. Если поместить несколько значений, они всегда будут обрабатываться СУБД, как единая величина.
       Проблема использования дополнительных данных в БД может быть разрешена путем построения другой таблицы (например, таблицы Client_Phone — "телефоны клиентов") с несколькими столбцами. Один столбец будет отведен под номер телефона, другой — под расшифровку типа номера (домашний номер, факс, электронная почта и т.д.) и третий — под описание того, когда можно позвонить человеку по этому номеру. Конечно, мы должны связать телефонный номер с конкретным человеком, который находится на другом конце линии. Владелец номера представлен в нашей первой таблице и поэтому мы должны найти способ связать эти две таблицы.
       Это можно сделать, записав первичный ключ (уникальный идентификатор столбца в таблице клиентов Clients) в таблицу Client_Phone. Поскольку это число уникально для каждого клиента, то всегда можно определить, какому клиенту соответствует данный номер. (Для большей ясности можно также включить имя клиента в таблицу Client_Phone, однако оно будет избыточным и займет дополнительное дисковое пространство. Если конкретное число связывает две таблицы, всегда можно правильно определить соответствующее имя.) Колонка ID_num в таблице Client_Phone называется внешним ключом, и мы будем говорить, что он имеет ссылку на первичный ключ таблицы Clients. (В этом руководстве ключи, на которые ссылаются внешние ключи, носят название родительских ключей). Рис.I.2 служит иллюстрацией таких отношений. Если все значения внешних ключей в таблице "Client Phone" имеют ссылку на значения, которые реально присутствуют в таблице Clients, то принято говорить, что система обладает свойством ссылочной целостности. Если ссылочная целостность отсутствует, то это должно вызывать тревогу, так как означает, что в базе данных существуют телефонные номера для тех клиентов, которых нет в таблице Clients или которые не могут быть идентифицированы.
       Кроме того, для таблицы Client_Phone также необходим первичный ключ, так как каждая таблица должна иметь первичный ключ. Для этой цели нельзя использовать номера в столбце ID_num, так как они не уникальны (у одного и того же клиента может быть несколько телефонных номеров). А может быть использовать для этой цели сам телефонный номер? Это уже лучше, но возможна ситуация, когда два клиента имеют один и тот же телефон дома или в офисе. Если такое случается, то возникает необходимость "проследить" отдельно каждый телефонный номер. В противном случае может потребоваться специальная трудноосуществимая обработка.

Client_Phone

ID_NUM

PHONE

TYPE

AVAIL

1809

415 555 8956

home

after 6pm

1809

510 555 6220

work

9-5 mf

1996

212 555 0199

work

app. 10-7

1996

212 555 7878

beeper

any

1777

503 555 2279

FAX

any

1777

503 555 9188

home

after 7

Рис.I.2. Таблица Client_Phone

       Первичный и внешний ключи необязательно должны основываться только на одном столбце. Мы можем скомбинировать столбцы ID_num и Phone (телефон). Эта комбинация должна всегда быть уникальной, потому что если мы встретим дважды один и тот же номер, относящийся к одному и тому же человеку, то это означает двойное вхождение, и одну из таких строк нужно отбросить. Таким образом, комбинация ID_num и Phone является логическим первичным ключом для таблицы Client_Phone. Ключ, который использует более одного столбца, иногда носит название многостолбцового, составного или конкатенированного.
       Подводя итоги, можно сказать, что каждая таблица имеет группу, состоящую из одного или нескольких столбцов, которая должна иметь уникальное значение для каждой строки таблицы. Эта величина или связанная группа величин образует первичный ключ и служит для идентификации строки. Таблица также может иметь группу из одного или нескольких столбцов, которая указывает на ее связь с другой таблицей. Эта группа называется внешним ключом, а группа столбцов в другой таблице, с которой связана первая таблица, называется родительским ключом. Родительский ключ должен быть уникальным идентификатором, чтобы всегда можно было указать, на какую строку таблицы родительского ключа имеется ссылка во внешнем ключе. Внешний ключ будет иметь то же количество и тип данных столбцов, что и родительский ключ, хотя он может называться по-другому. Значения внешних ключей не обязаны быть (и обычно не бывают) уникальными в своей таблице. Это необходимо только для таблицы родительских ключей. Система обладает ссылочной целостностью, если все значения внешних ключей представлены в родительском ключе, на который они ссылаются.

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

Объединение или связывание таблиц

       Теперь, когда стало ясно, как связать две таблицы, чтобы номера телефонов ассоциировались с информацией о клиентах, владеющих этими телефонами, встает вопрос: кто должен это сделать? Две таблицы остаются отдельными сущностями в базе данных. Однако, при извлечении содержащейся в них информации можно связать значение каждого внешнего ключа с родительским ключом и с содержимым других столбцов таблицы родительского ключа, которые необходимо просмотреть. Операция, с помощью которой информация извлекается из базы данных, называется запросом. Операция, которая извлекает информацию из нескольких таблиц одновременно, используя связь между столбцами двух таблиц, называется соединением. Соединение, в котором внешний ключ связан с родительским ключом, обычно называется естественным соединением (или, иногда, эквисоединением, хотя этот термин имеет в официальном стандарте другой смысл), так как оно встроено в структуру базы данных. С помощью подобных соединений данных, находящихся в отдельных таблицах, и построена реляционная структура. Существуют и другие способы соединений, которые объясняются в главе II при описании оператора SELECT.
       Группа связанных таблиц, представляющих собой модель реального объекта, носит название схемы. Описание содержимого схемы (т.е. количество таблиц в схеме, количество столбцов в каждой таблице и так далее) отражено в специальной группе таблиц, называемой Information_Shema (информационной схемой) в официальном стандарте SQL. В некоторых продуктах для Информационной Схемы применяется термин "каталог", однако в данном стандарте этот термин используется несколько иначе. Информация подобного типа называется метаданными, так как это данные, используемые для описания других данных.
       Наличие таких таблиц означает, что все информационные запросы о самой базе данных исполняются так же, как и обычные запросы информации из базы данных. Результаты такого запроса имеют ту же самую структуру, что и выходные данные обычного запроса. Такая универсальность называется замкнутостью, и это свойство рассматривается, как одна из наиболее сильных сторон реляционного подхода.
       Обычно схема принадлежит некоторому "пользователю". Технически такая принадлежность реализуется через Authorization ID (идентификатор авторизации), который соответствует определенному пользователю, хотя существуют и исключения, которые описаны в разделе "Привилегии, принадлежащие приложению". В данном руководстве для простоты будет использоваться термин "пользователь". Пользователь заполняет схему объектами. Объект представляет собой элемент схемы, который имеет имя и может быть однозначно идентифицирован. Объекты, которые мы рассматривали раньше, были таблицами, однако существуют и другие виды объектов. Используя оператор GRANT, пользователь может передать другим пользователям права доступа к тем таблицам, которые ему принадлежат. Различные типы доступа называются привилегиями, они дают возможность пользователям выполнять различные операции для работы с объектами. В разделе GRANT главы II даются объяснения смысла возможных привилегий.

См. также:
       главу II оператор GRANT.


<<Пред. Оглавление
Начало раздела
След.>>




Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/DataBase/SQL/SQL92/SQL92-1ch_2.shtml