Глушаков С.В., Ломотько Д.В. Базы данных

Подождите немного. Документ загружается.

Оргтехника принтеры, копиры

Средства связи телефоны, факсы

радиотелефоны

мобильные телефоны

ББК

32.97

Г 55

Серия «Учебный курс»

основана в 2002 году

Художник-оформитель

А. С. Юхтман

Издание осуществлено при участии

ООО «Стройинформцена»

г. Белгород

Глушаков С. В., Ломотько Д. В.

Г 55 Базы данных/Худож.-оформитель А. С. Юхт-

ман. — Харьков: Фолио; М.: ООО «Издательство ACT»,

2002. — 504 с. - (Учебный курс).

ISBN 966-03-1257-1.

В книге представлены теоретический и практический мате-

риал об управлении и структуре баз данных, рассмотрены ос-

новные приемы работы с ними при использовании языка за-

просов SQL.

Книга содержит также материал о конфигурировании и уп-

равлении сервера баз данных Microsoft SQL Server 7.0, о созда-

нии приложений «клиент-сервер» на примере различных про-

граммных средств.

Приводится много практических примеров и иллюстраций,

помогающих легче усвоить изложенный материал.

ББК 32.97

ISBN 966-03-1257-1

С. В. Глушаков, Д. В. Ломотько,

2001

А. С. Юхтман, художественное

оформление, 2001

ВВЕДЕНИЕ

Компьютерные системы, особенно в области коммуникаций и

хранения данных, развиваются несколько быстрее, чем осталь-

ные, потому что им приходится идти в ногу с технологическими и

социальными изменениями в мире. В связи с тем, что объемы

информации, подлежащей хранению, растут высокими темпами,

производители программного обеспечения вынуждены разраба-

тывать новые гибкие подходы к управлению большими объемами

данных.

Авторами данной книги была предпринята попытка предоста-

вить читателю обзор новых возможностей коллективной работы в

глобальных информационных системах. Эта книга предназначена

специально для пользователей и разработчиков приложений,

поставивших перед собой задачу изучения систем управления

реляционными базами данных. В книге рассмотрены три основ-

ных аспекта этой области.

В первой части книги представлена классическая теория

управления и организации баз данных. Здесь рассмотрены вопро-

сы, качающиеся специфики использования реляционных струк-

тур, проблем нормализации и манипуляции данными, контроля

целостности и разграничения доступа к информации.

Во второй части книги излагаются ключевые моменты исполь-

зования структурированного языка запросов SQL: создание про-

стых и вложенных запросов, добавления и изменения информа-

ции в базах данных, создания и модификации основных объектов

реляционных систем. Изложение материала построено на основе

большого количества примеров, с помощью которых описывают-

ся представленные вопросы.

В третьей части книги рассматриваются основные вопросы

использования сервера баз данных Microsoft SQL Server 7.0, с

помощью которого выполняются операции манипуляции данны-

ми, администрирования и управления ходом выполнения процес-

сов в системе, автоматизации резервного копирования и настрой-

ки доступа к информации. Отличительной чертой данной книги

является интересный материал об использовании вышеизложен-

ных методов работы с базами данных при разработке компьютер-

ных приложений. Здесь представлены возможности подключения

к SQL-серверу и использования языка запросов в различных ком-

пьютерных системах: Word, Excel, Access, Visual FoxPro, Visual

Basic, Visual C++, Internet, ASP.

Надеемся, что книга понравится читателю, и он по достоинст-

ву оценит ее.

Данная книга разработана преподавателями Харьковского ин-

ститута информационных технологий.

Мы будем рады Вашим отзывам и приглашаем Вас к сотруд-

ничеству в области обучения.

Телефоны: (0572) 21-28-72,20-69-20, 15-69-09

Адрес: 61050, Украина, г.Харьков, пер. Фейербаха 1/3.

E-mail: alcyon@xiit.kharkov.ua

ХАРЬКОВСКИЙ ИНСТИТУТ ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ

Предлагает платное ДИСТАНЦИОННОЕ ОБУЧЕНИЕ по специа-

лизированным курсам в области информационных технологий:

• Программирование на Visual Basic 6.0

• Программирование на Delphi

• Программирование на Java 2

Все курсы созданы на базе одноименных книг, выпущенных со-

вместно с издательством ФОЛИО. В комплект методического обес-

печения курса обучения входят: книжные пособия, система

управления на CD-ROM, регистрационная карточка.

Между слушателем и Институтом заключается договор на обучение.

По завершению процесса обучения Институтом выдается сертификат,

подтверждающий уровень знаний по изучаемому материалу.

За более подробной информацией следует обращаться:

Телефоны: (0572) 21-28-72, 20-69-20, 15-69-09

E-mail: alcyon@xiit kharkov. ua

ЧАСТЬ I

ТЕОРИЯ БАЗ ДАННЫХ

Глава 1.1

Введение в базы данных

Что такое база данных

В настоящее время жизнь человека настолько сильно на-

сыщена различного рода информацией, что для управления ек>

требуется создание огромного количества баз и банков данных

различного назначения. Сейчас практически любая задача свя-

зана с манипуляцией информацией и данными. По этой при-

чине в последние годы появилось множество различных ком-

пьютерных систем - систем управления базами данных - пред-

назначенных для этих целей.

Термины база данных (БД) и система управления базами дан-

ных (СУБД) чаще всего употребляются как относящиеся к ком-

пьютерам. Понятие БД можно применить к любой связанной ме-

жду собой по определенному признаку информации, хранимой и

организованной особым образом - как правило, в виде таблиц. По

сути, БД - это некоторое подобие электронной картотеки, элек-

тронного хранилища данных, которое хранится в компьютере в

виде одного или нескольких файлов. При этом возникает необхо-

димость в выполнении ряда операций с БД, в первую очередь это:

• добавление новой информации в существующие файлы БД;

• добавление новых пустых файлов в БД:

• изменение (модификация) информации в существующих

файлах БД:

• поиск информации в БД;

• удаление информации из существующих файлов БД:

• удаление файлов из БД.

Компьютеризированная информационная система представля-

ет собой программный комплекс, задачи которого состоят в под-

держке надежного хранения БД в компьютере, выполнении пре-

Часть I. Теория баз данных

образований информации и соответствующих вычислений, пре-

доставлении пользователям удобного и легко осваиваемого ин-

терфейса. Традиционно объемы информации, с которыми прихо-

дится иметь дело таким системам, довольно велики, а сами БД

имеют достаточно сложную структуру. Примерами информаци-

онных систем являются системы заказа железнодорожных или

авиационных билетов, банковские системы и многие другие.

В качестве иллюстрации рассмотрим небольшую БД, приве-

денную на рис. 1.1. в которой хранится информация о стипендии

студентов

Запись Е

K.OD

525122

525123

525124

525125

525126

525127

525128

525129

525130

525131

NAMb

Батракова И.Н.

Баулин А.В.

Белянжн Д. А.

Бондаренко О. В.

Зеленский ИВ.

Климова В.В.

Кричун ОБ.

Кузнецова В.В.

Нестреляй А.Н.

СаловаО.П.

UROUI'

5-4-УПП

BALL

4.5

«О

- ?«О

4.5

; 3.4

,4»

. 3.0

4с5

STIP

22.50

18.75

25.00

22.50

0.00

22.50

18.75

22.50

0.00

22.50

Поле

Рис. 1.1. Пример таблицы БД "Стипендия"

Данные о студентах записываются в таблицу, имеющую стро-

гую структуру данных. Информация внутри таблицы состоит из

полей, имеющих свое имя. В нашем примере - это поля, предна-

значенные для:

KOD - номер студенческого билета:

NAME - фамилия и инициалы студента;

GROUP - наименование учебной группы студента;

BALL - средний балл успеваемости студента;

STIP " .

- размер начисленной стипендии.

Каждую строку таблицы нужно рассматривать как запись, при

этом информация заносится в соответствующие поля. В то же

время все записи состоят из одинаковых полей, а характер ин-

формации для одного поля во всех записях одинаковый, но раз-

ные лоля имеют разный характер хранимых данных.

Основным назначением БД в первую очередь является быст-

рый поиск содержащейся в ней информации. При значительном

размере БД ручной поиск, а также модификация содержащейся

Глава 1.1. Введение в базы данных

информации занимает значительное время. Использование ком-

пьютера для ведения БД устраняет перечисленные выше пробле-

мы - поиск и выборка информации, ее модификация осуществля-

ются достаточно быстро и эффективно, а сама БД, состоящая из

тысяч записей, может легко уместиться на дискете.

Существует большое количество программ, которые предна-

значены для организации информации, помещения ее в таблицы

и манипуляции с нею - такие программы и получили название

СУБД. Основная особенность СУБД - это наличие средств для

ввода и хранения не только самих данных, но и описаний их

структуры.

Если говорить более детально, то к функциям СУБД относят

следующие:

управление данными непосредственно в БД - функция, обес-

печивающая хранение данных, непосредственно входящих в БД.

и служебной информация, обеспечивающей работу СУБД;

управление данными в памяти компьютера - функция, свя-

занная в первую очередь с тем, что СУБД работают с БД большо-

го размера. В целях ускорения работы СУБД используется буфе-

ризация данных в оперативной памяти компьютера. При этом

пользователь СУБД использует только необходимую для его

конкретной задачи часть БД, а при необходимости получает но-

вую "порцию" данных;

управление транзакциями - функция СУБД, которая произво-

дит ряд операций над БД, как над единым целым Как правило,

такие операции производятся в памяти компьютера. В первую

очередь транзакции необходимы для поддержания логической

целостности БД в многопользовательских системах. Если тран-

закция (манипуляция над данными) успешно выполняется, то

СУБД вносит соответствующие изменения в БД. В обратном слу-

чае ни одно из сделанных изменений никак не влияет на состоя-

ние БД;

управление изменениями в БД и протоколирование - функция,

связанная с надежностью хранения данных, то есть возможно-

стью СУБД восстанавливать состояние БД в аварийных ситуаци-

ях, например, при случайном выключении питания или сбое но-

сителя информации. Очевидно,, что для восстановления БД нужно

располагать дополнительной информацией, по которой и осуще-

ствляется восстановление. С этой целью ведется протокол изме-

нений БД, в который перед манипуляциями с данными делается

соответствующая запись. Для восстановления БД после сбоя

СУБД используется протокол и архивная копия БД - полная копия

БД к моменту начала заполнения протокола;

Часть I. Теория баз данных

поддержка языков БД - для работы с БД используются специ-

альные языки, в целом называемые языками баз данных. В СУБД

обычно поддерживается единый язык, содержащий все необхо-

димые средства - от создания БД до обеспечения пользователь-

ского интерфейса при работе с данными. Наиболее распростра-

ненным в настоящее время языком СУБД является язык SQL

(Structured Query Language).

(

настоящее время в большинстве БД используются реля-

ционные модели данных (о них поговорим ниже), однако для

начала кратко рассмотрим прочие основные модели данных, а

именно:

• модели, основанные на инвертированных списках;

• иерархические модели данных;

• сетевые модели данных.

• БД, организованная с помощью инвертированных спи-

сков, построена таким образом, что таблицы и пути

доступа к ним видны пользователям, при этом строки

таблиц физически упорядочены в некоторой последо-

вательности. В этих БД поддерживаются операторы,

устанавливающие адрес записи абсолютным (напри-

мер, первая запись, последняя запись таблицы) или от-

носительным образом (например, следующая за теку-

щей запись таблицы);

• операторы над адресуемыми записями.

БД, основанная на иерархической модели, состоит из упоря-

доченного набора деревьев. Каждое дерево состоит из одного

"корневого" (предок) и упорядоченного набора из нуля или более

связанных с ним поддеревьев (потомки). Целостность связи меж-

ду ними поддерживается автоматически.

В таких БД поддерживаются следующие операторы манипу-

лирования данными:

• найти дерево БД по заданному признаку;

• перейти от одного дерева к другому;

• перейти к записи внутри дерева или в порядке обхода ие-

рархии (сверху вниз, слева направо);

• вставить новую запись в указанную позицию.

• удалить текущую запись.

В БД с сетевой структурой данных поддеревья могут иметь

любое число корневых. Фактически сетевая БД состоит из набора

записей и множества связей между этими записями. Примерный

перечень операций для сетевых БД может быть следующим:

Глав» 1.1. Введение в базы данных

найти запись по заданному признаку;

перейти от предка к потомку по указанной связи;

перейти от потомка к предку по некоторой связи;

создать новую запись или удалить существующую;

модифицировать заданную запись;

включить в связь или исключить из связи;

переставить в другую связь.

Реляционные БД в настоящее время используются наиболее

широко, поэтому на этой модели данных мы остановимся под-

робнее чуть ниже.

Структура базы данных

Понятия архитектуры и структуры является одним из важ-

нейших в теории БД и служит основой для понимания возможно-

стей современных СУБД. Различают три уровня архитектуры БД:

• внутренний уровень - наиболее приближенный к физиче-

ской системе непосредственного хранения данных. Он

описывает, каким образом размещаются данные на уст-

ройствах хранения информации. Для традиционного

пользователя БД внутренний уровень, как правило, не-

доступен к просмотру и модификации;

• внешний уровень - связанный со способами представле-

ния данных непосредственно для пользователей. На

внешнем уровне пользователю предоставляется возмож-

ность манипуляции данными в СУБД с помощью специ-

ального языка. Такая ориентированность на конечного

пользователя делает БД независимой от физических па-

раметров среды хранения данных;

• концептуальный уровень - является переходным от внут-

реннего к внешнему уровням и, по сути, есть обобщенное

представление данных для множества пользователей. На

этом уровне содержание БД представляется в целом, в

отличие от внешнего уровня - где конкретные данные

представляются конкретному пользователю.

Очевидно, что структура БД не должна модифицироваться до

тех пор, пока изменения в реальном мире не потребуют соответ-

ствующей корректировки в ней для того, чтобы эта модель про-

должала соответствовать предметной области БД. Естественно,

что проектирование БД начинают с анализа предметной области

Часть I. Теория баз данных

и выявления требований к ней конечных пользователей. Проек-

тирование, как правило, поручается администратору базы дан-

ных (АБД) - человеку, хорошо знакомому с машинной обработ-

кой данных. Именно АБД определяет, какие именно данные бу-

дут храниться в процессе концептуального проектирования БД.

Объединяя требования будущих пользователей о содержимом

БД, АБД сначала создает обобщенное описание создаваемой БД с

использованием естественного языка, математических формул,

графиков и других средств. Только после формирования такого

обобщенного представления АБД приступает непосредственно к

формализации представления данных в БД.

В процессе проектирования АБД сталкиваете* с проблемой

управления передачей данных. Запросы к БД от конечных поль-

зователей должны происходить под управлением и контролем

специального программного компонента - диспетчера. Действи-

тельно, в общем случае рабочая станция пользователя от самой

БД может быть физически удалена на значительное расстояние.

Программа-диспетчер передачи данных не является частью

СУБД, а представляет собой отдельное приложение, функциони-

рующее совместно « согласовано.

Здесь возникает необходимость ввести понятие архитектура

клиент/сервер, которая предоставляет настоящую свободу выбо-

ра и согласования различных типов компонентов для клиента,

сервера и всех промежуточных звеньев. Правда, это ведет к ус-

ложнению системы.

Что же означает термин «архитектура клиент/сервер?» Осно-

вой такой системы является сервер БД, представляющий собой

приложение, осуществляющее комплекс действий по управлению

данными - выполнение запросов, хранение и резервное копиро-

вание данных, отслеживание целостности, проверку прав пользо-

вателей, ведение журнала транзакций. В качестве рабочего места

(клиента) при этом может быть использован обычный персональ-

ный компьютер, что позволяет не отказываться от привычной

рабочей ср%гды. '

Таким образом", информационная система построенная по

принципу клиент/сервер, состоит обычно из трех основных

компонентов:

• сервер БД, который и является собственно СУБД и

управляет хранением данных, доступом, защитой, ре-

зервным копированием, отслеживает целостность данных

и выполняет запросы клиента:

• клиенты, представляющие собой различные приложения

пользователей и выполняющие запросы к серверу, прове-

Глава 1.1. Введение в базы данных

ряющие допустимость данных и получающие ответы от

него;

• сеть и коммуникационное программное обеспечение,

осуществляющее взаимодействие между клиентом и сер-

вером с помощью сетевых протоколов.

В функции сервера БД входит не только непосредственное об-

служивание данных. Обязательно предусматриваются системы

блокировки и управления многопользовательским доступом,

элементы ограждения данных от несанкционированного доступа,

структуры оптимизации запросов к БД.

Кроме того, в задачи серверной части СУБД входит обеспече-

ние ссылочной целостности данных и контроль завершения

транзакций. Ссылочная целостность данных - это система и на-

бор специальных правил, обеспечивающих единство связанных

данных в БД. Контроль завершения транзакций - задача СУБД

по контролю и предупреждению повреждения данных в нештат-

ных ситуациях, например, при аппаратном сбое.

Эти функции реализуются при помощи хранимых процедур,

триггеров и правил. Хранимые процедуры - это набор особых

действий и манипуляций с данными, который хранится на серве-

ре, причем программы-клиенты способны их выполнять. Тригге-

ры - это вид хранимых процедур. Они связаны с событиями, и

запускаются автоматически, как только на сервере БД с данными

происходит такое событие. Правило - это такой тип триггера, ко-

торый проверяет данные до внесения их в БД.

В задачи коммуникационного программного обеспечения

входит в первую очередь обеспечение возможности программе-

клиенту быстро и легко подключиться к ресурсам сервера. Суще-

ствуют разнообразные варианты этого программного обеспече-

ния, но все они должны освобождать прикладные программы от

сложного взаимодействия с операционной системой, сетевыми

протоколами и серверами ресурсов.

В системах, построенных по принципу клиент/сервер, преоб-

ладают два типа архитектуры процессоров серверов: RISC и Intel.

RISC представляет собой традиционный вариант выбора для

Unix-серверов. Вообще говоря, RISC-серверы по производитель-

ности не намного превосходят серверы на базе Intel-процессоров,

но они стоят от 15 до 50 тысяч долларов.

Серверы на базе процессоров Intel сейчас быстро наращивают

вычислительную способность. С появлением процессора Pentium,

использующего RISC-подобную технологию, платформа Intel

приобретает все более широкую популярность. При этом многие

Часть I. Теория баз данных

современные операционные системы работают на Intel-машинах.

С учетом этого Unix уже уступает место Windows NT. в котором

широкие возможности Unix сочетаются с простотой использова-

ния Windows.

Коммуникационное программное обеспечение может быть,

например, в виде специального программного обеспечения,

которое осуществляет удаленный вызов сервисных функций

СУБД. Оно управляет передачей запроса и получением ре-

зультата, но не предлагает клиенту собственного интерфейса и

обработку данных на сервере - ведь это задача собственно

клиентской части.

Упрощенно архитектуру клиент/сервер можно представить в

виде схемы, приведенной на рис. 1.2.

Клиент 3

Рис. 1.2. Упрощенная схема СУБД в архитектуре клиент/сервер

Наиболее простой вид БД, построенной в архитектуре кли-

ент/сервер - это разделение вычислительной нагрузки между

двумя отдельными системами: клиентом и сервером. 6 принципе,

и клиентская, и серверная части могут физически находиться на

одном и том же компьютере, но большинство систем этой архи-

тектуры запускают клиентское приложение на одном компьюте-

ре, а приложение-сервер - на другом. Разумеется, для обмена ин-

формацией используется сеть и сетевое программное обеспече-

ние. При этом одно приложение может работать независимо от

другого, выполнять различные задания и разделять вычислитель-

ную нагрузку.

Глава 1.1. Введение в базы данных

Основные преимущества клиент/серверных по сравнению с

аналогичными информационными системами заключаются в сле-

дующем. Во-первых, это снижение количества передаваемой по

компьютерной сети информации. Это происходит потому, что,

скажем, при выборке из большой БД нескольких записей сервер

обрабатывает запрос и в качестве результата передает клиенту

только интересующую информацию, а не всю БД.

Во-вторых, преимуществом архитектуры клиент/сервер явля-

ется возможность хранения правил доступа и обработки на сер-

вере, что позволяет избежать дублирования кода в различных

приложениях, использующих общую БД. Кроме того, любая ма-

нипуляция с данными может быть произведена только в рамках

этих правил. Часть кода, связанного с обработкой данных, как

правило, реализуется в виде хранимых процедур сервера, что по-

зволяет еще более ускорить работу клиентского приложения за

счет уменьшения его размеров, а это в свою очередь означает, что

требования к рабочим станциям могут быть не такими высокими.

Это в конечном итоге снижает общую стоимость информацион-

ной системы даже при использовании дорогостоящей СУБД и

мощного сервера БД.

В третьих, современные СУБД, реализованные на платфор-

ме клиент/сервер, обладают мощными возможностями управ-

ления доступа к элементам БД, резервного копирования, архи-

вации и параллельной обработки данных, что значительно

улучшает работу.

Используя множество компьютеров, системы на платформе

клиент/сервер распределяют прикладную задачу по различным

рабочим станциям и серверам. Каждый элемент при этом берет

на себя свою часть вычислительной нагрузки, используя инфор-

мацию совместно с другими компьютерами сети, при этом мощ-

ность системы повышается без наращивания производительности

одного отдельного компьютера, а получается как результат сум-

мирования возможностей многих. Помимо всего, архитектура

клиент/сервер является технологией, предоставляющей большую

самостоятельность пользователям и возможность проявления

творчества в создании клиентских приложений.

Традиционно в клиент/серверных системах используются два

звена - клиент и сервер. При таком построении большую про-

граммную нагрузку несет на себе клиентская часть, а сервер в

основном используют для обслуживания данных. Двухзвенные

системы получаются достаточно простыми в .построении и об-

служивании, но такую модель невозможно нарастить для совме-

стной работы тысяч пользователей.

Часть I. Теория баз данных

Для обеспечения работы при больших вычислительных на-

грузках используется трех- или многозвенная архитектура, что

влечет за собой распределение системы по дополнительным

звеньям, обеспечивающим дополнительную вычислительную

мощность. Получившаяся мощная вычислительная система, к

сожалению, обладает повышенной сложностью, а при ее созда-

нии разработчики затрачивают больше времени.

Глава 1.2

Реляционная модель базы данных

Реляционные модели данных, как уже было сказано, в на-

стоящее время приобрели наибольшую популярность и практиче-

ски все современные СУБД ориентированны именно на такое

представление данных.

Реляционную модель можно представить как особый метод

рассмотрения данных, содержащий и собственно данные (в виде

таблиц), и способы работы и манипуляции с ними (в виде связей).

Реляционная модель предполагает три концептуальных элемента:

структура, целостность и обработка данных, как. впрочем, и

большинство нереляционных моделей. В этих элементах есть

свои специальные понятия, которые для дальнейшего изложения

необходимо кратко пояснить.

Таблица рассматривается как непосредственное «хранилище»

данных. Традиционно в реляционных системах таблицу называ-

ют отношением. Строку таблшщ называют кортежем, а столбец

- атрибутом. При этом атрибуты имеют уникальные (в пределах

отношения) имена. Количество кортежей в таблице называют

кардинальным числом, а количество атрибутов - степенью. Для

отношения предусматривают уникальный идентификатор, то есть

один или несколько атрибутов, значения которых в одно и то же

время не бывают одинаковыми.- идентификатор называют пер-

вичным ключом. Домен - это множество допустимых однородных

значений для того или щого атрибута. Таким образом, домен

можно рассмотреть как именованное множество данных, причем

составные части этого множества являются логически недели-

мыми единицами (в качестве домена могут выступать, например,

перечень фамилий сотрудников учреждения, однако не все фами-

лии могут присутствовать в таблице).

Отношение содержит две части - заголовок и собственно

содержательную часть. Заголовок содержит конечное множество

атрибутов, а содержательная часть (тело отношения) - множество

Глава 1.2. Реляционная модель базы данных

пар имени атрибута и его значения. Например, на рис. 1.3 KOD,

NAME и SUMM, содержащиеся в заголовке, являются атрибута-

ми, а скажем, пары SUMM - 25.50 или KOD - 5216 являются эле-

ментами тела отношения.

KOD

5216

5217

NAME

Парсов В.Ф.

Кесарева Н.В.

SUMM

25.50

17.05

а.

Атрибуты

Первичный ключ

Рис. 1.3. Пояснение понятий реляционных БД

В реляционных БД, в отличие от Других моделей, пользова-

тель указывает, какие данные для него необходимы, а не то, как

это делать. По этой причине процесс перемещения и навигации

по БД в реляционных системах является автоматическим, а эту

задачу в таких СУБД выполняет так называемый оптимизатор.

Его работа заключается, например, в том, чтобы наиболее эффек-

тивным способом произвести выборку данных из БД по запросу.

Таким образом, оптимизатор, по крайней мере, должен суметь

определить, из каких таблиц выбираются данные, насколько мно-

го информации в этих таблицах, каков физический порядок запи-

сей в таблицах и как они сгруппированы и. т. д.

Кроме того, реляционная СУБД выполняет и функции ката-

лога. В каталоге хранятся описания всех объектов, из которых

состоит БД - таблиц, индексов, триггеров и т. п. Очевидно, что

это жизненно необходимо для правильной работы всей системы -

так, например, оптимизатор использует в своей работе информа-

цию, хранящуюся в каталоге. Интересен тот факт, что каталог

сам является набором таблиц, поэтому СУБД может манипулиро-

вать ими традициснными средствами, не прибегая к каким-то

особым приемам и методам.

Часть I. Теория баз данных

Домены и отношения

Основные определения: домены; виды отношений', предикаты.

Отношения имеют ряд основных свойств, а именно:

• в самом общем случае в отношении не бывает двух оди-

наковых кортежей. Это следует из самого определения

отношения, однако для некоторых СУБД в ряде случаев

допускается отступление от этого свойства. Действитель-

но, поскольку в отношении имеет место первичный ключ,

то одинаковые кортежи исключены;

• кортежи не упорядочены сверху вниз - в отношении про-

сто отсутствует понятие позиционного номера. В отно-

шении без потери информации можно с успехом распо-

ложить кортежи в любом порядке;

• атрибуты не упорядочены слева направо - атрибуты в за-

головке отношения можно располагать в любом порядке,

при этом целостность данных не нарушается. Поэтому

понятия позиционного номера в отношении атрибута то-

же не существует;

• значения атрибутов состоят из логически неделимых

единиц - это свойство есть следствие того, что значения

берутся из доменов. Иначе, можно сказать, что отноше-

ния не содержат групп повторения, то есть являются

нормализованными (о чем мы будем говорить ниже).

В реляционных системах поддерживаются несколько видов

отношений.

Именованное - представляет собой переменное отношение,

определяемое в СУБД путем операторов создания и, как правило,

необходимое для более удобного представления информации для

пользователя.

Базовое отношение - являющееся непосредственной важной

частью БД, поэтому при проектировании им дают собственное

наименование.

Производное отношение - то, которое было определено через

другие (как правило, базовые) отношения путем использования

средств СУБД.

Представление - фактически является именованным произ-

водным- отношением, при этом представление выражается ис-

ключительно через операторы СУБД, примененные к именован-

ным отношениям, поэтому их физически в БД не существует.

Глава 1.2. Реляционная модель базы данных

Результат запроса - это неименованное производное отно-

шение, содержащее данные - результат конкретного запроса. Ре-

зультат запроса в БД не хранится, а существует только до тех

пор, пока он необходим пользователю.

Хранимое отношение - то, которое физически поддерживается

в памяти компьютера. К хранимым, в большинстве случаев, от-

носятся базовые отношения.

Исходя из вышесказанного, можно теперь определить

реляционную БД как набор отношений, связанных между собой.

Связь в данном случае - это ассоциирование двух или более

отношений. БД, не имеющая связей между отношениями, имеет

очень простую структуру и в полной мере реляционной назы-

ваться не может. Однако одно из основных требований к органи-

зации реляционной БД - это обеспечение возможности поиска

одних кортежей по значениям других, для чего необходимо уста-

новить между ними связи. А так как в реальных информацион-

ных системах часто содержатся тысячи кортежей, то теоретиче-

ски между ними может быть установлено более миллиона связей.

Наличие такого множества связей и определяет сложность реля-

ционных моделей БД. Существуют следующие основные виды

связей:

• один к одному;

• один ко многим;

• многие к одному;

• многие ко многим.

Связь "один к одному" предполагает, что в каждый момент

времени каждому элементу (кортежу) А соответствует 0 или 1

элементов (кортежей) В (см. рис. 1.4). Например, работник полу-

чает зарплату, и только одну.

Рис. 1.4. Связь "один к одному"

Часть I, Теория баз данных

Связь "один ко многим" состоит в том, что в каждый момент

времени каждому элементу (кортежу) А соответствует несколько

элементов (кортежей) В (см. рис. 1.5). В качестве примера можно

сказать, что в доме проживает много жильцов.

Я!

°° т.

| *

Дом

«шнммяяш

«1 со

Жильцы

*##

Рис. 1.5. Связь "один ко многим"

Связь "многие к одному" предполагает, что в каждый момент

времени множеству элементов А соответствует 1 элемент В. На-

пример, несколько студентов представляют собой студенческую

учебную группу (см. рис. 1.6).

Студенты

МИНИН

Группа

Журнал

Рис. 1.6. Связь "многие к одному"

Наконец, связь "многие ко многим" состоит в том, что в каж-

дый момент времени множеству элементов А соответствует мно-

жество элементов В (см. рис. 1.7). К сожалению, этот тип связи в

реляционных БД непосредственно -не поддерживается. Примером

Глава 1.2. Реляционная модель базы данных

такой связи может служить тот факт, что у студентов учебные

занятия по дисциплинам ведут множество преподавателей.

•••-

Студенты

Преподаватели

со

Рис. 1.7. Связь "многие ко многим"

Помимо вышеперечисленных, еще могут существовать мно-

жественные связи между одними и теми же элементами, тренар-

ные связи (см. рис. 1.8), которые, впрочем, могут быть выражены

через уже рассмотренные.

— занятия

Студенты

Преподаватели

научное руководство-

Рис. 1.8. Множественные и тренарные связи