Министерство образования Российской Федерации Омский государственный институт сервиса

Министерство образования Российской Федерации
Омский государственный институт сервиса
Кафедра высшей математики и информатики
О. Н. Лучко, Е. В. Морарь, И. В. Червенчук
БАЗЫ ДАННЫХ
Учебное пособие
Допущено Министерством образования Российской Федерации
в качестве учебного пособия для студентов высших учебных
заведений, обучающихся по специальности
"Прикладная информатика в сфере сервиса"
Омск 2003
Базы данных: Учебное пособие / О. Н. Лучко, Е. В. Морарь,
И. В. Червенчук. Омск: Омский государственный институт сервиса,
2003. 168 с.
ISBN
Целью учебного пособия является систематическое изложение
теоретических основ построения баз данных. Рассматриваются
основные понятия баз данных. Дается характеристика моделей
данных, подробно описывается реляционная модель. Излагаются
современные подходы к концептуальному проектированию баз
данных. Раскрываются принципы организации баз данных в сетях, а
также современные направления развития баз данных. По каждой
главе приводятся контрольные вопросы и задания.
Учебное пособие составлено в соответствии с Государственным
образовательным
стандартом
высшего
профессионального
образования по специальности 351400 "Прикладная информатика (по
областям)"
Предназначено
для
студентов
специальности
351400
"Прикладная информатика в сфере сервиса", а также может быть
полезно студентам всех направлений и специальностей подготовки в
области информационных и коммуникационных технологий.
Библиогр.: 32 назв. Рис. 69. Табл. 16
Рецензенты: д-р техн. наук, профессор В.И. Потапов (Омский
государственный технический университет)
канд. физ.-мат.наук, доцент С.Е. Макаров (Омский
государственный университет)
Ответственный за выпуск зав. кафедрой ВМ и И
О.Н. Лучко
ISBN
Рекомендовано заседанием кафедры
высшей математики и информатики
Протокол № 8 от 18.03.2003 г.
Утверждено научно-методическим
советом специальности 351400
Протокол № 4 от 21.03. 2003 г.
 Омский государственный институт сервиса, 2003
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ ................................................................................................. 7
1. ОСНОВЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ ....................................... 12
1.1. Архитектура системы баз данных ................................................ 12
1.2. Жизненный цикл базы данных ...................................................... 17
2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ ........................................ 21
2.1. Классификация моделей данных................................................... 21
2.2. Разновидности инфологических моделей данных ...................... 25
3. ДАТАЛОГИЧЕСКИЕ МОДЕЛИ ДАННЫХ ..................................... 34
3.1. Иерархические модели ................................................................... 34
3.2. Сетевые модели............................................................................... 37
3.3. Реляционные модели ...................................................................... 39
3.3.1. Основные понятия реляционной модели ................................ 40
3.3.2. Реляционная алгебра ................................................................. 45
3.3.3. Язык запросов по образцу QBE ............................................... 60
3.3.4. Структурированный язык запросов SQL ............................... 72
3.4. Проектирование реляционных баз данных .................................. 81
4. СЕМАНТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ....................................... 91
4.1. Объектно-ориентированное проектирование .............................. 91
4.1.1. Представление объектов ......................................................... 91
4.1.2. Описания классов ...................................................................... 93
4.1.3. Атрибуты в ODL ...................................................................... 93
4.1.4. Связи в ODL ............................................................................... 95
4.1.5. Обратные связи ........................................................................ 96
4.1.6. Множественность связей ....................................................... 98
4.1.7. Типы в ODL .............................................................................. 100
4.1.8. Проектирование с использованием ODL .............................. 103
4.1.9. Подклассы ................................................................................ 104
4.1.10. Множественное наследование в ODL ................................ 105
4.1.11. Моделирование ограничений ................................................ 115
4.1.12. Переход от объектно-ориентированной модели ....................
к реляционной..................................................................................... 117
4.2. Диаграммы "сущность-связь" ...................................................... 118
4.2.1. Компоненты диаграмм "сущность-связь" ......................... 118
4.2.2. Множественность E/R-связей .............................................. 112
4.2.3. Роли в связях ............................................................................ 115
4.2.4. Атрибуты связей .................................................................... 124
4.2.5. Конвертирование многосторонних связей в бинарные ..... 118
4.2.6. Проектирование E/R моделей ............................................... 126
5. БАЗЫ ДАННЫХ В СЕТЯХ ............................................................... 132
5.1. Архитектура "клиент-сервер" ...................................................... 140
5.2. Распределенные базы данных ..................................................... 137
5.3. Базы данных в Интернет .............................................................. 145
6. СОВРЕМЕННОЕ СОСТОЯНИЕ И ПЕРСПЕКТИВЫ РАЗВИТИЯ
БАЗ ДАННЫХ ........................................................................................ 158
ЗАКЛЮЧЕНИЕ ...................................................................................... 167
БИБЛИОГРАФИЧЕСКИЙ СПИСОК................................................... 158
ПРИЛОЖЕНИЕ 1. Информационные ресурсы internet...................... 170
ПРИЛОЖЕНИЕ 2. Словарь терминов.................................................. 171
ПРИЛОЖЕНИЕ 3.Список сокращений................................................ 164
ПРИЛОЖЕНИЕ 4. Темы рефератов ..................................................... 177
ВВЕДЕНИЕ
Современный этап развития общества характеризуется его
глобальной информатизацией и повсеместным использованием средств
информационных и коммуникационных технологий. Широкое
использование профессионально-ориентированных информационных
систем (ИС) становится важнейшим аспектом деятельности
специалистов любого профиля. Данная тенденция как нельзя более
характерна для сферы сервиса. Основная задача сервиса –
удовлетворение потребностей населения. Данная отрасль, основной
функцией которой является оказание широкого спектра услуг, является
одной из наиболее динамично развивающихся отраслей, гибко
реагирующей на глобальные изменения в жизни общества, к
важнейшим из которых относится информатизация всех сфер общества.
Традиционные виды деятельности в сфере сервиса, например, торговля
или услуги по продаже билетов, в условиях информатизации
приобретают новые формы: открываются интернет-магазины, широко
используются информационные системы заказа билетов и записи на
услуги. В современных условиях все большая доля специалистов,
занятых в сервисном обслуживании, приходится на сферу
информационного сервиса.
В настоящее время, а тем более в будущем, в условиях широкой
информатизации общества все большее распространение будут
получать справочные системы, системы информационной поддержки
деятельности учреждений, системы поддержки принятия решений,
системы автоматизированного учета и контроля, системы
автоматизированного проектирования и множество других систем на
базе средств информационных и коммуникационных технологий.
Основу функционирования информационных систем составляют
базы данных. В широком понимании база данных представляет
совокупность сведений о реальных процессах, событиях или явлениях,
относящихся к определенной предметной области и организованной
таким образом, чтобы обеспечить удобное представление этой
совокупности, как в целом, так и в любой ее части.
Истоки технологий баз данных относятся к началу 60-х годов. К
этому времени уже был накоплен некоторый опыт решения задач
обработки экономической информации средствами технологий
файловых систем, основанных на использовании магнитных лент с
последовательным доступом к данным. Появление устройств памяти
прямого доступа определило начало становления новых технологий,
связанных с созданием, поддержкой и использованием баз данных.
В период 60-х–70-х гг. формируются основы методологии
построения баз данных. Существенный вклад в технологии баз данных
внесла
CODASYL
(ассоциация
представителей
крупнейших
поставщиков и пользователей средств вычислительной техники), в
отчетах которой был впервые проведен систематический анализ
разработанного к тому времени программного инструментария и
фактически был предложена обобщенная функциональная модель
СУБД, впервые сформулированы концепции многоуровневой
архитектуры, функционирования систем управления базами данных
общего назначения, концепция схемы базы данных и языка определения
данных, основополагающие понятия сетевой модели данных.
Дальнейшее формирование архитектурной концепции баз данных было
продолжено Рабочей группой ANSI/X3/SPARC (была предложена
трехуровневая модель систем баз данных, в значительной степени
определившая дальнейшее развитие технологий баз данных).
Одновременно с подходом CODASYL формировался иной подход
на основе иерархической структуризации данных, оказавший
значительное влияние на разработки иерархических СУБД.
Значительный (в свое время по существу революционный) вклад в
развитие теории баз данных был сделан американским математиком
Э.Ф. Коддом, разработавшим реляционный подход к базам данных. В
настоящее время реляционная модель данных не только не утратила
своей актуальности, но и получила дальнейшее развитие благодаря
объектным технологиям.
Современные технологии баз данных характеризуются объектным
подходом, дальнейшим развитием архитектурных принципов "клиентсервер" и промежуточного слоя, интеграцией неоднородных
информационных ресурсов, расширением сферы применения благодаря
использованию CASE-средств и др.
Значимость и масштабы проводимых в настоящее время разработок
в области баз данных определяются инвестированием огромных
финансовых ресурсов в эту сферу. Важнейшее место при этом
отводится
совершенствованию
системы
подготовки
квалифицированных кадров, одним из важнейших элементов которой
является изучение теории систем баз данных.
Эффективность научной и образовательной работы в этой области
во многом определяется качеством и доступностью информационных
источников. Из опубликованных фундаментальных изданий можно
прежде всего отметить русские переводы знаменитого бестселлера К.
Дейта "Введение в системы баз данных", монографию А. Саймона
"Стратегические технологии баз данных", "Введение в системы баз
данных" Д. Ульмана и Д. Вида и др. Следует также отметить большую
актуальность для специалистов, преподавателей и студентов недавно
появившегося научно-справочного издания "Энциклопедия технологий
баз данных" М.Р. Когаловского. Кроме фундаментальной специальной
литературы имеется очень большое количество изданий по различным
версиям программных продуктов, предназначенных для работы с
базами данных. Оперативным источником информации для широкого
круга специалистов в рассматриваемой области информатики являются
публикации в ведущих научно-технических журналах, материалы
крупных международных конференций, информационные ресурсы
Интернет.
Знание основных идей и методов в области проектирования
профессионально-ориентированных баз данных, владение навыками
разработки и внедрения подобных систем становится важнейшим
компонентом
системы
подготовки
специалистов,
объектами
профессиональной деятельности которых являются информационные
процессы, определяемые спецификой предметной области. К
специалистам такого направления несомненно относятся информатики
(с квалификацией в области), подготовка которых в высших учебных
заведениях
осуществляется
на
основе
Государственного
образовательного стандарта (ГОС) высшего профессионального
образования специальности 351400 "Прикладная информатика (по
областям)". В соответствии с данным стандартом к числу важнейших
задач профессиональной деятельности информатика – специалиста по
созданию
и
внедрению
профессионально-ориентированных
информационных систем в предметной области относится и разработка
баз данных.
Настоящее пособие составлено на основе указанного ГОС (данная
дисциплина представлена в блоке общепрофессинальных дисциплин) и
содержит систематическое рассмотрение идей, методов, подходов и
технологий, используемых при проектировании и практической
разработке современных баз данных. При этом необходимо отметить,
что выбор в качестве предметной области сферы сервиса, которая по
аналогии с ИС также может рассматриваться в широком смысле
(выделяют такие виды сервиса как технический, технологический,
информационный,
транспортно-коммуникационный,
социальнокультурный), не снижает общности рассматриваемых в пособии
средств и методов, а реализуется прежде всего на основе разбора
примеров, являющихся специфичными для данной предметной
области. Отметим, что в настоящее время все большее
распространение получают понятия IT-услуг (ITSM, IT Service
Management). Знания и умения, полученные в ходе освоения курса
"Базы данных", составляют основу специальной подготовки студентовинформатиков (говоря современным языком, основу ИТ-образования).
Отмеченная широта понятий и методов, относящихся к
информационным системам и, в частности, к базам данных, определила
задачу выявления предмета изучения дисциплины "Базы данных",
определения характера и объема знаний по каждой из тем пособия, а
также определения роли и места данного курса в общей системе
дисциплин подготовки по специальности "Прикладная информатика в
сфере сервиса". Предполагается, что студенты уже обладают
достаточным уровнем фундаментальной подготовки в области
информатики, информационных и коммуникационных технологий,
полученным в ходе изучения других дисциплин ("Информатика и
программирование", "Операционные системы, среды и оболочки" и др.).
С другой стороны необходимо принимать во внимание, что многие
вопросы, связанные с проектированием программных средств и систем
(объектно-ориентированный подход, модели данных и др.), носят
общий характер и рассматриваются под собственным углом зрения в
таких дисциплинах как "Высокоуровневые методы информатики и
программирования", "Информационные системы", "Разработка и
стандартизация программных средств и информационных технологий".
Пособие состоит из 6 глав, к каждой из которых приведены
контрольные вопросы и задания для самостоятельной работы студентов.
Более глубокой проработке учебного материала пособия призвана
способствовать работа студентов с литературой, представленной в
библиографическом списке, а также с представленными в приложении
информационными ресурсами Интернет. Расширению научного
кругозора студентов будет способствовать и обсуждение на
семинарских занятиях рефератов, тематика которых отражает
современные направления развития технологий баз данных
(приложение 4).
Авторы считают нужным отметить, что в данном учебном пособии
представлены прежде всего теоретические основы построения баз
данных. Дальнейшее изучение современных технологий и подходов к
разработке баз данных, овладение практическими умениями и
навыками работы с современными СУБД для студентов специальности
351400 "Прикладная информатика в сфере сервиса" в Омском
государственном институте сервиса предусматривается в рамках
практических занятий, при выполнении заданий в ходе
производственной практики, в процессе выполнения курсовых
проектов.
Сфера возможного практического использования настоящего
учебного пособия не ограничивается системой подготовки
специалистов по специальности "Прикладная информатика в сфере
сервиса". Оно может использоваться как при подготовке
информатиков с квалификацией в других предметных областях
(информатиков-экономистов,
информатиков-менеджеров,
информатиков-социологов и т. д.), так и при подготовке
специалистов, профессиональная деятельность которых связана с
проектированием, разработкой и внедрением баз данных, а также
оценкой эффективности использования информационных систем на
предприятии. Более того, изучение представленного в пособии
материала будет полезно всем, кто планирует использовать базы
данных и на уровне пользователя, поскольку эффективность
эксплуатации любой системы повышается в случае, если
пользователь понимает суть происходящих при этом процессов и
владеет знаниями и умениями, необходимыми для ее модификации и
совершенствования.
1. ОСНОВЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ
1.1. Архитектура системы баз данных
Под базой данных (БД) понимается "организованная в
соответствии с определенными правилами и поддерживаемая в
памяти компьютера совокупность данных, характеризующая
актуальное состояние некоторой предметной области и используемая
для удовлетворения информационных потребностей пользователей"
[15].
Для описания базы данных инициативной группой ANSI/SPARC
(Американский национальный институт стандартов / Комитет по
требованиям и планированию стандартов) в 70-x гг. была предложена
трехуровневая архитектура. Архитектура ANSI/SPARC включает
следующие уровни: внутренний, концептуальный и внешний (рис. 1).
Внешний
уровень
Внешний
уровень
Ц
е
Концептуальный
уровень
х
а
...
Внутренний уровень
Рис.1. Уровни архитектуры
Каждый уровень описывается соответствующей схемой (средствами
языка описания данных соответствующего уровня), определяющей
свойства базы данных в терминах типов содержащихся в БД данных.
Уровни связаны механизмами междууровневого отображения
данных.
Внешний уровень определяет точку зрения пользователей на базу
данных. Отдельного пользователя интересует не вся БД, а только
некоторая часть ее. Пользовательское представление базы данных
(внешнее представление) будет абстрактным по сравнению с
физическим способом хранения данных. Оно отражает представление
содержимого базы данных отдельным пользователем. Например,
пользователь из отдела кадров может рассматривать базу данных как
набор сведений об отделах, о служащих и ничего не знать о клиентах
компании или о выпускаемой продукции. Каждый пользователь
создает
свое
внешнее
представление.
Пользовательские
представления отображаются в данные концептуального уровня. Это
отображение демонстрирует, как различные приложения будут
использовать данные. Внешний уровень определяется средствами
внешней схемы. Приложения внешнего уровня создаются средствами
либо одного из распространенных языков программирования
(например, С++), либо специального языка запросов (SQL).
Концептуальный уровень отражает обобщенную модель
предметной области, для которой создавалась база данных. На этом
уровне база данных представлена в наиболее общем виде.
Концептуальное представление – это представление данных такими,
какие "они есть на самом деле", а не то, какими их представляют
пользователи, абстрактное представление всей базы данных. Может
быть несколько внешних представлений, каждое из которых состоит
из более или менее абстрактного представления определенной части
базы данных, и может быть только одно концептуальное
представление, состоящее из абстрактного представления базы
данных в целом. Концептуальное представление определяется с
помощью концептуальной схемы.
Внутренний уровень связан со способами хранения и извлечения
данных. Внутреннее представление отражает низкоуровневую
структуру базы данных. Понятие структуры физической базы данных
включает: формат хранимой записи, структура путей доступа и
размещение записей на физических устройствах и т.д. Внутреннее
представление описывается средствами внутренней схемы,
определяющей не только типы хранимых записей, но и индексы,
представления памяти, упорядочение полей и т.д. Отображение
концептуального уровня во внутренний изолирует концептуальную
модель от влияния каких-либо возможных изменений в хранимых
данных на физических носителях. При изменении структуры
хранимой базы данных изменяется отображение "концептуальный-
внутренний" таким образом, чтобы результаты изменений не
коснулись концептуального уровня.
Трехуровневая архитектура позволяет обеспечить физическую
независимость хранимых данных. Разработчик базы данных может
при необходимости изменить физическую модель данных, переписав
хранимые данные на другие носители информации и реорганизовав
их физическую структуру. Также можно подключить к системе любое
число новых пользователей (новых приложений), дополнив, если
надо, концептуальную модель. Указанные изменения не будут
замечены существующими пользователями системы (окажутся
"прозрачными" для них), так же как не будут замечены и новые
пользователи. Следовательно, независимость данных обеспечивает
возможность развития системы баз данных без разрушения
существующих приложений.
Система баз данных представляет собой совокупность
следующих взаимосвязанных компонентов: данные (хранимая база
данных),
программное
обеспечение
(СУБД,
приложения,
операционная система и т.д.), аппаратное обеспечение (процессор,
оперативная память, магнитные диски для хранения информации и т.
д.), пользователи (рис. 2).
П
о
л
ь
з
о
в
а
т
е
л
и
АБД
.
.
.
Прикладные
программы
Аппаратное
обеспечение
СУБД
БД
Рис. 2. Компоненты системы баз данных
Рассмотрим подробнее такие компоненты системы баз данных
как пользователи и программное обеспечение.
С базами данных работают различные категории пользователей:
прикладные программисты, конечные пользователи, администраторы
базы данных.
Конечные пользователи – это основная категория пользователей.
Конечные пользователи работают с базами данных через рабочую
станцию или терминал, используя при этом либо приложения, либо
интерфейс СУБД. В зависимости от особенностей создаваемой базы
данных круг конечных пользователей может существенно
различаться. Конечным пользователем может быть, например, клиент
компьютерной фирмы, просматривающий каталог продукции или
услуг, или начальник отдела, анализирующий перспективы ее
развития.
Прикладные программисты разрабатывают внешние приложения,
которые позволяют выполнять над данными все стандартные
операции: выборку, удаление и изменение существующей
информации, вставку новой информации.
Администратор базы данных (АБД) – под этим понятием
подразумевается лицо (или группа лиц, возможно, целое штатное
подразделение), на которое возложено управление средствами базы
данных организации. В его функции входит:
 координировать все действия по проектированию, реализации
и ведению базы данных; учитывать перспективные и текущие
требования пользователей; следить, чтобы база данных удовлетворяла
актуальным информационным потребностям;
 анализировать существующие программные средства и
возможность их использования в базе данных, разрабатывать
программно-технические мероприятия по развитию базы данных;
 разрабатывать и реализовывать меры по обеспечению защиты
данных от некомпетентного их использования, от сбоев технических
средств, по обеспечению секретности определенной части данных и
разграничению доступа к данным;
 выполнять
работы
по
ведению
словаря
данных;
контролировать избыточность и противоречивость данных, их
достоверность;
 следить за тем, чтобы БД отвечала заданным требованиям по
производительности, т. е. чтобы обработка запросов выполнялась за
приемлемое время; выполнять при необходимости изменения методов
хранения данных, путей доступа к ним, связей между данными,
форматов данных; определять степень влияния изменений в данных
на всю БД; координировать вопросы технического обеспечения
системы аппаратными средствами исходя из требований,
предъявляемых БД к оборудованию;
 координировать
работы
системных
программистов,
разрабатывающих дополнительное программное обеспечение для
улучшения эксплуатационных характеристик системы;
 координировать
работы
прикладных
программистов,
разрабатывающих новые приложения и выполнять проверку и
включение прикладных программ в состав программного обеспечения
системы;
 работать с конечными пользователями, в том числе и по
вопросам обучения и консультирования и т.п.
Программное обеспечение включает, прежде всего, систему
управления базами данных (СУБД) – комплекс программных средств,
"предназначенный для создания и хранения базы данных на основе
некоторой модели данных, обеспечения логической и физической
целостности содержащихся в ней данных, надежного и эффективного
использования
ресурсов
(данных,
пространства
памяти,
вычислительных
ресурсов),
предоставления
к
ней
санкционированного доступа для приложений и конечных
пользователей, а также для поддержки функций администратора баз
данных" [15].
Рассмотрим функции СУБД подробнее:
 СУБД должна предоставлять пользователям и программам два
типа языков: язык описания данных (для описания логической
структуры данных) и язык манипулирования данными (для
выполнения запросов пользователя на выборку, изменение, удаление
данных).
 СУБД должна контролировать пользовательские запросы и
следить за выполнением правил безопасности и целостности,
определенные АБД.
 В СУБД должен быть предусмотрен механизм восстановления
данных.
 СУБД должна обеспечить функцию словаря данных. Словарь
данных содержит "данные о данных", так называемые метаданные.
Метаданные словаря предоставляются в виде, удобном для
восприятия человеком и характеризуют состав и структуру
пользовательских данных в базе данных. Словарь данных
предназначен для документирования разработки системы базы
данных, справочного обслуживания ее пользователей, а также для
персонала АБД.
СУБД является важнейшим, но не единственным компонентом
программного обеспечения. Другие программные компоненты:
средства разработки приложений, средства проектирования, утилиты,
генераторы отчетов и т. д.
База данных не существует без данных. Данные должны быть
определенным образом организованы. Теоретическим основам
организации данных посвящены главы 2-4.
С учетом вышеизложенного, детализированная архитектура баз
данных представлена на рис. 3.
Внешний
Конечные
пользователи
уровень
. . .
Отображение
АБД
П
р
о
е
к
т
и
р
о
в
а
н
и
е
Концептуальный
уровень
Отображение
Внутренний
уровень
Рис. 3. Детализированная архитектура баз данных
1.2. Жизненный цикл базы данных
Базы данных начинаются с людей и их потребностей. Разработка
базы данных представляет итеративный, пошаговый процесс. Каждый
шаг ведет к созданию рабочей базы данных; каждая итерация идет от
моделирования – к созданию структуры, а затем обратно в том порядке,
в каком это имеет смысл делать. Проектирование базы данных
начинается
с
определения
информационных
потребностей
пользователей, создания модели данных и заканчивается утилизацией
базы данных. Процедура создание концептуальной схемы базы данных,
определение данных, включаемых в базу данных, создание программ
обновления и обработки данных называется жизненным циклом базы
данных (ЖЦ). Жизненный цикл включает в себя процессы
проектирования, реализации и поддержания системы базы данных и
состоит из следующих этапов [29]:
 предварительное планирование;
 проверка осуществимости;
 определение требований;
 концептуальное проектирование;
 реализация;
 оценка работы и поддержка базы данных;
 снятие с эксплуатации.
Опишем главные задачи каждого этапа.
Предварительное планирование выполняется в процессе
разработки стратегического плана базы данных. Стратегический план
предполагает количество и вид баз данных, которые требуется создать
для организации. Когда начинается разработка проекта реализации,
общая информационная модель, созданная в процессе планирования
базы данных пересматривается и уточняется. Предварительное
планирование предполагает определение функций и количества
используемых прикладных программ, приложений, находящихся в
процессе создания. Эта информация помогает установить связи между
текущими приложениями и определить, каким образом используется
информация приложений, а также сформулировать будущие
требования к системе.
Проверка
осуществимости
определяет
технологическую,
операционную и экономическую осуществимость плана создания базы
данных. Технологическая осуществимость предполагает определение
доступности
необходимого
оборудования
и
программного
обеспечения, необходимых для работы базы данных: имеются ли в
наличии данные ресурсы, или необходимо их приобретение.
Операционная осуществимость связана с определением квалификации
и опыта специалистов, работающих с БД. Экономическая
целесообразность предполагает получение определенной выгоды от
внедрения базы данных.
Этап определения требований включает выбор целей базы данных,
выяснение информационных потребностей различных подразделений и
требований к оборудованию и программному обеспечению.
Информационные потребности могут выясняться с помощью анкет,
опросов менеджеров и работников компании, а также на основе
документов компании. Общая информационная модель, созданная на
этапе планирования базы данных, разделяется на модели для каждого
отдела компании, являющиеся основой для создания проекта
следующего этапа.
Этап концептуального проектирования
включает создание
концептуальной схемы базы данных. На этом же этапе создаются
подробные модели пользовательских представлений, которые затем
преобразуются в концептуальную модель, фиксирующую все элементы
данных, которые будет содержать база данных.
В процессе реализации базы данных выбирается и приобретается
СУБД. Затем концептуальная модель преобразуется в проект
реализации базы данных, создается словарь данных, база данных
заполняется данными, создаются прикладные программы и обучаются
пользователи. Построение словаря данных как центрального
хранилища определений структуры данных – ключевой шаг в
реализации базы данных. Словарь данных предназначен для
системного персонала администрирования данных, прикладных
программистов и конечных пользователей.
Оценка базы данных включает опросы пользователей с целью
выяснения неучтенных информационных потребностей. При
необходимости вносятся изменения, обеспечивается поддержка
системы путем добавления новых программ.
Последний этап – снятие с эксплуатации базы данных. Существует
правила, что сведения из базы данных не должны уничтожаться, а
передаются в Государственный архив. Срок хранения в архиве
определяется ценностью информации. Так, данные о заработной плате
хранятся 75 лет. В архиве информация хранится на магнитных лентах,
поэтому вся база данных переносится на твердый носитель.
Контрольные вопросы и задания
1. Какие уровни включает архитектура баз данных?
2. Дать определение внутреннего уровня.
3. Указать различие между внешним и концептуальным
представлениями базы данных.
4. Какие виды отображений определяются в архитектуре баз
данных? Охарактеризовать их.
5. Какие основные компоненты включает система баз данных?
6. Охарактеризовать категории пользователей БД.
7. Перечислить функции администратора баз данных.
8. Нарисовать схему архитектуры баз данных.
9. Перечислить и кратко описать этапы жизненного цикла базы
данных.
10. Указать назначение словаря данных.
2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ДАННЫХ
2.1. Классификация моделей данных
Основная задача построения моделей данных – адекватное
описание предметной области для последующего перевода на язык
информационных систем. При этом одними из основополагающих в
концепции баз данных являются обобщенные категории "данные" и
"модель данных".
Категория "данные" тесно связана с понятием "информация". Под
информацией понимают любые сведения об объектах и явлениях
окружающей среды, их параметрах, свойствах и состоянии, которые
воспринимают информационные системы (в том числе и живые
организмы), в процессе жизнедеятельности и работы. Под данными
можно понимать информацию, фиксированную в определенной
форме, пригодной для последующей обработки, хранения и передачи.
Понятие данные в концепции баз данных – это набор конкретных
значений, параметров, характеризующих объект, условие, ситуацию
или любые другие факторы. В энциклопедии технологий баз данных
данные определяются как "представление фактов о предметной
области системы баз данных или информационной системы в форме,
допускающей их хранение и обработку на компьютерах, передачу по
каналам связи, а также восприятие человеком" [15]. Примеры данных:
ткань платьевая "Вечер", $50 и т. д. Для использования данных
пользователь должен задать им определенную структуру с учетом
смыслового содержания. Поэтому центральным понятием в области
баз данных является понятие модели данных. Под моделью
понимается представление реальных сущностей, при котором
отражаются только некоторые их свойства и которое может
материализоваться в различных формах. В теории баз данных
используются разные модели: модели предметной области, модели
данных, архитектурные модели, модели транзакций. Для их описания
используются математический аппарат, графическая нотация,
специально разработанные дескриптивные языки и т.д.
Не существует однозначного определения термина "модель
данных", у разных авторов эта абстракция определяется с некоторыми
различиями. В нашем пособии будем придерживаться определения,
предложенного в [14].
Модель данных – это некоторая абстракция, которая, будучи
приложима к конкретным данным, позволяет пользователям и
разработчикам трактовать их как сведения, содержащие не только
данные, но и взаимосвязь между ними.
Модели
данных
Инфологические
модели
Информационная
алгебра
Модель
Смитов
Диаграммы
Бахмана
Модель
"сущностьсвязь"
Модель
"объектроль"
Даталогические модели
Документальные
модели
Ориентированные
на формат
документа
Фактографические
модели
На файловых
структурах
На
страничносегментной
организации
Теоретикографовые
Дескрипторные
модели
Тезауруcные
модели
Физические
модели
Иерархическая
Объектноориенированные
Теоретикомножественные
Сетевая
Реляционная
Многомерная
модель
Бинарных
отношений
Рис. 4. Классификация моделей
На рис. 4 представлена классификация моделей данных, в основу
которой положен подход, представленный в [14].
В соответствии с рассмотренной ранее трехуровневой
архитектурой ANSI/SPARC можно определить понятие модели
данных по отношению к каждому уровню.
Физическая организация данных оказывает основное влияние на
эксплуатационные характеристики базы данных. Разработчики
пытаются создать наиболее производительные физические модели
данных, предлагая пользователям тот или иной инструментарий для
поднастройки модели под конкретную СУБД. Физическая модель
данных оперирует категориями, касающимися организации внешней
памяти и структур хранения, используемых в данной операционной
среде. В настоящий момент в качестве физических моделей
используются различные методы размещения данных, основанные на
файловых структурах: это организация файлов прямого и
последовательного доступа, индексных файлов и инвертированных
файлов, файлов, использующих различные методы хэширования,
взаимосвязанных файлов. Кроме того, современные СУБД широко
используют страничную организацию данных. Физические модели
данных, основанные на страничной организации, являются наиболее
перспективными.
Модели данных, используемые на концептуальном уровне,
характеризуются большим разнообразием. По отношению к ним
внешние модели называются подсхемами и используют те же
абстрактные категории, что и концептуальные модели данных.
При проектировании базы данных выделяют еще один уровень,
предшествующий рассмотренным трем уровням. Модель этого
уровня должна выражать информацию о предметной области в виде,
независимом от используемой СУБД. Эти модели называются
инфологическими, или семантическими. Инфологическая модель
отображает реальный мир в некоторые, понятные человеку
концепции, полностью независимые от параметров среды хранения
данных. Термин "инфологическая модель" означает "концептуальная
модель в самом широком смысле", многие авторы вместо него
используют термины "абстрактная модель", "концептуальная в
широком смысле модель".
Инфологические модели данных используются на ранних
стадиях проектирования для описания структур данных в процессе
разработки приложений. Инфологическая модель должна быть
отображена в компьютерно-ориентированную даталогическую
модель, поддерживаемую конкретной СУБД. В даталогическом
аспекте рассматриваются вопросы представления данных в памяти
информационной системы.
Документальные модели данных применяются для представления
слабоструктурированной информации, ориентированной в основном
на свободные форматы документов, текстов на естественном языке
(монографий, публикаций в периодике, текстов законодательных
актов и т. п.).
Модели, ориентированные на формат документа, связаны,
прежде всего, с языками разметки документов. Стандартный
обобщенный язык разметки документов SGML (Standard Generalized
Markup Language) позволяет отделить аспекты содержания
документов от аспектов его представления. Описание документов в
этом языке не зависит от программно-аппаратной платформы, на
которой осуществляется их обработка. На его основе разработаны
программные системы управления документами, а также браузеры
для просмотра размеченных документов. На основе языка SGML
разработан язык гипертекстовой разметки HTML (HyperText Markup
Language), применяемый для отображения статистических данных на
Web-страницах. Этот язык определяет оформление элементов
документа и имеет некий ограниченный набор инструкций – тегов,
при помощи которых осуществляется процесс разметки. В качестве
элемента гипертекстовой базы данных, описываемой HTML,
используется текстовый файл, который может легко передаваться по
сети с использованием протокола HTTP. Эта особенность, а также то,
что HTML является открытым стандартом и огромное количество
пользователей имеет возможность применять возможности этого
языка для оформления своих документов, безусловно, повлияли на
рост популярности HTML и сделали его сегодня главным механизмом
представления информации в Интернете.
Однако HTML сегодня уже не удовлетворяет современным
требованиям. И ему на смену был предложен новый язык
гипертекстовой разметки XML (Extensible Markup Language). Язык
XML стал основой активно развивающейся новой более
перспективной и совершенной платформы для среды Web. Он
используется в качестве средства для описания грамматики других
языков и контроля за правильностью составления документов. Сам по
себе XML не содержит никаких тегов, предназначенных для
разметки, он просто определяет порядок их создания.
Тезаурусные модели основаны на принципе организации
словарей и содержат определенные языковые конструкции и
принципы их взаимодействия в заданной грамматике. Эти модели
эффективно используются в системах-переводчиках, особенно
многоязыковых переводчиках. Принцип хранения информации в этих
системах подчиняется тезаурусным моделям.
Дескрипторные модели – самые простые из документальных
моделей, они широко использовались на ранних стадиях
использования документальных баз данных. В этих моделях каждому
документу соответствовал дескриптор – описатель. Этот дескриптор
имел жесткую структуру и описывал документ в соответствии с теми
характеристиками, которые требуются для работы с документами в
разрабатываемой документальной БД. Например, для БД,
содержащей описание патентов, дескриптор содержал название
области, к которой относился патент, номер патента, дату выдачи
патента и еще ряд ключевых параметров, которые заполнялись для
каждого патента. Обработка информации в таких базах данных велась
исключительно по дескрипторам, то есть по тем параметрам, которые
характеризовали патент, а не по самому тексту патента.
Фактографические модели представлены в виде специальным
образом организованных совокупностей формализованных записей
данных. Основанные на таких моделях фактографические системы
используются не только для реализации информацинно-справочных
функций (в отличие от документальных систем), но и для решения
задач обработки данных. Под обработкой данных понимается
специальный класс решаемых на ЭВМ задач, связанных с вводом,
хранением, сортировкой, отбором и группировкой данных
однородной структуры. Центральным функциональным звеном
фактографических систем является СУБД.
2.2. Разновидности инфологических моделей данных
Информационная алгебра была разработана рабочей группой
комитета CODASYL. Целью данной работы являлось создание
структуры
машинно-независимого
языка
описания
задач,
ориентированного на системный уровень обработки данных. Основой
концептуальной
модели
является
представление,
что
информационная система имеет дело с объектами и событиями
реального мира, которые представляются в виде данных.
Информационная алгебра оперирует понятиями "сущность" и
"свойства". Сущность – нечто физически существующее в реальном
мире. Сущность имеет свойства. Для каждой сущности каждому из ее
свойств приписывается значение из множества значений свойства.
Также в информационной алгебре вводятся ряд понятий: система
координат, точка значений, пространство свойств. Вводятся также
понятия комплекса и агрегата.
При описании задач основной операцией является отображение
одного
подмножества
пространства
свойств
на
другое.
Рассматриваются два типа отображений. Одно соответствует
операциям в данном файле (можно, например, определить
отображение группы из пяти точек для каждого рабочего в одну
новую точку, которая будет содержать итог за неделю). Эта операция
называется агрегированием. Второй тип отображения соответствует
операции обработки файлов, при которой точки из некоторого числа
входных файлов обрабатываются для получения нового выходного
файла – комплексирование данных.
Создатели информационной алгебры надеялись, что развиваемый
подход приведет к появлению трансляторов, позволяющих
переводить реляционные выражения в процедурную форму.
Проектировщики
должны
специфицировать
релевантные
(существенные для задачи) наборы данных, а также связи и правила
их объединения, в соответствии с которыми данные обрабатываются,
классифицируются и объединяются в различные подмножества, в том
числе в выходные результаты.
Важно заметить, что в модели информационной алгебры
выделены основополагающие элементы: сущности, свойства,
значения свойства, которые позволяют адекватно описать некоторую
предметную область и реально существующие объекты. Выделение
этих элементов следует считать важным достижением. Здесь
выделены три основные составляющие, присущие природе данных:
носитель свойств ("сущность"), сами свойства ("свойства"), каждому
из которых приписывается значение ("значение свойства"), также
вводится понятие пространства – "пространство свойств".
Однако данная модель не отражает ряд важных моментов,
присущих природе данных, в частности не учитывается, что
 носители свойств могут находиться в определенных
отношениях друг с другом и образовывать некоторую структуру;
 сами свойства между собой также могут находиться в
некоторых отношениях.
В модели CODASYL введено понятие значения показателя, при
этом также необходимо указать некоторую характеристику
упорядочения, такую как номер наблюдения, дату измерения
показателя, время и т. п., чтобы была возможность различать ряд
значений определенного объекта по определенному показателю.
Данная характеристика, ввиду ее природой естественности, в модели
CODASYL присутствует неявно и входит в свойства. Выделение
характеристики упорядочения позволяет при необходимости
исследовать динамику изменения показателей, задать отношения:
быть позже, быть раньше, относиться к одному интервалу (к неделе,
месяцу, году), отстоять на определенный промежуток времени и др.;
ввести операции усреднения по интервалам и подсчета итоговых
сумм за период. То есть использование характеристики упорядочения
дает возможность в значительной мере автоматизировать процесс
подготовки данных для последующего анализа, в том числе
статистического. Существует целое направление так называемых
временных (temporal) баз данных, учитывающих изменения данных
во времени.
Модель Смитов. В семантическом моделировании проектируется
схема понятий прикладной области в их взаимосвязи. Предлагались и
предлагаются различные пути такого моделирования. Вот например,
какие
метапонятия
рассматривали
для
концептуального
моделирования в конце 70-х годов Дж. Смит и Д. Смит.
Исходными базовыми понятиями в трактовке этих двух
специалистов являются объекты и связи между объектами. Связи
могут быть двух видов: обобщение и агрегация (рис. 5).
Субъект
Физич.
лицо
Юридич.
лицо
Обобщение
Субъект
Адрес
Имя
Агрегация
Рис. 5. Два вида связей в модели Смитов
Обобщение интуитивно ясно, и связывает одни объекты с
другими, по смыслу более общими. Например, объект "животное"
есть обобщение для объектов "собака" и "лошадь". Агрегация
связывает разнородные объекты по признаку компонентного
вхождения в другие объекты, как например, "колеса" и "кузов"
связаны с "автомобилем" тем, что последний состоит из первых.
Независимо, оба вида связей образуют каждый свою иерархию среди
объектов модели.
Кроме этих базовых имеются и другие понятия концептуальной
модели, как-то атрибут, отношение, экземпляр, индивид. Самое
замечательное в модели Смитов – это относительность
перечисленных понятий. Одно и то же явление может быть и
объектом, и отношением, и атрибутом, и экземпляром, и индивидом,
и все определяется точкой зрения на явление. Зависимость
интерпретации от точки зрения на явление (а точнее – возможность
выбора точек зрения с разной интерпретацией) – это очень мощное
свойство, придающее концептуальной модели большую гибкость и
приспособляемость в описании проектируемой ИС. Это свойство,
например, будь оно реализовано, позволило бы в информационной
системе смотреть на "адрес" то как на объект реестра адресов, то как
на атрибут "лица", то как на отношение, связывающее владельца с
остальными жильцами – когда, где и кому как нужно. Наиболее
близко к концептуальной в этом отношении подошла (теоретическая)
реляционная модель данных, а вот объектный подход с его
фиксированной интерпретацией структуры отстоит от реляционного
на шаг назад.
В модели Смитов выделяются две иерархии – иерархия агрегаций
(отношение разнородных объектов) и иерархия обобщений (по типу
"собака, лошадь – животное"), в точках пересечения появляются
абстрактные объекты. Вводится также ряд понятий: индивиды,
категории, компоненты. Для успешной интеграции понятий
существует "принцип относительности объектов", который
утверждает, что индивиды, категории, отношения и компоненты суть
разные способы рассмотрения одних и тех же объектов. Разработана
методология
спецификаций,
основанная
на
принципах
относительности объектов и сохранения индивидов. Отказ от четкого
разграничения ролей объектов является одновременно и сильной и
слабой стороной данной модели. Слабые стороны данной модели
проявляются в тех случаях, когда можно четко разделить объекты
(носители свойств) и свойства, что характерно для систем
статистической обработки. Можно отметить, что не существует
формализма, позволяющего отличить объект от свойства, поэтому это
должно задаваться извне для построения более конкретной модели.
Модель Бахмана напоминает навигационную модель страниц и
ссылок сегодняшнего Интернета, ее иногда называют моделью
навигации данных. На диаграммах Бахмана изображают типы записей
и связи между типами записей.
Следует учитывать, что это одна из первых инфологических
моделей. Чарльз Бахман в GE (General Electric) построил прототип
системы навигации по данным. За руководство работы инициативной
группой DBTG, разработавшей стандартный язык определения
данных
и
манипулирования
данными,
Бахман
получил
Тьюринговскую премию. В своей Тьюринговской лекции он описал
эволюцию моделей плоских файлов к новому миру, где программы
могут осуществлять навигацию между записями, следуя связям
между записями. Идеологическая основа работы Бахмана (более
"научно" называемая моделью базы данных) IDS, за которую Бахман
заслуженно был удостоен в 1973 г. высшей компьютерной награды
ACM, получила название "сетевой" (network).
Модель "сущность-связь". Наиболее популярной семантической
моделью является модель "сущность-связь" (E/R – Entity/Relationship),
предложенная Питером Пин-Шен Ченом в 1976 г. На использовании
разновидностей E/R модели основано большинство современных
подходов к проектированию баз данных (в основном реляционных).
Данная модель имеет графическую природу, в ней используются
изображения в виде диаграмм с прямоугольниками и стрелками,
представляющие главные элементы данных и их связи. В данной
модели выделены объекты (объектом называется "предмет, который
может быть четко идентифицирован") и свойства объектов. Таким
образом, определяются отношения типа "объект–свойство". В связи с
наглядностью представления данных модели "сущность-связь"
получили широкое распространение в CASE-системах.
Объектная модель – логическая схема объектной БД в одной из
общепринятых систем описания (обозначений). Хотя, по выражению
К. Дж. Дейта, "не существует общепринятой, абстрактной и
формально определенной ‘объектной модели данных’" и
применительно к "объектной ‘модели’" правильнее говорить об
"удобном
ярлыке
для
целой
совокупности
некоторых
взаимосвязанных идей", конкретные CASE-системы, реализующие на
свой лад некоторые из этих идей, все же существуют.
Объектная схема – схема БД конкретной объектной СУБД, для
описания модели данных используются основные принципы
объектно-ориентированного программирования
Многомерная схема – схема данных в одной из многомерных
систем представления данных. Данные представляются посредством
гиперкуба (некоторого куба со множеством измерений).
Информационные системы масштаба предприятия, как правило,
содержат приложения, применяемые менеджерами высшего звена и
предназначенные для комплексного многомерного анализа данных,
их динамики, тенденций и т.п. Такой анализ в конечном итоге
призван способствовать принятию решений. Нередко эти системы так
и называются – системы поддержки принятия решений (DSS).
Указанные приложения обычно обладают средствами предоставления
пользователю агрегатных данных для различных выборок из
исходного набора в удобном для восприятия и анализа виде. Чаще
всего такие агрегатные функции образуют многомерный (а
следовательно, нереляционный) набор данных (нередко называемый
гиперкубом или метакубом), оси которого содержат параметры, а
ячейки – зависящие от них агрегатные данные. Пример многомерной
модели показан
на рис. 6.
Рис.6. Пример трехмерной модели
С середины 90-х годов интерес к многомерным моделям стал
приобретать массовый характер. Многомерные системы позволяют
оперативно обрабатывать информацию для проведения анализа и
принятия решения. Многомерные СУБД предназначены для
интерактивной аналитической обработки. По сравнению с
реляционной моделью многомерная организация данных обладает
более высокой наглядностью и информативностью.
К основным понятиям многомерных моделей относятся
измерение и ячейка. Измерение образуют множество однотипных
данных, образующих одну из граней гиперкуба. Ячейка – это поле,
значение которого однозначно определяется фиксированным набором
значений. Тип поля определен как цифровой.
Вдоль каждого измерения данные могут быть организованы в виде
иерархии, отражающей различные уровни их детализации. Благодаря
такой модели данных пользователи могут формулировать сложные
запросы, генерировать отчеты, получать подмножества данных.
При использовании более трех измерений представить и
изобразить такой куб в рамках 3-х мерного пространства,
ограниченного высотой, шириной и глубиной, невозможно. В данном
случае разработчики применяют специальные методы для
отображения неотображаемого, например, показ нескольких
последовательностей
(series)
на
одном
графике.
Каждая
последовательность закрашивается отдельным цветом. Группа
последовательностей представляет собой значение одного 4-го
измерения.
Технология комплексного многомерного анализа данных
получила название OLAP (On-Line Analytical Processing). Концепция
OLAP была описана в 1993 году известным исследователем баз
данных и автором реляционной модели данных Э.Ф.Коддом.
Нередко для повышения скорости выполнения запросов
пользователей данные кубов вычисляются заранее и хранятся в
многомерной базе данных.
Отметим, что многомерный анализ данных может быть
осуществлен как в клиентском приложении, так и на сервере баз
данных. Все производители ведущих серверных СУБД (IBM,
Informix, Microsoft, Oracle, Sybase) производят серверные средства
для такого анализа.
Существует мнение, причем вполне обоснованное, что
многомерные модели используются не для описания данных, а для их
представления, так как "универсализация" отношений приводит к
"потере точности" описания, но зато и к удобству восприятия
информации конечным пользователем. Таким образом, значение
многомерных схем – преимущественно "интерфейсное" (они удобны
конечным пользователям), а не описательное.
Объект-роль – модель концептуального описания, принятая в
системе InfoModeler фирмы Visio. В этой системе для модели
"объект-роль" используется два языка: графический и [условно-]
естественный.
В данной модели предполагается отсутствие принципиального
различия между объектами и свойствами, в ряде случаев они могут
меняться местами, все зависит от "роли", которой исполняет объект
при определенном описании.
Приведенная классификация не является законченной и
всеобъемлющей. Можно выделить ряд "гибридных" моделей,
имеющих отношения к разным классам. Например, RM/T –
расширенная реляционная модель, предложенная в 1979 году Коддом
для "лучшего учета семантики" прикладной области. В отличие от
реляционной модели, RM/T вообще не получила никакого
воплощения в реальных системах, но она также имеет большое
методологическое значение.
Контрольные вопросы и задания
1. Определить понятие "модель данных".
2. Привести классификацию моделей данных согласно
архитектуре ANSI/SPARC.
3. Описать физические модели данных.
4. Дать характеристику инфологическим моделям.
5. Охарактеризовать документальные модели данных.
6. Какие языки используются для описания моделей,
ориентированных на формат данных?
7. Какой принцип положен в основу тезаурусных моделей?
8. Охарактеризовать дескрипторные модели.
9. Каким образом представлены фактографические модели?
10. Какими понятиями оперирует информационная алгебра?
11. В чем различие операций агрегирования и комплексирования
данных?
12. Определить особенности модели объект-роль.
13. В чем заключаются достоинства E/R модели?
14. Описать модель Смитов.
15. Указать особенности модели Бахмана.
16. За какую работу Ч. Бахман получил Тьюринговскую премию?
17. Кем была разработана модель"сущность-связь"?
18. Привести пример многомерной модели.
19. Охарактеризовать основные понятия многомерной модели.
20. В чем суть OLAP-технологии?
3. ДАТАЛОГИЧЕСКИЕ МОДЕЛИ ДАННЫХ
Хранимые в БД данные описываются различными моделями
представления данных. К классическим (традиционным) моделям
относятся: сетевая, иерархическая, реляционная.
Сетевая и иерархическая модель являются историческими
предшественниками реляционной. Все ранние (дореляционные)
системы не основывались на каких-либо абстрактных моделях,
понятие модели данных фактически появилось в лексиконе
специалистов в области БД только вместе с реляционным подходом (в
70-е гг.). В ранних системах доступ к БД производился на уровне
записей. Пользователи этих систем осуществляли явную навигацию в
БД, используя языки программирования, расширенные функциями
СУБД. Интерактивный доступ к БД поддерживался только путем
создания соответствующих прикладных программ с собственным
интерфейсом.
После появления реляционных систем большинство ранних
систем было оснащено "реляционными" интерфейсами. Однако в
большинстве случаев это не сделало их по-настоящему
реляционными системами, поскольку оставалась возможность
манипулировать данными в естественном для них режиме.
СУБД, основанные на сетевой и иерархической моделях,
используются и в настоящее время.
3.1. Иерархические модели
Иерархическая модель данных была создана в 60-х годах как
отражение потребностей практики. Иерархическая модель состоит из
упорядоченного набора экземпляров типа
дерево (рис. 7).
Тип "дерево" является составным. Он
может включать в себя подтипы ("поддеревья"),
также являющиеся типом "дерево". Тип
"дерево" состоит из вершины ("корневого" Рис.7. Дерево
типа) и упорядоченного набора из нуля или
более типов "поддеревьев". Каждый из элементарных типов,
включенных в тип "дерево", является простым или составным типом
"запись". Простая "запись" состоит из одного типа, например,
символьного, а составная "запись" объединяет некоторую
совокупность различных типов, например, числовые и символьные.
Пример типа "дерево" (схемы иерархической БД) приведен на рис 8.
Группа студентов
Группа_номер Группа_количество
Группа_стипендия
Староста
Ст_номер Ст_ФИО
Ст_телефон
Студенты
Студ_номер Студ_ФИО Студ_стипендия
Рис. 8. Пример типа "дерево"
Корневой тип имеет подчиненные типы и сам не является
подтипом (подчиненным типом). Подтип является потомком по
отношению к предку (родителю).
В примере, приведенном на рис. 8, Группа является предком для
Староста и Студенты, а Староста и Студенты – потомки Группа.
Между типами записи поддерживаются связи.
Тип "дерево" в целом представляет собой иерархически
организованный набор типов "запись". База данных представляет
совокупность таких деревьев. Пример данных в структуре рис.8
приведен на рис. 9.
Потомки одного и того же типа являются близнецами. В
иерархической модели предусмотрены навигационные операции по
структуре базы данных и операции манипулирования данными.
Например, могут быть следующие операции:
 найти указанное "дерево" БД (например, Группу 21 ИТ);
 перейти от одного дерева к другому;
 перейти от одной записи к другой внутри дерева (например, к
следующей записи типа Студенты);
 перейти от одной записи к другой в порядке обхода иерархии;
 вставить новую запись в указанную позицию;
 удалить текущую запись.
Группа студентов
22 ИТ
22
6000
Староста
5
Смехов В.И.
10-32-18
Студенты
2
Иванова Т.И.
300
3
Петров С.И.
350
7
Матвеев Р.С.
235
Рис. 9. Пример данных в базе данных
Между предками и потомками автоматически поддерживается
целостность ссылок. Основное правило: никакой потомок не может
существовать без своего родителя, у некоторых родителей не может
быть потомков.
Иерархическая модель данных активно использовалась во многих
СУБД до появления реляционных систем. Наиболее известным ее
представителем является СУБД IMS компании IBM Corp., первая
версия которой появилась в 60-е гг. СУБД IMS эксплуатируется и в
настоящее время. Иерархическую модель данных поддерживают
также следующие СУБД: MARK IV компании Control Pate
Corporation, System 2000, разработанный SAS-Institute и др.
"Живучесть" иерархических моделей обусловлена тем, что
многие структуры данных естественным образом иерархичны
(например, в области биологии: виды, классы, группы и т.д.).
3.2. Сетевые модели
Концепция сетевой модели данных была сформулирована в конце
60-х годов в Предложениях группы CODASYL, и с тех пор на нее
ссылаются как на модель CODASYL DTBG. Сети представляют
естественный способ представления отношений между объектами.
Они широко применяются в математике, физике, социологии и др.
областях знаний. Сетевой подход к организации данных является
расширением иерархического. В иерархических структурах записьпотомок должна иметь одного предка; в сетевой структуре данных
потомок может иметь любое число предков. Возможные связи в
сетевой модели представлены на рис. 10.
Сетевая БД состоит из набора записей и
набора связей между этими записями. Тип связи
определяется для двух типов записи: предка и
потомка. Экземпляр типа связи состоит из
одного экземпляра типа записи предка и
упорядоченного набора экземпляров типа
Рис. 10. Сети
записи потомка. Для данного типа связи С с
типом записи предка P и типом записи потомка PT должны
выполняться следующие два условия:
 каждый экземпляр типа P является предком только в одном
экземпляре C;
 каждый экземпляр PT является потомком не более чем в
одном экземпляре С.
На формирование типов связи не накладываются особые
ограничения, т.е. возможны, например, следующие ситуации:
 тип записи потомка в одном типе связи может быть типом
записи предка в другом типе связи (как в иерархии);
 данный тип записи P может быть типом записи предка в
любом числе типов связи;
 данный тип записи P может быть типом записи потомка в
любом числе типов связи;
 может существовать любое число типов связи с одним и тем
же типом записи предка и одним и тем же типом записи потомка; и
если L1 и L2 – два типа связи с одним и тем же типом записи предка P
и одним и тем же типом записи потомка C, то правила, по которым
образуется родство, в разных связях могут различаться;
 типы записи X и Y могут быть предком и потомком в одной
связи и потомком и предком – в другой;
 предок и потомок могут быть одного типа записи.
Пример сетевой схемы БД приведен на рис. 11.
Учатся в группе
Группа
Студенты
Староста
Состоит из студентов
Имеет старосту
Рис. 11. Пример сетевой БД
Примерный набор операций для манипулирования данными
может быть следующим:
 найти конкретную запись в наборе однотипных записей
(студента Петрова С.И.);
 перейти от предка к первому потомку по некоторой связи (к
первому студенту группы 22 ИТ);
 перейти к следующему потомку в некоторой связи (от
Петрова С.И. к Матвееву Р.С.);
 перейти от потомка к предку по некоторой связи (найти
группу Ивановой Т.И.);
 создать новую запись;
 удалить запись;
 изменить запись;
 включить в связь;
 исключить из связи;
 переставить в другую связь и т.д.
В принципе поддержание целостности связей не требуется, но
иногда требуют целостности по ссылкам (как в иерархической
модели).
Системы на основе сетевой модели не получили широкого
распространения на практике. Типичным представителем подобной
СУБД является IDMS компании Cullinana Corp. После вхождения
Cullinana Corp в состав Computer Associates, правами на систему
IDMS стала обладать эта компания, которая до сих пор продолжает ее
поставлять и развивать.
3.3. Реляционные модели
Реляционный подход формировался в 70-е гг. Публикация
известной статьи Э.Ф. Кодда о реляционной модели данных ( в июне
1970 г.) стимулировала целый ряд математических исследований,
направленных на изучение свойств реляционных баз данных,
впоследствии приведших к созданию теории реляционных баз
данных. В своих работах Э.Ф. Кодд описал математические основы
реляционной модели. Основная идея Кодда состояла в том, чтобы
применить концепцию математических отношений к моделированию
данных. Отношение – это таблица из строк и столбцов. Наиболее
важные характеристики реляционной модели заключаются в
следующем:
 Описание данных производится в соответствии с их
естественной структурой, т. е. не требуется добавления
дополнительных структур для машинного представления.
 Обеспечивается независимость данных от их физического
представления, от связей между данными и от соображений
реализации.
 Модель обеспечивает строгую математическую основу для
интерпретации выводимости, избыточности и непротиворечивости
отношений.
В это же время компания IBM начала разработку нескольких
исследовательских проектов и программных продуктов-прототипов,
нацеленных на создание реляционных СУБД. Благодаря успешному
созданию исследовательских прототипов, реляционная теория стала
активно продвигаться на практике. В 80-х гг. было создано большое
количество коммерческих реляционных продуктов – от компаний
IBM, Oracle Corp., Ingres Corp. и др. поставщиков. В настоящее время
реляционные СУБД доминируют на рынке инструментальных средств
разработки систем баз данных. Примерами наиболее известных из
них являются следующие: dBaseIIIPlus, dBaseIV (фирма Ashton-Tate),
DB2 (IBM), R:BASE (Microrim), FoxBase (Fox Software), Paradox
(Borland), Access (Microsoft), Clarion (Clarion software), Oracle (Oracle)
и др.
Реляционные системы продолжают совершенствоваться и их
внутренняя природа значительно
меняется.
В
связи
с
распространением объектного подхода в 90-е гг. появились объектно-
реляционные модели. Расширяется и сфера применения реляционных
систем. Подробнее современные направления технологий баз данных
изложены в главе 6.
Примером
развития
реляционной
модели
является
постреляционная модель. Классическая реляционная модель
предполагает неделимость данных, постреляционная модель снимает
ограничение неделимости данных, допускает многозначные поля,
состоящие из множества значений. Набор значений многозначных
полей считается отдельной таблицей, встроенной в основную таблицу
(табл. 1).
Таблица 1
Постреляционная таблица
Наименование
Тип
Количество
материала
Ткань пальтовая
п/ш
300
Ткань костюмная
ч/ш
п/э
200
150
п/ш
500
На длину и количество полей в записях не накладывается
требование постоянства, поэтому структура данных и таблиц имеет
большую гибкость.
Достоинством постреляционной модели является возможность
представления совокупности связанных реляционных таблиц одной
постреляционной таблицей. Это обеспечивает высокую наглядность
представления информации и повышение эффективности ее
обработки. К недостаткам можно отнести сложность решения
проблемы обеспечения целостности и непротиворечивости хранимых
данных.
Постреляционная модель поддерживается, например, СУБД
uniVers, Bubba, Dasdb.
3.3.1. Основные понятия реляционной модели
Реляционная модель определяется тремя аспектами данных:
структурой данных (объектами данных), целостностью данных и
обработкой данных. Основными понятиями, описывающими
структуру данных в реляционной модели, являются: отношение,
кортеж, атрибут, домен, первичный ключ.
Под отношением будем понимать двумерную таблицу,
содержащую некоторые данные о рассматриваемой предметной
области.
Кортеж представляет упорядоченный набор элементов
(соответствует строке этой таблицы).
Атрибут соответствует столбцу таблицы. Количество атрибутов
называется степенью отношения.
Домен представляет множество всех значений для определенных
атрибутов отношения.
Первичный ключ – уникальный идентификатор отношения,
однозначно определяющий каждый кортеж.
В реляционной теории определяются свойства отношений:
 Отношение не должно содержать одинаковых кортежей.
Важным следствием этого свойства является то, что каждую строку
можно однозначно определить с помощью набора атрибутов,
составляющих первичный ключ.
 Кортежи не упорядочены сверху вниз.
 Атрибуты не упорядочены слева направо.
 Все значения атрибутов должны быть атомарными
(простыми), т.е. не допускать группы значений в одном столбце
одной строки (не расчленять значения).
На рис.12 приведен пример отношения Провайдеры Internet.
Отношение Провайдеры Internet включает 4 домена. Домен 1
содержит названия провайдеров, домен 2 – почасовую оплату, домен
3 – предлагаемую скорость соединения, домен 4 – адреса Web-сайтов.
Отношение (таблица)
Название
провайдера
Демос
Портал
Гласнет
Атрибут Почасовая
оплата
Почасовая
оплата
44,0
38,0
46,0
Скорость Web-сайт
45
50
48
www.demos.ru
www.portal.ru
www.glasnet.ru
Значение атрибута
Рис. 12. Отношение Провайдеры Internet
К
о
р
т
е
ж
и
Отношение Провайдеры Internet содержит 3 кортежа, каждый из
которых состоит из 4-х элементов, выбираемых из соответствующего
домена. Каждому кортежу соответствует строка таблицы.
Схема отношения (заголовок отношения) представляет собой
список имен атрибутов. Например, для приведенного примера схема
отношения имеет вид ПРОВАЙДЕРЫ INTERNET(Название
Провайдера, Почасовая Оплата, Скорость, Web-Сайт). Множество
собственно кортежей отношения часто называют содержимым
(телом) отношения.
Каждое отношение имеет минимальный набор атрибутов, по
значениям которых можно однозначно идентифицировать требуемый
кортеж. Такой набор называется ключом. Минимальность означает,
что исключение из набора любого атрибута не позволяет
идентифицировать отношение по оставшимся. Каждое отношение
обладает хотя бы одним возможным ключом. Любой из возможных
ключей принимается за первичный ключ. Первичным ключом
называется атрибут отношения, однозначно определяющий каждый
из его кортежей. Например, в отношении ПРОВАЙДЕРЫ INTERNET
ключевым может являться атрибут Название провайдера. Ключ может
быть составным, т.е. содержать несколько атрибутов. Следует
отдавать предпочтение несоставным ключам или ключам,
составленным из минимального числа атрибутов.
Ключи
являются
важным
инструментом
поддержания
целостности данных и служат для реализации следующих целей:
 исключения дублирования значений в ключевых атрибутах
(остальные атрибуты в расчет не принимаются);
 упорядочения кортежей. Некоторые СУБД позволяют
производить упорядочение по возрастанию или убыванию значений
всех ключевых атрибутов, а также смешанное упорядочение (по
одним – возрастание, а по другим – убывание);
 ускорения работы с кортежами отношения;
 организации связывания таблиц.
База данных содержит несколько таблиц. Иногда одни и те же
имена атрибутов используются в разных таблицах. Пусть в
отношении R1 имеется неключевой атрибут А, значения которого
являются значениями ключевого атрибута В другого отношения R2.
Тогда говорят, что атрибут А отношения R1 является внешним
ключом. Т.е. внешний ключ представляет набор атрибутов
отношения, значения которых являются одновременно значениями
первичного ключа другого отношения. Внешний ключ, ссылающийся
на свою собственную реляционную таблицу, называется рекурсивным
внешним ключом. С помощью внешних ключей устанавливаются
связи между отношениями.
Например, имеются следующие отношения КЛИЕНТЫ (Код
клиента, Название клиента, Адрес клиента) и ЗАКАЗЫ (Номер
заказа, Код клиента, Количество товара). Если определить атрибут
Код клиента в отношении КЛИЕНТЫ как первичный ключ, то в
отношении ЗАКАЗЫ этот атрибут будет являться внешним ключом.
Если каждый клиент может разместить только один заказ, то говорят,
что таблицы связаны соотношением "один-к-одному". Если же
каждый клиент может разместить любое количество заказов (в том
числе и ни одного), то таблицы связаны соотношением "один-комногим". Таблица КЛИЕНТЫ в этом контексте называется основной,
таблица заказы – дополнительной. Существуют типы связей "многиеко-многим" и "многие-к-одному". Подробнее типы связей
рассмотрены в главе 4.
Список, в котором указываются имена реляционных таблиц с
перечислением их атрибутов (первичные ключи подчеркнуты) и
определений внешних ключей называется реляционной схемой базы
данных.
Для пользователей информационной системы является важным,
чтобы база данных отражала предметную область однозначно и
непротиворечиво. Если она обладает такими свойствами, то говорят,
что БД удовлетворяет условию целостности. Чтобы добиться
выполнения этого условия, на БД накладывают некоторые
ограничения, называемые ограничениями целостности. Выделяют
два основных типа ограничений: целостность сущностей и
ссылочная целостность.
Кортежи реляционной таблицы представляют в модели элементы
конкретных объектов реального мира – сущностей. Ограничение
первого типа состоит в том, что любой кортеж любого отношения
должен отличаться от любого другого кортежа этого отношения, т. е.
любое отношение должно обладать первичным ключом. Это
требование автоматически удовлетворяется, если в системе не
нарушаются базовые свойства отношений. Первичный ключ
определяет каждый кортеж, а следовательно, каждый элемент
сущности. Для работы с данными каждого кортежа необходимо знать
значение ключа. Таким образом, элемент не должен записываться в
базу данных до тех пор, пока не определены значения его ключевых
атрибутов. Т. е. никакой ключевой атрибут любой строки не должен
быть пустым.
Внешние ключи служат для обеспечения целостности данных,
называемое ссылочной целостностью. Это означает, что значение
внешнего ключа должно быть либо пустым, либо равным одному из
текущих значений первичного ключа другой таблицы, иначе каждому
значению внешнего ключа должны соответствовать строки в
связываемых отношениях. Для нашего примера это означает, что если
в отношении ЗАКАЗЫ указан Код клиента, то этот клиент должен
существовать.
Ограничения целостности должны поддерживаться СУБД. Для
соблюдения целостности сущностей достаточно гарантировать
отсутствие в отношении кортежей с одним и тем же значением
первичного ключа. Со ссылочной целостностью значительно сложнее.
Необходимо следить за тем, чтобы не появлялись некорректные
значения внешних ключей при обновлении отношений (например,
заказы несуществующих клиентов). При удалении кортежа
существует три подхода, позволяющие поддерживать ссылочную
целостность:
 запрещается производить удаление кортежа, на который
существуют ссылки (либо сначала удалить ссылающиеся кортежи,
либо изменить значения их внешнего ключа);
 при удалении кортежа, на который имеются ссылки, во всех
ссылающихся кортежах значение внешнего ключа становится
неопределенным;
 при удалении кортежа из отношения, на которое ведется
ссылка, из ссылающегося отношения автоматически удаляются все
ссылающиеся кортежи (каскадное удаление).
Большинство современных СУБД способны контролировать
соблюдение правила ссылочной целостности. Для этой цели
используются различные объекты баз данных (ссылочные
ограничения и правила, триггеры и др.).
Уточним еще раз условия, которым должны удовлетворять
данные в реляционных таблицах:
 все строки таблицы должны быть уникальны, т. е. не может
быть в таблице двух одинаковых строк;
 имена столбцов таблицы должны быть различны, а значения
их атомарными;
 все строки одной таблицы должны иметь одну структуру,
соответствующую именам и типам столбцов;
 последовательность размещения строк и столбцов в таблице
является несущественной.
База данных включает одну или несколько таблиц, объединенных
смысловым содержанием, а также процедурами контроля целостности
и обработки информации. Помимо таблиц, база данных содержит еще
и другие объекты: экранные формы, отчеты, прикладные программы,
работающие с информацией базы данных. Кроме того база данных
хранит словарь данных (метаданные – "данные о данных").
3.3.2. Реляционная алгебра
В предыдущем разделе мы рассмотрели два аспекта реляционной
модели: структуру данных и целостность данных. Третьим, наиболее
важным аспектом реляционной модели, являются предложенные Е.Ф.
Коддом реляционные языки обработки данных: реляционная алгебра
и реляционное исчисление.
И реляционная алгебра и реляционное исчисление являются
теоретическими языками. Выражения реляционной алгебры и
формулы реляционного исчисления выполняются над отношениями
реляционных БД, т.е. операнды и результаты всех действий являются
отношениями. Языки реляционной алгебры являются процедурными,
так как отношение, являющееся результатом запроса к реляционной
БД, вычисляется при пошаговом выполнении последовательности
реляционных операторов, применяемым к отношениям. Операторы
состоят из операндов, в роли которых выступают отношения, и
реляционных операций. Результатом реляционной операции является
отношение.
Языки исчислений, в отличие от реляционной алгебры, являются
непроцедурными (описательными, или декларативными) и позволяют
выражать запросы с помощью предиката первого порядка
(высказывания в виде функции), которому должны удовлетворять
кортежи или домены отношений. Запрос к БД, выполненный с
использованием подобного языка, содержит лишь информацию о
желаемом результате. Для этих языков характерно наличие наборов
правил для записи запросов. Непроцедурные языки формулируют, что
нужно делать, а не как этого добиться.
Механизмы реляционной алгебры и реляционного исчисления
эквивалентны. Это означает, что для любого допустимого выражения
реляционной
алгебры
можно
построить
эквивалентную
(производящую такой же результат) формулу реляционного
исчисления и наоборот.
Основные операции реляционной алгебры, предложенные
Коддом,
следующие:
объединение,
разность
(вычитание),
пересечение, декартово (прямое) произведение (или произведение),
выборка (селекция, ограничение), проекция, деление и соединение.
К. Дж. Дейт расширил этот набор, включив операции:
переименования атрибутов, образования новых вычисляемых
атрибутов, вычисления итоговых функций, построения сложных
алгебраических выражений, присвоения, сравнения и т. д.
Операции реляционной алгебры Кодда можно разделить на две
группы: множественные (объединение, разность, пересечение и
произведение) и специальные реляционные (проекция, выборка,
деление и соединение).
Операции реляционной алгебры могут выполняться над одним
отношением (унарная операция) или над двумя отношениями
(бинарная операция). При выполнении бинарной операции
отношения, участвующие в операциях, должны быть совместимы по
структуре. Для этого, во-первых, отношения должны иметь
одинаковое количество атрибутов. Во-вторых, атрибуты должны
иметь одинаковые имена. В-третьих, атрибуты должны быть
определены на одном домене. Структура результирующего
отношения по определенным правилам наследует свойства структур
исходных отношений. В большинстве рассматриваемых бинарных
реляционных операций будем считать, что заголовки исходных
отношений идентичны. Некоторые отношения не являются
совместимыми по структуре, но становятся таковыми после
переименования атрибутов. Операция переименования рассмотрена
далее.
В нашем пособии мы рассмотрим операции реляционной
алгебры, следуя подходу, предложенному К. Дж. Дейтом в [10].
В качестве примера воспользуемся базой данных поставщиков и
тканей. В таблице S (поставщики) находятся сведения о
поставщиках тканей: код поставщика, название, рейтинг, город
расположения поставщика В качестве первичного ключа таблицы
выбран код поставщика S#. Таблица M (материалы) содержит
сведения о поставляемых тканях: код материала; наименование
материала, тип материала, поверхностная плотность материала (MS),
название города, где производится этот материал. Первичным ключом
этой таблицы является М# (код материала). Последняя таблица SM
(поставки) содержит сведения о поставках тканей, осуществляемых
поставщиками, и их количестве. Например, поставщик S1 поставляет
ткани M1, M2 и др., поставщик S4 – ткань M4 и т.д. Предполагается,
что в одно и то же время не может быть более, чем одной поставки
для одного поставщика и для одной ткани. Поэтому в качестве
первичного ключа этой таблицы можно выбрать составной ключ
S#М#, представляющий уникальную комбинацию для каждой
поставки с точки зрения набора текущих поставок в таблице. Каждое
из полей S# и М# таблицы SM в отдельности является внешним
ключом по отношению к таблице S и M соответственно. Можно
также отметить, что данные в табл. 2–4 приведены неполные и
упрощенные, реальная база данных содержит значительно больше
объектов и сведений.
Таблица 2
Поставщики
S#
Поставщик
Рейтинг
Город_П
S1
ООО "Росмануфактура"
30
Москва
S2
ООО "Сибтекстиль"
15
Тюмень
S3
ТД "Ивановские ткани"
30
Иваново
S4
ЧП Федоров А.К.
20
Москва
S5
ООО "Андромеда"
10
Омск
Таблица 3
М#
M1
M2
M3
M4
M5
M6
Материалы
Наименование материала
Тип
Ткань пальтовая "Ассоль"
п/ш
Сукно костюмное
ч/ш
"Снежинка"
Ткань пальтовая-мохер
п/ш
"День"
Ткань костюмная "Вечер"
п/э
Ткань костюмноп/э
платьевая "Искра"
Драп пальтовый "Бриз"
ч/ш
MS
380
400
Город_M
Москва
Омск
600
Улан-Удэ
280
270
Тюмень
Тюмень
750
Москва
Таблица 4
S#
Поставки
М#
Количество
S1
S1
S1
S1
S1
S1
S2
S2
S3
S4
S4
S4
M1
M2
M3
M4
M5
M6
M1
M2
M2
M2
M4
M5
3900
2100
2700
2400
2200
1900
3200
4100
700
1100
900
4300
Операции реляционной алгебры
Объединением двух совместимых отношений R1 и R2 одинаковой
размерности (R1 UNION R2) является отношение R, содержащее все
кортежи, которые принадлежат исходным отношениям (за
исключением повторяющихся).
Пример 3.1. Объединение отношений
Пусть отношением R1 будет множество поставщиков из Москвы,
а отношением R2 – множество поставщиков, которые поставляют
материал M1. Тогда отношение R обозначает поставщиков,
находящихся в Москве, или поставщиков, поставляющих материал
M1, либо тех и других (рис. 13).
П#
S1
S4
Отношение R1
Поставщик
Статус
ООО "Росмануфактура
30
ЧП Федоров А.К.
20
Город_П
Москва
Москва
П#
S1
S2
Отношение R2
Поставщик
Статус
ООО "Росмануфактура"
30
ООО "Сибтекстиль"
15
Город_П
Москва
Тюмень
П#
S1
S4
S2
Отношение R
Поставщик
Статус
ООО "Росмануфактура"
30
ЧП Федоров А.К.
20
ООО "Сибтекстиль"
15
Город_П
Москва
Москва
Тюмень
Рис. 13. Пример объединения отношений
Вычитанием совместимых отношений R1 и R2 одинаковой
размерности (R1 MINUS R2) является отношение, тело которого
состоит из множества всех кортежей, принадлежащих отношению R1,
но не принадлежащих отношению R2.
S4
ЧП Федоров А.К.
20
Москва
Рис. 14. Пример вычитания отношений
Для тех же отношений R1 и R2 из предыдущего примера
отношение R будет представлять собой множество поставщиков,
находящихся в Москве, но не поставляющих материал M1 (рис. 14).
Можно заметить что результат операции вычитания зависит от
порядка следования операндов, т. е. R1 MINUS R2 и R2 MINUS R1 –
не одно и то же.
Пересечением двух совместимых отношений R1 и R2 одинаковой
размерности (R1 INTERSECT R2) является отношение R с телом,
включающим в себя кортежи, одновременно принадлежащие обоим
отношениям.
Для отношений R1 и R2 результирующее отношение R будет
S1
ООО "Росмануфактура"
30
Москва
Рис. 15. Пример пересечения отношений
означать всех поставщиков из Москвы, поставляющих материал M1.
Тело отношения R состоит из единственного элемента (рис. 15).
Произведением отношения R1 степени k1 (степень отношения –
количество атрибутов в отношении) и отношения R2 степени k2 (R1
ТIМЕS R2), которые не имеют одинаковых имен атрибутов, является
такое отношение R степени (k1+k2), заголовок которого представляет
сцепление заголовков отношений R1 и R2, а тело – имеет кортежи,
такие, что первые k1 элементов кортежей принадлежат множеству R1,
а последние k2 элементов – множеству R2. Т. е. можно отметить, что
произведение возвращает отношение, содержащее всевозможные
кортежи,
которые
являются
сочетанием
двух
кортежей,
принадлежащих соответственно двум определенным отношениям.
При необходимости получить произведение двух отношений,
имеющих одинаковые имена одного или нескольких атрибутов,
применяется операция переименования RENAME.
Пример 3.2. Произведение отношений
Отношение R1 представляет множество номеров всех текущих
поставщиков {S1, S2, S3, S4, S5}, а отношение R2 – множество
номеров всех материалов {M1, M2, M3, M4, M5, M6}. Результат
операции – множество пар типа "поставщик-материал", т.е. {(S1, M1),
(S1, M2), (S1, M3)…(S5, M6)}.
Можно заметить, что на практике явное использование
произведения требуется только для сложных запросов.
Выборка возвращает отношение, содержащее все кортежи из
определенного отношения, которые удовлетворяют определенным
условиям. Выборка (R WHERE f) отношения R по формуле f
представляет собой новое отношение с заголовком отношения R и
телом, состоящим из таких кортежей отношения R, которые
удовлетворяют истинности логического выражения, заданного
формулой f.
Для записи формулы f используются имена атрибутов,
константы, логические операции (AND – И, OR – ИЛИ, NOT – НЕ),
операции отношения между величинами и скобки.
Пример 3.3. Выборка
1. Логическое выражение: M WHERE MS <400 (рис. 16).
Результирующее отношение содержит кортежи таблицы М,
содержащие материалы, поверхностная плотность которых меньше
М#
M1
M4
M5
Наименование материала
Ткань пальтовая "Ассоль"
Ткань костюмная "Вечер"
Ткань костюмноплатьевая "Искра"
Тип
п/ш
п/э
п/э
MS
380
280
270
Город_М
Москва
Тюмень
Тюмень
Рис. 16. Результат выборки 1
400.
2. Логическое выражение: SM WHERE S# = "S1" АND М# = "M1"
(рис. 17). Результирующее отношение содержит кортеж таблицы SM,
определяющий поставку поставщиком S1 материала M1.
Проекция возвращает отношение, содержащее все кортежи
определенного отношения после исключения из него некоторых
атрибутов.
Проекция отношения R на атрибуты X, У,..., Z (R [X, Y,..., Z]), где
множество (X, У,..., Z} является подмножеством полного списка
атрибутов заголовка отношения R, представляет собой отношение с
заголовком X, Y,..., Z и телом, содержащим кортежи отношения R, за
исключением повторяющихся кортежей. Повторение одинаковых
атрибутов в списке X, Y,..., Z запрещается.
S#
S1
М#
M1
Количество
3900
Рис. 17. Результат выборки 2
Операция проекции допускает следующие дополнительные
варианты записи.
1. Отсутствие списка атрибутов подразумевает указание всех
атрибутов (операция тождественной проекции);
2. Выражение вида R[ ] означает пустую проекцию, результатом
которой является пустое множество;
3. Операция проекции может применяться к произвольному
отношению, в том числе и к результату выборки.
Пример 3.4. Проекция
1. Результат проекции отношения M на атрибуты Тип, Город_М
(M[Тип, Город_М]) представлен на рис. 18.
Тип
п/ш
ч/ш
п/ш
п/э
ч/ш
Город_М
Москва
Омск
Улан-Удэ
Тюмень
Москва
Рис. 18. Результат проекции 1
2. Результат проекции ((S WHERE Город_П="Москва")[S#,
Город_П]) (рис. 19).
S#
S1
S4
Город_П
Москва
Москва
Рис. 19. Результат проекции 2
Деление для двух отношений (бинарного и унарного), возвращает
отношение, содержащее все значения одного атрибута бинарного
отношения, которое соответствует (в другом атрибуте) всем
значениям в унарном отношении.
Результатом деления отношения R1 с атрибутами А и В на
отношение R2 с атрибутом В (R1 DIVIDEBY R2), где А и В простые
или составные атрибуты, причем атрибут В – общий атрибут,
определенный на одном и том же домене (множестве доменов
составного атрибута), является отношение R с заголовком А и телом,
состоящим из кортежей r таких, что в отношении R1 имеются
кортежи (r, s), причем множество значений s включает множество
значений атрибута В отношения R2.
Пример 3.5. Деление отношений
R1 – проекция SM[S#, М#], R2 – отношение с заголовком М# и
телом M2, M4. Результатом будет отношение R с заголовком S# и
телом S1, S4 (рис. 20).
S#
S1
S1
S1
S1
S1
S1
S2
S2
S3
S4
S4
S4
М#
M1
M2
M3
M4
M5
M6
M1
M2
M2
M2
M4
M5
Отношения R1, R2, R
М#
M2
M4
S#
S1
S4
Рис. 20. Пример деления отношений
Соединение возвращает отношение, кортежи которого – это
сочетание двух кортежей, имеющих общее значения для одного или
нескольких общих атрибутов этих двух отношений. Операция
соединения имеет несколько разновидностей. Наиболее важным
является естественное соединение.
Операция
естественного
соединения
(операция
JOIN)
применяется к двум отношениям, имеющим общий атрибут. Этот
атрибут в отношениях имеет одно и то же имя и определен на одном и
том же домене.
Пусть отношения R1 и R2 имеют заголовки {X1, X2,… ,XM,
Y1,Y2,..,YN} и {Y1,Y2,..,YN, Z1, Z2, ZP} соответственно; т.е. атрибуты
Y1,Y2,..,YN – общие атрибуты для двух отношений. Можно
рассматривать выражения { X1, X2,… ,XM }, { Y1,Y2,..,YN }, { Z1, Z2,
ZP } как три составных атрибута X, Y, Z соответственно. Тогда
естественным соединением отношений R1 и R2 (R1 JOIN R2)
является отношение с заголовком {X, Y, Z} и телом, содержащим
множество всех кортежей таких, для которых в отношении R1
значение атрибута X равно x, атрибута Y равно y, в отношении R2
значение атрибута Y равно y, значение атрибута Z равно z.
Допустим, что атрибуты Город_П и Город_М определены на
одном и том же домене: множестве названий городов. Имя этого
домена может быть Город. Результат естественного соединения (S
JOIN M) приведен на рис. 21.
S#
Поставщик
S1
ООО
"Росмануфакт
ура"
ООО
"Росмануфакт
ура"
ООО "Сибтекстиль"
S1
S2
S2
S4
S4
S5
Рейти
нг
30
Город
М#
Наименование
материала
Ткань пальтовая
"Ассоль"
Тип
MS
Москва
M1
п/ш
380
30
Москва
M6
Драп пальтовый
"Бриз"
ч/ш
750
Тюмень
M4
Ткань
п/э
костюмная
"Вечер"
ООО "Сиб15
Тюмень M5 Ткань
п/э
текстиль"
костюмноплатьевая
"Искра"
ЧП Федоров
20
Москва M1 Ткань пальтовая п/ш
А.К.
"Ассоль"
ЧП Федоров
20
Москва M6 Драп пальтовый ч/ш
А.К.
"Бриз"
ООО
10
Омск
M2 Сукно
ч/ш
"Андромеда"
костюмное
Рис. 21. Результат естественного
соединения
"Снежинка"
280
15
270
380
750
400
Соединение Сf(R1, R2) отношений R1 и R2 по условию, заданному
формулой f ( – соединение), представляет собой отношение R,
которое можно получить путем произведения отношений R1 и R2 с
последующим применением к результату операции выборки по
формуле f. Правила записи формулы f такие же, как и для операции
выборки.
Другими словами, соединением отношения R1 по атрибуту А с
отношением R2 по атрибуту В (отношения не имеют общих имен
атрибутов) является результат выполнения операции вида:
(R1 Т1МЕS R2) WHERE А  В,
где  – логическое выражение над атрибутами, определенными
на одном (нескольких – для составного атрибута) домене.
Пример 3.6. -соединение
Необходимо найти соединение отношений S и P по атрибутам
Город_П
и
Город_М
соответственно,
причем
кортежи
результирующего отношения должны удовлетворять отношению
"больше".
(S TIMES M) WHERE Город_П > Город_М. Результат операции
-соединения показан в табл. 5.
Таблица 5
Результат операции соединения
S#
Поставщи
к
Рейт
инг
Город
_П
М#
S2
ООО
"Сибтекстиль"
15
Тюмень
M1
ООО
"Сибтекстиль"
S2 ООО
"Сибтекстиль"
15
Тюмень
M2
Сукно
ч/ш
"Снежинка"
400
15
Тюмень
M6
Драп
пальтовый
"Бриз"
ч/ш
750 Москва
S5 ООО
"Андромеда"
S5 ООО
"Андромеда"
10
Омск
M1
п/ш
380 Москва
10
Омск
M6
Ткань
пальтовая
"Ассоль"
Драп
пальтовый
"Бриз"
ч/ш
750 Москва
S2
Наименование
материала
Ткань
пальтовая
"Ассоль"
Тип
MS
Город_
М
п/ш
380 Москва
Омск
При рассмотрении операций реляционной алгебры К. Дж. Дейтом
вводятся дополнительные операторы: переименования, расширения,
подведения итогов, обновления [10].
Оператор переименования позволяет изменить имя атрибута
отношения и имеет следующий синтаксис:
<отношение> RENAME <исходное имя атрибута>
АS <новое имя атрибута>,
где <отношение> задается именем отношения либо выражением
реляционной алгебры. В последнем случае выражение заключают в
круглые скобки.
Например, S RENAME Город_П AS
Город_размещения_Поставщика
Допустим, необходимо изменить несколько имен атрибутов. Для
такого
случая
Дейт
вводит
оператор
множественного
переименования, синтаксис которого приведен ниже:
<отн.> RENAME <исх_имя_атр.1> АS <нов_имя_атр.1>,
<исх_имя_атр.2> АS <нов_имя_атр.2>,...,
<исх_имя_атр.N> АS <нов_имя_атр.N>.
Оператор расширения позволяет
дополнительный
атрибут,
значения
посредством
некоторых
скалярных
расширения имеет вид:
добавить в отношение
которого
вычисляются
вычислений.
Оператор
EXTEND <отношение> АDD <выражение>АS<нов_атрибут>,
где к исходному отношению добавляется (ключевое слово АDD)
новый атрибут с именем <нов_атрибут>, значения которого
подсчитываются по правилам, заданным <выражением>. Исходное
отношение может быть задано именем отношения или с помощью
выражения реляционной алгебры, заключенного в круглые скобки.
При этом имя нового атрибута не должно входить в заголовок
исходного отношения и не может использоваться в <выражении>.
Например, EXTEND S ADD 'Поставщик' AS SNAME.
Приведенное выражение дополняет отношение S столбцом
SNAME, значениями которого является символьная константа
'Поставщик'.
Помимо обычных арифметических операций и операций
сравнения в выражении можно использовать итоговые функции,
такие как, COUNT (количество), SUM (сумма), AVG (среднее), МАХ,
МIN.
Оператор множественного расширения имеет следующую
синтаксическую конструкцию:
EXTEND <отношение> АDD <выр_1> АS <атр_1>,
<выр_2> АS <атр_2>,...,
<выр_N>АS <атр_N>.
Операция подведения итогов SUMMARIZE выполняет
"вертикальные" или групповые вычисления и имеет следующий
формат:
SUMMARIZE <отношение> ВY (<список атрибутов>) АDD
<выражение> АS <новый атри6ут>,
где исходное отношение задается именем отношения либо
заключенным в круглые скобки выражением реляционной алгебры,
<список атрибутов> представляет собой разделенные запятыми имена
атрибутов исходного отношения А1, А2,..., АN, <выражение> – это
скалярное выражение, аналогичное выражению операции EXTEND, а
<новый атрибут> – имя формируемого атрибута. В списке атрибутов
и в выражении не должно использоваться имя нового атрибута.
Результатом операции SUMMARIZE является отношение R с
заголовком, состоящим из атрибутов списка, расширенного новым
атрибутом. Для получения тела отношения R сначала выполняется
проецирование (назовем проекцию R1) исходного отношения на
атрибуты А1, А2,..., АN , после чего каждый кортеж проекции
расширяется новым (N+1)-м атрибутом. Поскольку проецирование,
как правило, приводит к сокращению количества кортежей по
отношению к исходному отношению (удаляются одинаковые
кортежи), то можно считать, что происходит своеобразное
группирование кортежей исходного отношения: одному кортежу
отношения R1 соответствует один или более (если было
дублирование при проецировании) кортежей исходного отношения.
Значение (N+1)-го атрибута каждого кортежа отношения R
формируется путем вычисления выражения над соответствующей
этому кортежу группой кортежей исходного отношения.
Пример 3.7. Подведение итогов
Пусть требуется вычислить количество поставок по каждому из
поставщиков:
SUMMARIZE SP BY (S#) ADD COUNT AS Количество
поставок
Результат вычисления показан на рис. 22.
S#
S1
S2
S3
S4
Количество поставок
6
2
1
3
Рис. 22. Подведение итогов
Отметим, что функция COUNT определяет количество кортежей
в каждой из групп исходного отношения.
Рассмотрим еще один пример. С помощью выражения
SUMMARIZE SP BY (M#) ADD SUM (Количество) AS Общее
количество
определяется общее количество по каждому виду материала.
Оператор множественного подведения итогов, подобно
соответствующим операциям переименования и расширения,
выполняет одновременно несколько "вертикальных" вычислений и
записывает результаты в отдельные новые атрибуты. Примером
данного оператора может служить следующая запись:
SUMMARIZE SP BY (M#) ADD SUM (Количество) AS Общее
количество, AVG (Количество) AS (Сред_знач).
Оператор реляционного
следующим образом:
присвоения
можно
представить
<выражение-цель>:= <выражение-источник>,
где оба выражения представляют совместимые по структуре
отношения.
Вычисленное
значение
<выражение-источник>
присваивается отношению <выражение-цель>,
заменяя его
предыдущее значение.
Операция присвоения позволяет обновлять базу данных. С
помощью операции присвоения можно не только полностью заменить
все значения отношения <выражение-цель>, но и добавить или
удалить кортежи. Приведем пример, в котором в отношение S
добавляется один кортеж:
S:=S
UNION{(<S#
:'S6'>,
<Поставщик:
Донецкая
мануфактура>, <Рейтинг:40>, <Город_П: Донецк>)}
Оператор вставки имеет следующий вид:
INSERT <выражение-источник> INTO <выражение-цель>,
где оба выражения представляют совместимые по структуре
отношения. Выполнение операции заключается в вычислении
значения отношения <выражение-источник> и вставке полученных
кортежей в отношение, заданное <выражение-цель> (в приведенном
примере в отношение T).
INSERT (S WHERE Город_П ='Москва') INTO T
Оператор обновления имеет следующий вид:
UPDATE <выражение-цель> <список элементов>,
где <список элементов> представляет собой последовательность
разделенных запятыми операций присвоения <атрибут>:= <скалярное
выражение>. Результатом выполнения операции обновления является
отношение, полученное после присвоения соответствующих значений
атрибутам отношения, заданного целевым выражением
Например, UPDATE M WHERE Тип='п/ш' Город_П:='Ростов'.
Эта операция предписывает изменить значение атрибута Город_П
(независимо от того, каким оно было) на новое значение – 'Ростов'
таких кортежей отношения M, атрибут Тип которых имеет значение
'п/ш'.
Оператор удаления имеет следующий вид:
DELETE <выражение-цель>,
где <выражение-цель> представляет собой реляционное выражение.
Все кортежи в результирующем отношении удаляются. Например,
DELETE S WHERE Рейтинг <20.
Операция реляционного сравнения может использоваться для
прямого сравнения двух отношений. Она имеет следующий
синтаксис:
<выражение1> <выражение2>,
где выражения представляют совместимые по структуре отношения, а
знак  – это один из следующих операторов сравнения: = (равно), 
(не равно),  (подмножество), < (собственное подмножество), 
(надмножество), > (собственное надмножество).
Например, сравнение: "Совпадают ли города поставщиков и
города, в которых производятся ткани" можно записать так:
S[Город_П] = M[Город_М].
Сравнение "Есть ли поставщики, не осуществляющие поставки
материалов?" записывается следующим образом:
S[M#]=SP[M#].
Приведем несколько примеров использования реляционных
операторов.
1. Получить названия поставщиков, осуществляющих поставки
материала M2:
((SP JOIN S) WHERE M#='M2') [Поставщик].
2. Получить названия поставщиков, которые не поставляют
материал M2:
((S [S#] MINUS (SP WHERE M#='M2') [S#]) JOIN S) [Поставщик].
3. Получить названия поставщиков, поставляющих все детали:
((SP [S#, M#] DIVIDEBY M [M#] JOIN S [Поставщик].
4. Получить названия поставщиков, которые поставляют по
крайней мере один материал типа 'п/ш':
(((M WHERE Тип='п/ш') JOIN SP) [S#] JOIN S) [Поставщик].
В реализациях конкретных реляционных СУБД реляционная
алгебра и реляционное исчисление в "чистом" виде не используются.
Фактическим стандартом доступа к реляционным данным стал язык
SQL (Structured Query Language), представляющий собой смесь
операторов реляционной алгебры и выражений реляционного
исчисления, использующий синтаксис, близкий к фразам английского
языка
и
расширенный
дополнительными
возможностями,
отсутствующими в реляционной алгебре и реляционном исчислении.
3.3.3. Язык запросов по образцу QBE
Для манипулирования данными в базах данных используются
запросы. Запрос представляет собой сообщение конечного пользователя
или приложения, направляемое СУБД и активизирующее в базе данных
следующие действия: выборку, вставку, удаление или обновление
указанных в запросе данных. Запросы описываются с помощью языков
запросов: QBE (Query By Example) – язык запросов по образцу; SQL
(Structured Query Language) – структурированный язык запросов. Оба
языка являются непроцедурными, т. е. описывают свойства
результата ("что надо сделать"), а не алгоритм решения задачи ("как
это сделать").
Для манипулирования данными указанные языки имеют
практически одинаковые возможности. Главное отличие между ними
заключается в способе формирования запросов: язык QBE
предполагает ручное или визуальное формирование запроса, в то
время как использование SQL означает программирование запроса.
Язык QBE позволяет создавать запросы к БД путем заполнения
предлагаемой СУБД запросной формы. Традиционные компьютерные
языки являются текстовыми, в них решение задач формулируется в
виде символьных строк. QBE является графическим языком, в
котором запросы формулируются посредством графического
представления таблиц базы данных. Такой способ задания запросов
обеспечивает высокую наглядность и не требует знания
программирования – достаточно описать образец ожидаемого
результата. В каждой из современных реляционных СУБД имеется
свой вариант языка QBE, незначительно отличающийся от первого
описания QBE, предложенного М.М. Злуффом в 1975-1977 гг.
Помещая символы а определенные места в столбцах таблицы –
шаблона запроса, пользователь может определять условия отбора
строк для запроса, группировки данных, формат вывода данных,
операции обновления данных.
На языке QBE можно создавать однотабличные и
многотабличные (выбирающие или обрабатывающие данные из
нескольких связанных таблиц) запросы.
Запросная форма имеет вид таблицы-шаблона, имя и названия
полей которой совпадают с именем и названиями полей
соответствующей исходной таблицы. Чтобы узнать имена доступных
таблиц БД, в языке QBE предусмотрен запрос на выборку имен
таблиц. Названия полей исходной таблицы могут вводиться в шаблон
вручную или автоматически.
Для иллюстрации средств и возможностей языков QBE и SQL
используем БД небольшой торговой фирмы. В базе данных хранится
следующая информация: информация о клиентах, с которыми
работает данная фирма; информация о заказах, сделанных клиентами;
информация о товарах данной фирмы [табл. 6-8]. В таблицах
приведены неполные и упрощенные данные.
В таблице CUST (табл. 6) хранятся данные о клиентах: номер
клиента – CUST_NUM; название фирмы-клиента – CUST_NAME;
общий объем заказов, сделанных клиентом за год – CUST_SUM.
В таблице PROD (табл. 7) хранятся сведения о товарах фирмы:
идентификатор товара – PROD_ID; наименование товара –
PROD_NAME; цена товара – PRICE; количество единиц товара на
складе – STORE.
Таблица ORDERS (табл. 8) содержит сведения о заказах: номер
заказа – ORDER_NUM; номер клиента, сделавшего заказ –
CUST_NUM; идентификатор заказанного продукта – PROD_ID;
количество заказанного продукта – QTY; дата поставки –
DATE_ORDER. Для простоты будем считать, что в одном заказе
может упоминаться только один товар.
Таблица 6
CUST
CUST_NUM
3101
3102
3103
3104
3105
3106
3107
3108
3109
CUST_NAME
CUST_SUM
ООО "PC-Style"
ООО "Гермес"
ЧП Федоров В.Г.
ООО "Формат"
ЧП Гришин П.В.
ОАО "Энтрон"
ЗАО"IT-COM"
ООО "Омега"
ОАО " PC-Центр"
50000
70000
15000
100000
20000
125000
135000
95000
160000
Таблица 7
PROD
PROD_ID
3P
4P
6P
4MB
7MB
3V
4V
1M
2M
3M
PROD_NAME
Процессор Celeron 2400
Процессор Athlon XP 2600+
Процессор Pentium-4 2600
Материнская плата GA 81 PE 1000
Материнская плата EPOX 8KRA2+
Видеокарта Nvidia GeForce FX5600 128mb
Видеокарта Ati Radeon 9500 64mb
ОЗУ DDR 256 MB PC 2700
ОЗУ DDR 256 MB PC 3200
ОЗУ DDR 512 MB PC 3200
PRICE
STORE
90
110
200
100
95
140
150
45
50
97
1000
1200
800
1400
1350
770
850
1150
1250
1600
Таблица 8
ORDERS
ORDER_NUM
221
222
223
224
CUST_NUM
3101
3105
3106
3101
PROD_ID
3P
4MB
6P
3V
QTY
15
30
16
12
DATE_ORDER
20.12.02
20.12.02
21.12.02
5.01.03
225
226
227
228
229
230
231
3105
3104
3103
3102
3103
3108
3107
4P
1M
7MB
2M
3P
3M
4MB
27
10
18
21
17
16
10
17.01.03
14.02.03
18..02.03
1.03.03
5.03.03
5.03.03
7.03.03
QBE предлагает пользователю для создания запроса заполнение
таблиц-шаблонов. В первом столбце таблицы-шаблона выводится имя
таблицы, во всех остальных – имена столбцов.
Пример 3.8. Пример заполнения шаблона запроса
Запрос
"Вывести
названия
всех
клиентов"
можно
сформулировать с помощью следующего шаблона (рис. 23):
CUST УРЕ CUST_NUM
CUST_NAME
P.
CUST_SUM
Рис. 23. Шаблон запроса
В приведенном шаблоне "P." – это команда вывода, означающая,
что выводятся значения заданного столбца. После команды в языке
QBE ставится точка.
Результат выполнения приведенного шаблона следующий:
CUST_NAME
ООО "PC-Style"
ООО "Гермес"
ЧП Федоров В.Г.
ООО "Формат"
ЧП Гришин П.В.
ОАО "Энтрон"
ЗАО"IT-COM"
ООО "Омега"
ОАО " PC-Центр"
Обратим внимание на то, что результатом запроса является
реляционная таблица.
Рассмотрим различные варианты создания запросов.
Пример 3.9. Запрос с простым условием сравнения
Вывести все товары, цена которых не превышает 90 долларов.
Шаблон будет выглядеть следующим образом (рис. 24).
PROD
PROD_ID
PROD_NAME
P.
PRICE
<90
Рис. 24. Запрос с простым условием
STORE
Результатом запроса является следующий набор данных:
PROD_NAME
ОЗУ DDR 256 MB PC 2700
ОЗУ DDR 256 MB PC 3200
Пример 3.10. Запрос с составным условием сравнения
(логическая операция И)
Требуется вывести товары, цена которых больше 100 долларов и
количество которых на складе больше 1000 единиц (рис. 25).
PROD
P.
PROD_ID
PROD_NAME
PRICE
>100
STORE
>1000
Рис. 25. Запрос на выборку с операцией "И"
Результат запроса:
PROD_ID
PROD_NAME
PRICE
STORE
4P
Процессор Athlon XP 2600+
110
1200
Выводятся все данные выбранной строки, т.к. в шаблоне запроса
команда вывода "P." стоит в первом столбце шаблона. Если два
условия стоят на одной строке шаблона, то для выбора строки
необходимо выполнение обоих условий (логическая операция И).
Пример 3.11. Запрос с составным условием сравнения
(логическая операция ИЛИ)
Вывести все товары, цена которых больше 100 долларов или
количество которых на складе больше 1000 единиц (рис. 26).
PROD
PROD_ID
PROD_NAME
P.
P.
PRICE
P.>100
P.
STORE
P.
P.>1000
Рис. 26. Запрос на выборку с операцией "ИЛИ"
Условия, записанные на двух разных строках шаблона запроса,
соответствуют условиям, объединенным логическим оператором
ИЛИ. Команда вывода P. расположена на обеих строках и в каждом
из столбцов, которые должны выводится.
Результат запроса следующий:
PROD_NAME
PRICE
STORE
Процессор Athlon XP 2600+
Процессор Pentium-4 2600
Материнская плата GA 81 PE 1000
Материнская плата EPOX 8KRA2+
Видеокарта Nvidia GeForce FX5600
128mb
Видеокарта Ati Radeon 9500 64mb
ОЗУ DDR 256 MB PC 2700
ОЗУ DDR 256 MB PC 3200
ОЗУ DDR 512 MB PC 3200
110
200
100
95
140
1200
800
1400
1350
770
150
45
50
97
850
1150
1250
1600
Пример 3.12. Запрос с использованием блока условий
Например, требуется вывести товары с ценой от 100 до 150
долларов. Для этого введем блок условий с явным заданием операции
"И". Этот блок, обозначенный CONDITIONS содержит любые
требуемые ограничения данных. В нашем примере к значениям
одного и того же столбца должны одновременно применяться два
условия. Поэтому удобно применить одно условие в блоке условий
(рис. 27).
В этом примере введена переменная _S, которая является
элементом-образцом и обозначает неопределенное значение в
столбце таблицы. В данном примере элемент-образец обозначает
любое возможное значение столбца PRICE.
PROD
P.
PROD_ID
PROD_NAME
PRICE
_S
STORE
CONDITIONS
_S>=100 AND _S<=150
Рис. 27. Использование блока условий
Результат:
PROD_ID
PROD_NAME
PRICE
STORE
4P
4MB
3V
Процессор Athlon XP 2600+
Материнская плата GA 81 PE 1000
Видеокарта
Nvidia
GeForce
110
100
140
1200
1400
770
FX5600 128mb
Видеокарта Ati Radeon 9500 64mb
4V
150
850
Пример 3.13. Сравнение с элементами-образцами
Определить товар, цена которого больше, чем цена видеокарты
Nvidia GeForce FX5600 128mb . Пример шаблона приведен на рис. 28.
PROD
PROD_ID
PROD_NAME
PRICE
P.
P.>_В
Видеокарта Nvidia _В
GeForce
FX5600
128mb
STORE
Рис. 28. Сравнение с элементами-образцами
По-другому запрос можно сформулировать следующим образом:
"Цена видеокарты Nvidia GeForce FX5600 128mb обозначена как _В.
Вывести все товары, цена которых больше, чем _В."
Результат:
PROD_NAME
PRICE
Процессор Pentium-4 2600
Видеокарта Ati Radeon 9500 64mb
200
150
Рассмотрим создание многотабличных запросов.
Пример 3.14. Объединение двух таблиц
Допустим, необходимо вывести название фирм-клиентов,
заказавших количество товара больше 20 единиц. Для создания этого
запроса необходимо объединить две таблицы. Элемент-образец _CN
связывает две таблицы (рис. 29).
CUST
ORDERS
CUST_NUM
CUST_NAME
_CN
P.
ORDER_NUM
CUST_NUM
_CN
PROD_ID
QTY
P. >20
CUST_SUM
DATE_ORDER
Рис. 29. Связывание двух таблиц
Это означает, что в выбранной паре строк из двух таблиц в
соответствующих столбцах должно находиться одно и то же
значение.
Результат:
CUST_NAME
QTY
ЧП Гришин П.В.
ЧП Гришин П.В.
ООО "Гермес"
30
27
21
Пример 3.15. Запрос с использованием трех таблиц
Вывести названия клиентов, заказавших процессор Celeron 2400
(рис. 30).
CUST
CUST_NUM
CUST_NAME
_CN
P.
ORDERS ORDER_NUM
PROD
CUST_NUM
_CN
PROD_ID
_PI
PROD_ID
PROD_NAME
_PI
Процессор Celeron 2400
CUST_SU
M
QTY
DATE_ORDER
PRICE
STORE
Рис. 30. Связывание трех таблиц
Результат:
CUST_NAME
ООО "PC-Style"
ЧП Федоров В.Г.
Пример 3.16. Связывание таблиц с вычислениями
Определить объем каждого заказа в таблице ORDERS (рис.31).
PROD
PROD_ID
_PI
ORDERS ORDER_NUM
_OR
P.
_OR
PROD_NAME
CUST_NUM
'Объем заказа='
PRICE
_PR
PROD_ID
_PI
_PR*_QT
Рис. 31. Запрос с вычислениями
QTY
_QT
STORE
DATE_ORDER
В этом запросе введена дополнительная таблица, не имеющая
заголовков столбцов. Такая таблица называется целевой и
используется для определения данных, выводимых запросом. Данная
таблица содержит информацию о цели (результате запроса). Команда
вывода P. расположена в первом столбце целевой таблицы,
следовательно, выводятся все столбцы целевой таблицы.
Результат:
ORDER_NUM
221
222
223
224
225
226
227
228
229
230
231
Объем
Объем
Объем
Объем
объем
Объем
Объем
Объем
Объем
Объем
Объем
заказа=1350
заказа=3000
заказа=3200
заказа=1680
заказа=2970
заказа=450
заказа=1710
заказа=1050
заказа=1530
заказа=1552
заказа=1000
Пример 3.17. Запрос с частичным совпадением
Вывести номера заказов, в которых требуется поставка только
процессоров (рис. 32).
ORDERS ORDER_NUM
_ON
CUST_NUM
PROD
PROD_NAME
Процессор_RT
P.
PROD_ID
_PI
PROD_ID
_PI
QTY
PRICE
DATE_ORDER
STORE
_ON
Рис. 32. Запрос с частичным совпадением
В этом примере выбор строк основан на частичном совпадении. В
наших таблицах возможны два варианта записи модели процессоров,
поэтому в качестве окончания названия товара используется элемент
примера _RT, обозначающий любое возможное из окончаний.
При записи выражений на QBE
могут использоваться
встроенные функции: CNT (количество), SUM (сумма), AVG
(среднее), MIN (минимум), MAX (максимум), UN (уникальный), ALL
(все значения, в том числе и повторяющиеся).
Пример 3.18. Запрос с использованием функции MAX
Вывести максимальный объем из годовых заказов клиентов.
Шаблон запроса представлен на рис. 33.
Результат запроса, состоящий из одного значения 160 000, тоже
можно считать реляционной таблицей из одного столбца и одной
строки.
CUST
CUST_NUM
CUST_NAME
CUST_SUM
_T
P.
MAX._T
Рис. 33. Запрос с использованием функции MAX
Пример 3.19. Запрос с использованием функции AVG
Каков средний годовой объем заказов клиентов?
Шаблон запроса представлен на рис. 34.
Пример 3.20. Запрос с использованием функции CNT
Сколько клиентов заказало процессор Celeron 2400?
Шаблон запроса показан на рис. 35.
CUST
CUST_NUM
CUST_NAME
CUST_SUM
_T
P.
AVG._T
Рис. 34. Запрос с использованием функции AVG
ORDERS ORDER_NUM
CUST_NUM
_CN
PROD
PROD_NAME
процессор Celeron 2400
P.
PROD_ID
_PI
PROD_ID
_PI
QTY
DATE_ORDER
PRICE
STORE
CNT._CN
Рис. 35. Запрос с использованием функции CNT
Пример 3.21. Запрос с использованием оператора UNQ
Сколько всего клиентов сделало заказы?
Шаблон запроса приведен ниже (рис. 36).
ORDERS ORDER_NUM
P.
CUST_NUM
_CN
PROD_ID
QTY
DATE_ORDER
CNT.UNQ._CN
Рис. 36. Запрос с использованием оператора UNQ
Результат: 9. Оператор UNQ применяется для того, чтобы
каждого клиента подсчитать ровно один раз (повторы исключаются).
Пример 3.22. Запрос с группировкой
В некоторых запросах можно сгруппировать строки, имеющее
одинаковое значение в одном или нескольких столбцах. Одна такая
группа формируется на каждое значение заданного столбца. Затем к
группе можно применить статистические функции.
Вывести общее количество заказанного товара по каждому
клиенту.
"G." обозначается столбец, по которому производится
группировка. В нашем случае, группировка проводится по
CUST_NUM, т. к. мы хотим подсчитать общее количество товара по
каждому клиенту. Затем используется целевая таблица, задающая
вывод столбца, по которому производится группировка и значений
функций, примененных к группам (рис. 37)
ORDERS ORDER_NUM
P.
CUST_NUM
G._CN
_CN
PROD_ID
QTY
_QT
DATE_ORDER
SUM.QT
Рис. 37. Запрос с группировкой
Результат:
CUST_NUM
QTY
3101
3105
3106
3104
3103
3102
3108
27
57
16
10
35
21
16
3107
10
Пример 3.23. Запрос с группировкой и условием
Вывести номера клиентов, сделавших более одного заказа
(рис. 38).
ORDERS ORDER_NUM
_ON
P.
_CN
CUST_NUM
G._CN
PROD_ID
QTY
DATE_ORDER
CNT._ON >1
Рис. 38. Запрос с группировкой и условием
Результат:
CUST_NUM
3101
3103
3105
В отличие от рассмотренных операций, операции вставки,
удаления и модификации приводят к изменению исходной таблицы.
Вид операции (вставка – I., удаление – D., модификация – U.)
записывается в шаблоне под именем таблицы, а константы и
условные выражения указываются по тем же правилам, что и в
операциях выборки.
Пример 3.24. Вставка данных в таблицу
Вставка в таблицу ORDERS нового заказа может выглядеть
следующим образом (рис. 39):
ORDERS ORDER_NUM
I.
232
CUST_NUM
3109
PROD_ID
4V
QTY
20
DATE_ORDER
9.03.03
Рис. 39. Вставка строки в таблицу
Пример 3.25. Удаление информации из таблицы
Пусть необходимо удалить информацию о заказах клиента 3105
(рис. 40).
ORDERS ORDER_NUM
D..
CUST_NUM
3105
PROD_ID
QTY
Рис. 40. Удаление данных о клиенте
DATE_ORDER
Из таблицы ORDERS удаляется вся информация о клиенте 3105.
Пусть необходимо удалить информацию о заказах, сделанных до
17.01.03. Шаблон запроса выглядит следующим образом (рис. 41):
ORDERS ORDER_NUM
D.
CUST_NUM
PROD_ID
QTY
DATE_ORDER
< '17.01.03'
Рис. 41. Удаление данных о заказах
Пример 3.26. Изменение данных
Для изменения цены процессора Athlon XP 2600+ нужно
сформировать запрос (рис. 42).
PROD
PROD_ID
PROD_NAME
PRICE
STORE
Процессор Athlon XP 130
2600+
U.
Рис. 42. Изменение данных
Пример 3.27. Изменение данных с вычислениями
Для того, чтобы повысить цену всех товаров на 5% можно
сформировать запрос на изменение информации (рис. 43).
PROD
U.
PROD_ID
PROD_NAME
PRICE
STORE
1.05*_K
_K
Рис. 43. Изменение данных с вычислениями
Современные СУБД имеют незначительные изменения от
классического варианта QBE в интерпретации отдельных операций,
введению дополнительных операций и изменению формы
представления языка.
3.3.4. Структурированный язык запросов SQL
SQL (Structured Query Language) – структурированный язык
запросов – является инструментом, предназначенным для выборки и
обработки информации, содержащейся в компьютерной базе данных.
SQL является языком программирования, применяемым для
организации взаимодействия пользователя с базой данных (рис. 44).
SQL работает только с реляционными базами данных и предоставляет
пользователю следующие функциональные возможности:
 изменение структуры представления данных;
 выборка данных из базы данных;
 обработка базы данных, т. е. добавление новых данных,
изменение, удаление имеющихся данных;
 управление доступом к базе данных;
 совместное использование базы данных пользователями,
работающими параллельно;
 обеспечение целостности базы данных.
Пользователь составляет
SQL-ЗАПРОС на выборку
данных
СУБД
Обрабатывает
запрос
Требуемые ДАННЫЕ
отправляются
пользователю
База
данных
Рис. 44. Доступ к БД с помощью SQL
SQL – это не полноценный компьютерный язык типа PASCAL,
C++, JAVA. Еще раз отметим, что SQL, также как и QBE, является
непроцедурным языком. С помощью SQL описываются свойства и
взаимосвязи сущностей (объектов, переменных и т. п. ), но не
алгоритмы решения задачи. Он не содержит условных операторов,
операторов цикла, организации подпрограмм, ввода-вывода и т. п. В
связи с этим SQL автономно не используется. Инструкции SQL
встраиваются в программу, написанную на традиционном языке
программирования и дают возможность получить доступ к базам
данных (встроенный SQL). Кроме того, из таких языков, С, C++,
JAVA инструкции SQL можно посылать СУБД в явном виде,
используя интерфейс вызовов функций.
Язык SQL является многофункциональным языком. Во-первых,
SQL используется в качестве языка интерактивных запросов
пользователей с целью выборки данных и в качестве встроенного
языка программирования баз данных. Кроме того, SQL используется в
качестве языка администрирования БД для определения структуры
базы данных и управления доступом к данным, находящимся на
сервере; в качестве языка создания приложений клиент/сервер,
доступа к данным в среде Internet, распределенных баз данных.
С помощью SQL можно динамически изменять и расширять
структуру базы данных даже в то время, когда пользователи работают
с ее содержимым. Таким образом, SQL обеспечивает максимальную
гибкость. Статические языки определения данных запрещают доступ
к БД во время изменения ее структуры
Официальный стандарт языка SQL был опубликован ANSI и ISO
в 1986 г. В дальнейшем, он был расширен стандартами SQL-89 (1989
г.) и SQL-92 (1992 г.). Действующая версия стандарта SQL:1999 была
принята ANSI и ISO в конце 1999 г. В настоящее время ведется
работа над стандартом для SQL3, содержащим объектноориентированные расширения.
Кроме перечисленных выше версий языка SQL для
универсальных ЭВМ существует множество версий типа "клиентсервер", а также версий SQL для персональных компьютеров.
Основные инструкции языка SQL
Основные задачи, решаемые средствами языка SQL –
манипулирование различными объектами базы данных (таблицами,
индексами, представлениями и т. д.) и манипулирование данными,
хранящимися в таблицах базы данных. В связи с этим, язык SQL
принято делить на две части: язык определения данных DDL и язык
манипулирования данными DML. Основные инструкции языка SQL
представлены в табл. 9.
При описании синтаксиса инструкций будем использовать
следующие правила:
 каждая инструкция начинается с команды – ключевого слова,
описывающего действие, выполняемое инструкцией (например,
CREATE – создать, DELETE – удалить и т. д.);
 после команды следует одно или несколько предложений,
описывающих данные, с которыми работает инструкция, или
содержащих дополнительную информацию о действии, выполняемом
инструкцией. Каждое предложение начинается с ключевого слова,
например, WHERE (где), FROM (откуда), INTO (куда), HAVING
(имеющий);
 в квадратные скобки "[…]" заключены необязательные
элементы;
 вертикальная черта "|" , разделяющая два элемента, указывает
на то, что в инструкции используется либо один элемент, либо
второй;
 в
фигурные
скобки
"{…}"заключаются
элементы,
разделенные вертикальной чертой;
 троеточие означает, что далее в инструкции либо следует
выражение, либо повторяются элементы, указанные перед тремя
точками.
Таблица 9
Инструкции языка SQL
Вид
Название
Назначение
CREATE TABLE
Добавление новой таблицы в БД
DROP TABLE
Удаление таблицы
ALTER TABLE
Изменение структуры таблицы
CREATE INDEX
Создание индекса для столбца
DDL
DROP INDEX
Удаление индекса столбца
CREATE VIEW
Создание нового представления
DROP VIEW
Удаление представления
GRAND
Назначение привилегий доступа
пользователей к БД
REVOKE
Удаление привилегий
CREATE SCHEMA Добавление новой схемы в БД
DROP SCHEMA
Удаление схемы
SELECT
Выборка данных из таблицы
UPDATE
Обновление данных в таблице
DML
INSERT
Вставка новых строк в таблицу
DELETE
Удаление строк из таблицы
Рассмотрим основные инструкции языка SQL.
Инструкция создания таблицы имеет формат вида:
CREATE TABLE <имя таблицы>
(<имя столбца> <тип данных> [NOT NULL]
[,<имя столбца> <тип данных> [NOT NULL]]... )
После выполнения инструкции появляется новая таблица,
которой присваивается имя, указанное в инструкции. Имя таблицы
(как и имена других объектов – столбцов и пользователей) согласно
стандарту ANSI/ISO должны содержать от 1 до 18 символов,
начинаться с буквы и не содержать пробелов или специальных
символов пунктуации (на практике поддержка имен в различных
СУБД реализована по-разному).
Обязательными операндами данной инструкции являются имя
создаваемой таблицы и имя хотя бы одного столбца с указанием типа
данных, хранимых в этом столбце. SQL поддерживает различные
типы данных: целые числа, числа с плавающей запятой, строки
символов, значения даты и времени и др. В общем случае в
современных СУБД могут использоваться самые разнообразные
дополнительные типы данных, расширяющие базовый набор SQL.
При создании таблицы для отдельных столбцов могут
указываться некоторые дополнительные правила контроля вводимых
в них значений. Конструкция – NOT NULL (не пустое) служит
именно таким целям и для столбца таблицы означает, что в этом
столбце должно быть непустое (определенное) значение.
Пример 3.28. Создание таблицы
Пусть требуется определить таблицу ORDERS и ее столбцы.
Инструкция для определения таблицы может иметь следующий вид:
CREATE TABLE ORDERS (ORDER_NUM INTEGER NOT
NULL, CUST_NUM INTEGER NOT NULL, PROD_ID INTEGER
NOT NULL, QTY INTEGER NOT NULL, DATE_ORDER DATE
NOT NULL)
где INTEGER обозначает тип данных целое число, а DATE – тип
данных, обозначающих значения даты.
В процессе работы у пользователей возникает необходимость
добавить в таблицу информацию. Инструкция изменения структуры
таблицы имеет формат вида:
ALTER TABLE <имя таблицы>
{ADD|ALTER|DROP} <имя столбца> [<тип данных>]
[NOT NULL]
[,{ADD|ALTER|DROP} <имя столбца> [<тип данных>]
[NOT NULL],..]
Изменение структуры таблицы может состоять в добавлении
(ADD), изменении (ALTER) или удалении (DROP) одного или
нескольких столбцов таблицы.
Пример 3.29. Добавление столбца таблицы
Добавим в созданную ранее таблицу CUST столбец CUST_PHN,
содержащий телефоны клиентов. Для этого следует записать
инструкцию вида:
ALTER TABLE CUST ADD CUST_PHN CHAR (10)
Пример 3.30. Удаление столбца
Удалим из таблицы PROD столбец STORE.
рассматриваются без учета ограничений целостности).
ALTER TABLE PROD DROP STORE
(Примеры
Инструкция удаления таблицы имеет формат вида:
DROP TABLE <имя та6лицы>
Например, для удаления таблицы с именем SALE достаточно
записать оператор вида:
DROP TABLE SALE
Одним из структурных элементов физической памяти является
индекс. Индекс – это средство, обеспечивающее быстрый доступ к
строкам таблицы на основе значений одного или нескольких
столбцов. В индексе хранятся значения данных и указатели на строки,
где эти данные встречаются. Данные в индексе располагаются в
убывающем или в возрастающем порядке, чтобы СУБД могла быстро
найти требуемое значение. Затем по указателю СУБД сможет быстро
определить строку, содержащую требуемое значение. Инструкция
создания индекса имеет формат вида:
CREATE [UNIQUE] INDEX <имя индекса> ОN <имя
таблицы> (<имя столбца> [ ASC| DESC]
[,<имя столбца> [ASC| DESC],... )
Оператор позволяет создать индекс для одного или нескольких
столбцов заданной таблицы с целью ускорения выполнение
запросных и поисковых операций с таблицей. Для одной таблицы
можно создать несколько индексов.
Необязательная опция UNIQUE обеспечивает запрет задания
совпадающих значений для индекса. По существу, создание индекса с
указанием признака UNIQUE означает определение ключа в
созданной ранее таблице.
При создании индекса можно задать порядок автоматической
сортировки значений в столбцах – в порядке возрастания ASC (по
умолчанию), или в порядке убывания DESC. Для разных столбцов
можно задавать различный порядок сортировки.
Пример 3.31. Создание индекса
Пусть из таблице CUST часто извлекаются данные по названию
фирм-клиентов. Можно создать индекс main_index для сортировки
названий фирм-клиентов в алфавитном порядке по возрастанию.
Оператор создания индекса может иметь вид:
CREATE INDEX main_index ON CUST (CUST_NAME)
Инструкция удаления индекса имеет формат вида:
DROP INDEX<имя индекса>
Эта инструкция позволяет удалять созданный ранее индекс с
соответствующим именем. Так, например, для уничтожения индекса
main_index к таблице CUST достаточно записать инструкцию DROP
INDEX main_index.
Кроме таблиц и индексов существуют другие объекты базы
данных, например, представления. Представление является
"виртуальной" таблицей, содержащей набор столбцов одной или
нескольких таблиц. Однако, в отличие от таблицы, представление как
совокупность значений в базе данных реально не существует.
Представление определяется как запрос на выборку данных, которому
присвоили имя и сохранили в базе данных. Представление позволяет
пользователю увидеть результаты сохраненного запроса.
Инструкция создания представления имеет формат вида:
CREATE VIEW<имя представления>
[(<имя столбца> [,<имя столбца> ]…)]
AS <оператор SELECT>
При необходимости можно задать имя для каждого столбца
создаваемого представления. Список имен столбцов должен
содержать столько элементов, сколько столбцов содержится в
запросе. Если список имен в инструкции отсутствует, то каждый
столбец представления получает имя соответствующего столбца
запроса.
Пример 3.32. Создание представления
Необходимо создать представление c именем CUSTINF таблицы
CUST, включающее только названия клиентов и их номера.
CREATE VIEW CUSTINF
AS SELECT CUST_NUM, CUST_NAME
FROM CUST
Создать представление ORDER_CUS, показывающее заказы
сделанные клиентом 3105.
CREATE VIEW ORDER_CUS
AS SELECT
FROM ORDERS
WHERE CUST_NUM=3105
Инструкция удаления представления имеет формат вида:
DROP VIEW <имя представления>
Оператор позволяет удалить созданное ранее представление.
Заметим, что при этом таблицы, участвующие в запросе, удалению не
подлежат. Удаление представления ORDER_CUS производится
инструкцией вида:
DROP VIEW ORDER_CUS
Представления широко применяются для ограничения доступа
пользователей ко всей информации в таблицах базы данных.
Пример 3.33. Использование инструкции GRAND и REVOKE
Можно определить права доступа к таблицам базы данных с
помощью инструкций GRAND и REVOKE. Например, инструкция
GRAND INSERT
ON CUST
TO PETROV
разрешает сотруднику Петрову ввод данных в таблицу CUST.
Следующая инструкция отменяет привилегии сотрудника
Иванова на изменение данных о клиентах и чтение информации о них
REVOKE UPDATE, SELECT
ON CUST
TO IVANOV
Запросы являются фундаментом SQL. Многие разработчики
используют SQL исключительно в качестве инструмента для создания
запросов. Поэтому важнейшей инструкцией является инструкция
SELECT, которая используется для построения SQL-запросов:
SELECT [ALL | DISTINCT]<список данных>
FROM <список таблиц>
[WHERE <условие отбора>]
[GROUP BY <имя столбца> [,<имя столбца>]... ]
[HAVING <условие поиска>]
[ORDER BY <спецификация> [,<спецификация>]...]
Оператор SELECT позволяет производить выборку и вычисления
над данными из одной или нескольких таблиц. В предложении
SELECT указывается список возвращаемых столбцов, разделенных
запятыми. Для каждого элемента из списка в ответной таблице будет
создан один столбец. Ответная таблица может иметь (ALL), или не
иметь (DISTINCT) повторяющиеся строки. По умолчанию в ответную
таблицу включаются все строки, в том числе и повторяющиеся.
Список данных может содержать выражения над столбцами,
показывающие, что наряду с выборкой данных выполняются
вычисления, результаты которого попадают в новый (создаваемый)
столбец ответной таблицы
В отборе данных участвуют записи одной или нескольких
таблиц, перечисленных в списке предложения FROM. Такие таблицы
называют исходными таблицами запроса.
При использовании в списках данных имен столбцов нескольких
таблиц для указания принадлежности столбца некоторой таблице
применяют конструкцию вида: <имя таблицы>.<имя столбца>.
Предложение WHERE задает условия, которым должны
удовлетворять строки в результирующей таблице. Вслед за ключевым
словом WHERE указывается логическое выражение <условие
отбора>. Его элементами могут быть имена столбцов, операции
сравнения, арифметические операции, логические операции (И, ИЛИ,
НЕТ), скобки, специальные функции LIKE и т.д.
Предложение GROUP BY содержит список столбцов, которые
используются для группировки строк. Группой называются строки с
совпадающими значениями в столбцах, перечисленных за ключевыми
словами GROUP BY. Для сгруппированных данных можно
использовать статистические функции: AVG (среднее значение в
группе), МАХ (максимальное значение в группе), MIN (минимальное
значение в группе), SUM (сумма значений в группе), COUNT (число
значений в группе).
Вслед за предложением HAVING указывается логическое
выражение <условия поиска>, определяющее, какие из отобранных и
сгруппированных строк будут отображаться в результирующем
наборе данных. Правила записи аналогичны правилам формирования
<условия отбора> предложения WHERE.
Предложение ORDER BY задает порядок сортировки
результирующего множества строк. Обычно каждая <спецификация>
аналогична соответствующей конструкции оператора CREATE
INDEX и представляет собой конструкцию вида: <имя столбца> [
ASC | DESC].
Пример 3.34. Выбор строк
Пусть требуется вывести названия товаров и их цену.
Инструкцию выбора можно записать следующим образом:
SELECT PROD_NAME, PRICE
FROM PROD
Пример 3.35. Выбор с условием
Вывести названия товаров, цена которых больше
Инструкцию SELECT для этого запроса можно записать так:
SELECT PROD_NAME
FROM PROD
WHERE PRICE>100
100$.
Пример 3. 36. Выбор с сортировкой
Строки результатов запроса, как и строки таблицы базы данных,
не имеют определенного порядка. Включив в инструкцию SELECT
предложение ORDER BY, можно отсортировать результаты запроса.
Пусть требуется вывести название клиентов и годовой объем
заказов. Последний столбец отсортировать по возрастанию. По
умолчанию данные сортируются по возрастанию.
SELECT CUST_NAME, CUST_SUM
FROM CUST
ORDER BY CUST_SUM
Пример 3.37. Получение итоговых данных
Каков средний объем заказов?
Этот запрос обеспечивает вычисление среднего объема заказов,
используя данные из таблицы CUST
SELECT AVG (CUST_SUM)
FROM CUST
Пример 3.38. Вычисляемые столбцы
Например, требуется вычислить стоимость остатков товара,
хранящихся на складе. Данные вывести по каждому товару. Значения
вычисляемых столбцов определяются на основе выражения,
указанного в списке возвращаемых столбцов.
SELECT PROD_NAME, PRICE, STORE, (PRICE* STORE)
FROM PROD
Пусть требуется увеличить цену каждого товара на 5%. Запрос
можно сформулировать следующим образом:
SELECT PROD_NAME, PRICE, (PRICE*1.05)
FROM PROD
Во многих СУБД реализованы дополнительные арифметические
операции, операции над строками, встроенные функции для работы
со значениями даты и времени.
Например, требуется вывести номер заказа, месяц и год его
поставки. Запрос выглядит следующим образом:
SELECT ORDER_NUM, MONTH (DATE_ORDER), YEAR
(DATE_ORDER)
FROM ORDERS
Пример 3.39. Выбор всех столбцов
Иногда требуется получить содержимое всех столбцов таблицы.
С учетом этого в SQL разрешается использовать вместо списка
возвращаемых столбцов символ "*".
SELECT *
FROM ORDERS
Пример 3.40. Повторяющиеся строки
Результаты запроса могут содержать повторяющиеся строки.
Например, требуется вывести номера клиентов, сделавших заказы, из
таблицы ORDERS. Клиенты 3101, 3105, 3103 сделали более, чем по
одному заказу, поэтому строки с их номерами будут повторяться. Для
исключения повторяющихся строк используется предикат DISTINCT.
SELECT DISTINCT CUST_NUM
FROM ORDERS
Пример 3.41. Выбор с группированием
Пусть требуется найти минимальное и максимальное заказанное
количество для каждого из видов товаров. Оператор SELECT для
этого запроса имеет вид:
SELECT PROD_ID, MIN (QTY ), MAX (QTY )
FROM ORDERS
GROUP BY PROD_ID
Запрос выполняется следующим образом: заказы делятся на
группы, по одной группе на каждый товар. Затем для каждой группы
вычисляется максимальное и минимальное значения столбца QTY по
всем строкам, входящим в группу, и генерируется одна итоговая
строка результатов.
Пример 3.42. Условия отбора групп
Предложение HAVING можно использовать для отбора групп
строк, участвующих в запросе. Пусть требуется найти максимальное
заказанное количество каждого товара. Общее количество
заказанного товара не должно превышать 20.
SELECT PROD_ID, MAX (QTY )
FROM ORDERS
GROUP BY PROD_ID
HAVING SUM (QTY )<=20
При реализации данного запроса, вначале заказы разделяются на
группы по видам товаров. Затем исключаются те группы, в которых
общее количество заказанного товара превышает 20. И после этого в
оставшихся группах определяется максимальное заказанное
количество каждого товара.
Пример 3.43. Многотабличные запросы
На практике, многие запросы считывают информацию сразу из
нескольких таблиц базы данных. Например, необходимо вывести
список всех заказов, а также название клиента, сделавшего заказ.
Инструкция SELECT должна содержать условие отбора, которое
определяет связь между столбцами таблиц ORDERS и CUST.
SELECT ORDER_NUM, CUST_NAME, PROD_ID, QTY,
DATE_ORDER
FROM ORDERS, CUST
WHERE CUST.CUST_NUM=ORDERS.CUST_NUM
Приведенный запрос отличается от предыдущих, во-первых, тем,
что предложение FROM содержит не одну, а две таблицы. Во-вторых,
в условии отбора WHERE CUST.CUST_NUM=ORDERS.CUST_NUM
сравниваются столбцы из двух различных таблиц. Эти столбцы
называются связанными.
В данном примере, столбцы, используемые из разных таблиц,
имеют одинаковые имена. В этом случае необходимо указывать
полные имена столбцов, которые однозначно определяют их
местонахождение.
Инструкция на изменения строк имеет формат вида:
UPDATE <имя таблицы>
SET <имя столбца> = {<выражение> | NULL}
[,SET <имя столбца> = {<выражение> | NULL}... ]
[WHERE <условие>]
Инструкция UPDATE обновляет значения в определенных
предложением SET столбцах таблицы для тех строк, которые
удовлетворяют условию, заданному предложением WHERE.
Новые значения столбцов могут быть пустыми (NULL), либо
вычисляться в соответствии с арифметическим выражением.
Пример 3.44. Изменение строк
Пусть необходимо увеличить на 15% цену только тех товаров,
которые стоят меньше 100$. Запрос, сформулированный с помощью
оператора UPDATE, может выглядеть так:
UPDATE PROD
SET PRICE=( PRICE*1.15)
WHERE PRICE <=100
Инструкция для вставки новых строк имеет форматы двух
видов:
INSERT INTO <имя таблицы> [(<список столбцов>)]
VALUES (<список значений>)
и
INSERT INTO <имя таблицы> [(<список столбцов>)]
<предложение SELECT>
В первом формате оператор INSERT предназначен для одной
строки с заданными значениями в столбцах. Порядок перечисления
имен столбцов должен соответствовать порядку значений,
перечисленных в списке предложения VALUES. Если <список
столбцов> опущен, то в <списке значений> должны быть
перечислены все значения в порядке столбцов структуры таблицы.
Во втором формате оператор INSERT предназначен для ввода в
заданную таблицу новых строк, отобранных из другой таблицы с
помощью предложения SELECT.
Пример 3.45.
Ввести в таблицу CUST строку, содержащую сведения о новом
клиенте. Для этого можно записать инструкцию такого вида:
INSERT INTO CUST
VALUES ("3110", "ЧП Иванов П.Т.", NULL)
Пример 3.46.
Требуется скопировать в новую таблицу OLDORDERS сведения
о старых заказах.
INSERT INTO OLDORDERS (ORDER_NUM, CUST_NUM,
PROD_ID, QTY, DATE_ORDER)
SELECT ORDER_NUM, CUST_NUM, PROD_ID, QTY,
DATE_ORDER
FROM ORDERS
WHERE DATE_ORDER< '17.01.03'
Инструкция удаления строк имеет формат вида:
DELETE FROM <имя таблицы> [WHERE <условие>]
Результатом выполнения оператора DELETE является удаление
из указанной таблицы строк, которые удовлетворяют условию,
определенному предложением WHERE. Если необязательный
операнд WHERE опущен, т. е. условие отбора удаляемых записей
отсутствует, удалению подлежат все записи таблицы.
Пример 3.47. Удаление строк
Удалить из таблицы ORDERS сведения о старых заказах.
DELETE FROM ORDERS
WHERE DATE_ORDER<'17.01.03'
Подробнее с возможностями SQL можно ознакомиться в
специальной литературе по базам данных, или в документации
конкретной СУБД.
3.4. Проектирование реляционных баз данных
При проектировании реляционной базы данных разработчику
необходимо решить вопрос о наиболее эффективной структуре
данных. Основная цель проектирования БД – это сокращение
избыточности хранимых данных, а следовательно, экономия объема
используемой памяти, уменьшение затрат на многократные операции
обновления избыточных копий и устранение возможности
возникновения противоречий из-за хранения в разных местах
сведений об одном и том же объекте.
Проектирование должно быть эффективным, т. е. обеспечивать
минимальное дублирование данных, удобство их обработки и
обновления. Для удовлетворения этих требований необходимо
определить, из каких отношений должна состоять БД, какие атрибуты
должны входить в эти отношения.
Например, рассмотрим отношение R (табл. 10).
Таблица 10
Отношение R
Код_материала Наименование
Тип
Код_модели
101
Ткань пальтовая п/ш
312
"Ассоль"
101
Ткань пальтовая п/ш
512
"Ассоль"
210
Ткань
п/э
312
подкладочная
"Фея"
210
Ткань
п/э
512
подкладочная
"Фея"
210
Ткань
п/э
460
подкладочная
"Фея"
210
Ткань
п/э
430
подкладочная
"Фея"
315
Драп пальтовый ч/ш
460
"Бриз"
Можно заметить, что таблица спроектирована не совсем удачно.
В четырех кортежах, соответствующих материалу с кодом 210
повторяется одна и та же информация о наименовании и типе ткани.
Проблема возникает из-за того, что одна и та же ткань может
использоваться в разных моделях. Такое дублирование данных
называется избыточностью данных. Избыточность данных вызывает
нежелательные явления, возникающие в процессе работы с базой
данных, называемые аномалиями.
Предположим, что тип ткани подкладочной "Фея" указан
неправильно. Тогда необходимо внести изменения не в один кортеж,
а во все четыре (представьте, сколько может быть кортежей в
реальной БД!). Такая ситуация , при которой изменение значения
одного данного, может повлечь за собой просмотр и редактирование
нескольких строк таблицы, называется аномалией модификации
(редактирования).
Далее предположим, что ткани подкладочной в течение какоголибо времени не было на складе и модели, в которых она должна
была участвовать уже пошиты. Если принимается решение об
удалении всех сведений о пошитых моделях, то информация о
подкладочной ткани тоже утрачивается. Ситуация, заключающаяся в
том, что при удалении каких-либо данных из таблицы может
исчезнуть и информация, напрямую не связанная с удаляемой,
называется аномалией удаления.
Возможна и другая ситуация: приобретена ткань, но пока еще не
решено, в какой модели она будет участвовать. Поэтому, если мы
хотим избежать пустых (неопределенных) значений в кортежах,
информацию о ней мы не можем ввести в таблицу. Такая ситуация,
при которой невозможно ввести одни данные из-за отсутствия других
данных, называется аномалией ввода.
Избавится от избыточности данных позволяет нормализация базы
данных. Нормализация – это процесс преобразования отношения
путем декомпозиции (разбиения) его на два или более отношений,
имеющих лучшие свойства. Окончательная цель нормализации
сводится к получению такого проекта базы данных, в котором
каждый факт появляется лишь в одном месте, т. е. исключена
избыточность информации.
Нормализации – это классический метод проектирования
реляционной базы данных. Исходной точкой здесь является
представление предметной области в виде одного или нескольких
отношений, и на каждом шаге проектирования производится
некоторый набор схем отношений, обладающих лучшими
свойствами. Процесс проектирования представляет собой процесс
нормализации схем отношений, причем каждая следующая
нормальная форма обладает лучшими свойствами по сравнению с
предыдущей.
Каждой нормальной форме соответствует некоторый набор
ограничений. Отношение находится в определенной нормальной
форме, если оно удовлетворяет набору ограничений этой формы.
Основные свойства нормальных форм:
 каждая следующая нормальная форма в некотором смысле
лучше предыдущей;
 при переходе к следующей нормальной форме свойства
предыдущих нормальных форм сохраняются.
В теории реляционных баз данных обычно выделяется
следующая последовательность нормальных форм:
 первая нормальная форма (1NF);
 вторая нормальная форма (2NF);
 третья нормальная форма (3NF);
 нормальная форма Бойса-Кодда (BCNF);
 четвертая нормальная форма (4NF);
 пятая нормальная форма, или нормальная форма проекциисоединения (5NF или PJ/NF).
Процесс нормализации основан на понятии функциональной
зависимости. Функциональные зависимости позволяют накладывать
определенные ограничения на реляционную схему. Идея состоит в
том, что значение одного атрибута в кортеже определяет значение
другого атрибута. Например, в каждом кортеже отношения R
Код_материала
определяет
Наименование;
Код_материала
определяет Тип (табл. 11). Можно записать функциональные
зависимости:
Код_материала Наименование
Код_материала Тип
Для дальнейшего изложения нам потребуется несколько
определений.
Определение 1. Функциональная зависимость
Пусть A и B – атрибуты в отношении R. Атрибут В
функционально зависит от атрибута А, если в любой момент времени
каждому значению атрибута А соответствует в точности одно
значение атрибута В. Функциональная зависимость записывается
следующим образом: AB. Данная запись означает, что если два
кортежа в таблице R имеют одно и тоже значение атрибута A, то они
имеют одно и тоже значение атрибута B. Атрибут в левой части
называется детерминантом, т.к. его значение определяет значение
атрибута в правой части. Ключи таблицы являются детерминантами.
Определение 2. Неключевой атрибут
Неключевым атрибутом называется любой атрибут отношения,
не входящий в состав первичного ключа
Определение 3. Полная функциональная зависимость
Функциональная зависимость называется
полной, если
неключевой атрибут зависит от всего составного ключа и не зависит
от его частей.
Определение 4. Транзитивная функциональная зависимость
Если атрибут B функционально зависит от атрибута A (AB), а
атрибут C функционально зависит от атрибута B (BC), но обратная
зависимость отсутствует, то говорят, что атрибут С зависит от А
транзитивно.
Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из
этих атрибутов не является функционально зависимым от других.
Определение 6. Отношение находится в первой нормальной
форме (1NF), если значения его атрибутов атомарны. Исходное
отношение строится таким образом, чтобы оно было в 1NF.
Определение 7. Отношение находится во второй нормальной
форме (2NF), если выполняются ограничения первой нормальной
формы и каждый неключевой атрибут функционально полно зависит
от всего первичного ключа.
Определение 8. Отношение находится в третьей нормальной
форме (3NF), если выполняются ограничения второй нормальной
формы и все неключевые атрибуты взаимно независимы и полностью
зависят от первичного ключа (т. е. в отношении отсутствуют
транзитивные зависимости неключевых атрибутов от первичного
ключа).
Проектирование базы данных рассмотрим на следующем
примере. Пусть имеются сведения о поставках некоторой фирмой
материалов. Сформируем исходное отношение Поставки (табл. 11).
Таблица 11
Таблица Поставки
Код_заказа
1
110
110
120
120
Код_материала
2
21
30
13
15
1
120
120
130
130
130
140
140
150
150
160
160
Код_клиента
3
BN
BN
BR
BR
2
16
18
20
55
71
2
62
31
70
30
69
3
BR
BR
BR
BR
BR
BS
BS
BN
BN
AN
AN
Город клиента
4
Омск
Омск
Москва
Москва
4
Москва
Москва
Москва
Москва
Москва
Тюмень
Тюмень
Омск
Омск
Улан-Удэ
Улан-Удэ
Количес
тво
5
300
200
160
150
80
250
120
200
300
300
90
60
20
50
10
Дата
поставки
6
25.07.02
25.07.02
12.08.02
12.08.02
Окончание табл. 11
5
6
12.08.02
12.08.02
14.08.02
14.08.02
14.08.02
26.08.02
26.08.02
4.09.02
4.09.02
18.09.02
18.09.02
В качестве первичного ключа выберем составной ключ
Код_заказа-Код_материала, однозначно определяющий каждый
кортеж отношения. Данное отношение находится в 1NF, т. к. все
значения столбцов являются атомарными. Эта таблица содержит
избыточные данные. например, одни и те же сведения о клиенте
повторяются в записи о каждом заказанном материале. Результатом
избыточности являются следующие аномалии:
 адрес клиента можно ввести в базу данных тогда, когда он
заказал хотя бы одну ткань;
 при удалении записи о заказанной ткани одновременно
удаляются сведения о заказе и клиенте, его разместившем;
 при смене адреса клиента, необходимо обновлять все записи и
заказанных им материалах.
Напомним, что отношение находится во второй нормальной
форме, если оно находится в первой нормальной форме и его
неключевые атрибуты полностью зависят от всего первичного ключа.
В таблице Поставки неключевые атрибуты Код_клиента,
Город_клиента, Дата поставки зависят от атрибута Код_заказа,
являющегося частью составного ключа. Поэтому отношение
Поставки не соответствует второй нормальной форме.
Для того чтобы перейти от первой ко второй нормальной форме,
необходимо выполнить следующие шаги:
 определить, на какие части можно разбить первичный ключ,
так, чтобы некоторые из неключевых атрибутов функционально
полно зависели от одной из этих частей;
 создать новое отношение для каждой такой части ключа и
группы зависящих от нее атрибутов и переместить их в это
отношение (т. е. построить проекции на части составного первичного
ключа и атрибуты, зависящие от этих частей). Часть бывшего ключа
станет при этом первичным ключом нового отношения;
 удалить из исходной таблицы атрибуты, перемещенные в
другие отношения, кроме тех из них, которые станут внешними
ключами (построить проекцию без атрибутов, находящихся в
частичной функциональной зависимости от первичного ключа).
Для приведения исходной таблицы ко второй нормальной форме
поля Код_заказа, Код_клиента, Город_клиента, Дата_поставки
перемещаются в новую таблицу Поставки1, при этом Код_заказа –
первичный ключ новой таблицы.
Вторая таблица Заказы будет содержать составной первичный
ключ Код_заказа-Код_материала и поле Количество.
В результате новые таблицы будут выглядеть следующим
образом (табл. 12-13):
Таблица 12
Таблица 13
Поставки1
Код_заказа
Код_кли- Город
ента
клиента
110
120
130
140
150
160
BN
BR
BR
BS
BN
AN
Омск
Москва
Москва
Тюмень
Омск
Улан-Удэ
Заказы
Дата
поставки
Код_заказа
Код_материала
Количество
25.07. 02
12.08. 02
14.08. 02
26.08. 02
4.09.02
18.09. 02
110
110
120
120
120
120
130
130
130
140
140
150
150
160
21
30
13
15
16
18
20
55
71
2
62
31
70
69
300
200
160
150
80
250
120
200
300
300
90
60
20
10
160
30
50
Проанализируем полученные таблицы. В таблице Заказы не
наблюдается явная избыточность данных. Однако для таблицы
Поставки1 можно указать следующие аномалии:
 адрес конкретного клиента может содержаться в базе только
тогда, когда есть заказы;
 удаление сведений о заказе в таблице Поставки1 приведет к
удалению сведений о клиентах;
 при изменении адреса заказчика придется обновить все
кортежи в таблице Поставки1.
Устранить эти аномалии позволяет третья нормальная форма.
Считается, что таблица соответствует третьей нормальной форме,
если она находится во второй нормальной форме и ее неключевые
атрибуты взаимно независимы и зависят только от первичного ключа.
В отношении Поставки1 существует транзитивная зависимость
между неключевыми атрибутами Город_клиента и Код_клиента
(Код_клиента  Город_клиента).
Для перехода от второй нормальной формы к третьей
необходимо исключить транзитивные зависимости. Для этого
требуется выполнить следующие шаги:
 определить все атрибуты (или группы атрибутов), от которых
зависят другие атрибуты (выявить транзитивные зависимости);
 создать новое отношение для каждого такого атрибута и для
группы зависящих от него атрибутов и переместить их в это
отношение (т. е. построить проекцию отношения на атрибуты,
являющиеся причиной транзитивной зависимости). Атрибут, от
которого зависят все остальные перемещенные атрибуты, станет при
этом первичным ключом нового отношения;
 удалить перемещенные атрибуты из исходного отношения,
оставив лишь те, которые станут внешними ключами .
Для приведения таблицы Поставки1 к третьей нормальной
форме создадим новую таблицу Клиенты (табл. 14) и переместим в
нее
атрибуты
Код_клиента
и
Город_клиента.
Атрибут
Город_клиента из таблицы Поставки1 удалим, а атрибут
Код_клиента оставим в качестве внешнего ключа (табл. 16). Таблицу
Заказы оставим без изменения (табл. 15).
Таблица 14
Таблица 15
Клиенты
Заказы
Код_клиента
Город
клиента
BN
BR
BS
AN
Омск
Москва
Тюмень
Улан-Удэ
Код_заказа
Код_материала
Количест
во
1
2
3
110
110
120
21
30
13
120
120
15
150
16
80
Окончание табл. 15
2
3
18
250
20
120
55
200
71
300
2
300
62
90
31
60
70
20
69
10
30
50
1
120
130
130
130
140
140
150
150
160
160
300
200
160
Таблица 16
Поставки 2
Код_заказа
110
120
130
140
150
160
Код_клиента
BN
BR
BR
BS
BN
AN
Дата_поставки
25.07.02
12.08.02
14.08.02
26.08.02
4.09.02
18.09.02
На практике, в большинстве случаев процесс проектирования
заканчивается построением третьей нормальной формы. Например,
для нашего примера, после проведения нормализации можно
заметить следующие улучшения:
 сведения о клиенте можно хранить, если клиент не сделал ни
одного заказа;
 сведения о заказанном материале можно удалить, не опасаясь
удаления данных о клиенте и заказе;
 изменение адреса клиента или даты регистрации заказа теперь
требуют изменения только одной записи.
Существуют нормальные формы более высокого порядка.
Подробнее с технологией нормализации можно ознакомиться в
литературе по теории реляционных баз данных [5, 8, 10, 14, 18–20,
26–29, 31].
Контрольные вопросы и задания
1. Привести различия между иерархической и сетевой моделями
данных.
2. Охарактеризовать реляционную модель данных.
3. Перечислить составные элементы реляционной модели.
4. Что такое первичный ключ?
5. Перечислить условия, при соблюдении которых таблицу
можно считать отношением.
6. В чем суть целостности сущностей?
7. Определить условия ссылочной целостности.
8. Определить различие между первичным и внешним ключами.
9. Какое назначение внешних ключей?
10. В чем различия между реляционной алгеброй и реляционным
исчислением?
11. Перечислить операции реляционной алгебры.
12. Назвать и охарактеризовать дополнительные операции
реляционной алгебры, предложенные К. Дж. Дейтом.
13. Дать характеристику языку QBE.
14. Перечислить операторы языка SQL.
15. Выполнить сравнение языков QBE и SQL.
16. В чем заключается процесс нормализации?
17. Привести примеры аномалий ввода, модификации, удаления
данных.
18. Что такое функциональные зависимости?
19. Перечислить требования нормальных форм.
20. Описать этапы перехода от первой нормальной формы ко
второй.
21. Какая последовательность действий необходима для перехода
к третьей нормальной форме?
22. Составить
алгебраическое
выражение
(или
последовательность реляционных операций), необходимое для
выполнения следующих запросов к базе данных поставщиков и
материалов:
 получить полную информацию обо всех поставках в Москве;
 получить номера материалов, поставляемых поставщиком из
Тюмени;
 получить такие пары номеров материалов, которые
одновременно поставляются одним поставщиком;
 получить общее количество товаров, поставляемых
поставщиком S1;
 получить названия поставщиков, которые поставляют по
крайней мере один материал типа п/ш;
 получить типы материалов, поставляемых поставщиком S1.
19. В компании есть несколько отделов, в каждом отделе есть
несколько сотрудников, несколько проектов, несколько кабинетов.
Каждый сотрудник имеет план работы (несколько заданий). Для таких
заданий существует ведомость полученных вознаграждений. В
каждом кабинете есть несколько телефонов. В базе данных должна
содержится следующая информация:
 для каждого отдела: номер отдела, бюджет и номер
сотрудника, который возглавляет этот отдел;
 для каждого сотрудника: номер сотрудника, номер текущего
проекта, номер кабинета, номер телефона, название заданий вместе с
датами и размерами всех оплат;
 для каждого проекта: номер проекта и бюджет;
 для каждого кабинета: номер кабинета, площадь, номера всех
телефонов, установленных в кабинете.
Составить множество нормализованных отношений для
представления этой информации.
20. Создать реляционную схему базы данных предприятия сферы
сервиса (парикмахерской, мастерской по ремонту бытовой техники,
компьютерной фирмы и т.п.). Схема должна содержать как минимум
семь таблиц, приведенных к третьей нормальной форме. Обосновать
выбор структур таблиц, их взаимосвязь. Описать процесс
нормализации таблиц.
21. Дать определение данных на SQL для базы данных
поставщиков и материалов.
22. Сформулировать на SQL для базы данных поставщиков и
материалов следующий запрос: "Получить названия поставщиков,
поставляющих материал M2".
23. Сформулировать на SQL следующее обновление базы данных
поставщиков и материалов: "Изменить тип материала п/ш на ч/ш",
"Удалить все проекты, для которых нет поставок".
24. Сформулировать на QBE следующий запрос: "Вывести список
клиентов, чья общая сумма годовых заказов превышает 70000".
25. Сформулировать на QBE следующий запрос: "Перечислить
название и цену товаров, поставка которых осуществляется после
1.03.03".
26. Сформулировать на QBE следующее изменение базы данных:
"Удалить сведения о клиенте с номером 3101".
4. СЕМАНТИЧЕСКОЕ МОДЕЛИРОВАНИЕ
Разработка базы данных в терминах реляционной модели часто
сводится к сложному и неудобному для проектировщика процессу,
поскольку эти модели не содержат достаточно средств для
представления смысла данных. Такое положение вещей приводит к
замедлению процесса разработки БД и является источником
потенциальных ошибок. Семантика реальной предметной области
должна независимым от модели способом представляться в сознании
ее создателя. Поэтому в последнее время получило развитие
семантическое моделирование. Основная цель такого подхода –
организация интерфейса проектировщика, а также конечного
пользователя с информационной системой на уровне представлений в
пределах предметной области, а не на уровне структур данных.
Наиболее популярными в настоящее время инфологическими, или как
их еще называют семантическими, моделями являются объектноориентированная модель и модель "сущность-связь". Сочетая в себе
предметную наглядность и теоретическую обоснованность, они
являются мощным инструментом проектирования баз данных.
Данные подходы находят все большее воплощения в конкретных
системах управления базами данных.
4.1. Объектно-ориентированное проектирование
Для определения структуры БД в объектно-ориентированных
терминах многими специалистами используется язык ODL. Главное
назначение ODL – обеспечить запись объектно-ориентированных
проектов с последующим прямым переводом в выражения объектноориентированной СУБД (OODBMS). Как правило, основным языком
таких систем является C++ или Object Pascal, поэтому ODL
необходимо переводить в выражения этих языков. ODL соответствует
им обоим (но больше C++), поэтому указанный перевод достаточно
прост. Значительно сложнее осуществлять перевод из ODL или
проектов, реализованных в терминах модели "сущность-связь", в
выражения, систем управления реляционными базами данных
(RDBMS).
4.1.1. Представление объектов
При объектно-ориентированном проектировании считается, что,
мир состоит из объектов – определенных наблюдаемых сущностей.
Например, люди, животные, машины, авиарейсы, факультеты в
институте, здания и т. д. могут пониматься как объекты. При этом
каждый объект можно уникальным образом идентифицировать, чтобы
отличить его от любого другого объекта.
Для построения адекватной модели предметной области, как
правило, необходимо определить классы объектов, в рамках которых
объекты обладают сходными свойствами. Понятия "объект" и "класс" в
БД по сути дела совпадают с этими понятиями в языках объектноориентированного программирования (ООП).
Элементы и понятия реального мира, представляемые объектами
класса, должны быть сходными. Например, можно сгруппировать
всех клиентов ателье в один класс, а все заказы в другой. Нет смысла
объединять клиентов и заказы в одном классе, так как между ними
практически нет ничего общего, и они играют разные роли в сфере
деятельности ателье.
Все объекты одного класса должны иметь одинаковый набор
свойств. При программировании на объектно-ориентированном языке
можно представить объекты в виде записей, как показано на рис.45.
Номер_заказа
Изделие
Заказчик
Дата_приема
К объекту Клиент
...
Объект заказ
Рис.45. Объект, представляющий заказ ателье
Можно считать, что объекты имеют поля (слоты), в которых
размещены значения. Такими значениями могут быть целые числа,
строки или массивы, ссылки на другие объекты, а также методы, т. е.
функции, применяемые к объектам.
Мы сосредоточимся на абстрактных понятиях класса и его свойств,
не вдаваясь в детали реализации типа упорядочивания полей записи и
даже в реальное представление объекта.
Определяя проект классов ODL, будем описывать свойства
следующих видов, перечисление которых приводится далее.
1. Атрибуты – свойства, типы которых строятся из исходных
типов, например целых чисел или строк. Характерно то, что
атрибут имеет тип, не включающий в себя ни одного класса. В ODL
типы атрибутов ограничены.
2. Связи – свойства, типом которых являются ссылка на объект
некоторого класса или набор (например, множество) таких ссылок.
3. Методы – функции, которые можно применить к объектам
класса. В данном изложении применение методов не
рассматривается.
4.1.2. Описания классов
Описания класса в ODL в их простейшей форме состоят из
следующих элементов:
1. Ключевого слова interface.
2. Имени интерфейса (т.е. класса).
3. Списка свойств класса, заключенного в скобки. Напоминаем,
что свойства – это атрибуты, связи и методы.
Простая форма описания интерфейса:
interface <имя>{
<список свойств>}
4.1.3. Атрибуты в ODL
Свойства объектов называются атрибутами. Эти свойства
описывают определенные аспекты объекта, связывая с ним значение
некоторого простого типа. Например, все объекты студент могут
иметь атрибут имя, типом которого является строка, а значением –
имя данного человека. Эти объекты могут иметь также атрибут
дата_рождения, являющийся тройкой целых чисел (т.е. структурой
записи), выражающей год, месяц и день рождения данного
студента.
Пример 4.1. Ниже приведено ODL-описание класса изделий
ателье. Здесь оно относительно простое; позже мы расширим его.
1) interface Изделие {
2) attribute string назв_изделия;
3) attribute integer размер;
4) attribute enum Материал{ткань, мех, кожа}
тип_материала;};
Здесь и далее предполагается, что в именах допускаются
кириллические символы. Данный пример чисто иллюстративный, для
упрощения указывается только один размер и допускается
использование только трех типов материалов.
Строка 1 описывает Изделие как класс. Ключевое слово
interface используется в ODL для выражения класса. За строкой 1
следуют описания трех атрибутов, которые имеют объекты класса
Изделие. Первый из них на строке 2 называется назв_изделия, его
типом является string – строка символов. Предполагается, что
значением атрибута назв_изделия в любом объекте Изделие будет
название изделия (пальто, платье и т.д). Следующий атрибут
(размер), описанный в строке 3, имеет тип целых чисел, и
представляет размер изделия по установленной шкале. На строке 4
описан атрибут тип_материала, показывающий, из чего изготовлено
(или изготавливается) изделие. Его тип – перечень с именем
Материал. Значения атрибута перечня выбираются из списка
доступных литералов, в данном примере – ткань, мех, кожа.
Определенный таким образом объект Изделие можно считать
записью, или кортежем, состоящим из четырех компонентов, по
одному для каждого атрибута. Например:
("Пальто", 50, кожа) является объектом Изделие.
Пример 4.2. В примере 4.1 атрибуты имеют атомарные типы.
Могут быть атрибуты, типами которых являются структуры,
множества или множества структур. Ниже приводится пример с
неатомарным типом.
Определим класс Мастер:
1) Interface Мастер {
2) attribute string фамилия;
3) attribute string имя;
4) attribute string отчество;
5) attribute Struct Адреса
{string город, integer индекс, string улица,
string дом, integer квартира} адрес;
};
В строках 1,2,3 определяются атрибуты фамилия, имя, отчество
мастера, являющиеся строками. Строка 5 определяет атрибут адрес,
имеющий тип структуры записи. Имя этой структуры Адреса,
данный тип состоит из пяти полей: город, индекс, улица, дом (номер
дома может содержать дроби и буквы, поэтому выбран тип string),
квартира. В общем случае в ODL можно определить типы
структуры записи с помощью ключевого слова Struct и фигурных
скобок, выделяющих список имен полей и их типы.
4.1.4. Связи в ODL
Атрибуты объекта играют большую роль, однако иногда важнее
знать то, как они связаны с объектами того же самого или другого
класса.
Пример 4.3. Допустим, что к описанию класса Изделие из
примера 4.1 добавляется свойство, представляющее множество
работающих над ним мастеров. Поскольку сами мастера являются
классом, описанным в примере 4.2, информацию о них нельзя
сделать атрибутом Изделие, так как типы атрибутов не должны быть
классами или строиться из классов. Множество занятых при работе
над изделием мастеров, – это связь между классами Изделие и
Мастер, которая выражается строкой
relationship Set<Мастер> мастера;
в описании класса Изделие. Эта строка может появиться в примере
4.2 после любой из строк – с 1 по 4. Она означает, что в каждом
объекте класса Изделие есть множество ссылок на объекты класса
Мастер. Множество ссылок называется мастера. Ключевое слово
relationship определяет, что мастера содержит ссылки на другие
объекты, а ключевое слово Set, предшествующее <Мастер>,
показывает, что мастера ссылается на множество объектов
Мастер, а не на единственный объект. В общем случае в ODL тип,
являющийся множеством элементов другого типа Т, определяется
ключевым словом Set и угловыми скобками, выделяющими тип Т.
Вообще говоря, в физических терминах множество мастера
можно было бы представить списком указателей на объекты Мастер;
сами объекты Мастер физически не появлялись бы в объекте Изделие.
Однако на фазе проектирования БД физическое представление
неизвестно и важным аспектом связи является то, что из объекта
Изделие легко найти мастеров, работающим над данным изделием.
В примере 4.3 показана связь множества объектов (мастеров) с
единственным объектом (изделием). Можно установить и связь
единственного объекта с объектом описываемого класса.
Предположим, например, что в примере 4.3 был задан тип связи
Мастер, а не Set<Мастера >, с помощью строки
relationship Мастер к_мастеру;
Это значит, что с каждым изделием связан только один объект
Мастер.
4.1.5. Обратные связи
Любая прямая связь подразумевает наличие обратной связи.
Например, можно определять не только мастеров, занятых работой над
изделиями, но и изделия, над которыми работал данный мастер. Для
получения такой информации в объектах Мастер можно добавить
строку
relationship Set<Изделия> от_мастера;
к описанию класса Мастер из примера 4.2. Однако в такой строке и
сходном описании Изделие не учитывается очень важный аспект связи
между изделиями и мастерами, а именно: если мастер S находится в
множестве мастера для изделия M, то M находится в множестве
от_мастера для мастера S. Это соотношение связей между
множествами мастера и от_мастера выражается тем, что в
описании каждой связи указывается ключевое слово inverse и имя
другой связи. Если одна из связей находится в другом классе, как это
обычно и бывает, ссылка на нее делается с помощью имени этого
класса, за которым следуют двойное двоеточие (::) и имя связи.
Пример 4.4. Чтобы определить связь от_мастера класса
Мастер как обращение связи мастера в классе Изделие, изменим
описание класса Мастер следующим образом:
1)interface Мастер {
2) attribute string фамилия;
3) attribute string имя;
4) attribute string отчество;
5) attribute Struct Адреса {string город,
integer
индекс, string улица, string дом, integer квартира}
адрес;
6) relationship Set<Изделие> от_мастера
inverse Изделие::мастера;};
В строке 6 выражено не только описание связи от_мастера, но
и то, что данная связь имеет инверсию – Изделие::мастера.
Поскольку связь мастера определена в другом классе, ее имени
предшествуют двойное двоеточие и имя этого класса (Изделие).
Такая нотация широко применяется при ссылках на свойства
различных классов.
В примере 4.4 две обратные связи, каждая из которых
соединяет объект (изделие или мастера) с множеством объектов.
Как упоминалось ранее, есть связи и другого типа, соединяющие
объект с единственным объектом другого класса. Понятие
обращения связи при этом не изменяется. Общее правило: если
связь R для класса С соединяет с объектом х класса С множество
объектов y1, y2, ..., уn , то обратная к ней связь соединяет с каждым у
объект х (возможно, наряду с другими объектами).
Можно представить связь R класса С с классом D в виде списка
пар (или кортежей) отношения. Каждая пара состоит из объекта х из
класса С и связанного с ним объекта у из класса D:
C
D
x1
y1
x2
y2
…
…
Если R имеет тип Set<D>, то существует несколько пар с одним и тем
же С-значением. Если R имеет тип D, существует только одна пара с
заданным С-значением. Тогда обращение R есть множество пар с
обращенными компонентами:
C
D
y1
x1
y2
x2
…
…
Заметим, что это правило действует, даже если С и D являются одним
и тем же классом. Существуют связи класса с самим собой, например
связь "быть подчиненным" класса "сотрудники" с самим собой.
4.1.6. Множественность связей
Необходимо учитывать, что данный объект связан с
единственным объектом или он может быть связан с множеством
других объектов. В ODL эти возможности определяются тем,
применяется или нет в описании связи оператор множества типа Set.
При наличии обратимой пары связей существует четыре
возможности: связь может иметь тип "один-к-одному", "один-комногим", или "многие-ко-многим".
Рассмотренная связь между мастерами и изделиями относится к
типу "многие-ко-многим" и не является уникальной ни в одном
направлении: бывает над изделием работают несколько мастеров и
один мастер занят со множеством изделий. Следующий пример
является развитием предыдущих примеров. В нем вводится класс
Цех, представляющий пошивочные цеха, работающие с различными
изделиями.
Пример 4.5. Ниже приводится описание трех классов: Изделие,
Мастер и Цех. Первые два из них уже были введены в примерах 4.1
и 4.2. Объекты цехов имеют атрибуты название и адрес,
появляющиеся в строках 14 и 15. Заметим, что здесь типом адресов
является строка, а не структура, использованная для атрибута адрес
класса Мастер. В различных классах можно использовать атрибут с
одним и тем же именем, но с разными типами.
1) interface Изделие {
2) attribute string назв_изделия;
3) attribute integer размер;
4) attribute enum Материал{ткань, мех, кожа}
тип_материала;
5) relationship Set<Мастер> мастера
inverse Мастер::от_мастера;
6) relationship Цех выполняется_в
inverse Цех::обеспечивает;
};
7) interface Мастер {
8) attribute string фамилия;
9) attribute string имя;
10) attribute string отчество;
11) attribute Struct Адреса {string город, integer
индекс, string улица, string дом, integer квартира}
адрес;
12) relationship Set<Изделие> от_мастера
inverse Изделие::мастера;
};
13) interface Цех{
14) attribute string название;
15) attribute string адрес;
16) relationship Set<Изделие> обеспечивает
inverse Изделие::выполняется_в;
};
В строке 6 показана связь выполняется_в между изделиями и
цехами. Поскольку ее типом является Цех, а не Set <Цех >, каждое
изделие изготавливает только один цех. Обращение данной связи
показано в строке 16 – это связь обеспечивает между цехами и
изделиями. Ее типом является Set<Изделие>, поэтому каждый цех
обеспечивает множество изделий – возможно, ни одно, только одно
или большее число изделий.
Требования уникальности связи и ее обращения называются
множественностью связей. Наиболее распространенные варианты:
1. Связь типа "многие-ко-многим" класса С с классом D – это
связь, в которой с каждым объектом класса С ассоциируется
множество объектов класса D, а в ее обращении с каждым объектом
класса D ассоциируется множество объектов класса С. В описании,
приведенном в примере 4.5, мастера – это связь типа "многие-комногим" между классом Изделие и классом Мастер; такой же
является связь от_мастера между классами Мастер и Изделие.
В любом направлении связи допускается пустое множество.
2. Связь типа "многие-к-одному" класса С с классом D – это
связь, в которой для каждого объекта класса С существует
уникальный объект класса D, но в ее обращении с каждым объектом
класса D связаны многие С. В примере 4.5 выполняется_в – это
связь типа "многие-к-одному" класса Изделие с классом Цех.
Обратная ей связь – это связь типа "'один-ко-многим" класса D с
классом С. В том же примере обеспечивает – связь типа "одинко-многим" класса Цех с классом Изделие.
3. Связь типа "один-к-одному" класса С с классом D – это связь,
в которой для каждого объекта класса С существует уникальный
объект класса D.
В обратной связи каждый объект класса D связан с уникальным
объектом класса С. В описание из примера 4.5 можно добавить класс
Начальник, представляющий начальников цехов. Предполагается,
что каждый цех имеет единственного начальника и ни один человек
не может быть начальником более чем одного цеха. Значит, связь
между цехами и их начальниками имеет тип "один-к-одному" в
обоих направлениях.
При описании связей следует иметь в виду, что связь типа
"многие-к-одному" – это частный случай связи типа "многие-комногим", а связь типа "один-к-одному" – частный случай связи типа
"многие-к-одному". Любое полезное свойство связей типа "многиеко-многим" применимо к связям типа "многие-к-одному", а полезные
свойства последних верны и для связей типа "один-к-одному".
Например, структура данных для представления связей типа
"многие-к-одному" подходит для связей типа "один-к-одному", но
может быть непригодна для связи типа "многие-ко-многим".
Используя термины типа "уникальный" или "один" при
определении связей типа "многие-к-одному" или "один-к-одному"
необходимо учитывать некоторую неопределенность. Важно
считать, что "уникальный" или "один" элемент реально существует.
Например, для каждого изделия реально существует пошивочный
цех, а цех возглавляет реальный начальник. Однако есть все
основания считать, что в реальности уникального объекта не
существует. Например, цех может временно работать без начальника
или же мы можем не знать какому цеху относится конкретное
изделие.
Таким образом, обычно допускается, что предполагаемое значение
связанного объекта может отсутствовать. Значение "null" часто
допускается в БД там, где предполагается наличие истинного
значения.
Например,
в
терминологии
традиционного
программирования указатель "null" может стоять там, где
предполагается указатель на единственный объект.
4.1.7. Типы в ODL
Средства ODL предоставляют проектировщику систему типов,
подобную системам типов языка С или других популярных языков
программирования. Система типов строится из базовых типов, которые
определены сами по себе, с помощью конкретных рекурсивных правил
(сложные типы строятся из более простых). Базовые типы ODL:
1. Атомарные типы: целое число с плавающей точкой, символ,
строка символов, булево выражение и перечисление. Последний тип –
это список имен, объявленных синонимами целых чисел.
Перечисление содержится в строке 5 примера 4.4, где имена ткань, мех,
кожа в результате были определены как синонимы чисел 0, 1, 3.
2. Типы интерфейса, например Изделие и Мастер, являются
реальными структурами с компонентами для каждого атрибута и
каждой связи данного интерфейса. Эти имена представляют сложные
типы, определяемые с помощью перечисленных ниже типов, но их
можно считать базовыми.
Базовые типы комбинируются в структурные типы с помощью
следующих конструкторов типов:
1. Множество. Если T -любой тип, то Set<T> обозначает тип,
значениями которого являются все конечные множества элементов
типа Т.
2. Мультимножество. Если Т – любой тип, то Bag<T > обозначает
тип, значениями которого являются все мультимножества элементов
типа Т. Мультимножество допускает многократное повторение одного
и того же элемента. Например, {1, 2, 1} – это мультимножество, а не
множество, так как 1 повторяется в нем дважды.
3. Список. Если Т– любой тип, то List<T> обозначает тип,
значениями которого являются конечные списки, состоящие из нуля
или более элементов типа Т. В специальном случае тип string
является сокращением типа List<char>.
4. Массив. Если Т– любой тип, то Аггау<Т> обозначает тип,
элементами которого является массив из i элементов типа Т. Например,
Array<char,10> обозначает символьную строку длиной 10.
5. Структуры. Если Т1,T2, ..., Тn являются типами, a F1, F2, ..., Fn
именами полей, то
Struct N {Т1F1,T2F2…,TnF n }
обозначает тип с именем N, элементами которого служат структуры,
содержащие п полей; i-е поле имеет имя Fi и тип Тi. Например, строка 10
в примере 4.4 показывает тип структуры с именем Адрес с пятью полями.
Для того чтобы различать множества, мультимножества и списки
следует помнить, что элементы множества не упорядочены и каждый
из них входит в данное множество только один раз. Мультимножество
допускает более одного вхождения любого элемента, но элементы и их
вхождения не упорядочены. В списке может быть несколько
вхождений одного и того же элемента, но все вхождения в нем
упорядочены. Значит, {1, 3, 1} и {3, 1, 1} – это одно и то же
мультимножество, но {1, 3, 1} и {3, 1, 1} – это разные списки.
Первые четыре типа – множество, мультимножество, список и
массив – называются типами множеств. Существуют правила,
определяющие, какие типы можно ассоциировать с атрибутами, а
какие со связями.
Построение типа атрибута начинается с атомарного типа или со
структуры, полями которой являются атомарные типы. Затем по
выбору можно применить тип множества к исходному атомарному
типу структуры.
Тип связи – это или тип интерфейса, или тип набора,
примененный к типу интерфейса.
Важно помнить, что типы интерфейса могут не появляться в
типе атрибута, а атомарные типы – в типе связи. В этом отличие
атрибутов и связей друг от друга. Разница между ними еще и в том, как
строятся для них сложные типы: и атрибут, и связь допускают
произвольный тип множества в качестве последнего оператора, но тип
структуры допустим только в атрибутах.
Пример 4.6. Возможные типы атрибутов:
1) integer.
2) Struct N {string fieldl, integer field2}.
3) List<real>.
4) Array<Struct
N
{string
fieldl,
integer
field2}>.
Здесь 1 – атомарный тип, 2 – структура атомарных типов, 3 –
множество атомарного типа, а 4 – множество структур, построенных
из атомарных типов.
Допустим, что доступными базовыми типами являются имена
интерфейсов Изделие и Мастер. Тогда можно построить типы связи
Изделие или Bag<Мастер>. Однако следующие типы связей
недопустимы:
1. Struct N {Изделие fieldl, Мастер field2}.
Типы связей не могут включать в себя структуры.
2. Set<integer>. Типы связей не могут содержать
атомарные типы.
3. Set<Array<Мастер>. Типы связей не могут содержать
два применения типов множества (их не могут содержать и типы
атрибутов).
4.1.8. Проектирование с использованием ODL
В данном разделе рассматриваются некоторые полезные
принципы проектирования с использованием объектно-ориентированного подхода.
Правильность
Самое важное: проект должен быть адекватным конкретной
предметной области, правильно отображать реальный мир. Классы
или множества сущностей и их атрибуты, должны отражать
реальные объекты. Нельзя приписывать мастеру-портному атрибут
"число цилиндров", хотя это имеет смысл для класса автомобилей.
Любые установленные связи должны соотноситься с нашими
знаниями о моделируемой части реального мира.
Пример 4.7. Если определяется связь мастер_для между
Мастер и Изделие, она должна быть типа "многие-ко-многим", так
как наблюдения за реальным миром показывают, что мастера могут
быть заняты работой над многими изделиями, и изделия могут (не
обязательно, но могут) выполняться несколькими мастерами.
Неверно определять эту связь как " связь типа "один-к-одному".
Устранение избыточности
Необходимо следить за тем, чтобы каждый факт упоминался не
более одного раза. Например, мы использовали связь
обеспечивает между изделиями и цехами. Можно было бы еще
ввести атрибут название_цеха или множество сущностей Изделия, в
чем нет ничего незаконного. Однако это опасно по многим
причинам.
1. Необосновано увеличивается необходимый объем памяти,
одно описание факта займет всегда меньше места, чем два описания.
2. Могут возникать аномалии удаления и изменения данных.
Например, данные о каком-либо факте могут быть изменены в одном
месте, а в другом по недочету оставлены прежними, т. е. повышается
вероятность наличия противоречий в базе данных.
С первого взгляда может показаться, что использование связи и
ее обращения в ODL – это пример излишеств в модели. Однако не
следует полагать, что связь и ее обращение будут представлены двумя
различными структурами данных, например указателями в
различных направлениях. Вспомните, что определение связи и ее
обращения лишь отражают тот факт, что связи в принципе можно
придать любое направление.
Если же связь действительно реализуется двумя отдельными
структурами данных, возникает риск, связанный с избыточностью.
Поскольку предполагается, что базовые указатели постоянно
используются при изменении данных, при реализации СУБД,
основанных на ODL, нужно внимательно относиться к способам
изменений БД. Но эта проблема относится к уровню системы,
причем предполагается, что разработчики системы успешно (в
конечном счете) с ней справятся. На уровне реализации с
избыточностью связан меньший риск, и существование указателей
в обоих направлениях может привести к существенному
повышению скорости, с которой связи придается то или иное
направление.
И еще один важный момент. Не стоит вводить в проект больше
элементов, чем это необходимо.
4.1.9. Подклассы
Наследование является одним из основополагающих принципов
ООП. Довольно часто класс содержит объекты с особыми свойствами,
не связанными со всеми членами этого класса. В данном случае
рекомендуется разделить класс на подклассы, каждый из которых
будет иметь собственные специальные атрибуты и/или связи в
дополнение к тем, что присущи классу как единому целому. Сначала
рассмотрим простой способ описания подклассов в ODL, а затем (в
следующей главе) покажем, как иерархии класс-подкласс
представляются в E/R-модели с помощью специальных связей под
названием "isa" ("А есть В" выражает связь "isa" подкласса А с
подклассом В).
В рассматриваемом в качестве примера БД ателье могут
заказываться платья, костюмы, шубы и множество других типов
изделий. Для каждого из этих типов можно определить подкласс класса
Изделие, введенного в примере 4.1. По определению класс С является
подклассом другого класса D если в описании за именем С следуют
двоеточие и имя класса D.
Пример 4.8. Для иллюстрации будем различать труд портного и
скорняка. Меховое_изделие – это подкласс класса Изделие,
следовательно, Изделие – это суперкласс класса Меховое_изделие.
Выразим это простым ODL-описанием:
1) interface Меховое_изделие: Изделие {
2) relationship Set<Мастер> скорняжный_пошив;
};
Строка (1) показывает, что Меховое_изделие – подкласс класса
Изделие. Строка (2) означает, что все объекты класса Меховое_изделие
имеют связь скорняжный_пошив с мастерами, выполняющими
скорняжную работу. В описании не указано имя обращения этой связи,
хотя технически это следовало бы сделать. Заметим, что связь
скорняжный_пошив имеет смысл не для всех изделий, а только для
меховых изделий, поэтому не вводится для класса Изделие.
Подкласс наследует все свойства своего суперкласса (называемого
также классом, из которого выводится подкласс). Другими словами,
любые атрибут и связь суперкласса автоматически являются атрибутом и
связью его подкласса. В примере 4.8 каждый объект класса имеет все
атрибуты, наследованные от Изделие (вспомните пример 4.4), и в
дополнение к собственной связи скорняжный_пошив наследует от
Изделие связи мастера и выполняется_в.
4.1.10. Множественное наследование в ODL
У класса может быть несколько подклассов, каждый из которых
наследует свойства своего суперкласса, как было показано в
предыдущем разделе. Более того, подклассы сами могут иметь
подклассы, образуя иерархию классов, в которой каждый класс
наследует свойства своих предшественников. Некоторые классы
могут наследовать свойства из нескольких различных. Следующий
пример иллюстрирует потенциальные возможности и проблемы,
связанные с такой ситуацией.
Пример 4.9. Можно определить подкласс жилет класса Изделие:
1) interface Жилет: Изделие{
2) attribute string материал_спинки;
};
Все жилеты имеют атрибут, выражающий определяющий
материал спины, а также все атрибуты и две связи, которыми
обладают все изделия.
Теперь рассмотрим изделие "жилет из меха", являющееся и
меховым изделием, и жилетом. Кроме обычных свойств класса
Изделие, такие изделия должны иметь связь скорняжный_пошив и
атрибут материал_спинки. Эту ситуацию можно описать, определив
подкласс, являющийся подклассом обоих классов Меховое_изделие и
Жилет:
interface
Жилет{
};
Меховой_жилет:
Меховое_изделие,
Итак, объект Меховой жилет определяется для выражения всех
свойств обоих подклассов Жилет и никаких свойств или связей,
принадлежащих только меховым жилетам, не вводится. Объекты
класса Меховой_жилет наследуют атрибут материал_спинки класса
Жилет и связь скорняжный_пошив класса Меховое_изделие.
Поскольку классы Жилет и Меховое_изделие, в свою очередь,
наследуют атрибуты и две связи класса Изделие, класс
Меховой_жилет наследует также и эти атрибуты и свойства. Однако
он не наследует двух копий всех этих свойств, а наследует свойства
из класса Изделие через любой из двух его непосредственных
подклассов. Рис. 46 иллюстрирует связи подкласс-суперкласс, в
которых участвуют четыре названных класса.
Изделие
Меховое изделие
Жилет
Меховой_жилет
Рис. 46. Диаграмма множественного наследования
В общем случае можно определить класс С как подкласс любого
числа других классов, поставив двоеточие и перечислив имена всех
этих классов после описания имени интерфейса С. Пример 4.9
иллюстрирует именно такую форму связей. Когда класс С наследует
свойства нескольких классов, потенциально возможен конфликт
имен свойств. Два или более суперкласса класса С могут иметь
атрибут или свойство с одним и тем же именем при том, что типы
этих свойств различны.
Пример 4.10. Предположим, что класс Изделие имеет подклассы
Кожаное_изделие и Меховое_изделие, каждый из которых имеет
атрибут стиль. Но в классе Кожаное_изделие этот атрибут получает
значения из набора {молодежный, всевозрастной}, а в классе
Меховое_изделие – из набора {модный, традиционный}. Если затем
вводится новый подкласс Кожано-меховое_изделие, суперклассами
которого являются Кожаное_изделие и Меховое_изделие, тип
наследуемого атрибута стиль в классе Кожано-меховое_изделие
остается неясным.
Реализации ODL предлагают, по крайней мере, один из
следующих механизмов, подсказывающих пользователю, как
действовать в случае конфликта, возникающего из множественного
наследования.
1. Можно указать, какое из двух определений данного свойства
относится к подклассу. Так, в примере 4.10 считаем, что для изделия
из кожи и меха важен не показатель модности, а целевая возрастная
категория.
Тогда
устанавливается,
что
класс
Кожаномеховое_изделие наследует атрибут
стиль из суперкласса
Кожаное_изделие, а не Меховое_изделие.
2. Можно присвоить в классе С новое имя одному из двух
наследуемых свойств с одним и тем же именем. Если в примере 4.10
Кожано-меховое_изделие наследует атрибут стиль из класса
Кожаное_изделие, в этом классе можно определить дополнительный
атрибут фасон как результат замены имени атрибута стиль,
наследуемого из класса Меховое_изделие.
3. В классе С можно заново определить некоторые свойства,
определенные в его суперклассах. В примере 4.10 можно считать, что
атрибут стиль не должен наследоваться напрямую из любого
суперкласса, а переопределить этот атрибут как числовое значение,
которое выражает степень удовлетворенности клиентов, выявленную
путем их опроса.
Заметим, что даже в примере 4.9 есть конфликты: Кожаномеховое_изделие
наследует
из
каждого
непосредственного
суперкласса (Меховое_изделие и Кожаное_изделие) свойства, в том
числе назв_изделия и мастера, которые эти классы наследовали из
класса Изделие. Но поскольку определения назв_изделия и других
свойств идентичны в обоих суперклассах, выбирать используемое
определение можно вообще любым способом.
4.1.11. Моделирование ограничений
Как известно, описание базы данных включает ограничения
или правила, позволяющие более адекватно описать предметную
область, уменьшить возможность возникновения ошибок и
аномалий.
Ключи
В ODL ключ класса – это такое множество атрибутов А, что при
наличии в данном классе двух различных объектов 01 и 02 они не
могут иметь идентичных значений для любого атрибута в ключе К.
В ODL один или несколько атрибутов описываются как ключи
класса с помощью ключевого слова key или keys (любого из них), за
которым указываются атрибуты, формирующие ключ. Если в ключе
больше одного атрибута, список атрибутов заключается в круглые
скобки. Описание ключа должно стоять непосредственно за
описанием интерфейса, перед открывающей фигурной скобкой или
любыми атрибутами либо связями. Само описание ключа заключается
в круглые скобки.
Пример 4.11. Чтобы показать, что множество, состоящее из
атрибутов фамилия, имя, отчество является ключом для класса
Мастер, строка 7 в примере 4.4 заменяется на:
interface Мастер
(key (фамилия, имя, отчество)) { };
Вместо key можно применять keys даже если описывается только
один ключ.
Возможно, что ключами являются несколько множеств
атрибутов. Тогда за словом keys можно поместить несколько ключей,
разделенных запятыми. Обычно в ключах, имеющих множество
атрибутов, список атрибутов должен быть заключен в круглые
скобки, поэтому один ключ с несколькими атрибутами можно
отличить от нескольких ключей, содержащих по одному атрибуту.
Пример 4.12. Чтобы проиллюстрировать ситуацию, в которой
уместно иметь более одного ключа, рассмотрим класс Сотрудник. He
будем описывать здесь все множество его атрибутов и связей, но
предположим, что его атрибутами являются empID – идентификатор
сотрудника и ssNo – номер страхового полиса. Тогда эти атрибуты
можно описать как ключ:
(key empID, ssNo).
Поскольку список атрибутов здесь не заключен в скобки, в ODL
это означает, что каждый из атрибутов сам является ключом. Если
заключить в скобки пару (empID, ssNo), в ODL считается, что эти два
атрибута вместе формируют один ключ. Из записи
(key (empID, ssNo))
следует именно то, что никакие два сотрудника не могут иметь один и
тот же ID и один и тот же номер страхового полиса, хотя два
сотрудника могут совпадать по одному из этих атрибутов.
Ссылочная целостность
Если ограничения по единственному значению устанавливают,
что в данной роли существует только одно значение, ограничение
ссылочной целостности означает, что в этой роли существует в
точности одно значение. Вариантом ограничения ссылочной
целостности является ограничение, согласно которому атрибут имеет
единственное непустое значение, но "ссылочная целостность" чаще
применяется к связям между классами.
Рассмотрим связь выполняется_в между Изделие и Цех в
строке 6 примера 4.4. Разве такое возможно: объект класса Цех
является значением выполняется_в, а самого этого объекта не
существует? Ответ заключается в том, что в реализации ODL связь
выполняется_в представлена указателем или ссылкой на данный
объект и в какой-то момент времени этот объект удаляется из класса
Цех. Тогда указатель становится висящим и больше не указывает на
реальный объект.
Согласно ограничению ссылочной целостности объект, на
который есть ссылка, должен существовать. Это ограничение можно
ввести по-разному.
1. Можно запретить удаление объекта, на который есть ссылка
(в приведенном выше примере – цеха).
2. Можно потребовать, чтобы при удалении объекта, на который
есть ссылка, удалялся и объект, который на него ссылается. В
приведенном примере это значит, что при удалении цеха из базы
данных нужно удалить также все соответствующие изделия.
В дополнение к упомянутым условиям удаления требуется,
чтобы при создании объекта "изделие" существующий объект "цех"
был задан в качестве значения связи выполняется_в. При
изменении этого значения новое значение также должно быть
существующим объектом. Использование таких методов обеспечения
ссылочной целостности связи – вопрос реализации БД, и в настоящем
пособии мы не будем его обсуждать.
Прочие ограничения
Для конкретной базы данных могут быть введены также другие
ограничения (правила целостности). Например, учитывая оборот
изделий и реальные возможности мастеров можно ввести правило,
согласно которому у каждого мастера было бы не более десяти
изделий.
В ODL ограничить количество изделий на одного мастера до
десяти можно, задав тип атрибута мастера списком длины 10.
Однако здесь невозможно задать условие, согласно которому
множество будет иметь не более 10 элементов.
4.1.12. Переход от объектно-ориентированной модели
к реляционной
От объектно-ориентированной модели в большинстве случаев
достаточно легко перейти к реляционной.
Пусть принимаются следующие ограничения:
 все свойства класса представляют собой атрибуты (а не
отношения или методы);
 типы атрибутов атомарны (не являются структурами или
множествами).
В данном случае переход к реляционной модели прост: создаются
отношения с именем соответствующего класса, при этом атрибуты
объектной модели переходят в атрибуты соответствующего классу
отношения.
В ряде случаев не возникает проблем, даже если некоторые
атрибуты не атомарны (такие как дата, перечень). Можно, например,
тип "перечень" для дней недели представить целыми числами от 0 до
6.
Для более трудных случаев используются расширение множества
на несколько кортежей и дополнительные отношения.
Наиболее сложный случай связан с представлением
многозначных связей если связь имеет тип множества. В данном
случае используется комбинация двух методов:
 однозначные связи – нужно найти ключ для представления
каждого из связанных объектов;
 имеются атрибуты со значением типа множества – нужно
представить множество связанных объектов путем создания одного
кортежа для каждого значения. При этом появляется избыточность,
которая устраняется при переходе к нормальным формам более
высокого порядка.
В объектно-ориентированной модели имена атрибутов различных
объектов могут совпадать, поэтому в подобных ситуациях при
переходе к реляционной модели необходимо присвоить уникальные
имена атрибутам, например, включая в имя атрибута имя
соответствующего объекта.
4.2. Диаграммы "сущность-связь"
Немаловажную роль в инфологическом проектировании играет
наглядность представляемых моделей данных. В этой связи большой
популярностью разработчиков пользуются средства, основанные на
графических нотациях, самым распространенным средством данного
типа являются диаграммы "сущность-связь" (entity-relationship, E/R),
которые соответствуют объектно-ориентированному подходу. Эти
диаграммы имеют те же три главных компонента, о которых
говорилось при описании ODL (хотя модели E/R и ODL имеют
особенности, о которых речь пойдет ниже).
4.2.1. Компоненты диаграмм "сущность-связь"
1. Множества сущностей, аналогичные классам. Сущности –
это члены множества сущностей, аналогичные объектам ODL.
2. Атрибуты–- это значения, описывающие свойства
сущности. Атрибуты в E/R и ODL – это, по сути, одно и то же
понятие.
3. Связи – это соединения между двумя или более множествами
сущностей. Связи в E/R аналогичны связям в ODL за следующими
исключениями:
(a) В модели E/R одно имя приписывается связи в обоих
направлениях, а в ODL отдельно определяются связь и ее
обращение. Например, обратные связи Изделие::мастера
и Мастер:: от_мастера в примере 4.4 в модели E/R
были бы представлены единственной связью.
(b) Связи в E/R могут соединять более двух множеств
сущностей, а связи ODL – максимум два класса.
Пример 4.13. На рис. 47 изображена E/R диаграмма,
представляющая ту же самую информацию о реальном мире, что и
описание ODL в примере 4.5.
Множествами сущностей являются Изделие, Мастер и Цех.
Чтобы выразить небольшое различие между множествами сущностей
и классами, имена первых пишутся во множественном числе, имена
вторых в единственном.
Имя
назв_изделия
размер
тип_материала
Мастером
Фамилия
Отчество
Мастер
а
Изделия
Адрес
относиться
Цеха
Названи
е
Адрес
Рис. 47. Диаграммы "сущность-связь" для БД "Ателье"
Множество сущностей Изделия имеет те же атрибуты, что и класс
Изделие в примере 4.5, а именно – название изделия, размер, и тип
материала. Аналогично, два других множества имеют атрибуты, которые
были описаны для соответствующих классов ODL.
На рис. 47 видны также связи, соответствующие связям из ODLописания примера 4.5. Одно из них мастером содержит информацию
пары обратных связей мастера и от_мастера между ODLклассами Изделие и Мастер. E/R-связь относиться на рис. 44
представляет
обратные
связи
Изделие::выполняется_в
и
Цех::обеспечивает. Стрелка, указывающая на множество Цеха,
означает, что каждым изделием занимается только один цех.
4.2.2. Множественность E/R-связей
Для выражения множественности связей в E/R-диаграммах
можно применять стрелки. Если между множествами Е и F есть связь
типа "многие-к-одному", используется стрелка, указывающая на F.
Она означает, что каждая сущность из множества Е связана только с
одной сущностью из множества F. Однако сущность из F может быть
связана с многими сущностями в Е.
Связь типа "один-к-одному" между множествами Е и F выражается
стрелками, указывающими и на Е, и на F. Например, на рис. 48 показаны
два множества Цех и Начальник, а также связь между ними Возглавляет
(атрибуты не показаны). Предполагается, что начальник может
возглавлять только один цех, а у начальника может быть только один
цех, что и выражено стрелками, указывающими на оба множества.
Возглавляет
Цех
Начальник
Рис. 48. Связь типа "один-к-одному"
Зачастую E/R-связи удобно изображать таблицей, каждая строка
которой представляет пару сущностей, вовлеченных в данную связь.
Например, связь мастером можно представить так:
Изделия
Мастера
Вечернее платье
Мужской костюм
Дубленка
Иванова
Павлов
Семенова
Конкретного способа, которым должны реализовываться связи, не
существует ни в E/R-моделях, ни в ODL.
Такая таблица иногда называется множеством отношений для
конкретной связи. Элементы этого множества – строки таблицы. Их
можно представить в виде кортежей с компонентами для каждого
множества сущностей. Например, кортежем во множестве отношений
для связи мастером, является пара
(Вечернее платье, Иванова)
Многосторонние связи
В E/R-моделях, в отличие от ODL, удобно определять связи между
несколькими множествами. Однако на практике тернарные
Мастера
Договоры
Изделия
Цеха
Рис.49. Трехсторонняя связь
(трехсторонние) связи или связи еще более высокого порядка
встречаются довольно редко. Многосторонние связи в E/R-моделях
изображаются линиями, соединяющими ромб (связь) с каждым из
участвующих в данной связи множеств.
Пример 4.14. На рис. 49 изображена связь Договоры между
цехом и мастером на изготовление изделия. Она означает, что цех
заключает с мастером контракт на изготовление изделия. В общем
случае значением E/R-связи можно считать множество кортежей,
компонентами которых являются сущности, вовлеченные в данную
связь. Например, связь Договоры можно описать трехмерными
кортежами вида:
(цех, мастер, изделие).
В многосторонних связях стрелка, указывающая на множество Е,
означает, что из всех других вовлеченных в эту связь множеств
выбирается по одной сущности, связанной с единственной сущностью
в Е. (Заметим, что такое определение – это обобщение понятия
множественности, применявшегося для двухсторонних связей.) На
рис. 49 стрелка, указывающая на множество Цеха, означает, что
каждый мастер может иметь договор на изготовление конкретного
изделия только с одним цехом. Однако здесь нет стрелок,
указывающих на Мастера или Изделия. Цех может заключать договор
на участие в работе над изделием со многими мастерами, а мастер
может заключить контракт с цехом на работу над несколькими
изделиями.
Чтобы выразить связи между тремя или более участниками
недостаточно ставить или не ставить стрелки на линиях, идущих к
ромбу связи. Вполне реальную ситуацию с помощью стрелок
описать невозможно. Например, согласно рис. 49, цех является
функцией только изделия, а не мастера и изделия вместе взятых, так
как изделие производится единственным цехом. В принятой нотации
такую ситуацию невозможно отличить от случая трехсторонней
связи, когда множество, на которое указывает стрелка, является
функцией двух других множеств.
4.2.3. Роли в связях
Некоторое
множество
сущностей
может
многократно
фигурировать в одной и той же связи, от символа связи к множеству
проводится столько линий, сколько раз это множество участвует в
данной связи. Каждая из таких линий определяет роль, которую
множество играет в связи.
Пример 4.15. На рис. 50 изображена связь Быть_учеником
множества
Мастера
с
Наставник
самим собой. Каждая связь
– это связь между двумя
мастерами, один из которых
Быть_
Мастера
является учеником другого.
учеником
Для различения этих двух
мастеров, в рамках данной
связи одна линия отмечена
ролью Наставник, а другая
Ученик
ролью Ученик, которые
обозначают
мастераРис.50. Связь с Ученик
наставника и его ученика
соответственно. Предполагается, что у наставника может быть много
учеников, но у каждого ученика есть только один наставник. Таким
образом, стрелка E/R-диаграммы на рис. 50 показывает связь типа
"многие-к-одному" множества Ученик с множеством Наставник.
Пример 4.16. В качестве примера, включающего в себя
многостороннюю связь и множество сущностей со многими ролями,
на рис. 51 дается более сложная версия связи Договоры, введенной в
примере 4.5. Здесь показана связь Договоры между двумя цехами,
мастером и изделием. Для иллюстрации предполагается, что цех,
имеющий договор на пошив изделия с определенным мастером, может
заключить со вторым цехом договор, позволяющий привлекать
возможности другого цеха, например для получения каких-либо
материалов или выполнения тонких работ. Такая связь описывается
четверками вида:
(цех_1, цех_2, мастер, изделие),
причем цех_2 заключает с цехом_1 договор на привлечение мастера
цеха1 для изделия цеха2.
На рис. 51 есть стрелки, указывающие на Цеха в двух ролях: как
"владельца" мастера и как производителя изделия, но нет стрелок,
указывающих на Мастера или Изделия. Это значит, что при наличии
мастера, изделия и цеха, производящего изделие, только один цех может
"владеть" мастером. (Предполагается, что мастер имеет договор только
с одним цехом.) Аналогично, данное изделие производится
единственным цехом, поэтому при наличии мастера, изделия и цеха,
"владеющего"
мастером,
можно
определить
единственный
производящий изделие цех. Заметим, что обоих случаях для
определения уникальной сущности реально нужна только одна из
остальных сущностей (например, для определения уникального
производящего цеха необходимо знать только изделие), но этот факт
не изменяет множественное определение многосторонней связи.
Мастера
Договоры
Цех мастера
Изделия
Выполняющий цех
Цеха
Рис. 51. Четырехсторонняя связь
Стрелки не указывают на Мастера или Изделия. При наличии
мастера, "владеющего" им цеха и цеха, выпускающего изделия, может
быть заключено множество договоров, позволяющих мастеру работать
над различными изделиями. Значит, совсем не обязательно, что
остальные три компонента в четверке данной связи определяют
единственное изделие. Аналогично, производящий цех может
заключать контракт с другими цехами об участии нескольких их
мастеров при работе над одним своим изделием. Таким образом, мастер
не определяется тремя остальными компонентами данной связи.
4.2.4. Атрибуты связей
Бывает удобно приписывать атрибуты к связи, а не к одному из
множеств сущностей, находящихся в данной связи. Рассмотрим связь,
представляющую договор мастера с цехом на изготовление изделия
(рис. 49). Допустим, надо записать гонорар, указанный в этом
договоре. Однако гонорар нельзя связать с мастером, так как он
может получать разные гонорары за работу над разными
изделиями. Не очень хорошо связывать договор с цехом
(различным мастерам он может выплачивать разные гонорары)
или с изделием (разные мастера получают за подобные изделия
разные гонорары). Удобно связать гонорар с тройкой:
(мастер, изделие, цех)
во множестве отношений для связи Договоры. На рис. 52 показана
схема рис. 49 вместе с атрибутами. Связь имеет атрибут гонорар, а
множества сущностей имеют те же атрибуты, которые были
показаны на рис. 47.
Гонорар
назв_из
делия
размер
Изделия
Договоры
Имя
Фамилия
Мастера
Отчество
Адрес
тип_материала
название
Цеха
Адрес
Рис. 52. Связь с атрибутами
Размещать атрибуты на самих связях нет необходимости. Вместо
этого можно ввести новое множество сущностей с атрибутами,
приписанными данной связи, и включить такое множество в связь.
Пример 4.17. Изменим E/R-диаграмму (рис. 52), на которой
связь Договоры имеет атрибут гонорар.
гонорар
Гонорары
Договоры
Рис. 53. Перемещение атрибута в
множество сущностей
Создадим множество Гонорары с атрибутом гонорар (рис. 53).
4.2.5. Конвертирование многосторонних связей в бинарные
В ODL допустимы только бинарные связи, в отличие от E/Rмодели. Однако любую сложную связь, включающую в себя более двух
компонентов, нетрудно конвертировать в множество бинарных связей
типа "многие-к-одному" без потери какой-либо информации. В E/Rмодели можно ввести новое множество сущностей, элементами
которого являются кортежи множества отношений для многосторонней
связи. Такое множество называется множеством связующих
сущностей. Затем вводится связь типа "многие-к-одному" этого
множества связующих сущностей с каждым множеством сущностей,
предоставляющим элемент кортежей исходной многосторонней связи.
Если какое-то множество сущностей играет несколько ролей, оно
является целевым пунктом одной связи для каждой из ролей.
Пример 4.18. Четырехстороннюю связь (рис. 51) можно заменить
множеством сущностей под названием Договоры. Как показано на
рис. 54, это множество участвует в четырех связях. Если множество
отношений для связи Договоры имеет четверку
(цех_1, цех_2, мастер, изделие)
то сущность множества Договоры соединена связью от_мастера с
сущностью мастер из множества Мастера, связью изделие_от с
сущностью изделие из множества Изделия, а также связями
Цех_мастера и Выполняющий_цех соответственно с сущностями цех_1
и цех_2 из множества Цеха.
Вып_
цех
Издели
Изделия
е_отт
Договоры
Цеха
Предполагается, что у множества Договоры нет атрибутов, хотя
другие множества сущностей на рис. 54 имеют невидимые атрибуты.
Можно добавить атрибуты и множеству Договоры, например дату
подписания договора, сведения о заказчике.
Многосторонняя связь, подобная показанной на рис. 51, в ODL
изображалась бы способом, сходным с описанным выше
преобразованием для E/R-модели. Однако в ODL нет многосторонних
связей, поэтому данное преобразование не выбирается по желанию –
оно обязательно.
Пример 4.19. Допустим, есть классы Мастер, Изделие и Цех,
соответствующие каждому из трех множеств сущностей, показанных на
рис. 52. Для представления четырехсторонней связи Договоры вводится
новый класс Договор, не имеющий атрибутов, но имеющий четыре
связи, соответствующие четырем компонентам E/R-связи. ODLописание показано ниже; обратные связи пропущены. Каждая четверка
в E/R-связи Договоры соответствует объекту ODL-класса Договор.
interface Договор{
relationship Цех владеет_мастером;
relationship Цех выполняющий_цех;
relationship Мастер мастер_;
relationship Изделие изделие_;
};
4.2.6. Проектирование E/R моделей
Как уже говорилось, проект должен быть правильным
относительно описываемой предметной области. Сущности и их
атрибуты, должны отражать реальные объекты.
Простота
Не стоит вводить в проект больше элементов, чем это
необходимо.
Пример 4.20. Предположим, что вместо связи между Изделием и
Мастером было постулировано существование "договора на особых
условиях", предполагающего выполнение заказа на изделие только у
одного высококвалифицированного мастера и в самый короткий
срок. Тогда можно создать еще один класс или множество сущностей
Спецзаказ. Между изделием и единственным специальным
договором можно ввести связь обслуживает типа "один-к-одному".
И связь типа "многие-к-одному" множества Спецзаказ с множеством
Мастера завершает схему, показанную на рис. 55.
В принципе, такая структура правильно представляет реальный
мир, так как единственный цех, единственного мастера, можно
определять через спецзаказ. Однако множество Спецзаказ при этом
бесполезно, и лучше обойтись без него. Практическая реализация такого
множества приведет к программам, использующим более сложные связи
между мастерами и изделиями, занимает излишнее пространство
памяти и порождает ошибки.
Изделия
обслуживает
Спецзаказ
от_мастера
Мастер
Рис. 55. Слабый проект с ненужным множеством сущностей
Типы элементов проекта
Часто приходится выбирать тип элементов проекта, применяемых
для представления объектов реального мира. При этом часто выбор
заключается в том, что использовать: атрибуты или же классы,
множества сущностей. В общем случае атрибут проще реализовать,
чем любой класс/множество сущностей или связь. Впрочем, если все
делать только с помощью атрибутов, возникнут осложнения.
Пример 4.21. Рассмотрим пример, иллюстрирующий эффект от
применения многосторонней связи, и эквивалентный пример с
использованием бинарных связей. Связь Договоры между мастером,
изделием и двумя цехами (рис. 51) является четырехсторонней и
механически конвертируется в множество сущностей Договоры (рис.
54). Имеет ли значение, какой из этих подходов выбирается?
Решение в ODL однозначно, так как многосторонних связей не
существует. В E/R-модели приемлем любой подход. Однако
незначительное изменение исходной задачи практически вынуждает
нас выбирать подход, при котором используется множество
связующих сущностей. Для иллюстрации предположим, что в
договоре могут фигурировать один мастер, одно изделие, но любое
множество цехов. Эта ситуация сложнее той, что изображена на рис.
51, где было всего два цеха, играющие две роли. Сейчас допускается
любое число цехов. Один, возможно, выпускает изделие, в другом
делается плиссировка и т.д. Таким образом, приписать роли цехам
невозможно.
В данном случае оказывается, что множество отношений для
связи Договора должно содержать тройки вида
(мастер, изделие, множество цехов),
а сама связь Договоры – не только обычные множества сущностей
Мастера и Изделия, но и новое множество сущностей, элементами
которого являются множества цехов. Если такой подход допустим,
считать множества цехов базовыми сущностями неприемлемо.
Лучше считать множеством сущностей Договоры. Как и на
рис. 54, договор связывает мастера, изделие и множество цехов, но
теперь число цехов не ограничено. Поэтому между договорами и
цехами имеется связь типа "многие-ко-многим", а не "многие-кодному", как это было бы, если бы договора были настоящим
множеством "связующих" сущностей.
Изделия
изделие от
Догово
ры
Мастера
Цех_
Цеха
от_мас
тера
Рис. 56. Договоры, связывающие мастера, изделие
и множество цехов
Набросок E/R-диаграммы показан на рис. 56. Заметим, что здесь
договор связан с единственным мастером и единственным цехом, но
с произвольным множеством цехов.
Такая же стратегия проектирования подходит и для ODL.
Например, вполне приемлемо следующее описание интерфейса
ODL:
interface Договор{
relationship Мастер мастер1;
relationship Изделие изделие1;
relationship Set<Цех> цеха;
};
Здесь объекты договоров имеют три связи: с единственным
мастером, с единственным изделием и с множеством цехов.
Обратные связи опущены.
Определения подклассов
Как уже было рассмотрено, классы в ODL аналогичны
множествам сущностей в E/R-модели. Пусть класс С – это подкласс
класса D. Для выражения этого понятия в E/R-модели мы соединяем
множества сущностей, соответствующие классам С и D специальной
связью isa. Множества сущностей С и D обозначаются обычными
прямоугольниками. Атрибуты, или связи, относящиеся только к
сущностям С, присоединяются к прямоугольнику С, а атрибуты,
применимые к С и D, размешаются у D.
Связь isa обозначается линиями с треугольниками в середине.
Вершина каждого треугольника указывает на суперкласс.
Пример 4.22. На рис. 57 показаны множество сущностей Изделия
и два его подкласса: Кожаные_изделия и Меховые_изделия.
Треугольники, помеченные isa, указывают от Кожаные_изделия
и Меховые_изделия на суперкласс Изделия.
назв_изделия
isa
размер
Кожаные_
изделия
материал_
спин-ки
Изделия
к Мастера
тип_материала
isa
Меховые_
изделия
скорняжные
пошивы
Рис. 57. Связь isa в E/R-диаграмме
Связи мастером и относится, связывающие Изделия с Мастера
и Цеха, не показаны, но предполагается, что есть связь
скорняжные_пошивы между Меховые_изделия и Мастера.
Наследование в E/R-модели
Существует значительное отличие между наследованием в ODL
или других объектно-ориентированных моделях и наследованием в
E/R-модели. В ODL объект должен быть членом только одного
класса. В E/R-модели считается, что сущность имеет компоненты,
принадлежащие нескольким множествам сущностей, которые
являются частью isa-иерархии. Эти компоненты объединены в
единую сущность связями isa, и такая сущность имеет все атрибуты
своих компонентов, а также участвует во всех связях, в которых они
участвуют.
При таком подходе получается тот же эффект, что и в ODL, так
как наследование свойств дает объекту те же атрибуты и связи,
которые соответствующая ему сущность могла бы собрать из своих
компонентов.
При необходимости, вместо использования множественного
наследования, в
E/R-модели можно ввести новое множество
сущностей.
Моделирование ограничений
Как уже говорилось, описание базы данных включает
ограничения или правила, позволяющие более адекватно описать
предметную область, уменьшить возможность возникновения
ошибок и аномалий.
Ключи
Аналогично классам ODL, множество сущностей может также
иметь ключи. Если множество атрибутов формирует ключ для
множества сущностей, в нем не может быть двух сущностей, чьи
значения совпадают для каждого атрибута ключа. В нотации E/Rдиаграммы подчеркиваются атрибуты, принадлежащие ключу для
любого множества сущностей.
Имя
Адрес
Фамилия
Мастера
Отчество
Рис.58. Множество сущностей Мастера с отмеченным ключом
На рис. 58 показано множество сущностей Мастера из рис. 47 с
атрибутами фамилия, имя, отчество, которые вместе служат ключом.
В модели может быть несколько ключей, при в E/R-модели
отсутствуют средства для указания всех ключей. Принято выделять
один ключ в качестве первичного и рассматривать множество его
атрибутов как единственный ключ для множества сущностей.
Первичный ключ В E/R-модели первичный ключ выделяется
подчеркиванием, а другие ключи, называемые вторичными, либо не
отмечаются, либо перечисляются в комментарии на краю диаграммы.
Возможна необычная ситуация, когда ключ для множества
сущностей не принадлежит самому этому множеству. Такой случай
называется "слабыми множествами сущностей".
Ссылочная целостность
В E/R-диаграммах можно расширить функции стрелок таким
образом, чтобы они показывали, ожидается ли ссылочная целостность
данной связи в одном или нескольких направлениях. Пусть R – это
связь множества сущностей Е с множеством сущностей F. Стрелка с
закругленным "острием", указывающая на F, означает не только то,
что Е и F находятся в связи типа "многие-к-одному" или "один-кодному", но и то, что должно существовать множество Е. То же самое
относится к случаю, когда R – связь между более чем двумя
атрибутами.
Пример 4.23. На рис. 59 показано ограничение ссылочной
целостности для множеств Изделия, Цеха и Начальники. Эти
множества и связи впервые были введены на рис. 47 и рис. 48.
Закругленная стрелка, указывающая от связи обеспечивает на
множество Цеха выражает ограничение ссылочной целостности,
состоящее в том, что цех, обеспечивающий работу над изделием,
должен всегда присутствовать в множестве Изделия.
Изделия
Обеспеч
ивает
Цеха
Возглав
ляет
Начальники
Рис. 59. E/R-диаграмма, показывающая ограничения
ссылочной целостности
Аналогично, вторая закругленная стрелка от Возглавляет к Цеха,
означает: если начальник возглавляет цех, то этот цех обязательно
существует в множестве Цеха.
Заметим, что от Возглавляет на Начальник по-прежнему
указывает обычная стрелка, выражая разумное допущение о связи
между начальниками и их цехами. Если цех прекращает свое
существование, ее начальник больше не может называться
начальником (цеха) и должен быть удален из множества Начальники.
Поэтому закругленная стрелка указывает на Цеха. Если же из базы
данных удален начальник, цех может продолжать существовать.
Поэтому на Начальники указывает обычная стрелка, обозначающая,
что у каждого цеха есть только один начальник, но иногда он может
быть и без начальника.
Дополнительные ограничения
Для конкретной базы данных могут быть введены также другие
ограничения (правила целостности).
Например, учитывая оборот изделий и реальные возможности
мастеров, можно ввести правило, чтоб у каждого мастера было не
более десяти изделий.
В E/R диаграммах соответствующим образом помечают линии
между символами связи и множества сущностей, как в следующем
примере (рис. 60).
Изделия
мастером
10
Мастера
Рис. 60. Схема ограничения количества
изделий на одного мастера
Слабые множества сущностей
В ряде случаев для полного определения ключа некоторого
множества сущностей используются атрибуты, которые частично или
полностью принадлежат другому множеству сущностей. Множество с
таким ключом называется слабым множеством сущностей.
Появление слабых множеств сущностей связано с двумя
основными причинами. Во-первых, часто множества сущностей
выстраиваются в иерархию. Когда сущности множества Е являются
составными частями сущностей множества F, возможно, что имена
сущностей Е не уникальны до тех пор, пока не будет учитываться имя
той сущности из F, которой подчинена сущность из Е.
Во-вторых, слабые множества сущностей могут быть результатом
использования множеств связующих сущностей, которые вводятся для
устранения многосторонних связей. Эти множества сущностей
часто не имеют собственных атрибутов, их ключи формируются из
атрибутов, являющихся ключевыми для множеств, с которыми они
связаны.
Пример 4.24.
Данный пример иллюстрирует описание иерархии, которая
отображается с использованием слабых множеств сущностей. В цехе
может работать несколько бригад, которые обозначаются "бригада 1",
"бригада 2" и т.д. Но так же могут обозначить свои бригады и другие
цеха, поэтому атрибут номер не является ключом для бригад. Для
определения уникального имени бригады необходимы название цеха,
которому она принадлежит, и номер. Такая ситуация изображена на
название
номер
Бригады
Часть_
от
Цеха
адрес
Рис.61. Слабое множество сущностей
и его связи
рис. 61. Ключ для слабого множества сущностей Бригады состоит из
его собственного атрибута номер и атрибута название единственного
цеха, с которым данная бригада находится в связи Часть_ от типа
"многие-к-одному".
Ключевые атрибуты для слабого множества сущностей нельзя
получить произвольным образом. Если Е– слабое множество
сущностей, то каждое из множеств F, поставляющих один ключевой
атрибут для Е или более, должно быть соединено с Е связью R. Кроме
того, необходимо выполнить следующие условия:
1. R должно быть бинарной связью типа "многие-к-одному"
между E и F.
2. Атрибуты F, используемые в ключе для Е, должны быть
ключевыми атрибутами множества F.
3. Если F само является слабым, атрибуты F, используемые в
ключе для Е, могут быть атрибутами множества сущностей, с
которым F соединено связью типа "многие-к-одному.
4. Если есть несколько связей типа "многие-к-одному" между Е
и F, эти связи можно использовать для получения копий ключевых
атрибутов F, позволяющих сформировать ключ для Е. Заметим, что
сущность е из Е может быть связана с многими сущностями в F
посредством различных связей из Е. Поэтому ключи многих
различных сущностей из F могут появляться в ключевых значениях,
идентифицирующих отдельную сущность е из Е.
Для обозначения слабого множества сущностей и описания его
ключевых атрибутов принимаются следующие соглашения.
1. Слабое множество обозначается двойным прямоугольником.
2. Связи типа "многие-к-одному" слабого множества с другими
множествами сущностей, поставляющими для него ключевые
атрибуты, обозначаются двойными ромбами.
3. Если множество сущностей поставляет атрибуты для
собственного ключа, эти атрибуты подчеркиваются.
Эти соглашения суммируются в виде правила:
Множество сущностей с двойной границей является слабым. Его
ключ состоит из его собственных подчеркнутых атрибутов (если
таковые имеются) и ключевых атрибутов тех множеств, с которыми
данное слабое множество соединено связями типа "многие-к-одному",
имеющими двойную границу.
В объектно-ориентированных системах вопрос о поиске ключа
никогда не возникает, всегда можно построить ключ путем описания
атрибута или атрибутов, хотя это и необязательно. Объект обладает
свойством "целостности объекта" и в результате имеет адрес, по
которому его можно найти, a ID объекта уникальным образом
отличает один объект от другого даже тогда, когда их невозможно
различить по значениям их атрибутов или связям. А E/R-модель
"ориентирована на значение", и сущности различимы только по
связанным значениям их атрибутов. Поэтому нужно всегда
учитывать, что в E/R-моделях сущности любого множества можно
различать только по значениям, не обращаясь ни к какой
"идентичности объектов".
Переход от E/R-диаграмм к реляционным проектам
Переход от диаграммы "сущность-связь" к реляционной схеме БД
принципиально аналогичен переходу к ней от проекта ODL. Данный
переход достаточно хорошо формализуем.
1. Все простые сущности преобразуется в таблицу. Простая
сущность – сущность, не являющаяся подтипом и не имеющая
подтипов. Имя сущности становится именем таблицы.
2. Атрибуты становится возможными столбцами с тем же
именем; может выбираться более точный формат. Столбцы,
соответствующие необязательным атрибутам, могут содержать
неопределенные значения; столбцы, соответствующие обязательным
атрибутам, – не могут.
3. Ключи ER-модели преобразуются в первичный ключ таблицы.
Если имеется несколько возможных ER-ключей, выбирается наиболее
используемый ключ. Если в состав ключа ER-модели входят связи, к
числу столбцов первичного ключа добавляется копия уникального
идентификатора сущности, находящейся на дальнем конце связи (этот
процесс может продолжаться рекурсивно). Для именования этих
столбцов используются имена концов связей и/или имена сущностей.
4. Связи многие-к-одному (и один-к-одному) становятся
внешними ключами. Необязательные связи соответствуют столбцам,
допускающим неопределенные значения; обязательные связи –
столбцам, не допускающим неопределенные значения.
5. Индексы создаются для первичного ключа (уникальный
индекс), внешних ключей и тех атрибутов, на которых предполагается
в основном базировать запросы.
6. Если в концептуальной схеме присутствовали слабые
сущности, то возможны два способа:
 все слабые сущности в одной таблице (а);
для каждой слабые сущности – отдельная таблица (б).
При применении способа (а) таблица создается для наиболее
внешнего супертипа, а для подтипов могут создаваться
представления.
При использовании метода (б) для каждого подтипа первого
уровня (для более нижних используются представления) супертип
воссоздается с помощью представления UNION (из всех таблиц
подтипов выбираются общие столбцы – столбцы супертипа).
7. При наличии исключающих связей (сущность может быть
расщеплена на два или более взаимно исключающих подтипа, каждый
из которых включает общие атрибуты и/или связи) имеется два
способа работы.
 общий домен (а);
 явные внешние ключи (б).
Если остающиеся внешние ключи находятся все в одном домене,
т.е. имеют общий формат (способ (а)), то создаются два столбца:
идентификатор связи и идентификатор сущности. Столбец
идентификатора связи используется для различения связей,
покрываемых дугой исключения. Столбец идентификатора сущности
используется для хранения значений уникального идентификатора
сущности на дальнем конце соответствующей связи.
Если результирующие внешние ключи не относятся к одному
домену, то для каждой связи, покрываемой дугой исключения,
создаются явные столбцы внешних ключей; все эти столбцы могут
содержать неопределенные значения.
Преимущества перехода к схеме БД от E/R-моделей по
сравнению с ODL-проектом заключаются в следующем:
 Отношения
часто
можно
"нормализовать",
избегая
избыточности,
присутствующей
в
проекте,
полученном
непосредственно из описания ODL.
 Двухсторонние связи ODL заменяются единственным
отношением, представляющим связи в обоих направлениях.
В заключение раздела необходимо отметить, что приведенная
графическая нотация диаграмм “сущность-связь" не является
единственно допустимой. Существуют и другие способы
изображения,
например,
сущности
могут
изображаться
прямоугольниками, содержащими имя и список атрибутов; в
соответствии с изображением сущностей, связи также могут быть
представлены определенным образом.

Контрольные вопросы и задания
1. Пояснить основные положения объектно-ориентированного
проектирования.
2. Каким образом представляются объекты в ODL?
3. Как описываются атрибуты в ODL?
4. Охарактеризовать типы связей в ODL.
5. Привести пример обратной связи в ODL.
6. Привести пример связи "многие-ко-многим" в ODL.
7. Привести пример связи "многие-к-одному" в ODL.
8. Привести пример связи "один-к-одному" в ODL.
9. Перечислить базовые типы данных в ODL.
10. Чем отличается тип множество от типа мультимножество?
11. Перечислить принципы проектирования с использованием
ODL.
12. Что такое подкласс?
13. Привести пример множественного наследования в ODL.
14. Каким образом осуществляется моделирование ограничений
в ODL?
15. Какова последовательность действий для преобразования
ODL-модели в реляционную?
16. Перечислить компоненты E/R диаграммы.
17. Каким образом выражается множественность связей в E/R
диаграммах?
18. Привести примеры многосторонних связей.
19. В чем заключается суть ролей в связях?
20. Привести пример перемещения атрибута в множество
сущностей.
21. Описать слабые множества сущностей.
22. Какова технология конвертирования многосторонних связей в
бинарные?
23. Указать рекомендации по проектированию E/R-моделей.
24. Каким образом выбираются типы элементов проекта?
25. Для чего предназначена связь isa?
26. Как осуществляется моделирование ограничений в E/Rмодели?
27. Описать технологию перехода от E/R-модели к реляционной
модели.
28. Спроектировать БД предприятия, содержащую информацию о
сотрудниках и отделах, в которых работают сотрудники. Информация
о сотруднике – это его имя, адрес, телефон, должность, номер
паспорта. Отдел имеет название, число сотрудников, начальника.
Описать в ODL данную БД.
29. Описать в ODL БД, содержащую следующую информацию о
командах, игроках и их спонсорах:
 название
каждой
команды,
ее
игроков,
капитана
(одного из игроков) и цвета ее спортивной формы;
 имя, фамилия, отчество, место в команде (вратарь, защитник и
т. д.) каждого игрока.
 информацию о спонсорах.
30. Изменить предыдущее задание, указав, за какие команды
выступал каждый из игроков, включая начальную и конечную даты
его выступления за каждую из команд.
31. Составить генеалогическое дерево династии. Имеется
единственный класс. Информация, которую необходимо записать о
человеке, состоит из его имени (атрибут) и следующих связей: мать,
отец и дети. Опишите в ODL класс Особа. Обязательно указать
обращения связей, которые, подобно, мать, отец и дети, служат и
связями класса Особа с самим собой. Является ли дети инверсией
связи мать? Почему? Описать каждую связь и ее обращение как
множества пар.
32. Допустимо ли, чтобы тип был одновременно типом атрибута
ODL и типом связи ODL? Объяснить, почему.
33. В условия задания 1 добавлены новые элементы – проекты.
Проект имеет название, общий бюджет, объединяет несколько
сотрудников для его выполнения. Описать такую БД в ODL.
34. Представить БД предприятия из задания 1 в виде Е/Rмодели. Обязательно ввести стрелки (там, где они необходимы) для
выражения множественности связи.
35. Представить БД команды/игроки /болельщики из задания
2 в виде E/R-модели. Учтите, что множество цветов – неподходящий
тип атрибута для команд. Как можно обойти это ограничение?
36. Альтернативный способ представления информации задания
4, ввести тернарную связь Семья, полагая, что тройкой в множестве
отношений для Семья является (особа, отец, мать) и все ее члены,
разумеется, входят во множество Люди.
 составить диаграмму с указанной связью (не включая в нее
информацию об образовании). Использовать стрелки там, где они
необходимы;
 заменить тернарную связь Семья множеством сущностей и
бинарными связями; для отражения множественности связей
используйте стрелки.
37. Пусть в условиях задания 1 каждый отдел имеет сектор, с
названиями сектор1, сектор2, и т.д. Сотрудники относятся
непосредственно к секторам. Привести полную Е/R – диаграмму
такой информационной системы.
38. Один из способов представления студентов и оценок,
полученных ими на учебных курсах, использование множеств
сущностей, соответствующих студентам, курсам и "зачислениям".
Зачисления образуют множество "связующих" сущностей между
студентами и курсами. Их можно использовать не только для
представления того факта, что студент проходит определенный
курс, но для выражения отметок, полученных студентом по
данному курсу. Представить эту ситуацию в E/R-диаграмме, указав
слабые множества сущностей и их ключи. Является ли отметка
частью ключа для "зачислений"?
39. Выбрать и определить ключи для ODL-разработок из
задания 1.
40. Выбрать и определить ключи для Е/R – диаграмм из
задания 2.
5. БАЗЫ ДАННЫХ В СЕТЯХ
Повсеместное внедрение и развитие сетевых технологий,
тенденция к распределению вычислительных ресурсов накладывает
отпечаток на принципы построения СУБД. Применение сетевых
технологий позволило значительно укрупнить информационные
системы, увеличить число пользователей, обеспечить целостность в
рамках всей системы.
В основе построения сетевых систем управления данным лежат
два подхода: централизованный и децентрализованный. При
централизованном подходе систему баз данных можно рассматривать
как структуру, состоящую из двух частей – сервера и набора
клиентов. Под сервером в данном контексте понимается СУБД, а
клиенты – это различные приложения, инициирующие запросы на
услуги к серверу. Данный вариант архитектуры называется
архитектурой "клиент-сервер". Разделение системы баз данных на две
части определяет возможность обработки этих частей на разных
машинах. Поэтому можно говорить о распределенной обработке
информации. Распределенная обработка может быть разнообразной и
осуществляться на разных уровнях.
Децентрализованный подход предусматривает возможность
определенного узла сети выступать как в роли клиента, так и в роли
сервера данных. Очевидно, что в этом случае значительно
усложняются задачи поддержки транзакций и обеспечения
целостности.
В этой главе мы рассмотрим некоторые варианты
распределенной обработки данных .
5.1. Архитектура "клиент-сервер"
Определим основные понятия сервер и клиент. Под сервером в
информационных системах понимается программа (компьютер),
предоставляющая
услуги
по
запросам
других
программ
(компьютеров), называемых клиентами. В контексте баз данных
вводится понятие сервер баз данных [15]:
1. СУБД в архитектуре "клиент-сервер".
2. Компьютер в сети, на котором поддерживается база данных и
осуществляется обработка пользовательских запросов.
Сервер баз данных осуществляет целый комплекс действий по
управлению данными. Перечислим его основные функции:
 выполнение пользовательских запросов на выбор и
модификацию данных и метаданных;
 хранение и резервное копирование данных;
 поддержка ссылочной целостности данных согласно
правилам, определенным в базе данных;
 обеспечение авторизованного доступа к данным на основе
проверки прав и привилегий пользователей;
 протоколирование операций и ведение журнала транзакций
(сущность транзакции будет рассмотрена ниже).
Клиентские узлы поддерживают пользовательские интерфейсы и
функциональность приложений.
Основой архитектуры "клиент-сервер" является принцип
централизации хранения и обработки данных. Централизованная база
данных физически сосредоточена в одном месте и управляется одним
компьютером-сервером. Классическая двухзвенная схема "клиентсервер" представлена на рис. 62.
БД
Сервер БД
СУБД
Клиент 1
Клиент 2
. . . . . . . . . . .
.
Клиент N
Рис. 62. Архитектура "клиент – сервер"
Архитектура "клиент-сервер" допускает различные варианты
реализации. В первоначальном (централизованном) варианте
архитектуры
"клиент-сервер"
приложение
(пользовательская
программа) не разбивалось на части, используя ресурсы только
одного мощного компьютера. СУБД, данные и приложения хранились
на одном мощном мини-компьютере или мейнфрейме, принимающим
входную информацию с пользовательского терминала и
отображающего на нем данные (разделение функций было на
процессном уровне – один процесс выполнял функции клиента,
другой – сервера). С появлением персональных компьютеров и
локальных
вычислительных
сетей
появилась
возможность
распределения ресурсов по всем компьютерам сети с позиции
максимального использования их ресурсов. Основным принципом
разбиения приложения на части является разделение на группы
функций стандартного интерактивного приложения:
1. Функции ввода и отображения данных (Presentation Logic –
презентационная логика). К этой функции относятся все
интерфейсные экранные формы, с которыми работает пользователь, а
также отображаемая на экране результативная
и справочная
информация.
2. Прикладные функции, определяющие основные алгоритмы
решения задач (Business Logic – бизнес-логика).
3. Функции обработки данных внутри приложения (Database
Logic – логика обработки данных).
4. Функции управления информационными ресурсами (Database
Manager Logic). Это собственно СУБД, обеспечивающая хранение и
управление базами данных.
5. Служебные функции, играющие роль связок между
функциями первых четырех групп.
В децентрализованной архитектуре "клиент-сервер" существуют
различные варианты распределения функций между компьютеромсервером и компьютером-клиентом в двухзвенной модели: от
мощного сервера , на котором производится практически вся работа,
до мощного клиента, когда большая часть функций выполняется
компьютером-клиентом, а сервер обрабатывает поступающие к нему
по сети SQL-запросы. Рассмотрим наиболее популярные из них них.
В модели удаленного доступа к данным (Remote Data Access,
RDA) на сервере хранится база данных и ядро СУБД. На клиенте
располагается презентационная логика и бизнес-логика. Клиент
обращается к серверу с запросом на языке SQL, либо посредством
средств пользовательского интерфейса (API). Данную модель
поддерживает большое число серверных СУБД, имеющих SQLинтерфейсы, и инструментальных средств, обеспечивающих создание
клиентской части.
Модель сервера БД ( Database Server – DBS) характеризуется тем,
что функции компьютера-клиента ограничиваются презентационной
логикой. Большая часть бизнес-логики переложена на сервер. Иногда
такую модель называют моделью с "тонким клиентом". Эта модель
является более технологичной, чем RDA и применяется в таких СУБД
как Informix, Ingres, Sybase, Oracle, SQL MS Server.
Существуют и более сложные варианты реализации архитектуры
"клиент-сервер", например, трехзвенные информационные системы с
использованием серверов приложений, реализующих бизнес-логику
информационной системы (модель сервера приложений – Application
Server (AS)) (рис. 63).
БД
Сервер БД
СУБД
Сервер
приложений
1
Сервер
приложений
2
. . . .
. .
. . . .
. .
Клиент 1
. . .
Сервер
приложений
N
. . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . .
. .
Клиент M
Рис. 63. Трехзвенная модель архитектуры "клиент - сервер
"
Центральным звеном модели является сервер приложений, на
котором реализуется несколько прикладных функций. Серверов
приложений может быть несколько, и каждый из них представляет
свой вид сервиса.
Программные средства сервера приложений относятся к
категории программного обеспечения промежуточного слоя, которое
определяется как "некоторый набор процедур или функций,
обеспечивающих взаимодействие двух разнородных программ".
Программные средства этой категории применимы к компьютерным
сервисам практически любого вида, включая управление базами
данных и информацией. Многие компании-поставщики программного
обеспечения выпускают программные продукты, основанные на
стандартах IDAPI, ODBC, DRDA или других стандартах
промежуточного
слоя
и
предоставляющие
интерфейсные
возможности для клиента и сервера.
Затрагивая вопрос о категории промежуточного слоя необходимо
упомянуть о программных системах промежуточного слоя –
мониторах транзакций.
Транзакцией
называется
совокупность
операций
манипулирования данными (вставкой, удалением, выборкой,
обновлением) в системах баз данных, которая переводит базу данных
из одного целостного (непротиворечивого) состояния в другое
целостное состояние. Транзакция рассматривается как некоторое
неделимое с точки зрения пользователя действие над базой данных.
Например, транзакцией может быть последовательность операций по
формированию заказа на сборку компьютера в компьютерной фирме:
ввод нового заказа с реквизитами заказчика, формирование
платежного документа, запрос на комплектующие. С точки зрения
сотрудника компьютерной фирмы, это единая операция: если она
будет прервана, то база данных потеряет свое целостное состояние.
Восстановление данных в СУБД является составной часть управления
данными и подразумевает восстановление самой базы данных, т.е.
возвращение базы данных в правильное состояние в случае изменения
данных в результате сбоя. Восстановление данных реализуется через
механизм транзакций. Завершение транзакции означает, что все
операции, входящие в состав транзакций, успешно завершены и
результат их работы сохранен в базе данных. Откат транзакции
означает, что все уже выполненные операции отменяются и все
объекты базы данных, затронутые этими операциями возвращены в
исходное состояние. Для реализации возможности отката транзакций
большинство СУБД поддерживают запись в журналы транзакций,
позволяющие сохранять промежуточные состояния и восстанавливать
исходные данные при откате. Существуют различные модели
транзакций [10,14, 26 и др.].
Под монитором обработки транзакций (Transaction Processing
Monitor – TPM) понимаются средства программного обеспечения
промежуточного
слоя,
предназначенные
для
обеспечения
эффективного управления информационными и вычислительными
ресурсами в распределенных системах при обработке транзакций.
Понятие транзакции в TPM шире, чем транзакция в СУБД.
Основными
функциями
TPM
являются:
аутентификация
пользователей и проверка полномочий доступа, управление
коммуникациями, необходимыми для выполнения транзакций,
собственно управление транзакциями, включая управление
блокировкой ресурсов, журнализацию, фиксацию, откаты и
восстановление транзакций [15].
Основное достоинство архитектуры "клиент-сервер" заключается
в снижении сетевого трафика при выполнении запросов и
распределении процесса загрузки базы данных. SQL обеспечивает
определенный интерфейс между клиентской и серверной системой,
эффективно передавая запросы к базе данных. Преимущества данной
архитектуры обеспечили ей большую популярность. Многие
известные
компании-поставщики
программного
обеспечения
предлагают серверные СУБД и инструментальные средства
разработки клиентских приложения.
5.2. Распределенные базы данных
В настоящее время существует два класса СУБД: настольные и
серверные. Работа с небольшой базой данных, расположенной на
Коммуникационная сеть
Сервер БД 1
Клиент 1
. . .
. . .
БД
. . .
БД
Сервер БД 2
. . .
Клиент N
Клиент M
Рис. 64. Распределенная база данных
Клиент P
персональном компьютере, не подключенном к локальной сети
(настольный вариант СУБД), становится уже нехарактерным для
настоящего времени.
Компьютеры объединяются в локальные сети.
Даже если разрабатывается БД для небольшой фирмы, всегда
есть территориально-удаленные специфичные пользователи.
Распределенная база данных состоит из составных частей,
размещенных на разных узлах сети в соответствии с каким-либо
критерием (рис. 64).
Распределенные
базы
данных
(РаБД)
управляются
распределенными системами управления базами данных (РаСУБД).
Существуют различные модели распределения данных. РаБД могут
работать под управлением одинаковых и неодинаковых СУБД. В
первом случае говорят об однородных распределенных системах, во
втором – о неоднородных.
Однородные распределенные системы баз имеют в своей основе
один продукт СУБД, обычно с единственным языком баз данных
(например, SQL с расширениями для управления распределенными
данными). Существует множество различных вариантов построения
однородной системы РаБД. Например, на некотором узле
вычислительной сети может располагаться одна глобально доступная
"главная машина СУБД", с которой связаны компоненты для доступа
к данным локальных баз данных, размещенные совместно с самими
этими базами данных в пределах всей компании (или отдельного ее
подразделения в зависимости от масштаба распределения). Более
сложные модели могут допускать распределенность самой СУБД,
когда каждый ее компонент "на равных правах" имеет доступ к
данным любого другого узла.
Неоднородные системы включают два или более существенно
различающихся продукта управления данными. Неоднородные
системы баз данных можно, в свою очередь, также подразделить на
классы в широком диапазоне – от федеративных систем, до
различных типов систем мультибаз данных.
Однородные распределенные системы баз данных обычно
проектируются методом "сверху вниз", в целом аналогично
проектированию
централизованных
баз
данных
(создание
концептуальной, логической, физической моделей данных).
Неоднородные же, напротив, чаще всего строятся "снизу вверх" с
целью создать общую среду управления над существовавшими ранее
разрозненными базами данных. Основной проблемой при этом
становится объединение схем баз данных, таким образом, чтобы
предоставить как новым, так и прежним приложениям доступ и к
новым и к прежним ресурсам данных. Процесс создания системы
мультибаз данных технически сложен и нетривиален.
При создании однородных распределенных баз данных
используется два метода распределения данных: фрагментация и
тиражирование.
Фрагментация означает декомпозицию объектов базы данных,
таких, как реляционные таблицы, на две или более частей, которые
размещаются на разных компьютерных системах.
Проиллюстрируем это понятие примером из [24]. В БД имеется
таблица, содержащая данные о сотрудниках, работающих в
различных филиалах, или о заказах на продажу. Таблица может быть
разделена на фрагменты по географическому или другому
характеристическому признаку.
При горизонтальной фрагментации делаются горизонтальные
"срезы" в соответствии со значением какого-либо столбца таблицы.
Строки данных о сотрудниках могут разбиваться на подмножества,
соответствующие филиалам. Данные о продажах фрагментируются по
магазинам, где эти продажи производились
При
вертикальной
фрагментации
разбиение
таблицы
осуществляется не по строкам, а по столбцам. В этом случае
некоторая часть информации о каждом сотруднике хранится в одном
месте, а другая часть (относящаяся к той же таблице) – в другом.
Независимо от вида фрагментации, поддерживается глобальная
схема, представляющая единое описание всех составляющих ее
локальных баз данных, позволяющая воссоздать из имеющихся
фрагментов логически централизованную таблицу или другую
структуру базы данных.
Основным достоинством модели фрагментации является то, что
пользователи всех узлов (при исправных коммуникационных
средствах) получают информацию с учетом всех последних
изменений. Второе достоинство состоит в экономном использовании
внешней памяти компьютеров, что позволяет организовывать БД
больших объемов.
К недостаткам модели распределенной БД, основанной на
фрагментации данных, относится следующее: жесткие требования к
производительности и надежности каналов связи, а также большие
затраты коммуникационных и вычислительных ресурсов из-за их
связывания на все время выполнения транзакций. При интенсивных
обращениях
к
распределенной
БД,
большом
числе
взаимодействующих узлов, низкоскоростных и ненадежных каналах
связи обработка запросов по этой схеме становится практически
невозможной.
Тиражирование (или репликация) означает создание копий
некоторых фрагментов базы данных с целью приближения данных к
месту их использования. Основное достоинство метода заключается в
сокращении сетевого трафика и увеличение производительности
системы. Репликаторы представляют множество различных
физических копий некоторого объекта базы данных (обычно
таблицы), для которых в соответствии с определенными в базе
данных правилами поддерживается синхронизация (идентичность) с
некоторой "главной" копией. Теоретически значения всех данных в
тиражированных объектах должны автоматически и незамедлительно
синхронизироваться друг с другом. (На практике это правило обычно
несколько ослабляется.) В некоторых системах копии используются
исключительно в режиме чтения и обновляются в соответствии с
заданным расписанием. В других средах допускается модификация
отдельных значений в копиях, и эти изменения распространяются в
соответствии с процедурами планирования и координации.
Подробнее с различными моделями тиражирования можно
ознакомится в [24.]
Основной недостаток метода тиражирования БД заключается в
том, что на некотором интервале времени возможно "расхождение"
копий БД.
Различные поставщики предлагают множество программных
продуктов, позволяющих управлять распределенными ресурсами.
При этом в результате общего соглашения определились некоторые
характеристики "идеальной" РаСУБД:
 Прозрачность
относительно
местоположения.
Для
пользователя не должно быть разницы где физически находятся
данные, данные должны "выглядеть" так, если бы они находились на
локальном компьютере.
 Гетерогенные системы. СУБД должна работать с данными,
которые хранятся на системах с различной архитектурой и с разной
производительностью.
 Прозрачность относительно сети. СУБД должны работать
одинаково в разнородных сетях: от высокоскоростных ЛВС до
телефонных линий.
 Распределенные запросы. У пользователя должна быть
возможность строить запросы из любых таблиц, вне зависимости от
их реального физического расположения.
 Распределенные изменения. У пользователя должна быть
возможность изменять данные в любой таблице, независимо от
реального физического расположения таблиц и самого пользователя.
 Распределенные транзакции. СУБД должна выполнять
транзакции, выходящие за границы одной вычислительной системы, и
при этом поддерживать целостность данных при появлении отказов,
как в отдельных системах, так и в сети в целом.
 Безопасность. СУБД должна обеспечить защиту всей
распределенной базы от несанкционированного доступа.
 Универсальный доступ. СУБД должна обеспечивать единую
методику доступа ко всей корпоративной базе данных.
Следует отметить, что в силу ряда причин ни одно из
существующих распределенных СУБД не соответствует "идеалу" в
полной мере. Распределенные базы данных являются одним из
стратегических направлений развития вычислительной техники,
поэтому решение вышеперечисленных задач следует искать на пути
разработки новых подходов к обработке распределенных данных.
Доступ к данным в условиях распределенности представляет
сложную задачу, требует выделения значительных вычислительных
ресурсов и затрат на передачу информации. В рамках решения данной
комплексной задачи специалистами IBM была предложена
четырехуровневая схема доступа к распределенным данным, такое
расчленение проблемы обеспечивает хорошую основу для понимания
принципов управления распределенными ресурсами.
Уровень 1. Удаленный запрос.
Локальная система
Транзакция
Транзакция
Транзакция
Транзакция
Удаленная система
Инструкция
СУБД
БД
Инструкция
Инструкция
Инструкция
Удаленная система
СУБД
БД
Рис. 65. Доступ к распределенным данным: удаленные запросы
На данном уровне пользователь может выполнить инструкцию
SQL, которая производит доступ или модификацию информации в
одной удаленной базе данных (рис. 65).
Пользователь может таким образом обращаться к разным базам
данных, но при этом СУБД не поддерживает транзакции, состоящие
из нескольких инструкций (согласно терминологии IBM, транзакция –
"удаленная единица работы").
Очевидно, что возможности удаленных запросов ограничены,
такие запросы
полезны в условиях однократного или
кратковременного доступа к данным, хранящимся на удаленной
станции. При этом обработка данных производится в основном
средствами станции, инициирующей запрос.
Уровень 2. Удаленная транзакция.
На данном уровне
обеспечиваются более сложные транзакции, состоящие из нескольких
инструкций SQL (рис. 66)
Локальная система
Удаленная система
Инструкция
Транзакция
Инструкция
СУБД
БД
Удаленная система
Инструкция
Транзакция
Инструкция
СУБД
БД
Рис. 66. Доступ к распределенным данным: удаленные транзакции
У пользователя появляется возможность задать СУБД
последовательность инструкций SQL, осуществляющих доступ и
модификацию данных в удаленной базе, а затем выполнить или
отменить всю последовательность целиком, как одну транзакцию,
которая может быть успешно завершена или целиком отвергнута. При
этом все инструкции, составляющие транзакцию, должны быть
адресованы к одной базе данных.
Для обеспечения связи СУБД различных типов при удаленных
транзакциях часто используются так называемые шлюзовые
программы. Некоторые шлюзовые программы не только
обеспечивают выполнение удаленных транзакций, но и дают
пользователю возможность объединять в одном запросе таблицы из
локальной базы данных с таблицами из удаленной базы данных,
управляемой СУБД другого типа. Однако эти программы не
обеспечивают (и не могут обеспечить) выполнение транзакций,
необходимых для реализации более высоких уровней доступа к
распределенным данным. Например, шлюзовая программа может
обеспечить по отдельности целостность локальной базы данных и
целостность удаленной базы данных, но не гарантирует полного
выполнения транзакций в разных узлах сети.
Уровень 3. Распределенная транзакция (рис. 67). На данном
уровне каждый отдельный пользователь по средством SQL может
обращаться с запросом на выборку или модификацию данных к одной
базе данных в одной удаленной вычислительной системе. Транзакция,
представляющая собой последовательность операторов SQL, может
обращаться к двум или более базам данных, которые могут быть
расположены в различных системах. При этом СУБД гарантирует
целостность транзакций, т. е. то, что все части транзакции во всех
участвующих системах будут завершены или целиком отменены.
Очевидно, что уровень сложности системы, поддерживающей
подобные транзакции должен быть на порядок выше, чем для
Локальная система
Удаленная система
Инструкция
Транзакция
Инструкция
Инструкция
Транзакция
Инструкция
СУБД
БД
Удаленная система
СУБД
БД
Рис. 67. Доступ к распределенным данным: распределенные транзакции
предыдущих.
Чтобы обеспечить выполнение распределенной транзакции
необходимо активное взаимодействия отдельных СУБД, участвующих
в транзакции. Данное взаимодействие обычно осуществляется при
помощи специального протокола, называемого протоколом двухфазного
выполнения, основное назначение которого поддерживать целостность
распределенных транзакций без участия пользователя.
Уровень 4. Распределенный запрос (рис. 68). На данном уровне
один оператор SQL может обращаться к таблицам из двух или более баз
данных, которые расположены в различных вычислительных системах.
При этом СУБД отвечает за автоматическое выполнение оператора во
всех системах, участвующих в запросе. Транзакция представляет собой
последовательность инструкций. Как и на предыдущем уровне, СУБД
должна обеспечить целостность распределенной транзакции во всех
участвующих системах.
Локальная система
Удаленная система
Инструкция
Транзакция
Инструкция
Инструкция
СУБД
Удаленная система
СУБД
Транзакция
БД
БД
Инструкция
Рис. 68. Доступ к распределенным данным: распределенные запросы
На уровне распределенных запросов предъявляются повышенные
требования к программам оптимизации инструкций. На данном уровне
оптимизирующая программа при оценке альтернативных способов
обслуживания оператора SQL должна учитывать скорость передачи
данных в сети. Например, если локальной СУБД приходится
многократно обращаться к некоторой удаленной таблице (допустим при
создании объединения), то, эффективнее будет скопировать по сети
некоторую часть таблицы целиком, посредством одной операции
групповой передачи данных, чем многократно считывать по сети
отдельные записи.
Оптимизирующая программа должна также определить, какая
СУБД будет эффективнее управлять выполнением оператора. Например,
если большая часть таблиц находится в удаленной системе, то, вероятно,
было бы эффективнее, чтобы обработку выполняла удаленная СУБД
этой системы. Однако при чрезмерной загрузки удаленной системы такое
решение может оказаться малоэффективным. В целом, задача
оптимизирующей программы становится и более сложной, и более
важной. В силу своей сложности в настоящее время распределенные
запросы не поддерживаются полностью ни в одной коммерческой СУБД,
при этом, работы в этом направлении ведутся активно и следует ожидать
прогресса в данном направлении в самое ближайшее время.
Ряд новых направлений открывается в связи с развитием
объектно-ориентированных систем, в частности сред, основанных на
объектно-реляционном подходе. Пожалуй, наиболее важная область в
управлении распределенными объектами – это брокеры объектных
запросов (Object Request Broker, ORB). Концепция распределения
объектов распространилась не только на среды объектноориентированных СУБД, но и почти на любые мыслимые среды
информационных систем главным образом благодаря работам,
проводимым под эгидой Object Management Group (OMG), которая
разработала стандарт общей архитектуры брокера объектных
запросов – CORBA (Common Object Request Broker Architecture).
Сильным аргументом в пользу подхода к распределению данных,
основанного на серверах (централизованный подход), является то
преимущество, которое ему обеспечивает более высокая степень
контроля поддерживающих ресурсов данных и реализаций. Этот
аргумент может быть усилен в объектно-ориентированной области
благодаря подходу, предусматривающему использование брокеров
объектных запросов. Иначе говоря, базовая распределенная серверная
модель открывает дорогу для семантически более богатой модели с
инкапсуляцией методов средствами объектной модели.
Благодаря технологиям CORBA среды управления данными
могут быть интегрированы одна с другой в значительной степени
таким же образом, как и при серверном подходе. Отличие состоит,
однако, в том, что введение с помощью ORB объектноориентированного
уровня
обеспечивает
псевдообъектноориентированную обстановку не только для погруженных в нее
ООСУБД, но и для РСУБД, иерархических систем, сред плоских
файлов и других архитектур управления ресурсами данных. В
действительности синтезированная над ORB среда и серверы методов
поддерживают в системе парадигму управления распределенными
объектами независимо от внутренних реализаций.
5.3. Базы данных в Интернет
С появлением Интернет получила дальнейшее развитие
архитектура "клиент-сервер". С подключением локальных сетей к
Интернет, созданием внутрикорпоративных сетей, появляется
возможность с любого рабочего места в организации получить доступ
к информационным ресурсам сети.
Архитектура "клиент/сервер" на базе Интернет имеет
трехуровневую организацию. Пользовательским интерфейсом
является Web-браузер, расположенный на персональном компьютере
– "тонком" клиенте. Web-браузер взаимодействует с Web-сервером,
последний в свою очередь является клиентом для сервера баз данных
БД
Сервер БД
СУБД
SQL
WEB - сервер
CGI
WEB-Клиент 1
Java
WEB-Клиент 2
. . . . . . . . . . .
.
WEB-Клиент N
Рис. 69. Архитектура "клиент – сервер" на базе WEB
(рис. 69).
Наиболее часто в качестве сервера БД используется SQL-сервер.
Различают следующие механизмы доступа к БД: на стороне Webсервера и на стороне Web-клиента.
В первом случае обращение к серверу БД производится
следующим путем. Web-клиент заполняет специальную форму
запроса к БД и пересылает ее Web-серверу. Программами Webсервера вызываются внешние по отношению к ним программы в
соответствии с соглашениями одного из интерфейсов: СGI или API.
Внешние программы пишутся на языках программирования типа
С++, Perl, PHP. Программы, написанные в соответствии с
интерфейсом СGI, называются СGI-сценариями. Внешние программы
взаимодействуют с сервером БД на языке SQL, преобразуя текст
запроса в HTML-форме в SQL-запрос. После получения результатов
запроса внешняя программа формирует требуемую HTML-страницу,
передает ее Web-серверу, который пересылает ее Web-клиенту.
При доступе к БД на стороне клиента основным средством
реализации механизма взаимодействия Web-клиента и сервера БД
является язык JAVA, на котором пишутся программы (апплеты).
JAVA-программы хранятся на Web-сервере. В тексте HTMLдокумента ставятся в нужных местах ссылки на соответствующие
апплеты, при обнаружении которых в процессе работы с
гипертекстом происходит автоматическая пересылка JAVAпрограммы с сервера в среду выполнения браузера и загрузка на
выполнение. В диалоговом режиме с пользователем уточняются
характеристики запроса. Получив управление JAVA-апплет
взаимодействует с сервером БД, в результате чего, полученная из БД
информация предоставляется пользователю. Для обращения к
серверам баз данных разработан стандарт JDBC.
Из двух рассмотренных механизмов явного предпочтения отдать
тому или иному варианту нельзя. Все зависит от целей и условий
разработки
клиент-серверных
программ:
зависимость
от
операционной системы, вида Web-сервера и т.п.
Развитие интернет-технологий стимулирует появление новых
направлений в сфере сервиса. Уже никого не удивляют интернетбиблиотеки, интернет-магазины, интернет-справочники. Интересным
перспективным направлением в сфере сервиса является проект
"интеллектуальная квартира". Например, одной из задач программы
менеджера такой квартиры является следить за наличием в
холодильнике заданного набора продуктов; при необходимости
менеджер посылает заказ в интернет-магазин, который впоследствии
выполняется.
Ввиду постоянного увеличения числа пользователей Интернет
большие перспективы развития имеют интернет-СУБД бронирования
авиабилетов, билетов на концерты, столиков в ресторанах. В
настоящее время, уже не выглядит полной фантастикой
интерактивная справочно-информационная система Голливуда,
содержащая фильмы, информацию об актерах и режиссерах,
поддерживающая интерактивные форумы поклонников, позволяющая
участвовать во всевозможных виртуальных шоу.
Контрольные вопросы и задания
1. Определить основные понятия архитектуры "клиент-сервер".
2. Перечислить функции сервера баз данных.
3. Какой принцип является основой архитектуры "клиентсервер"?
4. Нарисовать двухзвенную схему модели "клиент-сервер".
5. Охарактеризовать функции стандартного интерактивного
приложения.
6. Назвать варианты разделения функций между компьютеромсервером и компьютером-клиентом для двухзвенной модели.
7. Охарактеризовать модель удаленного доступа к данным
(RAD).
8. Назвать достоинства и недостатки модели сервера баз данных.
9. Какие средства относятся к категории программного
обеспечения промежуточного слоя?
10. Определить назначение сервера приложений.
11. Что такое транзакция?
12. Указать функции монитора транзакций.
13. Нарисовать схему распределенной базы данных.
14. Охарактеризовать однородные распределенные системы.
15. Каким
методом
проектируются
неоднородные
распределенные системы?
16. Указать достоинства и недостатки метода фрагментации
данных.
17. Описать метод тиражирования данных.
18. Перечислить характеристики "идеальной" РаСУБД.
19. Охарактеризовать уровни доступа к распределенным данным
на примере четырехуровневой схемы.
20. Нарисовать модель доступа к данным на базе Интернет.
21. Указать основные механизмы доступа к БД в сети Интернет.
22. Каковы перспективы развития интернет-технологий в сфере
сервиса?
6. СОВРЕМЕННОЕ СОСТОЯНИЕ И
ПЕРСПЕКТИВЫ РАЗВИТИЯ БАЗ ДАННЫХ
Технологии баз данных и смежные с ними области
информационных технологий являются одной из наиболее бурно
развивающихся отраслей информатики и вычислительной техники,
причем темпы развития в последние годы особенно высоки.
Одним из направлений является развитие объектных технологий
баз данных. Объектно-ориентированные языки программирования
(такие как С++ и Java), объектно-ориентированные средства создания
приложений и сетевого программирования стали базовыми
технологиями разработки современного программного обеспечения.
Идейную поддержку развитию данного направления оказал
опубликованный в 1989 году "Манифест объектно-ориентированных
систем баз данных", в котором содержались основные требования
относительно обязательных свойств объектно-ориентированных баз
данных, и, предполагалось, что новые системы должны строиться на
базе объектно-ориентированного подхода, и нет особого смысла, так
или иначе, использовать реляционный подход. В данном манифесте
были приведены также необязательные свойства и открытые
возможности объектных систем. В области формирования
инфраструктуры объектных систем направляющую роль играет
учрежденный в 1989 г. консорциум OMG (Object Management Group),
целью которого является разработка и поддержка индустриальных
стандартов архитектуры программного обеспечения промежуточного
слоя (уровня архитектуры, занимающего промежуточное место между
сетевым уровнем и уровнем приложений) для создания
распределенных неоднородных объектных интероперабельных
систем. Традиционно к промежуточному слою относились средства
управления и доступа к данным, средства разработки программ,
средства управления распределенными вычислениями (включая
поддержку необходимых протоколов взаимодействия), средства
поддержки
пользовательского
интерфейса
и
др.
Такие
инфраструктуры использовались как отдельными компаниями (IBM),
так и в международных проектах (UNIX – ориентированная
интеграционная среда). Применяемые идеи и технологии не
позволяли до сих пор решить радикально архитектуру
промежуточного слоя. OMG на основе объектной технологии и идеи
интероперабельности вводит концепцию промежуточного слоя
последовательно,
радикально
и
до
конца.
Технически
интероперабельность компонентов (представляемых объектами)
решена введением базовой объектной модели, унифицированного
языка спецификации интерфейсов объектов, отделением реализации
компонентов от спецификации их интерфейсов, введением общего
механизма поддержки интероперабельности объектов (брокера
объектных заявок, играющего роль "общей шины", поддерживающей
взаимодействие объектов). Тем самым достигается однородность
представления компонентов и их взаимодействия. Далее, для
формирования информационной архитектуры вводится слой
унифицированных (ортогональных) служб, которые используются как
при конструировании прикладных систем, так и для формирования
функционально законченных средств промежуточного слоя,
предлагающих конкретные виды услуг. Существенно, что и службы и
средства
представляются
однородно
своими
объектными
интерфейсами, что позволяет обеспечить их интероперабельность
посредством брокера объектных заявок.
Базовый стандарт OMG – CORBA, принятый в 1991 г., получил
широкое признание и активно применяется на практике. Наряду с
созданием инфраструктуры для эффективного использования
объектного подхода в технологиях баз данных архитектура CORBA
предоставила один из методов обеспечения дальнейшего применения
информационных ресурсов и функциональности унаследованных
систем. Идея метода состоит в "объектизации" морально устаревшей
системы путем создания для нее "обертки" (Wrapper) с помощью
средств языка определения интерфейса IDL стандарта CORBA.
Система превращается в обычный стандартный объект и может быть
интегрирована в распределенную объектную среду.
К другим активно развиваемым важнейшим стандартам OMG
относятся язык UML для объектного анализа и проектирования,
стандарт XMI обмена метаданными между CASE-системами,
основанный на языке XML.
Развитие
производства
объектных
СУБД
потребовало
стандартизации модели данных и языковых средств, чтобы обеспечить
переносимость приложений и ресурсов данных между объектными
системами. Для решения этих задач ведущие поставщики объектных
СУБД учредили консорциум ODMG (Object Database Management
Group). В базовом стандарте ODMG определяются объектная модель,
являющаяся расширением объектной модели CORBA, и язык
определения объектов ODL. Был создан ряд чисто "объектных"
программных продуктов, соответствующих различным компонентам
данного стандарта: Objectivity/DB, GemStone, ObjectStore, POET,
Versant и др. Объектно-ориентированная модель является наиболее
подходящей платформой для CASE- и CAD-технологий.
Отношение специалистов в области баз данных к объектноориентированным базам данных (ООБД) неоднозначно. Главным
аргументом сторонников является то, что новая технология позволяет
добиться соответствия между программной моделью данных и
структурой базы данных, в отличие от фиксированных, жестких
структур реляционных таблиц. Кроме того, считается, что
многотабличные объединения в реляционной модели существенно
снижают производительность баз данных.
С другой стороны, чисто "объектная" модель вызывает много
нареканий среди специалистов (в частности, что объектноориентированный подход не имеет той мощной математической
основы, на которой построена реляционная модель, следствием чего
является
отсутствие
стандартов
построения
ООБД
и
стандартизированного языка запросов) и компании-производители
объектных СУБД испытывают определенные трудности с
продвижением своих продуктов на рынок.
Одновременно с развитием чисто "объектного подхода"
разработчики реляционных баз данных развивают объектнореляционную модель данных. На развитие данного направления
повлияли идеи, высказанные в "Манифесте систем баз данных
третьего поколения". Авторами были сформулированы основные
принципы построения СУБД нового поколения, предполагающие
развитие реляционной платформы с применением богатой системы
типов и расширением объектно-ориентированными возможностями, в
частности о расширении языка SQL базовыми объектными
возможностями (SQL:1999). СУБД, поддерживающие объектнореляционную модель данных, разрабатываются многими ведущими
компаниями, производителями программного обеспечения: Informix
Universal Database Server (Informix), DB2 Universal Database (IBM),
Oracle8 (Oracle). В последнее время появились предложения о
расширении SQL средствами интеграции с XML-данными, поддержки
языка Java. Предполагается дальнейшее совершенствование стандарта
SQL:1999 в рамках проекта SQL3.
Открывающиеся,
в
связи
с
интенсивным
развитием
коммуникационных возможностей Интернет, новые направления
развития отрасли накопления и доступа к данным приобретают все
большее значение. Прочно в обиход пользователей вошли технологии
глобальной гипертекстовой системы World Wide Web, которые
принципиальным образом изменили в последние годы облик
информационной среды общества. "Всемирная паутина" не только
эффективно воплотила гипертекстовые и гипермедийные технологии,
но
и
стала
одновременно
интегратором
неоднородных
информационных ресурсов, поддерживаемых в других средах (в
частности, в средах баз данных), обеспечила возможности для нового
этапа развития распределенных систем.
Новые возможности обеспечения интеграции информационных
ресурсов Web и баз данных получили дальнейшее развитие с
созданием платформы XML (в конце 2000 г. была принята новая
спецификация стандарта языка XML). Различные пути использования
этих возможностей активно изучаются в последние годы. В
частности, возможности использования единой техники доступа к
структурированным данным баз данных и слабоструктурированным
данным Web.
Перспективным направлением развития взаимодействия Webтехнологий и баз данных являются разработки систем баз данных
XML. В программе работ по созданию новой версии стандарта языка
SQL предусмотрено включение средств интеграции реляционных
данных и XML-данных.
Одной из основных тенденций, определяющих современные
направления
развития
технологий
баз
данных,
является
стремительный рост популярности хранилищ данных (Data
Warehousing), концепция которых была разработана Б. Инмоном.
Хранилище данных понимается как логически интегрированный
источник данных для систем поддержки принятия решений (DSS) и
информационных систем руководителя (EIS), который обеспечивает
поддержку принятия стратегических решений в крупной организации
на основе хранящихся исторических данных, отражающих
деятельность этой организации за продолжительный период времени.
Накапливая данные в хранилище, предприятие получает возможность
проведения статистических исследований, анализа тенденций и
перспектив развития, выявления слабых мест своей деятельности и
скрытых резервов. Хранилища данных используются для принятия
решений на основе сбора и анализа информации. Их главные
пользователи – это менеджеры, служащие планового отдела и отдела
маркетинга. Хранилища данных активно применяются в тех областях,
где информация о тенденциях бизнеса служит основой для принятия
решений, приводящих к значительной экономии средств или
приносящих большую прибыль. Например, в крупных производствах
– для анализа тенденций в области сбыта, в коммерции – для анализа
эффективности мероприятий, направленных на увеличения сбыта и
изучения демографических факторов, в финансовых структурах – для
анализа факторов, связанных с получением и погашением кредитов
клиентами и др. Хранилище данных – не то же самое, что база
данных, так как данные, поступившие в хранилище, приобретают
статус "неизменных". Вносимые изменения в хранилище носят
характер только "пополнения", а не произвольных поэлементных
обновлений, как в операционных базах данных, предназначенных для
каждодневной деятельности предприятия.
Основные компоненты хранилища:
 Средства
наполнения
хранилища,
представляющие
программный комплекс, выполняющий извлечение данных из
корпоративных операционных баз данных (OLTP-систем), их
обработку и загрузку в хранилища.
 База данных хранилища – реляционная база данных,
предназначенная для хранения огромных объемов данных, очень
быстрой загрузки и выполнения сложных аналитических запросов.
 Средства анализа данных – программный комплекс,
выполняющий статистический и временный анализ и представление
результатов в графической форме.
Структура базы данных хранилища данных разрабатывается
таким образом, чтобы максимально облегчить анализ информации. В
большинстве случаев информация в базе данных может быть
представлена в виде N-мерного куба фактов, отражающих деловую
активность компании в течение определенного времени.
Принципы организации хранилищ данных могут сыграть важную
роль в развитии электронных библиотек. Под электронной
библиотекой понимается крупная распределенная гипермедийная и
мультимедийная информационная система, позволяющая эффективно
использовать разнообразные коллекции электронных документов,
обладающая
развитыми
пользовательскими
интерфейсами,
обеспечивающая
доступ
пользователей
через
глобальные
коммуникационные сети.
90-е годы характеризуются развитием технологий управления
данными. В бизнес-приложениях наибольший интерес представляет
интеграция методов интеллектуального анализа данных с
технологией оперативной аналитической обработки данных (OLAP).
Системы OLAP обеспечивают аналитикам и руководителям быстрый
последовательный интерактивный доступ к внутренней структуре
данных и возможность преобразования исходных данных с тем,
чтобы они позволяли отразить структуру системы нужным для
пользователя образом. Кроме того, OLAP-системы позволяют
просматривать данные и выявлять имеющиеся в них закономерности
визуально, либо простейшими методами.
В настоящее время поддержка OLAP реализована во многих
СУБД и инструментах, поскольку является оптимальным решением
для большого класса приложений, где пользователи работают с
многомерными данными (то есть с данными, зависящими от
нескольких параметров, например от времени, местоположения и
других характеристик).
Технологии OLAP и хранилищ данных стимулируют развитие
ещё одного направления – темпоральных (временных) баз данных.
Темпоральные базы данных дополняют основные данные свойством
времени, переносят это свойство в среду самой СУБД, обеспечивают
языковые средства для выборки данных по запросам, связанным со
временем.
Программные средства, реализующие технологии OLAP и
хранилищ данных, выпускаются многими производителями
программных продуктов: IBM DB2 OLAP Server, Visual Warehouse
(IBM); MetaCube (Informix); Oracle Data Mart Suite (Oracle); группа
продуктов Express OLAP. Программные компоненты для поддержки
функциональных возможностей OLAP и хранилищ данных
предусмотрены в Microsoft SQL Server 2002 (Microsoft). Поддержка
временных рядов реализована в продуктах Informix Universal Database
Server и Oracle8.
Интеграция со всемирной паутиной систем поддержки принятия
решений, крупномасштабных хранилищ данных и прочих развитых
информационных систем становится реальностью. В этом
направлении следует ожидать развитие существующих и появлений
новых стандартов и технологий доступа.
Еще одним из перспективных направлений развития баз данных
является развитие дедуктивных баз данных. Эти базы данных
основаны на применении аппарата математической логики и средств
логического программирования в области систем баз данных.
Получение сведений из баз данных осуществляется не путем запросов
или аналитической обработки, а путем использования правил вывода
и построения цепочек применения этих правил для вывода ответов на
запросы. Для этих баз данных существуют языки запросов, отличные
от SQL.
Дальнейшее развитие архитектурных подходов информационных
систем связано с архитектурой "клиент-сервер". По такому принципу
строятся сервисы CORBA, Интернет, современные серверы баз
данных.
Развитие архитектуры распределенных систем связано с
концепцией промежуточного слоя. Имеются в виду средства
программного обеспечения, позволяющие изолировать приложения
от сетевых протоколов и особенностей конкретных операционных
систем. На принципах промежуточного слоя строятся многие
стандартные интерфейсы распределенных систем, например, ODBC,
JDBC. Одной из важнейших задач средств промежуточного слоя –
обеспечение интероперабельности (способности системы к
взаимодействию с другими системами) программных продуктов
различных поставщиков.
Новым архитектурным подходом является появления систем баз
данных с мобильной архитектурой. Создание миниатюрных
мобильных компьютеров, способных поддерживать операционные
платформы стационарных компьютеров, развитие сотовой телефонии
стимулируют разработки технологии теледоступа к базам данных и
мобильных систем баз данных. Основные направление исследований:
разработка эффективных методов восстановления баз данных,
стратегий кэширования в системах "клиент-сервер" и мобильных
системах,
обеспечение
высокой
производительности
и
масштабируемости систем, исследование новых моделей транзакций
для мобильных систем, обработка в таких системах запросов,
зависящих от местоположения пользователя, создание персональных
информационных систем, предназначенных для индивидуальных
информационных систем пользователя и др.
В ближайшее время возможно появление принципиально новых
подходов и направлений в области баз данных. Технической базой
для этого могут служить такие прогрессивные технологии повышения
производительности, как RAID (Redundat Arrays of Inexpensive disk –
эта аббревиатура обычно расшифровывается как "избыточные
массивы недорогих дисков"). Сочетание быстро увеличивающейся
мощности обработки с возможностью значительно быстрого
выполнения операций ввода-вывода в действительности приведет к
появлению среды, в которой увеличение производительности
обработки
транзакций
аппаратным
путем
представляется
приемлемым и желательным решением проблемы.
Эксперты определяют следующие основные направления
исследований в области баз данных:
 Разработка принципов самонастройки СУБД. Система должна
автоматически настраиваться без участия персонала администратора
баз данных на основе регистрации информации об условиях ее
функционирования.
 Создание новых технологий для крупномасштабных
федеративных систем. Примером такой системы является Web. К
кругу проблем данного направления относится обработка запросов
большой вычислительной сложности.
 Разработка новых подходов к архитектуре систем баз данных.
Эксперты полагают, что необходимо пересмотреть 20-летние
архитектурные принципы организации системы баз данных в связи с
изменением аппаратурных средств. Например, при объеме
оперативной памяти в пределах терабайта традиционные подходы
оказываются неэффективными.
 Интеграция структурированных и слабоструктурированных
данных. Имеется в виду интеграция технологий баз данных и Webтехнологий.
Динамика развития технологий баз данных очень высока.
Поэтому в ближайшее время возможно появление новых направлений
исследований.
В рамках учебного пособия невозможно охарактеризовать все
современные составляющие и перспективные направления развития
технологий баз данных. Сегодняшние технологии баз данных
представляют настолько обширную и разветвленную сферу "как в
части их собственных возможностей, так и в отношении
многообразия приложений" [24]. Поэтому важнейшим компонентом
изучения баз данных является работа с оперативными,
энциклопедическими и информационными источниками и Интернетресурсами.
Контрольные вопросы и задания
1. Дать характеристику объектно-ориентированной технологии
баз данных.
2. Перечислить чисто "объектные" программные продукты.
3. Каковы достоинства и недостатки ООБД?
4. Указать тенденции развития реляционных баз данных.
5. Каковы перспективы интеграции технологий баз данных и
Web-технологий?
6. Что такое хранилище данных?
7. Перечислить основные компоненты хранилища.
8. Дать характеристику OLAP-системам.
9. Каковы современные направления и архитектурные подходы
в развитии распределенных систем?
10. Что такое RAID-технологии?
11. Охарактеризовать основные направления исследований в
области баз данных.
ЗАКЛЮЧЕНИЕ
Рассмотренные в настоящем пособии вопросы, относящиеся к
проектированию и разработке баз данных, далеко не исчерпывают
весь перечень проблем и направлений развития этой отрасли
информатики. В настоящее время осуществляются многочисленные
исследования в области баз данных, СУБД и построении на их основе
информационных систем. Активно разрабатываются новые средства
описания и манипулирования данными, а также алгоритмы
выполнения операций в СУБД. Требуют новых эффективных
решений задачи обеспечения информационной безопасности баз
данных, без чего невозможна информационная безопасность и
конкретного владельца информации, и организации, и страны в
целом.
Дальнейший
прогресс
в
направлении
внедрения
информационных систем во все сферы деятельности невозможен без
разработки и использования распределенных баз данных,
совершенствования
способов
обмена
информацией
между
различными приложениями в глобальных компьютерных сетях.
Ведущими мировыми компаниями – разработчиками баз данных
предлагаются новые версии своих систем, реализующих все более
широкий спектр функций. Осуществляется разработка и принятие
новых стандартов в области СУБД.
Однако следует отметить, что все представленные направления
развития теории и практики создания баз данных используют в
качестве фундаментальной основы знание основных принципов баз
данных. Формирование таких знаний и соответствующих
практических умений и являлось основной целью данного учебного
пособия.
Авторы надеются, что представленный в данном пособии
учебный материал был доступным для понимания и интересным при
его изучении. Любые замечания и пожелания, направленные на
совершенствование данного пособия, а также предложения по
подготовке других учебных изданий по вопросам баз данных,
информационных систем, разработке и использованию других
средств информационных и коммуникационных технологий будут
приняты с благодарностью.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Базы данных: достижения и перспективы на пороге XXI
столетия: Пер. с англ. / Под ред. А. Зильбершатца, М. Стоунбрекера и
Дж. Ульмана // СУБД. 1996. № 3. С. 103–117
2. Баркер Скотт Ф. Профессиональное программирование в
Microsoft Access 2002: Пер. с англ. М.: Издательский дом "Вильямс",
2002. 992 с.
3. Боровиков В.В. Microsoft Access 2002. Программирование и
разработка баз данных и приложений. М.: СОЛОН-Р, 2002. 560 с.
4. Брукшир Дж. Гленн. Введение в компьютерные науки. Общий
обзор. 6-е изд.: Пер. с англ. М.: Издательский дом "Вильямс", 2001.
688 с.
5. Вендров А.М. Проектирование программного обеспечения
экономических информационных систем. М.: Финансы и статистика,
2000. 352 с.
6. Вендров А.М. CASE-технологии. Современные методы и
средства проектирования информационных систем. М.: Финансы и
статистика, 1998. 176 с.
7. Виллариал Б. . Программирование в Access 2002 в примерах:
Пер. с англ. М.: КУДИЦ-ОБРАЗ, 2003. 496 с.
8. Григорьев Ю. А., Ревунков Г. И. Банки данных: Учеб. для
вузов. М.: Изд-во МГТУ им. Н. Э. Баумана, 2002. 320 с.
9. Дарвин Х., Дейт К. Третий манифест: Пер. с англ. // СУБД.
1996. № 1. С. 110–123
10. Дейт К. Дж. Введение в системы баз данных. 6-е изд.: Пер. с
англ. М.: Издательский дом "Вильямс", 2000. 848 с.
11. Дженнингс Р. Использование Microsoft Access 2002. Спец.
изд.: Пер. с англ. М.: Издательский дом "Вильямс", 2002. 1012 с.
12. Дунаев С. С. Доступ к базам данных и техника работы в сети.
Практические приемы современного программирования. М.: Диалог –
МИФИ, 1999.
13. Зильбершац А, Здоник С. Стратегические направления в
системах баз данных: Пер. с англ. // СУБД. 1997. № 4. С. 4–23
14. Карпова Т.С. Базы данных: модели, разработка, реализация.
СПб.: Питер, 2001. 304 с.
15. Когаловский М.Р. Энциклопедия технологий баз данных. М.:
Финансы и статистика, 2002. 800 с.
16. Корнеев В. В., Гареев А. Ф. и др. Базы данных.
Интеллектуальная обработка информации. М.: Изд-во Нолидж, 2001.
496 с.
17. Литвин П, Гетц К, Гунделой М. Разработка корпоративных
приложений в Access 2002. Для профессионалов. СПб.: Питер; Киев:
BHV, 2003. 848 с.
18. Мартен Д. Базы данных: практические методы. М.: Радио и
связь, 1983. 168 с.
19. Мартин Дж.. Организация баз данных в вычислительных
системах. М.: Мир, 1980. 662 с.
20. Мейер Д. Теория реляционных баз данных. М.: Мир, 1987.
608 с.
21. Михеева В.Д., Харитонова И.А.. Microsoft Access 2002. СПб.:
БВХ-Петербург, 2002. 1040 с.
22. Послед Б.С. Access 2002. Приложения баз данных: Лекции и
упражнения. СПб., 2002. 656 с.
23. Риордан Р.М. Программирование в Microsoft SQL Server 2000.
Шаг за шагом: Практ. пособ. / Пер. с англ. М.: Изд-во ЭКОМ, 2002.
608 с.
24. Саймон А.Р. Стратегические технологии баз данных:
менеджмент на 2000 год: Пер. с англ. / Под ред. и с предисл. М.Р.
Когаловского. М.: Финансы и статистика, 1999. 479 с.
25. Слама Д., Гарбис Д., Рассел П. Корпоративные системы на
основе CORBA : Учеб. пособ.: Пер. с англ. М.: Издательский дом
"Вильямс", 2000. 368 с.
26. Ульман Дж., Уидом Дж. Введение в системы баз данных. М.:
Изд- во "Лори", 2000. 789 с.
27. Ульман Дж. Основы систем баз данных / Пер. с англ. М.:
Финансы и статистика, 1983. 334 с.
28. Федоров А., Елманова Н. Базы данных для всех. М.:
КомпьютерПресс, 2001. 256 с.
29. Хансен Г., Хансен Дж. Базы данных: разработка и управление:
Пер. с англ. М.: ЗАО "Издательство БИНОМ", 2000. 704 с.
30. Харитонова И., Вольман Н. Программирование в Access 2002:
учебный курс. СПб.: Питер, 2002. 480 с.
31. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных:
Учебник для высших учебных заведений / Под ред. проф.
А.Д. Хомоненко. СПб.: Корона принт, 2000. 416 с.
32. Цаленко М. Ш. Моделирование семантики в базах данных. М.:
Наука, 1989. 288 с.
ПРИЛОЖЕНИЕ 1
Информационные ресурсы Internet
ACM SIGMOD (Московская секция группы ACM):
http://www.ipi.ac.ru/sigmod/
ACM SIGWEB : http://www.acm.org/sigweb/
IEEE CS (Московский центр): http://www.computer.org.ru/
ISO: http://www.iso.ch
ODMG: http://www.odmg.org/
OMG: http://www.omg.org/
РГНФ (Российский гуманитарный научный фонд):
http://www.rfh.ru/
РФФИ (Российский фонд фундаментальных исследований):
http://www.rfbr.ru/
Исследовательские группы в области баз данных:
http://www.acm.org/sigmod/researchDepts/index.html
Календарь событий ACM: http://www.acm.org/sig_conferences/
http://www.acm.org/events/
Электронный магазин стандартов: http://webstore.ansi.org/
Электронная библиотека ACM: http://www.acm.org/dl/
Электронная библиотека IEEE CS:
http://www.computer.org/epub
DB2 Magazine Homepage: http://www.db2mag.com/
DBWorld: http://www.cs.wisc.edu/dbworld
D-LIB (On-Line): http://www.dlib.org/
ComputerWord Россия (журнал): http://www.osp.ru/cwr/
Директор
информационной
службы
(журнал):
http://www.osp.ru/
Открытые системы (журнал): http://www.osp.ru/os/
СУБД (журнал): http://www.osp.ru/dbms/
Исследовательская группа СИНТЕЗ Института проблем
информатики РАН: http://www.ipi.ac.ru/synthesis/
Репозитарий материалов по базам данных ЦИТ МГУ:
http://www.citforum.ru/database/
Список серверов, поддерживающих публикации по базам
данных: http://www.acm.org/sigmod/publications.html
ПРИЛОЖЕНИЕ 2
Словарь терминов
Атрибут – столбец реляционной таблицы
Атомарное значение – значение, не являющееся множеством
значений или повторяющейся группой
База данных – совокупность взаимосвязанных, совместно
используемых, управляемых данных, характеризующая актуальное
состояние некоторой предметной области
Внешний ключ – набор атрибутов одной реляционной таблицы,
являющийся ключом другой реляционной таблицы. Применяется для
создания связей между таблицами
Данные – представление фактов о предметной области в форме,
допускающей их обработку и хранение на компьютерах, восприятие
человеком
Дерево – иерархическая структура данных
Домен отношения – множество всех возможных значений
некоторого атрибута отношения
Жизненный цикл базы данных – процесс проектирования,
реализации и поддержания системы базы данных
Журнал СУБД – отдельная база данных (часть основной базы
данных), используемая для записи информации обо всех изменениях
базы данных
Запрос – специальным образом описанное требование,
определяющее производимые с данными в базе данных манипуляции:
выборку, удаление, изменение, вставку данных
Завершение транзакции – процесс, в результате которого все
операции, входящие в состав транзакции, успешно завершены
Защита
данных
–
средства
предотвращения
несанкционированного доступа к базе данных
Избыточность данных – дублирование данных в базе данных
Индекс – средство ускорения операций поиска записей в
таблицах
Клиент – компьютер (программа), использующий ресурс
вычислительной сети
Ключ отношения или первичный ключ – атрибут отношения,
однозначно определяющий каждый кортеж
Курсор – указатель, используемый для перемещения по наборам
записей при их обработке
Кортеж – строка реляционной таблицы
Мэйнфрейм
–
многопользовательская
централизованная
вычислительная система
Метаданные – данные о данных, описывающие их структуру,
формат представления, методы доступа, место хранения, семантику,
хранящиеся в словаре данных
Модель представления данных – логическая структура данных
Нормальная форма – правила структурирования реляционных
таблиц во избежание аномалий
Нормализация – процесс преобразования реляционных таблиц
путем ликвидации повторяющихся групп и иных противоречий в
хранении данных с целью приведения таблиц к виду, позволяющему
осуществлять непротиворечивое и корректное редактирование
данных
Отношение – двумерная таблица
Ограничение целостности – условия, которым должны
удовлетворять хранимые в базе данные
Откат транзакции – процесс, в результате которого все уже
выполненные операции, входящие в состав транзакции, отменяются, а
все объекты базы данных, затронутые этими операциями,
возвращаются в исходное состояние
Представление – объект базы данных, являющийся виртуальной
таблицей, предоставляющей данные из одной или нескольких
реальных таблиц. Представление не содержит данных, а только
описывает их источник
Приложение – программа, предназначенная для решения
некоторой совокупности задач или типовой инструментарий
Рабочая станция – персональный компьютер, являющийся
рабочим местом пользователя в сети
Реляционная алгебра – теоретический процедурный язык
манипуляции реляционными таблицами
Реляционное исчисление – теоретический непроцедурный язык
определения запросов к реляционным таблицам
Реляционная модель данных – модель данных, представляющая
данные в виде таблиц
Репликация – копирование информации из одной базы данных в
несколько других, выполняемое как единовременно, так и по
заданному расписанию
Роль – совокупность прав на доступ к тому или иному объекту
баз данных
Связь – взаимоотношение между атрибутами двух таблиц. Связь
между двумя таблицами устанавливается путем присвоения значений
внешнего ключа одной таблицы значениям первичного ключа другой
таблицы
Семантическая модель – модель, фиксирующая значения
сущностей и отношений реального мира
Сервер базы данных – 1. СУБД с архитектурой "клиент-сервер".
2. Компьютер в сети, на котором поддерживается БД
Сервер –. программа (компьютер), предоставляющая некоторые
услуги по запросам других программ (компьютеров), называемых
клиентами
Сеть – совокупность компьютеров, объединенных средствами
передачи данных
Словарь данных – подсистема базы данных, предназначенная для
централизованного хранения информации о структурах данных, типах
данных, взаимосвязях файлов базы данных друг с другом, кодах
защиты и т. п.
Степень реляционной таблицы – число атрибутов реляционной
таблицы
Сущность – объект любой природы, данные о котором хранятся
в базе данных
Схема отношения – список имен атрибутов отношения
Транзакция – последовательность операций над базой данных,
отслеживаемое СУБД от начала до завершения как единое целое.
Транзакции все вместе либо выполняются, либо отменяются
Транзитивная зависимость – функциональная зависимость, при
которой неключевой атрибут функционально зависит от одного или
более неключевых атрибутов
Файл-сервер – компьютер, предназначенный для организации
управления файлами в сети
Функциональная зависимость атрибута В от атрибута А – такая
зависимость атрибутов, при которой каждому значению атрибута А
соответствует одно значение атрибута В
Хранимая процедура – программа обработки данных,
хранящаяся и выполняемая на компьютере-сервере
Целостность – свойство базы данных, означающее, что она
содержит полную, непротиворечивую и адекватно отражающую
предметную область информацию
Экземпляр – действительные значения записей, выраженные в
структуре данных
ПРИЛОЖЕНИЕ 3
Список сокращений
АБД – администратор базы данных
БД – база данных
ЖЦ – жизненный цикл
ИТ – информационные технологии
ИС – информационная система
ПО – программное обеспечение
РаБД – распределенная база данных
СУБД – система управления базами данных
ООБД – объектно-ориентированная база данных
ACM (Association for Computing Machinery) – Международная
ассоциация по вычислительной технике
ACM SIGMOD (ACM Special Interest Group on Management of
Data) – группа ACM по управлению данными
ADM (Architected Data Mart) - развиваемая витрина данных
ANSI (American National Standards Institute) – Американский
национальный институт стандартов
ANSI/SPARC (ANSI/Systems Planning and Requirements
Commitee) – Американский национальный институт стандартов /
Комитет системного планирования и управления
AS (Application Server) – модель сервера приложений
API (Application Programming Interface) – интерфейс прикладного
программирования
CAD (Computer Aided Design) – система автоматизации
проектирования
CASE (Computer Aided Software Engineering) – автоматизация
разработки программного обеспечения
CGI (Common Gateway Interface) – интерфейс взаимодействия
Web-сервера с внешними программами
CIM (Computer Integrated Manufacturing) – автоматизированное
интегрированное производство.
CODASYL (Conference on Data Systems Languages) – Ассоциация
по языкам систем данных
CORBA (Common Object Request Broker Architecture) – стандарт
архитектуры неоднородных распределенных интероперабельных
объектных сред
DBMS (Database Management System) – система управления
базами данных
DBS (Database Server) – модель сервера БД
DBTG (Data Base Task Group) – группа задач баз данных
DDL (Data Definition Language) – язык определения данных
DDM (Distributed Data Mart) – распределенная витрина данных
DDW (Distributed Data Warehouse) – распределенное хранилище
данных
DML (Data Manipulation Language) – язык обработки данных
DSS (Decision Support System) – полнофункциональная система
анализа и исследования данных, система поддержки принятия
решений
EDW (Enterprise Data Warehouse) - хранилище данных
предприятия
EDMA (Enterprise Data Mart Architecture) – архитектура витрин
данных предприятия
EIS (Executive Information System) – информационная система
руководителя предприятия (система оперативного мониторинга)
E/R (Entity-Relationship) – "сущность-связь"
ERD (Entity-Relationship Diagram) – диаграмма "сущность-связь"
FDM (Federated Data Mart) – объединенная витрина данных
FDW (Federated Data Warehouse) – объединенное хранилище
данных
HTML (HyperText Markup Language) – стандартный язык для
создания страниц Интернет
IDL (Interface Definition Language) – декларативный язык для
определения интерфейсов объектов независимо от языков их
реализации
IEEE (Institute of Electrical and Electronics Engineers) – Институт
инженеров по электротехнике и электронике (крупнейшее
международное профессиональное общество)
IEEE CS (IEEE Computer Society) – компьютерное общество
IEEE
IMS (Information Management System) – система управления
информацией (одна из первых СУБД)
ISO
(International
Organization
for
Standardization)
–
Международная организация по стандартизации
IVE (Industrial Virtual Enterprise) – индустриальное виртуальное
предприятие
ITSM (IT Servise Management) – модель управления IT-услугами
JDBC (Java Database Connectivity) – Java-интерфейс для
установки связи с базами данных
ODBC (Open Database Connectivity) – открытый интерфейс
установки связи с базами данных
ODBS (Open Database Connectivity) – открытое соединение баз
данных
ODL (Object Description language) – объектный язык
ODMG (Object Data Management Group) – индустриальный
консорциум для выработки стандарта объектно-ориентированных
СУБД
OLAP (Online Analytical Processing) – технологии интерактивной
аналитической обработки данных в системах баз данных
OMG (Object Management Group) – индустриальный консорциум
для выработки стандарта архитектуры неоднородных объектных
интероперабельных распределенных систем
ORD (Object Request Broker) – брокер объектных ресурсов
QBE (Query By Example) – запрос по образцу
QUEL (Query Language) – язык запросов
RDA (Remote Data Access) – модель удаленного доступа к БД
RM/T (Relational Model/Tasmania) – расширенная реляционная
модель
RPC (Remote Procedure Call) – удаленный вызов процедур
SGML (Standart Generalized Markup Language) – общий язык
разметки
SQL (Structured Query Language) – структурированный язык
запросов
TCP/IP (Transmission Control Protocol/Internet Protocol) –
протокол управления передачей/протокол Интернет
TPM (Transaction Processing Monitor) – монитор обработки
приложений
UML (Unified Modeling Language) – язык, предназначенный для
спецификации, визуализации, конструирования и документирования
систем
программного
обеспечения
на
основе
объектноориентированных методов
XMI (XML Metadata Interchange) – индустриальный стандарт
языка обмена метаданными между индустриальными средствами
объектного анализа и проектирования
XML (Extensible Markup Language) – новый стандарт языка
разметки для Web- документов (второго поколения)
ПРИЛОЖЕНИЕ 4
Темы рефератов
1. Основные направления научных исследований в области
систем баз данных.
2. Стандарты баз данных, их назначения и виды.
3. История создания языка SQL и его стандартизация.
4. Объектные технологии баз данных и стандарт ODMG.
5. Геоинформационные
системы
(ГИС).
Стандарты,
перспективы развития технологий ГИС.
6. Темпоральные базы данных.
7. Дедуктивные базы данных.
8. Консорциум OMG и основные направления его
деятельности.
9. Интеграция Web-технологий и технологий баз данных.
10. Многомерный анализ данных и технология OLAP.
11. Дореляционные структуры данных.
12. Основные направления развития реляционных баз данных.
13. Выбор и оценка СУБД.
14. Роль метаданных в информационных системах.
15. Базы данных в мобильных системах.
16. Хранилища данных.
17. XML: состояние и перспективы.
18. CASE-средства разработки информационных систем.
19. Распределенные технологии в информационных системах.
20. Технологии разработки цифровых библиотек.
21. Концепции
построения
систем
автоматизации
документооборота.
22. Модели транзакций.
23. Защита данных в базах данных.
24. Механизмы доступа к данным.
25. Средства разработки приложений.
Лучко Олег Николаевич
Морарь Елена Витальевна
Червенчук Игорь Владимирович
Базы данных
Учебное пособие
Редактор Л. Г. Сигитова
Изд. № 113
Раб. программа
п.п. 2.1.1-2.1.18
Лицензия ЛР № 021278 от 06.04.98 г.
Подписано в печать
. Формат 6084 1/16.
Бумага типограф. Оперативный способ печати.
Усл. печ.л. 9,76. Уч.-изд.л. 9,3. Тираж 200 экз.
Заказ №
Издательско-полиграфический центр ОГИС
644099, Омск, Красногвардейская, 9