48548

Базы данных. Модели данных

Конспект

Информатика, кибернетика и программирование

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

Русский

2013-12-17

1.19 MB

20 чел.

6

ОГЛАВЛЕНИЕ

введение 5

1. Основы построения баз данных 10

1.1. Архитектура системы баз данных 10

1.2. Жизненный цикл базы данных 15

2. Модели представления данных 18

2.1. Классификация моделей данных 18

2.2. Разновидности инфологических моделей данных 22

3. ДатАлогические модели данных 30

3.1. Иерархические модели 30

3.2. Сетевые модели 33

3.3. Реляционные модели 35

3.3.1. Основные понятия реляционной модели 36

3.3.2. Реляционная алгебра 41

3.3.3. Язык запросов по образцу QBE 55

3.3.4. Структурированный язык запросов SQL 67

3.4. Проектирование реляционных баз данных 78

4. Семантическое моделирование 88

4.1. Объектно-ориентированное проектирование 88

4.1.1. Представление объектов 88

4.1.2. Описания классов 90

4.1.3. Атрибуты в ODL 90

4.1.4. Связи в ODL 92

4.1.5. Обратные связи 93

4.1.6. Множественность связей 95

4.1.7. Типы в ODL 97

4.1.8. Проектирование с использованием ODL 100

4.1.9. Подклассы 101

4.1.10. Множественное наследование в ODL 102

4.1.11. Моделирование ограничений 105

4.1.12. Переход от объектно-ориентированной модели  

к реляционной 107

4.2. Диаграммы "сущность-связь" 108

4.2.1. Компоненты диаграмм "сущность-связь" 108

4.2.2. Множественность E/R-связей 109

4.2.3. Роли в связях 112

4.2.4. Атрибуты связей 113

4.2.5. Конвертирование многосторонних связей в бинарные 115

4.2.6. Проектирование E/R моделей 116

5. БАЗЫ ДАННЫХ В СЕТЯХ 129

5.1. Архитектура "клиент-сервер" 129

5.2. Распределенные базы данных 134

5.3. Базы данных в Интернет 142

6.  СОВРЕМЕННОЕ СОСТОЯНИЕ И Перспективы развития баз данных 146

Заключение 154

библиографический список 155

ПРИЛОЖЕНИЕ 1. Информационные ресурсы internet 157

приложение 2. Словарь терминов 158

ПРИЛОЖЕНИЕ 3.Список сокращений 161

ПРИЛОЖЕНИЕ 4. Темы рефератов 164


введение

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

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

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

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

В период 60-х–70-х гг. формируются основы методологии построения баз данных. Существенный вклад в технологии баз данных внесла CODASYL (ассоциация представителей крупнейших поставщиков и пользователей средств вычислительной техники), в отчетах которой был впервые проведен систематический анализ разработанного к тому времени программного инструментария и фактически был предложена обобщенная функциональная модель СУБД, впервые сформулированы концепции многоуровневой архитектуры, функционирования систем управления базами данных общего назначения, концепция схемы базы данных и языка определения данных, основополагающие понятия сетевой модели данных. Дальнейшее формирование архитектурной концепции баз данных было продолжено Рабочей группой ANSI/X3/SPARC (была предложена трехуровневая модель систем баз данных, в значительной степени определившая дальнейшее развитие технологий баз данных).

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

Значительный (в свое время по существу революционный) вклад в развитие теории баз данных был сделан американским математиком Э.Ф. Коддом, разработавшим реляционный подход к базам данных. В настоящее время реляционная модель данных не только не утратила своей актуальности, но и получила дальнейшее развитие благодаря объектным технологиям.

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

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

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

Знание основных идей и методов в области проектирования профессионально-ориентированных баз данных, владение навыками разработки и внедрения подобных систем становится важнейшим компонентом системы подготовки специалистов, объектами профессиональной деятельности которых являются информационные процессы, определяемые спецификой предметной области. К специалистам такого направления несомненно относятся информатики (с квалификацией в области), подготовка которых в высших учебных заведениях осуществляется на основе Государственного образовательного стандарта (ГОС) высшего профессионального образования специальности 351400 "Прикладная информатика (по областям)". В соответствии с данным стандартом к числу важнейших задач профессиональной деятельности информатика – специалиста по созданию и внедрению профессионально-ориентированных информационных систем в предметной области относится и разработка баз данных.

Настоящее пособие составлено на основе указанного ГОС (данная дисциплина представлена в блоке общепрофессинальных дисциплин) и содержит систематическое рассмотрение идей, методов, подходов и технологий, используемых при проектировании и практической разработке современных баз данных. При этом необходимо отметить, что выбор в качестве предметной области сферы сервиса, которая по аналогии с ИС также может рассматриваться в широком смысле (выделяют такие виды сервиса как технический, технологический, информационный, транспортно-коммуникационный, социально-культурный), не снижает общности рассматриваемых в пособии средств и методов, а реализуется прежде всего на основе разбора примеров, являющихся специфичными для данной предметной области. Отметим, что в настоящее время все большее распространение получают понятия IT-услуг (ITSM, IT Service Management). Знания и умения, полученные в ходе освоения курса "Базы данных", составляют основу специальной подготовки студентов-информатиков (говоря современным языком, основу ИТ-образования).

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

Пособие состоит из 6 глав, к каждой из которых приведены контрольные вопросы и задания для самостоятельной работы студентов. Более глубокой проработке учебного материала пособия призвана способствовать работа студентов с литературой, представленной в библиографическом списке, а также с представленными в приложении информационными ресурсами Интернет. Расширению научного кругозора студентов будет способствовать и обсуждение на семинарских занятиях рефератов, тематика которых отражает современные направления развития технологий баз данных (приложение 4).

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

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


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

1.1. Архитектура системы баз данных

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

Внешний уровень

Концептуальный уровень

. . .

Рис.1. Уровни архитектуры

Цеха

Внутренний уровень

Внешний уровень

Для описания базы данных инициативной группой ANSI/SPARC (Американский национальный институт стандартов / Комитет по требованиям и планированию стандартов) в 70-x гг. была предложена трехуровневая архитектура. Архитектура ANSI/SPARC включает следующие уровни: внутренний, концептуальный и внешний (рис. 1). Каждый уровень описывается соответствующей схемой (средствами языка описания данных соответствующего уровня), определяющей свойства базы данных в терминах типов содержащихся в БД данных. Уровни связаны механизмами междууровневого отображения             данных.

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

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

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

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

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

Рис. 2. Компоненты системы баз данных

.  .  .

АБД

СУБД

Прикладные программы

БД

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

Пользователи

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

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

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

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

Администратор базы данных (АБД) – под этим понятием подразумевается лицо (или группа лиц, возможно, целое штатное подразделение), на которое возложено управление средствами базы данных организации. В его функции входит:

  1.  координировать все действия по проектированию, реализации и ведению базы данных; учитывать перспективные и текущие требования пользователей; следить, чтобы база данных удовлетворяла актуальным информационным потребностям;
  2.  анализировать существующие программные средства и возможность их использования в базе данных, разрабатывать программно-технические мероприятия по развитию базы данных;
  3.  разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования, от сбоев технических средств, по обеспечению секретности определенной части данных и разграничению доступа к данным;
  4.  выполнять работы по ведению словаря данных; контролировать избыточность и противоречивость данных, их достоверность;
  5.  следить за тем, чтобы БД отвечала заданным требованиям по производительности, т. е. чтобы обработка запросов выполнялась за приемлемое время; выполнять при необходимости изменения методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определять степень влияния изменений в данных на всю БД; координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию;
  6.  координировать работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы;
  7.  координировать работы прикладных программистов, разрабатывающих новые приложения и выполнять проверку и включение прикладных программ в состав программного обеспечения системы;
  8.  работать с конечными пользователями, в том числе и по вопросам обучения и консультирования и т.п.

Программное обеспечение включает, прежде всего, систему управления базами данных (СУБД) – комплекс программных средств, "предназначенный для создания и хранения базы данных на основе некоторой модели данных, обеспечения логической и физической целостности содержащихся в ней данных, надежного и эффективного использования ресурсов (данных, пространства памяти, вычислительных ресурсов), предоставления к ней санкционированного доступа для приложений и конечных пользователей, а также для поддержки функций администратора баз данных" [15].

Рассмотрим функции СУБД подробнее:

  1.  СУБД должна предоставлять пользователям и программам два типа языков: язык описания данных (для описания логической структуры данных) и язык манипулирования данными (для выполнения запросов пользователя на выборку, изменение, удаление данных).
  2.  СУБД должна контролировать пользовательские запросы и следить за выполнением правил безопасности и целостности, определенные АБД.
  3.  В СУБД должен быть предусмотрен механизм восстановления данных.
  4.  СУБД должна обеспечить функцию словаря данных. Словарь данных содержит "данные о данных", так называемые метаданные. Метаданные словаря предоставляются в виде, удобном для восприятия человеком и характеризуют состав и структуру пользовательских данных в базе данных. Словарь данных предназначен для документирования разработки системы базы данных, справочного обслуживания ее пользователей, а также для  персонала АБД.

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

База данных не существует без данных. Данные должны быть определенным образом организованы. Теоретическим основам организации данных посвящены главы 2-4.

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

.  .  .

Конечные пользователи

В н е ш н и й       у р о в е н ь

Внутренний

уровень

Концептуальный

уровень

Про

ектирование

Отображение

Отображение

Рис. 3. Детализированная архитектура баз данных

АБД

1.2. Жизненный цикл базы данных

Базы данных начинаются с людей и их потребностей. Разработка базы данных представляет итеративный, пошаговый процесс. Каждый шаг ведет к созданию рабочей базы данных; каждая итерация идет от моделирования – к созданию структуры, а затем обратно в том порядке, в каком это имеет смысл делать. Проектирование базы данных начинается с определения информационных потребностей пользователей, создания модели данных и заканчивается утилизацией базы данных. Процедура создание концептуальной схемы базы данных, определение данных, включаемых в базу данных, создание программ обновления и обработки данных называется жизненным циклом базы данных (ЖЦ). Жизненный цикл включает в себя процессы проектирования, реализации и поддержания системы базы данных и состоит из следующих   этапов [29]:

  1.  предварительное планирование;
  2.  проверка осуществимости;
  3.  определение требований;
  4.  концептуальное проектирование;
  5.  реализация;
  6.  оценка работы и поддержка базы данных;
  7.  снятие с эксплуатации.

Опишем главные задачи каждого этапа.

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

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

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

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

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

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

Последний этап – снятие с эксплуатации базы данных. Существует правила, что сведения из базы данных не должны уничтожаться, а передаются в Государственный архив. Срок хранения в архиве определяется ценностью информации. Так, данные о заработной плате хранятся 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. Целью данной работы являлось создание структуры машинно-независимого языка описания задач, ориентированного на системный уровень обработки данных. Основой концептуальной модели является представление, что информационная система имеет дело с объектами и событиями реального мира, которые представляются в виде данных.

Информационная алгебра оперирует понятиями "сущность" и "свойства". Сущность – нечто физически существующее в реальном мире. Сущность имеет свойства. Для каждой сущности каждому из ее свойств приписывается значение из множества значений свойства. Также в информационной алгебре вводятся ряд понятий: система координат, точка значений, пространство свойств. Вводятся также понятия комплекса и агрегата.

При описании задач основной операцией является отображение одного подмножества пространства свойств на другое. Рассматриваются два типа отображений. Одно соответствует операциям в данном файле (можно, например, определить отображение группы из пяти точек для каждого рабочего в одну новую точку, которая будет содержать итог за неделю). Эта операция называется агрегированием. Второй тип отображения соответствует операции обработки файлов, при которой точки из некоторого числа входных файлов обрабатываются для получения нового выходного файла – комплексирование данных.

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

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

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

  1.  носители свойств могут находиться в определенных отношениях друг с другом и образовывать некоторую структуру;
  2.  сами свойства между собой также могут находиться в некоторых отношениях.

В модели CODASYL введено понятие значения показателя, при этом также необходимо указать некоторую характеристику упорядочения, такую как номер наблюдения, дату измерения показателя, время и т. п., чтобы была возможность различать ряд значений определенного объекта по определенному показателю. Данная характеристика, ввиду ее природой естественности, в модели CODASYL присутствует неявно и входит в свойства. Выделение характеристики упорядочения позволяет при необходимости исследовать динамику изменения показателей, задать отношения: быть позже, быть раньше, относиться к одному интервалу (к неделе, месяцу, году), отстоять на определенный промежуток времени и др.; ввести операции усреднения по интервалам и подсчета итоговых сумм за период. То есть использование характеристики упорядочения дает возможность в значительной мере автоматизировать процесс подготовки данных для последующего анализа, в том числе статистического. Существует целое направление так называемых временных (temporal) баз данных, учитывающих изменения данных во времени.

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

Рис. 5. Два вида связей в модели Смитов

Субъект

Субъект

Физич. лицо

Юридич. лицо

Адрес

Имя

   Обобщение

Агрегация

Исходными базовыми понятиями в трактовке этих двух специалистов являются объекты и связи между объектами. Связи могут быть двух видов: обобщение и агрегация (рис. 5).

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

Кроме этих базовых имеются и другие понятия концептуальной модели, как-то атрибут, отношение, экземпляр, индивид. Самое замечательное в модели Смитов – это относительность перечисленных понятий. Одно и то же явление может быть и объектом, и отношением, и атрибутом, и экземпляром, и индивидом, и все определяется точкой зрения на явление. Зависимость интерпретации от точки зрения на явление (а точнее – возможность выбора точек зрения с разной интерпретацией) – это очень мощное свойство, придающее концептуальной модели большую гибкость и приспособляемость в описании проектируемой ИС. Это свойство, например, будь оно реализовано, позволило бы в информационной системе смотреть на "адрес" то как на объект реестра адресов, то как на атрибут "лица", то как на отношение, связывающее владельца с остальными жильцами – когда, где и кому как нужно. Наиболее близко к концептуальной в этом отношении подошла (теоретическая) реляционная модель данных, а вот объектный подход с его фиксированной интерпретацией структуры отстоит от реляционного на шаг назад.

В модели Смитов выделяются две иерархии – иерархия агрегаций (отношение разнородных объектов) и иерархия обобщений (по типу "собака, лошадь – животное"), в точках пересечения появляются абстрактные объекты. Вводится также ряд понятий: индивиды, категории, компоненты. Для успешной интеграции понятий существует "принцип относительности объектов", который утверждает, что индивиды, категории, отношения и компоненты суть разные способы рассмотрения одних и тех же объектов. Разработана методология спецификаций, основанная на принципах относительности объектов и сохранения индивидов. Отказ от четкого разграничения ролей объектов является одновременно и сильной и слабой стороной данной модели. Слабые стороны данной модели проявляются в тех случаях, когда можно четко разделить объекты (носители свойств) и свойства, что характерно для систем статистической обработки. Можно отметить, что не существует формализма, позволяющего отличить объект от свойства, поэтому это должно задаваться извне для построения более конкретной модели.

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

Следует учитывать, что это одна из первых инфологических моделей. Чарльз Бахман в GE (General Electric) построил прототип системы навигации по данным. За руководство работы инициативной группой DBTG, разработавшей стандартный язык определения данных и манипулирования данными, Бахман получил Тьюринговскую премию. В своей Тьюринговской лекции он описал эволюцию моделей плоских файлов к новому миру, где программы могут осуществлять навигацию между записями, следуя связям между записями. Идеологическая основа работы Бахмана (более "научно" называемая моделью базы данных) IDS, за которую Бахман заслуженно был удостоен в 1973 г. высшей компьютерной награды ACM, получила название "сетевой" (network).

Модель "сущность-связь". Наиболее популярной семантической моделью является модель "сущность-связь" (E/REntity/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. Иерархические модели

Рис.7. Дерево

Иерархическая модель данных была создана в 60-х годах как отражение потребностей практики. Иерархическая модель состоит из упорядоченного набора экземпляров типа дерево (рис. 7).

Тип "дерево" является составным. Он может включать в себя подтипы ("поддеревья"), также являющиеся типом "дерево". Тип "дерево" состоит из вершины ("корневого" типа) и упорядоченного набора из нуля или более типов "поддеревьев". Каждый из элементарных типов, включенных в тип "дерево", является простым или составным типом "запись". Простая "запись" состоит из одного типа, например, символьного, а составная "запись" объединяет некоторую совокупность различных типов, например, числовые и символьные. Пример типа "дерево" (схемы иерархической БД) приведен на рис 8.

Группа студентов

Группа_номер    Группа_количество      Группа_стипендия

Староста

Ст_номер    Ст_ФИО      Ст_телефон

Студенты

Студ_номер    Студ_ФИО    Студ_стипендия

Рис. 8. Пример типа "дерево"

Корневой тип имеет подчиненные типы и сам не является подтипом (подчиненным типом). Подтип является потомком по отношению к предку (родителю).

В примере, приведенном на рис. 8, Группа является предком для Староста и Студенты, а Староста и Студенты – потомки Группа. Между типами записи поддерживаются связи.

Тип "дерево" в целом представляет собой иерархически организованный набор типов "запись". База данных представляет совокупность таких деревьев. Пример данных в структуре рис.8 приведен на рис. 9.

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

  1.  найти указанное "дерево" БД (например, Группу 21 ИТ);
  2.  перейти от одного дерева к другому;
  3.  перейти от одной записи к другой внутри дерева (например, к следующей записи типа Студенты);
  4.  перейти от одной записи к другой в порядке обхода иерархии;
  5.  вставить новую запись в указанную позицию;
  6.  удалить текущую запись.

Группа студентов

22 ИТ                                 22                           6000

Староста

5          Смехов В.И.        10-32-18

Рис. 9. Пример данных в базе данных

Студенты

2              Иванова Т.И.               300

7              Матвеев Р.С.                235

3              Петров С.И.                 350

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

Иерархическая модель данных активно использовалась во многих СУБД до появления реляционных систем. Наиболее известным ее представителем является СУБД IMS компании IBM Corp., первая версия которой появилась в 60-е гг. СУБД IMS эксплуатируется и в настоящее время. Иерархическую модель данных поддерживают также следующие СУБД: MARK IV компании Control Pate Corporation, System 2000, разработанный SAS-Institute и др.

"Живучесть" иерархических моделей обусловлена тем, что многие структуры данных естественным образом иерархичны (например, в области биологии: виды, классы, группы и т.д.).

3.2. Сетевые модели

Концепция сетевой модели данных была сформулирована в конце 60-х годов в Предложениях группы CODASYL, и с тех пор на нее ссылаются как на модель CODASYL DTBG. Сети представляют естественный способ представления отношений между объектами. Они широко применяются в математике, физике, социологии и др. областях знаний. Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь одного предка; в сетевой структуре данных потомок может иметь любое число предков. Возможные связи в сетевой модели представлены на рис. 10.

Рис. 10. Сети

Сетевая БД состоит из набора записей и набора связей между этими записями. Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи С с типом записи предка P и типом записи потомка PT должны выполняться следующие два условия:

  1.  каждый экземпляр типа P является предком только в одном экземпляре C;
  2.  каждый экземпляр PT является потомком не более чем в одном экземпляре С.

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

  1. тип записи потомка в одном типе связи может быть типом записи предка в другом типе связи (как в иерархии);
  2. данный тип записи P может быть типом записи предка в любом числе типов связи;
  3.  данный тип записи P может быть типом записи потомка в любом числе типов связи;
  4.  может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 – два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться;
  5.  типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком – в другой;
  6.  предок и потомок могут быть одного типа записи.

Имеет старосту

Группа

Студенты

Староста

Состоит из студентов

Рис. 11. Пример сетевой БД

Учатся в группе

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

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

  1.  найти конкретную запись в наборе однотипных записей (студента Петрова С.И.);
  2.  перейти от предка к первому потомку по некоторой связи (к первому студенту группы 22 ИТ);
  3.  перейти к следующему потомку в некоторой связи (от Петрова С.И. к Матвееву Р.С.);
  4.  перейти от потомка к предку по некоторой связи (найти группу Ивановой Т.И.);
  5.  создать новую запись;
  6.  удалить запись;
  7.  изменить запись;
  8.  включить в связь;
  9.  исключить из связи;
  10.  переставить в другую связь и т.д.

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

Системы на основе сетевой модели не получили широкого распространения на практике. Типичным представителем подобной СУБД является IDMS компании Cullinana Corp. После вхождения Cullinana Corp в состав Computer Associates, правами на систему IDMS стала обладать эта компания, которая до сих пор продолжает ее поставлять и развивать.

3.3. Реляционные модели

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

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

В это же время компания 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. Основные понятия реляционной модели

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

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

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

Атрибут соответствует столбцу таблицы. Количество атрибутов называется степенью отношения.

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

Первичный ключ – уникальный идентификатор отношения, однозначно определяющий каждый кортеж.

В реляционной теории определяются свойства отношений:

  1.  Отношение не должно содержать одинаковых кортежей. Важным следствием этого свойства является то, что каждую строку можно однозначно определить с помощью набора атрибутов, составляющих первичный ключ.
  2.  Кортежи не упорядочены сверху вниз.
  3.  Атрибуты не упорядочены слева направо.
  4.  Все значения атрибутов должны быть атомарными (простыми), т.е. не допускать группы значений в одном столбце одной строки (не расчленять значения).

На рис.12 приведен пример отношения Провайдеры Internet.

Отношение Провайдеры Internet включает 4 домена. Домен 1 содержит названия провайдеров, домен 2 – почасовую оплату, домен 3 – предлагаемую скорость соединения, домен 4 – адреса Web-сайтов.

Рис. 12. Отношение Провайдеры Internet

Отношение (таблица)

Атрибут Почасовая оплата

Кор

т

ежи

Значение атрибута

Название

провайдера

Почасовая оплата

Скорость

Web-сайт

Демос

44,0

45

www.demos.ru

Портал

38,0

50

www.portal.ru

Гласнет

46,0

48

www.glasnet.ru

Отношение Провайдеры Internet содержит 3 кортежа, каждый из которых состоит из 4-х элементов, выбираемых из соответствующего домена. Каждому кортежу соответствует строка таблицы.

Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид ПРОВАЙДЕРЫ INTERNET(Название Провайдера, Почасовая Оплата, Скорость, Web-Сайт). Множество собственно кортежей отношения часто называют содержимым (телом) отношения.

Каждое отношение имеет минимальный набор атрибутов, по значениям которых можно однозначно идентифицировать требуемый кортеж. Такой набор называется ключом. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать отношение по оставшимся. Каждое отношение обладает хотя бы одним возможным ключом. Любой из возможных ключей принимается за первичный ключ. Первичным ключом называется атрибут отношения, однозначно определяющий каждый из его кортежей. Например, в отношении ПРОВАЙДЕРЫ INTERNET ключевым может являться атрибут Название провайдера. Ключ может быть составным, т.е. содержать несколько атрибутов. Следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов.

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

  1.  исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);
  2.  упорядочения кортежей. Некоторые СУБД позволяют производить упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним – возрастание, а по другим – убывание);
  3.  ускорения работы с кортежами отношения;
  4.  организации связывания таблиц.

База данных содержит несколько таблиц. Иногда одни и те же имена атрибутов используются в разных таблицах. Пусть в отношении R1 имеется неключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 является внешним ключом. Т.е. внешний ключ представляет набор атрибутов отношения, значения которых являются одновременно значениями первичного ключа другого отношения. Внешний ключ, ссылающийся на свою собственную реляционную таблицу, называется рекурсивным внешним ключом. С помощью внешних ключей устанавливаются связи между отношениями.

Например, имеются следующие отношения КЛИЕНТЫ (Код клиента, Название клиента, Адрес клиента) и ЗАКАЗЫ (Номер заказа, Код клиента, Количество товара). Если определить атрибут Код клиента в отношении КЛИЕНТЫ как первичный ключ, то в отношении ЗАКАЗЫ этот атрибут будет являться внешним ключом. Если каждый клиент может разместить только один заказ, то говорят, что таблицы связаны соотношением "один-к-одному". Если же каждый клиент может разместить любое количество заказов (в том числе и ни одного), то таблицы связаны соотношением "один-ко-многим". Таблица КЛИЕНТЫ в этом контексте называется основной, таблица заказы – дополнительной. Существуют типы связей "многие-ко-многим" и "многие-к-одному". Подробнее типы связей рассмотрены в главе 4.

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

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

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

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

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

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

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

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

  1.  все строки таблицы должны быть уникальны, т. е. не может быть в таблице двух одинаковых строк;
  2.  имена столбцов таблицы должны быть различны, а значения их атомарными;
  3.  все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов;
  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

Материалы

М#

Наименование материала

Тип

MS

Город_M

M1

Ткань пальтовая "Ассоль"

п/ш

380

Москва

M2

Сукно костюмное "Снежинка"

ч/ш

400

Омск

M3

Ткань пальтовая-мохер "День"

п/ш

600

Улан-Удэ

M4

Ткань костюмная "Вечер"

п/э

280

Тюмень

M5

Ткань костюмно-платьевая "Искра"

п/э

270

Тюмень

M6

Драп пальтовый "Бриз"

ч/ш

750

Москва

Таблица 4

Поставки

S#

М#

Количество

S1

M1

3900

S1

M2

2100

S1

M3

2700

S1

M4

2400

S1

M5

2200

S1

M6

1900

S2

M1

3200

S2

M2

4100

S3

M2

700

S4

M2

1100

S4

M4

900

S4

M5

4300

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

Объединением двух совместимых отношений R1 и R2 одинаковой размерности (R1 UNION R2) является отношение R, содержащее все кортежи, которые принадлежат исходным отношениям (за исключением повторяющихся).

Пример 3.1. Объединение отношений

Пусть отношением R1 будет множество поставщиков из Москвы, а отношением R2 – множество поставщиков, которые поставляют материал M1. Тогда отношение R обозначает поставщиков, находящихся в Москве, или поставщиков, поставляющих материал M1, либо тех и других (рис. 13).

Рис. 13. Пример объединения отношений

Отношение R1

П#

Поставщик

Статус

Город_П

S1

ООО "Росмануфактура

30

Москва

S4

ЧП Федоров А.К.

20

Москва

Отношение R2

П#

Поставщик

Статус

Город_П

S1

ООО "Росмануфактура"

30

Москва

S2

ООО "Сибтекстиль"

15

Тюмень

Таблица 7

Отношение R

П#

Поставщик

Статус

Город_П

S1

ООО "Росмануфактура"

30

Москва

S4

ЧП Федоров А.К.

20

Москва

S2

ООО "Сибтекстиль"

15

Тюмень

Вычитанием совместимых отношений 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 с телом, включающим в себя кортежи, одновременно принадлежащие обоим отношениям.

S1

ООО "Росмануфактура"

30

Москва

Рис. 15. Пример пересечения отношений

Для отношений R1 и R2 результирующее отношение R будет означать всех поставщиков из Москвы, поставляющих материал 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. Выборка

М#

Наименование материала

Тип

MS

Город_М

M1

Ткань пальтовая "Ассоль"

п/ш

380

Москва

M4

Ткань костюмная "Вечер"

п/э

280

Тюмень

M5

Ткань костюмно-платьевая "Искра"

п/э

270

Тюмень

Рис. 16. Результат выборки 1

1. Логическое выражение: M WHERE MS <400 (рис. 16). Результирующее отношение содержит кортежи таблицы М, содержащие материалы, поверхностная плотность которых меньше 400.

S#

М#

Количество

S1

M1

3900

Рис. 17. Результат выборки 2

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 запрещается.

Операция проекции допускает следующие дополнительные варианты записи.

  1.  Отсутствие списка атрибутов подразумевает указание всех атрибутов (операция тождественной проекции);
  2.  Выражение вида R[ ] означает пустую проекцию, результатом которой является пустое множество;
  3.  Операция проекции может применяться к произвольному отношению, в том числе и к результату выборки.

Пример 3.4. Проекция

Тип

Город_М

п/ш

Москва

ч/ш

Омск

п/ш

Улан-Удэ

п/э

Тюмень

ч/ш

Москва

Рис. 18. Результат проекции 1

1. Результат проекции отношения M на атрибуты Тип, Город_М  (M[Тип, Город_М]) представлен на рис. 18.

S#

Город_П

S1

Москва

S4

Москва

Рис. 19. Результат проекции 2

2. Результат проекции ((S WHERE Город_П="Москва")[S#, Город_П]) (рис. 19).

Деление для двух отношений (бинарного и унарного), возвращает отношение, содержащее все значения одного атрибута бинарного отношения, которое соответствует (в другом атрибуте) всем значениям в унарном отношении.

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

Пример 3.5. Деление отношений

Отношения R1, R2, R

S#

М#

М#

S#

S1

M1

M2

S1

S1

M2

M4

S4

S1

M3

S1

M4

S1

M5

S1

M6

S2

M1

S2

M2

S3

M2

S4

M2

S4

M4

S4

M5

Рис. 20. Пример деления отношений

R1 – проекция SM[S#, М#], R2 – отношение с заголовком М# и телом M2, M4. Результатом будет отношение R с заголовком 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#

Поставщик

Рейтинг

Город

М#

Наименование материала

Тип

MS

S1

ООО "Росмануфактура"

30

Москва

M1

Ткань пальтовая "Ассоль"

п/ш

380

S1

ООО "Росмануфактура"

30

Москва

M6

Драп пальтовый "Бриз"

ч/ш

750

S2

ООО "Сиб-текстиль"

15

Тюмень

M4

Ткань костюмная "Вечер"

п/э

280

S2

ООО "Сиб-текстиль"

15

Тюмень

M5

Ткань костюмно-платьевая "Искра"

п/э

270

S4

ЧП Федоров А.К.

20

Москва

M1

Ткань пальтовая "Ассоль"

п/ш

380

S4

ЧП Федоров А.К.

20

Москва

M6

Драп пальтовый "Бриз"

ч/ш

750

S5

ООО "Андромеда"

10

Омск

M2

Сукно костюмное "Снежинка"

ч/ш

400

Рис. 21. Результат естественного соединения

Соединение С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#

Поставщик

Рейтинг

Город_П

М#

Наиме-нование материала

Тип

MS

Город_М

S2

ООО "Сиб-текстиль"

15

Тю-мень

M1

Ткань пальтовая "Ассоль"

п/ш

380

Москва

S2

ООО "Сиб-текстиль"

15

Тю-мень

M2

Сукно "Снежинка"

ч/ш

400

Омск

S2

ООО "Сиб-текстиль"

15

Тю-мень

M6

Драп пальтовый "Бриз"

ч/ш

750

Москва

S5

ООО "Андро-меда"  

10

Омск

M1

Ткань пальтовая "Ассоль"

п/ш

380

Москва

S5

ООО "Андро-меда"

10

Омск

M6

Драп пальтовый "Бриз"

ч/ш

750

Москва

При рассмотрении операций реляционной алгебры К. Дж. Дейтом вводятся дополнительные операторы: переименования, расширения, подведения итогов, обновления [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>,...,

<выр_NS <атр_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 Количество поставок

S#

Количество поставок

S1

6

S2

2

S3

1

S4

3

Рис. 22. Подведение итогов

Результат вычисления показан на рис. 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') [Поставщик].

  1.  Получить названия поставщиков, которые не поставляют материал M2:

((S [S#] MINUS (SP WHERE M#='M2') [S#]) JOIN S) [Поставщик].

  1.  Получить названия поставщиков, поставляющих все детали:

((SP [S#, M#] DIVIDEBY M [M#] JOIN S [Поставщик].

  1.  Получить названия поставщиков, которые поставляют по крайней мере один материал типа 'п/ш':

(((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

CUST_NAME 

CUST_SUM 

3101

ООО "PC-Style"

50000

3102

ООО "Гермес"

70000

3103

ЧП Федоров В.Г.

15000

3104

ООО "Формат"

100000

3105

ЧП Гришин П.В.

20000

3106

ОАО "Энтрон"

125000

3107

ЗАО"IT-COM"

135000

3108

ООО "Омега"

95000

3109

ОАО " PC-Центр"

160000

Таблица 7

PROD  

PROD_ID 

PROD_NAME 

PRICE 

STORE 

3P

Процессор Celeron 2400

90

1000

4P

Процессор Athlon XP 2600+

110

1200

6P

Процессор Pentium-4 2600

200

800

4MB

Материнская плата GA 81 PE 1000

100

1400

7MB

Материнская плата EPOX 8KRA2+

95

1350

3V

Видеокарта Nvidia GeForce FX5600 128mb

140

770

4V

Видеокарта Ati Radeon 9500 64mb

150

850

1M

ОЗУ DDR 256 MB PC 2700

45

1150

2M

ОЗУ DDR 256 MB PC 3200

50

1250

3M

ОЗУ DDR 512 MB PC 3200

97

1600

Таблица 8

ORDERS 

ORDER_NUM 

CUST_NUM 

PROD_ID 

QTY  

DATE_ORDER 

221

3101

3P

15

20.12.02

222

3105

4MB

30

20.12.02

223

3106

6P

16

21.12.02

224

3101

3V

12

5.01.03

225

3105

4P

27

17.01.03

226

3104

1M

10

14.02.03

227

3103

7MB

18

18..02.03

228

3102

2M

21

1.03.03

229

3103

3P

17

5.03.03

230

3108

3M

16

5.03.03

231

3107

4MB

10

7.03.03

QBE предлагает пользователю для создания запроса заполнение таблиц-шаблонов. В первом столбце таблицы-шаблона выводится имя таблицы, во всех остальных – имена столбцов.

Пример 3.8. Пример заполнения шаблона запроса

Запрос "Вывести названия всех клиентов" можно сформулировать с помощью следующего шаблона (рис. 23):

CUST УРЕ

CUST_NUM 

CUST_NAME 

CUST_SUM 

Рис. 23. Шаблон запроса

P.

В приведенном шаблоне "P." – это команда вывода, означающая, что выводятся значения заданного столбца. После команды в языке QBE ставится точка.

CUST_NAME

ООО "PC-Style"

ООО "Гермес"

ЧП Федоров В.Г.

ООО "Формат"

ЧП Гришин П.В.

ОАО "Энтрон"

ЗАО"IT-COM"

ООО "Омега"

ОАО " PC-Центр"

Результат выполнения приведенного шаблона следующий:

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

Рассмотрим различные варианты создания запросов.

Пример 3.9. Запрос с простым условием сравнения

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

P.

<90

Рис. 24. Запрос с простым условием

Вывести все товары, цена которых не превышает 90 долларов. Шаблон будет выглядеть следующим образом (рис. 24).

Результатом запроса является следующий набор данных:

PROD_NAME 

ОЗУ DDR 256 MB PC 2700

ОЗУ DDR 256 MB PC 3200

Пример 3.10. Запрос с составным условием сравнения (логическая операция И)

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

P.

>100

>1000

Рис. 25. Запрос на выборку с операцией "И"

Требуется вывести товары, цена которых больше 100 долларов и количество которых на складе больше 1000 единиц (рис. 25).

Результат запроса:

PROD_ID 

PROD_NAME 

PRICE 

STORE 

4P

Процессор Athlon XP 2600+

110

1200

Выводятся все данные выбранной строки, т.к. в шаблоне запроса команда вывода "P." стоит в первом столбце шаблона. Если два условия стоят на одной строке шаблона, то для выбора строки необходимо выполнение обоих условий (логическая операция И).

Пример 3.11. Запрос с составным условием сравнения (логическая операция ИЛИ)

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

P.

P.>100

P.

P.

P.

P.>1000

Рис. 26. Запрос на выборку с операцией "ИЛИ"

Вывести все товары, цена которых больше 100 долларов или количество которых на складе больше 1000 единиц (рис. 26).

Условия, записанные на двух разных строках шаблона запроса, соответствуют условиям, объединенным логическим оператором ИЛИ. Команда вывода P. расположена на обеих строках и в каждом из столбцов, которые должны выводится.

Результат запроса следующий:

PROD_NAME 

PRICE 

STORE 

Процессор Athlon XP 2600+

110

1200

Процессор Pentium-4 2600

200

800

Материнская плата GA 81 PE 1000  

100

1400

Материнская плата EPOX 8KRA2+ 

95

1350

Видеокарта Nvidia GeForce FX5600 128mb

140

770

Видеокарта Ati Radeon 9500 64mb 

150

850

ОЗУ DDR 256 MB PC 2700

45

1150

ОЗУ DDR 256 MB PC 3200

50

1250

ОЗУ DDR 512 MB PC 3200

97

1600

Пример 3.12. Запрос с использованием блока условий

Например, требуется вывести товары с ценой от 100 до 150 долларов. Для этого введем блок условий с явным заданием операции "И". Этот блок, обозначенный CONDITIONS содержит любые требуемые ограничения данных. В нашем примере к значениям одного и того же столбца должны одновременно применяться два условия. Поэтому  удобно применить одно условие в блоке условий (рис. 27).

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

P.

_S

CONDITIONS

_S>=100 AND _S<=150

Рис. 27. Использование блока условий

В этом примере введена переменная _S, которая является элементом-образцом и обозначает неопределенное значение в столбце таблицы. В данном примере элемент-образец обозначает любое возможное значение столбца PRICE.

Результат:

PROD_ID 

PROD_NAME 

PRICE 

STORE 

4P

Процессор Athlon XP 2600+

110

1200

4MB

Материнская плата GA 81 PE 1000  

100

1400

3V

Видеокарта Nvidia GeForce FX5600 128mb

140

770

4V

Видеокарта Ati Radeon 9500 64mb 

150

850

Пример 3.13. Сравнение с элементами-образцами

Определить товар, цена которого больше, чем цена видеокарты Nvidia GeForce FX5600 128mb . Пример шаблона приведен на рис. 28.

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

P.

P.>_В

Видеокарта Nvidia GeForce FX5600 128mb

Рис. 28. Сравнение с элементами-образцами

По-другому запрос можно сформулировать следующим образом: "Цена видеокарты Nvidia GeForce FX5600 128mb обозначена как _В. Вывести все товары, цена которых больше, чем _В."

Результат:

PROD_NAME 

PRICE 

Процессор Pentium-4 2600

200

Видеокарта Ati Radeon 9500 64mb 

150

Рассмотрим создание многотабличных запросов.

Пример 3.14. Объединение двух таблиц

Допустим, необходимо вывести название фирм-клиентов, заказавших количество товара больше 20 единиц. Для создания этого запроса необходимо объединить две таблицы. Элемент-образец _CN связывает две таблицы (рис. 29).

CUST

CUST_NUM

CUST_NAME 

CUST_SUM 

_CN

P.

ORDERS

ORDER_NUM 

CUST_NUM 

PROD_ID 

QTY  

DATE_ORDER 

_CN

P. >20

Рис. 29. Связывание двух таблиц

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

Результат:

CUST_NAME 

QTY

ЧП Гришин П.В.

30

ЧП Гришин П.В.

27

ООО "Гермес"

21

Пример 3.15. Запрос с использованием трех таблиц

Вывести названия клиентов, заказавших процессор Celeron 2400 (рис. 30).

CUST

CUST_NUM

CUST_NAME 

CUST_SUM 

_CN

P.

ORDERS

ORDER_NUM

CUST_NUM

PROD_ID

QTY

DATE_ORDER

_CN

_PI

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

_PI

Процессор Celeron 2400

Рис. 30. Связывание трех таблиц

Результат:

CUST_NAME 

ООО "PC-Style"

ЧП Федоров В.Г.

Пример 3.16. Связывание таблиц с вычислениями

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

_PI

_PR

ORDERS

ORDER_NUM

CUST_NUM

PROD_ID

QTY

DATE_ORDER

_OR

_PI

_QT

P.

_OR

'Объем заказа='

_PR*_QT

Рис. 31. Запрос с вычислениями

Определить объем каждого заказа в таблице ORDERS (рис.31).

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

Результат:

ORDER_NUM 

221        Объем заказа=1350

222        Объем заказа=3000

223        Объем заказа=3200

224        Объем заказа=1680

225        объем заказа=2970

226        Объем заказа=450

227        Объем заказа=1710

228        Объем заказа=1050

229        Объем заказа=1530

230        Объем заказа=1552

231        Объем заказа=1000

Пример 3.17. Запрос с частичным совпадением

ORDERS

ORDER_NUM 

CUST_NUM 

PROD_ID

QTY

DATE_ORDER

_ON

_PI

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

_PI

Процессор_RT

P.

_ON

Рис. 32. Запрос с частичным совпадением

Вывести номера заказов, в которых требуется поставка только процессоров (рис. 32).

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

При записи выражений на QBE  могут использоваться встроенные функции: CNT (количество), SUM (сумма), AVG (среднее), MIN (минимум), MAX (максимум), UN (уникальный), ALL (все значения, в том числе и повторяющиеся).

Пример 3.18. Запрос с использованием функции MAX

Вывести максимальный объем из годовых заказов клиентов. Шаблон запроса представлен на рис. 33.

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

Рис. 33. Запрос с использованием функции MAX

CUST

CUST_NUM

CUST_NAME 

CUST_SUM 

_T

P.

MAX._T

Пример 3.19. Запрос с использованием функции AVG

Каков средний годовой объем заказов клиентов?

Шаблон запроса представлен на рис. 34.

Пример 3.20. Запрос с использованием функции CNT

Сколько клиентов заказало процессор Celeron 2400?

ORDERS

ORDER_NUM

CUST_NUM

PROD_ID

QTY

DATE_ORDER

_CN

_PI

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

_PI

процессор Celeron 2400

P.

CNT._CN

Рис. 35. Запрос с использованием функции CNT

Рис. 34. Запрос с использованием функции AVG 

CUST

CUST_NUM

CUST_NAME 

CUST_SUM 

_T

P.

AVG._T

Шаблон запроса показан на рис. 35.

Пример 3.21. Запрос с использованием оператора UNQ

Сколько всего клиентов сделало заказы?

ORDERS

ORDER_NUM 

CUST_NUM

PROD_ID

QTY

DATE_ORDER

_CN

P.

CNT.UNQ._CN

Рис. 36. Запрос с использованием оператора UNQ 

Шаблон запроса приведен ниже (рис. 36).

Результат: 9. Оператор UNQ применяется для того, чтобы каждого клиента подсчитать ровно один раз (повторы исключаются).

Пример 3.22. Запрос с группировкой

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

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

"G." обозначается столбец, по которому производится группировка. В нашем случае, группировка проводится по CUST_NUM, т. к. мы хотим подсчитать общее количество товара по каждому клиенту. Затем используется целевая таблица, задающая вывод столбца, по которому производится группировка и значений функций, применных к группам (рис. 37)

ORDERS

ORDER_NUM 

CUST_NUM 

PROD_ID 

QTY

DATE_ORDER 

G._CN

_QT

P.

_CN

SUM.QT

Рис. 37. Запрос с группировкой

Результат:

CUST_NUM 

QTY  

3101

27

3105

57

3106

16

3104

10

3103

35

3102

21

3108

16

3107

10

Пример 3.23. Запрос с группировкой и условием

ORDERS

ORDER_NUM 

CUST_NUM 

PROD_ID

QTY 

DATE_ORDER

_ON

G._CN

P.

_CN

CNT._ON >1

Рис. 38. Запрос с группировкой и условием

Вывести номера клиентов, сделавших более одного заказа      (рис. 38).

Результат:

CUST_NUM

3101

3103

3105

В отличие от рассмотренных операций, операции вставки, удаления и модификации приводят к изменению исходной таблицы. Вид операции (вставка – I., удаление – D., модификация – U.) записывается в шаблоне под именем таблицы, а константы и условные выражения указываются по тем же правилам, что и в операциях выборки.

Пример 3.24. Вставка данных в таблицу

ORDERS

ORDER_NUM 

CUST_NUM

PROD_ID

QTY

DATE_ORDER

I.

232

3109

4V

20

9.03.03

Рис. 39. Вставка строки в таблицу

Вставка в таблицу ORDERS нового заказа может выглядеть следующим образом (рис. 39):

Пример 3.25. Удаление информации из таблицы

Пусть необходимо удалить информацию о заказах клиента 3105 (рис. 40).

ORDERS

ORDER_NUM 

CUST_NUM

PROD_ID 

QTY

DATE_ORDER 

D..

3105

Рис. 40. Удаление данных о клиенте

Из таблицы ORDERS удаляется вся информация о клиенте 3105.

Пусть необходимо удалить информацию о заказах, сделанных до 17.01.03. Шаблон запроса выглядит следующим образом (рис. 41):

ORDERS

ORDER_NUM

CUST_NUM

PROD_ID

QTY

DATE_ORDER

D.

< '17.01.03'

Рис. 41. Удаление данных о заказах

Пример 3.26. Изменение данных

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

U.

Процессор Athlon XP 2600+

130

Рис. 42. Изменение данных

Для изменения цены процессора Athlon XP 2600+ нужно сформировать запрос (рис. 42).

Пример 3.27. Изменение данных с вычислениями

PROD

PROD_ID 

PROD_NAME 

PRICE 

STORE 

U.

1.05*_K

_K

Рис. 43. Изменение данных с вычислениями

Для того, чтобы повысить цену всех товаров на 5% можно сформировать запрос на изменение информации (рис. 43).

Современные СУБД имеют незначительные изменения от классического варианта QBE в интерпретации отдельных операций, введению дополнительных операций и изменению формы представления языка.

3.3.4. Структурированный язык запросов SQL

SQL (Structured Query Language) – структурированный язык запросов – является инструментом, предназначенным для выборки и обработки информации, содержащейся в компьютерной базе данных. SQL является языком программирования, применяемым для организации взаимодействия пользователя с базой данных (рис. 44). SQL работает только с реляционными базами данных и предоставляет пользователю следующие функциональные возможности:

  1.  изменение структуры представления данных;
  2.  выборка данных из базы данных;
  3.  обработка базы данных, т. е. добавление новых данных, изменение, удаление имеющихся данных;
  4.  управление доступом к базе данных;
  5.  совместное использование базы данных пользователями, работающими параллельно;
  6.  обеспечение целостности базы данных.

СУБД

Обрабатывает запрос

База

данных

Рис. 44. Доступ к БД с помощью SQL

Пользователь составляет 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 представлены в табл. 10.

При описании синтаксиса инструкций будем использовать следующие правила:

  1.  каждая инструкция начинается с команды  ключевого слова, описывающего действие, выполняемое инструкцией (например, CREATE – создать, DELETE – удалить и т. д.);
  2.  после команды следует одно или несколько предложений, описывающих данные, с которыми работает инструкция, или содержащих дополнительную информацию о действии, выполняемом инструкцией. Каждое предложение начинается с ключевого слова, например, WHERE (где), FROM (откуда), INTO (куда), HAVING (имеющий);
  3.  в квадратные скобки "[…]" заключены необязательные элементы;
  4.  вертикальная черта "|" , разделяющая два элемента, указывает на то, что в инструкции используется либо один элемент, либо второй;
  5.  в фигурные скобки "{…}"заключаются элементы, разделенные вертикальной чертой;
  6.  троеточие означает, что далее в инструкции либо следует выражение, либо повторяются элементы, указанные перед тремя        точками.

Таблица 10

Инструкции языка SQL

Вид

Название

Назначение

DDL

CREATE TABLE

Добавление новой таблицы в БД

DROP TABLE

Удаление таблицы

ALTER TABLE

Изменение структуры таблицы

CREATE INDEX

Создание индекса для столбца

DROP INDEX

Удаление индекса столбца

CREATE VIEW

Создание нового представления

DROP VIEW

Удаление представления

GRAND

Назначение привилегий доступа пользователей к БД

REVOKE

Удаление привилегий

CREATE SCHEMA

Добавление новой схемы в БД

DROP SCHEMA

Удаление схемы

DML

SELECT

Выборка данных из таблицы

UPDATE

Обновление данных в таблице

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. Выбор с условием

Вывести названия товаров, цена которых больше 100$. Инструкцию SELECT для этого запроса можно записать так:

SELECT PROD_NAME

FROM PROD  

WHERE PRICE>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 (табл. 11).

Таблица 11

Отношение R

Код_материала

Наименование

Тип

Код_модели

101

Ткань пальтовая "Ассоль"

п/ш

312

101

Ткань пальтовая "Ассоль"

п/ш

512

210

Ткань подкладочная "Фея"

п/э

312

210

Ткань подкладочная "Фея"

п/э

512

210

Ткань подкладочная "Фея"

п/э

460

210

Ткань подкладочная "Фея"

п/э

430

315

Драп пальтовый "Бриз"

ч/ш

460

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

Предположим, что тип ткани подкладочной "Фея" указан неправильно. Тогда необходимо внести изменения не в один кортеж, а во все четыре (представьте, сколько может быть кортежей в реальной БД!). Такая ситуация , при которой изменение значения одного данного, может повлечь за собой просмотр и редактирование нескольких строк таблицы, называется аномалией модификации (редактирования).

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

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

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

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

Каждой нормальной форме соответствует некоторый набор ограничений. Отношение находится в определенной нормальной форме, если оно удовлетворяет набору ограничений этой формы. Основные свойства нормальных форм:

  1.  каждая следующая нормальная форма в некотором смысле лучше предыдущей;
  2.  при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

  1.  первая нормальная форма (1NF);
  2.  вторая нормальная форма (2NF);
  3.  третья нормальная форма (3NF);
  4.  нормальная форма Бойса-Кодда (BCNF);
  5.  четвертая нормальная форма (4NF);
  6.  пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Процесс нормализации основан на понятии функциональной зависимости. Функциональные зависимости позволяют накладывать определенные ограничения на реляционную схему. Идея состоит в том, что значение одного атрибута в кортеже определяет значение другого атрибута. Например, в каждом кортеже отношения R Код_материала определяет Наименование; Код_материала определяет Тип (табл. 11). Можно записать функциональные зависимости:

Код_материала Наименование

Код_материала Тип

Для дальнейшего изложения нам потребуется несколько определений.

Определение 1. Функциональная зависимость 

Пусть A и B – атрибуты в отношении R. Атрибут В функционально зависит от атрибута А, если в любой момент времени каждому значению атрибута А соответствует в точности одно значение атрибута В. Функциональная зависимость записывается следующим образом: AB. Данная запись означает, что если два кортежа в таблице R имеют одно и тоже значение атрибута A, то они имеют одно и тоже значение атрибута B. Атрибут в левой части называется детерминантом, т.к. его значение определяет значение атрибута в правой части. Ключи таблицы являются детерминантами.

Определение 2. Неключевой атрибут 

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

Определение 3. Полная функциональная зависимость 

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

Определение 4. Транзитивная функциональная зависимость 

Если атрибут B функционально зависит от атрибута A (AB), а атрибут C функционально зависит от атрибута B (BC), но обратная зависимость отсутствует, то говорят, что атрибут С зависит от А транзитивно.

Определение 5. Взаимно независимые атрибуты 

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

Определение 6. Отношение находится в первой нормальной форме (1NF), если значения его атрибутов атомарны. Исходное отношение строится таким образом, чтобы оно было в 1NF.

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

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

Проектирование базы данных рассмотрим на следующем примере. Пусть имеются сведения о поставках некоторой фирмой материалов. Сформируем исходное отношение Поставки (табл. 12). 

Таблица 12

Таблица Поставки

Код_зака-за

Код_ма-териала

Код_клиен-та

Город клиента

Количество

Дата поставки

1

2

3

4

5

6

110

21

BN

Омск

300

25.07.02

110

30

BN

Омск

200

25.07.02

120

13

BR

Москва

160

12.08.02

120

15

BR

Москва

150

12.08.02

Окончание табл. 12

1

2

3

4

5

6

120

16

BR

Москва

80

12.08.02

120

18

BR

Москва

250

12.08.02

130

20

BR

Москва

120

14.08.02

130

55

BR

Москва

200

14.08.02

130

71

BR

Москва

300

14.08.02

140

2

BS

Тюмень

300

26.08.02

140

62

BS

Тюмень

90

26.08.02

150

31

BN

Омск

60

4.09.02

150

70

BN

Омск

20

4.09.02

160

30

AN

Улан-Удэ

50

18.09.02

160

69

AN

Улан-Удэ

10

18.09.02

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

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

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

Для того чтобы перейти от первой ко второй нормальной форме, необходимо выполнить следующие шаги:

  1.  определить, на какие части можно разбить первичный ключ, так, чтобы некоторые из неключевых атрибутов функционально полно зависели от одной из этих частей;
  2.  создать новое отношение для каждой такой части ключа и группы зависящих от нее атрибутов и переместить их в это отношение (т. е. построить проекции на части составного первичного ключа и атрибуты, зависящие от этих частей). Часть бывшего ключа станет при этом первичным ключом нового отношения;
  3.  удалить из исходной таблицы атрибуты, перемещенные в другие отношения, кроме тех из них, которые станут внешними ключами (построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от первичного ключа).

Для приведения исходной таблицы ко второй нормальной форме поля Код_заказа, Код_клиента, Город_клиента, Дата_поставки перемещаются в новую таблицу Поставки1, при этом Код_заказа – первичный ключ новой таблицы.

Вторая таблица Заказы будет содержать составной первичный ключ Код_заказа-Код_материала и поле Количество.

В результате новые таблицы будут выглядеть следующим образом (табл. 13-14):

                                        Таблица 13                                 Таблица 14

           Поставки1                                                 Заказы

Код_за-каза

Код_кли-ента

Город клиента

Дата поставки

Код_за-каза

Код_ма-териала

Коли-чество

110

BN

Омск

25.07. 02

110

21

300

120

BR

Москва

12.08. 02

110

30

200

130

BR

Москва

14.08. 02

120

13

160

140

BS

Тюмень

26.08. 02

120

15

150

150

BN

Омск

4.09.02

120

16

80

160

AN

Улан-Удэ

18.09. 02

120

18

250

130

20

120

130

55

200

130

71

300

140

2

300

140

62

90

150

31

60

150

70

20

160

69

10

160

30

50

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

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

Устранить эти аномалии позволяет третья нормальная форма. Считается, что таблица соответствует третьей нормальной форме, если она находится во второй нормальной форме и ее неключевые атрибуты взаимно независимы и зависят только от первичного ключа. В отношении Поставки1 существует транзитивная зависимость между неключевыми атрибутами Город_клиента и Код_клиента (Код_клиента  Город_клиента).

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

  1.  определить все атрибуты (или группы атрибутов), от которых зависят другие атрибуты (выявить транзитивные зависимости);
  2.  создать новое отношение для каждого такого атрибута и для группы зависящих от него атрибутов и переместить их в это отношение (т. е. построить проекцию отношения на атрибуты, являющиеся причиной транзитивной зависимости). Атрибут, от которого зависят все остальные перемещенные атрибуты, станет при этом первичным ключом нового отношения;
  3.  удалить перемещенные атрибуты из исходного отношения, оставив лишь те, которые станут внешними ключами .

Для приведения таблицы Поставки1 к третьей нормальной форме создадим новую таблицу Клиенты (табл. 15) и переместим в нее атрибуты Код_клиента и Город_клиента. Атрибут Город_клиента из таблицы Поставки1 удалим, а атрибут Код_клиента оставим в качестве внешнего ключа (табл. 17). Таблицу Заказы оставим без изменения (табл. 16).

            Таблица 15                                                Таблица 16

  Клиенты                                                     Заказы

Код_кли-ента

Город клиента

Код_за-каза

Код_ма-териала

Количество

BN

Омск

1

2

3

BR

Москва

110

21

300

BS

Тюмень

110

30

200

AN

Улан-Удэ

120

13

160

120

15

150

120

16

80

Окончание табл. 16

1

2

3

120

18

250

130

20

120

130

55

200

130

71

300

140

2

300

140

62

90

150

31

60

150

70

20

160

69

10

160

30

50

                                                      Таблица 17

Поставки 2

Код_заказа

Код_клиента

Дата_поставки

110

BN

25.07.02

120

BR

12.08.02

130

BR

14.08.02

140

BS

26.08.02

150

BN

4.09.02

160

AN

18.09.02

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

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

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

Подробнее с технологией нормализации можно ознакомиться в литературе по теории реляционных баз данных [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. Составить алгебраическое выражение (или последовательность реляционных операций), необходимое для выполнения следующих запросов к базе данных поставщиков и материалов:
  23. получить полную информацию обо всех поставках в Москве;
  24. получить номера материалов, поставляемых поставщиком из Тюмени;
  25. получить такие пары номеров материалов, которые одновременно поставляются одним поставщиком;
  26. получить общее количество товаров, поставляемых поставщиком S1;
  27. получить названия поставщиков, которые поставляют по крайней мере один материал типа п/ш;
  28. получить типы материалов, поставляемых поставщиком S1.
  29. В компании есть несколько отделов, в каждом отделе есть несколько сотрудников, несколько проектов, несколько кабинетов. Каждый сотрудник имеет план работы (несколько заданий). Для таких заданий существует ведомость полученных вознаграждений. В каждом кабинете есть несколько телефонов. В базе данных должна содержится следующая информация:
  30. для каждого отдела: номер отдела, бюджет и номер сотрудника, который возглавляет этот отдел;
  31. для каждого сотрудника: номер сотрудника, номер текущего проекта, номер кабинета, номер телефона, название заданий вместе с датами и размерами всех оплат;
  32. для каждого проекта: номер проекта и бюджет;
  33. для каждого кабинета: номер кабинета, площадь, номера всех телефонов, установленных в кабинете.

Составить множество нормализованных отношений для представления этой информации.

  1. Создать реляционную схему базы данных предприятия сферы сервиса (парикмахерской, мастерской по ремонту бытовой техники, компьютерной фирмы и т.п.). Схема должна содержать как минимум семь таблиц, приведенных к третьей нормальной форме. Обосновать выбор структур таблиц, их взаимосвязь. Описать процесс нормализации таблиц.
  2. Дать определение данных на SQL для базы данных поставщиков и материалов.
  3. Сформулировать на SQL для базы данных поставщиков и материалов следующий запрос: "Получить названия поставщиков, поставляющих материал M2".
  4. Сформулировать на SQL следующее обновление базы данных поставщиков и материалов: "Изменить тип материала п/ш на ч/ш", "Удалить все проекты, для которых нет поставок".
  5. Сформулировать на QBE следующий запрос: "Вывести список клиентов, чья общая сумма годовых заказов превышает 70000".
  6. Сформулировать на QBE следующий запрос: "Перечислить название и цену товаров, поставка которых осуществляется после 1.03.03".
  7. Сформулировать на 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 Мастер::от_мастера;

  1.  relationship Цех выполняется_в

  inverse Цех::обеспечивает;

      };

  1.  interface Мастер {
  2.  attribute string фамилия;
  3.  attribute string имя;
  4.  attribute string отчество;
  5.   attribute Struct Адреса {string город, integer индекс, string улица,  string дом, integer квартира} адрес;
  6.   relationship Set<Изделие> от_мастера

inverse Изделие::мастера;

 };

  1.  interface Цех{
  2.   attribute string название;
  3.   attribute string адрес;
  4.   relationship Set<Изделие> обеспечивает

       inverse Изделие::выполняется_в;

      };

В строке 6 показана связь выполняется_в между изделиями и цехами. Поскольку ее типом является Цех, а не Set <Цех >, каждое изделие изготавливает только один цех. Обращение данной связи показано в строке 16 – это связь обеспечивает между цехами и изделиями. Ее типом является Set<Изделие>, поэтому каждый цех обеспечивает множество изделий – возможно, ни одно, только одно или большее число изделий.

Требования уникальности связи и ее обращения называются множественностью связей. Наиболее распространенные варианты:

  1.  Связь типа "многие-ко-многим" класса С с классом D – это связь, в которой с каждым объектом класса С ассоциируется множество объектов класса D, а в ее обращении с каждым объектом класса D ассоциируется множество объектов класса С. В описании, приведенном в примере 4.5, мастера – это связь типа "многие-ко-многим" между классом Изделие и классом Мастер; такой же является связь от_мастера между классами Мастер и Изделие.

В любом направлении связи допускается пустое множество.

  1.  Связь типа "многие-к-одному" класса С с классом D – это связь, в которой для каждого объекта класса С существует уникальный объект класса D, но в ее обращении с каждым объектом класса D связаны многие С. В примере 4.5 выполняется_в – это связь типа "многие-к-одному" класса Изделие с классом Цех. Обратная ей связь – это связь типа "'один-ко-многим" класса D с классом С. В том же примере обеспечивает – связь типа "один-ко-многим" класса Цех с классом Изделие.
  2.  Связь типа "один-к-одному" класса С с классом 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…,TnFn}

обозначает тип с именем 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 Меховой_жилет: Меховое_изделие, Жилет{

};

Итак, объект Меховой жилет определяется для выражения всех свойств обоих подклассов Жилет и никаких свойств или связей, принадлежащих т