Содержание:
Содержание 2
- Реляционные
базы данных 3
Что такое
базы данных? 3
Первые модели
данных 3
Системы
управления
файлами 3
Иерархические
СУБД 4
Сетевые базы
данных 5
Реляционная
модель данных 7
Таблицы 8
Первичные
ключи 9
Отношения
предок/потомок 10
Внешние
ключи 11
Двенадцать
правил Кодда 12
- Язык
SQL
как стандартный
язык баз данных 14
Язык SQL 15
Роль
SQL 16
Достоинства
SQL 17
Независимость
от конкретных
СУБД 18
Переносимость
с одной вычислительной
системы
на другую 18
Стандарты
языка
SQL 18
Одобрение
SQL
компанией IBM
(DB2) 19
Протокол
ODBC
и компания
Microsoft 19
Реляционная
основа 19
Высокоуровневая
структура,
напоминающая
английский
язык 20
Интерактивные
запросы 20
Программный
доступ к базе
данных 20
Различные
представления
данных 20
Полноценный
язык для работы
с базами данных 20
Динамическое
определение
данных 21
Архитектура
клиент/сервер 21
- Стандарты
SQL 21
Стандарты
ANSI/ISO 21
Другие стандарты
SQL 22
ODBC и
консорциум
SQL Access Group 23
Миф о переносимости 23
- Влияние
SQL 25
SQL и
спецификация
SAA
компании IBM 25
SQL на
мини-компьютерах 26
SQL на системах
UNIX 26 SQL и обработка
транзакций 26
SQL на персональных
компьютерах 27
SQL в локальных
сетях 28
Список
использованной
литературы
30
Список
использованной
литературы:
"SQL
Полное
руководство"
BHV,
Киев, 1998
"Программирование
в среде СУБД
FoxPro
2.0"
Радио
и связь, Москва,
1993
"Эффективная
работа с Microsoft
Access 7.0"
Питер,
Санкт-Петербург,
1997
Санкт-Петербургский
Государственный
Технический
Университет
Факультет
Экономики и
Менеджмента
Кафедра
"Мировая Экономика"
РЕФЕРАТ
По Информатике
на тему:
"Реляционные
Базы Данных.
SQL -
стандартный
язык реляционных
баз данных"
Выполнил:
Егоров С. Н.
гр.2078/2
Проверил:
Первицкий А.
Ю.
Санкт-Петербург
1999
1. Реляционные
базы данных
Что
такое базы
данных?
В самом общем
смысле база
данных -
это набор записей
и файлов, организованных
специальным
образом. В
компьютере,
например, можно
хранить фамилии
и адреса друзей
или клиентов.
Один из типов
баз данных -
это документы,
набранные с
помощью текстовых
редакторов
и сгруппированные
по темам. Другой
тип - файлы
электронных
таблиц, объединяемые
в группы по
характеру их
использования.
Первые
модели данных
С ростом
популярности
СУБД в 70-80-х годах
появилось
множество
различных
моделей данных.
У каждой из них
имелись свои
достоинства
и недостатки,
которые сыграли
ключевую роль
в развитии
реляционной
модели данных,
появившейся
во многом благодаря
стремлению
упростить и
упорядочить
первые модели
данных.
Системы
управления
файлами.
До появления
СУБД все данные,
которые содержались
в компьютерной
системе постоянно,
хранились в
виде отдельных
файлов. Система
управления
файлами,
которая обычно
является частью
операционной
системы компьютера,
следила за
именами файлов
и местами их
расположения.
В системах
управления
файлами модели
данных, как
правило, не
использовались;
эти системы
ничего не знали
о внутреннем
содержимом
файлов. Для
такой системы
файл, содержащий
документ текстового
процессора,
ничем не отличается
от файла, содержащего
данные о начисленной
зарплате.
З
Рис 1.1. Приложение
для начисления
зарплаты,
использующее
систему управления
файлами.
Программа
для обновления
данных по служащим
ОСД
Программа
для начисления
зарплаты
ОСД
ОСД
Программа
для создания
отчетов по
служащим
ОСД
Рис. 1.1. Приложение
для начисления
зарплаты,
использующее
систему управления
файлами.
нание о содержимом
файла - какие
данные в нём
хранятся и
какова их структура
- было уделом
прикладных
программ,
использующих
этот файл, что
иллюстрирует
рис. 1.1. В приложении
для начисления
зарплаты каждая
из программ,
обрабатывающих
файл с информацией
о служащих,
содержит в себе
описание
структуры
данных
(ОСД), хранящихся
в этом файле.
Когда структура
данных изменялась
- например, в
случае добавления
нового элемента
данных для
каждого служащего,
- необходимо
было модифицировать
каждую из программ,
обращавшихся
к файлу. Со временем
количество
файлов и программ
росло, и на
сопровождение
существующих
приложений
приходилось
затрачивать
всё больше и
больше усилий,
что замедляло
разработку
новых приложений.
Проблемы
сопровождения
больших систем,
основанных
на файлах, привели
в конце 60-х годов
к появлению
СУБД. В основе
СУБД лежала
простая идея:
изъять из программ
определение
структуры
содержимого
файла и хранить
её вместе с
данными в базе
данных.
Иерархические
СУБД
Одной из
наиболее важных
сфер применения
первых СУБД
было планирование
производства
для компаний,
занимающихся
выпуском продукции.
Например, если
автомобильная
компания хотела
выпустить 10000
машин одной
модели и 5000 машин
другой модели,
ей необходимо
было знать,
сколько деталей
следует заказать
у своих поставщиков.
Чтобы ответить
на этот вопрос,
необходимо
определить,
из каких деталей
состоят эти
части и т.д.
Например, машина
состоит из
двигателя,
корпуса и ходовой
части; двигатель
состоит из
клапанов, цилиндров,
свеч и т.д. Работа
со списками
составных
частей была
как будто специально
предназначена
для компьютеров.
С
Рис 1.2. Иерархическая
база данных,
содержащая
информацию
о составных
частях
Записи
писок
составных
частей изделия
по своей природе
является
иерархической
структурой.
Для хранения
данных, имеющих
такую структуру,
была разработана
иерархическая
модель данных,
которую иллюстрирует
рис. 1.2.
В этой модели
каждая запись
базы данных
представляла
конкретную
деталь. Между
записями существовали
отношения
предок/потомок,
связывающие
каждую часть
с деталями,
входящими в
неё.
Чтобы получить
доступ к данным,
содержащимся
в базе данных,
программа
могла:
найти конкретную
деталь (правую
дверь) по её
номеру;
перейти
"вниз" к первому
потомку (ручка
двери);
перейти
"вверх" к предку
(корпус);
перейти "в
сторону" к
другому потомку
(правая дверь).
Таким образом,
для чтения
данных из
иерархической
базы данных
требовалось
перемещаться
по записям, за
один раз переходя
на одну запись
вверх, вниз или
в сторону.
Одной из
наиболее популярных
иерархических
СУБД была Information
Management System (IMS) компании
IBM,
появившаяся
в 1968 году. Ниже
перечислены
преимущества
IMS и реализованной
в ней иерархической
модели.
Простота
модели.
Принцип построения
IMS был легок
для понимания.
Иерархия базы
данных напоминала
структуру
компании или
генеалогическое
дерево.
Использование
отношений
предок/потомок.
СУБД IMS
позволяла
легко представлять
отношения
предок/потомок,
например: "А
является частью
В" или "А владеет
В".
Быстродействие.
В СУБД IMS
отношения
предок/потомок
были реализованы
в виде физических
указателей
из одной записи
на другую,
вследствие
чего перемещение
по базе данных
происходило
быстро. Поскольку
структура
данных в этой
СУБД отличалась
простотой, IMS
могла размещать
записи предков
и потомков на
диске рядом
друг с другом,
что позволяло
свести к минимуму
количество
операций
записи-чтения.
СУБД IMS
все ещё является
одной из наиболее
распространённых
СУБД для больших
ЭВМ компании
IBM.
Доля мэйнфреймов
этой компании,
на которых
используется
данная СУБД,
превышает 25%.
С
Клиенты
Служащие
Товары
етевые
базы данных
Е
Заказы
Рис. 1.3. Множественные
отношения
предок/потомок
сли структура
данных оказывалась
сложнее, чем
обычная иерархия,
простота
структуры
иерархической
базы данных
становилась
её недостатком.
Например, в
базе данных
для хранения
заказов один
заказ мог участвовать
в трёх различных
отношениях
предок/потомок,
связывающих
заказ с клиентом,
разместившим
его, со служащим,
принявшим его,
и с заказанным
товаром, что
иллюстрирует
рис. 1.3. Такие
структуры
данных не
соответствовали
строгой иерархии
IMS.
В связи с этим
для таких приложений,
как обработка
заказов, была
разработана
новая сетевая
модель данных.
Она являлась
улучшенной
иерархической
м
оделью,
в которой одна
запись могла
участвовать
в нескольких
отношениях
предок/потомок,
как показано
на рис. 1.4. В сетевой
модели такие
отношения
назывались
множествами.
В 1971 году на конференции
по языкам систем
данных был
опубликован
официальный
стандарт сетевых
баз данных,
который известен
как модель
CODASYL.
Компания IBM
не стала разрабатывать
собственную
сетевую СУБД
и вместо этого
продолжала
наращивать
возможность
IMS.
Но в 70-х годах
независимые
производители
программного
обеспечения
реализовали
сетевую модель
в таких продуктах,
как IDMS
компании Cullinet,
Total к
Рис.
1.4. Сетевая база
данных, содержащая
информацию
о заказах
Клиенты
Товары
Заказы
Записи
Множество
омпании
Cincom и
СУБД Adabas,
которые приобрели
большую популярность.
Сетевые базы
данных обладали
рядом преимуществ:
Гибкость.
Множественные
отношения
предок/потомок
позволяли
сетевой базе
данных хранить
данные, структура
которых была
сложнее простой
иерархии.
Стандартизация.
Появление
стандарта
CODASYL
популярность
сетевой модели,
а такие поставщики
мини-компьютеров,
как Digital
Equipment Corporation и Data
General, реализовали
сетевые СУБД.
Быстродействие.
Вопреки своей
большой сложности,
сетевые базы
данных достигали
быстродействия,
сравнимого
с быстродействием
иерархических
баз данных.
Множества были
представлены
указателями
на физические
записи данных,
и в некоторых
системах
администратор
мог задать
кластеризацию
данных на основе
множества
отношений.
Конечно, у
сетевых баз
данных были
недостатки.
Как и иерархические
базы данных,
сетевые базе
данных были
очень жесткими.
Наборы отношений
и структуру
записей приходилось
задавать наперёд.
Изменение
структуры базы
данных обычно
означало перестройку
всей базы данных.
Как иерархическая,
так и сетевая
база данных
были инструментами
программистов.
Чтобы получить
ответ на вопрос
типа "Какой
товар наиболее
часто заказывает
компания Acme
Manufacturing?", программисту
приходилось
писать программу
для навигации
по базе данных.
Реализация
пользовательских
запросов часто
затягивалась
на недели и
месяцы, и к моменту
появления
программы
информация,
которую она
предоставляла,
часто оказывалась
бесполезной.
Реляционная
модель данных
Недостатки
иерархической
и сетевой моделей
привели к появлению
новой, реляционной
модели данных,
созданной
Коддом в 1970 году
и вызвавшей
всеобщий интерес.
Реляционная
модель была
попыткой упростить
структуру базы
данных. В ней
отсутствовали
явные указатели
на предков и
потомков, а все
данные были
представлены
в виде простых
таблиц, разбитых
на строки и
столбцы. На
рис. 1.5. показана
реляционная
версия сетевой
базы данных,
содержащей
информацию
о заказах и
приведенной
на рис. 1.4.
К сожалению,
практическое
определение
понятия "реляционная
база данных"
оказалось
гораздо более
расплывчатым,
чем точное
математическое
определение,
данное этому
термину Коддом
в 1970 году. В первых
реляционных
СУБД не были
реализованы
некоторые из
ключевых частей
модели Кодда,
и этот пробел
был восполнен
только впоследствии.
По мере роста
популярности
реляционной
концепции
реляционными
стали называться
многие базы
данных, которые
на деле таковыми
не являлись.
Таблица
CUSTOMERS |
COMPANY
|
CUST_REP
|
CREDIT_LIMIT
|
JSP
Inc.
|
103
|
$50,000.00
|
First
Corp.
|
101
|
$65,000.00
|
Рис.
1.5. Реляционная
база данных,
содержащая
информацию
о заказах
В ответ на
неправильное
использование
термина "реляционный"
Кодд в 1985 году
написал статью,
где сформулировал
12 правил, которым
должна удовлетворять
любая база
данных, претендующая
на звание
реляционной.
С тех пор двенадцать
правил Кодда
считаются
определением
реляционной
СУБД. Однако
можно сформулировать
и более простое
определение:
Реляционной
называется
база данных,
в которой все
данные, доступные
пользователю,
организованны
в виде таблиц,
а все операции
над данными
сводятся к
операциям над
этими таблицами.
Приведенное
определение
не оставляет
места встроенным
указателям,
имеющимся в
иерархических
и сетевых СУБД.
Несмотря на
это, реляционная
СУБД также
способна реализовать
отношения
предок/потомок,
однако эти
отношения
представлены
исключительно
значениями
данных, содержащихся
в таблицах.
Таблицы
В
Таблица
OFFICES |
|
|
|
OFFICE
|
CITY
|
REGION
|
MGR
|
TARGET
|
SALES
|
22
|
Denver
|
Western
|
108
|
$300,000.00
|
$186,042.00
|
11
|
New
York
|
Easten
|
106
|
$575,000.00
|
$692,000.00
|
12
|
Chicago
|
Easten
|
104
|
$800,000.00
|
$739,000.00
|
13
|
Atlanta
|
Easten
|
105
|
$350,000.00
|
$735,157.00
|
21
|
Los
Angeles
|
Western
|
108
|
$725,000.00
|
$835,915.00
|
Город,
в котором расположен
офис
Идентификатор
служащего,
управляющего
офисом
Объём
продаж офиса
с начала года
Данные
об офисе в Нью-Йорке
Данные
об офисе в
Лос-Анджелесе
Рис.
1.6. Структура
реляционной
таблицы.
реляционной
базе данных
информация
организована
в виде таблиц,
разделённых
на строки и
столбцы, на
пересечении
которых содержатся
значения данных.
У каждой таблицы
имеется уникальное
имя, описывающее
её содержимое.
Более наглядно
структуру
таблицы иллюстрирует
рис 1.6., на котором
изображена
таблица OFFICES.
Каждая горизонтальная
строка
этой таблицы
представляет
отдельную
физическую
сущность - один
офис. Пять строк
таблицы вместе
представляют
все пять офисов
компании. Все
данные, содержащиеся
в конкретной
строке таблицы,
относятся к
офису, который
описывается
этой строкой.
Каждый вертикальный
столбец
таблицы OFFICES
представляет
один элемент
данных для
каждого из
офисов. Например,
в столбце CITY
содержатся
названия городов,
в которых расположены
офисы. В столбце
SALES
содержатся
объёмы продаж,
обеспечиваемые
офисами.
На пересечении
каждой строки
с каждым столбцом
таблицы содержится
в точности одно
значение данных.
Например, в
строке, представляющей
нью-йоркский
офис, в столбце
CITY
содержится
значение "New
York". В столбце
SALES
той же строки
содержится
значение
$692.000.000,
которое является
объёмом продаж
нью-йоркского
офиса с начала
года.
Все значения,
содержащиеся
в одном и том
же столбце,
являются данными
одного типа.
Например, в
столбце CITY
содержатся
только слова,
в столбце SALES
содержатся
денежные суммы,
а в столбце MGR
содержатся
целые числа,
представляющие
идентификаторы
служащих. Множество
значений, которые
могут содержаться
в столбце, называется
доменом
этого столбца.
Доменом столбца
CITY является
множество
названий городов.
Доменом столбца
SALES
является любая
денежная сумма.
Домен столбца
REGION состоит
всего из двух
значений, "Eastern"
и "Western",
поскольку у
компании всего
два торговых
региона.
У каждого
столбца в таблице
есть своё имя,
которое обычно
служит заголовком
столбца. Все
столбцы в одной
таблице должны
иметь уникальные
имена, однако
разрешается
присваивать
одинаковые
имена столбцам,
расположенным
в различных
таблицах. На
практике такие
имена столбцов,
как NAME,
ADDRESS, QTY, PRICE и SALES,
часто встречаются
в различных
таблицах одной
базы данных.
Столбцы
таблицы упорядочены
слева направо,
и их порядок
определяется
при создании
таблицы. В любой
таблице всегда
есть как минимум
один столбец.
В стандарте
ANSI/ISO
не указывается
максимально
допустимое
число столбцов
в таблице, однако
почти во всех
коммерческих
СУБД этот предел
существует
и обычно составляет
примерно 255
столбцов.
В отличие
от столбцов,
строки таблицы
не имеют определённого
порядка. Это
значит, что
если последовательно
выполнить два
одинаковых
запроса для
отображения
содержимого
таблицы, нет
гарантии, что
оба раза строки
будут перечислены
в одном и том
же порядке.
В таблице
может содержаться
любое количество
строк. Вполне
допустимо
существование
таблицы с нулевым
количеством
строк. Такая
таблица называется
пустой.
Пустая таблица
сохраняет
структуру,
определённую
её столбцами,
просто в ней
не содержится
данные. Стандарт
ANSI/ISO
не накладывает
ограничений
на количество
строк в таблице,
и во многих
СУБД размер
таблиц ограничен
лишь свободным
дисковым
пространством
компьютера.
В других СУБД
имеется максимальный
предел, однако
он весьма высок
- около двух
миллиардов
строк, а иногда
и больше.
Первичные
ключи
Поскольку
строки в реляционной
таблице не
упорядочены,
нельзя выбрать
строку по ее
номеру в таблице.
В таблице нет
"первой", "последней"
или "тринадцатой"
строки. Тогда
каким же образом
можно указать
в таблице конкретную
строку, например
строку для
офиса, расположенного
в Денвере?
В правильно
построенной
реляционной
базе данных
в каждой таблице
есть один или
несколько
столбцов, значения
в которых во
всех строках
разные. Этот
столбец (столбцы)
называется
первичным
ключом
таблицы. Давайте
вновь посмотрим
на базу данных,
показанную
на рис.
1.6. На первый
взгляд, первичным
ключом таблицы
OFFICES
могут служить
и столбец OFFICE,
и столбец
CITY.
Однако в
случае, если
компания будет
расширяться
и откроет в
каком-либо
городе второй
офис, столбец
CITY
больше не
сможет выполнять
роль первичного
ключа. На практике
в качестве
первичных
ключей таблиц
обычно следует
выбирать
идентификаторы,
такие как
идентификатор
офиса
(OFFICE
в таблице
OFFICES),
служащего
(EMPL_NUM
в таблице
SALESREPS)
и клиента
(CUST_NUM
в таблице
CUSTOMES).
А в случае;
с таблицей
ORDERS
выбора нет
— единственным
столбцом, содержащим
уникальные
значения, является
номер заказа
(ORDER_NUM).
Таблица
PRODUCTS,
фрагмент
которой показан
на рис.
1.7, является
примером таблицы,
в которой первичный
ключ представляет
собой комбинацию
столбцов. Такой
первичный ключ
называется
составным.
Столбец MRF_ID
содержит
идентификаторы
производителей
всех товаров,
перечисленных
в таблице, а
столбец
PRODUCT_ID
содержит
номера, присвоенные
товарам производителями.
Может показаться,
что столбец
PRODUCT_ID
мог бы
и один выполнять
роль первичного
ключа, однако
ничто не мешает
двум различным
производителям
присвоить своим
изделиям одинаковые
номера. Таким
образом, в качестве
первичного
ключа таблицы
PRODUCTS
необходимо
использовать
комбинацию
столбцов
MRF_ID
и
PRODUCT_ID.
Для каждого
из товаров,
содержащихся
в таблице, к
Таблица
PRODUCTS |
|
|
MFR_ID
|
PRODUCT_ID
|
DESCRIPTION
|
PRICE
|
QTY_ON_HAND
|
REI
|
2A45C
|
Ratchet
Link
|
$79.00
|
210
|
ACI
|
4100Y
|
Widget
Remover
|
$2,750.00
|
25
|
QSA
|
KX47
|
Reducer
|
$355.00
|
38
|
BIC
|
41672
|
Plate
|
$180.00
|
0
|
Первичный
ключ
Рис.
1.7. Пример таблицы
с составным
первичным
ключом
омбинация
значений в этих
столбцах будет
уникальной.
Первичный
ключ для каждой
строки таблицы
является уникальным,
поэтому в таблице
с первичным
ключом нет двух
совершенно
одинаковых
строк. Таблица,
в которой все
строки отличаются
друг от друга,
в математических
терминах называется
отношением.
Именно этому
термину реляционные
базы данных
и обязаны своим
названием,
поскольку в
их основе лежат
отношения
(таблицы с
отличающимися
друг от друга
строками).
Хотя первичные
ключи являются
важной частью
реляционной
модели данных,
в первых реляционных
СУБД
(System/R, DB2, Oracle и других)
не была обеспечена
явным образом
их поддержка.
Как правило,
проектировщики
базы данных
сами следили
за тем, чтобы
у всех таблиц
были первичные
ключи, однако
в самих СУБД
не было возможности
определить
для таблицы
первичный ключ.
И только в СУБД
DB2 Version
2, появившейся
в апреле 1988
года, компания
IBM реализовала
поддержку
первичных
ключей. После
этого подобная
поддержка была
добавлена в
стандарт
ANSI/ISO.
Отношения
предок/потомок
Одним из
отличий реляционной
модели от первых
моделей представления
данных было
то, что в ней
отсутствовали
явные указатели,
используемые
для реализации
отношений
предок/потомок
в иерархической
модели данных.
Однако вполне
очевидно, что
отношения
предок/потомок
существуют
и в реляционных
базах данных.
Например, в
нашей базе
данных каждый
из служащих
закреплен за
конкретным
офисом, поэтому
ясно, что между
строками
таблицы
OFFICES
и таблицы
SALESREPS
существует
отношение. Не
приводит ли
отсутствие
явных указателей
в реляционной
модели к потере
информации?
Как следует
из рис.
1.8, ответ
на этот вопрос
должен быть
отрицательным.
На рисунке
изображено
несколько строк
из таблиц
OFFICES
и
SALESREPS. Обратим
внимание на
то, что в столбце
REP_OFFICE таблицы
SALESREPS содержится
идентификатор
офиса, в котором
работает служащий.
Доменом этого
столбца (множеством
значений, которые
могут в нем
храниться)
является множество
идентификаторов
офисов, содержащихся
в столбце OFFICE
таблицы
OFFICES.
То, в каком
офисе работает
Мэри Джонс
(Магу Jones),
можно узнать,
определив
значение столбца
REP_OFFICE
в строке
таблицы
SALESREPS
для Мэри
Джонс (число
II) и затем
отыскав в таблице
OFFICES
строку с
таким же значением
в столбце
OFFICE
(это для
офиса в Нью-Йорке).
Таким же образом,
чтобы найти
всех служащих
нью-йоркского
офиса, следует
запомнить
значение столбца
OFFICE
для Нью-Йорка
(число
II), а потом
просмотреть
таблицу
SALESREPS
и найти все
строки, в столбце
REP_OFFICE
которых
содержится
число
11 (это строки
для Мэри Джонс
и С
Таблица
OFFICES |
|
OFFICE
|
CITY
|
REGION
|
22
|
Denver
|
Western
|
11
|
New
York
|
Eastern
|
12
|
Chicago
|
Eastern
|
Таблица
SALESREPS |
|
|
EMPL_NUM
|
NAME
|
AGE
|
REP_OFFICE
|
105
|
Bill
Adams
|
37
|
13
|
109
|
Mary
Jones
|
31
|
11
|
102
|
Sue
Smith
|
48
|
21
|
106
|
Sam
Clark
|
52
|
11
|
Рис.
1.8. Отношение
предок/потомок
в реляционной
базе данных
эма Кларка
(Sam Clark)).
Отношение
предок/потомок,
существующее
между офисами
и работающими
в них людьми,
в реляционной
модели не потеряно;
просто оно
реализовано
в виде одинаковых
значений данных,
хранящихся
в двух таблицах,
а не в виде явного
указателя. Все
отношения,
существующие
между таблицами
реляционной
базы данных,
реализуются
в таком виде.
Внешние
ключи
Столбец одной
таблицы, значения
в котором совпадают
со значениями
столбца, являющегося
первичным
ключом другой
таблицы, называется
внешним
ключом.
На рис.
4.9 столбец
REP_OFFICE
представляет
собой внешний
ключ для таблицы
OFFICES.
Значения,
содержащиеся
в этом столбце,
представляют
собой идентификаторы
офисов. Эти
значения
соответствуют
значениям в
столбце
OFFICE,
который
является первичным
ключом таблицы
OFFICES.
Совокупно
первичный и
внешний ключи
создают между
таблицами, в
которых они
содержатся,
такое же отношение
предок/потомок,
как и в иерархической
базе данных.
Внешний ключ,
как и первичный
ключ, тоже может
представлять
собой комбинацию
столбцов. На
практике внешний
ключ всегда
будет составным
(состоящим из
нескольких
столбцов), если
он ссылается
на составной
первичный ключ
в другой таблице.
Очевидно, что
количество
столбцов и их
типы данных
в первичном
и внешнем ключах
совпадают.
Если таблица
связана с несколькими
другими таблицами,
она может иметь
несколько
внешних ключей.
На рис.
1.9. показаны
три внешних
ключа таблицы
ORDERS
из учебной
базы данных:
столбец
REP
является
внешним ключом
для таблицы
SALESREPS
и связывает
каждый заказ
со служащим,
принявшим его;
столбец
CUST является
внешним ключом
для таблицы
CUSTOMES
и связывает
каждый заказ
с клиентом,
разместившим
его;
столбцы
MRF
и
PRODUCT
совокупно
представляют
собой составной
внешний ключ
для таблицы
PRODUCTS,
который
связывает
каждый заказ
с заказанным
товаром.
О
Таблица
CUSTOMERS |
CUST_NUM
|
COMPANY
|
… |
|
2117
|
J.P.
Sinclair
|
… |
|
Таблица
SALESREPS |
EMPL_NUM
|
NAME
|
… |
|
106
|
Sam
Clark
|
… |
|
Таблица
PRODUCTS |
|
MFR_ID
|
PRODUCT_ID
|
DESCRIPTION
|
… |
|
|
REI
|
2A44L
|
Left
Hinge
|
… |
|
|
Таблица
ORDERS |
|
|
|
|
ORDER_NUM
|
ORDER_DATE
|
CUST
|
REP
|
MFR
|
PRODUCT
|
… |
|
|
|
|
|
112967
|
17-DEC-89
|
2117
|
106
|
REI
|
2A44L
|
… |
|
|
|
|
|
Рис. 1.9. Множественные
отношения
предок/потомок
в реляционной
базе данных
тношения
предок/потомок,
созданные с
помощью трех
внешних ключей
в таблице
ORDERS,
могут показаться
знакомыми. И
действительно,
это те же
самые отношения,
что и в сетевой
базе данных,
представленной
на рис.
1.4. Как показывает
пример, реляционная
модель данных
обладает
всеми
возможностями
сетевой модели
по части выражения
сложных отношений.
Внешние ключи
являются неотъемлемой
частью реляционной
модели,
поскольку
реализуют
отношения между
таблицами базы
данных. К несчастью,
как и в случае
с первичными
ключами, поддержка
внешних ключей
отсутствовала
в первых реляционных
СУБД. Она была
введена в системе
DB2 Version 2
и теперь имеется
во всех коммерческих
СУБД.
Двенадцать
правил Кодда
В статье,
опубликованной
в журнале
"Computer World", Тэд
Кодд сформулировал
двенадцать
правил, которым
должна соответствовать
настоящая
реляционная
база данных.
Двенадцать
правил Кодда
приведены в
табл. 1.1.
Они являются
полуофициальным
определением
понятия реляционная
база данных.
Перечисленные
правила основаны
на теоретической
работе Кодда,
посвященной
реляционной
модели данных.
Таблица
1.1. Двенадцать
правил Кодда,
которым должна
соответствовать
_ реляционная
СУБД.
_
|
1. Правило
информации.
Вся информация
в базе данных
должна быть
предоставлена
исключительно
на логическом
уровне и только
одним способом
- в виде значений,
содержащихся
в таблицах.
|
2. Правило
гарантированного
доступа.
Логический
доступ ко всем
и каждому элементу
данных (атомарному
значению) в
реляционной
базе данных
должен обеспечиваться
путём использования
комбинации
имени таблицы,
первичного
ключа и имени
столбца.
|
3. Правило
поддержки
недействительных
значений.
В настоящей
реляционной
базе данных
должна быть
реализована
поддержка
недействительных
значений, которые
отличаются
от строки символов
нулевой длинны,
строки пробельных
символов, и
от нуля или
любого другого
числа и используются
для представления
отсутствующих
данных независимо
от типа этих
данных.
|
4. Правило
динамического
каталога,
основанного
на реляционной
модели.
Описание базы
данных на
логическом
уровне должно
быть представлено
в том же виде,
что и основные
данные, чтобы
пользователи,
обладающие
соответствующими
правами, могли
работать с
ним с помощью
того же реляционного
языка, который
они применяют
для работы с
основными
данными.
|
Правило
исчерпывающего
подъязыка
данных.
Реляционная
система может
поддерживать
различные
языки и режимы
взаимодействия
с пользователем
(например, режим
вопросов и
ответов). Однако
должен существовать
по крайней
мере один язык,
операторы
которого можно
представить
в виде строк
символов в
соответствии
с некоторым
четко определенным
синтаксисом
и который в
полной мере
поддерживает
следующие
элементы:
— определение
данных; —
определение
представлений; —
обработку
данных (интерактивную
и программную); —
условия целостности; —
идентификация
прав доступа; —
границы транзакций
(начало, завершение
и отмена).
|
6. Правило
обновления
представлений.
Все представления,
которые теоретически
можно обновить,
должны быть
доступны для
обновления.
|
7. Правило
добавления,
обновления
и удаления.
Возможность
работать с
отношением
как с одним
операндом
должна существовать
не только при
чтении данных,
но и при добавлении,
обновлении
и удалении
данных.
|
8. Правило
независимости
физических
данных.
Прикладные
программы и
утилиты для
работы с данными
должны на
логическом
уровне оставаться
нетронутыми
при любых
изменениях
способов хранения
данных или
методов доступа
к ним.
|
9. Правило
независимости
логических
данных.
Прикладные
программы и
утилиты для
работы с данными
должны на
логическом
уровне оставаться
нетронутыми
при внесении
в базовые таблицы
любых изменений,
которые теоретически
позволяют
сохранить
нетронутыми
содержащиеся
в этих таблицах
данные.
|
10. Правило
независимости
условий целостности.
Должна существовать
возможность
определять
условия целостности,
специфические
для конкретной
реляционной
базы данных,
на подъязыке
реляционной
базы данных
и хранить их
в каталоге,
а не в прикладной
программе.
|
11. Правило
независимости
распространения.
Реляционная
СУБД не должна
зависеть от
потребностей
конкретного
клиента.
|
12.
Правило
единственности.
Если в реляционной
системе есть
низкоуровневой
язык (обрабатывающий
одну запись
за один раз),
то должна
отсутствовать
возможность
использования
его для того,
чтобы обойти
правила и условия
целостности,
выраженные
на реляционном
языке высокого
уровня (обрабатывающем
несколько
записей за
один раз).
|
Правило
1 напоминает
неформальное
определение
реляционной
базы данных,
приведенное
ранее.
Правило
2 указывает
на роль первичных
ключей при
поиске информации
в базе данных.
Имя таблицы
позволяет найти
требуемую
таблицу, имя
столбца позволяет
найти требуемый
столбец, а первичный
ключ позволяет
найти строку,
содержащую
искомый элемент
данных.
Правило
3 требует,
чтобы отсутствующие
данные можно
было представить
с помощью
недействительных
значений
(NULL), которые
описаны в главе
5.
Правило
4 гласит,
что реляционная
база данных
|