И Попов ЕД Попова АВ...

Министерство образования и науки Российской Федерации федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования Московский государственный университет печати имени Ивана Федорова

Д.И. Попов, Е.Д. Попова, А.В. Некрасов

Информационные технологии в издательском деле и полиграфии: основы

проектирования баз данных Учебное пособие

Допущено УМО по образованию в области полиграфии и книжного дела

для студентов высших учебных заведений, обучающихся по направлению подготовки 29.03.03 «Технология полиграфического

и упаковочного производства»

Москва 2015

2

УДК 004.6 ББК 32.973.26-0.18.2

П 58

Р е ц е н з е н т ы: Винокур А.И., д-р техн. наук, профессор, директор

Института принтмедиа и информационных технологий МГУП имени Ивана Федорова;

Николаев А.Б., д-р техн. наук, профессор, заведующий кафедрой «Автоматизированные системы управления» МАДИ (государственного технического университета)

Попов Д.И., Попова Е.Д., Некрасов А.В.

П 58 Информационные технологии в издательском деле и поли- графии: основы проектирования баз данных : учеб. пособие / Д.И. Попов, Е.Д. Попова, А.В. Некрасов (Южный федераль-ный университет); Моск. гос. ун-т печати имени Ивана Федо-рова. — М.: МГУП имени Ивана Федорова, 2015. — 165 с. ISBN 978-5-8122-1317-6

Учебное пособие предназначено для изучения основ проектирования ре-ляционных баз данных. В издании приводятся основные принципы проекти-рования информационных систем на основе СУБД, даются основы реляцион-ной алгебры, рассматриваются проблемы нормализации отношений, излагаются возможности языка SQL. Пособие рассчитано на студентов, обу-чающихся по направлению 29.03.03 — «Технология полиграфического и упа-ковочного производства», изучающих дисциплины «Информатика» и «Про-граммные средства обработки информации», а также для учащихся по направлению 42.03.03 — «Издательское дело». Кроме того, может быть по-лезно для учащихся других направлений обучения, а также для магистрантов, аспирантов, изучающих проектирование баз данных.

УДК 004.6 ББК 32.973.26-0.18.2

ISBN 978-5-8122-1317-6 © Попов Д.И., Попова Е.Д.,

Некрасов А.В., 2015 © МГУП имени Ивана Федорова, 2015

3

Содержание

Введение.................................................................................................................... 8 1. Проектирование баз данных ......................................................12

1.1. Ассоциации ...............................................................................12 1.2. Модель «Сущность-связь» (ER-модель) ................................16 1.3. Сущность...................................................................................16 1.4. Атрибуты...................................................................................18 1.5. Ключи ........................................................................................21 1.6. Связи ..........................................................................................24 1.7. Преобразование и оптимизация ER-диаграмм ......................27 1.8. Построение отношений на основе ER-диаграмм ..................30 1.9. Вопросы для самоконтроля .....................................................31 1.10. Тестовые задания....................................................................32

2. Логические модели данных и нормализация отношений ....39 2.1. Иерархическая модель .............................................................39 2.2. Сетевая модель .........................................................................41 2.3. Реляционная модель .................................................................43 2.4. Нормализация отношений .......................................................45 2.5. Цель нормализации ..................................................................45 2.6. Типы функциональных зависимостей ....................................47 2.7. Нормальные формы..................................................................49 2.8. Вопросы для самоконтроля .....................................................59 2.9. Тестовые задания......................................................................60

3. Элементы реляционной алгебры ..............................................70 4.1. Основные понятия ....................................................................70 3.2. Пример реляционных отношений...........................................73 3.3. Операции реляционной алгебры .............................................76 3.4. Реляционное исчисление (РИ).................................................87 3.5. РИ кортежей и доменов ...........................................................88 3.6. Вопросы для самоконтроля .....................................................89 3.7. Тестовые задания......................................................................90

4

4. Язык запросов SQL ......................................................................98 4.1. Основные понятия ....................................................................98 4.2. Типы данных SQL ....................................................................99 4.3. Использование SQL для выборки данных из таблиц ..........101 4.4. Общий вид оператора SELECT.............................................103 4.5. Механизм работы оператора SELECT..................................105 4.6. Операторы сравнения, логические и арифметические операторы .......................................................................................106 4.7. Использование специальных операторов.............................108 4.8. Использование оператора NULL ..........................................110 4.9. Использование NOT со специальными операторами .........111 4.10. Использование функций агрегирования и предложения HAVING .........................................................................................111 4.11. Выборка информации из нескольких таблиц ....................114 4.12. Рекурсивное соединение таблицы ......................................118 4.13. Использование вложенных запросов..................................120 4.14. Связанные подзапросы ........................................................124 4.15. Оператор EXISTS .................................................................126 4.16. Использование операторов ANY, SOME, ALL .................129 4.17. Оператор UNION..................................................................131 4.18. Ввод, удаление и изменение значений полей ....................133 4.19. Создание таблиц ...................................................................137 4.20. Обеспечение ссылочной целостности ................................139 4.21. Изменение структуры таблиц и удаление таблиц .............142 4.22. Представления ......................................................................142 4.23. Привилегии ...........................................................................144 4.24. Вопросы для самоконтроля .................................................146 4.25. Тестовые задания..................................................................147

Заключение........................................................................................156 Библиографический список .............................................................160 Предметный указатель ..................................................................163

5

Предисловие

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

Решение вопросов автоматизации различных производствен-ных задач в издательском деле и полиграфии не имеет перспекти-вы без эффективного использования систем управления базами данных (СУБД). С другой стороны, все сложнее требования к зна-ниям и умениям специалистов, использующих такие ИС в процес-се свое производственной деятельности. Это означает, что специа-листы высокого уровня должны обладать фундаментальными знаниями в области проектирования и эксплуатации современных ИС. Фундаментом таких знаний является теория баз данных, в ос-нову которой положены методы реляционной алгебры и реляци-онного исчисления, теория множеств и отношений, методы деком-позиции отношений и языки манипулирования данными. Безусловно, высококвалифицированный специалист в любой при-кладной отрасли должен уметь учитывать и применять многолет-ний опыт разработчиков ИС. Этот опыт выливается порой в созда-ние неформальных и эвристических методик и рекомендаций по проектированию, сопровождению и эксплуатации ИС. Таким об-разом, разработка и проектирование ИС на основе БД является достаточно сложной задачей, и успешное решение этой задачи бу-дет зависеть от того, насколько фундаментально подходит к ней разработчик.

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

6

нием информационных систем на основе баз данных по дисципли-нам «Информатика» и «Программные средства обработки инфор-мации» для направления 29.03.03 — «Технология полиграфиче-ского и упаковочного производства», а также по дисциплине «Информационные технологии в издательском деле» направления 42.03.03 — «Издательское дело».

Пособие поможет учащимся овладеть следующими компетен-циями федеральных образовательных стандартов:

1) компетенции по направлению 29.03.03 — «Технология по-лиграфического и упаковочного производства»: • владеть основными методами, способами и средствами полу-

чения, хранения, переработки информации, иметь навыки ра-боты с компьютером как средством управления информацией (ОК-12);

• уметь использовать для решения коммуникативных задач со-временные технические средства и информационные техноло-гии (ПК-5);

• применять основные методы и средства проектирования в профессиональной деятельности по выпуску книг, газет, жур-налов, рекламной, упаковочной и другой продукции с исполь-зованием информационных технологий (ПК-30); 2) компетенции по направлению 42.03.03 — «Издательское дело»:

• владеть основными методами, способами и средствами полу-чения, хранения, переработки информации, иметь навыки ра-боты с компьютером как средством управления информацией (ОК-13);

• владеть приемами и методами аналитико-синтетической пере-работки потоков информации (ПК-8);

• уметь использовать информационные технологии и про-граммное обеспечение при разработке издательских проектов (ПК-14). Основная задача данного учебного пособия — постараться

рассмотреть методики и знания, накопленные за последние деся-тилетия в теории проектирования БД и ИС, и достаточно сжато изложить их в этом пособии. Так, для подготовки пособия были

7

использованы фундаментальные работы и труды в области проек-тирования БД таких известных авторов, ставших классиками в этой области, как К. Дейт [9], Т. Коннолли [16], Т. Тиори [29], Дж. Ульман [30], М. Грабер [8], Дж. Хаббард [32] и др. Был также учтен опыт отечественных разработчиков и авторов, издававших свои работы в Москве [5,12,36], Санкт-Петербурге [7,35], Ростове-на-Дону[24, 1,2,13,17,37] и других городах. Кроме того, были про-анализированы и использованы опыт и публикации многочислен-ных авторов в Интернете: В. Кириллов [14], С. Кузнецов [18], А. Пушников [26] и др.

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

8

Введение

База данных (БД) может быть определена как совокупность предназначенных для машинной обработки структурированных данных, которые применяются многими пользователями в рамках одной или нескольких организаций [13].

Особенностью БД является тот факт, что она рассчитана на ис-пользование при создании различных независимых программ и приложений. В этом основное отличие БД от обычных файлов данных — они используется только в конкретно разработанном для них приложении.

В соответствии с приведенным определением БД обладает сле-дующими качествами [37]: • интегрированностью данных, т.е. направлена на решение раз-

личных задач; • структурированностью данных, т.е. отражает некоторую часть

реального мира; • взаимосвязью данных, т.е. в БД хранятся данные, связанные

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

ной информации; • доступностью и целостностью данных; • независимостью данных от прикладных программ.

Система управления базой данных (СУБД) — специальная программа и/или пакет программ, которые управляют работой БД, обеспечивают доступ к данным и их централизованное управле-ние. Именно СУБД обеспечивает независимость данных, а при-кладные программы поддерживают логику каждой отдельной за-дачи. Не всякая программа работы с БД является СУБД, для этого она должна обладать следующими качествами: • обеспечить пользователя (или прикладные программы) языко-

выми средствами поиска и манипулирования данными. В на-стоящее время в качестве такого языка широко используется

9

язык SQL — структурированный язык запросов (см. раздел «Язык запросов SQL»);

• обеспечить поддержку логических моделей данных. Модель данных определяет логическое представление физических дан-ных (см. раздел «Логические модели данных»);

• обеспечить операции создания и манипулирования логически-ми данными (выборка, вставка, обновление, удаление и т.д.) и одновременное управление физическими данными. Это орга-низуется либо с помощью командного интерфейса, либо с по-мощью конструкций языка манипулирования данными (что за-частую совпадает);

• обеспечить защиту и согласованность данных, поскольку при коллективном режиме работы многих пользователей возможно использование общих физических данных. При разработке БД необходимо учитывать определенные тре-

бования. БД должна: • удовлетворять актуальным информационным потребностям

пользователя; • отвечать требованиям достоверности и непротиворечивости

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

зависимость приложений от организации данных; • поддерживать возможные изменения и расширения предмет-

ной области; • быть универсальной по отношению к программной и аппарат-

ной средам; • отвечать различным требованиям по производительности. Так,

например, в ИС с реальным временем обработки данных ин-формация должна выдаваться очень быстро (OLTP — Online Transition Processing — оперативная обработка данных), а в ИС, связанных с анализом данных, возможны ситуации, когда данные обрабатываются достаточно долго (OLAP — Online Analytic Processing — аналитическая обработка данных). Данные, хранящиеся в БД, представляют собой некоторый

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

10

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

Элемент данных (ЭД) определяет некоторое свойство или ат-рибут объекта предметной области. Например, для объекта «сту-дент» некоторой предметной области можно ввести следующие ЭД: «дата», «ФИО», «адрес».

Экземпляром элемента данных (ЭЭД) называется некоторое конкретное значение, принимаемое ЭД. Например, для ЭД «ФИО» экземпляром может быть строковое значение «Петров Иван Ива-нович».

Поименованная совокупность ЭД, рассматриваемая в програм-ме как единое целое, носит название агрегата данных (например, «дата, ФИО, адрес»).

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

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

в различные записи. Полнота заключается в том, что любой ЭД может характери-

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

ределения структуры БД [13,24]: • концептуальный; • логический; • физический.

Концептуальная модель представляет собой объекты и их взаимосвязи без указания способов их физического хранения. То есть концептуальная структура (или схема) состоит: из основных ЭД предметной области (личности, факты), называемых объекта-ми; элементарных данных, описывающих свойства и признаки

11

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

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

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

Пользователям выделяются подмножества этой логической модели, называемые внешними моделями.

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

Логическая модель отображается в физическую память, такую как диск, дискета, и получается физическая модель.

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

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

Второй уровень независимости данных: внешние модели не за-висят от изменений физической памяти и методов доступа к БД.

Независимость данных является одним из важнейших требова-ний к БД.

12

1. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

1.1. Ассоциации

Связи в БД определяют некоторую зависимость между парами ЭД. Такую зависимость можно представлять при помощи ассоциа-ций. Существует три типа ассоциаций: ассоциация 1 (простая ); ас-социация М (сложная); ассоциация С (условная) [37].

Если ЭЭД, от которого направлена связь, идентифицирует один и только один ЭЭД, к которому направлена эта связь, то го-ворят об ассоциации типа 1, или простой ассоциации. Простая ас-социация определяет функциональную зависимость между ЭД. Идентификация в этом случае является уникальной. Связь в об-ратном направлении не рассматривается.

Например, рассмотрим связь между ЭД «№ студенческого би-лета» и «Группа». Очевидно, что в рамках предметной области, например, «студенты конкретного вуза» номер студенческого би-лета будет однозначно определять группу, в которой учится соот-ветствующий студент. Это говорит о том, что в данном случае речь идет о простой ассоциации. Аналогично и для пары ЭД «№ паспорта» и «ФИО» предметной области «паспортный стол» (рис. 1.1).

Рис. 1.1. Простая ассоциация

№ студ.билета

№ паспорта

Группа

ФИО

1

1

13

Если ЭЭД, от которого направлена связь, идентифицирует не-которое число (0, 1 или несколько) ЭЭД, к которому направлена связь, то говорят, об ассоциации типа М, или сложной ассоциации. Связь в обратном направлении не рассматривается. Сложная ассо-циация определяет многозначную зависимость между ЭД. Иден-тификация в этом случае необязательно является уникальной. На-пример, по конкретной студенческой группе можно определить некоторое количество номеров студенческих билетов тех студен-тов, которые учатся в этой группе. Другой пример — пара ЭД «со-трудник» и «должность» для предметной области «отдел кадров — архив сотрудника» (рис. 1.2).

Рис. 1.2. Сложная ассоциация

Для конкретного экземпляра ЭД может не существовать ЭЭД, к которому направлена связь. Это допускается в сложной и услов-ной ассоциациях. Однако в условной ассоциации обязательное требование: если такой ЭЭД все-таки существует, то он единст-венный.

Если ЭЭД, от которого направлена связь, идентифицирует один ЭЭД, либо не идентифицирует ни одного ЭЭД, к которому направлена эта связь, то говорят об ассоциации типа С, или услов-ной ассоциации. Связь в обратном направлении не рассматривает-ся. Например, для двух ЭД «№ студ. билета» и «дата отчисления» связь может и не существовать, но если существует, то только единственная. Рассмотрим еще пример. Пусть дана предметная область «учебные занятия» и имеется пара ЭД «преподаватель» — «аудитория». В этом случае для конкретного момента времени, учитывая расписание, можно указать, где именно находится пре-

Группа

Сотрудник


Должность

М

М

14

подаватель — номер аудитории (причем единственный). Но может быть такая ситуация, когда связи не существует, т.е. у преподава-теля в это время нет занятий (рис. 1.3).

Рис. 1.3. Условная ассоциация

При проектировании БД важную роль играет также связь меж-ду ЭД в обратном направлении. Когда рассматриваются связи в обе стороны, говорят об отображениях. Отображение является средством для определения характера взаимосвязей между эле-ментами данных, так как отображение описывает двусторонние связи между ЭД.

Выделяют несколько типов отображений: 1:1, 1:М, М:1, М:N. При помощи отображений 1:1 («один к одному») представляют

такой тип связи, когда один ЭЭД, от которого направлена связь, идентифицирует один и только один ЭЭД, к которому направлена связь, и наоборот (рис. 1.4).

Рис. 1.4. Отображение 1:1

При помощи отображений 1:М («один ко многим») представ-ляют такой тип связи, когда ЭЭД, от которого направлена связь,


№ паспорта

ФИО

ФИО

1:1

1:1


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

Дата отчисления

Аудитория

С

С

15

идентифицирует некоторое число (0,1 или несколько) ЭЭД, к ко-торым направлена связь, причем в данном направлении идентифи-кация не обязательно является уникальной. Однако в обратном на-правлении любой ЭЭД идентифицирует один и только один ЭЭД, от которого направлена связь (рис. 1.5).

Отображение М:1 является обратным к отношению 1:М. Дос-таточно поменять ЭД местами (рис. 1.5).

Рис. 1.5. Отображения 1:М и М:1

При помощи отображений М:N («многие ко многим») пред-ставляют такой тип связи, когда один ЭЭД, от которого направле-на связь, идентифицирует некоторое число ЭЭД, к которым на-правлена связь, и наоборот (идентификация не уникальна в обоих направлениях) (рис. 1.6).

Рис. 1.6. Отображение М:N


Покупатель

Дисциплина

Товар

М:N

М:N


Группа

Группа


1:М

М:1

16

1.2. Модель «Сущность-связь» (ER-модель)

Модель «Сущность-связь» (Entity-Relationship model, или ER-модель) представляет собой высокоуровневую концептуальную модель данных, которая была разработана американским ученым в области информатики Питером Ченом [37] в 1976 году с целью упрощения задачи проектирования БД. Данная модель данных представляет собой набор концепций, которые описывают струк-туру БД и связанные с ней транзакции обновления и извлечения данных [16]. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского вос-приятия данных и согласования большого количества технических аспектов, связанных с проектированием БД. Следует особо под-черкнуть, что концептуальная модель данных не зависит от кон-кретной СУБД или аппаратной платформы, которая используется для реализации БД.

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

1.3. Сущность

Типы сущностей — объект или концепция, которые характе-ризуются на данном предприятии как имеющие независимое су-ществование.

Основной концепцией ER-моделирования является тип сущно-сти (entity type), который представляет собой множество объектов реального мира с одинаковыми свойствами. Тип сущности харак-теризуется независимым существованием или объектом с концеп-туальным (или абстрактным) существованием, как показано в табл. 1.1. В данный момент можно дать только рабочее определе-ние типа сущности, поскольку пока не существует строгого фор-мального определения. Это значит, что разные разработчики могут выделять разные сущности.

17

Таблица 1.1

Примеры сущностей Физическое существование Концептуальное существование

Сотрудник Объект недвижимости Клиент Деталь Поставщик Изделие

Осмотр объекта недвижимости Инспекция объекта недвижимости Продажа объекта недвижимости Рабочий стаж

Сущность — экземпляр типа сущности, который может быть идентифицирован уникальным образом.

Каждый уникально идентифицируемый экземпляр типа сущно-сти называется просто сущностью. Некоторые другие авторы предпочитают называть его экземпляром сущности (entity occur-rence или entity instance).

Каждый тип сущности характеризуется именем и списком свойств. БД обычно содержит много разных типов сущностей. На-пример, для выбранной нами предметной области можно выделить такие типы сущностей, как Сотрудник, Родственник, Объект не-движимости, Филиал, Владелец, Клиент и др. Несмотря на то, что тип сущности обладает уникальным набором атрибутов, каждая сущ-ность имеет свои собственные значения для каждого атрибута. Типы сущностей можно классифицировать как сильные и слабые.

Слабый тип сущности — тип сущности, существование ко-торого зависит от сущности какого-то другого типа.

Сильный тип сущности — тип сущности, существование ко-торого не зависит от сущности какого-то другого типа.

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

18

Для наглядного отображения модели «Сущность-связь» ис-пользуются диаграммы «Сущность-связь» или ЕR-диаграммы.

Каждый сильный тип сущности изображается на диаграмме в виде прямоугольника с именем сущности внутри него, а каждый слабый тип сущности — в виде прямоугольника с двойным конту-ром. На рис. 1.7 показан пример представления на диаграммах сильных (Сотрудник и Филиал) и слабых (Родственник) типов сущностей.

Рис. 1.7. Слабые и сильные сущности

1.4. Атрибуты

Атрибут — свойство типа сущности или типа связи. Напри-мер, сущность Филиал может быть описана номером филиала (ФNo), адресом (Адрес), номером телефона (Телефон) и номером факса (Факс). Атрибуты сущности содержат значения, описываю-щие каждую сущность. Значения атрибутов представляют основ-ную часть сведений, сохраняемых в БД.

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

Домен атрибута — набор значений, которые могут быть при-своены атрибуту.

Каждый атрибут связан с набором значений, который называ-ется доменом. Домен определяет все потенциальные значения, ко-торые могут быть присвоены атрибуту. Например, количество комнат в объекте недвижимости может варьироваться от одной до пятнадцати для каждого экземпляра этой сущности. Следователь-но, набор допустимых значений для атрибута «Количество ком-нат» (комнаты) сущности Жилье можно определить как набор це-лых чисел от 1 до 15.

Различные атрибуты могут совместно использовать один и тот же домен. Например, атрибуты адреса «Адрес» сотрудников ком-пании (сущности Сотрудник) и владельцев объектов недвижимо-

Родственник Сотрудник

Филиал

19

сти (Владелец) могут совместно использовать один и тот же домен всех возможных адресов. Домены также могут представлять собой комбинацию, состоящую из нескольких других доменов. Напри-мер, домен «Дата рождения» сущности Staff состоит из таких под-чиненных доменов, как «день», «месяц» и «год».

Домен атрибута имени «имя» определить труднее, потому что он состоит из множества всех возможных имен. Очевидно, что это — текстовая строка, но она может состоять не только из букв, но так-же из дефисов или других специальных символов. Полностью раз-работанная модель данных включает домены каждого атрибута, присутствующего в ER-модели.

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

Простой атрибут — атрибут, состоящий из одного компо-нента с независимым существованием.

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

Составной атрибут — атрибут, состоящий из нескольких компонентов, каждый из которых характеризуется независимым существованием.

Некоторые атрибуты могут быть разделены на более мелкие компоненты, которые характеризуются независимым существова-нием. Например, атрибут адреса «Адрес» сущности, представ-ляющей отделение компании Филиал со значением «347928, Рос-товская область, г. Таганрог, Некрасовский, 44» может быть разбит на отдельные атрибуты почтового индекса — «Индекс со значением 347928», области «Область» со значением «Ростов-ская», города «Город» со значением «Таганрог», улицы «Улица» со значением «Некрасовский 44».

Решение о моделировании атрибута «Адрес» в виде простого атрибута или разбиении его на атрибуты «Индекс», «Область», «Город», «Улицa» зависит от того, как рассматривается атрибут «Адрес» в пользовательском представлении — как единое целое или как набор отдельных компонентов.

20

Однозначный атрибут — атрибут, который содержит одно значение для одной сущности.

Большинство атрибутов типов сущностей является однознач-ным для каждого отдельного экземпляра этой сущности. Напри-мер, сущность Филиал всегда имеет единственное значение в ат-рибуте номера отделения компании (ФNo), например Ф3. Поэтому атрибут ФNo является однозначным.

Многозначный атрибут — атрибут, который содержит не-сколько значений для одной сущности.

Некоторые атрибуты могут иметь несколько значений для од-ной сущности. Например, сущность Филиал может иметь несколь-ко значений для атрибута номера телефона отделения компании «Телефон», например: 315-118 и 37-17-47. Следовательно, атрибут «Телефон» в этом случае будет многозначным. Многозначный ат-рибут допускает присутствие определенного количества значений (возможно, в заданных пределах — максимальном и минимальном количестве). Например, атрибут «Телефон» отделения компании может иметь от одного до десяти значений. Иными словами, лю-бое отделение компании должно иметь минимум один номер те-лефона и максимум десять собственных телефонных номеров.

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

Некоторые атрибуты могут быть связаны с определенной сущ-ностью. Например, атрибут «Возраст сотрудника» является вели-чиной, производной от его «Даты рождения», и поэтому эти атри-буты являются связанными. Причем атрибут «Возраст сотрудника» является производным атрибутом, значение которого вычисляется на основании значения атрибута «Дата рождения».

В некоторых случаях значение атрибута является производным от многих сущностей одного и того же типа. Например, атрибут общего количества сотрудников «Количество» отделения компа-нии сущности типа Сотрудник может быть вычислен на основе подсчета количества сущностей Сотрудник.

21

1.5. Ключи

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

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

Например, номер отделения компании (ФNo) является потен-циальным ключом сущности типа Филиал, поскольку он содержит разные значения для каждой отдельной сущности Филиал. Потен-циальный ключ должен содержать значения, которые уникальны для каждого отдельного экземпляра сущности данного типа. На-пример, каждое отделение компании обладает уникальным номе-ром, и не существует отделений с одинаковыми номерами.

Первичный ключ — потенциальный ключ, который выбран в качестве первичного.

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

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

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

22

Составной ключ бывает полностью составным и полусоставным. Полностью составной ключ содержит несколько атрибутов,

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

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

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

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

В некоторых случаях ключ сущности состоит из нескольких атрибутов, значения которых, взятые вместе, а не по отдельности, уникальны для каждого экземпляра сущности. Например, сущ-ность Осмотр (осмотр жилья) может обладать следующими атри-бутами: «Съемщик» (СкNo, клиент, который осматривал жилье), «Жилье» (Жno, код недвижимости, которая осматривалась), «Да-та» (дата осмотра) и «Комментарий осмотра». Один и тот же съемщик может осматривать жилье несколько раз, и результат ос-мотра будет отличаться датами осмотра и комментариями. Для уникальной идентификации результатов каждого осмотра жилья необходимо использовать значения СкNo, Жno, «Дата». Таким об-разом, сущность Осмотр обладает составным первичным ключом, состоящим из атрибутов СкNo, Жno, «Дата».

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

23

Эллипс окружен пунктирным контуром, если атрибут является производным (атрибут «Количество»), и двойным контуром, если атрибут является многозначным (атрибут «Телефон»).

Если атрибут является составным, его атрибуты-компоненты изображаются в виде присоединенных к нему эллипсов. На рис.1.8 показано, что атрибут «Полное Имя» сущности Сотрудник являет-ся составным атрибутом, состоящим из атрибутов имени, отчества и фамилии.

Рис. 1.8. Представление сущности

Имя атрибута, который является первичным ключом сущности данного типа, подчеркивается. Первичным ключом сущности Со-трудник является атрибут номера отделения компании CкNo.

Рис. 1.9. Представление на ER-диаграмме сущностей атрибутов и связей

24

1.6. Связи

Связь представляет собой некоторую осмысленную ассоциа-цию между сущностями различных типов. Каждая связь изобража-ется в виде ромбика с указанным на нем именем связи. Ромбик имеет двойной контур, если связь соединяет слабую сущность с сильной, от которой эта слабая сущность зависит. На рис. 1.9 при-ведены связи между сущностями Сотрудник, Родственник, Фили-ал. Связь «Степень родства» (ст. родства) определяет, кто и каким именно родственником является у сотрудника компании, а связь «Работает» определяет, в каком филиале работает сотрудник. Для снижения уровня детализации на ER-диаграммах часто указывают только те атрибуты, которые представляют собой первичные клю-чи изображаемых сущностей.

Степень связи — количество сущностей, которые охвачены данной связью. Участниками связи могут быть одна (унарная или рекурсивная связь), две (бинарная связь), три (тринарная связь), четыре (кватернарная связь) сущности. Если степень связи больше двух, то связь называется сложной. Например, на рис. 1.10 для сущностей Клиент, Сотрудник и Недвижимость определена три-нарная связь — «Арендовать».

Рис. 1.10. Пример тринарной связи

Связям могут присваиваться ролевые имена — для указания назначения каждой сущности (участницы данной связи). Ролевые имена имеют большое значение в рекурсивных связях (при опре-делении функций каждого участника). Например, на рис. 1.11 при-веден пример рекурсивной связи, которая может быть интерпрети-рована так (читаем рисунок по часовой стрелке): «сотрудник-руководитель управляет подчиненным сотрудником». Кроме того,

25

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

Рис. 1.11. Рекурсивная связь и ролевые имена связи

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

Кардинальность связи описывает количество возможных свя-зей для каждой из сущностей-участниц. Наиболее распространен-ными являются бинарные связи с показателями кардинальности 1:1, 1:М и M:N. Показатели кардинальности ставятся слева и спра-ва от ромбиков связи (рис. 1.12). Связи, указанные на рис. 1.12, подчеркивают, что руководитель может управлять только одним филиалом и у филиала может быть только один руководитель, то-гда как каждый сотрудник может работать только в одном филиа-ле, но в этом филиале может работать много разных сотрудников. Иногда кардинальность связи обозначают в виде двойной пары вида (Min,Max): (Min1,Max1), подчеркивая дополнительные струк-турные ограничения в виде минимальных и максимальных значе-ний, обозначающих участие сущности в данной связи.

Например, если мы поменяем на рис. 1.12 для связи «Распо-ложен» обозначение M на (4, N), а обозначение 1 поменяем на (0,1), то смысл у такого нового обозначения кардинальности будет следующим: в каждом отделении компании работает, по крайней мере, 4 сотрудника (Min = 4), а максимальное их значение не огра-ничено (Max = N). Аналогично, обозначение (0,1) указывает, что

26

сотрудник не обязательно работает в каком-то из отделений ком-пании (Min1 = 0), но работать одновременно в нескольких филиа-лах он не может (Max1 = 1).

Рис. 1.12. Сущности, связанные двумя связями с ролевыми именами

и кардинальностями связей 1:1 и M:1

Степень участия определяет, зависит ли существование не-которой сущности от участия в связи некоторой другой сущности.

Полная степень участия (или обязательное участие) опре-деляется в том случае, если для существования некоторой сущно-сти требуется существование другой сущности, связанной с ней определенной связью. В противном случае степень участия явля-ется частичной (необязательное участие). Например, в связи «Расположен» между сущностями Сотрудник и Филиал участие сущности Филиал связи является полным, поскольку каждый фи-лиал компании имеет некоторый персонал. Однако поскольку не-которые работники (например, торговые агенты) не относятся ни к какому конкретному отделению компании, то участие сущности Сотрудник в связи «Расположен» является частичным. На ER-диаграммах участники связи с полным участием соединяются со значком связи двойной линией, а участники связи с частичным участием — одинарной (рис. 1.13).

Рис. 1.13. Степень участия сущностей в связи

27

1.7. Преобразование и оптимизация ER-диаграмм

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

На этом этапе выполняются следующие действия: 1) устранение связей типа M:N; 2) устранение сложных связей (степень связи больше 2); 3) устранение рекурсивных связей; 4) устранение связей с атрибутами; 5) устранение множественных атрибутов; 6) перепроверка связей 1:1; 7) удаление избыточных связей. Кратко рассмотрим, как выполняются эти действия. Устранение связей типа M:N. Сначала производится опреде-

ление некоторой промежуточной сущности, как правило слабого типа, поскольку она зависит от сущностей владельцев, «породив-ших» ее. После этого связь типа M:N заменяется двумя связями типа 1:М, устанавливаемыми со вновь созданной сущностью.

Рассмотрим пример: каждый покупатель в магазине приобре-тает товары в нескольких отделах у нескольких продавцов. Связь «Торг» между сущностями «Покупатель» — «Продавец» имеет тип (M:N). Постараемся избавиться от этой связи (рис. 1.14). Вве-дем дополнительную сущность «Сделка» и две одноименные свя-зи: «Участвует». Каждый покупатель может участвовать во мно-жестве сделок, но каждая сделка оформляется только на одного покупателя. Аналогично и продавец: он может совершать множе-ство сделок, но в каждой сделке не может участвовать более одно-го продавца.

Устранение сложных связей осуществляется тоже с помощью промежуточной сущности (как правило, слабого типа). Сложная связь заменяется необходимым количеством бинарных связей типа 1:M, устанавливаемых со вновь созданной сущностью. Преобразуем сложную связь, представленную на рис. 1.10. Добавим слабую сущ-

28

ность Договор-аренда и сформируем три новые связи: «Организует», «Содержит», «Связана с». Результат представлен на рис. 1.15.

Рис.1.14. Связь M:N на ER-диаграммах: а) до устранения; б) после

Рис. 1.15. Фрагмент ER-диаграммы после удаления сложной связи

Устранение рекурсивных связей осуществляется посредст-вом определения некоторой промежуточной сущности (как прави-ло, слабого типа) и введения двух дополнительных связей между вновь созданной и старой сущностями. Например, устраним ре-курсивную связь, представленную на рис. 1.11, посредством вве-дения новой сущности слабого типа Персонал и двух связей — «Руководит» и «Подчиняется». Получим фрагмент диаграммы, представленный на рис. 1.16.

29

Рис. 1.16. Рекурсивная связь после устранения

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

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

Устранение связей с атрибутами осуществляется посредст-вом преобразования такой связи в новую сущность (как правило, слабого типа) и возможным добавлением новых связей.

Устранение множественных атрибутов проводится посред-ством определения новой сущности, в которую включаются воз-можные значения таких атрибутов. Например, на рис. 1.8 пред-ставлена сущность Сотрудник с множественным атрибутом «Телефон». Это означает, что сотрудник может иметь несколько телефонов. Устраним множественную зависимость, введя новую сущность Телефон и новую связь «Имеет». Тогда фрагмент диа-

30

граммы после устранения множественного атрибута будет таким (рис. 1.17).

Рис. 1.17. Устранение множественных атрибутов

1.8. Построение отношений на основе ER-диаграмм

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

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

2. В случае составных атрибутов в отношение включаются только составляющие их простые атрибуты.

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

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

31

5. Для каждой связи типа 1:1, установленной между сущностя-ми E1 и E2, необходимо переслать атрибуты первичного ключа сущности Е1 в отношение, представляющее сущность Е2. Эти ат-рибуты будут использоваться в нем в качестве внешнего ключа. Сущность, которая частично участвует в связи, определяется как родительская, а та сущность, которая участвует в связи полностью, определяется как дочерняя. Если обе сущности участвуют в связи одинаково, то выбор родительской и дочерней сущностей осуще-ствляется произвольно.

6. Для каждой связи типа 1:М, установленной между сущно-стями E1 и E2, необходимо переслать копию атрибутов первично-го ключа сущности Е1 в отношение, представляющее сущность Е2, где они будут играть роль внешнего ключа. Сущность, пред-ставляющая «единичную» сторону связи, определяется как родитель-ская, а сущность, представляющая «множественную» сторону, — как дочерняя.

1.9. Вопросы для самоконтроля

1. Какие существуют типы ассоциаций для представления за-висимости между парами элементов данных?

2. Что представляет собой модель «Сущность-связь»? 3. Как можно классифицировать типы сущностей? 4. Какая диаграмма используется для наглядного отображения

модели сущности? 5. Что такое домен атрибута? 6. На какие категории делятся атрибуты? 7. Что в общем значении подразумевается под ключом? 8. Каким бывает составной ключ? 9. Что представляет собой связь? 10. Если ромб имеет двойной контур, что это значит? 11. Что такое степень связи? 12. Как изображаются атрибуты на диаграмме? 13. Какие связи являются наиболее распространенными? 14. Что соединяется двойной и одинарной линиями на диаграмме?

32

15. Назовите этапы преобразования и оптимизации ER-диаграмм.

16. Что надо создать для каждой слабой сущности при по-строении отношений на основе ER-диаграмм?

17. Что обозначается в виде прямоугольника с двойным конту-ром?

18. Для чего используется проверка связей типа 1:1? 19. В каких случаях связь называется избыточной? 20. Какая сущность является родительской, а какая дочерней?

1.10. Тестовые задания

1. Ассоциации бывают следующих типов: a) условные b) безусловные c) сильные d) слабые

2. Отображение служит для:

a) учета двусторонних связей между сущностями b) исключения дубликатов данных в отношении c) переноса данных из одной таблицы в другую d) переноса данных из таблицы в запрос e) создания зеркальных копий БД

3. Для предметной области «Автопарк» отображение между

сущностями «Номер маршрута» и «Номер машины» имеет вид: a) М:1 b) 1:1 c) 1:М d) М:М e) 1:С f) С:1 g) С:С

33

4. Для предметной области «Университет» отображение меж-ду сущностями «Факультет» и «Кафедра» имеет вид: a) М:1 b) 1:1 c) 1:М d) М:М e) 1:С f) С:1 g) С:С

5. Для предметной области «Школа» отображение между

сущностями «Кабинет» и «Ответственный» (без учета исто-рии изменений) имеет вид: a) М:1 b) 1:1 c) 1:М d) М:М e) 1:С f) С:1 g) С:С

6. В рамках данной предметной области (ПО) данное отобра-

жение между сущностями может иметь тип М:М: a) ПО «Кинематограф», отображение «Фильм» — «Актер» b) ПО «Кинематограф», отображение «Фильм» — «Режис-

сер» c) ПО «Расписание», отображение «Кабинет» — «Класс» d) ПО «Ресторан», отображение «Официант» — «Столик» e) ПО «Кулинария», отображение «Ингредиент» — «Блю-

до»

7. В рамках данной предметной области (ПО) данное отобра-жение между сущностями может иметь тип М:М: a) ПО «Библиотека», отображение «Шифр» — «Книга» b) ПО «Деканат», отображение «Дисциплина» — «Препо-

даватель»

34

c) ПО «Юный химик», отображение «Химический эле-мент» — «Название реакции»

d) ПО «Юный химик», отображение «Химический эле-мент» — «Номер в таблице Менделеева»

e) ПО «Школьный сад», отображение «Дерево» — «Вид»

8. Ключ, состоящий из 2 или более атрибутов: a) составной b) полный c) множественный d) двойной e) атрибутивный

9. Ключ, построенный при помощи отображения М:1:

a) полусоставной b) полностью составной c) полный d) вложенный e) зависимый

10. Из … ключа можно удалить один атрибут, но он при этом

останется ключом: a) полностью составного b) полусоставного c) избыточного d) включенного e) расширенного f) двойного

11. Ассоциации бывают:

a) простые b) сложные c) парные d) одиночные

35

12. На схеме диаграммы «Сущность-связь» атрибуты изобра-жаются в виде: a) прямоугольника b) окружности c) прямой d) эллипса e) ромба f) треугольника

13. Связь на схеме диаграммы «Сущность-связь» может быть

изображена в виде … контуром: a) ромба с двойным b) ромба с пунктирным c) прямоугольника с одиночным d) прямоугольника с двойным e) окружности с двойным f) окружности с пунктирным

14. Основные концепции модели «Сущность — связь» вклю-

чают: a) типы сущностей b) типы данных c) виды отображений d) типы связей e) виды описаний f) атрибуты g) аббревиатуры

15. Домен атрибута — это:

a) мощность множества значений атрибута b) множество значений, которые могут быть присвоены

атрибуту c) крайняя точка области определения атрибута d) множество связей, которые может принимать атрибут e) набор свойств атрибута

36

16. Для ключа допустимы следующие ситуации: a) в его состав может входить несколько атрибутов b) его значения могут совпадать для родственных записей c) его значения могут не совпадать для неродственных за-

писей d) в его состав может входить несколько записей e) его значения могут совпадать для равных доменов f) допускается несовпадение значений ключа и индекса

17. Полностью составной ключ … атрибутов: a) состоит только из составных b) состоит только из многозначных c) состоит только из независимых d) использует только производные e) состоит из полностью разнородных

18. Полусоставной ключ:

a) состоит из неуникальных атрибутов b) построен при помощи отображения М:1 c) построен при помощи отображения М:М d) построен на основе полусоставного запроса e) содержит только производные атрибуты

19. Степень связи — это:

a) количество сущностей, которые охвачены данной свя-зью

b) количество экземпляров сущности, которые вовлечены в связь

c) количество ассоциаций между сущностями d) число рекурсивных ассоциаций сущности e) степень вложенности ассоциаций между сущностями

20. Преобразование и оптимизация диаграммы «Сущность-

связь» подразумевает: a) устранение связей степенью больше двух b) устранение простых связей

37

c) объединение слабых сущностей с сильными d) отождествление ролевых имен с атрибутами связи e) устранение связей с атрибутами

21. Ключевые поля используют для:

a) установления связей между отношениями b) уникальной идентификации записей c) составления запросов d) индексации полей для более надежной работы с за-

писями e) проведения транзакций

22. Атрибут, состоящий из нескольких компонентов, каждый

из которых характеризуется независимым существованием: a) простой b) сложенный из простых c) объединенный d) интегрированный e) составной

23. Атрибут — это:

a) набор значений экземпляра сущности b) свойства типа сущности или связи c) мощности сущности или связи d) имя типа сущности e) набор связей для конкретного экземпляра сущности

24. На схеме диаграммы «Сущность-связь» ключевые атрибу-

ты изображаются в виде: a) эллипса и подчеркивания имени атрибута b) эллипса с одиночным контуром c) окружности с пунктирным контуром d) окружности и подчеркивания имени атрибута e) прямоугольника с двойным контуром f) прямоугольника с пунктирным контуром

38

25. В рамках теории БД и теории диаграмм «Сущность-связь» атрибут может присутствовать у: a) владельца сущности b) таблицы c) дочерней сущности d) сильной сущности e) слабой сущности

Ответы: 1 — a; 2 — a; 3 — c; 4 — c; 5 — b; 6 — a, c, e; 7 — b, c;

8 — a; 9 — a; 10 — c; 11 — a, b; 12 — d; 13 — a; 14 — a, d, f;15 — b; 16 — a; 17 — c; 18 — b; 19 — a; 20 — a, e; 21 — a, b; 22 — e; 23 — b; 24 — a; 25 — c, d, e.

39

2. ЛОГИЧЕСКИЕ МОДЕЛИ ДАННЫХ И НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

2.1. Иерархическая модель

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

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

Два связанных сегмента, расположенных на смежных уровнях, называются исходными (для более высокого уровня) и порожден-ными (для более низкого).

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

В каждой логической структуре БД имеется единственный сегмент, который не зависит ни от какого другого сегмента. Этот сегмент называется головным или корневым. В корневом сегменте обычно располагается идентификатор объекта, свойства которого раскрываются в сегментах второго и более глубоких уровней ие-рархии. Все сегменты одного типа, которые порождены одним и тем же исходным сегментом, называются подобными.

Рассмотрим использование иерархической модели в предмет-ной области «Учет и торговля недвижимостью». Предположим, есть следующие сущности: Филиал, Сотрудник, Жилье, Осмотр, Владелец, Клиент.

40

Для данной предметной области можно составить следующую иерархию типов записей (рис. 2.1).

Филиал

Сотрудник

Осмотр ВладелецКлиент

Жилье

Рис. 2.1. Иерархическая модель

Рассмотрим, как хранится информация для одного экземпляра записи филиала в Пензе с кодом Ф3, с двумя сотрудниками, тремя объектами недвижимости, клиентами и т.д. (рис. 2.2).

Ф3

Петров

Владелец

Пенза ул.Строителей 2

Иван Сидоров Олег Жилье1 Жилье2 Жилье3

Клиент1 Иванов

Клиент2 Быков

РезультатОсмотра1

РезультатОсмотра2

Павлов

. . .. . .

Рис. 2.2. Экземпляр иерархической записи

В иерархической БД хранится упорядоченное множество таких экземпляров записей. Набор всех экземпляров записей одного корня называется единым экземпляром дерева. Для обработки ин-формации в иерархической БД принят навигационный подход, т.е.

41

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

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

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

ную детализацию объектов на различных уровнях представле-ния. Недостатки:

• невозможность хранения экземпляров записей, которые не имеют никаких родительских записей;

• сложность при выполнении операции включения и удаления. • сложность реализации отношения М:N.

2.2. Сетевая модель

Сетевая модель данных используется достаточно давно и оп-ределена в стандарте CODASYL. Используется термин CODASYL-совместимые системы, т.е. системы, поддерживающие сетевую архитектуру [16, 24]. Основной конструкцией сетевой мо-дели является набор [5, 13]. Он представляет собой поименован-ную совокупность записей, образующих двухуровневую иерархи-ческую структуру, причем, один тип записи определяется как «владелец», а другие типы записей являются «членами» набора.

Каждый экземпляр набора состоит из одного экземпляра запи-си «владелец» и одного или более «членов» набора.

Сетевую модель можно представить как граф с записями в ви-де узлов графа и наборами в виде его ребер. Граф является более общей структурой по сравнению с деревом (иерархия), поскольку отдельный узел может иметь произвольное количество родитель-ских узлов, а также произвольное количество подчиненных узлов. Это решает проблему обеспечения связи М:N.

Рассмотрим пример использования сетевой модели (рис. 2.3), используя предметную область, данные об исполнителях и научно-исследовательских работах [13, 24].

42

Рис. 2.3. Сетевая модель

Узлами сети являются отдельные экземпляры записи, которые являются единицей доступа. В дополнение к экземплярам записей-узлов, представляющих исполнителей и темы работ, введен третий тип записи, который называется связью или связующей записью. Экземпляр связующей записи представляет связь между одним исполнителем и одной научно-исследовательской работой темы и содержит данные, описывающие эту связь. В данном примере это количество работ, выполняемых исполнителем. Все экземпляры связующей записи, соответствующие одному исполнителю, поме-щаются в цепочку, начинающуюся и возвращающуюся к этому исполнителю. Аналогичным образом устанавливаются связи для каждой отдельной научной работы (рис. 2.4).

Рис. 2.4. Данные в сетевой модели

43

Основными недостатками сетевой модели данных являются следующие: сложная структура памяти, а также необходимость понижать сложность сетевой модели, а именно, исключать имею-щиеся циклы.

2.3. Реляционная модель

Основа реляционной модели — это реляционные отношения или, попросту, таблицы, т.е. БД в реляционной модели состоит из набора таблиц. Таблицы (отношения) должны удовлетворять сле-дующим ограничениям (требованиям):

1) отношение имеет имя, которое отличается от имен всех дру-гих отношений, используемых в данной предметной области;

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

3) все строки таблицы должны иметь одну и ту же структуру, т.е. одно и то же количество атрибутов с соответственно совпа-дающими именами;

4) имена столбцов должны быть различными, а значения столбцов — однотипными (берутся из одного и того же домена);

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

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

Строки отношений называют кортежами, записями. Столбцы (элементарные типы) часто называют атрибутами

или полями записи. Домен представляет собой множество (набор значений), из ко-

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

Каждое отношение в таблице физически может храниться либо в отдельном небольшом файле, либо в одном большом файле в со-вокупности с другими таблицами. Как правило, в терминологии реляционной модели можно выделять следующие понятия [37] (табл. 2.1).

44

Таблица 2.1

Терминология реляционной модели Уровень абстракции Терминология

Абстрактный уровень Сущность Экземпляр сущ-ности

Свойство сущ-ности

Реляционная модель Отношение Кортеж Атрибут База данных Таблица Строка Столбец Физические данные Файл Запись Поле

Теоретической основой реляционной модели является реляци-

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

1) использование двумерных таблиц для представления струк-тур данных является наиболее простым способом работы с БД;

2) реляционная модель поддается четкой формализации на ос-нове реляционной алгебры;

3) операции проекции, соединения и другие операции позво-ляют легко разрезать и склеивать отношения, получая таким обра-зом новые, производные отношения. Это дает возможность легко извлекать разнообразную информацию из множества таблиц;

4) упрощается контроль доступа и управление правами доступа как к целой таблице, так и к ее отдельным частями, вплоть до ат-рибутов и кортежей;

5) реляционное представление дает ясную картину взаимосвязи атрибутов из различных отношений;

6) физическое размещение таблиц файлов может оказаться не-много проще, чем размещение иерархических и сетевых структур;

7) в реляционной модели значительно проще обеспечить неза-висимость данных;

8) существует возможность добавления, изменения и удаления некоторых атрибутов в таблице, без изменения отношения в це-лом, а также добавления новых отношений без серьезных послед-ствий;

9) в реляционной модели языки манипулирования данных дос-таточно просты и понятны.

45

2.4. Нормализация отношений

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

2.5. Цель нормализации

Основная цель нормализации — создание набора отношений с заданными свойствами:

1) между атрибутами не должно быть нежелательных функ-циональных зависимостей;

2) группировка атрибутов должна обеспечивать минимум дуб-лирования данных.

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

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

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

46

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

Таблица 2.2

Пример неявной избыточности № гостя Комната Телефон

1 12 23–12 2 13 21–13 3 14 24–14 4 12 23–12

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

что один и тот же № телефона имеют гости, живущие в одной комнате. Если поменяется номер у гостя №1, то у гостя № 4 не по-меняется, отсюда следует противоречие: в одной комнате два раз-ных номера.

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

Аномалия удаления в ненормализованных таблицах может при-вести к тому, что при удалении информации об одном объекте бу-дет удалена также информация о каких-то других объектах. На-пример, при необходимости удалить один или несколько атрибутов записи приходится удалять всю запись целиком. Это в

47

свою очередь приводит к исключению информации о данном объ-екте в БД в целом, хотя требовалось удалить лишь некоторую часть информации об объекте (несколько полей записи).

2.6. Типы функциональных зависимостей

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

Пусть даны два атрибута А и В. Атрибут В функционально за-висит от А (обозначается A→B), если каждое значение атрибута А связано только с одним значением атрибута В (в любой момент времени). А и В могут быть составными, т.е. они могут представ-лять собой не единичные атрибуты, а группы, состоящие из двух или более атрибутов.

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

Проанализируем атрибуты «Номер сотрудника» (CNo) и «Должность» для отношения «Сотрудники». Зная значение атри-бута CNo, мы однозначно сможем определить «Должность» дан-ного сотрудника. Однако в обратном направлении мы не можем так сказать, поскольку может быть множество сотрудников с од-ной должностью, т.е. CNo→Должность. Аналогично можно ука-зать, что CNo→ЗП и т.д.

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

48

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

Если в отношении неключевой атрибут функционально зави-сит только от части составного ключа, то говорят о частичной за-висимости.

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

Если для атрибутов А, В, С выполняются условия А→В и В→С, но обратная зависимость отсутствует, то говорят, что С за-висит от А транзитивно (транзитивная зависимость) при усло-вии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С.

В отношениях между атрибутами может существовать еще один тип зависимости − многозначная зависимость. В отношении R атрибут В многозначно зависит от А ( А–>>В ), если каждому значению А соответствует множество значений В, никак не свя-занных с другими атрибутами из R.

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

49

2.7. Нормальные формы

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

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

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

Рассмотрим следующий пример [37]. Пусть в некоторой орга-низации мы получили в качестве исходных данных бумажную форму в виде бланка, заполненного от руки, который восстановлен на рис. 2.5. Каждый такой бланк находится в картотеке клиентов и содержит информацию о некотором клиенте, который проживал по определенным адресам (снимал квартиры).

Страница: 1

Информация о клиенте Дата: 7-10-2002

Имя: Ключов Иван Номер клиента: Ск76 Код собст-венности

Адрес Сдана Освобож-дена

Цена аренды

Вла-де-лец

Имя Вл.

ЖЖ36 ул.М-2 11-09-02 6-10-02 400 Вл46 Дмит-рий

ЖЖ21 ул.D-18 10-01-01 11-11-01 700 Вл87 Кирилл

Рис. 2.5. Бумажная форма с информацией о клиенте

Введем следующие атрибуты: «КлNo» — номер клиента, «КлИмя» — имя клиента, «СобNo» — код собственности, «Адрес» — адрес собственности, «Сдана» — дата сдачи собственности в аренду, «Осв» — дата освобождения собственности, «Цена» — цена аренды, «ВлNo» — код владельца, «ВлИ» — имя владельца.

50

Разработчик БД на основе нескольких таких форм из картотеки клиентов составил таблицу, которая соответствует ННФ (табл. 2.3).

Таблица 2.3

Ненормализованная форма (ННФ) КлN

o КлИмя СобN

o Адрес Сда

на Осв Це-

на ВлN

o ВлИ

Ск76 Иван Ключов

ЖЖ36

ул.М-2

11-09-02

6-10-02

400 Вл46 Дмит-рий

ЖЖ21

ул.D-18

10-01-01

11-11-01

700 Вл87 Ки-рилл

Ск56 Лина Жильцова

ЖЖ16

ул.N-5

1-08-01

1-10-01

560 Вл93 Антон

ЖА14 ул.Н-16

1-10-01

1-11-01


ЖЖ36

ул.М-2

10-01-01

11-11-01


Очевидно, в этой таблице не выполняются условия атомарно-сти значений доменов, поскольку, например, атрибут «СобNo» первой записи содержит одновременно значения ЖЖ36 и ЖЖ21. Поэтому необходимо привести данную таблицу к 1НФ.

Возможны два варианта приведения к 1НФ. Самый простой вариант — разделить одну запись на несколько частей (несколько записей), продублировав при этом значения атрибутов «КлNo» и «КлИмя» на все соответствующие записи. То есть необходимо до-биться, чтобы на пересечении каждой строки и каждого столбца находилось единственное значение (табл. 2.4). Полученное таким способом единственное отношение назовем Сделки.

Таблица 2.4

Отношение «Сделки» в 1НФ КлN

o КлИ-мя

СобNo Адрес Сда-на

Осв Це-на

ВлNo ВлИ

Ск76 Иван Клю-чов

ЖЖ36 ул.М-2

11-09-02

6-10-02


51

Продолжение табл. 2.4 КлN

o КлИ-мя

СобNo Адрес Сда-на

Осв Це-на

ВлNo ВлИ

Ск76 Иван Клю-чов

ЖЖ21 ул.D-18

10-01-01

11-11-01

700 Вл87 Ки-рилл

Ск56 Лина Жиль-цова

ЖЖ16 ул.N-5 1-08-01

1-10-01

560 Вл93 Антон


ЖА14 ул.Н-16

1-10-01

1-11-01



ЖЖ36 ул.М-2

10-01-01

11-11-01


Второй вариант предполагает, что повторяющаяся группа (в данном примере код клиента и его имя) удаляется из данного от-ношения (остается только ключевой атрибут) и помещается в дру-гое отношение вместе с копией исходного ключевого атрибута.

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

Отношение Сделки представлено в 1НФ, поскольку на пересе-чении каждой строки и каждого столбца имеется единственное значение. Однако это отношение будет подвержено аномалиям об-новления. Например, если изменить имя клиента для первой сдел-ки, то возникнет противоречие между именами и их номерами, по-скольку во второй записи для такого же номера клиента останется старое имя. Другой пример аномалии: необходимо изменить арендную плату для жилья ЖЖ36 на улице М-2. Для этого придет-ся обновить две строки (в данном случае первую и последнюю), так как если изменить данные только в одной строке, то БД будет приведена в противоречивое состояние.

Во избежание таких аномалий необходимо привести данное отношение ко второй нормальной форме.

Отношение представлено во второй нормальной форме (2НФ), когда оно находится в 1НФ и каждый атрибут отношения,

52

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

Вторая нормальная форма применяется к отношениям с со-ставными ключами.

Дело в том, что отношение с первичным ключом на основе единственного атрибута всегда находится, по крайней мере, во 2НФ.

Нормализация 1НФ с образованием 2НФ-отношений предпо-лагает устранение частичных зависимостей. Если в отношении между атрибутами существует частичная зависимость, то функ-ционально-зависимые атрибуты удаляются из него и помещаются в новое отношение вместе с копией их детерминанта.

Найдем все функциональные зависимости (ФЗ) в отношении Сделки.

ФЗ1: (КлNo, СобNo) → (Сдана, Осв); ФЗ2: КлNo → КлИмя; ФЗ3: СобNo → (Адрес, Цена, ВлNo, ВлИ); ФЗ4: ВлNo → ВлИ; ФЗ5: (КлNo, Сдана) → (СобNo, Адрес, Осв, Цена, ВлNo,

ВлИ); ФЗ6: (СобNo, Сдана) → (КлNo, КлИмя, Осв). Как видно из первых трех ФЗ потенциальным ключом является

пара атрибутов КлNo, СобNo, поскольку от них зависят все ос-тавшиеся атрибуты отношения. Однако есть еще два потенциаль-ных ключа: (КлNo, Сдана), (СобNo, Сдана). Кроме того, обра-тим внимание на зависимость ФЗ4. Она является транзитивной, поскольку ФЗ3 указывает, что СобNo → ВлNo, т.е. имеем: СобNo→ ВлNo, ВлNo → ВлИ — типичная транзитивная зави-симость.

Выберем в качестве первичного, ключ КлNo, СобNo и нари-суем граф функциональных зависимостей (рис. 2.6) для данного отношения.

53

КлNo СобNo КлИмя Адрес Сдана Осв Цена ВлNo ВлИ

ФЗ1

ФЗ2

ФЗ3

ФЗ5

ФЗ6

(первичный ключ)

(зависимость от части ключа)

(зависимость от части ключа) (транзитивная зависимость)

(потенциальныйключ)

(потенциальный Рис. 2.6. Граф функциональных зависимостей

Из графа функциональных зависимостей видно, что существуют две частичные зависимости ФЗ2 и ФЗ3. Это говорит о том, что отношение Сделки не находится во 2НФ и должно быть к ней преобразовано.

Для этого необходимо создать такие новые отношения, чтобы атрибу-ты, не входящие в первичный ключ, были перемещены в них вместе с ко-пией части первичного ключа, от которого они функционально зависят. Применение этого правила приведет к созданию трех новых отношений: Съемщик, Аренда, Собственник, которые представлены на рис. 2.7.

Съемщик

КлNo КлИмя Ск76 Иван Ключов Ск56 Лина Жиль-

цова Собственник

СобNo Адрес Цена ВлNo ВлИ ЖЖ36 ул.М-2 400 Вл46 Дмит-

рий ЖЖ21 ул.D-18 700 Вл87 Кирилл ЖЖ16 ул.N-5 560 Вл93 Антон ЖА14 ул.Н-16 700 Вл46 Дмит-

рий Рис. 2.7. Примеры отношений во второй нормальной форме (2НФ)

54

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

Отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ и неключевой атрибут транзитивно не зависит от первичного ключа.

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

Выпишем все ФЗ в новых отношения и проанализируем их. Отношение Съемщик: ФЗ2: КлNo → КлИмя; Отношение Аренда: ФЗ1: (КлNo, СобNo) → (Сдана, Осв); ФЗ5: (КлNo, Сдана) → (СобNo, Осв); ФЗ6: (СобNo, Сдана) → (КлNo, Осв). Отношение Собственник: ФЗ3: СобNo → (Адрес, Цена, ВлNo, ВлИ); ФЗ4: ВлNo → ВлИ; В отношениях Съемщик и Аренда нет транзитивных зависимо-

стей. Однако в отношении Собственник оно присутствует, перейдя «по наследству» от отношения Сделки: СобNo → ВлNo, ВлNo → → ВлИ.

Устраним транзитивную зависимость в отношении Собствен-ник, перенеся в отдельное отношение пару атрибутов (ВлNo, ВлИ), оставив копию детерминанта в отношении Собственник. Получим два новых отношения Жилье и Владелец, которые нахо-

55

дятся в 3НФ, поскольку в них нет транзитивных зависимостей (рис. 2.8).

Жилье

СобNo Адрес Цена ВлNo ЖЖ36 ул.М-2 400 Вл46 ЖЖ21 ул.D-18 700 Вл87 ЖЖ16 ул.N-5 560 Вл93 ЖА14 ул.Н-16 700 Вл46

Рис. 2.8. Отношения в третьей нормальной форме (3НФ)

Весь процесс нормализации можно изобразить как декомпози-цию исходного отношения на более мелкие (рис. 2.9).

КлNoКлИмяСобNoАдресСданаОсвЦенаВлNoВлИ

Сделки

КлNoКлИмя

СъемщикСобNoАдресЦенаВлNoВлИ

СобственникКлNoСобNoСданаОсв

Аренда

КлNoКлИмя

СъемщикКлNoСобNoСданаОсв

АрендаСобNoАдресЦенаВлNo

ЖильеВлNoВлИ

Владелец

1НФ

2НФ

3НФ

Рис. 2.9. Процесс декомпозиции отношений

Владелец ВлNo ВлИ Вл46 Дмитрий Вл87 Кирилл Вл93 Антон

56

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

В некоторых случаях достаточно 3НФ для создания надежных информационных систем. Однако иногда разработчики пытаются преобразовать 3НФ к нормальной форме Бойса-Кодда (НФБК). Коддом было доказано, что большинство потенциальных анома-лий добавлений, удалений и добавлений в БД будет устранено в случае должной декомпозиции каждого отношения в НФБК, кото-рая определяется следующим образом: отношение находится в НФБК тогда и только тогда, когда каждый его детерминант яв-ляется потенциальным ключом.

Все предыдущие НФ рассматривали зависимость только от первичного ключа, в НФБК учитываются функциональные зави-симости, в которых участвуют потенциальные ключи отношения. Для отношения с единственным потенциальным ключом его 3НФ и НФБК являются эквивалентными.

Итак, для проверки принадлежности отношения к НФБК необ-ходимо найти все его детерминанты и убедиться в том, что они яв-ляются потенциальными ключами.

Различие между 3НФ и НФБК заключается в том, что функ-циональная зависимость A→B допускается в 3НФ-отношении, ес-ли атрибут В является первичным ключом, а атрибут А необяза-тельно является потенциальным ключом. В НФБК-отношении эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом, т.е. НФК является жесткой версией 3НФ, поскольку каждое НФБК-отношение является 3НФ-отношением, но не всякое 3НФ-отношение является НФБК-отношением.

Заметим, что бывают ситуации, когда нежелательно преобра-зовывать отношение к НФБК, а лучше остановиться на 3НФ. На-пример, декомпозиция нежелательна, если детерминант и опреде-

57

ляемые им атрибуты помещаются в разные отношения. Разработ-чик должен принимать решение, выбирая лучшее решение между лишней избыточностью данных в 3НФ и возможной потерей неко-торых функциональных зависимостей в НФБК.

Для нашего примера отношения Жилье, Владелец, Съемщик, очевидно, находятся в НФБК, поскольку каждое из них имеет один детерминант, который является потенциальным ключом этого от-ношения. В отношении Аренда имеется три детерминанта: (КлNo, СобNo), (КлNo, Сдана), (СобNo,Сдана), которые являются потенциальными ключами. Поэтому отношение Аренда также на-ходится в НФБК.

Нарушение НФБК происходит достаточно редко, поскольку это может случиться только тогда, когда:

1) имеются два (или более) составных потенциальных клю-ча);

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

Приведем пример, когда отношение может не удовлетворять требованиям НФБК. Опишем кратко предметную область.

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

Отношение «Интервью клиентов» может выглядеть так (табл. 2.4).

Таблица 2.4

Пример отношения «Интервью клиентов» КлNo ДатаИнтервью ВремяИнтервью КодСотрудника Комната Кл76 13.06.2002 10:30 С5 Г131 Кл56 13.06.2002 12:00 С5 Г131 Кл74 13.06.2002 12:00 С37 Г128 Кл56 1.09.2002 10:30 С5 Г128

Функциональные зависимости: ФЗ1: (КлNo, ДатаИнтервью) → (ВремяИнтервью, Код-

Сотрудника, Комната);

58

ФЗ2: (КодСотрудника, ДатаИнтервью, ВремяИнтер-вью) → ( КлNo );

ФЗ3: (Комната, ДатаИнтервью, ВремяИнтервью) → → (КодСотрудника, КлNo );

ФЗ4: (КодСотрудника, ДатаИнтервью) → (Комната); Выделим ключи: ФЗ1 — первичный ключ, ФЗ2, ФЗ3 — потен-

циальные ключи, т.е. детерминат ФЗ4 КодСотрудника, Дата-Интервью не является потенциальным ключом и тем самым на-рушает требование НФБК. Аномалия обновления возникает, если необходимо на 13.06.2002 изменить комнату для проведения ин-тервью с сотрудником C5. Чтобы избежать противоречивости дан-ных нужно произвести изменения в двух записях.

Для преобразования отношения к НФБК разобьем его на от-ношения Интервью и Комнаты, выделив атрибуты, входящие в ФЗ4 в отношение Комнаты (рис. 2.10).

Интервью КлNo ДатаИнтервью ВремяИнтервью КодСотрудника Кл76 13.06.2002 10:30 С5 Кл56 13.06.2002 12:00 С5 Кл74 13.06.2002 12:00 С37 Кл56 1.09.2002 10:30 С5 Комнаты КодСотрудника ДатаИнтервью Комната С5 13.06.2002 Г131 С37 13.06.2002 Г128 С5 1.09.2002 Г128

Рис.2.10. Пример отношений в НФБК.

В заключение этого раздела приведем определения нормаль-ных форм более высокого уровня [16].

Отношение находится в 4НФ тогда и только тогда, когда оно находится в НФБК и при наличии многозадачной зависимости А–>>В все атрибуты данного отношения также функционально зависят от А.

Отношение находится в 5НФ, если в нем нет зависимостей со-единения. Зависимость соединения — это свойство декомпозиции

59

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


1. В чем заключается иерархическая модель данных? 2. Что такое иерархическая запись? 3. Назовите достоинства иерархической модели. 4. Что представляет собой набор? 5. Из чего состоит каждый экземпляр набора? 6. Назовите недостатки сетевой модели данных. 7. Что является основой реляционной модели? 8. Что такое сегмент? 9. Какой сегмент называется головным? 10. Как называют строки отношений? 11. Назовите основные достоинства реляционного подхода. 12. Что такое нормализация отношений? 13. В чем заключается цель нормализации? 14. Почему в БД следует использовать только нормализован-

ные отношения? 15. Как может характеризоваться избыточность? 16. В чем заключается аномалия добавления? 17. В чем заключается аномалия удаления? 18. Что такое декомпозиция? 19. Назовите все функциональные зависимости. 20. Что такое ненормализованная форма? 21. Какое отношение может находиться в первой нормальной

форме? 22 К каким отношениям применяется вторая нормальная форма? 23. Какое отношение может находиться в третьей нормальной

форме? 24. Что такое НФБК? 25. В чем заключаются различия между 3НФ и НФБК? 26. В каких случаях может произойти нарушение НФБК?

60


1. Данные в … модели представлены как коллекция записей (сег-ментов), связанных между собой в древовидную структуру:

a) иерархическую b) сетевую c) реляционную d) графовую e) сущностною

2. Иерархическая модель оперирует с понятием:

a) сегмент b) набор c) узел d) нод e) поле

3. В иерархической модели, единственный сегмент, который

не зависит от всех остальных называется: a) исходным b) данным c) источником данных d) корневым e) источником записей f) источником сегментов

4. Если основной концепцией модели является отношение, то

эта модель является: a) сетевой b) сущностной c) реляционной d) иерархической e) древовидной

5. В списке лишним является термин:

a) запись b) поле

61

c) столбец d) атрибут

6. В основе реляционной модели данных лежит понятие:

a) отношение b) таблица c) набор d) иерархия e) связь f) экземпляр данных

7. Основной конструкцией сетевой модели является:

a) связь b) отношение c) набор d) ассоциация e) источник связи

8. Модель, которую можно представить как граф с записями в

виде узлов и наборами в виде ребер: a) сущностная b) сетевая c) иерархическая d) древовидная e) графовая f) топологическая g) реляционная

9. Для обеспечения связи между владельцами и членами на-

бора в сетевой модели используется: a) третий тип записи — связующая запись b) ссылка на атрибуты владельца у всех экземпляров набора c) введение учетной записи в каждый набор d) ссылка на все вложенные атрибуты у записи-владельца e) ссылка на атрибуты подчиненных записей у владельца

62

10. На рисунке изображен фрагмент:

a) сетевой модели b) иерархической записи c) логической записи d) диаграммы «Сущность-связь» e) реляционной модели

11. Кортеж — это:

a) запись b) строка таблицы c) столбец d) область определения атрибута e) источник записей

12. На рисунке изображен фрагмент:

63

a) диаграммы «Сущность-связь» b) иерархической записи c) логической записи d) сетевой модели e) реляционной модели

13. В один экземпляр набора входит: a) один экземпляр записи-владельца b) один или более экземпляров записи-владельца c) один или ни одного экземпляра записи-владельца d) один или более экземпляров записи-члена e) не более одного экземпляра записи-члена

14. Все сегменты одного типа, порожденные одним и тем же

исходным сегментом, называются: a) родственными b) подобными c) равнозначными d) устойчивыми e) одноранговыми

15. На рисунке сегмент «Жилье» является для сегмента «Фи-лиал»:

a) починенным b) порожденным c) исходным d) вложенным e) включенным

16. На рисунке сегмент «Жилье» является для сегмента «Ос-

мотр»:

64

a) базовым b) порожденным c) исходным d) вложенным e) включенным

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

a) все данные сводятся в одну общую таблицу b) устранены все зависимости 1:1 c) устранены все зависимости 1:М d) все данные охвачены одной связью с минимальным ко-

личеством атрибутов e) устранены все нежелательные функциональные зависи-

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

18. В основе операции нормализации лежит понятие:

a) редукции b) абдукции c) декомпозиции d) абстрагирования e) изоморфизма

65

19. Избыточность данных опасна тем, что: a) трудно совершать корректное обновление данных b) могут возникнуть «забытые» данные при удалении c) извлечение избыточных данных может привести к пе-

реполнению буфера d) поиск избыточных данных содержит противоречия e) взаимоисключающие значения атрибутов нельзя обна-

ружить 20. Явная избыточность данных заключается в том, что:

a) одни и те же значения одного или нескольких атрибутов могут появиться в отношении несколько раз

b) одна и та же запись появляется в отношениях более од-ного раза

c) источник данных часто генерирует одинаковые значе-ния

d) данные повторяют друг друга в запросах e) сервер хранит одинаковые отношения

21. Первая нормальная форма заключатся в том:

a) в каждой ячейке таблицы — только одно значение b) в каждой строке таблицы — только одно значение c) в каждом столбце таблицы — только одно значение d) домен каждого атрибута содержит не более одного зна-

чения e) домен каждого атрибута содержит только атомарные

значения 22. MSAccess изначально создает отношения в следующей

нормальной формальной: a) первой b) второй c) третей d) четвертой e) ненормализованной f) Бойса-Кодда

66

23. Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и:

a) отсутствуют возможности разбиения атрибутов на бо-лее мелкие

b) дальнейшая детальная декомпозиция доменов атрибу-тов невозможна

c) дальнейшая детальная декомпозиция связей вида 1:М невозможна

d) все условные связи заменены на связи 1:С e) каждый атрибут отношения, не входящий в состав пер-

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

f) каждый атрибут отношения, составляющий первичный ключ, характеризуется полной функциональной зависи-мостью от первично ключа

24. Об отношении с первичным ключом, состоящим из един-

ственного атрибута можно сказать, что: a) никакое дальнейшее разбиение атрибутов невозможно b) отношение находится по крайней мере во второй нор-

мальной форме c) отношение находится по крайней мере во третей нор-

мальной форме d) нормальная форма отношения не превышает первую e) отношение не имеет нормальных форм

25. Совпадение 3-й нормальной формы и нормальной формы

Бойса-Кодда: a) невозможно для реляционных БД b) возможно при условии совпадения 1 и 2 нормальных

форм c) возможно при условии совпадения 2 и 3 нормальных

форм d) возможно для отношений с полнофункциональным

ключом

67

e) возможно для отношений с единственным потенциаль-ным ключом

26. Отношение находится в форме Бойса-Кодда тогда и только тогда, когда:

a) каждый его детерминант является потенциальным клю-чом

b) все его детерминанты составные c) все его ключи первичны d) всякий его детерминант полнофункционален e) каждый его первичный ключ является потенциальным

детерминантом 27. Преобразование к третьей нормальной форме из второй

нормальной формы подразумевает: a) дополнение связей между атрибутами до полной функ-

циональной зависимости b) устранение транзитивных зависимостей атрибутов c) устранение полных функциональных зависимостей ме-

жду атрибутами d) удаление транзитивно связанных данных e) объединение транзитивно связанных данных в один ат-

рибут 28. Номер нормальной формы в которой находится приведен-

ная таблица (0 — для ненормализованной формы): Название предмета

Дата экзамена

Количество сдающих

Преподава-тель

История 11.11.2003 12.11.2003 12.11.2003

9 6 7

Петров Петров Свиридов

Химия 10.11.2003 12.11.2003

3 6

Иванов Иванов

a) 3 b) 1 c) 2 d) 0 e) НФБК

68

29. Номер нормальной формы, в которой находится приведен-ная таблица (0 — для ненормализованной формы):

Название предмета

Дата экзамена

Количество сдающих


История 12.11.2003 9 Свиридов История 11.11.2003 5 Петров История 12.11.2003 8 Петров Химия 10.11.2003 3 Иванов Химия 12.11.2003 6 Иванов

a) 0 b) 1 c) 2 d) 3 e) НФБК

30. Данная реляционная модель предметной области «Зоо-

парк» находится в следующей нормальной форме:

a) 0

b) 1 c) 2 d) 3 e) НФБК

31. Данная реляционная модель предметной области «Зоо-парк» находится в следующей нормальной форме:

69

a) 0 b) 1 c) 2 d) 3 e) НФБК

Ответы: 1 — a; 2 — a; 3 — d; 4 — c; 5 — a; 6 — a, b; 7 — c;

8 — b; 9 — a; 10 — b; 11 — a, b; 12 — d; 13 — a, d; 14 — b; 15 — b; 16 — c; 17 — e, f; 18 — c;19 — a, b;20 — a; 21 — a, e;22 — a; 23 — e; 24 — b; 25 — e; 26 — a; 27 — b; 28 — d; 29 — b; 30 — c; 31 — e.

70

4. ЭЛЕМЕНТЫ РЕЛЯЦИОННОЙ АЛГЕБРЫ

4.1. Основные понятия

Введем основные понятия [16], которые будут использоваться далее в этом разделе. Некоторые из них уже вводились ранее, по-этому приводимые ниже определения лишь уточняют их исполь-зование в реляционной алгебре.

Отношение — «плоская» таблица, состоящая из строк, удовле-творяющих определенным условиям (см. требования к отношени-ям в предыдущем разделе).

Атрибут — поименованный столбец отношения. Кортеж — строка отношения. Степень отношения — количество атрибутов, которое оно со-

держит. Кардинальность отношения — количество кортежей в отноше-

нии. Реляционная БД — набор нормализованных отношений. Домен — набор допустимых значений для одного или нескольких

атрибутов, т.е. каждый атрибут определяется на некотором домене. Пример задания атрибутов и их доменов приведен в табл. 3.1.

Таблица 3.1 Атрибуты и домены

Атрибут Имя домена Содержание домена

Определение домена

Фno BRANCH_NUM Множество всех до-пустимых номеров филиалов компании

Символьный; 3 символа, диапазон Ф1-Ф99

Улица STREET_NAME Множество всех на-званий улиц

Символьный; 25 символов

TelNo TELFAX_No Множество всех номеров телефонов


ФаксNo TELFAX_No Множество всех номеров факсов


71

Пусть nDDD ,...,, 21 — некоторые множества. Тогда любое под-множество декартового произведения n множеств вида

( ){ }iinni

n

iDddddDDDD ∈=×⋅⋅⋅××=×

=,...,., 21211

является отношением. При этом nDDD ,...,, 21 называются до-менами.

Пример. Пусть { }0902011 ,, ФФФD = , { }ДьяковИвановСидоровПетровD ,,,2 = , { }ийНекрасовскперЛенинаулD .,.3 = .

Тогда кардинальность декартового произведения 24321 =×× DDD , а отношение 321 DDD ×× будет следующим

(табл. 3.2):

Таблица 3.2

Пример результата декартова произведения ФNo ( 11 Dd ∈ ) Фамилия ( 22 Dd ∈ ) Улица (

33 Dd ∈ )

Ф01 Петров Ул.Ленина Ф01 Петров Пер.Некрасовский Ф01 Сидоров ул.Ленина Ф01 Сидоров Пер.Некрасовский Ф01 Иванов ул.Ленина Ф01 Иванов Пер.Некрасовский Ф01 Дьяков ул.Ленина Ф01 Дьяков Пер.Некрасовский Ф02 Петров ул.Ленина Ф02 Петров Пер.Некрасовский Ф02 Сидоров ул.Ленина Ф02 Сидоров Пер.Некрасовский Ф02 Иванов ул.Ленина Ф02 Иванов пер.Некрасовский Ф02 Дьяков ул.Ленина Ф02 Дьяков пер.Некрасовский Ф09 Петров ул.Ленина Ф09 Петров пер.Некрасовский Ф09 Сидоров ул.Ленина Ф09 Сидоров пер.Некрасовский

72

Продолжение табл. 3.2 ФNo ( 11 Dd ∈ ) Фамилия ( 22 Dd ∈ ) Улица (

33 Dd ∈ )

Ф09 Иванов ул.Ленина Ф09 Иванов пер.Некрасовский Ф09 Дьяков ул.Ленина Ф09 Дьяков пер.Некрасовский

На этом отношении можно задать множество других отноше-ний, являющихся его подмножеством. Например, зададим отно-шение:

Адрес_Филиала(ФNo,Фамилия,Улица) = { (Ф01,Петров,пер.Некрасовский), (Ф02,Иванов,ул.Ленина), (Ф09,Иванов,ул.Ленина) }.

Иногда для того чтобы подчеркнуть наличие того или иного атрибута в отношении указывают пары атрибут-значение. В этом случае отношения записывают в виде множества кортежей { }):,...,:( 11 nn dAdA , где Ai — атрибуты отношения, di — значение ат-рибута.

Реляционная схема — имя отношения, за которым в круглых скобках следует множество пар атрибутов и доменов: ( )nn DADAR :,...,: 11 . Или в более простом виде: ( )nAAR ,...,1 . Реляционная алгебра — язык операций, которые на основе од-

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

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

Основные операции: • выборка, • проекция, • декартово произведение, • объединение, • разность.

73

Дополнительные операции: • соединение, • пересечение, • деление.

Операции выборки и проекции унарные, остальные — бинарные. Пусть R и S — отношения. Рассмотрим схематично отношение

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

Рис. 3.1. Схематичное изображение операций реляционной алгебры

3.2. Пример реляционных отношений

Для демонстрации основных операций реляционной алгебры рассмотрим некоторые отношения, являющиеся результатом про-ектирования БД для предметной области — автоматизация дея-тельности фирмы по работе с недвижимостью («Учет недвижимо-сти») [37].

Схема взаимосвязи отношений представлена на рис. 3.2. Пусть имеются следующие отношения (их содержание и на-

полнение данными приведено ниже в таблицах на рис. 3.3). 1. Филиал (ФNo, Улица, Область, Город, Индекс, Телефон,

Факс) — информация о координатах филиала фирмы по рабо-те с недвижимостью.

74

2. Сотрудники (CNo, Имя, Фамилия, Адрес, Телефон, Должность, Пол, Дата рождения, ЗП, Паспорт, ФNo) — информация о сотрудниках фирмы, работающих в разных фи-лиалах.

3. Жилье (Жno, Улица, Область, Город, Индекс, Тип, Ком-наты, Плата, ВлNo, CNo, ФNo) — информация о сдаваемом жилье (недвижимости) по различным филиалам.

4. Съемщик (СкNo, Имя, Фамилия, Адрес, Телефон, Нуж_тип, max_плата, ФNo) — информация о съемщиках (арендаторах) жилья: кому, где и какое жилье требуется.

5. Владелец (ВлNo, Имя, Фамилия, Адрес, Телефон) — ин-формация о владельцах сдаваемого жилья или недвижимости.

6. Осмотр (СкNo, ЖNo, Дата, Комментарий) — информация об осмотре жилья съемщиками с их комментариями относи-тельно этого жилья.

ФNoФилиал

СnoФNo

Сотрудники

СкNoФNo

Съемщик ЖNoВлNoСNoФNo

Жилье

ВлNoВладелец

СкNoЖNo

Осмотр

Рис. 3.2. Схема взаимосвязей для примера из предметной области

Филиал ФNo Улица Область Город Индекс Телефон Факс

Ф5 Дворцовая 22

Московская Москва 332211 6655440 6655450

Ф7 Артемовская 16

Донецкая Донецк 998877 2215150 2215160

Ф3 Морской 163

Пензенская Пенза 887766 6216220 6216230

Ф4 Морзе 32 Липецкая Липецк 776655 2412410 2412420 Ф2 Центральная

56 Московская Москва 366666 8138150 8138140

75

Сотрудники

Жилье ЖNo

Ули- ца

Об-ласть

Город Ин-декс

Тип Ком-наты

Пла- та

ВлNo

СNo

ФNo

ЖА14

ул. Н-16

Астра-ханская

Аст-рахань

343434

Дом 6 650 Вл46

4 Ф7

ЖЛ94

ул. А-6

Мос-ковская

Моск-ва

343435

Кв. 4 400 Вл87

6 Ф5

ЖЖ4

ул. L-6

Пензен-ская

Пенза 343436

Кв. 3 350 Вл40

3 Ф3

ЖЖ36

ул. М-2


Пенза 343437

Кв. 3 375 Вл93

2 Ф3

ЖЖ21

ул. D-18


Пенза 343438

Дом 5 600 Вл87

2 Ф3

ЖЖ16

ул. N-5


Пенза 343439

Кв. 4 450 Вл93

3 Ф3

Съемщик СкNo Имя Фамилия Адрес Телефон Нуж_

тип Мах_ плата

ФNo

Ск76 Иван Ключов ул. Н−56 6211110 Кв. 425 Ф5 Ск56 Лина Жильцова ул. F−64 6211120 Кв. 350 Ф3 Ск74 Михаил Рышков ул. Т−18 6211130 Дом 750 Ф3 Ск62 Мария Третьякова ул. Т−5 6211140 Кв. 600 Ф7

76

Осмотр СкNo Жno Дата Комментарий Ск56 ЖА14 2.05.98 Слишком мала Ск76 ЖЖ4 20.04.98 Слишком далеко Ск56 ЖЖ4 26.05.98 Ск62 ЖА14 14.05.98 Нет столовой Ск56 ЖЖ36 28.04.98

Рис. 3.3. Пример отношений для задачи «Учет недвижимости».

3.3. Операции реляционной алгебры

3.3.1. Выборка (или ограничение)

Обозначение операции: σпредикат(R). Операция является унарной и определяет результирующее отно-

шение, которое содержит только те кортежи (строки) отношения R, которые удовлетворяют заданному условию (предикату).

Например, необходимо составить список всех сотрудников с заработной платой, превышающей 10 000 рублей. Это достигается с помощью следующего оператора реляционной алгебры:

σзп>10000 (Сотрудники). Результатом будут строки отношения «Сотрудники» с номерами сотрудников 1, 2, 3, 5 (CNo={1, 2, 3, 5}).

3.3.2. Проекция

Обозначение операции: Патр1,…,атрN(R). Операция проекции работает с одним отношением R и определя-

ет новое отношение, содержащее вертикальное подмножество отно-шения R, создаваемое посредством извлечения значений указанных атрибутов и исключения из результата строк-дубликатов (рис. 3.4).

77

Рис. 3.4. Пример вычисления проекции

Например, создать ведомость ЗП всех сотрудников компании с указанием атрибутов: CNo, Имя, Фамилия, ЗП. Этого можно дос-тичь с помощью следующего оператора реляционной алгебры:

ПCNo,Имя,Фамилия,ЗП(Сотрудники).

3.3.3. Декартово произведение

Обозначение операции: R×S. Операция декартового произведения определяет новое отно-

шение, которое является результатом конкатенации (т.е. сцепле-ния) каждого кортежа из отношения R с каждым кортежем из от-ношения S.

Операторы выборки и проекции извлекают информацию только из одного отношения. Очевидно, возможно возникновение таких си-туаций, когда нужна некоторая комбинация данных из нескольких отношений. Оператор декартового произведения умножает два от-ношения, что в результате приводит к созданию другого отношения, состоящего из всех возможных пар кортежей обоих отношений. Сле-довательно, если одно отношение имеет I кортежей и N атрибутов, а другое — J кортежей и М атрибутов, то отношение с их декартовым произведением будет содержать I×J кортежей и N+M атрибутов. Ис-ходные отношения могут содержать атрибуты с одинаковыми име-нами. В таком случае имена атрибутов будут содержать названия от-ношений в виде префиксов для обеспечения уникальности имен атрибутов в отношении, полученном как результат выполнения опе-рации декартового произведения.

Пример. Необходимо создать список всех съемщиков, которые осматривали объекты с указанием сделанных ими комментариев: ПСкNo,Имя,Фамилия (Съемщик)×ПСкNo,ЖNo,Комментарий (Осмотр) (табл. 3.3).

78

Таблица 3.3

Результат выражения ПСкNo,Имя,Фамилия(Съемщик)×ПСкNo,ЖNo,Комментарий(Осмотр)

Съемщик. СкNo

Имя Фамилия Осмотр. СкNo

ЖNo Комментарий

1 СК76 Иван Ключов СК56 ЖА14 Слишком мала

2 СК76 Иван Ключов СК76 ЖЖ4 Слишком далеко

3 СК76 Иван Ключов СК56 ЖЖ4

4 СК76 Иван Ключов СК62 ЖА14 Нет столовой

5 СК76 Иван Ключов СК56 ЖЖ36

6 СК56 Ирина Жильцова СК56 ЖА14 Слишком мала

7 СК56 Ирина Жильцова СК76 ЖЖ4 Слишком далеко

8 СК56 Ирина Жильцова СК56 ЖЖ4

9 СК56 Ирина Жильцова СК62 ЖА14 Нет столовой

10 СК56 Ирина Жильцова СК56 ЖЖ36

11 СК74 Михаил Рыжков СК56 ЖА14 Слишком мала

12 СК74 Михаил Рыжков СК76 ЖЖ4 Слишком далеко

13 СК74 Михаил Рыжков СК56 ЖЖ4

14 СК74 Михаил Рыжков СК62 ЖА14 Нет столовой

15 СК74 Михаил Рыжков СК56 ЖЖ36

16 СК62 Мария Третьякова СК56 ЖА14 Слишком мала

17 СК62 Мария Третьякова СК76 ЖЖ4 Слишком далеко

18 СК62 Мария Третьякова СК56 ЖЖ4

19 СК62 Мария Третьякова СК62 ЖА14 Нет столовой

20 СК62 Мария Третьякова СК56 ЖЖ36

79

Полученное отношение избыточно и содержит лишние записи, например: записи с разными значениями атрибута CкNo для ис-ходного запроса не имеют смысла. Поэтому применим к получен-ному отношению операцию выборки:

σСъемщик.СкNo=Осмотр.СкNo(ПСкNo,Имя,Фамилия(Съемщик) × × ПСкNo,ЖNo,Комментарий(Осмотр)).

В результате будут выбраны записи с номерами строк 2, 6, 8, 10, 19.

3.3.4. Объединение

Обозначение операции: R∪S. Объединение отношений R и S с кортежами I и J соответствен-

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

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

Пример. Создать список областей, где имеется филиал компании или объект недвижимости. Для получения результата применим следующую формулу: ПОбласть(Филиал)U ПОбласть(Жилье).

Получим отношение: R(Область)={Московская, Донецкая, Пензенская, Липец-

кая, Астраханская}.

3.3.5. Разность

Обозначение операции: R−S. Разность двух отношений R и S состоит из кортежей, которые

имеются в отношении R, но отсутствуют в отношении S. Причем от-ношения R и S должны быть совместимы по объединению.

Пример. Создать список всех городов, в которых есть отделение компании, но нет объектов недвижимости, сдаваемых в аренду:

Пгород(Филиал)-Пгород(Жилье)=R (Город)= {Донецк, Липецк}.

80

3.3.6. Операции соединения

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

Ниже перечислены различные типы операций соединения, ко-торые несколько отличаются друг от друга и могут быть в той или иной степени полезны: • тета-соединение (θ-join); • соединение по эквивалентности (equi-join), которое является

частным видом тета-соединения; • естественное соединение (natural join); • внешнее соединение (outer join); • полусоединение (semi-join).

3.3.7. Тета-соединение (θ-join)

Обозначение операции: SR F>< . Операция тета-соединения определяет отношение, которое со-

держит кортежи из декартового произведения отношений R и S, удовлетворяющие предикату F. Предикат F имеет вид R.ai θ S.bi, где вместо θ может быть указан один из операторов сравнения (<, <=, >, >=, = или ~=).

81

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

)( SRSR FF ×= σ>< . Так же как и в случае с декартовым произведением, степенью

тета-соединения называется сумма степеней операндов-отношений R и S. Если предикат F содержит только оператор равенства (=), то соединение называется соединением по эквивалентности (equi-join).

Пример. Создать список всех съемщиков, которые осматривали объекты недвижимости с указанием их имен и сделанных ими комментариев:

ПСкNo,Имя,Фамилия(Съемщик) СкNoОсмотрСкNoСъемщик .. =>< ПСкNo,ЖNo,Комментарий(Осмотр).

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

3.3.8. Естественное соединение

Обозначение операции: SR >< . Естественным соединением называется соединение по эквива-

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

Степенью естественного соединения называется сумма степе-ней операндов-отношений R и S минус количество атрибутов x.

3.3.9. Внешнее соединение

Обозначение операции: SR <⊃ . Зачастую при соединении двух отношений кортеж из одного

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

82

Левым внешним соединением называется соединение, при ко-тором кортежи отношения R, не имеющие совпадающих значений в общих столбцах отношения S, также включаются в результи-рующее отношение.

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

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

Пример. Пусть даны два отношения T1, T2 (рис. 3.5).

Рис.3.5. Исходные отношения T1, T2

Тогда получаем (рис. 3.6): левое и правое внешнее соединение

83

L = T1 <⊃ T2:

P = Т1 ⊂> Т2:

Рис. 3.6. Пример нахождения левого и правого внешнего соединений

Таким образом, можно сделать следующие заключения. Полное внешнее соединение — это объединение левого и

правого внешних соединений, т.е LU P. Естественное соединение — это пересечение левого и правого

внешних соединений, т.е. L I P. Пример. Создать отчет о ходе проведения осмотров объектов

недвижимости. Ответ: ПЖNo,Улица, Город(Жилье) <⊃ (Осмотр).

Результат будет следующим.

ЖNo Улица Город СкNo Дата Комментарий ЖА14 Ул.Н-16 Астрахань Ск56 2.05.98 Слишком мала ЖА14 Ул.Н-16 Астрахань Ск62 14.05.98 Нет столовой ЖЛ94 Ул.А-6 Москва NULL NULL NULL ЖЖ4 Ул.L-6 Пенза Ск76 20.04.98 Слишком далеко ЖЖ4 Ул.L-6 Пенза Ск56 26.05.98 ЖЖ36 Ул.М-2 Пенза Ск56 28.04.98 ЖЖ21 Ул.D-18 Пенза NULL NULL NULL ЖЖ16 Ул.N-5 Пенза NULL NULL NULL

84

3.3.10. Полусоединение

Обозначение операции: SR F> . Операция полусоединения определяет отношение, которое со-

держит те кортежи отношения R, которые входят в соединение от-ношений R и S.

Преимущество полусоединения заключается в том, что оно по-зволяет сократить количество кортежей, которые нужно обрабо-тать для получения соединения. Это особенно полезно при вычис-лении соединений в распределенных системах. Операцию полусоединения можно сформулировать и с помощью операторов проекции и соединения: ( )∏= A FF SRSR ><> .

Здесь А — это набор всех атрибутов в отношении R. На самом деле, это полутета-соединение, причем следует отметить, что су-ществуют полусоединения по эквивалентности и полуестествен-ные соединения.

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

Замечание. В этом запросе необходимы только атрибуты от-ношения «Сотрудники» (т.е. нужно сделать полусоединение с от-ношением «Филиал»), (табл. 3.4).

Пусть F = . .. ' '

Сотрудники ФNo Филиал ФNoANDФилиал Область Пензенская

==

Тогда получим выражение: Сотрудники F> Филиал.

Таблица 3.4

Результат вычисления полусоединения СNo

Имя

Фа- ми- лия

Адрес Те-ле- фон

Долж-ность

Пол

Д. р.

ЗП Пас- порт

ФNo

2 Ан-на

Бе-режная

ул. Х-81, Пенза

2222220

Старший ассистент

Ж 10.11.60

12000

XII- 4555

Ф3

85

Окончание табл. 3.4 СNo

Имя Фа- ми- лия

Адрес Те-ле-фон

Долж- ность

Пол

Д. р.

ЗП

Пас- порт

ФNo

3 Да-вид

Фор- дов

ул. Z- 63, Пенза

3333330

Агент М 24. 03. 58

18000

X- 6366

Ф3

5 Сю-зан-на

Бод- рова

ул.С- 5, Пенза

5555550

Мене- джер

Ж 3. 06. 40

24000

XXL- 1234

Ф3

3.3.11. Пересечение

Обозначение операции: R∩S. Операция пересечения определяет отношение, которое содер-

жит кортежи, присутствующие как в отношении R, так и в отно-шении S. Отношения R и S должны быть совместимы по объеди-нению.

Пересечение можно сформулировать и на основе оператора разности множеств: R∩S = R–(R– S).

Пример. Указать суммы, соответствующие совпадению спроса и предложения, т.е. такие суммы, для которых совпадают стои-мость оплаты жилья и стоимость, которую может заплатить за жи-лье съемщик: ППлата(Жилье) ∩ ПMaxплата(Съемщик). Результатом будут две строки с цифрами 350, 600.

3.3.12. Деление

Обозначение операции: R÷S. Оператор деления может быть полезен в случае запросов осо-

бого типа, которые довольно часто встречаются в приложениях БД. Предположим, что отношение R определено на множестве ат-рибутов А, а отношение S — на множестве атрибутов В, причем В⊆А (т.е. В является подмножеством А). Пусть С = А−В, т.е. С яв-ляется множеством атрибутов отношения R, которые не являются атрибутами отношения S. Тогда определение оператора деления будет выглядеть следующим образом.

86

Результатом оператора деления является набор кортежей от-ношения R, определенных на множестве атрибутов С, которые со-ответствуют комбинации всех кортежей отношения S.

Этот оператор можно сформулировать и на основе других ос-новных операторов. Схематично эту операцию можно изобразить так (рис.3.7).

T1=ПС(R) ; T2=ПС((S×T1) − R) ; T= R÷S = T1 − T2.

Рис.3.7. Графическая иллюстрация операции деления отношений

Пример 1. Даны отношения со схемами: V(A,B) и W(B). Най-дем V ÷ W.

V W V ÷ W

А В а 1 а 2 b 1 b 2 c 1

Пример 2. Создать список всех съемщиков, которые осматри-

вали объекты недвижимости с тремя комнатами. Разобьем реше-ние на несколько шагов:

а) с помощью оператора выборки находим все трехкомнатные объекты недвижимости:

A a b

B 1 2

87

ЖNo

ЖЖ4 ЖЖ36

ПЖNо(σ комнаты=3(Жилье));

б) с помощью проекции получаем отношение, содержащее только номера объектов недвижимости и личные номера съемщи-ков: ПСкNо, ЖNо (Осмотр);

CKNo ЖNo

CK56 ЖА14 CK76 ЖЖ4 CK56 ЖЖ4 CK62 ЖА14 CK56 ЖЖ36

в) применим оператор деления и получим искомый результат:

(ПСNo, ЖNo (Осмотр)) ÷ (ПЖNo(σ комнаты=3(Жилье))) = = R (CкNo) = {CK56}.

3.4. Реляционное исчисление (РИ)

Основное отличие реляционного исчисления (РИ) от реляци-онной алгебры заключается в том, что РИ указывает, что следует извлечь из отношения, а не как извлечь.

В основе РИ лежит исчисление предикатов. Предикат — это истинностная функция с аргументами. Аргументы имеют некото-рую область определения, и при подстановке одних значений ар-гументов из области определения предиката он называется истин-ным суждением, а при подстановке других — ложным суждением. Используется следующее обозначение: {X | P(X)}. Если предикат имеет истинное значение, то такое обозначение читается как «те X, для которых предикат P(X) является истинным».

Предикаты могут содержать операции конъюнкции (&), дизъ-юнкции (∨), отрицания ( ~) и другие операции булевой алгебры.

88

РИ существует в двух формах: • РИ кортежей; • РИ доменов. Рассмотрим основные возможности РИ кортежей.

3.5. РИ кортежей и доменов

Большинство выражений в РИ кортежей требует указания об-ласти определения. Другими словами, указывается, к каким отно-шениям принадлежит определенный кортеж.

Типичное выражение РИ кортежей имеет вид (K∈R){ K | P(K)}. Читается так: «для кортежей K из отношения R выбираются та-

кие кортежи, для которых истинен предикат P(K)». Пример: (S∈Сотрудники){S | S.ЗП>1000} — множество кор-

тежей отношения Сотрудники, для которых значение атрибута ЗП (зарплата) больше 1000; (S∈Сотрудники){S.ЗП | S.ЗП>1000} — множество кортежей отношения Сотрудники, для которых значе-ние атрибута ЗП (зарплата) больше 1000. В последнем выражении подчеркивается, что в кортежах выбирается только один атрибут.

В РИ кортежей также используются кванторы существования ∃ и общности ∀ , которые имеют те же свойства, что и в исчисле-нии предикатов.

Пример: (∃В∈Филиал, S∈Сотрудники) (В.ФNo=S.ФNo & B.Город =

=’Москва’). Приведем примеры запросов с использованием РИ. 1. Составить список сотрудников менеджеров, зарплата у кото-

рых >25000: (S∈Сотрудники) (S.Имя, S.Фамилия S. Должность =

= ’Менеджер’ & S.ЗП>25000). 2. Составить список всех сотрудников, которые отвечают за

работу с недвижимостью в Пензе: (S∈ Сотрудники, P∈ Жилье){S | ∃P (P.CNo=S.CNo &

P.Город=’Пенза’)}.

89

3. Составить список всех сотрудников, которые в данный мо-мент не работают с объектами недвижимости:

(S∈ Сотрудники, P∈ Жилье){S.Имя, S.Фамилия | ~ (∃P (S.CNo=P.CNo)) } или (S∈ Сотрудники, P∈ Жилье){S.Имя, S.Фамилия | ∀ P(~(S.CNo=P.CNo)) }.

4. Создать список всех клиентов, осматривавших объекты не-движимости в городе Пензе с указанием имен и комментариев:

(R∈ Съемщик,V∈ Осмотр, P∈ Жилье) {R.Имя, R.Фамилия, V.Комментарий | ∃V (R.CкNo = V.CкNo) & ∃ (V. ЖNo = P. ЖNo & P.Город=’Пенза’) }.

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

Например: {S|~S∈Сотрудники} — такие выражения в РИ на-зываются опасными, а остальные выражения — безопасными.

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

В заключение этого раздела приведем следующие утверждения без их доказательств [16].

Утверждение 1. Если РИ доменов ограничивается безопасны-ми выражениями, то оно эквивалентно РИ кортежей, тоже ограни-ченному безопасными выражениями.

Утверждение 2. Для любого выражения реляционной алгебры существует эквивалентное выражение РИ, а для любого выраже-ния РИ доменов или РИ кортежей существует эквивалентное вы-ражение реляционной алгебры.


1. Что такое реляционная алгебра? 2. Назовите основные и дополнительные операции. 3. Дайте определение операции проекции. 4. Дайте определение операции декартового произведения. 5. Дайте определение операции проекции.

90

6. В каких случаях отношения совместимы по объединению? 7. Дайте определение операции объединения. 8. Дайте определение операции разности. 9. Дайте определение операции соединения. 10. Перечислите различные типы операций соединения. 11. Что подразумевается под левым внешним соединением? 12. Дайте определение операции полусоединения. 13. Дайте определение операции пересечения. 14. Дайте определение операции деления. 15. Что такое предикат? 16. В каких формах существуют реляционные исчисления? 17. Какова основная цель РИ доменов? 18. Что является результатом оператора деления? 19. Какое соединение называется соединением по эквивалент-

ности? 20. Назовите утверждения связанные с реляционными исчис-

лениями.


1. Таблица — это по сути: a) отношение b) набор кортежей c) набор доменов d) связи плюс данные e) набор данных из источника данных f) результаты работы генератора данных

2. Столбец таблицы — это по сути:

a) атрибут b) кортеж c) источник связи d) совокупность кортежей e) объединение записей

91

3. Строка таблицы — это по сути: a) атрибут b) кортеж c) источник связи d) совокупность доменов e) объединение записей

4. Число, показывающее количество атрибутов в отношении

называется: a) доменная степень b) кардинальность отношения c) мощность связей d) степень отношения e) определитель отношения f) характеристическое число отношения

5. Число, указывающее мощность множества атрибутов от-

ношения называется: a) доменная степень b) кардинальность отношения c) мощность связей d) степень отношения e) определитель отношения f) характеристическое число отношения

6. Число, указывающее мощность множества строк отноше-

ния называется: a) степень отношения b) кардинальность отношения c) мощность связей d) доменная степень e) определитель отношения f) характеристическое число отношения

92

7. Таблица по сути является: a) подмножеством Декартова произведения доменов ее ат-

рибутов b) подмножеством Декартова произведения доменов ее

кортежей c) суммой произведения ее атрибутов d) суммой произведения ее кортежей e) суммой атрибутов ее доменов f) подмножеством Декартова произведения атрибутов ее

доменов 8. В последовательности лишним является понятие:

a) таблица b) отношение c) результат запроса d) подмножество комбинаций значений в столбцах e) подмножество Декартова произведения доменов атри-

бутов f) индекс

9. Отношение — это:

a) столбец таблицы b) строка таблицы c) таблица d) совокупность связей e) множество значений, которое может принимать экземп-

ляр 10. Атрибут — это:

a) столбец таблицы b) строка таблицы c) значение экземпляра данных d) совокупность связей данных e) множество значений, которое может принимать экземп-

ляр

93

11. Степень отношения — это: a) количество транзитивных связей b) мощность множества его атрибутов c) количество записей и строк d) количество измерений таблицы e) количество связей атрибутов

12. Кортеж — это:

a) столбец таблицы b) строка таблицы c) значение поля экземпляра данных d) совокупность транзитивных связей e) мощность множества его атрибутов

13. Кардинальность отношения — это количество:

a) транзитивных связей b) записей в таблице c) строк в таблице d) измерений таблицы e) связей атрибутов

14. Основой операции «отношение» является операция реля-

ционной алгебры: a) сложение b) проекция c) декартово произведение d) декартова проекция e) реляционное сложение f) группировка

15. Операция «Проекция» относится к группе:

a) основных b) дополнительных c) абстрактных d) необязательных e) обязательных f) редких

94

16. Операция «Соединение» относится к группе: a) основных b) дополнительных c) абстрактных d) необязательных e) обязательных f) редких

17. Результат операции …… — новое отношение, содержащее

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

a) выборка b) исключающее вычитание c) соединение d) пересечение e) деление

18. Операция «Деление» относится к группе:


19. Операция «Разность» относится к группе:


20. Операция «Выборка» относится к группе:

a) основных b) дополнительных

95

c) абстрактных d) необязательных e) обязательных f) редких

21. Операция «Пересечение» относится к группе:


22. Результат операции … — новое отношение, содержащее

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

a) выборка b) ограничение c) редукция d) объединение e) разность f) исключающее вычитание g) соединение h) пересечение i) деление j) проекция

23. Результат операции … — новое отношение, степень кото-

рого равна количеству перечисленных столбцов a) исключающее вычитание b) соединение c) пересечение d) деление e) проекция

96

24. Операциями проекции являются: a) σусловие(R) b) П список столбцов (R) c) σсписок атрибутов(R)

d) П список атрибутов (R) e) П предикат (R)

25. Результатом применения операции U является:

a) новое отношение, включающее все атрибуты отноше-ний-участников

b) новое отношение, включающее все строки отношений-участников

c) новое отношение, включающее все домены отношений-участников

d) первое отношение поглощает строки второго e) первое отношение поглощает кортежи второго f) первое отношение поглощает атрибуты второго

26. Результат операции R — S — новое отношение, которое

состоит из: a) атрибутов, которые имеются в S, но отсутствуют в R b) кортежей, которые имеются в S, но отсутствуют в R c) атрибутов, которые имеются в R, но отсутствуют в S d) кортежей, которые имеются в R, но отсутствуют в S e) атрибутов, которые имеются и в R и в S f) кортежей, которые имеются и в R и в S

27. Операция «разность» накладывает ограничения для отно-

шений-участников: a) аналогичные ограничениям операции «объединение» b) аналогичные ограничениям операции U c) аналогичные ограничениям операции «деление» d) аналогичные ограничениям операции х e) операция «разность» не имеет ограничений к примене-

нию

97

28. Основными операциями реляционной алгебры являются: a) пересечение b) проекция c) выборка d) деление

29. Результат операции выборка — это новое отношение: a) содержащее только указанные столбцы b) объединяющее все строки исходного отношения с ука-

занными строками из нового c) содержащее только указанные номера строк d) содержащее только те кортежи, которые удовлетворяют

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

заданному предикату 30. Операция «проекция»:

a) исключает из исходного отношения указанные столбцы b) исключает из исходного отношения указанные строки c) включает в результат только указанные столбцы d) включает в результат только указанные строки e) исключает из результата строки дубликаты f) исключает из результата столбы дубликаты

Ответы: 1 — a, b; 2 — a; 3 — b; 4 — d; 5 — d; 6 — b; 7 — a;

8 — f; 9 — c; 10 — a; 11 — b; 12 — b; 13 — b, c; 14 — c; 15 — a; 16 — b; 17 — a; 18 — b; 19 — a; 20 — a; 21 — b; 22 — a, b; 23 — e; 24 — b, d; 25 — b; 26 — d; 27 — a, b; 28 — b, c; 29 — d, e; 30 — c, e.

98

4. ЯЗЫК ЗАПРОСОВ SQL

4.1. Основные понятия

SQL (Structured Query Language — структурированный язык запросов) предназначен для обработки реляционных БД [8]. Многие конструкции и операторы языка SQL связаны с операция-ми реляционной алгебры. С этой точки зрения методы реляцион-ной алгебры являются базовыми для более глубокого понимания и использования языка SQL. В различных СУБД используются два типа языка SQL:

1) интерактивный SQL — для выполнения действий непосред-ственно над БД в оперативном режиме. Как правило, интерактив-ному SQL сопутствует некоторая программа-сервер SQL. Наибо-лее популярны в настоящее время Oracle SQL-Server, MS-SQL Server, Inter Base и некоторые другие;

2) встроенный SQL — состоит из команд SQL, включенных непосредственно в программы, которые написаны на другом языке программирования. Например, в таких системах программирова-ния, как Delphi, C++ Builder, VBasic, VC++ имеется встроенный SQL. В различных СУБД, например в MS-Access, также имеются возможности использовать команды встроенного SQL.

В языке SQL существует множество команд, которые относят-ся к тем или иным выполняемым действиям. Таким образом, мож-но разделить SQL на определенные подмножества: • DQL — язык запросов. Команды предназначены для извлече-

ния данных из таблиц; • DML — язык манипуляции данными; • TPL — язык обработки транзакций. Команды позволяют объе-

динить команды языка DHL в группы транзакций. Если одна из команд не может быть выполнена, то отменяются все преды-дущие команды из этой же транзакции, — происходит «откат транзакции»;

99

• DDL — язык определения данных. Включает также инструк-ции обеспечения целостности данных. Например, команды создания таблиц и организации связей между ними;

• CCL — язык управления курсором. Позволяет выбрать для об-работки одну строку из результирующего множества запросов;

• DCL — язык управления данными. Содержит инструкции, с помощью которых выполняется присваивание прав доступа к БД, множеству таблиц или представлений.

4.2. Типы данных SQL

Для различных СУБД типы данных SQL несколько отличаются друг от друга. Для обеспечения совместимости был введен стан-дарт ANSI SQL. Типы данных, совместимые с ANSI, состоят из символов и различных типов чисел, которые могут классифициро-ваться как точные числа и приблизительные числа. Точные число-вые типы — это номера с десятичной точкой или без десятичной точки. Приблизительные числовые типы — это номера в показа-тельной (экспоненциальной по основанию 10) записи. Для всех прочих типов отличия слишком малы, чтобы их как-то классифи-цировать. Иногда в описании типов данных используют параметр, который называют аргументом размера. Значения по умолчанию обеспечены для всех типов, если размер аргумента отсутствует.

Ниже в табл. 4.1 представлены наиболее часто используемые типы данных ANSI SQL (имена в круглых скобках — это синони-мы). Если в столбце описания типа используется словосочетание «реализационно-определенный формат», то имеется в виду, что эта часть конструкции языка SQL может отличаться для различ-ных реализаций СУБД.

100

Таблица 4.1 Типы данных в SQL

ТИП Описание TEXT Обычное текстовое поле CHAR (или CHARACTER) Пример. CHAR (10)

Строка текста. В круглых скобках можно указывать аргу-мент размера поля — это целое число, которое указывает максимальную длину строки. Значения этого типа должны быть заключены в одиночные кавычки, например 'cтрока текста'. Две рядом стоящие одиночные кавычки ('') внутри строки будут пониматься как одна одиночна кавычка (')

DEC (или DECIMAL) Пример. DEC (10,2)

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

NUMERIC Такое же число как DECIMAL, за исключением того, что максимальное десятичное не может превышать ар-гумента точности

INT (или INTEGER)

Целое число. Эквивалентно DECIMAL, но без цифр справа от десятичной точки, т.е. с масштабом, равным 0. Аргумент размера не используется (он автоматически устанавливается в реализационно-зависимое значение)

SMALLINT Такое же как INTEGER, за исключением того, что в за-висимости от реализации размер по умолчанию не мо-жет быть большим, чем INTEGER

FLOAT Число с плавающей запятой на основе показательной функции A⋅10N. Аргумент размера состоит из одного числа, определяющего минимальную точность. Напри-мер, константа этого типа 3.245E-2 представляет число 3,245⋅10-2 =0,03245

REAL Такое же, как FLOAT, за исключением того, что ника-кой аргумент размера не используется. Точность уста-новлена реализационно-зависимо по умолчанию

DOUBLE PRECISION (или DOUBLE)

Такое же, как REAL, за исключением того, что реализа-ционно-определяемая точность для DOUBLE PRECISION должна превышать реализационно-определяемую точность REAL

APPROXIMATE NUMERIC

Приблизительное число

EXACT NUMERIC Точное число

101

Для сравнения приведем некоторые типы данных, которые поддерживает MS-Access (табл. 4.2).

Таблица. 4.2 Типы данных в Access

Тип Описание BOOLEAN Логическое значение «истина» или «ложь» (True-False,

Yes/No). Занимаемый размер памяти — 1 бит INTEGER Целое число в диапазоне от –32768 до +32767. Занимаемый

размер памяти — 2 байта LONG Длинное целое в диапазоне от — 2 147 483 648 до

2 147 483 647 (4 байта) SINGLE Число с плавающей точкой в диапазоне от

–3.402823E38 до –1.401298E–45 для отрицательных чисел и от 1.401298E–45 до 3.402823E38 для положительных чисел (точ-ность до 7 десятичных цифр, размер — 4 байта)

DOUBLE Число с плавающей точкой в диапазоне от –1.79769313486231E308 до –4.94065645841247E–324 для от-рицательных значений и от 4.94065645841247E–324 до1.79769313486231E308 для положительных чисел (точность до 15 десятичных цифр, размер — 8 байт)

СURRENCY Денежное значение. Зависит от региональных настроек ОС DATE Значение даты и времени STRING Строка символов

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

Использование запросов на языке SQL считается самым рас-пространенным способом применения возможностей этого языка. Фактически большинство пользователей БД и информационных систем в первую очередь нуждаются в информации, полученной с помощью запросов языка SQL. Умение правильно сформировать запрос на языке SQL, в настоящее время считается важнейшим элементом компьютерной грамотности, поэтому будем начинать изучать язык SQL с обсуждения понятия «запрос», и с того как он выполняется на этом языке [8].

Запрос — команда, которая выдается программе БД для поиска определенной информации из таблиц. Эта информация обычно по-сылается непосредственно на экран компьютера или терминала, хотя в большинстве случаев, ее можно также послать на принтер, сохранить в файле (как объект в памяти компьютера) или предста-

102

вить как вводную информацию для другой команды или процесса. Запросы обычно рассматриваются как часть языка DML. Однако, так как запрос не меняет информацию в таблицах, а просто пока-зывает ее пользователю, будем рассматривать запросы как само-стоятельную категорию среди команд DML, которые производят действие, а не просто показывают содержание БД.

Все запросы в SQL состоят из одиночной команды. Эта коман-да называется SELECT (выбор). Несмотря на простоту формата команды SELECT, с ее помощью можно выполнять достаточно сложную обработку данных. В самой простой форме команда SELECT инструктирует БД, чтобы извлечь информацию из табли-цы, указанной в предложении FROM. Например, для того чтобы вывести на экран таблицу Съемщик (см. отношения в предыдущем разделе) достаточно использовать такую команду:

SELECT СкNo, Имя, Фамилия, Адрес, Телефон, Нуж_тип, Max_плата, ФNo FROM Съемщик;

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

Рассмотрим подробнее, что означает записанная выше команда. Ключевое слово SELECT сообщает БД, что эта команда — за-

прос. Все запросы начинаются этим словом, сопровождаемым пробелом. Далее идет список имен столбцов из таблицы, которые выбираются по запросу: СкNo, Имя, Фамилия, Адрес, Те-лефон, Нуж_тип, Max_плата, ФNo. Любые столбцы, не пе-речисленные здесь, не будут включены в вывод команды. Это, ко-нечно, не значит что они будут удалены или их информация будет стерта из таблиц, потому что запрос не воздействует на информа-цию в таблицах, он только показывает данные. Ключевое слово FROM сопровождается пробелом и затем именем таблицы (или нескольких таблиц), используемой в качестве источника информа-ции. В данном случае — это таблица Съемщик. Точка с запятой «;» используется во всех интерактивных командах SQL, чтобы сооб-щать БД, что команда заполнена и готова к выполнению. В неко-торых системах наклонная черта влево (\) в строке является инди-катором конца команды.

103

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

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

SELECT * FROM Съемщик;

4.4. Общий вид оператора SELECT

SELECT [ DISTINCT | ALL ] <выражение или имя по-ля>, ... FROM <ссылка на таблицу>, ... [WHERE <предикат>] [GROUP BY <столбец, по которому выполняется группировка>, ...] [HAVING <предикат>] [ORDER BY <столбец, по которому выполняется упорядочивание> [ ASC | DESC ], ... ]

Здесь квадратные скобки ([]) обозначают необязательные эле-менты. Многоточие (...) обозначает элементы, которые могут по-вторяться один или более раз. Рассмотрим каждый элемент коман-ды SELECT подробнее.

«Выражение или имя поля» — описывает столбцы, функции агрегирования, константы, которые включаются в результирую-щую таблицу.

104

Ключевое слово DISTINCT (отличие) «следит» за тем, какие значения (строки) были выведены ранее так, что бы они не были продублированы в списке. Это полезный способ избежать избы-точности данных. Однако нужно следить за тем, чтобы не были потеряны некоторые важные данные, несмотря на то, что они дуб-лируются в результате. DISTINCT может указываться только один раз в данном предложении SELECT.

Ключевое слово ALL (все) имеет противоположное слову DISTINCT назначение — дублирование строк вывода сохранится. Если ни ALL, ни DISTINCT не указаны, принимается ALL.

Ключевое слово FROM определяет имена таблиц или запросов, которые используются в данном запросе. Из них будет извлекаться нужная информация.

Ключевое слово WHERE позволяет устанавливать предикаты, условие которых может быть или верным или неверным для лю-бой строки таблицы. Команда извлекает только те строки из таб-лицы, для которых такое утверждение верно. Например, если не-обходимо выбрать имена съемщиков и их телефоны только из третьего филиала, то можно использовать такой запрос:

SELECT Имя, Фамилия, Телефон, ФNo FROM Съемщик WHERE ФNo = ‘Ф3’;

Заметим, что если поле не является текстовым, то в операции сравнения кавычки указывать не нужно. Например, выберем съемщиков, которые готовы платить за квартиру больше 400 руб.:

SELECT Имя, Фамилия, Телефон FROM Съемщик WHERE Max_плата > 400;

Ключевые слова GROUP BY позволяют осуществлять группи-ровку записей при использовании функции агрегирования. Если используется GROUP BY, все столбцы в предложении SELECT, должны будут применяться как группа столбцов, если они не со-держатся в агрегатной функции. Вся группа столбцов должна быть представлена среди выражений, указанных в предложении SELECT. Для каждой отдельной комбинации значений группы столбцов будет иметься одна и только одна строка вывода. Более

105

подробно это будет рассмотрено позже, при изучении агрегатных функций.

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

Ключевые слова ORDER BY используются для окончательной сортировки полученных данных. Указываются столбцы, по кото-рым нужно сортировать, при этом ключевое слово ASC означает сортировку по возрастанию, DESC — сортировку по убыванию.

4.5. Механизм работы оператора SELECT

SELECT оценивает каждую возможную строку кандидата, по-лученную следующим образом.

Если включена только одна ссылка на таблицу, то каждая строка этой таблицы рассматривается как строка кандидата.

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

Для каждой строки кандидата значения подставляются в пре-дикат в предложении WHERE, которые делают это предикат вер-ным, неверным, или неизвестным.

Если не используется оператор GROUP BY, каждое выражение из списка первоначальных выражений, применяется к каждой строке кандидата, значение которой делает предикат истинным.

Результат этой операции применяется к выходным данным. Если используется оператор GROUP BY, то строки кандидата

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

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

106

Если указан предикат HAVING, то из результата исключаются данные, противоречащие этому предикату.

Если был указан DISTINCT, то из результата удаляются повторяю-щиеся строки.

Наконец, если указан ORDER BY, то проводится сортировка данных и результат выводится пользователю.

4.6. Операторы сравнения, логические и арифметические операторы

Для формирования сложных предикатов в SQL можно исполь-зовать следующие операторы (табл. 4.3).

Таблица 4.3

Логические и другие операторы в SQL Оператор Назначение

> Сравнивает два значения и возвращает «истину», если значение слева от оператора больше значения справа

< Сравнивает два значения и возвращает «истину», если левое значение меньше значения справа

>= Сравнивает два значения и возвращает «истину», если левое значение больше или равно значения справа

<= Сравнивает два значения и возвращает «истину», если левое значение меньше или равно значения справа

= Сравнивает два значения и возвращает «истину», если левое значение равно значения справа

<> Сравнивает два значения и возвращает «истину», если левое значение не равно значения справа

AND Логическая операция И (конъюнкция) OR Логическая операция ИЛИ (дизъюнкция)

NOT Логическая операция НЕ (отрицание) + Сложение двух чисел – Вычитание * Умножение / Деление & Конкатенация (объединение двух строк или двух любых разно-

типных значений)

107

Пример 1. Пусть необходимо найти жилье в Пензе стоимостью не более 400 рублей.

Select Улица, Город, Плата From Жилье Where Город=’Пенза’ AND Плата<=400;

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

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

Предположим, нужно вывести цену за аренду жилья и рядом налог на имущество, выплачиваемый за это жилье. Результат вы-дать отсортированный по полям «город» и «адрес». Пусть налог на имущество за месяц представляет собой фиксированную сумму, равную 40 рублям плюс 13% от стоимости аренды:

SELECT Жилье.ЖNo, Жилье.Город, Жилье.Улица,

Жилье.Плата, '40 руб. + 13%' AS СтавкаНалога, (40+ Жилье.Плата*13/100)&'рублей' AS Налог

FROM Жилье ORDER BY Город, Улица; Результат выполнения запроса отражен в табл. 4.4.

Таблица 4.4

Результат выполнения запроса

ЖNo Город Улица Плата Ставка Налога Налог ЖА14 Астрахань ул.Н-16 650,00р. 40 руб. + 13% 124,5рублей ЖЛ94 Москва ул.А-6 400,00р. 40 руб. + 13% 92рублей ЖЖ21 Пенза ул.D-18 600,00р. 40 руб. + 13% 118рублей ЖЖ4 Пенза ул.L-6 350,00р. 40 руб. + 13% 85,5рублей ЖЖ16 Пенза ул.N-5 450,00р. 40 руб. + 13% 98,5рублей ЖЖ36 Пенза ул.М-2 375,00р. 40 руб. + 13% 88,75рублей

108

Пример 2. Выдать список сотрудников мужского пола старше 55 лет и женского пола старше 45 лет. В данном примере будем использовать дополнительную функцию Date ( ), которая возвра-щает текущую дату. Аналог такой функции присутствует в раз-личных реализациях СУБД, но не рассматривается стандартом SQL:

Select Имя, Фамилия, Дрожд From Сотрудники Where (Пол=’М’ AND (Date()- Дрожд)>55) OR (Пол=’Ж’ AND (Date()- Дрожд)>45);

4.7. Использование специальных операторов

Для определения более сложных выражений в предикатах с од-ной стороны и упрощения внешнего вида предикатов — с другой, в SQL используются различные дополнительные операторы (табл. 4.5).

Таблица 4.5 Специальные операторы

Оператор, пример Назначение <поле> IN (знач.1, знач.2, …) Пример. SELECT * FROM Сотруд-ники WHERE Фno IN (‘Ф3’, ‘Ф7’);

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

<поле> BETWEEN <МinЗнач> AND <МахЗнач> Пример. SELECT * FROM Сотруд-ники WHERE ЗП BETWEEN 9000 AND 20000;

Определяет диапазон, значения которого должны увеличиваться от возможного мини-мального значения (<МinЗнач>) до макси-мального (<МахЗнач>) и возвращает истину, если проверяемое поле принадлежит данному диапазону. Значение может быть как число-вым, так и символьным

<поле> LIKE <шаблон> Пример. SELECT * FROM Сотруд-ники WHERE Фамилия LIKE ‘Б%’;

Проверяет, совпадает ли значение проверяе-мого поля с шаблоном. В качестве метасим-волов шаблонов используются: символ под-черкивания ( _ ), который замещает любой одиночный символ; символ процента (%) за-мещает последовательность любого количе-ства символов

109

Замечания. 1. Оператор BETWEEN включает в результат граничные зна-

чения, поэтому, для того чтобы исключить граничные значения, можно использовать оператор IN. Например, необходимо выдать список всех сотрудников, зарплата которых больше 9 000, но меньше 20 000, т.е. граничные значения не включаются в резуль-тат. Тогда запрос может быть таким:

SELECT * FROM Сотрудники WHERE (ЗП BETWEEN 9000 AND 20000) AND NOT ЗП

IN (9000,20000); 2. Если в BETWEEN используются в качестве аргументов

строки, то происходит отбор значений по диапазону ASCII-кодов символов. Например, если необходимо выбрать сотрудников, чьи фамилии находятся в алфавитном диапазоне от А до Л, то можно использовать такой запрос:

SELECT * FROM Сотрудники WHERE Фамилия BETWEEN ‘А’ AND ‘Л’;

3. Оператор LIKE применим только к символьным данным

(типа CHAR). 4. В некоторых реализациях SQL (например, в СУБД MS-

Access) вместо метасимвола ‘%’ используется метасимвол ‘*’. 5. Использование метасимвола без его специального назначе-

ния (экранирование метасимвола) достигается путем определения ESC-символа, определяемого конструкцией ESCAPE, которая сле-дует сразу же после конструкции LIKE. Обычно в качестве такого символа применяется знак — ‘/’. Предположим, нам нужно найти подстроку ‘_/’ в поле «Комментарий» таблицы «Осмотр». Так как оба символа являются метасимволами, то их нужно «экраниро-вать»:

SELECT * FROM Осмотр WHERE Комментарий LIKE '%/_//%'

ESCAPE '/';

110

4.8. Использование оператора NULL

Часто в таблицах существуют записи, которые не имеют ника-ких значений для каждого поля, например, потому, что информа-ция не завершена, или потому, что это поле просто не заполнялось. SQL учитывает такой вариант, позволяя вводить значение NULL (ПУСТОЙ) в поле вместо значения. Когда значение поля равно NULL, это означает, что программа БД специально промаркирова-ла это поле как не имеющее никакого значения для этой строки (или записи).

NULL отличается от простого значения поля так же как нуль (0) отличается от обычного числа. Значение нуля или пробела БД будет обрабатывать так же, как и любое другое значение. Значение NULL не имеет типа данных и может помещаться в поле любого типа.

Так как NULL указывает на отсутствие значения, то невозмож-но знать, каков будет результат любого сравнения с использовани-ем NULL. Когда NULL сравнивается с любым значением, даже с другим таким же NULL, результат будет ни верным, ни неверным, он неизвестен. Неизвестное логическое значение ведет себя так же, как неверная строка, которая, произведя неизвестное значение в предикате, не будет выбрана запросом. Следует учитывать, что NOT (неверное) равняется «верно», NOT (неизвестное) равняется «неизвестно». Следовательно, выражение типа 'Фамилия = NULL' или 'Фамилия IN (NULL)' будет неизвестно, независимо от значе-ния поля «Фамилия».

Часто необходимо делать различия между значениями «невер-но» и «неизвестно» между строками, содержащими значения столбцов, которые не соответствуют условию предиката и которые содержат NULL в столбцах. По этой причине SQL предоставляет специальный оператор IS, который используется с ключевым сло-вом NULL для проверки значения NULL.

Найдем все записи в таблице Съемщик с NULL значениями в столбце «Фамилия»:

SELECT * FROM Съемщик WHERE Фамилия IS NULL;

111

Здесь не будет никакого вывода, потому что в таблице нет ни-каких значений NULL.

4.9. Использование NOT со специальными операторами

Специальные операторы IN, BETWEEN, LIKE, а также NULL могут использоваться совместно с булевым оператором NOT — отрицание, инверсия.

Например, если мы хотим устранить NULL из нашего вывода, мы будем использовать NOT, чтобы изменить на противополож-ное значение предиката:

SELECT * FROM Съемщик WHERE Фамилия IS NOT NULL;

При отсутствии значений NULL в таблице (как в нашем слу-чае) будет выведена вся таблица Съемщик. Аналогично можно ввести следующее:

SELECT * FROM Съемщик WHERE NOT Фамилия IS NULL — такой запрос приемлем.

Другие примеры использования NOT: SELECT * FROM Жилье WHERE Город NOT IN (' Астрахань ', 'Москва' );

SELECT * FROM Жилье WHERE NOT Город IN ('Астрахань', 'Москва' ); Таким же способом можно использовать NOT BETWEEN и

NOT LIKE.

4.10. Использование функций агрегирования и предложения HAVING

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

112

одиночное значение для всей группы таблицы. Имеется список этих функций: • COUNT — производит номера строк или не NULL значения

полей которые выбрал запрос; • SUM — производит арифметическую сумму всех выбранных

значений данного поля; • AVG — производит усреднение всех выбранных значений дан-

ного поля; • MAX — производит наибольшее из всех выбранных значений

данного поля; • MIN — производит наименьшее из всех выбранных значений

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

предложении SELECT запроса, но с одним исключением, они бе-рут имена поля как аргументы. Только числовые поля могут ис-пользоваться с SUM и AVG. С функциями COUNT, MAX и MIN — числовые или символьные поля. Когда агрегатные функции ис-пользуются с символьными полями, MAX и MIN будут трансли-ровать их в эквивалент ASCII, который должен сообщать, что MIN будет означать первое, а MAX — последнее значение в алфавит-ном порядке.

Попробуем найти сотрудника с максимальной заработной платой: SELECT MAX(ЗП) FROM Сотрудники;

Такой запрос выдаст одно число — 30 000, которое соответст-вует максимальной ЗП в таблице «Сотрудники».

Функция COUNT несколько отличается от всех. Она считает число значений в данном столбце, или число строк в таблице. Ко-гда она считает значения столбца, она используется с DISTINCT чтобы производить счет чисел различных значений в данном поле. Например, чтобы сосчитать номера сотрудников:

SELECT COUNT ( DISTINCT СNo ) FROM Сотруд-ники;

Чтобы подсчитать общее число строк в таблице, можно ис-пользовать функцию COUNT со звездочкой вместо имени поля, как в следующем примере:

SELECT COUNT (*) FROM Сотрудники;

113

Ответом на запрос является цифра 6. COUNT со звездочкой включает NULL и дубликаты, по этой причине DISTINCT не при-меним c COUNT (*).

Агрегатные функции могут также (в большинстве реализаций) использовать аргумент ALL, который помещается перед именем поля, подобно DISTINCT, но означает противоположное — вклю-чать дубликаты. ANSI технически не позволяет этого для COUNT, но многие реализации ослабляют это ограничение. Ниже приво-дятся различия между ALL и * когда они используются с COUNT:

1) ALL использует имя поля как аргумент;

2) ALL не может подсчитать значения NULL.

Пока ’*’ является единственным аргументом, который включа-ет NULL-значения, и он используется только с COUNT; функции, отличные от COUNT игнорируют значения NULL в любом случае. Следующая команда подсчитает (COUNT) число не-NULL значе-ний в поле должность — сотрудник (включая повторения), резуль-татом тоже будет число 6:

SELECT COUNT ( ALL Должность ) FROM Сотрудники;

До этого момента использовались агрегатные функции с оди-ночными полями как аргументами. Однако можно также исполь-зовать агрегатные функции с аргументами, которые состоят из скалярных выражений, включающих одно или более полей. В этом случае использовать DISTINCT не разрешается. Предложение GROUP BY позволяет определять подмножество значений в осо-бом поле в терминах другого поля и применять функцию агрегата к подмножеству. Это дает возможность объединять поля и агре-гатные функции в едином предложении SELECT. Например, пред-положим, что необходимо найти наибольшую стоимость жилья в каждом городе:

SELECT Город, MAX(Плата) FROM Жилье GROUP BY Город;

Результат для этого запроса будет таким:

114

Астрахань 650 Москва 400 Пенза 600

GROUP BY применяет агрегатные функции для группы одина-ковых значений указанного поля (в данном примере поле «Го-род»). То есть каждая группа состоит из всех строк с тем же самым значением поля «Город» и функция MAX применяется отдельно для каждой такой группы. Это значение поля, к которому приме-няется GROUP BY, имеет, по определению, только одно значение на группу вывода, также как это делает агрегатная функция. Ре-зультатом является совместимость, которая позволяет агрегатам и полям объединяться именно таким образом. GROUP BY может также использоваться с многочисленными полями. Агрегатные функции и поля не могут выбираться одновременно, если не будет использовано предложение GROUP BY.

Предложение HAVING определяет критерии, используемые для того, чтобы удалять определенные группы из вывода, точно так же, как предложение WHERE делает это для индивидуальных строк. Аргументы в предложении HAVING следуют тем же самым правилам, что и в предложении SELECT, состоящем из команд, использующих GROUP BY. Они должны иметь только одно зна-чение на группу вывода. Например, чтобы узнать, в каких городах максимальная оплата жилья не превышает 600 рублей можно со-ставить такой запрос:

SELECT Город, MAX(Плата) FROM Жилье GROUP BY Город HAVING Плата<=600;

4.11. Выборка информации из нескольких таблиц

Соединение таблиц Одна из наиболее важных особенностей запросов SQL — это

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

115

операции называется соединением, которое является одним из ви-дов операций в реляционных БД. При соединении все таблицы представляются списком в предложении FROM запроса и отделя-ются запятыми. Предикат запроса может ссылаться к любому столбцу любой связанной таблицы и, следовательно, может ис-пользоваться для связи между ними. Обычно предикат сравнивает значения в столбцах различных таблиц, чтобы определить, удовле-творяет ли WHERE установленному условию. Полное имя столбца таблицы фактически состоит из имени таблицы, сопровождаемого точкой и затем имени столбца, например: «Жилье. Город или Съемщик. Фамилия».

До этого в примерах имена таблиц были опущены, потому что запрашивалась только одна таблица. SQL достаточно интеллектуа-лен, чтобы присвоить соответствующий префикс имени таблицы. Даже когда используется запрос многочисленных таблиц, можно опускать их имена, если все их столбцы имеют различные заго-ловки. Но так бывает не всегда. Например, мы имеем две типовые таблицы со столбцами, называемыми «Город». Если необходимо связать эти столбцы (кратковременно), то нужно указать их с име-нами «Жилье». «Город» или «Филиал.Город», чтобы SQL мог их различать. Предположим, что нужно каждому филиалу сопоста-вить недвижимость в этом городе: SELECT Филиал.ФNo, Филиал.Телефон, Филиал.Город,

Жилье.Город, Жилье.Улица FROM Филиал, Жилье WHERE

Филиал. Город=Жилье.Город; Результат запроса будет таким (табл. 4.6). Заметьте, что поря-

док строк может быть произвольным.

Таблица 4.6

Результат запроса о жилье по филиалам

ФNo Телефон Филиал.Город Жилье.Город Улица Ф5 6655440 Москва Москва ул.А-6 Ф3 6216220 Пенза Пенза ул.N-5 Ф3 6216220 Пенза Пенза ул.D-18

116

Окончание табл. 4.6.

ФNo Телефон Филиал.Город Жилье.Город Улица Ф3 6216220 Пенза Пенза ул.М-2 Ф3 6216220 Пенза Пенза ул.L-6 Ф2 8138150 Москва Москва ул.А-6

При выполнении этого запроса SQL сначала сделает декартово произведение таблиц «Филиал» и «Жилье», затем будет выбрана проекция по указанным полям, после чего из списка будут удале-ны все записи, не удовлетворяющие условию предиката WHERE. Другими словами, будет сделано эквивалентное соединение по общему атрибуту «Город».

Аналогичным образом можно соединять и более двух таблиц. Типы соединений в SQL Язык SQL имеет конструкцию JOIN для организации различ-

ных видов соединений. Перед этой конструкцией обычно следует слово, уточняющее тип соединения: • Inner — эквивалентное соединение, при котором каждая строка

в одной таблице имеет соответствующую строку в другой; • Right — правое внешнее соединение, включает все строки из

одной таблицы (правой или указанной первой) плюс все соот-ветствующие строки из другой;

• Left — левое внешнее соединение (аналогичное правому, толь-ко выборка всех строк производится из левой таблицы);

• Cross — декартово произведение; • Natural — естественное соединение; • Full — комбинация левого и правого соединений; • Union — соединение, противоположное внутреннему соедине-

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

виды соединений. Например, MS-Acces поддерживает только пер-вые три типа.

117

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

SELECT Филиал.ФNo, Филиал.Телефон, Филиал. Город, Жилье.Город, Жилье.Улица FROM Жилье INNER JOIN Филиал ON (Жилье. Город = Филиал.Город);

Приведем пример левого соединения: SELECT Съемщик.Фамилия, Съемщик.Имя,

Осмотр.Дата, Осмотр.Комментарий FROM Съемщик LEFT JOIN Осмотр ON Съемщик. СкNo = Осмотр.СкNo;

Смысл этого запроса такой: выдать фамилии всех съемщиков и возможные результаты осмотра ими объектов недвижимости. Ре-зультат запроса будет следующим (табл. 4.7).

Таблица 4.7

Результат выполнения запроса о съемщиках жилья

Фамилия Имя Дата Комментарий Ключов Иван 20.04.1998 Слишком далеко Жильцова Лина 28.04.1998 Жильцова Лина 26.05.1998 Жильцова Лина 02.05.1998 Слишком мала Рышков Михаил Третьякова Мария 14.05.1998 Нет отдельной столовой

Использование левого соединения дало нам важную информа-цию о том, что клиент Рышков Михаил ни разу не осматривал не-движимость. Эта информация была бы потеряна при использова-нии эквивалентного (INNER) и правого (RIGHT) соединений.

Более сложный пример с соединением трех таблиц. Необходи-мо получить информацию, на каких объектах недвижимости уже побывали клиенты (табл. 4.8):

SELECT Съемщик.Фамилия, Съемщик.Имя, Жилье.Город, Жилье.Улица

FROM (Съемщик INNER JOIN

118

Осмотр ON Съемщик.СкNo = Осмотр.СкNo) INNER JOIN Жилье ON Осмотр.Жno = = Жилье.ЖNo;

Таблица 4.8

Результат запроса с соединением трех таблиц

Фамилия Имя Город Улица Жильцова Лина Астрахань ул.Н-16 Ключов Иван Пенза ул.L-6 Жильцова Лина Пенза ул.L-6 Третьякова Мария Астрахань ул.Н-16 Жильцова Лина Пенза ул.М-2

Заметим, что в этом запросе не выводятся данные из таблицы «Осмотр», хотя она необходима для получения результата. Такой тип запроса называется косвенным, т.е. таблица «Осмотр» косвен-но присутствует в запросе.

4.12. Рекурсивное соединение таблицы

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

В таком запросе используются алиасы (или псевдонимы) для каждой копии таблицы. Псевдоним — это имя таблицы, которое в дальнейшем будет использоваться в запросе. Псевдоним указыва-ется сразу за именем таблицы в инструкции FROM. В большинст-ве реализаций перед алиасом требуется ключевое слово AS. Ана-логичным образом можно дать псевдоним любому полю. Следует иметь в виду, что псевдоним существует только пока команда вы-полняется.

119

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

Например, мы хотим узнать номера филиалов, находящихся в одном городе:

SELECT Филиал_1.ФNo, Филиал.ФNo, Филиал. Город FROM Филиал AS Филиал_1 INNER JOIN Филиал

ON Филиал_1.Город = Филиал. Город;

Или можно по другому: SELECT ФИЛ1.ФNo, ФИЛ2.ФNo, ФИЛ1.Город FROM Филиал AS ФИЛ1, Филиал AS ФИЛ2 WHERE ФИЛ1.Город = ФИЛ2.Город;

В обоих случаях результат выполнения запросов будет одина-ковым, за исключением заголовков столбцов (табл. 4.9).

Таблица 4.9

Результат выполнения запроса по городам

ФИЛ1.ФNo ФИЛ2.ФNo Город Ф2 Ф5 Москва Ф5 Ф5 Москва Ф7 Ф7 Донецк Ф3 Ф3 Пенза Ф4 Ф4 Липецк Ф2 Ф2 Москва Ф5 Ф2 Москва

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

Помимо того, что в результат попали одни и те же филиалы (например, строки 2, 3, 4, 5, 6), в нем содержатся два значения для каждой комбинации филиалов в одинаковых городах, причем вто-рой раз в обратном порядке (строки 1 и 7). Важно понять, почему так получилось. Дело в том, что выполняется обычная операция соединения, т.е. каждое значение в таблице ФИЛ1 соединяется с

120

каждым значением в таблице ФИЛ2. Поэтому первый результат мы получим, когда соединим Ф2 с Ф5 по полю «Город», а потом наступит черёд соединения Ф5 с Ф2 по тому же полю. Аналогично в результат попадут соединения Ф2 с Ф2, Ф3 с Ф3 и т.д. поскольку у них тоже один и тот же город. Таким образом, SQL правильно выполнил все то, о чем его просили.

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

SELECT Ф1.ФNo, Ф2.ФNo, Ф1.Город FROM Филиал AS Ф1, Филиал AS Ф2 WHERE Ф1.Город = Ф2.Город AND Ф1.ФNo < Ф2.ФNo;

В результат будет выбрана только первая строка из предыду-щего запроса.

4.13. Использование вложенных запросов

С помощью SQL можно строить запросы, вложенные внутрь друг друга. Обычно внутренний запрос генерирует значение (или несколько значений), которое проверяется в предикате внешнего запроса, определяющего, верно оно или нет. То есть результат ра-боты одного запроса должен управлять поведением другого запро-са. Подзапрос размещается внутри одного из предикатов главного запроса. Предикаты, использующие подзапрос, имеют форму:

<выражение><оператор><подзапрос>. В зависимости от типа оператора подзапрос должен возвра-

щать либо одно значение, либо несколько. Для основных операто-ров сравнения и логических операторов подзапрос обязательно должен возвращать только единственное значение. Множество значений подзапрос может возвращать только в случае, когда ис-пользуется оператор IN. Теоретически в каждой части оператора

121

BETWEEN также могут использоваться вложенные подзапросы, слева и справа от ключевого слова AND:

SELECT * FROM Жилье WHERE Плата BETWEEN (SELECT AVG(Плата) FROM Жилье)

AND (SELECT MAX(Плата) FROM Жилье); Но такие конструкции обычно не требуются и могут быть реа-

лизованы более простыми способами. Рассмотрим следующий пример:

SELECT * FROM Филиал WHERE Город IN

(SELECT Город FROM Жилье WHERE ВлNo = 'В87');

Результат выполнения запроса отражен в табл. 4.10.

Таблица 4.10

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

ФNo Улица Область Город Индекс Телефон Факс Ф5 Дворцовая 22 Московская Москва 332211 6655440 6655450 Ф3 Морская 163 Пензенская Пенза 887766 6216220 6216230 Ф2 Центральная 56 Московская Москва 366666 8138150 8138140

Чтобы оценить внешний (основной) запрос, сначала необходи-мо оценить внутренний запрос (или подзапрос), который располо-жен внутри предложения WHERE. В данном примере внутренний запрос возвращает список городов, в которых расположена недви-жимость владельца с кодом В87 (Кирилл Фирсов). Результат под-запроса вернет две записи со значениями городов {‘Моск-ва’,’Пенза’}. Далее внешний запрос будет применяться к этому множеству. Грубо говоря, теперь запрос будет выглядеть так:

SELECT * FROM Филиал WHERE Город IN (‘Москва’,’Пенза’);

122

Таким образом, смысл всего запроса следующий: найти все филиалы, которые отвечают за работу с недвижимостью владельца В87 (Кирилла Фирсова).

Если бы мы были уверены, что внутренний запрос возвращает только одно значения, то вместо IN можно было использовать знак равенства (=).

Если используется подзапрос, который не выводит никаких значений, то и основной запрос не выведет никаких значений. Подзапросы, которые не производят никакого вывода (или произ-водят пустой вывод), вынуждают рассматривать предикат как не-известный. Однако неизвестный предикат имеет тот же самый эф-фект что и неверный: никакие строки не выбираются по основному запросу. В некоторых случаях можно использовать DISTINCT, чтобы «вынудить» подзапрос генерировать одиночное значение. Уровень вложенности подзапросов может быть любым, практически без ограничений.

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

цию без предложения GROUP BY, будет выбирать одиночное зна-чение, которое может быть использовано в предикате основного запроса. Важно иметь в виду, что сгруппированные посредством предложения GROUP BY агрегатные функции, могут производить многочисленные значения и поэтому могут использоваться только с оператором IN.

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

SELECT * FROM Жилье WHERE Плата

BETWEEN (SELECT AVG(Плата) FROM Жилье GROUP BY Город

123

HAVING Город = "Пенза") AND

(SELECT MAX(Плата) FROM Жилье); Но лучше его было бы использовать без применения GROUP

BY: SELECT * FROM Жилье WHERE Плата

BETWEEN (SELECT AVG(Плата) FROM Жилье WHERE Город = "Пенза")

AND (SELECT MAX(Плата) FROM Жилье);

Результат обоих запросов показан ниже и имеет смысл: выдать список недвижимости, арендная плата за которую выше средней арендной платы по городу Пенза (табл. 4.11).

Таблица 4.11

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

ЖNo Улица Область Город Индекс Тип Ком-наты Плата ВлNo Сno ФNo

ЖА14 ул.Н-16

Астрахан-ская

Астрахань 343434 Дом 6 650,00р. В46 4 Ф7

ЖЖ21 ул.D-18

Пензен- ская

Пенза 343438 Дом 5 600,00р. В87 2 Ф3

ЖЖ16 ул.N-5 Пензен- ская

Пенза 343439 Кв. 4 450,00р. В93 3 Ф3

Вложенные запросы могут появляться в списке таблиц после слова FROM. В этом случае вложенный запрос может возвращать любое количество записей с любыми значениями. Например, по-следний запрос можно записать в следующем виде:

SELECT a.* FROM Жилье AS a,

(SELECT AVG(Плата) AS AvgПлата FROM Жилье WHERE Город = "Пенза") AS b,

124

(SELECT MAX(Плата) AS MaxПлата FROM Жилье) AS c

WHERE a.Плата BETWEEN b.AvgПлата AND c.MaxПлата;

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

ния, как и в обычных запросах.

4.14. Связанные подзапросы

Связанные подзапросы используются, когда в запросе имеется ссылка на таблицу, имя которой указано в предложении FROM внешнего запроса. Подзапрос выполняется один раз для каждой строки таблицы из основного запроса:

SELECT Имя, Фамилия FROM Съемщик a WHERE #04/20/1998# IN

(SELECT дата FROM Осмотр b WHERE a.СкNo = b.СкNo); Смысл данного запроса: выдать список клиентов, которые ос-

матривали недвижимость 20 апреля 1998 года. Результатом будет одна строка с именем и фамилией клиента — Иван Ключов.

В этом запросе используется подзапрос, позволяющий связать (соединить) две таблицы по полю СкNo. Псевдоним «а» внешней таблицы используется в подзапросе, таким образом, мы имеем де-ло со связанным подзапросом. Следует заметить, что значение да-ты дано в формате #mm/dd/yyyy#, который используется в MS-SQL (и MS-Access соответственно). Здесь mm — номер месяца, dd — номер дня, yyyy — год. Для других реализаций языка SQL возможны различные варианты.

Отметим также, что при определении алиаса таблицы мы опус-тили слово AS, что тоже опускается в различных реализациях SQL.

125

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

SELECT b.Имя, Фамилия, Телефон,Город,Улица,

Область, c.Плата FROM Владелец b,

(SELECT a.* FROM Жилье AS a WHERE Город = "Пенза") as c

WHERE b.ВлNo=c.ВлNo ORDER BY Плата; Результат выполнения запроса отражен в табл. 4.12.

Таблица 4.12

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

Имя Фамилия Телефон Город Улица Область Плата Татьяна Мурова 3040520 Пенза ул.L-6 Пензенская 350,00р. Антон Целых 3040530 Пенза ул.М-2 Пензенская 375,00р. Антон Целых 3040530 Пенза ул.N-5 Пензенская 450,00р. Кирилл Фирсов 3040510 Пенза ул.D-18 Пензенская 600,00р.

Заметим, что в этом запросе мы намеренно несистематично ис-пользовали алиасы в первой строке. Цель этого — показать, что если имена полей различны, то SQL сам «сообразит», из какой таблицы нужно выбирать то или иное поле. Однако для лучшего понимания запроса предпочтительнее все-таки указывать алиасы перед именами полей.

При использовании связанных подзапросов в предложении HAVING в них можно применять только функцию агрегирования из предложения SELECT внешнего запроса или поле из предложе-ния GROUP BY.

Например, необходимо выбрать города, средняя цена жилья в которых более чем на 150 рублей меньше максимальной:

126

SELECT Город, Avg(Плата) AS СредняяЦена, max(Плата) AS MaxЦена

FROM Жилье AS a GROUP BY Город HAVING (Avg(a.Плата)+150) < (SELECT max(Плата) FROM Жилье AS b WHERE a.Город = b.Город); Результат выполнения запроса отражен в табл. 4.13.

Таблица 4.13

Результат выполнения запроса с использованием операторов HAVING и GROUP BY

Город СредняяЦена MaxЦена Пенза 443,75р. 600,00р.

4.15. Оператор EXISTS

Оператор EXISTS используется, чтобы указать предикату главного запроса, производит подзапрос вывод каких-то данных или нет. EXISTS — это оператор, возвращающий верное или не-верное значение, т.е. логический оператор. Это означает, что он может работать автономно в предикате или в комбинации с други-ми логическими выражениями операторами AND, OR и NOT. Оператор берет подзапрос как аргумент и оценивает его как вер-ный, если подзапрос производит какой-либо вывод, или оценивает как неверный, если подзапрос ничего не возвращает (или возвра-щает пустой результат).

Например, необходимо получить данные из таблицы «Жилье» только в том случае, если хотя бы одно из них (или несколько) есть в Москве:

SELECT * FROM Жилье

127

WHERE EXISTS (SELECT * FROM Жилье WHERE Город='Москва'); Результат выполнения запроса отражен в табл. 4.14.

Таблица 4.14

Результат выполнения запроса с использованием оператора EXISTS

Область Город Улица Астраханская Астрахань ул.Н-16 Московская Москва ул.А-6 Пензенская Пенза ул.L-6 Пензенская Пенза ул.М-2 Пензенская Пенза ул.D-18 Пензенская Пенза ул.N-5

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

Более часто EXISTS применяется со связанными запросами. В этом случае EXISTS оценивается отдельно для каждой строки таб-лицы, на которую есть ссылка во внешнем запросе. Например, не-обходимо выдать список сотрудников, которые курируют более одного объекта недвижимости (табл. 4.15):

Таблица 4.15

Запрос с использованием оператора EXIST и его результат

SELECT DISTINCT СNo From Жилье AS ВнешнЗапрос WHERE EXISTS

(SELECT * FROM Жилье AS ВнутрЗапросWHERE

ВнешнЗапрос.СNo=ВнутрЗапрос.СNo AND ВнешнЗапрос.ЖNo<>ВнутрЗапрос.Жno );

CNo2 3

128

Для каждой строки-кандидата внешнего запроса внутренний запрос находит строки, имеющие соответствующее значение но-мера сотрудника (т.е. «тот же сотрудник»), но другое значение ко-да недвижимости ЖNo. Если строка, удовлетворяющая данному критерию, найдена во внутреннем запросе, это означает что пре-дикат EXISTS истинен для текущей строки внешнего запроса и номер сотрудника включается в результат. Оператор DISTINCT исключает повторения, которые могут быть, поскольку номера клиентов будут выводиться для каждого объекта недвижимости.

Усложним запрос, добавив в результат вывода, кроме кода со-трудника, еще его имя, адрес и телефон. Теперь необходимо ис-пользовать комбинацию оператора EXISTS и соединение двух таблиц:

SELECT DISTINCT Внеш1.СNo, Внеш1.Фамилия, Внеш1.Имя, Внеш1.Адрес, Внеш1.Телефон FROM Сотрудники AS Внеш1, Жилье Внеш2 WHERE EXISTS

(SELECT * FROM Жилье AS ВнутрЗапрос WHERE Внеш2.СNo=ВнутрЗапрос.СNo AND

Внеш2.ЖNo<>ВнутрЗапрос.ЖNo) AND Внеш1.СNo= Внеш2.СNo;

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

изменены только псевдонимы. Внешний запрос соединяет табли-цы Сотрудники и Жилье по полю CNo, оценивая одновременно оператор EXISTS. В результате использования алиасов получаем доступ к нужным полям, раскрывающим информацию о сотрудни-ках, курирующих более одного объекта недвижимости.

Оператор EXISTS очень часто используют в комбинации с оператором NOT, который меняет его смысл на противоположный. Например, для того чтобы получить данные о сотрудниках, кури-рующих только один объект недвижимости, достаточно в преды-дущем примере использовать NOT EXISTS.

129

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

4.16. Использование операторов ANY, SOME, ALL

Эти операторы используются только с подзапросами в сочета-нии с логическими операциями. Каждый из них «считает» подза-прос своим аргументом, точно так же как и оператор EXISTS.

ANY и SOME имеют одно и то же назначение и являются си-нонимами. ANY (или SOME) оценивает результат как истину, если какое-либо выбранное подзапросом значение совпадает с опреде-ленным условием или некоторым полем.

Пусть необходимо выбрать те объекты недвижимости, которые расположены в городах, где есть филиалы:

SELECT ЖNo, Город, Улица, ФNo FROM Жилье WHERE Город = ANY (SELECT Город FROM Филиал); Результат выполнения запроса отражен в табл. 4.16.

Таблица 4.16

Результат выполнения запроса с использованием оператора ANY для поиска городов

ЖNo Город Улица ФNo ЖЛ94 Москва ул.А-6 Ф5 ЖЖ4 Пенза ул.L-6 Ф3 ЖЖ36 Пенза ул.М-2 Ф3 ЖЖ21 Пенза ул.D-18 Ф3 ЖЖ16 Пенза ул.N-5 Ф3

Оператор ANY «берет» каждое значение поля «Город» в таблице Филиал, полученной в подзапросе, и оценивает результат как истину, ес-ли какое-либо значение совпадает со значением поля «Город» из теку-щей строки внешнего запроса. Это означает, что подзапрос должен вы-

130

давать значения того же типа, которые сравнивались в предикате. Это важная особенность использования ANY.

В данном примере оператор ANY работает аналогично опера-тору IN. То есть, если вместо «Город=ANY» указать «Город IN», то результат выполнения не изменится. Важно понимать, что ANY может использоваться совместно с другими логическими операто-рами (операторы сравнения) и тем самым отличается от IN.

Выберем недвижимость, которая по стоимости дороже, чем ка-кая-либо недвижимость в Пензе:

SELECT ЖNo, Город, Улица, ФNo, Плата FROM Жилье WHERE Плата > ANY (Select Плата from Жилье

WHERE Город='Пенза'); Результат выполнения запроса отражен в табл. 4.17.

Таблица 4.17

Результат выполнения запроса с использованием оператора ANY для поиска стоимости выше, чем в городе Пенза

ЖNo Город Улица ФNo Плата ЖА14 Астрахань ул.Н-16 Ф7 650,00р. ЖЛ94 Москва ул.А-6 Ф5 400,00р. ЖЖ36 Пенза ул.М-2 Ф3 375,00р. ЖЖ21 Пенза ул.D-18 Ф3 600,00р. ЖЖ16 Пенза ул.N-5 Ф3 450,00р.

Главное понять, что условие ANY рассматривается как выра-жение «хотя бы одного». В Пензе несколько объектов недвижимо-сти с разной стоимостью. Минимальная стоимость жилья в Пензе — 350 р. Поэтому запрос выберет все записи, в которых стоимость больше 350 (т.е. больше стоимости «хотя бы одного» объекта не-движимости в Пензе).

Другой важный оператор, который используется с подзапроса-ми — это оператор ALL. Он принимает значение «истина», если каждое значение, выбранное в процессе выполнения подзапроса,

131

удовлетворяет условию, заданному в предикате внешнего запроса. Если подзапрос не генерирует выходных данных, то ALL — исти-на, а ANY — ложь.

Например, необходимо выдать список недвижимости, которая по стоимости дороже, чем стоимость каждой недвижимости в Пензе.

Запрос будет полностью совпадать с предыдущим, только вме-сто оператора ANY нужно поставить оператор ALL.

SELECT ЖNo, Город, Улица, ФNo, Плата FROM Жилье WHERE Плата > ALL (Select Плата from Жилье

WHERE Город='Пенза');

ЖNo Город Улица ФNo Плата ЖА14 Астрахань ул.Н-16 Ф7 650,00р.

4.17. Оператор UNION

Оператор UNION объединяет выходные данные двух или бо-лее SQL-запросов в единое множество строк и столбцов. В объе-динении ни один из запросов не влияет на другой: они выполня-ются независимо, но их выходные данные затем объединяются и выдаются в качестве результата.

UNION автоматически исключает из объединения повторяю-щиеся строки, а предложение ORDER BY применяется для упоря-дочивания данных всего объединения.

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

132

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

Формат оператора следующий: <запрос1> UNION <запрос2> [UNION <запрос3> . . . ] [ORDER BY <Номер столбца>];

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

SELECT Фамилия, Имя, Телефон, 'Сотрудник' AS Должность, ЗП AS Оклад

FROM Сотрудники UNION SELECT Фамилия, Имя, Телефон, 'Арендатор',

'По контракту' FROM Владелец ORDER BY 1;

Результат выполнения запроса отражен в табл. 4.18.

Таблица 4.18

Результат выполнения запроса с использованием оператора UNION

Фамилия Имя Телефон Должность Оклад Бережная Анна 2222220 Сотрудник 12000 Бодрова Сюзанна 5555550 Сотрудник 24000 Здрава Мария 4444440 Сотрудник 9000 Киров Дмитрий 3040500 Арендатор По контракту Лейкина Юлия 6555550 Сотрудник 9000

133

Окончание табл. 4.18

Фамилия Имя Телефон Должность Оклад Мурова Татьяна 3040520 Арендатор По контракту Петров Иван 1111110 Сотрудник 30000 Фирсов Кирилл 3040510 Арендатор По контракту Фордов Давид 3333330 Сотрудник 18000 Целых Антон 3040530 Арендатор По контракту

4.18. Ввод, удаление и изменение значений полей

Вставка, изменение и удаление данных из БД могут быть про-изведены в SQL с использованием трех команд: INSERT (вста-вить), UPDATE (обновить), DELETE (удалить). Все эти команды принадлежат подмножеству DML языка SQL. Они учитывают ог-раничения целостности данных, накладываемые на таблицу сред-ствами СУБД (ввод обязательных непустых полей, ограничения на значения полей, ссылочная целостность, запрет пустых и повто-ряющихся значений в ключевых атрибутах и т.д.) и не будут вы-полнять соответствующие действия, если они приводят к наруше-нию целостности данных.

Все новые записи в SQL вводятся с использованием команды INSERT. В самой простой форме INSERT использует следующий синтаксис:

INSERT INTO <имя_таблицы> VALUES ( <значение1>, <значение2>, ...);

При этом в таблицу добавляется новая запись и полям этой за-

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

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

134

INSERT INTO Владелец VALUES ('Вл99', 'Алексей', 'Петров',

'ул.А-23', 23211233); Команды DML не производят никакого вывода, но как прави-

ло, интерактивный SQL сообщает о результатах выполнения ко-манды. Имя таблицы (в нашем случае Владелец) должно быть предварительно определено, а каждое значение, пронумерованное в предложении значений, должно совпадать с типом данных столбца, в который оно вставляется. В ANSI эти значения не могут составлять выражений, хотя многие реализации допускают ис-пользовать выражения (например, в MS-Access). Значения вводят-ся в таблицу по порядку, поэтому первое значение с именем, авто-матически попадает в столбец 1, второе − в столбец 2 и т.д. Если нужно ввести пустое значение (NULL), то оно вводится точно так же, как и обычное значение.

В конструкции оператора INSERT допускается указывать столбцы, куда необходимо занести значения при вставке. Список столбцов указывается в скобках сразу за именем таблицы. Это по-зволяет вставлять имена в любом порядке и в любом количестве. При этом тем полям, которые не были указаны автоматически, присваиваются значения по умолчанию или, если таковые не оп-ределены, то NULL-значения. В следующем примере показано, как можно добавить новую запись в таблицу Владелец, установив зна-чения для полей «ВлNo» и «Фамилия», а остальным полям будут присвоены NULL-значения, поскольку для данной таблицы ни для каких полей не были определены значения по умолчанию:

INSERT INTO Владелец ( ВлNo, Фамилия ) VALUES ('Вл98', 'Петров');

Если введено ограничение на запрет использования значения NULL в каком-либо столбце и для этого столбца не установлено значение по умолчанию, то этот столбец должен быть обязательно обеспечен значением для любой команды INSERT, которая отно-сится к таблице. Иначе будет выведено сообщение об ошибке, и запись не будет добавлена в таблицу.

135

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

Предположим, все сотрудники мужского пола решили сдать свою недвижимость в аренду, т.е. необходимо добавить этих со-трудников к таблице Владелец. Это можно сделать так:

INSERT INTO Владелец ( ВлNo, Имя, Фамилия, Адрес, Телефон ) SELECT 'Вл' & СNo, Имя, Фамилия, Адрес, Телефон FROM Сотрудники WHERE Пол='М';

Здесь выбираются все значения произведенные запросом, т.е. все сотрудники из таблицы Сотрудники мужского пола помеща-ются в таблицу Владелец. Обратите внимание, как формируется поле «ВлNo» (код владельца) на основании поля «CNo» (код со-трудника). Поскольку эти поля различного типа, пришлось ис-пользовать операцию конкатенации (&), чтобы привести их к од-ному типу.

Удаление записей осуществляется по команде DELETE. Уда-ление столбцов не предусмотрено в этой команде. Формат коман-ды следующий:

DELETE FROM <таблица> [WHERE <предикат>];

При выполнении команды будут удалены все записи указанной таблицы, для которых предикат становится истинным. Если не указывается предложение WHERE с предикатом, то из таблицы будут удалены все записи, однако сама таблица останется в БД. Удаление пустой таблицы из БД осуществляется по другой коман-де — DROP, которая будет рассмотрена ниже. Необходимо пом-нить об ограничениях на целостность данных, которые могут по-мешать удалять те или иные записи. Например, мы хотим удалить из таблицы Владелец записи, в которые не введен адрес:

136

DELETE FROM Владелец WHERE Адрес Is NULL;

Изменять некоторые или все значения в существующей строке можно при использовании команды UPDATE. Формат команды следующий:

UPDATE <таблица> SET <поле1>=<значение1>[, <поле2>=<значение2>, ...] [WHERE <предикат>]; В указанной таблице изменяется значение поля или нескольких

полей. Если не указан предикат WHERE, то изменения будут вне-сены для всех записей таблицы. Если указан предикат WHERE, то изменения вносятся только в те записи, которые удовлетворяют условию предиката. В предложении SET можно указывать и пус-тые (NULL) значения для полей.

Предположим, необходимо повысить в должности всех менед-жеров, назвав их должности «Старший менеджер», и увеличить им оклад на 20%:

UPDATE Сотрудники SET ЗП=((ЗП* 120)/100),

Должность = 'Старший Менеджер' WHERE Должность='Менеджер'; Например, очистим значение поля «Комментарий» для всех за-

писей в таблице Осмотр: UPDATE Осмотр SET Комментарий = NULL; Внутри предикатов в командах INSERT, UPDATE, DELETE

можно использовать подзапросы точно таким же образом, как ис-пользовались подзапросы в предикате WHERE оператора SELECT. Например, повысим оклад на 5% тем сотрудникам, которые кури-руют более одного объекта недвижимости:

137

UPDATE Сотрудники SET ЗП=((ЗП* 105)/100) WHERE 2 <= (SELECT COUNT (СNo)

FROM Жилье WHERE Сотрудники.СNo = Жилье.СNo );

4.19. Создание таблиц

Таблицы создаются командой CREATE TABLE. Эта команда создает пустую таблицу — таблицу без строк. Далее значения вво-дятся в таблицу с помощью команды INSERT.

Синтаксис команды CREATE TABLE: CREATE TABLE <имя таблицы> ( <имя столбца> <тип данных> [(<размер>)]

[<ограничения>], . . .

<имя столбца> <тип данных> [(<размер>)] [<ограничения>],

<ограничения на таблицу> ( <столбец1> [, <столбец2>,…]),

. . . <ограничения на таблицу> ( <столбец1>

[, <столбец2>,…]) ) ; Здесь: имя таблицы — имя создаваемой таблицы; имя столбца — имена столбцов таблицы; тип данных — тип данных столбца таблицы с возможным ат-

рибутом размера (см. выше раздел «Типы данных в SQL); ограничения — возможные ограничения, накладываемые тре-

бованием обеспечения целостности данных. Ограничения пере-числяются через пробел. Наиболее часто используемые ограниче-ния: NOT NULL — запретить использование NULL-значений в данном поле; UNIQUE — обеспечить поддержку только уникаль-ных, неповторяющихся значений в данном поле; PRIMARY KEY — поле является первичным ключом; CHECK ( <предикат> ) — раз-

138

решить ввод в поле только тех значений, которые удовлетворяют предикату; DEFAULT = <значение> — определяет значение, при-сваиваемое полю по умолчанию после добавления новой строки в таблицу.

Ограничения на таблицу схожи с ограничениями на столбцы, только эти ограничения действуют на группу столбцов, указанных в скобках. Например, в ограничениях на таблицу могут быть ука-заны: PRIMARY KEY — список столбцов, являющихся первич-ным ключом; UNIQUE — группа столбцов, комбинация значений которых должна быть уникальной; CHECK(<предикат>) — преди-кат, который проверяется всегда при изменении группы значений в таблице.

Например, создадим таблицу филиалов:

CREATE TABLE Филиалы ( ФNo char(3) NOT NULL UNIQUE PRIMARY KEY, Улица char(30), Область char(30) DEFAULT = ‘Ростовская’, Город char(20) DEFAULT = ‘Таганрог’

CHECK ( IN (‘Таганрог’, ‘Ростов’, ‘Шахты’, ‘Новочеркасск’, ‘Белая Калитва’),

Индекс LONG, Телефон char(12), Факс char(12), CHECK( (Индекс>=0)AND ((Телефон IS NOT NULL) OR (ФАКС IS NOT NULL)) ) );

В созданной таблице первичным ключом является поле «ФNo», которое требует ввода только уникальных ненулевых зна-чений, поле «Область» принимает значение по умолчанию «Рос-товская», а в поле «Город» можно ввести только значения четырех городов Ростовской области. На всю таблицу (точнее на каждую запись таблицы) наложено ограничение: почтовый индекс должен быть больше, либо равен нулю и в каком-то одном из полей «Те-лефон» или «Факс» должно быть непустое значение.

139

Примечание. MS-Access SQL не поддерживает конструкции ограничения CHECK, DEFAULT в операторе CREATE TABLE, хотя сама СУБД обеспечивает это в режиме конструктора таблиц.

4.20. Обеспечение ссылочной целостности

Система находится в состоянии ссылочной целостности, если каждое значение внешнего ключа (каждая строка) ссылается толь-ко на одно значение (одну строку) родительского ключа.

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

Все наши таблицы (Сотрудники, Владелец, Жилье, Филиал, Съемщик, Осмотр) находятся в состоянии ссылочной целостности. Рассмотрим пример: таблица Владелец имеет первичный ключ — по-ле «ВлNo». Такое же поле имеется в таблице Жилье. Для таблицы Жилье поле «Жилье.ВлNo» является внешним ключом, а поле «Владелец.ВлNo» — родительским. Действительно, какое бы мы ни взяли значение из поля «Жилье.ВлNo», оно будет ссылаться на одну и только одну строку в таблице «Владелец». Это логично: у частной собственности (недвижимости в нашей предметной облас-ти) не может быть более одного владельца. Аналогичным образом для каждой связи в нашем примере мы можем указать пару — («родительский ключ», «внешний ключ»): («Жилье.ЖNo», «Ос-мотр.ЖNo»), («Филиал.ФNo», «Съемщик.ФNo») и т.д.

При создании таблиц язык SQL позволяет ввести ограничения на ссылочную целостность таблиц. Для этого используются конст-рукция FOREIGN KEY (переводится как «внешний ключ») и кон-струкция REFERENCES.

Возможны два варианта использования этих двух конструкций: 1) описание внешнего ключа как ограничения на таблицу; 2) описание внешнего ключа как ограничения на поле (исполь-

зуется, если ключ содержит только одно поле).

140

В первом случае в конце конструкции CREATE TABLE в области перечисления ограничений на таблицу указывается конструкция

FOREIGN KEY (<поле1>[,<поле2>,...] ) REFERENCES <имя таблицы> (<поле21> [,<поле22>,...]) .

Эта конструкция позволяет определить, что указанные поля (<поле1>,<поле2>,...) являются внешним ключом для данной таб-лицы, а родительский ключ находится в указанной таблице («<имя таблицы>» ) и определяется указанными полями (<по-ле21>,<поле22>,...). Такую конструкцию лучше использовать для составных ключей, т.е. когда ключи состоят из нескольких полей, но также ее можно использовать и для простых ключей. Например, чтобы определить связь родительского и внешнего ключей («Вла-делец.ВлNo», «Жилье.ВлNo») при создании таблицы «Жилье» нужно использовать конструкцию на ограничение таблицы:

FOREIGN KEY (ВлNo) REFERENCES Владелец (ВлNo).

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

REFERENCES <имя таблицы> (<поле21> [,<поле22>,...]),

которая имеет аналогичный смысл, что и в первом случае. Напри-мер, как альтернативу первого варианта для той же связи («Владе-лец.ВлNo», «Жилье.ВлNo») при создании таблицы «Жилье» в об-ласти описания поля «ВлNo» можно написать следующее:

ВлNo CHAR(6) REFERENCES Владелец (ВлNo).

Когда введены ограничения на обеспечение ссылочной цело-стности в поле внешнего ключа невозможно ввести значение, ко-торое отсутствует в родительском ключе, но возникает вопрос, как быть с внешним ключом, если меняется (обновляется) или удаля-ется значение родительского ключа. Возможны три варианта:

1) запретить изменение родительского ключа, т.е. изменение родительского ключа ограничено (RESTRICTED);

141

UPDATE OF <имя таблицы> RESTRICTED |

CASCADES | NULLS

и/или DELETE OF <имя таблицы> RESTRICTED |

CASCADES | NULLS.

2) разрешить изменение родительского ключа, но при таком изменении автоматически менять все значения во внешних клю-чах, т.е. изменения производятся каскадно (CASCADES);

3) разрешить изменение родительского ключа, но при таком изменении автоматически устанавливать все значения внешнего ключа равным NULL.

Каждый из трех вариантов может быть рассмотрен относи-тельно операций обновления и удаления. Тогда говорят о возмож-ных эффектах обновления и эффектах удаления. В SQL имеется возможность указать на способ использования эффектов удаления и эффектов обновления. Для этого в разделе описания ограниче-ний таблицы с внешним ключом указываются конструкции:

Здесь <имя таблицы> указывает на таблицу с родительским ключом.

Например, для той же связи («Владелец.ВлNo», «Жи-лье.ВлNo») при создании таблицы Жилье в области описания ог-раничений на таблицу можно написать следующее:

UPDATE OF Владелец CASCADES DELETE OF Владелец RESTRICTED.

Это будет означать, что при изменении номера владельца в таблице Владелец каскадно будут изменены все связанные номера в таблице Жилье, а удаление записей в таблице Владелец будет ог-раничено, т.е. запрещено до тех пор, пока в таблице Жилье есть хотя бы одна запись в которой значение поля «ВлNo» совпадает со значением поля «ВлNo» удаляемой записи таблицы Владелец.

142

4.21. Изменение структуры таблиц и удаление таблиц

Чтобы изменить определение существующей таблицы, исполь-зуется команда ALTER TABLE. Она не входит в стандарт ANSI, но достаточно широко применяется в различных реализациях. Ко-манда обычно используется для добавления столбцов к таблице. Иногда она может удалять столбцы или изменять их размеры, а также в некоторых реализациях добавлять или удалять ограниче-ния. Приведем синтаксис команды для добавления столбца к таб-лице:

ALTER TABLE <имя таблицы> ADD <имя столбца> <тип данных>(<размер>) [, <имя столбца> <тип данных>(<размер>),...];

Столбец будет добавлен со значением NULL для всех строк таблицы. Новый столбец станет последним по порядку столбцом таблицы. В некоторых реализациях SQL имеется возможность удалять столбцы (DEL вместо ADD) или изменять параметры столбцов. Наиболее часто изменением столбца может быть просто увеличение его размера или добавление (удаление) ограничения. Любые изменения в таблице должны не противоречить сущест-вующим данным и не повреждать их.

Для удаления пустой таблицы из БД используется простая кон-струкция:

DROP TABLE <имя таблицы >;

В многопользовательских SQL-системах для удаления таблицы необходимо быть ее собственником (т.е. создателем).

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

4.22. Представления

Представления (view) — это таблицы, содержание которых выбирается из других таблиц с помощью выполнения запроса.

143

Реализация представлений в SQL-системах, как правило, говорит о сущности представлений — это запросы, которые выполняются всякий раз, когда представление является объектом команды. Вы-вод результатов выполнения запроса при этом в каждый момент становится содержанием представления. Это как «замочная сква-жина», через которую можно смотреть на реальные таблицы БД.

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

Представление создается с помощью команды

CREATE VIEW <имя представления> AS <запрос> [WITH CHECK OPTION];

Если указано предложение WITH CHECK OPTION, представ-

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

Удаление представления осуществляется по команде DROP VIEW <имя представления>;

Представление бывает обновляемым (updatable), если к нему можно применить команды обновления (INSERT, DELETE и UPDATE), и читаемым (read-only) в противном случае. Существует несколько требований для создания обновляемых представлений: • представление должно базироваться на одной таблице; • представление должно включать первичный ключ таблицы;

144

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

• представление не должно содержать спецификаций DISTINCT, GROUP BY, HAVING;

• представление не должно использовать подзапросы; • представление не может содержать константы, строки, выра-

жения в списке выбранных выходных полей.

4.23. Привилегии

Каждый пользователь в многопользовательской среде SQL имеет специальное идентификационное имя или номер. Команда, посланная в БД, ассоциируется с определенным пользователем или, иначе, со специальным идентификатором доступа. Любая команда интерпретируется и разрешается (или запрещается) на ос-нове информации, связанной с идентификатором доступа пользо-вателя, подавшего команду.

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

SQL-привилегии определенные ANSI, — это объектные при-вилегии. Это означает, что пользователь имеет привилегию вы-полнить данную команду только для определенного объекта в БД. Привилегии должны различаться для разных объектов. Объектные привилегии связаны одновременно и с пользователями, и с табли-цами. То есть привилегия дается определенному пользователю для определенной таблицы, либо для базовой таблицы, либо для пред-ставления. Необходимо помнить, что пользователь, создавший таблицу любого вида, является владельцем этой таблицы. Это оз-начает, что пользователь имеет все привилегии на эту таблицу и может передавать ее другим пользователям для работы с ней. При-ведем основные привилегии, которые можно назначить пользова-телю:

145

SELECT — пользователь с этой привилегией может выполнять запросы для таблицы;

INSERT — пользователь с этой привилегией может выполнять команду INSERT для таблицы;

UPDATE — пользователь с этой привилегией может выпол-нять команду UPDATE для таблицы. Эта привилегия может огра-ничить возможность обновление для определенных столбцов таб-лицы;

DELETE — пользователь с этой привилегией может выполнять команду DELETE для таблицы;

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

Существуют привилегии, которые называются системными. Они предоставляют определенные права для администратора SQL-системы. Например, привилегия DBA (Data Base Administrator — администратор базы данных) дает полный доступ ко всем табли-цам и системным ресурсам SQL-системы, RESOURSE — право создавать таблицы, CONNECT — право на соединение с БД и т.п. Такие привилегии в основном зависят от реализации SQL-системы.

Создатель таблицы (а также системный администратор) имеет все права на нее, а поэтому может предоставлять некоторые права на таблицу кому-нибудь еще. Это может быть выполнено с помо-щью команды GRANT. Формат команды следующий:

GRANT ALL | <привилегия1>,<привилегия2>,... ON <имя таблицы> TO PUBLIC | <пользователь1>,

<пользователь2>,... [WITH GRANT OPTION];

Команда выдает права (привилегии) на таблицу, указанные че-рез запятую тем пользователям, имена которых указаны в конце команды. Если в конце команды добавлена строка WITH GRANT OPTION, то эти пользователи имеют право передавать полученные

146

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

Для отмены привилегий работает команда REVOKE, формат которой аналогичен команде GRANT:

REVOKE ALL | <привилегия1>,<привилегия2>,... ON <имя таблицы> TO PUBLIC | <пользователь1>,

<пользователь2>,...; Привилегии можно применять (и отменять) к представлениям

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

В качестве аргументов для GRANT и REVOKE можно взять ключевые слова ALL и PUBLIC. Слово ALL используется вместо списка привилегий, когда необходимо предоставить пользователю все права. Слово PUBLIC — вместо списка пользователей, если необходимо предоставить указанные права не каким-то конкретно пользователям, а всем пользователям системы.


1. Какие типы языка SQL используются в различных СУБД? 2. Назовите, на какие подмножества можно разделить SQL. 3. Какой стандарт был введен для абсолютной совместимости? 4. Что такое запрос? 5. Из какой команды состоит запрос? 6. Какие ключевые слова используются при группировке дан-

ных? 7. Как SELECT оценивает каждую возможную строку кандидата? 8. Перечислите операторы сравнения, логические и арифмети-

ческие операторы. 9. Для чего используется оператор BETWEEN? 10. Чем отличается значение поля NULL от 0?

147

11. Назовите все агрегатные функции. 12. Что означает значение поля «*»? 13. Какой оператор позволяет выбирать данные из разных таб-

лиц? 14. Перечислите типы соединения для конструкции JOIN? 15. Что такое алиас? 16. Напишите пример построения вложенного подзапроса. 17. Для чего используют оператор UNION? 18. Как создать таблицу в SQL? 19. Объясните, как происходит ввод, удаление и изменение

значений полей? 20. В каком случае система находится в состоянии ссылочной

целостности? 21. Что означает View? 22. С помощью какой команды вводятся новые записи? 23. Какие команды могут удалить таблицу? 24. Перечислите требования для создания обновляемых пред-

ставлений. 25. Перечислите основные привилегии, которые можно назна-

чить пользователю?


1. В языке запросов SQL можно выделить подмножества: a) MСL b) VCL c) HTML d) DQL e) DML f) TRL

2. При помощи языка SQL можно решать задачи:

a) извлечение данных из таблиц b) сохранение резервных копий баз данных на твердый но-

ситель

148

c) подключение удаленных серверов для обработки дан-ных

d) настройка СУБД для конкретного пользователя e) установка иерархического дерева модели f) обработка транзакций

3. Транзакция — это:

a) последовательность операций, которые должны быть выполнены либо все, либо вообще не выполнены

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

c) настройка СУБД на выполнение ряда операций автома-тически

d) процесс сжатия БД в резервную копию, который не мо-жет быть прерван

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

4. SQL оперирует с данными следующих типов (по стандарту

ANSI): a) символьные b) численные c) логические d) календарные e) валютные (денежные) f) исчисляемые

5. Запрос SQL по сути является:

a) указанием СУБД выбрать данные или каким-то образом их организовать

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

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

d) указания клиенту как хранить и обрабатывать выбран-ные данные

149

e) ряд инструкций для администратора БД о процессе вы-борки данных

6. При запросе на выборку SQL — запрос начинается с клю-

чевого слова: a) Take b) From c) Select d) Extract e) Where f) Reject

7. При формировании запроса на выборку являются обяза-

тельными секции: a) select выражение или список полей b) from таблица или другой запрос c) where условие отбора записей d) group by атрибуты по которым производится группи-

ровка e) having условие отбора f) order by атрибут по которому производится сортировка

8. Запрос «Select * from tblBook» выдаст как результат:

a) только пустые поля таблицы tblBook b) только непустые записи таблицы tblBook c) только пустые записи таблицы tblBook d) только непустые поля таблицы tblBook e) все содержимое таблицы tblBook f) список всех столбцов таблицы tblBook

9. Запрос «Select distinct * from tblBook» выдаст как результат:

a) только пустые поля таблицы tblBook b) список всех столбцов таблицы tblBook c) только те записи таблицы tblBook, которые содержат

символ * d) только те поля таблицы tblBook, которые содержат символ *

150

e) все содержимое таблицы tblBook, исключив строки-дубликаты

10. Ключевое слово having используется совместно с:

a) предикатом, указанном в where b) агрегатными предикатами c) ключевым словом group by d) ключевым словом distinctrow e) ключевым словом desc

11. Оператор Select при проверке предикатов рассматривает:

a) каждую строку каждой указанной таблицы b) каждый столбец каждой указанной таблицы c) только те строки, для которых указан предикат d) только те строки, на которых определен предикат e) комбинацию каждой строки таблицы со всеми комби-

нациями строк из других таблиц

12. Формирование предиката допускает использование опера-торов и операций: a) () — группировка предикатов b) математические операции +, -, * и т.д. c) строковые операции d) операторы сброса reset, clear и т.д. e) операторы зависимостей f(x) f) исключающие операторы except и т.д.

13. Ошибка в данной записи запроса на выборку заключается в

том, что: «Select tblBook.intId, tblBook.strTitle, tblBook.intPrice,

(tblBook.intPrice * 15/100) as ‘web-shop extra charge’» a) отсутствует обязательное указание, какие именно стро-

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

ки-дубликаты

151

c) присутствует излишнее дублирование названия таблицы в секции select

d) присутствует излишнее дублирование указания источ-ника данных

e) запрещено вычислять значение поля в запросе f) отсутствует обязательное указание источника данных

14. Оператор IN предназначен для:

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

b) задания границ множества для проверки вхождения в него значения некоторого атрибута

c) задания границ и мощности множества для проверки вхождения в него значения некоторого атрибута

d) задания некоторой области определения для некоторого атрибута

e) сравнения атрибута с границами некоторого множества значений

f) определения вхождения (или не вхождения) атрибута в список заданных атрибутов некоторого отношения

15. Оператор, задающий границы некоторого множества (диа-

пазона) значений для проверки принадлежности к нему зна-чения некоторого атрибута: a) in b) is c) having d) conclude e) like f) between g) inside

16. Оператор like предназначен для:

a) осуществления поиска значений атрибутов по заданной маске

b) осуществления поиска однокоренных слов по заданно-му корню

152

c) осуществления генерации всех значений некоторого ат-рибута, похожего на заданный

d) задание границ некоторого множества, элементы кото-рого являются родственными для некоторого атрибута

e) осуществления поиска родственных атрибутов для не-которого заданного

17. Запрос, выбирающий все книги от 1996 до 2000 года выпус-

ка из таблицы tblBook имеет вид: a) Select * from tblBook where tblBook.Год выпуска > 1995

and tblBook.Год выпуска <= 2000 b) Select * from tblBook where tblBook.Год выпуска in

(1996, 1997, 1998, 1999, 2000) c) Select tblBook.Год выпуска (1996, 1997, 1998, 1999,

2000) from tblBook where tblBook.Год выпуска like this d) Select * from tblBook where tblBook.Год выпуска > 1996

and tblBook.Год выпуска < 2000 e) Select * from tblBook where tblBook.Год выпуска like be-

tween (1996, 1997, 1998, 1999, 2000) f) Select * from tblBook where tblBook.Год выпуска between

(1996, 1997, 1998, 1999, 2000)

18. Значение Null для атрибута означает, что: a) данное поле не имеет домена b) данный атрибут не имеет домена c) значение этого поля равно 0 для цифровых полей d) значение этого поля равно «» для строговых полей e) значение этого поля равно «/0» для строговых полей f) данное поле не имеет значения

19. Для нахождения обобщенных групповых значений полей

(так же как и одного поля) используют функции: a) вычисления b) математические c) статистические d) агрегатные e) агрегирования

153

20. Функция, производящая поиск количества строк, называется: a) cntc b) number c) avg d) enum e) count

21. Функция поиска количества строк имеет следующие огра-

ничения на аргумент: a) только текстовые поля b) только числовые поля c) только поля дата/время d) только логические поля e) может использовать поля любого типа

22. Функция поиска минимального значения имеет ограниче-

ния на аргумент: a) только текстовые поля b) только числовые поля c) может использовать и числовые и текстовые поля d) только числа и даты e) только логические f) может использовать поля любого типа

23. Функция поиска суммарного значения имеет ограничения

на аргумент: a) только текстовые поля b) только числовые поля c) может использовать и числовые и текстовые поля d) только числа и даты e) только логические f) может использовать поля любого типа g)

24. В случае необходимости указания каких-либо критериев отбора данных для функций агрегирования используют ключевые слова: a) order by

154

b) having by c) where d) then e) group by f) having

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

нескольких групп данных в таблице используют ключевые слова: a) order by b) having by c) where d) then e) group by f) having

26. Запрос, определяющий среднюю цену книг каждого автора

2002 года: a) Select count ( tblBook.Название) from tblBook group by

tblBook.Автор having tblBook.Год выпуска = 2002 b) Select count ( tblBook.Название) from tblBook group by

tblBook.Автор where tblBook.Год выпуска = 2002 c) Select count ( tblBook.Название) from tblBook order by

tblBook.Автор where tblBook.Год выпуска = 2002 d) Select count ( tblBook.Название having tblBook.Год вы-

пуска = 2002) from tblBook e) Select count ( tblBook.Название) having tblBook.Год вы-

пуска = 2002 from tblBook group by tblBook.Автор f) Select count ( tblBook.Название) from tblBook having

tblBook.Год выпуска = 2002 group by tblBook.Автор

27. Рекурсивное соединение — это: a) последовательное соединение нескольких таблиц b) попарное соединение нескольких таблиц c) соединение таблиц по кольцу

155

d) соединение запроса и таблицы e) соединение таблицы и запроса к ней же f) соединение таблицы (запроса) с собой

28. Подзапрос SQL можно поместить:

a) в произвольное место основного запроса b) только в select-секции c) только в секции предиката where d) только в секции предиката having, при использовании

group by e) в частной секции запроса или в select-секции f) только в той части, где указываются данные или источ-

ник данных

29. Оператор Union накладывает следующее ограничение на свои аргументы: a) домены атрибутов аргументов должны совпадать b) кортежи атрибутов аргументов должны совпадать c) атрибуты аргументов должны быть равны d) аргументы атрибутов должны совпадать e) аргументы кортежей должны совпадать

30. Оператор All используется для того чтобы … подзапрос(ов):

a) указать тип предиката объединения связанных b) проверить, производит ли вывод указанный c) проверить существует ли хотя бы один из заданных d) указать, что в качестве источника данных может быть

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

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

каждя строка из результата

Ответы: 1 — d, e, f; 2 — a, f; 3 — a; 4 — a, b; 5 — a; 6 — c; 7 — a, b; 8 — e; 9 — e; 10 — c; 11 — e; 12 — a, b, c; 13 — f; 14 — a; 15 — f; 16 — a; 17 — a; 18 — f; 19 — d, e; 20 — e; 21 — e; 22 — c; 23 — b; 24 — e, f; 25 — e; 26 — a; 27 — f; 28 — f; 29 — a; 30 — f.

156

ЗАКЛЮЧЕНИЕ

Жизненный цикл любой информационной системы (ИС) мож-но разбить на три основные стадии [13]: • анализ и проектирование; • программная реализация; • эксплуатация.

На стадии анализа и проектирования ИС проектировщик дол-жен проделать следующую работу. 1. Обследовать предметную область автоматизации. 2. Провести планирование разработки баз данных для поиска са-

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

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

4. Определить типы сущностей, типы связей, перечень атрибутов и связать их с типами сущностей и связей.

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

6. Подготовить диаграмму «Сущность–связь». 7. Обсудить полученную концептуальную модель данных с ко-

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

модель путем: устранения связей типа M:N, устранения слож-ных связей (связей со степенью больше 2), устранения рекур-сивных связей, устранения связей с атрибутами, удаления

157

множественных атрибутов, удаления избыточных связей и пе-репроверки связей типа 1:1.

9. Определить набор отношений исходя из структуры логической модели данных, т.е. на основе диаграммы «Сущность–связь» построить отношения и связи между ними.

10. Проверить отношения с помощью правил нормализации и при необходимости провести декомпозицию отношений.

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

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

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

сти локальных моделей. 15. Выработать технологию обслуживания ИС, т.е. определить по-

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

16. Проверить корректность проекта. Проект должен адекватно на требуемом уровне детальности отображать предметную об-ласть. На стадии программной реализации необходимо выполнить

следующие пункты. 1. Выбрать компьютер и инструментальные средства (конкрет-

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

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

158

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

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

4. Разработать и реализовать программное обеспечение ИС для всех приложений. При необходимости осуществить конверти-рование и загрузку данных из аналогичных систем или старых версий системы.

5. Провести тестирование и отладку ИС и скорректировать тех-нологию ее обслуживания.

6. Составить необходимые инструкции по работе системы и обу-чить пользователей.

7. Подготовить полную системную документацию в соответствии с ЕСПД (стандарты по «Единой системы программной доку-ментации»).

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

159

Проектирование БД представляет собой трудоемкий, длитель-ный и во многих случаях не формализуемый процесс.

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

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

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

Кроме того, при проектировании БД необходимо обеспечить: • защиту данных от разрушений при сбоях оборудования, от не-

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

• выполнение ограничений на конфигурацию вычислительной системы, в первую очередь на ресурсы памяти;

• простоту и удобство эксплуатации информационной систе-мы;

• гибкость, т.е. возможность развития и последующей адаптации системы к изменениям в предметной области и к новым по-требностям пользователей [5]. Таким образом, только комплексный подход с использованием

фундаментальных знаний в области проектирования БД способен гарантировать разработчикам верные и надежные решения при создании и эксплуатации ИС на основе БД.

160

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Попов Д.И., Калашникова Т.Г. Руководство к циклу лаборатор-ных работ «Разработка приложений баз данных на основе MS-Access». Таганрог: Изд-во ТРТУ, 2001. 38 с. № 3116.

2. Попов Д.И. Руководство к лабораторной работе «Публикация баз данных в Интернет на основе ASP-технологии». Таганрог: Изд-во ТРТУ, 2000. 28 с. № 3012.

3. Атре Ш. Структурный подход к организации баз данных. М.: Финансы и статистика, 1983. 320 с.

4. Бекаревич Ю.Б., Пушкина Н.В. Microsoft Access 2000. СПб.: BHV-Санкт-Петербург, 1999.

5. Бойко В.В., Савинков В.М. Проектирование баз данных инфор-мационных систем. 2-е изд. М.: Финансы и статистика, 1989. 351 с.

6. Вейскас Д. Эффективная работа с MS-Access 97. СПб.: Питер-ком, 1999.

7. Горев А., Ахаян Р., Махашарипов С. Эффективная работа с СУБД. СПб.: Питер, 1997. 704 с.

8. Грабер М. Введение в SQL. М.: Лори, 1997. 548 с. 9. Дейт К.Дж. Введение в системы баз данных. 6-е изд. М.: Изд-

во «Вильямс», 1999. 848 с. 10. Дженникс P. Access 95 в подлиннике: Пер. с англ. Том 1,2.

СПб.: BHV, 1997. 11. Калверт Ч. Delphi 4. Энциклопедия пользователя (+CD-ROM).

Киев: Изд-во «Диасофт-Киев», 2000. 800 с. 12. Кандзюба С.П. Delphi 6. Базы данных и приложения. Лекции и

упражнения. М.: Изд-во «Diasoft», 2002. 576 с. 13. Карелин В.П. Создание и программирование баз данных сред-

ствами СУБД FoxPro: Учебное пособие. Таганрог: ТРТУ, 1997. 83 с.

14. Кириллов В.В. Основы проектирования реляционных баз дан-ных. Санкт-Петербургский Государственный институт точной

161

механики и оптики (технический университет). Кафедра вы-числительной техники. //Интернет публикация: http://www.citforum.ru/database/dbguide/index.shtml.

15. Козлов. Программирование для Интернет в Delphi 5. М.: Изд-во «Бином», 2001. 368 с.

16. Коннолли Т., Бегг К., Страчан А. Базы данных. Проектирова-ние, реализация и сопровождение. Теория и практика. М.: Изд-во «Вильямс». 2000. 1120 с.

17. Костюк А.И. Базы данных и знаний: Курс лекций. Таганрог: Изд-во ТРТУ, 1999. 175 с.

18. Кузнецов С.Д. Основы современных баз данных. Информаци-онно-аналитические материалы Центра информационных тех-нологий. //Интернет публикация: http://www.citforum.ru/ database/osbd/contents.shtml.

19. Кэмпбелл Мэри. Access. Ответы: Пер. с англ. М.: Восточная книжная компания, 1996.

20. Ланг К., Чоу Дж. Публикация баз данных в Интернете: Пер. с англ. СПб.: Символ-Плюс, 1998. 480 с.

21. Мартин Дж. Организация баз данных в вычислительных сис-темах: Пер. с англ. 2-е изд. М.: Мир, 1980. 662 с.

22. Мейер М. Теория реляционных баз данных. М.: Мир, 1987. 608 с. 23. Озкарахан Э. Машины баз данных и управление базами дан-

ных: Пер. с англ. М.: Мир, 1989. 696 с. 24. Попов Д.И., Попова Е.Д. Информационные технологии. Базы

данных. М.: Изд-во МГУП. 2009. 117 с. 25. Проектирование реляционных баз данных. Руководство проек-

тировщика. Ростов/Д, 1989. 26. Пушников А.Ю. Введение в системы управления базами дан-

ных. Часть 1. Реляционная модель данных: Учебное пособие. Уфа: Изд-во Башкирского ун-та 1999. 108 с.

27. Ресурсы Интернет: http://www.activeserverpages.ru/, www. vbtraning. com, http://codeguru.earthweb.com/, http://www. citforum.ru

28. Секреты создания интрасетей. СПб.: Питер, 1998. 592 с. 29. Тиори Т., Фрай Дж. Проектирование структур баз данных. М.:

Мир, 1985. 507 с.

162

30. Ульман Дж. Основы систем баз данных. М.: Финансы и стати-стика, 1983.

31. Фадеенков Е. Основы использования WWW-технологий для доступа к существующим базам данных (http://citforum.ru/ database/ cnit/1.shtml).

32. Хаббард Дж. Автоматизированное проектирование баз дан-ных. М.: Мир, 1984.

33. Харитонова И., Михеев М. Microsoft Access 2000 в подлинни-ке. СПб.: БХВ-Санкт-Петербург, 1999.

34. Хилайер С., Мизик Д. Программирование Active Server Pages: Пер. с англ. 3-е изд., доп. М.: Издательско-Торговый дом «Рус-ская редакция», 2000. 320 с.

35. Хомоненко А.Д., Цыганкова В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. СПб.: «Корона-принт», 2000. 416 с.

36. Четвериков В.Н., Ревунков Г.И., Самохвалов Э.Н. Базы и банки данных. М.: Высш. шк., 1987. 248 с.

37. Chen P.P. The Entity-Relationship model — Toward a unified view of data// ACM Trans. Database Systems, 1(1), 9–36, 1976.

163

Предметный указатель

ALL, 103, 104, 113, 130, 131, 145, 146 ALTER TABLE, 142 AND, 84, 106–109, 120–128 ANY, 129–131 ASC, 103, 105 AVG, 112, 121–126 BETWEEN, 108, 109, 111, 121–124 CHAR, 100, 109 CODASYL, 41 COUNT, 112, 113 CREATE TABLE, 137–140 CREATE VIEW, 143 CROSS, 116 DEC, 100 DELETE, 133, 135, 136, 143, 145 DESC, 105 DISTINCT, 104, 106, 112, 113, 128, 144 DROP TABLE, 142 ER-диаграмма, 24, 26 EXISTS, 126–129 FLOAT, 100 FROM, 102–104, 108–136 FULL, 116 GRANT, 145–146 GROUP BY, 103–105, 113, 114, 122, 125 HAVING, 105, 106, 114, 125, 126, 144 IN, 108–111, 120–122, 130 INNER, 116–119 INSERT, 133–137, 145 JOIN, 80, 116 LEFT, 116 LIKE, 108–111 MAX, 25, 26, 112, 114 MIN, 25, 26, 112 NATURAL, 80, 116

NOT, 106, 110, 111, 126, 138 NULL, 82, 83, 110, 116, 134, 137, 141, 142 NUMERIC, 100 OR, 106, 108, 126 ORDER BY, 105–107, 131 REAL, 100 REVOKE, 146 RIGHT, 116, 117 SELECT, 102–105, 108–137, 145 SOME, 129 SQL, 9, 82, 98–102, 108–120, 124, 125, 131, 133, 141–145 SUM, 112 TEXT, 100 UNION, 116, 131–132 UPDATE, 133, 136, 137, 141–146 WHERE, 103–131, 135–137 агрегат данных, 10

агрегатная функция, 104, 111–114, 122

алиас, 118, 124, 125, 128

аномалия, 46, 51–58 добавления, 46 обновления, 51, 54, 58 удаления, 46

ассоциация, 11 простая, 12 сложная, 12, 13 условная, 12, 13, 14

атрибут, 11, 16–30, 43–58, 70–88 многозначный, 20 однозначный, 20 производный, 20 простой, 19 составной, 19

164

база данных (БД), 8–18, 39–50, 102, 144, 145, 159

выборка, 9, 72, 76, 114, 116

данные, 8–10, 39–45, 102–106

декартово произведение, 72, 77, 146

деление, 73, 85, 106

детерминант, 48, 52–57

домен, 18, 19, 43, 49, 50, 70, 88, 89

жизненный цикл, 156

зависимость 9, 12, 13, 48, 52, 53, 56, 58 многозначная, 48

запись, 10, 39, 42, 44, 46, 50, 134, 138, 141 логическая, 10

запрос, 9, 79, 84, 88, 98–143 вложенный, 123 рекурсивный, 118

избыточность, 10, 45, 46, 47 неявная, 46 явная, 46

информационные системы, 5, 101, 156, 159

кардинальность отношения, 70

ключ, 21 внешний, 22, 30, 31, 56, 139, 140 избыточный, 22 первичный, 21, 23, 29–31, 45, 52, 56, 138 полностью составной, 22 полусоставной, 22 потенциальный, 21, 56 простой, 21 составной, 21, 22, 52

кортеж, 43–48, 70–89

модель, 9–11 внешняя, 11 иерархическая, 39, 40 концептуальная, 11, 16 логическая, 11 реляционная, 43, 44, 68 сетевая, 41, 42 сущность-связь, 16 физическая, 11

независимость данных, 8, 11 нормализация отношений, 39, 45 нормальная форма Бойса-Кодда, 56 нормальные формы, 49 объединение, 72, 79 отношение, 30, 43, 44, 46–58, 70, 73, 77–87 отображение, 14, 15, 22 многие ко многим, 15 один к одному, 14

165

Учебное издание

Информационные технологии в издательском деле и полиграфии: основы проектирования баз данных

Учебное пособие

Допущено УМО по образованию в области полиграфии и книжного дела

для студентов высших учебных заведений, обучающихся по направлению подготовки 29.03.03 «Технология полиграфического

и упаковочного производства»

Попов Дмитрий Иванович Попова Елена Дмитриевна

Некрасов Алексей Валентинович (Южный федеральный университет)

Редактор Е.Б. Казакова

Компьютерная верстка И.В. Бурлаковой

Подписано в печать 15.07.15. Формат 60×84/16. Бумага офсетная. Печать на ризографе. Усл. печ. л. 9,65.

Тираж 100 экз. (1-й завод 50 экз.). Заказ № 126

Московский государственный университет печати имени Ивана Федорова. 127550, Москва, ул. Прянишникова, д. 2А.

Отпечатано в Издательстве МГУП имени Ивана Федорова.

И Попов ЕД Попова АВ...

Documents