- •Iso (международной организацией по
- •2 Понимание sql
- •Что такое - реляционная база данных?
- •Порядок строк произволен
- •4 Понимание sql ___________________________________________________________________
- •Идентификация строк ( первичные ключи )
- •Столбцы именуются и нумеруются
- •8 Понимание sql
- •************** Работа с sql **************
- •Sql : обзор
- •Что делает ansi ?
- •Интерактивный и вложенный sql
- •14 Понимание sql
- •Субподразделения sql
- •16 Понимание sql
- •Sql несогласованности
- •Что такое - пользователь?
- •18 Понимание sql
- •Условия и терминология
- •************** Работа с sql **************
- •24 Понимание sql
- •26 Понимание sql
- •Переупорядочение столбца
- •28 Понимание sql
- •Параметры distinct
- •30 Понимание sql
- •32 Понимание sql
- •************* Работа с sql ***************
- •38 Понимание sql
- •40 Понимание sql
- •42 Понимание sql
- •44 Понимание sql
- •Использование специальных операторов в условиях
- •50 Понимание sql
- •52 Понимание sql
- •54 Понимание sql
- •56 Понимание sql
- •************** Работа с sql **************
- •Обобщение данных с помощью агрегатных функций
- •64 Понимание sql
- •66 Понимание sql
- •Включение дубликатов в агрегатные функции
- •Предложение group by
- •68 Понимание sql
- •Предложение having
- •70 Понимание sql
- •72 Понимание sql
- •************** Работа с sql **************
- •Формирование выводов запросов
- •Помещение текста в вашем выводе запроса
- •78 Понимание sql
- •80 Понимание sql
- •82 Понимание sql
- •Упорядочение вывода по номеру столбца
- •84 Понимание sql
- •************** Работа с sql **************
- •Запрашивание многочисленых таблиц также как одной
- •90 Понимание sql
- •92 Понимание sql
- •94 Понимание sql
- •************** Работа с sql **************
- •Объединение таблицы с собой
- •Псевдонимы
- •100 Понимание sql
- •Устранение избыточности
- •102 Понимание sql
- •Больше псевдонимов
- •104 Понимание sql
- •106 Понимание sql
- •************** Работа с sql **************
- •Вставка одного запроса внутрь другого
- •112 Понимание sql
- •114 Понимание sql
- •116 Понимание sql
- •In определяет набор значений, одно из которых должно совпадать с другим
- •118 Понимание sql
- •In является подходящим, если запрос может ограниченно производить одно
- •120 Понимание sql
- •122 Понимание sql
- •*************** Работа с sql *************
- •Соотнесенные подзапросы
- •130 Понимание sql
- •132 Понимание sql
- •Соотнесенные подзапросы в предложении having
- •134 Понимание sql
- •*************** Работа с sql *************
- •Использование оператора exists
- •140 Понимание sql
- •142 Понимание sql
- •144 Понимание sql
- •146 Понимание sql
- •************** Работа с sql **************
- •Использование оператора exists
- •152 Понимание sql
- •154 Понимание sql _____________________________________________________________________
- •156 Понимание sql
- •158 Понимание sql
- •160 Понимание sql
- •162 Понимание sql
- •Использование count вместо exists
- •166 Понимание sql
- •************** Работа с sql **************
Порядок строк произволен
Чтобы поддерживать максимальную гибкость, строки таблицы, по оп-
ределению, не должны находиться ни в каком определенном порядке.
С этой точки зрения, в этом структура базы данных отличается от
нашей адресной книги.
4 Понимание sql ___________________________________________________________________
ГЛ. 1
Вход в адресную книгу обычно упорядочивается в алфавитном порядке.
В системах с реляционной базой данных, имеется одна мощная возмож-
ность для пользоватей - это способность упорядочивать информацию
так чтобы они могли восстанавливать ее.
Рассмотрим вторую таблицу. Иногда Вам необходимо видеть эту
информацию упорядоченной в алфавитном порядке по именам,
иногда в возрастающем или убывающем порядке, а иногда сгруппиро-
ванной по отношению к какому-нибудь доктору.
Наложение порядка набора в строках будет сталкиваться со способностью
заказчика изменять его, поэтому строки всегда рассматриваются как
неупорядоченные. По этой причине, вы не можете просто сказать:" Мы
хотим посмотреть пятую строку таблицы. " Пренебрегая порядком в
котором данные вводились или любым другим критерием, мы определим,
не ту строку, хотя она и будет пятой. Строки таблицы которые рассмат-
риваются, не будут в какой-либо определенной последовательности.
Идентификация строк ( первичные ключи )
По этим и другим причинам, вы должны иметь столбец в вашей таблице
который бы уникально идентифицировал каждую строку. Обычно, этот
столбец содержит номер - например, номер пациента назначаемый каждому
пациенту. Конечно, вы могли бы использовать имя пациентов,
но возможно что имеется несколько Mary Smiths; и в этом случае, вы не
будете иметь другого способа чтобы отличить этих пациентов друг от
друга.
Вот почему номера так необходимы. Такой уникальный столбец( или уни-
кальная группа столбцов ), используемый чтобы идентифицировать каждую
строку и храненить все строки отдельно, называются - первичными ключами
таблицы.
Первичные ключи таблицы важный элемент в структуре базы данных.
Они - основа вашей системы записи в файл; и когда вы хотите найти
определенную строку в таблице, вы ссылаетесь к этому первичному ключу.
Кроме того, первичные ключи гарантируют, что ваши данные имеют
определенную целостность. Если первичный ключ правильно используется
и поддерживается, вы будете знать что нет пустых строк таблицы и что
каждая строка отличается от любой другой строки. Мы будем обсуждать
ключи и далее когда поговорим относительно справочной целостности
в Главе 19.
Столбцы именуются и нумеруются
В отличие от строк, столбцы таблицы ( также называемые полями )
упорядочиваются и именуются. Таким образом, в нашей таблице адресной
ОПИСАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ 5
______________________________________________________________________
книги, возможно указать на " адрес столбца " или на " столбец 3 ". Конечно,
это означает что каждый столбец данной таблицы должен иметь уникальное
имя чтобы избежать неоднозначности. Лучше всего если эти имена указывают
на содержание поля. В типовых таблицах этой книги, мы будем использовать
такие сокращения для имени столбца, как cname для имени заказчика, и odate
для даты порядка. Мы также дадим каждой таблице личный числовой номер
столбца в качестве первичного ключа. Следующий раздел будет объяснять эти
таблицы и их ключи более подробно.
========= ТИПОВАЯ БАЗА ДАННЫХ ==========
Таблицы 1.1, 1.2, и 1.3 составляют реляционную базу данных которая являе-
тся минимально достаточной чтобы легко ее отслеживать, и достаточно
полной, чтобы иллюстрировать главные понятия и практику использования
SQL.
Эти таблицы напечатаны в этой главе а также в Приложении E.
Так как они будут использоваться для иллюстрирования различных особен-
ностей SQL по всей этой книге, мы рекомендуем чтобы вы скопировали их,
для удобства ссылки к ним.
Вы могли уже обратить внимание что первый столбец каждой таблицы
содержит номера чьи значения различны для каждой строки. Как вы
наверное и предположили, это - первичные ключи таблиц. Некоторые из
этих номеров также показаны в столбцах других таблиц. В этом нет ничего
неверного. Они показывают связь между строками которые используют
значение принимаемое из первичного ключа, и строками где это значение
используется в самом первичном ключе.
Таблица 1.1: Продавцы
----------------------------------------------
SNUM | SNAME | CITY | COMM
--------|-----------|--------------|----------
1001 | Peel | London | .12
1002 | Serres | San Jose | .13
1004 | Motika | London | .11
1007 | Rifkin | Barcelona | .15
1003 | Axelrod | New York | .10
---------------------------------------------
6 ПОНИМАНИЕ SQL
________________________________________________________________
ГЛ. 1
Таблица 1.2: Заказчики
----------------------------------------------
CNUM | CNAME | CITY | RATING | SNUM
-------|------------|---------|--------|------
2001 | Hoffman | London | 100 | 1001
2002 | Giovanni | Rome | 200 | 1003
2003 | Liu | SanJose | 200 | 1002
2004 | Grass | Berlin | 300 | 1002
2006 | Clemens | London | 100 | 1001
2008 | Cisneros | SanJose | 300 | 1007
2007 | Pereira | Rome | 100 | 1004
----------------------------------------------
Таблица 1.3: Порядки
-----------------------------------------------
ONUM | AMT | ODATE | CNUM | SNUM
-------|-----------|-------------|------|------
3001 | 18.69 | 10/03/1990 | 2008 | 1007
3003 | 767.19 | 10/03/1990 | 2001 | 1001
3002 | 1900.10 | 10/03/1990 | 2007 | 1004
3005 | 5160.45 | 10/03/1990 | 2003 | 1002
3006 | 1098.16 | 10/03/1990 | 2008 | 1007
3009 | 1713.23 | 10/04/1990 | 2002 | 1003
3007 | 75.75 | 10/04/1990 | 2004 | 1002
3008 | 4723.00 | 10/05/1990 | 2006 | 1001
3010 | 1309.95 | 10/06/1990 | 2004 | 1002
3011 | 9891.88 | 10/06/1990 | 2006 | 1001
-----------------------------------------------
Например, поле snum в таблице Заказчиков указывает, какому продавцу
назначен данный заказчик. Номер поля snum связан с таблицей Продавцов,
которая дает информацию об этих продавцах. Очевидно, что продавец
которому назначены заказчики должен уже существовать - то есть,
значение snum из таблицы Заказчиков должно также быть представлено
в таблице Продавцов. Если это так, то говорят, что " система находится
в состоянии справочной целостности ".
Этот вывод будет более полно и формально объяснен в Главе 19.
ПРИМЕЧАНИЕ: Эти три представленых таблицы в тексте имеют русские
имена - Продавцов, Заказчиков и Порядков, и далее будут упоминаться
именно под этими именами. Имена любых других применяемых в книге
таблиц будут написаны по английски что бы отличать их от наших базовых
таблиц этой базы данных. Кроме того в целях однозначности, имена зака-
зчиков, продавцов, Системных Каталогов а также полей в тексте, также
будут даны на латыни.
ОПИСАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ 7
_________________________________________________________________
Таблицы приведены как пример к похожей ситуации в реальной жизни,
когда вы будете использовать SQL чтобы следить за продавцами, их
заказчиками, и порядками заказчиков. Давайте рассмотрим эти три
таблицы и значения их полей.
Здесь показаны столбцы Таблицы 1.1
ПОЛЕ СОДЕРЖАНИЕ
--------- ----------------------------------------------
snum уникальный номер назначенный каждому продавцу
( " номер служащего " ).
sname имя продавца.
city расположение продавца( город ).
comm комиссионные продавцов в десятичной форме.
Таблица 1.2 содержит следующие столбцы:
ПОЛЕ СОДЕРЖАНИЕ
-------- ---------------------------------------------------
cnum уникальный номер назначенный каждому заказчику.
cname имя заказчика.
city расположение заказчика( город ).
rating код указывающего уровень предпочтения данного заказчика
перед другими. Более высокий номер указывают на большее
предпочтение( рейтинг ).
snum номер продавца назначенного этому заказчику
( из таблицы Продавцов )
И имеются столбцы в Таблице 1.3:
ПОЛЕ СОДЕРЖАНИЕ
--------- ---------------------------------------------------
onum уникальный номер данный каждому приобретению.
amt значение суммы приобретений.
odate дата приобретения.
cnum номер заказчика делающего приобретение
( из таблицы Заказчиков ).
snum номер продавца продающего приобретение
( из таблицы Продавцов).