WWW.DISS.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

 

Pages:     || 2 |

«КРАМОРЕНКО Н. В. БАЗЫ ДАННЫХ ВЛАДИВОСТОК 2004 3 ОГЛАВЛЕНИЕ ПРОГРАММА ДИСЦИПЛИНЫ АННОТАЦИЯ ВВЕДЕНИЕ МОДУЛЬ 1. ОСНОВНЫЕ ПОНЯТИЯ ГЛАВА 1.1. ВВЕДЕНИЕ В БАЗЫ ДАННЫХ ГЛАВА 1.2. ПОЛЬЗОВАТЕЛИ БАНКОВ ДАННЫХ 1.2.1. Основные ...»

-- [ Страница 1 ] --

ДАЛЬНЕВОСТОЧНЫЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ТИХООКЕАНСКИЙ ИНСТИТУТ

ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ И ТЕХНОЛОГИЙ

КРАМОРЕНКО Н. В.

БАЗЫ

ДАННЫХ

ВЛАДИВОСТОК

2004

3

ОГЛАВЛЕНИЕ

ПРОГРАММА ДИСЦИПЛИНЫ

АННОТАЦИЯ

ВВЕДЕНИЕ

МОДУЛЬ 1. ОСНОВНЫЕ ПОНЯТИЯ

ГЛАВА 1.1. ВВЕДЕНИЕ В БАЗЫ ДАННЫХ

ГЛАВА 1.2. ПОЛЬЗОВАТЕЛИ БАНКОВ ДАННЫХ

1.2.1. Основные функции группы администратора БД

ГЛАВА 1.3. АРХИТЕКТУРА БАЗ ДАННЫХ

1.3.1. Трехуровневая архитектура баз данных

1.3.2. Процесс прохождения пользовательского запроса

ГЛАВА 1.4. КЛАССИФИКАЦИЯ МОДЕЛЕЙ ДАННЫХ

ГЛАВА 1.5. ЖИЗНЕННЫЙ ЦИКЛ БД

1.5.1. Системный анализ предметной области

МОДУЛЬ 2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

ГЛАВА 2.1. ИНФОЛОГИЧЕСКОЕ (СЕМАНТИЧЕСКОЕ) МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

2.1.1. Модель «сущность-связь»

2.1.2. Пример построения модели «сущность-связь»

ГЛАВА 2.2. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

2.2.1. Реляционные объекты данных

2.2.2. Ограничения целостности в реляционной модели данных

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

2.2.4. Алгоритм перехода от модели «сущность-связь» к реляционной модели

ГЛАВА 2.3. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ НА ОСНОВЕ ПРИНЦИПОВ НОРМАЛИЗАЦИИ

2.3.1. Функциональные зависимости

2.3.2. Первая нормальная форма

2.3.3. Вторая нормальная форма

2.3.4. Третья нормальная форма

2.3.5. Нормальная форма Бойса-Кодда

2.3.6. Четвертая нормальная форма

2.3.7. Пятая нормальная форма (нормальная форма проекции-соединения)

МОДУЛЬ 3. РЕАЛИЗАЦИЯ РЕЛЯЦИОННОЙ МОДЕЛИ В СРЕДЕ ВЫБРАННОЙ СУБД

ГЛАВА 3.1. РЕАЛИЗАЦИЯ РЕЛЯЦИОННОЙ МОДЕЛИ В СРЕДЕ ВЫБРАННОЙ СУБД (MS ACCESS)

3.1.1. Создание таблиц

3.1.2. Построение схемы данных. Задание ограничений целостности

ГЛАВ 3.2. ТАБЛИЧНЫЙ ЯЗЫК ЗАПРОСОВ QBE

3.2.1. Запросы с использованием одной таблицы

3.2.2. Возможности совместной обработки нескольких таблиц, связывание таблиц

3.2.3. Вычисляемые поля

3.2.4. Возможности группировки данных. Использование агрегатных функций

3.2.5. Вложенные запросы

3.2.6. Корректирующие запросы

3.2.7. QBE как «построитель» SQL-запросов

МОДУЛЬ 4. ЯЗЫК SQL

ГЛАВА 4.1. ОПЕРАТОР ВЫБОРА SELECT

4.1.1. Синтаксис оператора SELECT

4.1.2. Запросы с использованием одной таблицы

4.1.3. Возможности совместной обработки нескольких таблиц

4.1.4. Вычисляемые поля

ГЛАВА 4.2. ПРИМЕНЕНИЕ АГРЕГАТНЫХ ФУНКЦИЙ И ВЛОЖЕННЫХ ЗАПРОСОВ В ОПЕРАТОРЕ ВЫБОРА

4.2.1. SQL-функции

4.2.2. Вложенные подзапросы

ГЛАВА 4.3. ОПЕРАТОРЫ МАНИПУЛИРОВАНИЯ ДАННЫМИ

ЗАКЛЮЧЕНИЕ. НАПРАВЛЕНИЯ РАЗВИТИЯ БАЗ ДАННЫХ

ГЛОССАРИЙ

СПИСОК ЛИТЕРАТУРЫ

ЗАДАНИЯ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ

МОДЕЛЬ «СУЩНОСТЬ-СВЯЗЬ»

РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

РЕЛЯЦИОННАЯ АЛГЕБРА

НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

ЗАПРОСЫ НА QBE

ЗАПРОСЫ НА SQL

ПРОЕКТИРОВАНИЕ БД «БИБЛИОТЕКА»

ПРОГРАММА ДИСЦИПЛИНЫ

Модуль 1. Основные понятия Глава 1.1. Введение в базы данных Глава 1.2. Пользователи банков данных Основные функции группы администратора БД Глава 1.3. Архитектура баз данных Трехуровневая архитектура баз данных Процесс прохождения пользовательского запроса Глава 1.4. Классификация моделей данных.

Документальные модели. Фактографические модели.

Глава 1.5. Жизненный цикл БД.

Этапы проектирования БД. Системный анализ предметной области Модуль 2. Проектирование базы данных Глава 2.1 Инфологическое моделирование предметной области Представление данных с помощью модели «сущность-связь» (ER-модели). Основные понятия: сущность, атрибут, ключ, связь. Виды связей.

Пример построения модели «сущность-связь»

Глава 2.1. Реляционная модель данных Реляционные объекты данных Ограничения целостности Реляционная алгебра Алгоритм перехода от модели «сущность-связь» к реляционной модели Глава 2.3. Проектирование реляционных баз данных на основе принципов нормализации Функциональные зависимости. 1НФ. 2НФ. 3НФ. НФБК. 4НФ. 5НФ Модуль 3. Реализация реляционной модели в среде выбранной СУБД Глава 3.1. Реализация реляционной модели в среде выбранной СУБД (MS Access) Создание таблиц Построение схемы данных. Задание ограничений целостности.

Глава 3.2. Табличный язык запросов (QBE) Запросы с использованием одной таблицы Возможности совместной обработки нескольких таблиц, связывание таблиц.

Вычисляемые поля.

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

Корректирующие запросы QBE как «построитель» SQL-запросов Модуль 4. Язык SQL Глава 4.1. Оператор выбора Select Синтаксис оператора Select Запросы с использованием одной таблицы Возможности совместной обработки нескольких таблиц Вычисляемые поля Глава 4.2. Применение агрегатных функций и вложенных запросов в операторе выбора SQL-функции Вложенные подзапросы Глава 4.3. Операторы манипулирования данными Заключение. Направления развития баз данных Объектно-ориентированные БД Распределенные БД Темпоральные БД В учебном пособии изложены принципы построения реляционных баз данных. Рассмотрен процесс построения концептуальных моделей, на примере модели «сущность-связь». Описываются все основные аспекты реляционной модели данных. Приведен пример реализации реляционной модели в СУБД MS Access.



Пособие предназначено для студентов специальности: 351400 «Прикладная информатика (по областям)» всех форм обучения.

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

Учебное пособие соответствует требованиям стандарта дисциплины «Базы данных» и предназначено для студентов специальности: 351400 «Прикладная информатика (по областям)» всех форм обучения.

В данном учебном пособии изложены принципы построения реляционных баз данных.

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

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

В модуле 3 дается описание процесса реализации реляционной модели в среде СУБД MS Access, на множестве примеров рассматривается табличный язык запросов QBE.

В модуле 4 рассматривается стандартный язык запросов SQL.

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

Современные авторы часто употребляют термины «банк данных» и «база данных» как синонимы, однако в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г., эти понятия различаются.

Там приводятся следующие определения банка данных, базы данных и СУБД:

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

База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.

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

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

Преимущества использования БД Рассмотрим, какие преимущества получает пользователь при использовании БД как безбумажной технологии [1].

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

Рассмотрим подробнее преимущества, связанные с централизованным управлением:

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

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

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

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

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

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

Т.е. информация станет противоречивой.

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

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

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

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

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

• обеспечение целостности данных Задача целостности заключается в обеспечении правильности и точности данных в базе данных. Противоречие между двумя записями, представляющими один «факт», является примером недостатка целостности; конечно, эта проблема может возникнуть только при наличии избыточности в хранимых данных (см. пункт сокращение избыточности). Но даже если избыточность отсутствует, БД может содержать неправильную информацию. Например, год рождения сотрудника указан как 1999, тогда как сейчас 2004 год (возраст сотрудника – 5 лет?), или в домашнем адресе сотрудника указана несуществующая улица. Централизованное управление БД позволяет избежать подобных проблем – насколько их вообще можно избежать. Для этого определяются правила целостности, применяемые при каждой попытке обновления данных (т.е. операции обновления, вставки или удаления).

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

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

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

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

1. Проектирование 2. Реализация 3. Эксплуатация 4. Модернизация и развитие 5. Снятие с эксплуатации На каждом этапе своего существования с банком данных связаны разные категории пользователей. Определим основные категории пользователей и их роль в функционировании банка данных.

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

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

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

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

Рассмотрим их более подробно. В составе группы администратора БД должны быть:

• системные аналитики;

• проектировщики структур данных и внешнего по отношению к банку данных информационного обеспечения;

• проектировщики технологических процессов обработки данных;

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

• операторы и специалисты по техническому обслуживанию.

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

1.2.1. Основные функции группы администратора БД 1. Анализ предметной области: описание предметной области, выявление ограничений целостности, определение статуса (доступности, секретности) информации, определение потребностей пользователей, определение соответствия «данные—пользователь», определение объемно-временных характеристик обработки данных.

2. Проектирование структуры БД: определение состава и структуры файлов БД и связей между ними, выбор методов упорядочения данных и методов доступа к информации, описание БД на языке описания данных (ЯОД).

3. Задание ограничений целостности при описании структуры БД и процедур обработки БД:

• задание декларативных ограничений целостности, присущих предметной области;

• определение динамических ограничений целостности, присущих предметной области в процессе изменения информации, хранящейся в БД;

• определение ограничений целостности, вызванных структурой БД;

• разработка процедур обеспечения целостности БД при вводе и корректировке данных;

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

4. Первоначальная загрузка и ведение БД:

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

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

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

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

• разработка средств фиксации доступа к данным и попыток нарушения системы защиты;

• тестирование системы защиты;

• исследование случаев нарушения системы защиты и развитие динамических методов 6. Обеспечение восстановления БД:

• разработка организационных средств архивирования и принципов восстановления БД;

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

7. Анализ обращений пользователей БД: сбор статистики по характеру запросов, по времени их выполнения, по требуемым выходным документам 8. Анализ эффективности функционирования БД:

• анализ показателей функционирования БД;

• планирование реструктуризации (изменение структуры) БД и реорганизации БнД.

9. Работа с конечными пользователями:

• сбор информации об изменении предметной области;

• сбор информации об оценке работы БД;

• обучение пользователей, консультирование пользователей;

• разработка необходимой методической и учебной документации по работе конечных 10. Подготовка и поддержание системных средств:

• анализ существующих на рынке программных средств и анализ возможности и необходимости их использования в рамках БД;

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

11. Организационно-методическая работа по проектированию БД:

• выбор или создание методики проектирования БД;

• определение целей и направления развития системы в целом;

• планирование этапов развития БД;

• разработка общих словарей-справочников проекта БД и концептуальной модели;

• стыковка внешних моделей разрабатываемых приложений;

• курирование подключения нового приложения к действующей БД;

• обеспечение возможности комплексной отладки множества приложений, взаимодействующих с одной БД.

1.3.1. Трехуровневая архитектура баз данных Терминология в СУБД, да и сами термины «база данных» и «банк данных» частично заимствованы из финансовой деятельности. Это заимствование – не случайно и объясняется тем, что работа с информацией и работа с денежными массами во многом схожи, поскольку и там и там отсутствует персонификация объекта обработки: две банкноты достоинством в сто рублей столь же неотличимы и взаимозаменяемы, как два одинаковых байта (естественно, за исключением серийных номеров). Вы можете положить деньги на некоторый счет и предоставить возможность вашим родственникам или коллегам использовать их для иных целей. Вы можете поручить банку оплачивать ваши расходы с вашего счета или получить их наличными в другом банке, и это будут уже другие денежные купюры, но их ценность будет эквивалентна той, которую вы имели, когда клали их на ваш счет.

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на Рис. 1-1:

Рис. 1-1. Трехуровневая модель системы управления базой данных 1. Уровень внешних моделей – самый верхний уровень, где каждая модель имеет свое «видение»

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

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

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

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

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

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

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

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

1. Пользователь посылает СУБД запрос на получение данных из БД.

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

5. СУБД запрашивает информацию о местоположении данных на физическом уровне (файлы или физические адреса).

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

8. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в системный буфер.

9. Операционная система оповещает СУБД об окончании пересылки.

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

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

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

Разумеется, механизм прохождения запроса в реальных СУБД гораздо сложнее, но и эта упрощенная схема показывает, насколько серьезными и сложными должны быть механизмы обработки запросов, поддерживаемые реальными СУБД.

Одними из основополагающих в концепции баз данных являются обобщенные категории «данные» и «модель данных».

Понятие «данные» в концепции баз данных – это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы. Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Не существует однозначного определения этого термина, у разных авторов эта абстракция определяется с некоторыми различиями, но, тем не менее, можно выделить нечто общее в этих определениях.

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

На Рис. 1-3 представлена классификация моделей данных.

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

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

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

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

Фактографические модели данных соответствуют представлению информации в виде определенных структур данных (дерево, сеть, таблица).

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

Модели, основанные на языках разметки документов, связаны, прежде всего, со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах. Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки. С помощью SGML можно описывать структурированные данные, организовывать информацию, содержащуюся в документах, представлять эту информацию в некотором стандартизованном формате.

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

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

Однако HTML сегодня уже не удовлетворяет в полной мере требованиям, предъявляемым современными разработчиками к языкам подобного рода. И ему на смену был предложен новый язык гипертекстовой разметки, мощный, гибкий и, одновременно с этим, удобный язык XML. В чем же заключаются его достоинства?

XML (Extensible Markup Language) — это язык разметки, описывающий целый класс объектов данных, называемых XML-документами. Он используется в качестве средства для описания грамматики других языков и контроля за правильностью составления документов. То есть сам по себе XML не содержит никаких тегов, предназначенных для разметки, он просто определяет порядок их создания.

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

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

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

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

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

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ЕR-модели.

3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.

4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

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

В общем случае существуют два подхода к выбору состава и структуры предметной области:

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

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

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

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

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

Глава 2.1. Инфологическое (семантическое) моделирование предметной области Инфологическое моделирование (иногда используется термин семантическое моделирование) применяется на втором этапе проектирования БД, то есть после системного анализа предметной области. На этапе системного анализа были сформированы понятия о предметах, фактах и событиях, которыми будет оперировать БД. Инфологическое проектирование связано с представлением семантики предметной области в модели БД, т.е. моделирование структур данных, опираясь на смысл этих данных. Инфологическое моделирование было предметом исследований в конце 1970-х и начале 1980-х годов. Было предложено несколько моделей данных, названных семантическими моделями.

Наибольшее распространение получила модель "сущность-связь" (entity-relationship model, ERмодель), предложенная в 1976 г. Питером Пин-Шэн Ченом.

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

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

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

В этой главе мы рассмотрим основные понятия модели "сущность-связь":

• Ключевые атрибуты 4. степени связей 5. классы принадлежности сущностей в связях А также рассмотрим пример построения диаграммы "сущность-связь".

2.1.1. Модель «сущность-связь»

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

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

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

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

Примеры сущностей: люди, продукты, студенты и т.д.

Примеры экземпляров сущностей: конкретный человек, конкретный продукт, конкретный студент и т.д.

Сущности не обязательно должны быть непересекающимися. Например, экземпляр сущности СТУДЕНТ, также принадлежит сущности ЛЮДИ.

Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного объекта. Атрибут должен иметь имя, уникальное в пределах данной сущности.

Рассмотрим множество пищевых продуктов, имеющихся в магазине. Каждый продукт можно представить следующими характеристиками: Код продукта, Продукт,, Срок хранения, Условия хранения В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида Продукты(КодПродукта, Продукт, ЕдиницаИзмерения, СрокХранения, УсловияХранения) Например, поставщиков, поставляющих продукты в магазин, можно описать как Поставщики(КодПоставщика, Поставщик, Адрес) Множество допустимых значений (область определения) атрибута называется доменом.

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

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

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

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

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

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

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

Связь, существующая между двумя сущностями, называется бинарной связью.

Связь, существующая между n сущностями, называется n-арной связью.

Рекурсивная связь – это связь между экземплярами одной сущности.

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

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

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

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

• один-к-одному (обозначается 1:1). Это означает, что в такой связи в каждый момент времени каждому экземпляру сущности A соответствует 1 или 0 экземпляров сущности B.

Данный факт представлен на Рис. 2-1, где прямоугольники обозначают сущности, а ромб связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной • один-ко-многим (1:N). Одному экземпляру сущности A соответствуют 0, 1 или N экземпляров сущности B. Графически степень связи N отображается "древообразной" линией, так это сделано на следующем рисунке (Рис. 2-2).

• многие-к-одному (N:1). Эта связь аналогична отображению 1:N. Одному экземпляру сущности B соответствуют 0, 1 или N экземпляров сущности A (Рис. 2-3).

• многие-ко-многим (M:N). В этом случае одному экземпляру сущности A соответствуют 0, 1 или N экземпляров сущности B, и наоборот, одному экземпляру сущности B соответствуют 0, 1 или N экземпляров сущности A (Рис. 2-4).

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

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

1. Если рассматривать традиционный брак, то степень связи между сущностями Мужчина и Женщина будет 1:1. Кроме того, каждый мужчина, состоящий в браке, обязательно ДОЛЖЕН иметь жену. Таким образом, говорят, что сущность Женщина имеет обязательный класс принадлежности. И, наоборот, каждая женщина, состоящая в браке, ДОЛЖНА иметь мужа. То есть, сущность Мужчина также имеет обязательный класс принадлежности (2-5).

Рис. 2-5. Связь 1:1, обязательные классы принадлежности 2. Сотрудник руководит отделом (Рис. 2-6). Поскольку сотрудник может руководить только ОДНИМ отделом, а в отделе может быть только ОДИН руководитель, то степень связи в этом примере 1:1. Кроме того, в каждом отделе ДОЛЖЕН быть руководитель, т.е. каждому экземпляру сущности Отдел ДОЛЖЕН соответствовать экземпляр сущности Сотрудник (сущность Сотрудник имеет обязательный класс принадлежности). С другой стороны, далеко не все сотрудники должны быть руководителями, т.е. сотрудник МОЖЕТ (но не должен) быть руководителем. Таким образом, есть экземпляры сущности Сотрудник, которым не соответствует ни один экземпляр сущности Отдел (необязательный класс принадлежности).

Рис. 2-6. Связь 1:1, обязательный и необязательный классы принадлежности 3. Человек читает книгу (Рис. 2-7). Человек может читать сразу только ОДНУ книгу, а конкретная книга может быть читаема только ОДНИМ человеком, следовательно, степень связи 1:1. Человек МОЖЕТ читать книгу, а может ничего не читать. С другой стороны не каждая книга должна читаться, некоторые стоят на полке. Таким образом, обе сущности имеют необязательный класс принадлежности.

Рис. 2-7. Связь 1:1, необязательные классы принадлежности Рассмотрим примеры степени связи один-ко-многим (многие-к-одному):

4. В процессе обучения студенты объединены в группы. Каждая группа может содержать множество студентов, а каждый студент может входить только в одну группу, т.е. степень связи 1:N (Рис. 2-8). Каждая группа ДОЛЖНА содержать студентов, а каждый студент ДОЛЖЕН быть зачислен в конкретную группу, т.е. обе сущности имеют обязательные классы принадлежности Рис. 2-8. Связь 1:N, обязательные классы принадлежности 5. Поставщики продуктов имеют один юридический адрес, следовательно, ДОЛЖНЫ находиться в одном конкретном городе. А в одном городе МОГУТ находиться один, несколько или ни одного поставщика. Т.е. связь будет N:1, сущность Города будет иметь обязательный, а сущность Поставщики – необязательный классы принадлежности (Рис. 2-9).

Рис. 2-9. Связь N:1, обязательный и необязательный классы принадлежности Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной).

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

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

6. В магазине происходит продажа продуктов. Продукт не может быть продан, если его нет в магазине. Поэтому сущность Продажи является зависимой от сущности Продукты (Рис. 2-10).

Продукт МОЖЕТ быть продан в разные дни (а может быть вообще не продан), конкретная продажа связана только с одним продуктом. Таким образом, степень связи N:1, сущность Продажи имеет необязательный, а сущность Продукты - обязательный классы принадлежности (в самом деле, продажа без продукта теряет смысл) Рассмотрим пример степени связи многие-ко-многим:

7. Продукты в магазин поставляются поставщиками. Каждый продукт, имеющийся в магазине, ДОЛЖЕН быть поставлен одним или несколькими поставщиками, а каждый из поставщиков МОЖЕТ поставлять один или несколько продуктов или не поставлять ни одного. Т.е. степень связи M:N (Рис. 2-11), а класс принадлежности для Поставщиков – обязательный, для Продуктов – необязательный.

Рис. 2-11. Связь M:N, обязательный и необязательный классы принадлежности Между одними и теми же сущностями могут существовать несколько связей, например:

8. С одной стороны продукты в магазин поставляются заказчиками, с другой стороны, чтобы продукты были поставлены в магазин, необходимо заказать поставщикам необходимые продукты. Таким образом, между сущностями Продукты и Поставщики существуют связи «Поставляют» и «Заказаны» (Рис. 2-12). Связь «Поставляют» рассмотрена в предыдущем примере. Рассмотрим подробнее связь «Заказаны». Каждый продукт ДОЛЖЕН быть заказан одному или нескольким поставщикам, каждый поставщик МОЖЕТ получить заказ на один или несколько продуктов или вообще не получить заказ.

9. Рассмотрим сущности Врач и Пациент. Пациент ДОЖЕН иметь одного лечащего врача, а врач МОЖЕТ лечить несколько пациентов. Кроме того, пациент МОЖЕТ иметь нескольких врачейконсультантов, а врач МОЖЕТ консультировать нескольких пациентов (Рис.2-13).

2.1.2. Пример построения модели «сущность-связь»

В процессе построения диаграммы "сущность-связь" можно выделить несколько этапов:

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

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

1. Продукты Для этой сущности необходимы следующие атрибуты:

• Код продукта – уникальный идентификатор, ключевой атрибут • Продукт – название продукта • Единица измерения – литры, килограммы, штуки и т.п.

• Срок хранения в днях – для определения даты окончания срока годности продукта • Условия хранения – температура, влажность и т.п.

2. Поставщики • Код поставщика – уникальный идентификатор, ключевой атрибут • Поставщик – название организации или ФИО физического лица • Код города – выделим отдельно город, где находится поставщик, для удобства дальнейшей работы (например, для поиска) • Адрес – поскольку город выделен в отдельный атрибут, то в адресе остается улица и дом (а также квартира – для физического лица) 3. Продажи • Код продукта – какой именно продукт был продан • Количество – сколько продано этого продукта в тех единицах измерения, которые указаны для этого продукта в сущности Продукт • Цена продажи – цена при продаже за единицу продукта 4. Города – поскольку мы выделили отдельно город из адреса поставщика, то возникает необходимость в этой сущности Код города – уникальный идентификатор, ключевой атрибут Сократив для удобства названия атрибутов, получим список сущностей:

• Продукты(КодПрод, Продукт, ЕдИзм, СрокХран(дней), УсловияХран) • Поставщики(КодПост, Поставщик, КодГорода, Адрес, ФИОдиректора, Телефон, Факс) обратите внимание, что в этой сущности ключ составной, поскольку каждый день продается множество продуктов, и конкретный продукт может быть продан в разные дни • Города(КодГорода, Город) Рассмотрим связи, существующие между описанными выше сущностями:

1. Продукты в магазин поставляются поставщиками, т.е. существует связь M:N «Поставляют»

между сущностями Продукты и Поставщики (подробно эта связь рассмотрена в примере параграфа 2.1.1., Рис. 2-11). Эта связь имеет следующие атрибуты:

• Дата поставки • Код поставщика – какой поставщик поставил этот продукт • Код продукта – какой именно продукт был поставлен • КоличествоП – сколько поставлено этого продукта в тех единицах измерения, которые указаны для этого продукта в сущности Продукт • Цена поставки – цена при поставке за единицу продукта • Дата изготовления – дата изготовления продукта Ключом будет составной атрибут: Дата поставки, Код поставщика, Код продукта (объясните, почему именно эти атрибуты вошли в составной ключ) 2. Продукты должны быть заказаны поставщикам, т.е. существует связь M:N «Заказаны»

между сущностями Продукты и Поставщики (подробно эта связь рассмотрена в примере параграфа 2.1.1, Рис. 2-12). Эта связь имеет следующие атрибуты:

• Код поставщика – какому поставщику заказан этот продукт • Код продукта – какой именно продукт был заказан • КоличествоЗ – сколько поставлено этого продукта в тех единицах измерения, которые указаны для этого продукта в сущности Продукт Ключом будет составной атрибут: Дата заказа, Код поставщика, Код продукта (объясните, почему именно эти атрибуты вошли в составной ключ) 3. В магазине происходит продажа продуктов, т.е. существует связь N:1 «Происходит» между сущностями Продажи и Продукты (подробно эта связь рассмотрена в примере 6 параграфа 2.1.1, Рис. 2-10) 4. Поставщики находятся в определенном городе, т.е. существует связь N:1 «Находятся»

между сущностями Поставщики и Города (подробно эта связь рассмотрена в примере параграфа 2.1.1., Рис. 2-9) После объединения всех фрагментов в общую модель и добавления атрибутов, получится диаграмма "сущность-связь", приведенная на Рис. 2-14.

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

• Первую часть реляционной модели – объекты (структура) • Вторую часть реляционной модели – целостность • структурная целостность • языковая целостность • ссылочная целостность • Третью часть реляционной модели – операторы реляционной алгебры • теоретико-множественные операции • специальные операции реляционной алгебры • свойство замкнутости • свойства ассоциативности и коммутативности • примитивные операции • примеры использования реляционных операций 2.2.1. Реляционные объекты данных Основные понятия и ограничения реляционной модели (от английского relation – отношение) впервые были сформулированы сотрудником компании IBM Е.Ф.Коддом в 1970 г.

Реляционная модель связана с тремя аспектами данных: объектами данных (структурой данных), целостностью данных и обработкой данных [1, 2].

Основной структурной частью (объектом) реляционной модели является отношение.

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

Декартово произведение Для заданных конечных множеств D1, D2,…,Dn (не обязательно различных) декартовым произведением D1 D2… Dn называется множество произведений вида: d d2… dn, где d1D1, d2D2,…, dnDn.

Пример: Имеем три домена D1={a,b,c}, D2={m,k}, D3={y,z}.

Декартово произведение этих доменов Отношением R, определенным на множествах D1, D2,…,Dn (n 1), необязательно различных, называется подмножество декартова произведения D1 D2… Dn.

Исходные множества D1, D2,…,Dn называются доменами отношения Элементы декартова произведения d1 d2… dn называются кортежами Число n определяет степень отношения ( n=1 - унарное, n=2 - бинарное,..., n-арное) Количество кортежей называется кардинальным числом или мощностью отношения Домен представляет собой именованное множество атомарных значений одного типа. Под атомарным значением понимается “наименьшая семантическая единица данных”, т.е. это значение, не имеющее внутренней структуры при рассмотрении в реляционной модели. Это не значит, что такое значение не имеет внутренней структуры вообще. Например, название должности состоит из букв, но, разложив название по буквам, мы потеряем значение.

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

Значение доменов заключается в том, что домены ограничивают сравнения. Т.е. если два атрибута определены на одном и том домене, то их можно сравнивать, применяя операции сравнения допустимые для данного домена. Например, атрибуты Дата приема на работу и Дата окончания ВУЗа определены на одном домене Даты; для этого домена допустимы операции сравнения: =,,,. Поэтому данные атрибуты можно сравнивать, используя все указанные операции сравнения.

Отношение удобно представить в виде таблицы, столбцы которой соответствуют вхождениям доменов в отношение, а строки – наборам из n значений, взятых их исходных доменов, и расположенным в соответствии с заголовком отношения (Рис. 2-15). Столбцы отношения называют атрибутами, а строки – кортежами. Однако нельзя сказать, что отношение и таблица полностью идентичны. Различие между отношением и таблицей мы рассмотрим чуть позже, когда будем рассматривать свойства отношений.

Отношение содержит две части: заголовок и тело (заголовок – это строка заголовков столбцов, тело – это множество строк данных).

Заголовок (или схема отношения) содержит фиксированное множество атрибутов или, точнее, пар :

причем каждый атрибут Aj соответствует только одному из лежащих в основе доменов Dj (j = 1, 2, …, n). Все имена атрибутов A1, A2, …, An разные.

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

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

Тело содержит множество кортежей.

(i = 1, 2, …, m, где m – количество кортежей в этом множестве). В каждом таком кортеже есть одна такая пара, т.е., для каждого атрибута Aj в заголовке. Для любой такой пары vij является значением из уникального домена Dj, связанного с атрибутом Aj.

Т.е. можно сказать, что отношение – это множество кортежей, соответствующих одной схеме отношения.

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

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

Пример: Для иллюстрации введенных терминов рассмотрим отношение Расписание, приведенное на Рис. 2-15. В этом отношении есть четыре основных домена: домен номеров рейса (№ рейса), домен наименований населенных пунктов (Населенные пункты), домен времени (Время) и домен типов поездов (Тип поезда).

Обратите внимание, что количество доменов меньше количества атрибутов, т.е. некоторые атрибуты определены на одном и том же домене. Так атрибуты Пункт отправления и Пункт назначения определены на домене Населенные пункты, а атрибуты Время отправления и Время прибытия – на домене Время. Т.е. атрибуты Пункты отправления и Пункт назначения (и соответственно Время отправления и Время прибытия) можно сравнивать. Например, для определения транзитных рейсов, которыми можно добраться из Владивостока в Хасан, необходимо сравнить пункт назначения с пунктом отправления, а также время прибытия одного рейса с временем отправления другого (чтобы узнать есть ли запас времени для пересадки на транзитный рейс).

Схема отношения (заголовок отношения) выглядит как (№ рейса, Пункт отправления, Пункт назначения, Время отправления, Время прибытия, Тип поезда) или по определению схема представляет собой набор упорядоченных пар:

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

Тело отношения представляет собой набор строк (кортежей). Рассмотрим подробнее один из кортежей:

(681, Владивосток, Новочугуевка, 22:05, 9:30, ПАСС) по определению этот кортеж представляет собой набор упорядоченных пар:

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

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

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

Свойства отношений Рассмотрим теперь свойства отношений, которые следуют из приведенного выше определения отношения. В любом отношении • Отсутствуют одинаковые кортежи • Отсутствует упорядоченность кортежей • Отсутствует упорядоченность атрибутов • Все значения атрибутов атомарные Отсутствие одинаковых кортежей Это свойство следует из определения отношения как множества кортежей, а множества в математике по определению не содержат одинаковых элементов.

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

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

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

Отсутствие упорядоченности кортежей Свойство отсутствия упорядоченности кортежей (сверху вниз) также следует из того, что тело отношения – это математическое множество, а простые множества в математике не упорядочены.

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

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

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

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

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

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

Примером ненормализованного отношения является отношение R1 на Рис.2-16. Чтобы можно было использовать отношение в реляционной БД, его необходимо привести в виду отношения R2 (Рис. 2Процесс получения отношения R2 из R1 называется нормализацией (подробнее процесс нормализации описан в Главе?).

Это свойство также иллюстрирует отличие таблицы от отношения. Строго говоря, на Рис. 2только R2 является отношением, а таблицей можно назвать как R1, так и R2.

2.2.2. Ограничения целостности в реляционной модели данных Вторым аспектом реляционной модели данных является поддержка целостности.

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

В классическом понимании поддержка целостности включает 3 части:

• Структурная целостность • Языковая целостность • Ссылочная целостность Эти 3 вида целостности определяют допустимую форму представления и обработки информации в реляционных БД.

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

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

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

• при добавлении кортежей в отношение проверяется уникальность их первичных ключей • не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение Здесь возникает необходимость рассмотреть проблему неопределенных значений (Nullзначений) [1, 2]. Неопределенное значение интерпретируется в реляционной модели как значение, неизвестное на данный момент времени. При сравнении неопределенных значений не действуют стандартные правила сравнения: одно Null-значение никогда не считается равным другому Nullзначению.

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

Таблица 2-2 содержит пример проверки атрибута Адрес на неопределенное значение.

Введение Null-значений привело к модификации классической двузначной логики к трехзначной. Таблица 2- содержит таблицу истинности для трехзначной логики.

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

Ссылочная целостность При установлении связи между отношениями возникает необходимость поддержания целостности по ссылкам. Отношение со стороны «один» будем называть – основным отношением, а отношение со стороны «многие» – подчиненным.

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

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

То есть значение внешнего ключа должно либо:

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

Для каждого внешнего ключа в процессе проектирования необходимо решить три вопроса:

1. Может ли данный внешний ключ принимать неопределенные значения 2. Что произойдет при попытке УДАЛЕНИЯ записи из основного отношения, на которую ссылается внешний ключ подчиненного отношения?

Например, удалить поставщика, для которого имеется, по крайней мере, одна поставка.

В общем случае существует три ситуации:

• Каскадирование удаления, при котором удаляются все записи из подчиненного отношения, соответствующие удаляемому первичному ключу основного отношения (будет удален поставщик и все его поставки) • Ограничение удаления, при котором удаляется запись из основного отношения только в том случае, если в подчиненном отношении нет соответствующих значений внешнего ключа, иначе удаление отменяется (удаление поставщика невозможно, пока существует хотя бы • Установка неопределенных значений, при которой внешний ключ подчиненного отношения устанавливается в неопределенное значение (Null-значание), а соответствующая запись из основного отношения удаляется (все значения внешнего ключа в поставках принимают Данное свойство поддерживается не всеми СУБД. Если необходимо применить эту ситуацию, то в подчиненном отношении сначала нужно удалить все значения внешнего ключа соответствующие первичному, и только после этого удалять запись из основного отношения с соответствующим первичным ключом 3. Что произойдет при попытке ОБНОВЛЕНИЯ первичного ключа основного отношения, на который ссылается некоторый внешний ключ подчиненного отношения? Например, при попытке обновления кода поставщика, для которого имеется хотя бы одна поставка.

Здесь также возможны три ситуации:

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

• уникальность значений полей. Например, в отношении Студент(№ зачетной книжки, ФИО, Паспорт, Адрес) свойство уникальности значений должно быть установлено для атрибутов:

№ зачетной книжки (т.к. это первичный ключ) и Паспорт (т.к. номера всех паспортов • обязательность заполнения полей (допустимость или недопустимость Null-значений).

Например, при вводе данных о поставщиках не вся информация может быть доступна сразу: адрес, телефоны для связи могут быть уточнены позднее. Т.е. для атрибутов Код города, Адрес, Телефон устанавливается допустимость Null-значений • значение по умолчанию. Задание значения по умолчанию по умолчания означает, что каждый раз при вводе новой строки в отношение, при отсутствии данных этому атрибуту присваивается значение по умолчанию.Например, если большинство поставщиков находятся во Владивостоке, то для атрибута Код города присваивается значение по умолчанию соответствующее коду Владивостока • диапазон значений Например, оценки выставляются по пяти бальной шкале от 1 до 5, тогда условие для этого диапазона (для MS Access) будет выглядеть как: Between 1 And • принадлежность набору значений Например, атрибут РезультатЗачета может принимать значения только «Зачтено» или «Не зачтено», тогда условие на проверку принадлежности набору значений (для MS Access) будет выглядеть как: “Зачтено” Or “Не зачтено”.

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

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

К традиционным операциям относятся операции:

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

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

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

Совместимость по типу Операции объединения, пересечения и вычитания требуют от операндов совместимости по типу. Будет говорить, что два отношения совместимы по типу, если у них эквивалентные схемы, а точнее:

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

Рис. 2-17. База данных продуктов и поставщиков (значения для примера) Теоретико-множественные операции реляционной алгебры Объединением двух совместимых по типу отношений А и В называется отношение с тем же заголовком, как в исходных отношениях, и с телом, состоящим из множества всех кортежей, принадлежащих А или В или обоим отношением (за исключением повторяющихся).

Продукты1 (содержащее продукты, имеющиеся в магазине) и Продукты (содержащее продукты, поставляемые поставщиком P2). Результатом объединения станет отношение R1 (Рис. 0-18), содержащее продукты, которые или имеются в магазине или поставляются поставщиком P2 (либо и то и другое).

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

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

Пример: Пересечением отношений Продукты1 и Продукты2 (Рис. 2станет отношение R2 (Рис. 2-19), содержащее продукты, имеющиеся в магазине и поставляемые поставщиком P2.

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

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

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

Пример: При вычитании отношения Продукты2 из отношения Продукты1 (Рис. 2-17) получится отношение R3 (Рис. 2-20), содержащее продукты, имеющиеся в магазине, кроме тех продуктов, которые поставляет поставщик P2.

При вычитании отношения Продукты1 из отношения Продукты2 получится другое отношение R4 (поскольку операция вычитания не коммутативная). Отношение R4 (Рис. 2-20) будет содержать продукты, поставляемые поставщиком P2, кроме тех продуктов, которые имеются в магазине.

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

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

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

здесь n – число элементов в первом кортеже c, m – число элементов во втором кортеже q.

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

Расширенное декартово произведение двух отношений А и В, где А и В не имеют общих атрибутов, определяется как отношение с заголовком, который представляет собой сцепление двух заголовков исходных отношений А и В, и телом, состоящим из множества всех кортежей c, таких, что c представляет собой сцепление кортежа a, принадлежащего отношению A, и кортежа b, результата равно произведению кардинальных чисел исходных отношений А и В, а степень равна сумме их степеней.

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

Пример: Декартовым произведением отношений Поставщики и ВидПродукта (Рис. 2-17) будет отношение R5 (Рис. 2-21). Отношение R5 соответствует ситуации, когда все поставщики поставляют все виды продуктов.

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

Все теоретико-множественные операции являются ассоциативными операциями, т.е.

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

Пусть – булевское выражение, составленное из термов сравнения с помощью связок И (), ИЛИ (), НЕ (-) и, возможно, скобок. В качестве термов сравнения допускаются:

где А – имя некоторого атрибута, принимающего значения из домена D; а – константа, взятая из того же домена D, а D; – одна из допустимых для данного домена D операций сравнения (=,, где А, В – имена некоторых -сравнимых атрибутов, то есть атрибутов, принимающих значение из одного и того же домена D.

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

• Результатом выборки продуктов, поставляемых поставщиком P3, из отношения Продукты (Рис. 2-17) будет отношение R6 (Рис. 2-22, a) • Результатом выборки Владивостокских поставщиков из отношения Поставщики (Рис. 2-17) будет отношение R7 (Рис. 2-22, b) Проекцией отношения A по атрибутам X, Y, …, Z, где каждый из атрибутов принадлежит отношению A(A[X, Y, …, Z]), называется отношение с заголовком {X, Y, …, Z} и телом, содержащим множество всех кортежей {X:x, Y:y, …, Z:z}, таких, для которых в отношении A значение атрибута X равно x, атрибута Y равно y, …, атрибута Z равно z. Таким образом, с помощью оператора проекции получено «вертикальное» подмножество данного отношения, т.е. подмножество, получаемое исключением всех атрибутов, не указанных в списке атрибутов, и последующим исключением дублирующих кортежей (подкортежей) из того, что осталось.

• Проекцией отношения Продукты1 (Рис. 2-17) по атрибуту КодПоставщика будет отношение R8 (Рис. 2-23, a). Обратите внимание, что дублирующие кортежи исключены из • Проекцией отношения Поставщики (Рис. 2-17) по атрибуту Город будет отношение R9 (Рис.

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

Например, нужно выбрать названия поставщиков из Владивостока (на основе отношения Поставщики – Рис. 2-17). Сначала выполняется операция выборки, а затем – проекции Соединение (естественное, условное) Операция соединения имеет несколько разновидностей. Однако наиболее важным является естественное соединение, поэтому часто для обозначения именно естественного соединения используют общий термин «соединение».

Пусть отношения A и B имеют заголовки:

{X1, X2,…, Xm, Y1, Y2,…, Yn} { Y1, Y2,…, Yn, Z1, Z2,…, Zp} соответственно;

т.е. атрибуты Y1, Y2,…, Yn (и только они) – общие для двух отношений;

X1, X2,…, Xm – остальные атрибуты отношения A; Z1, Z2,…, Zp – остальные атрибуты отношения B. Предположим также, что соответствующие атрибуты (т.е. атрибуты с одинаковыми именами) определены на одном и том же домене. Будем рассматривать выражения {X1, X2,…, Xm}, {Y1, Y2,…, Yn}, {Z1, Z2,…, Zp} как три составных атрибута X, Y, Z соответственно.

Тогда естественным соединением отношений A и B называется отношение с заголовком {X, Естественное соединение обладает свойствами коммутативности и ассоциативности.

Отметим также, что если отношения A и B не имеют общих атрибутов, то естественное соединение превращается в декартово произведение.

Пример: Рассмотрим отношения Продукты1 и Поставщики (Рис. 2-17). Атрибуты КодПоставщика и КодП определены на одном и том же домене кодов поставщиков. Поскольку при естественном соединении также требуется, чтобы общие атрибуты соединяемых отношений имели одинаковые имена, переименуем атрибут КодП отношения Поставщики в КодПоставщика. Тогда естественным соединением отношений Продукты1 и Поставщики по атрибуту КодПоставщика будет отношение R11 (Рис. 2-24).

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

Пусть отношения A и B не имеют общих имен атрибутов, и определяется как в операции выборки. Тогда условным соединением отношения A по атрибуту X с отношением B по атрибуту Y называется отношение с заголовком, который представляет собой сцепление двух заголовков исходных отношений А и В (как и при операции декартова произведения), и с телом, содержащим множество кортежей t, таких что t принадлежит этому декартову произведению и вычисление условия “X Y” дает значение «истина» для этого кортежа. Атрибуты X и Y должны быть определены на одном и том же домене, а операция должна иметь смысл для этого домена.

Пример: Получить названия продуктов (отношение Продукты1 – Рис. 2-17), поставляемых поставщиками из Владивостока (отношение Поставщики – Рис. 2-17). По сути, в этом примере необходимо использовать две операции: условного соединения – для получения непосредственно списка продуктов, поставляемых Владивостокскими поставщиками (R12); и проекции – для получения только названий продуктов (R13) (Рис. 2-25).

Пусть отношения A и B имеют заголовки:

{X1, X2,…, Xm, Y1, Y2,…, Yn} { Y1, Y2,…, Yn } соответственно;

т.е. атрибуты Y1, Y2,…, Yn – общие для двух отношений, и отношение A имеет дополнительные атрибуты X1, X2,…, Xm, а отношение B не имеет дополнительных атрибутов. (Отношения A и B представляют соответственно делимое и делитель). Предположим также, что соответствующие атрибуты (т.е. атрибуты с одинаковыми именами) определены на одном и том же домене. Пусть выражения {X1, X2,…, Xm}и {Y1, Y2,…, Yn}обозначают два составных атрибута X и Y соответственно.

Пример: Пусть отношение R14 содержит поставщиков и виды поставляемых ими продуктов, а отношение ВидПродукта содержит виды продуктов (Рис. 2-26). Тогда, чтобы получить поставщиков поставляющих ВСЕ виды продуктов, необходимо отношение R14 разделить на отношение ВидПродукта по атрибуту КодВида (Рис. 2-26).

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

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

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

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

I. Пусть даны три отношения с эквивалентными схемами: (ФИО, Должность, Отдел).

Отношение R1 содержит список сотрудников предприятия, работающих над проектом P1, R2 – список сотрудников, работающих над проектом P2, R3 – список сотрудников, живущих во Владивостоке. Сотрудники могут работать над несколькими проектами.

Составить формулы для следующих запросов:

1. Список сотрудников, живущих не во Владивостоке, т.е. это такие сотрудники, которые могут содержаться в отношении R1 или R2 или обоих отношениях, но не входят в отношение R этот пример показывает, что один и тот запрос можно сформулировать несколькими способами 2. Список сотрудников, работающих над двумя проектами и живущих во Владивостоке, т.е. это (R1R2) \ (R1R2) 4. Список сотрудников, работающих только над одним из проектов, и живущих во Владивостоке (R1R2) \ (R1R2) R3 или (R1R3)(R2R3) \ (R1R2) II. Даны следующие отношения:

R1(Таб№, ФИО, Должность, Отдел) – список сотрудников по отделам R2(Должность, Оклад) – должностные оклады R3(Должность, Отдел) – штатные должности по отделам, т.е. какие должности должны быть в каждом отделе.

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

Составить формулы для следующих запросов:

(R1[Отдел = “Бухгалтерия”]) [Таб№, ФИО] (R1[R1.Должность = R2.Должность R2.Оклад > 3000]R2) [ФИО] R3 \ (R1[Должность, Оклад]) R3 \ R3[Должность = “Мастер”] (R1[R1.ФИО = R1’.ФИО R1.Должность R1’.Должность]R1’)[ФИО] Обратите внимание, что для поиска строк, удовлетворяющих условию больше одного, применяется операция соединения отношения с самим собой. Поэтому мы взяли копию отношения R1 и назвали ее R1’.

R4 = (R1[R1.ФИО = R1’.ФИО R1.Должность R1’.Должность]R1’)[ФИО] (R1[ФИО]) \ R 7. Отделы, имеющие в штате, по крайней мере, все те должности, что и в отделе “Цех 1” R3[Должность Должность]R 2.2.4. Алгоритм перехода от модели «сущность-связь» к реляционной модели Модель «сущность-связь» используется на ранних стадиях проектирования БД. Как уже говорилось модель «сущность-связь» является концептуальной моделью и не учитывает особенности конкретной СУБД (допустимые типы и наименования полей и таблиц, ограничения целостности и т.п.). Существует алгоритм однозначного преобразования модели «сущность-связь» в реляционную модель данных (т.е. осуществляется переход от инфологического моделирования к логическому проектированию схемы реляционной БД). Рассмотрим этот алгоритм.

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

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

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



Pages:     || 2 |


Похожие работы:

«БАЛТИЙСКАЯ МЕЖДУНАРОДНАЯ АКАДЕМИЯ ПРОФЕССИОНАЛЬНАЯ БАКАЛАВРСКАЯ ПРОГРАММА Управление культурой БАКАЛАВРСКАЯ РАБОТА Культура скандинавских саамов: Этнологический портрет Студент: Еременко Антон_RI4A1361 (нм. уч. договора, подпись, дата) Специальность: Межкультурные взаимоотношения (Латвия – Швеция) Научныйруководитель: О.Одегова (учёная.степень, звание),(подпись, дата) Рига 2009 BALTIJAS STARPTAUTISK AKADMIJA PROFESIONL BAKALAURA PROGRAMMA Kultras vadba BAKALAURA DARBS Skandinvijas smu kultra:...»

«ПРОГРАММА ВСТУПИТЕЛЬНОГО ЭКЗАМЕНА ПО НАУЧНОЙ СПЕЦИАЛЬНОСТИ 05.26.02 БЕЗОПАСНОСТЬ В ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЯХ (ТЕХНИЧЕСКИЕ НАУКИ) ВВЕДЕНИЕ Современный научно-технический прогресс и расширение производственной деятельности человека с использованием энергоемких систем, взрывоопасных и ядовитых веществ, усложнение технологических процессов производства увеличили риск возникновения аварий и катастроф, пожаров, радиоактивных и химических заражений местности и других опасностей. Риск возникновения...»

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

«ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ ВОЛОГОДСКОЙ ОБЛАСТИ УТВЕРЖДАЮ Директор БОУ СПО ВО Вологодский политехнический техникум _ /М.В.Кирбитов/ _20_г. ПРОГРАММА ПРОФЕССИОНАЛЬНОГО МОДУЛЯ Выполнение работ по профессии Слесарь по ремонту автомобилей Вологда 2011 г. 1 Программа профессионального модуля разработана на основе Федерального государственного образовательного стандарта по специальности среднего профессионального образования (далее – СПО) 190631 Техническое обслуживание и ремонт автомобильного транспорта...»

«Приложение 8Б: Рабочая программа факультативной дисциплины Формирование развития управленческих команд как субъектная управленческая деятельность ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ПЯТИГОРСКИЙ ГОСУДАРСТВЕННЫЙ ЛИНГВИСТИЧЕСКИЙ УНИВЕРСИТЕТ Утверждаю _ проректор по научной работе и развитию интеллектуального потенциала университета профессор З.А. Заврумов _2012 г. Аспирантура по специальности 22.00.08 Социология управления отрасль...»

«МИНИСТЕРСТВО ТРАНСПОРТА РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное агентство морского и речного транспорта Утверждаю: Руководитель Федерального агентства морского и речного транспорта А.А. Давыденко 2012 г. ПРИМЕРНАЯ ПРОГРАММА Подготовка лица, имеющего военно-морское образование, при длительном перерыве в работе по специальности (судоводитель) (Раздел A-I/11 пункт 2 Кодекса ПДНВ) Москва 2012 2 Учебный план программы Подготовка лица, имеющего военно-морское образование, при длительном перерыве в работе по...»

«УТВЕРЖДАЮ Директор МАОУ Лицей № 15 _ Т.Н. Гонтарева _ 2013г. Сведения о программно-методическом обеспечении учебного плана на 2013- 2014 учебный год I ступень обучения Учебные предметы УМК Классы * неделю часов в Кол-во Название, автор, Используемые элементы УМК Автор Год издания 1а, 1б Уроки обучения Букварь, Бунеев Р.Н., Обучение грамоте Школа грамоте, Бунеев Р.Н., Бунеева Е.В., 2100 Бунеева Е.В., Пронина Пронина О.В. О.В. Прописи Мои волшебные Пронина О.В. пальчики Тетрадь для печатания...»

«Пояснительная записка Рабочая программа учебного предмета география составлена в соответствии с требованиями федерального компонента государственного стандарта общего образования по географии 2004г. и примерной программы для основного общего образования по географии 2004г. В соответствии с требованиями нового базисного учебного плана, по которому на изучение географии в 6 классе отводится 1 час, данная программа содержит все темы, включенные в федеральный компонент содержания образования....»

«Министерство охраны природы Туркменистана Национальный институт пустынь, растительного и животного мира ДОКЛАД по осуществлению Национальной программы действий по борьбе с опустыниванием в Туркменистане Ашхабад — 2000 г. СОДЕРЖАНИЕ ВВЕДЕНИЕ 3 1. СРЕДООБРАЗУЮЩИЕ КОМПОНЕНТЫ ПРИРОДЫ 5 1.1. Географическое положение 5 1.2. Климатические особенности 6 1.3. Поверхностные и подземные воды 8 1.4. Почвы 1.5. Ископаемые богатства 1.6. Состояние биоразнообразия 2. ОПУСТЫНИВАНИЕ И ОСУЩЕСТВЛЕНИЕ НПДБО В...»

«УТВЕРЖДАЮ Директор школы Н.Г.Акимова Приказ №165 _02сентября 2013г МУНИЦИПАЛЬНОЕ БЮДЖЕТНОЕ ОБЩЕОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ СРЕДНЯЯ ОБЩЕОБРАЗОВАТЕЛЬНАЯ ШКОЛА № 25 УЧЕБНО-МЕТОДИЧЕСКОЕ ОБЕСПЕЧЕНИЕ СОДЕРЖАНИЯ ОБРАЗОВАНИЯ НА 2013/2014УЧЕБНЫЙ ГОД. 5 класс (ФГОС) Учебные предметы Программы Учебно-методическое обеспечение Кол-во Кол-во перечня часов по часов по Номер Класс учебному программ плану е Русский язык Рыбченкова Л. М., Александрова О. М. Л.М.Рыбченкова, О.М. 664 5а 5 Русский язык. Рабочие...»

«ПОЛОЖЕНИЕ о международной ярмарке бизнес-идей приграничья, направленной на решение первоочередных задач по развитию инвестиционного климата приграничных территорий Российской Федерации, Украины и Республики Беларусь ПОЛОЖЕНИЕ о международной ярмарке бизнес-идей приграничья, направленной на решение первоочередных задач по развитию инвестиционного климата приграничных территорий Российской Федерации, Украины и Республики Беларусь 1. Общие положения 1.1. Международная ярмарка бизнес-идей...»

«ГОСУДАРСТВЕННАЯ ИНСПЕКЦИЯ РЕСПУБЛИКИ УЗБЕКИСТАН ПО НАДЗОРУ ЗА БЕЗОПАСНОСТЬЮ ПОЛЕТОВ ПРОГРАММА НАДЗОРА И ИНСПЕКЦИОННЫХ ПРОВЕРОК ЦЕНТРА УЗАЭРОНАВИГАЦИЯ ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ ПОЛЕТОВ ПРИ ОВД г. Ташкент-2008г 2 УТВЕРЖДЕНО приказом начальника Государственной инспекции Республики Узбекистан по надзору за безопасностью полетов № 34 от 25 02 2008г. ПРОГРАММА НАДЗОРА И ИНСПЕКЦИОННЫХ ПРОВЕРОК ЦЕНТРА УЗАЭРОНАВИГАЦИЯ ПО ОБЕСПЕЧЕНИЮ БЕЗОПАСНОСТИ ПОЛЕТОВ ПРИ...»

«Минобрнауки России Филиал федерального государственного бюджетного образовательного учреждения высшего профессионального образования Вятский государственный гуманитарный университет в г. Кирово-Чепецке Кафедра экономики и управления УТВЕРЖДАЮ зав. кафедрой Агалакова О.С. Подпись 12.09.2012 УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС учебной дисциплины Делопроизводство в кадровой службе для специальностей: 080505.65 Управление персоналом Кирово-Чепецк Учебно-методический комплекс составлен в соответствии с ГОС...»

«Государственное образовательное учреждение высшего профессионального образования Липецкий государственный технический университет Кафедра культуры “УТВЕРЖДАЮ” Декан факультета инженеров транспорта _ Ляпин С.А. 200_ РАБОЧАЯ ПРОГРАММА ДИСЦИПЛИНЫ ДЕЛОВОЕ ОБЩЕНИЕ В ПРОФЕССИОНАЛЬНО ОРИЕНТИРОВАННОЙ СРЕДЕ Направление подготовки: 190600 Эксплуатация транспортно-технологических машин и комплексов Профиль подготовки: Автомобильный сервис Квалификация (степень) выпускника: бакалавр Форма обучения: очная...»

«Аннотация к рабочей программе по математике (5 – 6 классы) 1. Рабочая программа по математике для 5 и 6 классов составлена - на основе федерального компонента Государственного стандарта основного общего образования с учетом Примерных программ по учебным предметам (Математика. 5-9 классы: проект (М: Просвещение, 2010)), подготовленных в рамках проекта Разработка, апробация и внедрение федеральных государственных стандартов общего образования второго поколения, реализуемого Российской академией...»

«1. Пояснительная записка Рабочая программа по истории составлена на основе Примерной программы, разработанной Министерством образования, программы по истории России Данилова А.А. и Косулиной Л.Г. и прогрпммы по Всеобщей истории Годера Г.И. и Свенцицкой И.С., Агибаловой Е.В., Юдовской А.Я., Сороко-Цюпы О.С. Данная программа конкретизирует содержание предметных тем образовательного стандарта, дает примерное распределение учебных часов по разделам курса и рекомендуемую последовательность изучения...»

«Санкт-Петербург 2007/2008 Факультет инноватики Слушатели Президентской программы подготовки управленческих кадров для организаций народного хозяйства Российской Федерации 2007-2008 учебного года НАПРАВЛЕНИЕ: Руководители инновационных проектов, тип А © ФИ СПбГПУ 2007 1 Санкт-Петербург 2007/2008 Факультет инноватики НАПРАВЛЕНИЕ – РУКОВОДИТЕЛИ ИННОВАЦИОННЫХ ПРОЕКТОВ, ТИП А Батенко Владимир Игоревич Страна/Регион: Россия Город/Область: Санкт-Петербург Контактный телефон: (812)715-16- Адрес...»

«Министерство образования Республики Коми государственное автономное образовательное учреждение среднего профессионального образования Республики Коми Печорский промышленно-экономический техникум (ГАОУСПО РК ППЭТ) ПУБЛИЧНЫЙ ДОКЛАД о состоянии и развитии учреждения среднего профессионального образования в 2012-2013 году Печора 2013 Публичный доклад 2012-2013 уч. год ГАОУСПО РК ППЭТ Министерство образования Республики Коми Государственное автономное образовательное учреждение среднего...»

«Министерство сельского хозяйства Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Кубанский государственный аграрный университет РАБОЧАЯ ПРОГРАММА по дисциплине Б2.В.ДВ.2 Возрастная физиология (индекс и наименование дисциплины) Специальность 111900.65 Ветеринарно-санитарная экспертиза Квалификация (степень) выпускника бакалавр Факультет Ветеринарной медицины Кафедра-разработчик Кафедра физиологии и кормления с.х....»

«МИНИСТЕРСТВО КУЛЬТУРЫ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ КИНО И ТЕЛЕВИДЕНИЯ УТВЕРЖДАЮ Проректор по учебной работе В.Я. Герасимов 2012 г. РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ РАБОТА НАД ЗВУКОВОЙ ПАРТИТУРОЙ ТЕЛЕВИЗИОННЫХ ПРОГРАММ Специальность/направление - 071104 Звукорежиссура кино и телевидения Квалификация/степень выпускника – звукорежиссер Форма обучения – очная,...»






 
2014 www.av.disus.ru - «Бесплатная электронная библиотека - Авторефераты, Диссертации, Монографии, Программы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.