Мартин Грубер - Понимание SQL (Мартин Грубер. Понимание SQL), страница 2

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

Адреснаякнига могла бы выглядеть следующим образом:ИмяGerry FarishCelia BrockYves GrilletТелефон(415)365-8775(707)874-3553(762)976-3665Адрес127 Primrose Ave.,SF246 #3rd St., Sonoma778 Modernas, BarcelonaТо что вы получили является основой реляционной базы данных как и было определено в начале этого обсуждения — а именно, двумерной (строка и столбец) таблицей информации.

Однако, реляционные базы данных редко состоят из однойтаблицы. Такая таблица меньше чем файловая система. Создав несколько таблицвзаимосвязанной информации, вы сможете выполнить более сложные и мощные операции с вашими данными. Мощность базы данных зависит от связи которую вы можете создать между фрагментами информации, а не от самого фрагмента информации.СВЯЗЫВАНИЕ ОДНОЙ ТАБЛИЦЫ С ДРУГОЙПозвольте нам использовать пример нашей адресной книги, чтобы начать обсуждение базы данных, которая может реально использоваться в деловой ситуации.Предположим, что персонажи в нашей первой таблице (адресной книги) — это пациенты больницы. В другой таблице, мы могли бы запомнить дополнительную информацию об этих пациентах. Столбцы второй таблицы могли бы быть помечены какПациент, Доктор, Страховка, и Баланс.ПациентFarishGrilletBrockДокторDrumeHalbenHalbenСтраховкаB.C./B.S.NoneHealth,Inc.Баланс$272.99$44.76$9077.47Много мощных функций можно выполнить извлекая информацию из этих таблицсогласно указанным параметрам, особенно когда эти параметры включают в себяфрагменты информации свзанные в различных таблицах друг с другом.

Например,возьмем — докторов. Предположим доктор Halben захотел получить номера телефонов всех своих пациентов. Чтобы извлечь эту информацию, он мог бы связать таблицус номерами телефонов пациентов (по адресной книге) с таблицей которая бы указывала, какой из пациентов — его. Хотя, в этом простом примере, он мог бы держать этов голове и сразу получать номера телефонов пациентов Grillet и Brock, эти таблицымогут быть слишком большими и слишком сложными. Программы реляционной базыданных разрабатывались для того чтобы обрабатывать большие и сложные совокупности данных такого типа, что очевидно является более универсальным методом вделовом мире. Даже если бы база данных больницы содержала сотни или тысячиимен — как это вероятно и бывает на практике — одна команда SQL могла бы выдатьдоктору Halben информацию в которой он нуждался почти немедленно.ПОРЯДОК СТРОК ПРОИЗВОЛЕНЧтобы поддерживать максимальную гибкость, строки таблицы, по определению,не должны находиться ни в каком определенном порядке.

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

По этойпричине, вы не можете просто сказать: "Мы хотим посмотреть пятую строку таблицы." Пренебрегая порядком в котором данные вводились или любым другим критерием, мы определим, не ту строку, хотя она и будет пятой. Строки таблицы которыерассматриваются, не будут в какой-либо определенной последовательности.ИДЕНТИФИКАЦИЯ СТРОК (ПЕРВИЧНЫЕ КЛЮЧИ)По этим и другим причинам, вы должны иметь столбец в вашей таблице которыйбы уникально идентифицировал каждую строку. Обычно, этот столбец содержит номер — например, номер пациента назначаемый каждому пациенту. Конечно, вы моглибы использовать имя пациентов, но возможно что имеется несколько Mary Smiths; и вэтом случае, вы не будете иметь другого способа чтобы отличить этих пациентов другот друга. Вот почему номера так необходимы.

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

Кроме того, первичные ключи гарантируют,что ваши данные имеют определенную целостность. Если первичный ключ правильноиспользуется и поддерживается, вы будете знать что нет пустых строк таблицы и чтокаждая строка отличается от любой другой строки. Мы будем обсуждать ключи и далее когда поговорим относительно справочной целостности в Главе 19.СТОЛБЦЫ ИМЕНУЮТСЯ И НУМЕРУЮТСЯВ отличие от строк, столбцы таблицы (также называемые полями) упорядочиваются и именуются. Таким образом, в нашей таблице адресной книги, возможно указать на "адрес столбца" или на "столбец 3". Конечно, это означает что каждый столбецданной таблицы должен иметь уникальное имя чтобы избежать неоднозначности.Лучше всего если эти имена указывают на содержание поля. В типовых таблицах этойкниги, мы будем использовать такие сокращения для имени столбца, как cname дляимени заказчика, и odate для даты порядка.

Мы также дадим каждой таблице личныйчисловой номер столбца в качестве первичного ключа. Следующий раздел будет объяснять эти таблицы и их ключи более подробно.ТИПОВАЯ БАЗА ДАННЫХТаблицы 1.1, 1.2, и 1.3 составляют реляционную базу данных которая являетсяминимально достаточной чтобы легко ее отслеживать, и достаточно полной, чтобыиллюстрировать главные понятия и практику использования SQL. Эти таблицы напечатаны в этой главе а также в Приложении E. Так как они будут использоваться дляиллюстрирования различных особенностей SQL по всей этой книге, мы рекомендуемчтобы вы скопировали их, для удобства ссылки к ним.Вы могли уже обратить внимание что первый столбец каждой таблицы содержитномера чьи значения различны для каждой строки.

Как вы наверное и предположили,это — первичные ключи таблиц. Некоторые из этих номеров также показаны в столбцах других таблиц. В этом нет ничего неверного. Они поазывают связь между строками которые используют значение принимаемое из первичного ключа, и строками гдеэто значение используется в самом первичном ключе.Таблица 1.1:ПродавцыSNUM10011002100410071003Таблица 1.2:CITYLondonSan JoseLondonBarcelonaNew YorkCOMM.12.13.11.15.10ЗаказчикиCNUM2001200220032004200620082007Таблица 1.3:SNAMEPeelSerresMotikaRifkinAxelrodCNAMEHoffmanGiovanniLiuGrassClemensCisnerosPereiraCITYLondonRomeSanJoseBerlinLondonSanJoseRomeRATING100200200300100300100SNUM1001100310021002100110071004ПорядкиONUM3001300330023005300630093007300830103011AMT18.69767.191900.105160.451098.161713.2375.754723.001309.959891.88ODATE10/03/199010/03/199010/03/199010/03/199010/03/199010/04/199010/04/199010/05/199010/06/199010/06/1990CNUM2008200120072003200820022004200620042006SNUM1007100110041002100710031002100110021001Например, поле snum в таблице Заказчиков указывает, какому продавцу назначен данный заказчик.

Номер поля snum связан с таблицей Продавцов, которая даетинформацию об этих продавцах. Очевидно, что продавец которому назначены заказчики должен уже существовать — то есть, значение snum из таблицы Заказчиковдолжно также быть представлено в таблице Продавцов. Если это так, то говорят, что"система находится в состоянии справочной целостности".

Этот вывод будетболее полно и формально объяснен в Главе 19.ПРИМЕЧАНИЕ: Эти три представленых таблицы в тексте имеют русские имена — Продавцов, Заказчиков и Порядков, и далее будут упоминаться именно под этими именами. Именалюбых других применяемых в книге таблиц будут написаны по английски чтобы отличать их отнаших базовых таблиц этой базы данных.

Кроме того в целях однозначности, имена заказчиков, продавцов, Системных Каталогов а также полей в тексте, также будут даны на латыни.Таблицы приведены как пример к похожей ситуации в реальной жизни, когда выбудете использовать SQL чтобы следить за продавцами, их заказчиками, и порядкамизаказчиков.