Иванов Д.Н. Введение в реляционные базы данных / Иванов Д.Н. Введение в реляционные базы данных

ББК32.973.26-018.2я73 В24

Печатается по решению кафедры информатики АлтГУ

Рецензенты:

профессор кафедры прикладной математики АГТУ

Е.Н Крючкова

Алтайский

госуниверситет

БИБЛИОТЕКА

В24 Введение в реляционные базы данных: Учеб. пособие по курсу «Базы данных». - Барнаул: Изд-во Алт. ун-та, 2003.-43 с.

Данное учебное пособие подготовлено по материалам лекций по теории баз данных, читавшихся студентам математического факультета Алтайского государственного факультета. Главная задача пособия - дать начальный уровень знаний по основным положениям теории баз данных и помочь освоить практические методы и подходы к проектированию и созданию баз данных. Пособие предназначено ДЛЯ студентов младших курсов вузов, начинаюих изучать дисциплину «Базы данных».

© Иванов Д.Н., 2003 © Алтайский государственный университет, 2003

Предисловие

Практически любая информационная система требует эффективную и надежную технологию долговременного хранения и обработки информации. Поэтому такая область информатики, как системы баз данных является обя­ зательным предметом изучения студентами, специализирующихся в различ­ ных областях информационных технологий. Учебная дисциплина «Базы дан­ ных» включена в стандарты специальностей, связанных с подготовкой спе­ циалистов по вычислительной технике, а раздел, посвященный базам данных, включен в общий курс информатики всех специальностей.

Данное учебное пособие подготовлено по материалам лекций по теории баз данных, читавшихся студентам математического факультета Алтайского государственного факультета. Главная задача пособия - дать начальный уро­ вень знаний по основным положениям теории баз данных и помочь освоить практические методы и подходы к проектированию и созданию баз данных. Пособие предназначено для студентов младших курсов вузов, начинающих изучать дисциплину «Базы данных».

В первой главе в сжатом виде изложены основные положения теории баз данных, которые помогут ориентироваться в терминологии, понять ос­ новные концепции хранения, обработки и защиты информации от нарушения логической целостности. Рассмотрены реляционная модель данных, которая лежит в основе практически всех современных систем управления баз дан­ ных (СУБД), и реляционное исчисление, на основе которого построен стан­ дартный язык манипулирования данными SQL.

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

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

Раздел упражнений для самостоятельной работы содержит темы задач различных уровней сложности для практического закрепления полученных знаний. В пособии не рассматриваются конкретные программные продукты реляционных СУБД, которые можно применить для решения задач. Такие продукты предлагаются студентам для самостоятельного освоения.

Введение

База данных в узком смысле может рассматриваться как некоторое автоматизированное хранилище необходимых для работы наборов данных. Однако абстрактное понятие «данные», как отражение объектов реального мира, в процессе разработки конкретного файла базы данных требует уточнения - какими свойствами наделен исследуемый объект, какие значения могут при­ нимать свойства объекта, какие действия допустимы с этим объектом, как этот объект связан с другими объектами. Без ответов на эти вопросы разраба­ тываемая база данных порождает массу проблем, которые впоследствии ска­ зываются на эффективности работы системы в целом, а также на достоверно­ сти результатов. Одна из самых распространенных проблем - это избыточ­ ность, возникающая при хранении одних и тех же данных в разных файлах. Избыточность приводит к .дублированию описания свойств объекта, и, как следствие, его неоднозначности и противоречивости. Несогласованность в описании объекта может привести к аномалиям обновления значений свойств, а также к напрасной работе по наполнению базы данных. Таким образом, отвечая на поставленные вопросы, данные обретают свою структуру, кото­ рая не ограничивается описанием физических объектов реального мира.

В традиционной терминологии объекты реального мира, сведения о ко­ торых хранятся в базе данных, принято называть сущностями {entity), а их свойства - атрибутами {attribute). Так, физический объект «Деталь» может обладать свойствами «Название», «Вес». Но в базе данных может храниться информация о заказах детали, что является процессом, а не физическим объ­ ектом. Кроме того, сущность «Заказ» может обладать своими собственными свойствами «Срок поставки», «Количество», «Поставщик».

Объекты реального мира имеют друг с другом множество сложных свя­ зей и зависимостей. База данных должна содержать описание значимых {пря­ мых) связей. Можно определить прямые связи между сущностями «Деталь» и «Поставщик», «Деталь» и «Производитель». С другой стороны, сущности «Поставщик» и «Производитель» зависимы друг от друга, но это всего лишь косвенная связь посредством сущности «Заказ». Отсутствие описаний связей может привести к нарушению логической целостности данных. Например, можно оформить заказ таких деталей, которые не выпускаются ни одним производителем.

Таким образом, в широком смысле слова, база данных теперь представ­ ляется как совокупность описаний объектов реального мира, связей между ними и хранилище соответствующих значений.

Глава 1. Основы теории реляционных баз данных

1.1. Системы баз данных

Задачи по доступу к данным и выполнению допустимых операций над ними решаются системами баз данных. Основные функции по поиску, до­ бавлению, обновлению и удалению данных согласно правилам и ограничени­ ям, описанным структурой базы данных, возлагаются на уровень программ­ ного обеспечения системы баз данных - систему управления базами данных {СУБД, Database Management System, DBMS), которая обеспечивает следую­ щие возможности:

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

-Способность поддерживать разнообразные представления {view) од­ них и тех же данных.

-Управление многопользовательским доступом к данным.

-Гарантия безопасности - защита от несанкционированного доступа и обеспечение целостности данных.

Система баз данных состоит из следующих компонентов:

1.Пользователи. Люди, использующие данные.

2.Приложения. Прикладные программы пользователей, обеспечи­ вающие возможность пользователям манипулировать представле­ ниями данных.

3.СУБД. Программное обеспечение системы баз данных.

4.Данные. Физическая реализация СУБД по хранению информации.

5.Аппаратное обеспечение.

1.2.Модели данных

Модель данных имеет первостепенное значение и является фундамен­ том всех существующих СУБД. Модель данных - это формальная конструк­ ция, служащая для представления информации об окружающем мире. В рам­ ках модели данных принято рассматривать три компонента:

-Структура данных.

-Целостность данных.

-Манипуляция данными.

В теории баз данных определены четыре традиционные модели данных, используемых при проектировании СУБД.

Иерархическая модель данных была предложена в 1968 году компанией IBM. Данные модели представлены в виде упорядоченного набора деревьев, где дерево - структура данных, в которой каждая запись данных связана только с одной записью-предком и произвольным набором записейпотомков.

Сетевая модель данных была создана в 1971 году рабочей группой Da­ tabase Task Group Конференции по языкам и системам данных (Conference On Data Systems Languages, CODASYL). Сетевая модель является, по сути, мо­ дификацией иерархической модели, где появилась возможность связывания одной записи-потомка с произвольным набором записей-предков.

Реляционная модель данных впервые была сформулирована Э. Ф. Коддом (Codd E.F.) в 1970 году. Она существенно отличалась от описанных ра­ нее моделей и в 80-х годах получила всеобщее признание как наиболее со­ гласованная и удобная модель разработки СУБД. В реляционной модели данные представляются в виде таблиц, состоящих из строк и столбцов. Связь между данными осуществляется не с помощью явных указателей, как в сете­ вой модели, а С помощью значений одного или нескольких столбцов связан­ ных таблиц.

Объектно-ориентированная модель призвана устранить некоторые не­ достатки реляционной модели, связанные с идеей представления данных в виде некоторого пассивного множества, где нет средств моделирования ре­ ального поведения данных. Кроме того, весьма ограниченные семантические ВОЗМОЖНОСТИ описания данных реляционной модели затрудняют понимание действительного смысла данных. Так, например, операция оформления зака­ за деталей требует проверки наличия соответствующего количества деталей у производителя, что можно реализовать в реляционной базе данных путем написания специальной автоматически вызываемой СУБД процедуры {триг­ гера). В объектно-ориентированной базе данных такая операция может быть составной частью определения данных. В настоящее время, не смотря на все попытки стандартизации, объектно-ориентированная модель данных не име­ ет такого четкого определения, как реляционная модель. Отсюда возникают различные способы реализации объектно-ориентированных СУБД. Поэтому потенциальные пользователи СУБД, знакомые с реляционным подходом и однородным составом программных продуктов, не спешат переходить к объ­ ектно-ориентированным системам, хотя ряд реляционных продуктов уже снабжен объектно-ориентированными технологиями.

1.3, Реляционная модель данных

Внастоящее время на рынке СУБД преобладают программные продук­ ты, построенные на реляционных технологиях. Реляционная модель данных имеет строгое теоретическое обоснование по каждому компоненту - струк­ туре данных, целостности данных и манипуляции данными.

1.3.1.Структура реляционных данных

Вреляционной базе данных информация хранится в двумерной таблице, которая называется отношением. Каждая строка отношения называется кор­ тежем, каждый столбец отношения - атрибутом. В терминологии СУБД строка и столбец называются соответственно записью и полем. Количество

6

атрибутов определяет степень отношения, а количество кортежей - карди­ нальность отношения. Каждое отношение содержит тело и заголовок. Заго­ ловок состоит из имени отношения и имен атрибутов, которые составляют данное отношение. Имя отношения должно быть уникальным в системе, имя атрибута должно быть уникальным в данном отношении. Тело отношения состоит из неупорядоченного набора кортежей. Значение атрибута в каждом кортеже должно удовлетворять условию атомарности, т.е. на пересечении строки и столбца может находиться единственное значение, а не набор. От­ ношение, удовлетворяющее условию атомарности, называется нормализован­ ным.

Таким образом, реляционной базой данной можно назвать набор норма­ лизованных отношений разной степени.

1.3.2. Целостность реляционных данных

Целостность данных в реляционной системе обеспечивается набором определенных ограничений на значения атрибутов и концепцией ключей.

Домен {domain) определяет набор допустимых значений, которые может принимать атрибут. В узком смысле понятие домен близко к понятию тип данных, принятый в программировании. Как и тип данных, домен определяет не только множество допустимых значений, но и допустимые операции для каждого типа (например, сложение чисел, конкатенация строк и т.д.). Однако, идея, заложенная в понятие «домен», намного шире, чем понятие «тип дан­ ных» и может трактоваться как семантика значения атрибута или как природа данных. Например, для представления роста человека можно использовать домен «Рост», а для показателей веса - домен «Вес». Оба домена могут быть представлены числовым типом данных, но операции, например, сложения и сравнения для значений этих двух доменов будут бессмысленны. В теории реляционных баз данных в определении отношения всегда указывается имя атрибута и его домен, что является необходимым условием. Поэтому, каждое значение, присваиваемое атрибуту должно соответствовать его домену. В рамках одного отношения допустимо использование нескольких атрибутов, определенных на одном и том же домене. К сожалению, ни один программ­ ный продукт, выпущенный на рынок реляционных СУБД в настоящее время, не поддерживает домены в полном его смысле в связи со сложностью форма­ лизации этого понятия на программном уровне. Взамен доменов современ­ ные реляционные СУБД предлагают дополнительные ограничения на атри­ буты на основе базовых типов данных, например, диапазон допустимых це­ лочисленных значений от 0 до 300, строки длиной в 25 символов и т.д. В не­ которых СУБД существует возможность создания пользовательских типов данных основанных на базовых типах, что можно рассматривать как некото­ рую замену доменам.

Null-значения определяют отсутствие значения. Потребность в неопре­ деленном значении атрибута возникает, когда, например, база данных созда-

7

ется на основе информации, не обладающей полными сведениями о какой либо сущности. Так, если в базе данных хранится информация о картинах, то вполне вероятно в коллекции может существовать картина неизвестного ху­ дожника. В этом случает атрибут «Автор» отношения «Картина» должен принимать Null-значения, а не строковое значение «Неизвестен», так как это значение системой может быть распознано как имя художника. Таким обра­ зом, в определении отношения кроме домена для каждого атрибута также необходимо указать допустимость Null-значений. Существуют определенные причины, требующие минимизации использования Null-значений для обес­ печения целостности данных, которые будут рассмотрены ниже.

Потенциальный ключ (candidate key) - это атрибут или набор атрибутов, которые можно использовать для уникальной идентификации кортежей от­ ношения. В реляционной модели данных всякое отношение обладает свойст­ вом уникальности кортежей. Реализация этого свойства возложена на систе­ му потенциальных ключей, причем в одном отношении может быть опреде­ лено несколько потенциальных ключей, каждый из которых имеет собствен­ ное множество уникальных значений. Любой потенциальный ключ не может содержать атрибуты с Nullзначениями.

Первичный ключ (primary key) обычно выбирается среди потенциальных ключей и может быть определен в отношении только в единственном числе. Условно первичный ключ можно назвать «главным» потенциальным ключом отношения.

Внешний ключ (foreign key) определяет связи отношений по значениям определенного атрибута или нескольких атрибутов. Если в отношении А есть потенциальный ключ СК, то в отношении В можно определить внешний ключ FK, значения которого в каждом кортеже должны соответствовать од­ ному из значений всех кортежей потенциального ключа СК отношения А. Причем количество атрибутов, входящих в состав внешнего ключа FK долж­ но соответствовать количеству атрибутов потенциального ключа СК, а каж­ дый атрибут внешнего ключа должен быть определен на том же домене, что и соответствующий атрибут потенциального ключа. Заметим, что имена ат­ рибутов не обязательно должны совпадать. Этот процесс называет заданием связи между отношениями А и В. Схематично такая связь выражается как В—>А. Реляционная модель допускает связь атрибутов внутри отношения как A(X)—>A(Y), где X и Г - атрибуты внешнего ключа и потенциального ключа соответственно, которые определены на одном домене. Связь вида R1 —> R2

->... —>• Rn называется ссылочным путем, а связь Rt —> R2 —> ... —> Rn —>R1 явля­ ется ссылочным циклом.

При использовании системы внешних ключей возникает понятие ссы­ лочной целостности. Реляционная СУБД должна гарантировать целостность данных при удалении кортежей или модификации значений атрибутов, вхо­ дящих в состав потенциального ключа, для которого определены один или несколько внешних ключей. Что должно произойти, если, например, из от-

ношения «Автор» будет удален кортеж, содержащий информацию о худож­ нике, а в отношении «Картины» существует несколько кортежей с информа­ цией о картинах этого художника? Существует три типа соблюдения ссылоч­ ной целостности, один из которых должен быть указан при создании внешне­ го ключа в отношении «Картины»:

-Ограничение. СУБД запрещает удаление кортежа, если существуют соответствующие ссылки на значения потенциального ключа этого кортежа из других отношений.

-Каскадирование. Этот вариант предусматривает предварительно уда­ ление всех кортежей, содержащих соответствующие значения внешнего ключа ссылающихся отношений, а затем удаление и самого требуемого кор­ тежа.

-Присвоение Null-значения. В этом случае все значения внешнего ключа ссылающихся отношений заменяются Null-значениями,

Необходимо отметить, что никаких ограничений не накладывается на удаление кортежей, содержащих значения внешнего ключа.

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

1.33. Реляционная база данных

База данных будет отвечать требованиям реляционной модели, если:

1.Данные хранятся в двумерных таблицах. Каждое имя таблицы уникально.

2.Каждый атрибут имеет уникальное имя для данной таблицы.

3.Каждый атрибут таблицы определен доменом.

4.Для каждого атрибута таблицы определена возможность использо­ вания Null-значений.

5.Значение каждого атрибута атомарно.

6.Для каждой таблицы определен хотя бы один потенциальный ключ.

7.Определены связи между таблицами и установлены соответствую­ щие внешние ключи.

8.Для каждого внешнего ключа указан тип соблюдения ссылочной целостности.

1.3.3. Манипулирование реляционными данными

Теоретической основой реляционной модели стала теория отношений, основу которых заложили два логика - американец Чарльз Содерс Пирс (Ch. S. Pierce, 1839-1914) и немец Эрнст Шредер (Е. Schroder, 1841-1902). В руко­ водстве по теории отношений было показано, что множество отношений замкнуто относительно некоторых специальных операций, что образует вме­ сте с этими операторами абстрактную алгебру.

Одно из главных достоинств реляционных баз данных - это возмож­ ность извлекать данные из любого множества реляционных таблиц посредст-

вом всего восьми реляционных операций, образующих реляционную алгебру, которую впервые сформулировал в 1970 году Э.Ф. Кодд.

- Выборка (WHERE). Оператор WHERE возвращает кортежи указанного отношения, которые удовлетворяют значению «истина» некоторого логиче­ ского выражения. Например:

Д е т а л и WHERE Вес > 10 AND Вес < 42

- Проекция. Операция проекции возвращает все кортежи указанного от­ ношения с сокращенным набором атрибутов за исключением дубликатов. Например:

Автор [Фамилия, Дата рождения]

- Декартово произведение (TIMES). Декартово произведение двух от­ ношений возвращает отношение, все кортежи которого состоят из конкате­ нации кортежей исходных отношений. Тело результирующего отношения состоит из всех возможных сочетаний кортежей первого отношения с корте­ жами второго. Степень результирующего отношения равняется сумме степе­ ней исходных отношений, а кардинальность - произведению кардинальности исходных отношений. Исходные отношения не должны содержать общих атрибутов, т.е. атрибутов, заданных на одном и том же домене и имеющих одинаковые имена: A(W, X) TIMES B(Y, Z) = C(W, X, Y, Z).

- Соединение (JOIN). Операция соединения - разновидность декартова произведения, в котором участвуют два отношения с одним или несколькими общими атрибутами. Соединение с такими условиями еще называют естест­ венным соединением. Результат соединения - тело, состоящее из всех воз­ можных сочетаний кортежей исходных отношений, в которых совпадают значения общих атрибутов: А(Х, Y) JOIN B{Y, Z) = С(Х, Y, Z).

В случае, если в отношениях A{W,X) и B(Y, Z) нет общих имен атрибу­ тов, но есть общие домены атрибутов X и У, то соединение таких двух отно­ шений можно выразить как

(A TIMES В) WHERE X=Y

-Объединение (UNION). Операция объединения выполняется как стан­ дартная математическая операция работы с множествами. В реляционной алгебре такая операция применима только к совместимым по типу отноше­ ниям, т.е. должны совпадать степени исходных отношений и каждый атрибут одного отношения должен совпадать по имени и домену с соответствующим атрибутом второго отношения. Результат объединения - отношение с заго­ ловком, совпадающим с одним из исходных отношений, и телом, состоящим из всех кортежей исходных отношений. Все дубликаты кортежей из резуль­ тата исключаются: А(Х) UNION В(Х) = С(Х).

-Вычитание (MINUS). Операция вычитания также применяется к двум совместимым по типу отношениям и возвращает кортежи, которые присутст­ вуют только в первом отношении.

-Пересечение (INTERSECT). Операция пересечения двух совместимых по типу отношений возвращает кортежи, которые существуют в обоих отношениях.

-Деление (DIVIDE). Одно отношение можно разделить на другое, если множество атрибутов второго отношения является подмножеством атрибутов первого отношения. Результат деления - отношение, заголовок которого со­ стоит из атрибутов первого отношения без перекрывающихся атрибутов вто­ рого отношения: А(Х, Y) DIVIDE B(Y) = С(Х). Тело результата будет содер­ жать такие значения не перекрывающихся атрибутов первого отношения, которые совпадают для всего набора значений атрибутов второго отношения.

АВ

После определения Коддом первоначальных восьми операций появи­ лась необходимость введения дополнительных операторов.

- Расширение (EXTEND). В традиционных операциях отсутствуют сред­ ства скалярных вычислений. Оператор EXTEND позволяет дополнить исход­ ное отношение новым вычисляемым атрибутом, причем вычисление производится «горизонтально» - по значениям атрибутов текущего кортежа. Так, например, если в отношении «Сотрудники» определены атрибуты

11

«Имя» и «Дата_рождения», то появляется возможность вычисления для каж­ дого сотрудника его возраста:

EXTEND Сотрудники ADD (СЕГОДНЯ()-Дата_рождения)/365.25 AS Возраст

- Переименование (RENAME). В результате операции переименования получается отношение с измененным именем атрибута или нескольких атри­ бутов.

Сотрудники RENAME Фамилия AS Фам_Сотр, Имя AS Имя_Сотр

- Подведение итогов (SUMMARIZE). Оператор SUMMARIZE позволя­ ет проводить «вертикальное» вычисление по всем значениям атрибута отно­ шения, как для всего отношения, так и для определенных групп значений указанного атрибута или нескольких атрибутов. Для такого рода вычислений используется ряд агрегатных функций COUNT(), MAX(), MIN(), SUM(), AVG().

SUMMARIZE Сотрудники BY ()

ADD AVG(Возраст) AS Средний_Возраст

SUMMARIZE Детали BY (Цвет)

ADD COUNT() AS Количество_Деталей

В первом случае получается отношение с одним кортежем и атрибутом «Средний_Возраст», в котором хранится среднее значение возраста всех со­ трудников. Во втором случае отношение результата содержит два атрибута: атрибут «Цвет» и ровно столько кортежей, сколько уникальных значений цвета деталей присутствует в отношении, и атрибут «Количество_Деталей», где для каждого цвета в кортеже указано количество деталей такого цвета.

Кроме того, существуют операторы обновления (INSERT, UPDATE, DELETE), которые позволяют соответственно добавлять новые кортежи в отношение, обновлять существующие значение атрибутов и удалять кортежи из отношения.

Нетрудно заметить, что в результате каждой реляционной операции по­ лучается новое отношение, над которым, в свою очередь, можно выполнять другие операции. Такое свойство называется свойством замкнутости.

Некоторому выражению, построенному с помощью реляционных опе­ раторов, можно присвоить имя и хранить этот новый объект в реляционной базе данных. Такой объект называется представлением {view), обращение к которому осуществляется как к обычному отношению и над которым можно выполнять другие реляционные операции.

Красные_Детали := Детали WHERE Цвет="Красный"

12

1.4. Язык SQL

Язык структурированных запросов {Structured Query Language, SQL)

является стандартом для всех реляционных систем. SQL позволяет пользователю СУБД создавать и удалять данные из базы данных, описывать правила, обеспечивающие целостность данных в рамках реляционной мо­ дели, а также выполнять полный набор операций реляционной алгебры.

Язык был разработан в конце 70-х годов и был реализован в первом прототипе реляционной СУБД System R фирмы IBM. В силу широкого рас­ пространения SQL стал стандартом «де-факто» для языков манипулирования данными в реляционных системах. Язык неоднократно подвергался стандар­ тизации. В 1989 году был создан первый стандарт языка, который получил название ANSI-SQL или SQL1. Дальнейшая стандартизация проводилась в 1989 и 1992 годах, после чего появились стандарты SQL2 и SQL3. Однако не все СУБД поддерживают последние стандарты языка SQL. Каждый разра­ ботчик пытается внести в язык собственные дополнительные функциональ­ ные возможности, в результате чего появляются различные модификации языка. Так, например, СУБД Oracle предлагает язык PL/SQL, в СУБД Micro­ soft SQL Server используется собственная модификация языка T-SQL. Для знакомства с языком SQL достаточно рассмотреть стандарт ANSI-SQL, кото­ рый должен поддерживаться всеми СУБД, претендующими на роль реляци­ онных СУБД.

Реляционная алгебра используется для извлечения данных из реляцион­ ной базы данных. Язык SQL предлагает для реляционных систем интерфейс более высокого уровня. Это декларативный язык, а не процедурный. В реля­ ционной алгебре указывается последовательность реляционных операций, т.е. процедуру, с помощью которой можно получить в результате необходи­ мое отношение. В языке SQL составляется описание данных, которые необ­ ходимо получить посредством оператора, который транслируется нижеле­ жащим системным уровнем в последовательность алгебраических операций.

Язык SQL состоит из операторов, которые делятся на две группы.

-Язык определения данных {Data Definition Language, DDL). Операторы CREATE, ALTER и DROP позволяют описывать и изменять структуру базы данных, включая определение таблиц, представлений, ключей, индексов и т.д. - любых объектов базы данных.

-Язык манипулирования данными {Data Manipulation Language, DML).

Операторы SELECT, INSERT, UPDATE и DELETE используются для извле­ чения, вставки, обновления и удаления данных соответственно.

1,4.1. Оператор SELECT

Оператор извлечения данных SELECT предлагает полный спектр функ­ циональных возможностей реляционной алгебры. Имея в качестве аргумента все множество таблиц базы данных и их представлений, оператор описывает

13

ограничения, какие необходимо наложить на это множество, чтобы в резуль­ тате получить требуемую таблицу.

Синтаксис оператора SELECT можно представить следующим образом:

Порядок выполнения инструкций оператора строго определен. Резуль­ тат каждой инструкции - таблица, к которой применяет следующая инструк­ ция.

1. Инструкция FROM. Результат вычисления обязательной инструкции FROM есть декартово произведение таблиц, перечисленных в списке. Список не может быть пустым и должен состоять хотя бы из одной таблицы. Каждой таблице допустимо назначение псевдонима, который будет действительным только в рамках всего выражения оператора SELECT, например:

FROM Детали AS А, Производители AS В

2.Инструкция WHERE выполняет реляционную операцию выборки к результату инструкции FROM. Инструкция WHERE необязательна и может быть опущена.

3.Инструкция GROUP BY также необязательна и применяется к резуль­ тату двух предыдущих инструкций, группируя строки по значениям указан­ ных в списке атрибутов.

4.Инструкция НА. V1NG может применяться только к сгруппированной таблице и накладывает некоторое условие на группу.

BY Детали.Цвет

HAVING COUNT() > 100

Указанный пример пары инструкций GROUP BY и HAVING группиру­ ет таблицу «Детали» по цвету, а затем оставляет в результате только те цвета,

укоторых количество соответствующих записей в группе превышает 100.

5.Инструкция SELECT применяется к результату всех предыдущих ин­ струкций и эквивалентна реляционным операциям проекция, расширение и переименование. Предположим, что таблица «Сотрудники» содержит атри­ буты «Фамилия», «Имя», «Отчество», «Дата рождения» и «Номер отдела». Таблица «Отделы» содержит атрибуты «Номер отдела» и «Название». Для получения списка всех сотрудников с указанием отдела, где он работает, и его текущего возраста можно построить следующее выражение на языке SQL.

SELECT

А.Номер отдела, Фамилия AS Сотрудник,

(СЕГОДНЯ() - Дата_Рождения)/365.25 AS Возраст, Название AS Отдел

FROM Сотрудники AS А, Отделы AS В WHERE А.Номер_Отдела = В.Номер_Отдела

Эквивалентная запись данного запроса операторами реляционной ал­ гебры будет выглядеть так:

Символ «*» применяется для указания всех атрибутов вычисленной таблицы. Однако при декартовом перемножении двух таблиц, в которых при­ сутствуют два атрибута с одинаковым именем (как «Номер отдела» в приме­ ре), что допустимо на высоком уровне языка SQL в отличие от строгих пра­ вил реляционной алгебры, возникает путаница - какой из атрибутов имеется в виду.

Таблица, которая возвращается в результате выполнения оператора SELECT, может содержать дубликаты строк, избежать которых можно, ука­ зав ключевое слово DISTINCT.

6. Инструкция ORDER BYвыполнятся последней, и сортирует результат по указанным в списке атрибутам, причем имена атрибутов должны соответ­ ствовать именам атрибутов из списка инструкции SELECT. Порядок сорти­ ровки указывается после каждого атрибута. Ключевое слово ASC использу­ ется для сортировки по возрастанию и DESC - по убыванию. Кроме имен атрибутов можно использовать порядковый номер результирующего столбца в списке инструкции SELECT, например:

ORDER BY 4, Возраст DESC, Сотрудник

Необходимо отметить некоторые особенности и ограничения использо­ вания отдельных инструкций. Инструкция SELECT не может содержать ат­ рибуты, не входящие в список атрибутов инструкции GROUP BY, кроме но­ вых вычисляемых атрибутов с использованием агрегатных функций COUNT0, МАХ(), MIN(), SUMO, AVG().

Допустимо использование вложенных подзапросов, например, для по­ иска всех деталей с максимальным весом можно использовать следующее выражение:

SELECT * FROM Детали

WHERE Вес = (SELECT MAX(Вес) FROM Детали)

Дополнительные возможности по конструированию условия выборки возникают при использовании специальных логических операторов.

- X [NOT] LIKE {шаблон} - оператор сравнения LIKE дает значение «истина», если строковое значение атрибута X соответствует шаблону. Шаб­ лон - строка, которая может содержать два специальных символа «%» и «_». Первый означает любое количество любых символов, а второй - один любой символ.

- X [NOT] BETWEEN xl AND x2 - дает значение «истина», если значе­ ние атрибута X лежит внутри диапазона значений [xl..x2].

-X [ NOT ] IN (подзапрос) - дает значение «истина», если значение ат­ рибута X в текущей строке исходной таблицы содержится в множестве всех значений единственного атрибута таблицы, получаемой в результате подза­ проса.

-X {оператор сравнения} ALL | ANY (подзапрос) - условие вида «все- или-какой-нибудь» дает значение «истина», когда соответствующее сравне­ ние значения атрибута X в текущей строке исходной таблицы дает значение «истина» для всех значений (ALL) или хотя бы для одного значения (ANY) единственного атрибута таблицы, получаемой в результате подзапроса.

Пример. Найти красные детали, которые тяжелее любой синей детали.

В результате запроса будет получена деталь D203. Если необходимо найти красную деталь тяжелее хотя бы одной синей детали, то в запросе сле­ дует заменить ALL на ANY и будут получены детали D203 и D204.

- [NOT] EXISTS (подзапрос) - дает значение «истина», если таблица подзапроса возвращает хотя бы одну строку.

SELECT * FROM Детали AS Д1 WHERE Д1.Цвет - "RED" AND EXISTS

( SELECT * FROM Детали AS Д2

WHERE Д1.Вес > Д2.Вес AND Д2.Цвет = "BLUE" )

Пример эквивалентен поиску красных деталей, которые тяжелей хотя бы одной синей детали. Но в этих двух примерах есть существенное разли­ чие, связанное с оптимизацией запроса. Скорость выполнения второго при­ мера на большом массиве данных будет существенно ниже, чем первого. Де­ ло в том, что подзапрос первого примера выполняется один раз и сравнение происходит для каждой строки по уже вычисленному подзапросу. Подзапрос второго примера будет выполняться постоянно для каждой строки Д1. Одна-

ко, существуют определенные задачи, решение которых невозможно без опе­ ратора EXISTS.

-X IS [NOT] NULL - возвращает значение «истина», если значение X не определено. Обычный оператор сравнения, например, X = NULL дает значе­ ние «ложь».

Замечание. Исходные Null-значения дают неопределенные значения ре­ зультату любых операций. Например, если один из числовых атрибутов X или Y в каком-либо кортеже примет значение NULL, то результат операции X

+Y для этого кортежа будет равен NULL.

Спомощью оператора UNION можно выполнить реляционную опера­ цию объединения двух запросов, построенных с помощью оператора SELECT:

(3aпpoc 1) UNION (Запрос2)

Язык SQL некоторых СУБД поддерживает соответствующие реляцион­ ным операциям вычитания и пересечения операторы MINUS и INTERSECT. Если такая поддержка отсутствует, то, например, операцию вычитание А(Х) MINUS B(X) можно выразить как

SELECT X FROM A WHERE X NOT IN (SELECT X FROM B)

Особую реализацию получила реляционная операция соединения. На­ пример, A(X,Y) JOIN B(Y,Z) можно выразить как

SELECT X, A.Y, Z FROM А, В WHERE A.Y == B.Y

В языке SQL-92 существует специальный синтаксис соединения таблиц:

SELECT A . * , B.Z FROM A JOIN В ON A.Y = B.Y

Это пример обычного в понимании реляционной алгебры естественного

ное, левое и правое внешнее соединение. Отличие внешнего соединения от внутреннего заключается в том, что в результирующей таблице не отбрасы­ ваются строки, в которых значения общих столбцов не совпадают. Так, на­ пример, при левом соединении в результат войдут все строки левой таблицы, а значения столбцов отсутствующих строк по значению общего столбца пра­ вой таблицы будут заменены Null-значением.

SELECT A.*, B.Z FROM A LEFT OUTER JOIN В ON A.Y = B.Y

АВ A LEFT OUTER JOIN В

1.4.2. Операторы INSERT, UPDATE и DELETE

Оператор INSERT позволяет добавлять в таблиц}' одну строку, если указана следующая форма выражения:

INSERT INTO < таблица >

{ ( < список атрибутов > ) VALUES ( < список значений > )

} | DEFAULT VALUES

Также можно добавить сразу несколько строк, полученных с помощью запроса:

INSERT INTO < таблица > ( < список атрибутов > ) < запрос >

Оператор UPDATE позволяет обновить значения атрибутов таблицы новыми значениями.

UPDATE < таблица > SET

< атрибут > = < значение > | ( < подзапрос > )

[, < атрибут > = < значение > | ( < подзапрос > ) [,...]] [WHERE < условие на обновляемые строки > ]

Оператор DELETE удаляет из таблицы строки, которые удовлетворяют указанному условному выражению.

DELETE FROM < таблица >

[WHERE < условие на удаляемые строки > ]

Инструкция WHERE операторов UPDATE и DELETE соответствует по своим возможностям инструкции WHERE оператора SELECT.

1.5. Реляционная СУБД

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

1. Обеспечивает поддержку реляционных баз данных согласно указан­ ным выше условиям.

2.Обеспечивает поддержку целостностей сущностей их связей.

3.Поддерживает реляционные операции по манипулированию данными посредством языка SQL.

Глава 2. Проектирование реляционной базы данных

Первым шагом перехода от теории к практике является процесс проек­ тирования реляционной базы данных для конкретной предметной области. Каждая предметная область порождает многообразие объектов и процессов, в которых участвуют эти объекты по определенным правилам, всевозможные связи и зависимости между объектами. Поэтому проектирование базы дан-

18

ных является достаточно сложным и ответственным этапом в ходе реализа­ ции системы, главная цель которого - создание эффективной структуры дан­ ных, имеющей максимальную защиту целостности данных.

2.1. Этапы проектирования базы данных

Процесс проектирования базы данных состоит из нескольких этапов.

1. Постановка задачи. Первая стадия проектирования заключается в фиксации требований пользователя как к разрабатываемой системе в целом. так и к управляемой этой системой информации.

2.Семантическое моделирование. На основе поставленных пользовате­ лем требований строится семантическая модель базы данных, цель которой заключается в описании смыслового значения данных. Сначала проводится системный анализ предметной области на основе требований пользователя для подробного словесного описания объектов этой области, их свойств, свя­ зей и зависимостей с другими объектами, на основе чего строится модель «сущность-связь», которая представляет зависимости между объектами в виде диаграмм. Существуют и другие методы семантического моделирования для определения смыслового значения данных, однако различные вариации модели «сущность-связь», или ER-модели, являются самыми распространен­ ными в моделировании баз данных.

Первые два этапа представляют концептуальное проектирование базы данных, в результате которого создается высокоуровневая логическая модель базы данных, которая еще называется концептуальной моделью. Такая мо­ дель обладает следующими свойствами:

- Независимость от классических моделей данных. Построив четко оп­ ределенную концептуальную модель, можно выбирать, на каком типе систе­ мы проводить реализацию базы данных и даже сменить ее, если появится такая необходимость. Однако, такая независимость только кажущаяся, так как в действительности каждая методология семантического моделирования приспособлена к определенному типу системы. Так, в частности ERмоделирование направлена именно на реляционные системы, но если уже определено, что использоваться будет реляционная система, то независи­ мость ER-модели от конкретной реляционной СУБД существует.

- Полнота описания данных. Это важное свойство говорит о том, что в концептуальную модель можно заложить намного больше смыслового опи­ сания и ограничений, чем в любой классической модели данных.

3.Следующим этапом проектирования базы данных будет преобразова­ ние концептуальной модели в концептуальную схему конкретной системы баз данных. Для реляционной СУБД это будет процесс преобразования опре­ деленных сущностей во множество таблиц, создания потенциальных ключей, определения связей между таблицами посредством внешних ключей и т.д.

19