Перейти к оглавлению
1. ВВЕДЕНИЕ В РЕЛЯЦИОННУЮ БАЗУ ДАННЫХ
SQL (ОБЫЧНО ПРОИЗНОСИМАЯ КАК "SEEQUEL") символизирует собой Струк-
турированный Язык Запросов. Это - язык который дает вам возможность
создавать и работать в реляционных базах данных, которые являются на-
борами связанной информации сохраняемой в таблицах.
Мир баз данных становится все более и более единым, что привело к
необходимости создания стандартного языка который мог бы использовать-
ся чтобы функционировать в большом количестве различных видов компь-
ютерных сред. Стандартный язык позволит пользователям знающим один на-
бор команд, использовать их чтобы создавать, отыскивать, изменять, и
передавать информацию независимо от того работают ли они на персональ-
ном компьютере, сетевой рабочей станции, или на универсальной ЭВМ.
В нашем все более и более взаимосвязанном компьютерном мире, пользо-
ватель снабженый таким языком, имеет огромное преимущество в использо-
вании и обобщении информации из ряда источников с помощью большого
колличества способов.
Элегантность и независимость от специфики компьютерных технологий, а
также его поддержка лидерами промышленности в области технологии реля-
ционных баз данных, сделало SQL, и вероятно в течение обозримого буду-
щего оставит его, основным стандартным языком. По этой причине, любой
кто хочет работать с базами данных 90-х годов должен знать SQL.
Стандарт SQL определяется ANSI (Американским Национальным Институтом
Стандартов) и в данное время также принимается ISO (МЕЖДУНАРОДНОЙ ОР-
ГАНИЗАЦИЕЙ ПО СТАНДАРТИЗАЦИИ). Однако, большинство коммерческих прог-
рамм баз данных расширяют SQL без уведомления ANSI, добавляя разные
другие особенности в этот язык, которые, как они считают, будут весьма
полезны. Иногда они несколько нарушают стандарт языка, хотя хорошие
идеи имеют тенденцию развиваться и вскоре становиться стандартами
"рынка" сами по себе в силу полезности своих качеств. В этой книге, мы
будем, в основном, следовать стандарту ANSI, но одновременно иногда
будет показывать и некоторые наиболее общие отклонения от его стандар-
та.
Вы должны проконсультироваться с документацией вашего пакета прог-
рамм который вы будете использовать, чтобы знать где в нем этот стан-
дарт видоизменен. ПРЕЖДЕ, ЧЕМ ВЫ СМОЖЕТЕ ИСПОЛЬЗОВАТЬ SQL, ВЫ должны
понять что такое реляционные базы данных. В этой главе, мы это объяс-
ним, и покажем насколько реляционные базы данных полезны. Мы не будем
обсуждать SQL именно здесь, и если вы уже знаете эти понятия довольно
хорошо, вы можете просто пропустить эту главу. В любом случае, вы
должны рассмотреть три таблицы которые предоставляются и объясняются в
конце главы; они станут основой наших примеров в этой книге. Вторая
копия этих таблиц находится Приложении E, и мы рекомендуем скопировать
их для удобства ссылки к ним.
ЧТО ТАКОЕ - РЕЛЯЦИОННАЯ БАЗА ДАННЫХ?
Реляционная база данных - это тело связанной информации, сохраняемой
в двумерных таблицах. Напоминает адресную или телефонную книгу. В кни-
ге имеется большое количество входов, каждый из которых соответствует
определеной особенности. Для каждой такой особенности, может быть нес-
колько независимых фрагментов данных, например имя, телефонный номер,
и адрес. Предположим, что вы должны сформатировать эту адресную книгу
в виде таблицы со строками и столбцами. Каждая строка ( называемая
также записью ) будет соответствовать определенной особенности; каждый
столбец будет содержать значение для каждого типа данных - имени, те-
лефонного номера, и адреса представляемого в каждой строке. Адресная
книга могла бы выглядеть следующим образом:
Имя Телефон Адрес
Gerry Farish ( 415)365-8775 127 Primrose Ave.,SF
Celia Brock ( 707)874-3553 246 #3rd St.,Sonoma
Yves Grillet ( 762)976-3665 778 Modernas,Barcelona
То что вы получили является основой реляционной базы данных как и
было определено в начале этого обсуждения - а именно, двумерной (стро-
ка и столбец ) таблицей информации. Однако, реляционные базы данных
редко состоят из одной таблицы. Такая таблица меньше чем файловая сис-
тема. Создав несколько таблиц взаимосвязанной информации, вы сможете
выполнить более сложные и мощные операции с вашими данными. Мощность
базы данных зависит от связи которую вы можете создать между фрагмен-
тами информации, а не от самого фрагмента информации.
СВЯЗЫВАНИЕ ОДНОЙ ТАБЛИЦЫ С ДРУГОЙ
Позвольте нам использовать пример нашей адресной книги чтобы начать
обсуждение базы данных которая может реально использоваться в деловой
ситуации. Предположим, что персонажи в нашей первой таблице ( адресной
книги ) - это пациенты больницы. В другой таблице, мы могли бы запом-
нить дополнительную информацию об этих пациентах. Столбцы второй таб-
лицы могли бы быть помечены как Пациент, Доктор, Страховка, и Балланс.
Пациент Доктор Страховка Балланс
Farish Drume B.C./B.S. $272.99
Grillet Halben None $44. 76
Brock Halben Health,Inc. $9077.47
Много мощных функций можно выполнить извлекая информацию из этих
таблиц согласно указанным параметрам, особенно когда эти параметры
включают в себя фрагменты информации свзанные в различных таблицах
друг с другом. Например, возьмем - докторов. Предположим доктор Halben
захотел получить номера телефонов всех своих пациентов. Чтобы извлечь
эту информацию, он мог бы связать таблицу с номерами телефонов пациен-
тов ( по адресной книге ) с таблицей которая бы указывала, какой из
пациентов - его. Хотя, в этом простом примере, он мог бы держать это в
голове и сразу получать номера телефонов пациентов Grillet и Brock,
эти таблицы могут быть слишком большими и слишком сложными. Программы
реляционной базы данных разрабатывались для того чтобы обрабатывать
большие и сложные совокупности данных такого типа, что очевидно явля-
ется более универсальным методом в деловом мире. Даже если бы база
данных больницы содержала сотни или тысячи имен - как это вероятно и
бывает на практике - одна команда SQL могла бы выдать доктору Halben
информацию в которой он нуждался почти немедленно.
ПОРЯДОК СТРОК ПРОИЗВОЛЕН
Чтобы поддерживать максимальную гибкость, строки таблицы, по опреде-
лению, не должны находиться ни в каком определенном порядке. С этой
точки зрения, в этом структура базы данных отличается от нашей адрес-
ной книги. Вход в адресную книгу обычно упорядочивается в алфавитном
порядке. В системах с реляционной базой данных, имеется одна мощная
возможность для пользоватей - это способность упорядочивать информацию
так чтобы они могли восстанавливать ее.
Рассмотрим вторую таблицу. Иногда Вам необходимо видеть эту информа-
цию упорядоченной в алфавитном порядке по именам, иногда в возрастаю-
щем или убывающем порядке, а иногда сгруппированной по отношению к ка-
кому-нибудь доктору. Наложение порядка набора в строках будет сталки-
ваться со способностью заказчика изменять его, поэтому строки всегда
рассматриваются как неупорядоченные. По этой причине, вы не можете
просто сказать:" Мы хотим посмотреть пятую строку таблицы. " Пренебре-
гая порядком в котором данные вводились или любым другим критерием, мы
определим, не ту строку, хотя она и будет пятой. Строки таблицы кото-
рые рассматриваются, не будут в какой-либо определенной последователь-
ности.
ИДЕНТИФИКАЦИЯ СТРОК ( ПЕРВИЧНЫЕ КЛЮЧИ )
По этим и другим причинам, вы должны иметь столбец в вашей таблице
который бы уникально идентифицировал каждую строку. Обычно, этот стол-
бец содержит номер - например, номер пациента назначаемый каждому па-
циенту. Конечно, вы могли бы использовать имя пациентов, но возможно
что имеется несколько Mary Smiths; и в этом случае, вы не будете иметь
другого способа чтобы отличить этих пациентов друг от друга.
Вот почему номера так необходимы. Такой уникальный столбец( или уни-
кальная группа столбцов ), используемый чтобы идентифицировать каждую
строку и храненить все строки отдельно, называются - первичными ключа-
ми таблицы.
Первичные ключи таблицы важный элемент в структуре базы данных. Они
- основа вашей системы записи в файл; и когда вы хотите найти опреде-
ленную строку в таблице, вы ссылаетесь к этому первичному ключу. Кроме
того, первичные ключи гарантируют, что ваши данные имеют определенную
целостность. Если первичный ключ правильно используется и поддержива-
ется, вы будете знать что нет пустых строк таблицы и что каждая строка
отличается от любой другой строки. Мы будем обсуждать ключи и далее
когда поговорим относительно справочной целостности в Главе 19.
СТОЛБЦЫ ИМЕНУЮТСЯ И НУМЕРУЮТСЯ
В отличие от строк, столбцы таблицы ( также называемые полями ) упоря-
дочиваются и именуются. Таким образом, в нашей таблице адресной книги,
возможно указать на " адрес столбца " или на " столбец 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
-----------------------------------------------------------
Таблица 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.
ПРИМЕЧАНИЕ: Эти три представленых таблицы в тексте имеют русские
имена - Продавцов, Заказчиков и Порядков, и далее будут упоминаться
именно под этими именами. Имена любых других применяемых в книге таб-
лиц будут написаны по английски что бы отличать их от наших базовых
таблиц этой базы данных. Кроме того в целях однозначности, имена за-
казчиков, продавцов, Системных Каталогов а также полей в тексте, также
будут даны на латыни.
Таблицы приведены как пример к похожей ситуации в реальной жизни,
когда вы будете использовать SQL чтобы следить за продавцами, их за-
казчиками, и порядками заказчиков. Давайте рассмотрим эти три таблицы
и значения их полей.
Здесь показаны столбцы Таблицы 1.1
ПОЛЕ СОДЕРЖАНИЕ
--------- ----------------------------------------------
snum уникальный номер назначенный каждому продавцу
( " номер служащего " ).
sname имя продавца.
city расположение продавца( город ).
comm комиссионные продавцов в десятичной форме.
Таблица 1.2 содержит следующие столбцы:
ПОЛЕ СОДЕРЖАНИЕ
-------- ---------------------------------------------------
cnum уникальный номер назначенный каждому заказчику.
cname имя заказчика.
city расположение заказчика( город ).
rating код указывающего уровень предпочтения данного заказчика
перед другими. Более высокий номер указывают на большее
предпочтение( рейтинг ).
snum номер продавца назначенного этому заказчику
( из таблицы Продавцов )
И имеются столбцы в Таблице 1.3:
ПОЛЕ СОДЕРЖАНИЕ
--------- ---------------------------------------------------
onum уникальный номер данный каждому приобретению.
amt значение суммы приобретений.
odate дата приобретения.
cnum номер заказчика делающего приобретение
( из таблицы Заказчиков ).
snum номер продавца продающего приобретение
( из таблицы Продавцов).
=========== РЕЗЮМЕ ============
Теперь вы знаете что такое реляционная база данных, понятие, которое
звучит сложнее чем есть на самом деле. Вы также изучили некоторые фун-
даментальные принципы относительно того, как сделаны таблицы - как ра-
ботают строки и столбцы, как первичные ключи отличают строки друга
друга, и как столбцы могут ссылаться к значениям в других столбцах.
Вы поняли что запись это синоним строки, и что поле это синоним
столбца. Оба термина встречаются в обсуждении SQL, и мы будем исполь-
зовать их в равной степени в этой книге.
Вы теперь знакомы с таблицами примеров. Краткие и простые , они спо-
собны показать большинство особенностей языка, как вы это увидите В
некоторых случаях, мы будем использовать другие таблицы или постулаты
некоторых различных данных в одной из этих таблиц чтобы показать вам
некоторые другие возможности.
Теперь вы готовы к углублению в SQL самостоятельно. Следующая глава
даст вам быстрый просмотр языка, и даст вам информацию, которая помо-
жет Вам ссылаться к уже пройденным местам.
************** РАБОТА С SQL **************
1. Какое поле таблицы Заказчиков является первичным ключом ?
2. Что является столбцом 4 из таблицы Заказчиков ?
3. Как по другому называется строка? Столбец?
4. Почему вы может не запрашивать для просмотра первые пять строк
таблицы?
( См. Приложение A для ответов. )
Перейти к оглавлению
