Управление данными
Шестаков Николай Александрович
[email protected]
Схема курса
• Теория
– Лекции
• Практика
– Лабораторные работы
– ИДЗ
• Экзамен
– Допуск: сдача л/р и ИДЗ
– 2 теоретических вопроса + 1 практический
Материалы
ftp://ftp.vt.tpu.ru/study/Shestakov/public/
database
• Конспект лекций
• Книги
• Экзаменационные вопросы
Предмет курса
• Теория реляционных БД
• Проектирование БД
• Язык реляционных БД SQL
• Дополнительные вопросы
• Практика:
– Microsoft SQL Server
– Microsoft SQL Server Management Studio
– Toad Data Modeler
Основные понятия
• Информация —сведения об объектах и
явлениях окружающей среды, их
параметрах, свойствах и состояниях,
которые уменьшают имеющуюся о них
степень неопределенности, неполноты
знаний.
• Данные – это информация, представленная
в виде, пригодном для обработки.
Основные понятия
• Данные - сведения, представленные в
определенной знаковой системе и на
определенном материальном носителе для
обеспечения возможностей хранения,
передачи, приема и обработки.
• Информация - это данные,
сопровождающиеся смысловой нагрузкой,
помещенные в некоторый контекст.
Основные понятия
• Знание – зафиксированная и проверенная
практикой информация, которая может
многократно использоваться людьми для
решения тех или иных задач.
Основные понятия
• Информационная система (ИС) – это
совокупность аппаратных и программных
средств, данных, персонала, организационных
процессов, обеспечивающих нужных людей
нужной информацией в нужное время.
• Information system — a set of hardware,
software, data, human, and procedural
components intended to provide the right data
and information to the right person at the right
time.
Основные понятия
• ИС:
– Аппаратное обеспечение
– Программное обеспечение
– Данные
– Персонал
– Организационные процессы
Основные понятия
• ИС:
– Аппаратное обеспечение
– Программное обеспечение (ПО)
– Данные
– Персонал
– Организационные процессы
Основные понятия
• Признаки ИС:
– Большой объем информации
– Информация хранится структурированно, т.е.
в базе данных
– Система содержит ПО, выполняющее
обработку информации по нетривиальным
алгоритмам
База данных
• Базой данных является представленная в
объективной форме совокупность
самостоятельных материалов (статей,
расчетов, нормативных актов, судебных
решений и иных подобных материалов),
систематизированных таким образом,
чтобы эти материалы могли быть найдены
и обработаны с помощью электронной
вычислительной машины (Гражданский
кодекс РФ, ст. 1260).
Признаки (свойства) баз данных
• База данных хранится и обрабатывается в вычислительной
системе. Таким образом, любые внекомпьютерные хранилища
информации (архивы, библиотеки и т. п.) базами данных не
являются.
• Данные в базе данных хорошо структурированы
(систематизированы). Под структурированностью в данном
случае понимается явное выделение составных частей
(элементов), связей между ними, а также типизация элементов
и связей, при которой с каждым типом элемента или связи
соотносится определённая семантика и допустимые операции.
• Структура базы данных обеспечивает эффективный поиск и
обработку данных. Эффективность здесь главным образом
определяется тем, как соотносятся гибкость и мощность
возможностей (поиска и обработки) с затратами усилий и
ресурсов.
СУБД
• Система управления базами данных – это
совокупность программ и языковых
средств, предназначенных для создания,
ведения и использования БД
Функции СУБД (основные)
• Абстрагирование от физического
представления логическим
представлением в виде схемы БД в рамках
используемой модели данных.
• Поддержка целостности данных в рамках
созданной схемы БД.
• Поддержка языка запросов.
Функции СУБД (основные)
• Таким образом, эти функции сводятся к
управлению данными в БД в соответствии с
некоторой моделью данных
Функции СУБД (дополнительные)
• Разграничение прав доступа.
• Поддержка транзакций.
• Поддержка параллелизма и
многопользовательского режима.
• Наличие средств восстановления после сбоев,
резервного копирования и резервного
дублирования.
• Поддержка распределенных хранилищ
данных.
• Поддержка аналитических функций (OLAP).
Дополнительные определения
• Система баз данных(database system) – ИС,
значительную часть которой составляет БД и СУБД.
• Банк данных (data bank) – совокупность баз данных
для централизованного накопления и
коллективного использования однородных данных
в какой-либо области человеческой деятельности.
Первоначально банками данных называли большие
базы данных под централизованным управлением
мощной ЭВМ. Сейчас чаще всего этот термин
применяют к системам БД, данные которых
доступны как некоторый информационный
справочный сервис
Дополнительные определения
• Хранилище данных (data warehouse) –
очень большая предметноориентированная информационная
корпоративная база данных, специально
разработанная и предназначенная для
подготовки отчётов, анализа бизнеспроцессов с целью поддержки принятия
решений в организации.
Дополнительные определения
• База знаний (knowledge base) – БД,
разработанная для управления знаниями.
Кроме, собственно данных, содержит
различные метаданные: правила
логического вывода, семантические связи.
Модели данных
• СУБД абстрагируются от физического
уровня представления данных и
предоставляют логическую модель для
работы с данными
• Эти логические модели называют
моделями данных. Они описывают то, в
каком виде данные представлены
пользователям СУБД
Модели данных
• Концепция МД родилась в области баз
данных и приобрела в ней
фундаментальное значение. Не случайно за
работы в этой области в разное время
получали премию Тьюринга Чарльз Бахман
(1973) и Эдгар Кодд (1981). Чарльз Бахман
является идеологом сетевой модели
CODASYL, а Кодд – создатель реляционной
модели.
Модели данных
• В классической теории баз данных, модель
данных есть формальная теория
представления и обработки данных в системе
управления базами данных (СУБД), которая
включает, по меньшей мере, три аспекта:
1) аспект структуры: методы описания типов и
логических структур данных в базе данных;
2) аспект манипуляции: методы манипулирования
данными;
3) аспект целостности: методы описания и
поддержки целостности базы данных.
Модели данных
• Аспект структуры определяет, что из себя
логически представляет база данных.
• Аспект целостности определяет средства
описаний корректных состояний базы
данных.
• Аспект манипуляции определяет способы
перехода между состояниями базы данных
(то есть способы модификации данных) и
способы извлечения данных из базы данных.
Функции СУБД (основные)
• Абстрагирование от физического
представления логическим
представлением в виде схемы БД в рамках
используемой модели данных.
• Поддержка целостности данных в рамках
созданной схемы БД.
• Поддержка языка запросов.
Модели данных
• Следовательно, основной функцией,
которую выполняет СУБД, можно назвать
поддержку модели данных, что
выражается в:
– поддержке структурного аспекта (замена
физического представления логическим),
– поддержке аспекта целостности,
– поддержке манипуляционного аспекта (языка
запросов)
Модели данных
• Иерархическая
• Сетевая
• Реляционная
• Объектная (объектно-ориентированная)
• Объектно-реляционная
Иерархическая МД
• Иерархическая МД организует данные в виде
иерархической древовидной структуры.
• Недостатки модели:
– Далеко не всякая предметная область может быть
представлена в виде иерархии.
– Ограничены возможности запросов: поиск в БД требует
прохода по элементам, начиная с корневого.
• Достоинства ИМД:
– Если данные предметной области представимы в виде
иерархии, то иерархическая СУБД будет оперировать с
такими данными эффективнее, чем любая другая.
Иерархическая МД
• Пример ИСУБД – IMS (IBM). Использована и
модифицирована модель, созданная
компанией North American Rockwell и язык
DL/1 (при участии Caterpillar).
• Выпущена в 1966, используется до сих пор
(особенно банковский сектор)
• В настоящее время дополняется
реляционной DB2
Иерархическая модель – XML
• Структура иерархична и определена
синтаксисом XML
• Ограничения целостности задаются через
XML-Schema (XML-документ должен быть
валиден по отношению к схеме)
• Язык: XQuery/XSLT/XPath
Сетевая МД
• С точки зрения теории графов сетевой модели
соответствует произвольный граф. В вершинах графа
при интерпретации помещаются типы сущностей, а
ребра (дуги) графа интерпретируются как типы связей
между типами сущностей.
• Таким образом, в сетевой модели можно реализовать
произвольные связи между сущностями, т.к. граф, в
отличие от дерева, может иметь циклы.
• Однако декларативные возможности языка в такой БД
довольно скудны. Фактически для поиска связанных
элементов приходится осуществлять навигацию по
связям, и логика программы становится сильнее
привязанной к структуре БД.
Сетевые СУБД
• Стандарт сетевой МД разработан при
участии Чарльза Бахмана комитетом
CODASYL в 60-е годы
• В 60-х появились первые сетевые СУБД
(General Electric IDS, DEC DBMS-10, B.F.
Goodrich IDMS)
• В 80-е вытеснены реляционными
системами.
Навигационные БД
• Недостаток сетевых и иерархических
моделей – навигационный характер
запросов. Доступ к элементам данных
осуществляется путём навигации от
элемента к элементу по цепочке.
• Реляционные системы предоставляют
декларативный язык запросов, что
является серьёзным преимуществом
Архитектура систем БД
• В ранний период становления технологий БД (60-е годы)
подходы к разработке и описанию архитектуры систем БД
только зарождались и формировались в результате осмысления
опыта разработки первых промышленных систем. Серьезное
влияние на развитие этого направления оказал Чарльз Бахман,
работавший над проектом одной из первых коммерческих
СУБД IDS (General Electric, 1963 г.) Реализованные в ней
принципы организации БД и манипулирования данными легли
в основу стандарта спецификации сетевой модели данных
CODASYL. В CODASYL были сформулированы основополагающие
принципы построения систем БД, что оказало влияние на
формирование концепции, известной под названием
«трехсхемной технологии» (3-schema approach), описанной в
стандарте ANSI/X3/SPARC (1975 г.)
Архитектура ANSI/X3/SPARC
Архитектура ANSI/X3/SPARC
• Было предложено описывать архитектуру систем БД
на трёх уровнях (представлениях):
• Внешний уровень, или уровень пользовательских
представлений (external schema).
• Концептуальный уровень, иногда его называют
логическим уровнем – это обобщенное
представление данных предметной области
(conceptual schema).
• Внутренний (физический) уровень, или уровень
представления данных, как они хранятся в БД
(internal schema).
Архитектура ANSI/X3/SPARC
• Логическая независимость от данных
означает полную защищенность внешних
схем от изменений, вносимых в
концептуальную схему
• Физическая независимость от данных
означает защищенность концептуальной
схемы от изменений, вносимых во
внутреннюю схему.
Архитектура ANSI/X3/SPARC
• Представленная архитектура, кроме самих
уровней включает отображения:
– концептуального на внутренний, и
– внешнего на концептуальный.
• Отображением концептуальный-внешний
занимается прикладное ПО, входящее в
состав ИС при помощи средств СУБД.
• Отображением концептуальныйфизический занимается СУБД.
Проектирование БД
• Проектирование БД – процесс создания проекта
БД, предназначенной для поддержки
функционирования предприятия и способствующей
достижению его целей.
Когда описание процесса проектирования выходит
за рамки полезных советов (т.н. best practices), то
уместно говорить о методологии проектирования.
• Методология проектирования –
структурированный подход, предусматривающий
использование специализированных процедур,
технических приемов, инструментов, документации
и ориентированный на поддержку и упрощение
процесса проектирования.
Этапы разработки информационной
системы
1. Сбор и анализ требований пользователей.
2. Определение требований к системе.
3. Проектирование БД и выбор СУБД.
Проектирование приложений (параллельно).
4. Разработка приложений.
5. Создание прототипов (необязательный этап).
6. Тестирование. Возврат на п.1.
7. Эксплуатация и сопровождение. Возврат на
п.1.
Этапы проектирования БД
• Концептуальное (семантическое)
проектирование
(aka инфологическое)
• Логическое проектирование
(aka даталогическое)
• Физическое проектирование
Концептуальное проектирование БД
• Концептуальное проектирование БД –
процесс создания модели используемой на
предприятии информации, не зависящей от
любых аспектов ее представления в
компьютерной системе.
• Задача концептуального этапа
проектирования БД — получение
семантических (смысловых) моделей БД
(концептуальных схем), отражающих
информационное содержание конкретной
предметной области.
Концептуальное проектирование БД
• Результат концептуального этапа
проектирования – концептуальная схема БД
• Концептуальная схема БД является
семантической моделью предметной области.
Она описывает структуру (типы) элементов
данных и взаимосвязи между ними. При этом
не затрагивая вопросы представления этих
данных в компьютерной системе.
• Концептуальная схема – наиболее
абстрактное, но при этом формальное
представление БД
Концептуальное проектирование БД
• Для формального описания концептуальных
схем БД используют семантические модели
• Т.о. создание концептуальной схемы БД
можно также назвать семантическим
моделированием
• Семантическая модель – это теория,
математический аппарат, предназначенный
для создания концептуальных схем БД
• Самая широко используемая семантическая
модель – модель «сущность-связь» (EntityRelationship Model, ER-model)
Концептуальное проектирование БД
• При создании концептуальной схемы
разработчик БД:
– Изучает и описывает информационные
потребности пользователей
– Изучает и описывает предметную область
– Формализует полученное знание при помощи
аппарата семантической модели в
концептуальную схему БД
Логическое проектирование БД
• Логическое проектирование – процесс создания
модели используемой на предприятии информации
(логической схемы БД) на основе выбранной
модели данных. Для реляционной МД на этом
этапе получают реляционную схему БД.
• Задача логического этапа проектирования —
организация данных, выделенных на предыдущем
этапе проектирования в форму, принятую в
выбранной модели данных.
• Модель данных для логического проектирования
выполняет примерно ту же роль, что и
семантическая модель для концептуального этапа
Логическое проектирование БД
• На этапе логического проектирования
выбирается модель данных, т.е. тип СУБД.
• Результатом проектирования является
логическая схема БД
• Логическая схема проектируется при
помощи аппарата выбранной модели
данных, но не зависит от конкретной СУБД
Физическое проектирование
• Физическое проектирование – процесс подготовки
описания реализации БД на языке выбранной
СУБД. Рассматриваются организация файлов и
индексов, предназначенных для обеспечения
эффективного доступа к данным, связанные с этим
средства защиты и пр.
• Задача физического подэтапа проектирования —
выбор рациональной структуры хранения данных и
методов доступа к ним, исходя из арсенала
методов, который представляется разработчику
средой СУБД и ОС.
Физическое проектирование
• Результат физического проектирования –
проект БД в конкретной выбранной для
использования СУБД.
• Проект БД включает всё необходимое для
того, чтобы развернуть (создать) готовую
для работы базу данных (пока ещё без
самих данных)
Проектирование БД
• Этапы концептуального и логического
проектирования систем отделяют от физического
проектирования по следующим причинам:
– Они связаны с разными аспектами системы, поскольку
отвечают на вопрос что делать, а не как делать.
– Они выполняются в разное время, поскольку понять,
что надо сделать, следует прежде, чем решить, как это
сделать.
– Они требуют разных навыков и опыта, поэтому требуют
привлечения специалистов различного профиля.
Проектирование БД
Этап
проектирования
Математический
аппарат
Результат
Концептуальный
Семантическая
модель
Концептуальная
схема БД
Наиболее
абстрактна
Логический
Модель данных
Логическая схема
Зависит от типа
СУБД, но не от
конкретной СУБД
Проект БД
Зависит от
конкретной СУБД
Физический
Модель «Сущность-связь» (Entity-Relationship model)
Компоненты ER-модели
• Сущности
• Связи
Модель «Сущность-связь» (Entity-Relationship model)
• Сущность (entity) – некоторый объект, который
рассматривается в конкретной предметной области как
имеющий независимое существование.
• Тип (класс) сущности (entity type) – множество
потенциально возможных сущностей, объединённых
общим набором свойств (атрибутов)
• Иногда выделяют понятие набор сущностей (entity set)
как множество сущностей одного типа. При этом
считается, что тип сущности описывает все сущности,
которые в принципе могут существовать, а набор –
конкретное подмножество типа, с которым мы
работаем в данный момент или храним в БД.
ER-модель (сущности)
• Варианты терминологии
Множество
Объект
Множество сущностей (entity set)
Сущность (entity)
Сущность (Entity)
Экземпляр сущности (Entity instance)
Тип сущности (entity type)
Экземпляр сущности (Entity occurrence)
Сущность
Сущность
ER-модель (сущности)
• Атрибут – свойство сущности. Тип сущности
обладает набором атрибутов, общим для всех
экземпляров сущности.
• Каждый атрибут относится к некоторому
домену (типу)
• Атрибут может быть обязательным
(mandatory) и необязательным. Обязательные
атрибуты не могут содержать пустые значения
в экземплярах сущности
• Домен – множество возможных значений
атрибута
ER-модель (сущности)
• Идентификатор – минимальный набор атрибутов,
который однозначно идентифицирует экземпляр
определенной сущности внутри её класса
• Другими словами, никакие два экземпляра одного
класса сущности не могут иметь совпадающие
значения идентификаторов
• Написанное выше справедливо для сильных
классов сущностей
• Если идентификаторов несколько, один из них, как
правило, выбирается в качестве первичного,
остальные становятся альтернативными
• Идентификаторы также часто называют ключами
ER-модель (сущности)
• Пример типа сущности
Первичный идентификатор
Альтернативные
идентификаторы
Атрибуты
Домены
Обязательность (mandatory)
ER-модель (сущности)
Тип сущности
(обозначен на ER-диаграмме)
Экземпляры сущности
(существуют в реальности и БД)
Иванов И.И.
Петров П.П.
Кузнецова К.К.
Номер =…
ФИО = Петров П.П.
Номер паспорта =…
ИНН =…
…
ER-модель (сущности)
Тип сущности
(обозначен на ER-диаграмме)
Экземпляры сущности
(существуют в реальности и БД)
Иванов И.И.
Петров П.П.
Кузнецова К.К.
Схема
Данные
Номер =…
ФИО = Петров П.П.
Номер паспорта =…
ИНН =…
…
ER-модель (связи)
• Связь (relationship) – однозначно
идентифицируемая ассоциация, которая включает
по одному экземпляру сущности из каждого
участвующего в связи типа сущности
• Тип связи – множество возможных осмысленных
ассоциаций между экземплярами сущностей
определенных типов. На тип связи могут налагаться
определённые ограничения. Часто тип связи
называют просто связью (тогда от понятия
экземпляра связи её отличают по смыслу и
контексту)
ER-модель (связи)
• Варианты терминологии
Множество
Объект
Множество связей (set of relationships)
Связь (relationship)
Связь (Relationship)
Экземпляр связи (Relationship instance)
Тип связи (relationship type)
Связь (relationship)
Связь
Связь
ER-модель (связи)
• Пример связи
8890
8990
Тип связи
Экземпляры связи
Схема
Данные
ER-модель (связи)
• Арность связи –количество экземпляров
сущности, участвующих в связи
• Арность 2 – бинарная связь
• Арность 3 – тернарная связь
ER-модель (связи)
• Примеры многоарных связей
ER-модель (связи)
• Атрибуты связей
• Классическая ER-модель Питера Чена
подразумевает наличие атрибутов как у
сущностей, так и у связей
• Большинство средств ER-моделирования не
поддерживают атрибуты связей. Связь с
атрибутами должна быть преобразована в
сущность
ER-модель (бинарные связи)
• Бинарная связь является самым
распространённым типом связи
• Инструменты ER-моделирования обычно не
поддерживают произвольные многоарные
связи (кроме конкретных видов многоарных
связей, например, наследования)
• Многоарная связь может быть всегда
преобразована в сущность и набор бинарных
связей
ER-модель (бинарные связи)
• Классификация бинарных связей
– 1:1 (один-к-одному, one-to-one)
– 1:М (один-ко-многим, one-to-many)
– М:М (многие-ко-многим, many-to-many)
ER-модель (бинарные связи)
• Связь 1:1
• Если между типами сущностей установлен
такой вид связи, то это означает, что
одному экземпляру первой связываемой
сущности можно сопоставить не более одного
экземпляра второй связываемой сущности и
одному экземпляру второй связываемой
сущности можно сопоставить не более одного
экземпляра первой связываемой сущности
ER-модель (бинарные связи)
• Связь 1:М
• Если между типами сущностей установлен
такой вид связи, то это означает, что
одному экземпляру первой связываемой
сущности можно сопоставить несколько
экземпляров второй связываемой сущности,
но
одному экземпляру второй связываемой
сущности можно сопоставить не более одного
экземпляра первой связываемой сущности
ER-модель (бинарные связи)
• Связь М:М
• Если между типами сущностей установлен
такой вид связи, то это означает, что
одному экземпляру первой связываемой
сущности можно сопоставить несколько
экземпляров второй связываемой сущности,
но
одному экземпляру второй связываемой
сущности можно сопоставить несколько
экземпляров первой связываемой сущности
ER-модель (бинарные связи)
• Если в схеме присутствует связь 1:1, то
очень вероятно, что связанные типы
сущностей стоит объединить в одну
сущность
• Связь М:М может быть преобразована в
промежуточную сущность и две связи 1:М
• Таким образом, самым распространённым
типом бинарной связи является 1:М
ER-модель (кардинальность связи)
• Кардинальность (кратность, мощность) связи –
количество возможных экземпляров
некоторой сущности, которые могут быть
связаны с одним экземпляром другой
сущности с помощью этой связи.
Кардинальность может быть указана как одно
значение, или как набор или диапазон
значений.
• Кардинальность задаётся для концов связи
• Приведённая классификация бинарных связей
является классификацией по кардинальности
ER-модель
• Сильные и слабые (зависимые) типы
сущностей
• Связи с зависимостью (dependency) aka
идентифицирующие связи
ER-модель
Определения, которые противоречат друг другу
• (1) Слабыми называют типы сущностей, экземпляры которых не
могут присутствовать в базе данных, пока не существует
связанного с ним экземпляра другой сущности.
• (2) Слабой сущностью называется сущность, логически
зависящая от существования другой сущности
• (3) К слабым сущностям относятся сущности, экземпляры
которых могут существовать в БД только в том случае, если в
них присутствуют экземпляры некоторых других сущностей
(Крёнке)
• (4) In a relational database, a weak entity is an entity that cannot be
uniquely identified by its attributes alone, it must use a foreign key
in conjunction with its attributes to create a primary key
Т.е. внешний ключ входит в состав первичного ключа
(en.wikipedia.org/wiki/Weak_entity)
ER-модель
Примем следующее определение
• Сущность (как тип) является слабой (==
зависимой), если она не может быть
идентифицирована только собственными
атрибутами, для идентификации также
используется одна или несколько связей с
другими сущностями
• Связь, которая входит в состав такого
идентификатора, называется
идентифицирующей (identifying) или связью с
зависимостью (with dependency)
ER-модель
• Нотации ER-диаграмм
– Нотация Питера Чена
– Воронья лапка (Merise)
– IDEF1X
– UML
Примеры проектирования
концептуальных схем БД
БД библиотеки должна хранить информацию о
читателях и истории выданных книг. На каждой
книге ставится штамп с уникальным кодом.
БД расписания автобусных маршрутов. Должна
храниться история расписаний. Расписание отдельного
маршрута может быть разным в разные дни.
Реляционная модель данных
• Основы РМД заложены Эдгаром Коддом в конце
1960-х
• Преимущества РМД:
– Реляционный подход основывается на небольшом
числе интуитивно понятных абстракций, на основе
которых возможно простое моделирование наиболее
распространённых предметных областей; эти
абстракции могут быть точно и формально определены
– Теоретическим базисом РМД служит простой и
мощный мат. аппарат теории множеств и мат. логики
– Ненавигационный характер управления данными без
необходимости знания конкретной физической
организации базы данных
Реляционная модель данных
• Литература
– С.Д. Кузнецов. Основы баз данных
– К. Дж. Дейт. Введение в системы баз данных.
8-е издание (или новее)
– Ramakrishnan, Gehrke. Database Management
Systems (2nd Ed.)
Реляционная модель данных
• Структурный аспект
– Отношения, атрибуты, домены, переменные
отношения
• Аспект ограничений целостности
– Потенциальные и внешние ключи
• Аспект манипулирования данными
– Реляционная алгебра и реляционное
исчисление
РМД: определения из классической
теории множеств
• Множество – совокупность некоторых
объектов, которые называются элементами
множества
• Свойства множеств:
– Элемент множества не может быть включен во
множество несколько раз. Он либо принадлежит
множеству, либо не принадлежит
– Задавая некоторое множество, мы определяем,
какие элементы в него входят, но не определяем
порядок этих элементов
РМД: определения из классической
теории множеств
• Кортеж длины n – упорядоченная
последовательность из n элементов
x1, x2, …, xn
• Декартовым (прямым) произведением множеств
А1, А2, …, Аn называется множество кортежей
обозначаемое через A1×A2×…×An.
• n-местным отношением на множествах А1, А2, …, Аn
называется любое подмножество декартова
произведения A1×A2×…×An.
• Элементы x1, x2, …, xn (где
) связаны отношением P тогда и только тогда, когда
РМД: определения из классической
теории множеств
• Пример 1
– Множество A={a, b, c}
– Множество B={1, 2}.
– A×B = {(a, 1), (a, 2), (b, 1), (b, 2), (c, 1), (c, 2)}.
– Пример отношения на множествах A и B:
{(a, 2), (b, 1), (b, 2)}
РМД: определения из классической
теории множеств
•
•
Пример 2
Есть множества:
–
–
–
–
–
•
множество телефонных номеров (ТН),
множество фамилий (Ф),
множество имен (И),
множество дат (Д),
множество номеров паспортов (ПН).
На декартовом произведении И×Ф×ПН×Д можно задать отношение:
{
(Иван, Петров, 6912 789568, 01.01.1985),
(Петр, Иванов, 7112 789568, 02.03.1985),
(Елена, Кузнецова, 7012 789568, 03.02.1985),
(Ирина, Семёнова, 6822 789568, 01.01.1985)
}
•
•
Запись в виде A1×A2×…×An задает порядок следования множеств в ДП, что
позволяет различать какой элемент внутри кортежа из какого множества был
взят
Первоначально Эдгар Кодд в реляционной модели использовал примерно
такое определение отношения
РМД: структурный аспект
• Терминология классической теории
множеств оказалась неудобной
• Поэтому базовые термины: кортеж,
отношение, атрибут имеют в РМД свои,
отличные от классических, определения
• Далее будем использовать терминологию
по Кристоферу Дейту
РМД: структурный аспект
• Домен (тип) – множество всех возможных
значений, которые может принимать некоторый
атрибут
• В приведённых примерах каждое из множеств,
входящих в ДП, можно назвать доменом. Иногда
домены также называют типами. В реляционной
теории домен и тип – одно и то же, и чаще
используется термин домен. Иногда под типами
понимают более общие множества, например,
целое или строка. Но можно задать домен и более
узко, например «адрес электронной почты».
РМД: структурный аспект
• Определение кортежа и отношения из теории
множеств не очень-то удобно для использования в
области БД, поскольку:
– В отношении нет информации об имени атрибута.
– Отношение явно не несет информации о том, к каким
доменам принадлежат элементы кортежей. Это
становится известно только если непосредственно
указано подмножеством какого ДП является
отношение.
– То же самое относится и к кортежам. Взяв отдельный
кортеж, мы без дополнительной информации ничего
не можем сказать о том, значениями каких атрибутов
являются элементы кортежа и какие имена у этих
атрибутов.
РМД: структурный аспект (кортеж)
• Если дана коллекция доменов Ti (i = 1, 2, …, n), которые не
обязательно все должны быть разными, то
кортежем t, определенным с помощью этих типов, является
множество упорядоченных троек в форме <Ai, Ti, vi> , где Ai –
имя атрибута, Ti – имя домена, vi – значение, принадлежащее
домену Ti.
• n – это степень или арность кортежа. Кортеж степени n
называют n-арным или n-элементным
• Упорядоченная тройка <Ai, Ti, vi> - компонент кортежа.
• Упорядоченная пара <Ai, Ti> - атрибут кортежа, и однозначно
определяется именем атрибута Ai
• vi – значение атрибута
• Множество атрибутов <Ai, Ti> составляет заголовок (тип)
кортежа
РМД: структурный аспект (кортеж)
• Кортежи t1 и t2 являются равными тогда и
только тогда, когда они имеют одинаковые
атрибуты А1, А2, …, Аn и для всех i (i = 1, 2, …, n)
и значение v1 атрибута Ai в кортеже t1 равно
значению v2 атрибута Ai в кортеже t2
• Если t1 = t2, то t1 и t2 называются дубликатами
по отношению друг к другу
• Для кортежей в общем случае не задан
порядок (неприменимы операции сравнения
«больше» и «меньше»)
РМД: структурный аспект (кортеж)
• Свойства кортежей
– Каждый кортеж содержит точно одно значение
для каждого из своих атрибутов.
– Значение атрибута кортежа не может быть
пустым.
– Компоненты кортежа не упорядочены, в
отличие от аналога из ТМ.
– Подмножество кортежа является кортежем, а
подмножество заголовка является заголовком.
РМД: структурный аспект (кортеж)
• Пример кортежа
Название атрибута
Название домена
Имя сотрудника:
Имя
Фамилия
Фамилия
сотрудника: Номер паспорта сотрудника:
Номер паспорта
Елена
Кузнецова
7012 789568
Дата рождения:
Дата
03.02.1985
Значение
Заголовок
РМД: структурный аспект (отношение)
• Отношение (значение отношения) r состоит из
заголовка и тела, которые соответствуют следующим
определениям.
– Заголовок отношения (схема отношения или тип
отношения) r представляет собой заголовок кортежа,
определение которого дано в определении кортежа.
Атрибутами отношения называют атрибуты его заголовка, и,
соответственно, степенью отношения называется степень
его заголовка.
– Тело отношения r представляет собой множество кортежей,
имеющих один и тот же заголовок, совпадающий с
заголовком отношения. Кардинальность отношения r
определяется как кардинальность этого множества (т.е.
равна количеству кортежей).
РМД: структурный аспект (отношение)
• Пример отношения
Имя сотрудника:
Имя
Фамилия сотрудника:
Фамилия
Номер паспорта сотрудника:
Номер паспорта
Дата рождения:
Дата
Елена
Кузнецова
7012 789568
03.02.1985
Иван
Петров
6912 789568
01.01.1985
Петр
Иванов
7112 789568
02.03.1985
Ирина
Семёнова
6822 789568
01.01.1985
Заголовок
Тело
РМД: структурный аспект (отношение)
• Свойства отношений
1. Каждый кортеж содержит точно одно значение
соответствующего типа для каждого атрибута.
2. Атрибуты не характеризуются упорядочиванием
(например, слева направо).
3. Кортежи не характеризуются упорядочиванием
(например, сверху вниз).
4. В отношении отсутствуют дубликаты кортежей.
5. Даже если отношение не содержит кортежей, у
него есть заголовок
РМД: структурный аспект (отношение)
• Переменная отношения – это переменная, значениями
которой могут быть отношения заведомо заданного типа с
определенными ограничениями целостности.
• Все термины заголовок, тело, атрибут, кортеж, степень (и т.д.),
которые были перед этим определены для значений
отношения, интерпретируются также очевидным образом
применительно к переменным отношения.
• Все возможные значения любой отдельно взятой переменной
отношения принадлежат к одному и тому же типу отношения, а
именно к типу отношения, указанному в определении
переменной отношения (указанному косвенно, если данная
переменная отношения является представлением), и поэтому
имеют одинаковый заголовок.
РМД: структурный аспект
• Реляционная база данных — это такая база
данных, которая воспринимается ее
пользователями как множество
переменных отношения, неформально
называемых таблицами.
РМД: структурный аспект
Соответствие реляционных терминов терминам SQL
Реляционный термин
SQL термин
Переменная отношения
(Relation Variable)
Отношение
(Relation)
Таблица (Table) (как элемент схемы БД),
Представление (View)
Набор данных (Dataset),
Состояние (текущее наполнение) таблицы,
Результат запроса,
Таблица (как множество записей)
Столбец (Column),
Поле (Field)
Домен, Тип, Определяемый пользователем тип
Строка (Row),
Запись (Record)
Атрибут отношения
Домен
Кортеж
РМД: ограничения целостности
• Ограничение целостности (ОЦ) – это логическое
выражение, связанное с некоторой БД, результатом
вычисления которого всегда должно быть истинное
значение. Т.е. ОЦ ограничивает возможные состояния
БД
• Если какая-либо операция приводит к тому, что это
выражение принимает ложное значение, эта операция
не должна быть применена, а состояние БД должно
остаться таким, каким оно было до применения
операции
• Важная функция СУБД – поддержка ОЦ, т.е. СУБД
должна следить за тем, чтобы ОЦ выполнялись, а
операции, приводящие к их нарушению, не
применялись
РМД: ограничения целостности
• Классификация ОЦ
– Ограничением базы данных называется ограничение
на значения, которые разрешено принимать указанной
базе данных.
– Ограничением переменной отношения называется
ограничение на значения, которые разрешено
принимать указанной переменной отношения.
– Ограничением атрибута называется ограничение на
значения, которые разрешено принимать указанному
атрибуту.
– Ограничение типа представляет собой не что иное, как
определение множества значений, из которых состоит
данный тип. Задавая домен, мы задаём ограничение
типа.
РМД: ограничения целостности
• В РМД поддерживается класс ОЦ,
основанный на понятии ключей:
– Потенциальные ключи
– Внешние ключи (для поддержки ссылочной
целостности)
РМД: ОЦ – потенциальный ключ
• Допустим, что K — множество атрибутов
переменной отношения R. В таком случае K
является потенциальным ключом для R тогда
и только тогда, когда оно обладает
одновременно двумя перечисленными ниже
свойствами:
а) Уникальность. Ни одно допустимое значение R
никогда не содержит два разных кортежа с одним
и тем же значением K.
б) Несократимость. Никакое строгое подмножество
K не обладает свойством уникальности.
РМД: ОЦ – потенциальный ключ
• Потенциальный ключ может быть простой (состоит из
одного атрибута) и составной (состоит из нескольких
атрибутов)
• Каждая переменная отношения имеет, по меньшей
мере, один потенциальный ключ (множество всех
атрибутов переменной отношения R всегда обладает
свойством уникальности, т.к. никакие два кортежа в
значении R не могут являться дубликатами)
• Потенциальные ключи в реляционной модели
предоставляют основной механизм адресации на
уровне кортежей. Зная значение потенциального ключа,
мы можем найти кортеж в отношении, и если он в
отношении присутствует, то гарантированно в
единственном экземпляре. Значение потенциального
ключа можно использовать как ссылку на кортеж в
отношении
РМД: ОЦ – суперключи
• Любое надмножество потенциального
ключа будет обладать свойством
уникальности. Такое надмножество
называется суперключом (СК).
• СК обладает свойством уникальности, но
необязательно обладает свойством
несократимости.
• Потенциальный ключ – частный случай
суперключа.
РМД: ОЦ – первичные и
альтернативные ключи
• В переменной отношения может быть больше
одного потенциального ключа
• Один из этих ключей выбирается в качестве
первичного
• Остальные потенциальные ключи называются
альтернативными
• С точки зрения РМД, выбор первичного ключа (ПК)
является произвольным. На практике ПК выбирают
исходя из удобства использования (короткие ПК
удобнее в качестве ссылок)
• Потенциальные ключи в РМД играют роль
идентификаторов в ER-модели (первичные ключи –
роль первичных идентификаторов)
РМД: ОЦ – потенциальный ключ
Студент
ID Студента
Первичный ключ
Номер зачётной книжки
Альтернативный ключ
Номер студенческого билета
Альтернативный ключ
Номер паспорта
Альтернативный ключ
Потенциальные ключи
Фамилия
Имя
Отчество
Дата рождения
ID Группы
Номер паспорта, Имя
Номер зачётной книжки, Дата рождения
ID Студента, Отчество, ID Группы
…
Примеры
составных
суперключей
РМД: ОЦ – потенциальный ключ
Состав заказа
Номер заказа
Номер товара
Количество товара
Стоимость
Составной первичный ключ
РМД: ОЦ – внешние ключи
Группы
Студент
ID Группы
ID Студента
Номер
Номер зачётной книжки
Год поступления
Номер студенческого билета
Номер паспорта
Фамилия
Имя
Отчество
Дата рождения
ID Группы
Не обязательно для каждого студента
повторно указывать Номер группы и
Год поступления
Достаточно задать ID Группы, по которому
можно найти данные о группе в
переменной отношения Группы
Для этого ID Группы должен быть первичным
ключом в переменной отношения Группы
Для атрибутов-ссылок в РМД введено понятие
внешнего ключа
РМД: ОЦ – внешние ключи
• Чтобы корректно использовать атрибут ID Группы пер.отн.
Студенты в качестве ссылки на кортеж пер.отн. Группы
необходимо:
– ID Группы в пер.отн. Группы является уникальным (т.е.
потенциальным ключом)
– Атрибут ID Группы в пер.отн. Студенты и ID Группы в пер.отн.
Группы принадлежат одному типу (домену)
– Атрибут ID Группы в пер.отн. Студенты содержит значения,
существующие в пер.отн. Группы
– Предыдущее условие должно соблюдаться при выполнении
любых операций над пер.отн. Студенты и Группы (удаление,
добавление, обновление), т.е. является ограничением
целостности
• Для автоматического выполнения этих условий атрибут
Студенты.[ID Группы] объявляется внешним ключом на
атрибут Группы.[ID Группы]
РМД: ОЦ – внешние ключи
(определение)
• Допустим, что R2 — некоторая переменная отношения.
В таком случае внешним ключом в R2 является
множество атрибутов R2, скажем, FK, такое, что
выполняются следующие требования:
а) существует переменная отношения R1 (R1 и R2 не
обязательно должны быть разными) с потенциальным
ключом CK;
б) существует взаимнооднозначное соответствие между
атрибутами FK и атрибутами CK, такое что атрибут A2i из FK
определен на том же домене, что и соответствующий
атрибут A1i из CK;
в) в любое время каждое значение атрибута A2i из FK в
значении R2 идентично значению атрибута A1i из СК в
некотором кортеже в текущем значении R1.
РМД: ОЦ – внешние ключи
Русскоязычный термин
Англоязычный термин
Потенциальный ключ
Candidate Key
Первичный ключ
Primary Key
Альтернативный ключ
Alternate Key
Суперключ
Superkey
Внешний ключ
Foreign Key
РМД: ОЦ – внешние ключи
• Связь через внешний ключ относится к типу
«один-ко-многим»
• Если внешний ключ объявить потенциальным
ключом, то связь станет «один-к-одному»
• Связь «Многие-ко-многим» реализуется через
промежуточную переменную отношения и две
связи «1:М»
• Если внешний ключ переменной отношения
входит в состав первичного, то
соответствующая этой пер.отн. сущность
является слабой
РМД: ОЦ – внешние ключи
Концептуальная схема (ER-модель)
Книги
Авторы
Номер
UI
М:М
ФИО
Номер
UI
ISBN
AI
Название
Биография
Аннотация
Логическая схема (реляционная модель)
Авторы
Номер
ФИО
Биография
PK
1:М
Книги
АвторыКниги
М:1
Номер
PK
AK
Номер
автора
PK,
FK
ISBN
Номер
книги
PK,
FK
Аннотация
Название
РМД: ОЦ – внешние ключи
• Внешний ключ может указывать на
первичный ключ в той же переменной
отношения
• Пример: иерархия
Сотрудники
ID Сотрудника
PK
ID Начальника
FK
ФИО
Рабочий
телефон
Отображение ER-диаграммы на
реляционную схему
• Отображение сущностей и атрибутов
– Сущности ER-модели преобразуются в
переменные отношения в РМД
– Атрибуты сущностей ER-модели преобразуются
в атрибуты переменных отношения
– Идентификаторы становятся потенциальными
ключами
Отображение ER-диаграммы на
реляционную схему
• Отображение связей и зависимостей
– Связь 1:М в ER-модели преобразуется в атрибут
переменной отношения – внешний ключ (на
стороне «многие»)
– Связь М:М преобразуется в промежуточную
переменную отношения и две связи 1:М
– Если сущность слабая (зависимая), то внешний
ключ, соответствующий связи с зависимостью
(dependency), входит в состав первичного
ключа
Отображение ER-диаграммы на
реляционную схему
• Отображение наследования
– 1 способ: в сущности-наследники включаются
атрибуты родительской сущности и в таком
виде преобразуются в переменные отношения
– 2 способ: сущность родитель преобразуется в
переменную отношения, сущности-наследники
преобразуются в переменные отношения,
связанные с родительской п.о. внешним
ключом, который также является первичным
РМД: Манипулирование данными
• В РМД существует 2 базовых механизма
манипулирования данными:
– Реляционная алгебра
• Основана на теории множеств
– Реляционное исчисление
• Основано на математической логике (исчислении
предикатов первого порядка)
РМД: Реляционная алгебра
• Существует много более или менее
равносильных определений реляционной
алгебры (РА), которые различаются набором
операций, их обозначением и интерпретацией
• Здесь описывается алгебра Эдгара Кодда
расширенная Кристофером Дейтом
• http://www.intuit.ru/department/database/rdbintro/3
(С.Д. Кузнецов. Введение в реляционные базы
данных, лекция 3)
РМД: Реляционная алгебра
• Любая алгебра состоит из:
– множества элементов
– операций, определённых над этими элементами
• Важное свойство алгебры – замкнутость
операций на множестве элементов. Это
значит, что любая операция принимает
элементы этого множества и возвращает
элементы этого множества. Это даёт
возможность строить алгебраические
выражения
РМД: Реляционная алгебра
• Например:
– Операции {+, -} на множестве целых чисел
являются алгеброй
– Операции {*, /} на множестве положительных
рациональных чисел являются алгеброй
– Операции {AND, NOT} на множестве {True, False}
являются алгеброй
– Операции {+, -} на множестве натуральных
чисел не являются алгеброй
РМД: Реляционная алгебра
• Множеством элементов в РА алгебре
является множество отношений
• Следовательно, все операции РА
определены на отношениях и их
результатами являются отношения
• Таким образом, РА позволяет группировать
операции в алгебраические выражения и
запросы к реляционной БД могут быть
представлены в виде таких выражений
РМД: Реляционная алгебра
• В рассматриваемом варианте алгебры
Кодда определено 8 операций,
разделённых на 2 группы:
– Теоретико-множественные операции
• заимствованы из теории множеств и адаптированы
к реляционному подходу
– Специальные реляционные операции
• Не имеют традиционных аналогов в теории
множеств
РМД: Реляционная алгебра
• Теоретико-множественные операции
– Объединение (UNION)
– Пересечение (INTERSECT)
– Разность (MINUS)
– Декартово произведение (TIMES)
• Специальные реляционные операции
– Селекция или ограничение (WHERE)
– Проекция (PROJECT)
– Соединение (JOIN)
– Деление (DIVIDE BY)
РМД: Реляционная алгебра
• Кроме этого (Крисом Дейтом) были
предложены дополнительные
вспомогательные операции:
– Переименование (RENAME)
– Присваивание ( := )
РМД: Реляционная алгебра
Операция
Приоритет
RENAME
4
WHERE
3
PROJECT
3
TIMES
2
JOIN
2
INTERSECT
2
DIVIDE BY
2
UNION
1
MINUS
1
РМД: Реляционная алгебра
• Объединение, пересечение, разность.
Традиционные определения:
– Объединением множеств A и B является такое
множество C, что для любого с ϵ C либо существует
такой элемент a ϵ A, что c=a, либо существует такой
элемент b ϵ B, что c=b ;
– пересечением множеств A и B является такое
множество C, что для любого c ϵ C существуют такие
элементы a ϵ A, и b ϵ B, что c = a = b ;
– разностью множеств A и B является такое множество C,
что для любого c ϵ C существует такой элемент a ϵ A, что
c = a, и не существует такой элемент b ϵ B, что c = b.
РМД: Реляционная алгебра
РМД: Реляционная алгебра
• Традиционные определения не применимы к
отношениям из РМД
• Если понимать отношения как множества кортежей,
то объединив кортежи произвольных отношений,
мы не получим отношение, т.к. у кортежей могут
быть разные заголовки
• Отсюда возникает понятие совместимости
отношений по объединению
• Отношения совместимы по объединению, если они
имеют одинаковый заголовок (тип)
• То же справедливо и для пересечения и разности
РМД: Реляционная алгебра
• Если даны отношения R1 и R2 одного и того же типа,
то:
– объединение этих отношений R1 UNION R2 является
отношением того же типа с телом, которое состоит из
всех кортежей, присутствующих в R1 или в R2 или в
обоих отношениях;
– разность отношений R1 MINUS R2 является
отношением того же типа с телом, которое состоит из
всех кортежей, присутствующих в R1, но не
присутствующих в R2;
– пересечение отношений R1 INTERSECT R2 является
отношением того же типа с телом, которое состоит из
всех кортежей, присутствующих одновременно и в R1,
и в R2.
РМД: Реляционная алгебра
• Декартово произведение. Традиционное
определение:
– декартовым произведением множеств A{a} и B{b}
является такое множество пар C{<c1, c2>}, что для
каждого элемента <c1, c2> множества C существуют
такой элемент a множества A, что c1 = a, и такой
элемент b множества B, что c2 = b.
• Если таким образом перемножить тела двух
отношений, то не получится отношение
(получится множество пар кортежей)
РМД: Реляционная алгебра
• Декартово произведение (расширенное
определение в РМД)
– Пусть имеются два отношения
R1{a1, a2, …, an} и R2{b1, b2, …, bm}.
Тогда результатом операции R1 TIMES R2 является
отношение
R{a1, a2, …, an, b1, b2, …, bm}, тело которого является
множеством кортежей вида
{ra1, ra2, …, ran, rb1, rb2, …, rbm} таких, что
{ra1, ra2, …, ran} входит в тело R1, а
{rb1, rb2, …, rbm} входит в тело R2
РМД: Реляционная алгебра
• Для того, чтобы расширенное декартово
произведение можно было выполнить корректно,
необходимо, чтобы отношения R1 и R2 не
содержали совпадающих имён атрибутов.
• Это условие называется совместимостью по взятию
расширенного декартова произведения
• Если необходимо перемножить отношения с
совпадающими именами атрибутов в заголовках, к
одному из отношений необходимо применить
операцию переименования (RENAME)
РМД: Реляционная алгебра
• Операция селекции (ограничения или
сокращения)
– Пусть R – некоторое отношение, а P — некоторое
логическое выражение (предикат), принимающее
значения атрибутов кортежа отношения R в
качестве входных параметров.
– Селекцией отношения R по условию P
(R WHERE P) является отношение с тем же
заголовком, что и в R, и с телом, состоящим из всех
кортежей отношения R, удовлетворяющих условию
P (для которых предикат P принимает истинное
значение)
РМД: Реляционная алгебра
• Операция проекции (PROJECT)
– Предположим, что отношение R имеет атрибуты X,
Y, . . ., Z (а также, возможно, некоторые другие). В
таком случае проекция отношения R по атрибутам
X, Y, ..., Z (обозначим PROJECT R(X, Y, ..., Z) ) является
отношением, соответствующим требованиям:
• Его заголовок формируется из заголовка отношения R
путем удаления всех атрибутов, не указанных в
множестве { X, Y, ... , Z }.
• Тело состоит из всех кортежей { Х х , Y у, ..., Z z}, таких, что
в отношении R присутствует кортеж со значением х
атрибута X, у атрибута Y ... и (соответственно) z атрибута
Z.
РМД: Реляционная алгебра
• Таким образом, применение операции проекции
фактически приводит к получению "вертикального"
подмножества заданного отношения, полученного
путем удаления всех атрибутов, не указанных в
разделенном запятыми списке имен атрибутов, и
последующего устранения дубликатов
(суб)кортежей из множества оставшихся кортежей.
• Если отношение представить в виде таблицы, то
операции проекции будет соответствовать удаление
некоторых столбцов таблицы и (затем) удаление
дубликатов записей
РМД: Реляционная алгебра
• Операция соединения
• результатом операции соединения
отношений R1 и R2 по условию P (R1 JOIN
R2 WHERE P), совместимых по взятию
расширенного декартова произведения,
является отношение, получаемое путем
выполнения операции ограничения по
условию P расширенного декартова
произведения отношений R1 и R2
РМД: Реляционная алгебра
• То есть:
• R1 JOIN R2 WHERE P
есть то же самое, что
(R1 TIMES R2) WHERE P
• И соединение в общем случае – это
декартово произведение с селекцией
РМД: Реляционная алгебра
• Виды соединений
– Эквисоединение (EQUIJOIN)
• Предикат P имеет вид a=b, где a и b – атрибуты разных операндов
соединения
– Естественное соединение (NATURAL JOIN)
• Применяется к паре отношений A и B, обладающих (возможно,
составным) общим атрибутом c (т. е. атрибутом с одним и тем же
именем и определенным на одном и том же домене). Пусть ab
обозначает объединение заголовков отношений A и B. Тогда
естественное соединение A и B – это спроецированный на ab
результат эквисоединения A и B по условию A.c = B.c
• В данном определении использована точечная нотация (с
указанием не только имени атрибута, но и отношения, из которого
берётся атрибут. Такая нотация позволяет обращаться к
одинаковым именам атрибутов из разных отношений без явного
использования операции RENAME
РМД: Реляционная алгебра
• Деление (DIVIDE BY)
• Результатом деления отношения R1(A’,B’) на
отношение R2(B’), где A’ и B’ — подмножество
атрибутов, причем B’ — подмножество общих для
обоих отношений атрибутов (атрибутов связи),
является новое отношение R(A’), содержащее
атрибуты A’ и кортежи отношения R1 с
одинаковыми c R2 значениями атрибутов связи B’.
• Или: тело R состоит из кортежей v(a) таких, что в
теле отношения R1 содержатся кортежи y(a, b)
такие, что проекция y(a, b) по b включает тело
отношения R2
РМД: Реляционная алгебра
(R1 DIVIDE BY R2) TIMES R2 является подмножеством R1
http://www.intuit.ru/department/database/rdbintro/3/5.html
РМД: Реляционное исчисление
• РИ основано на логике предикатов 1-го
порядка
• Форма записи выражений на языке РИ более
декларативна, чем РА: в РИ записывается
условие, которому должен удовлетворять
результат, когда в РА – последовательность
операций
• Несмотря на это РИ и РА эквивалентны в своей
выразительной полноте: любое выражение на
языке РИ можно выразить через РА и наоборот
РМД: Реляционное исчисление
• Пример
– работаем с базой данных, которая состоит из
отношений СЛУЖАЩИЕ {СЛУ_НОМ, СЛУ_ИМЯ,
СЛУ_ЗАРП, ПРО_НОМ} и ПРОЕКТЫ {ПРО_НОМ,
ПРОЕКТ_РУК, ПРО_ЗАРП} (в отношении ПРОЕКТЫ
атрибут ПРОЕКТ_РУК содержит имена служащих,
являющихся руководителями проектов, а атрибут
ПРО_ЗАРП – среднее значение зарплаты,
получаемой участниками проекта)
– хотим узнать имена и номера служащих, которые
являются руководителями проектов со средней
заработной платой, превышающей 38000 руб.
РМД: Реляционное исчисление
• РА:
– (СЛУЖАЩИЕ JOIN ПРОЕКТЫ WHERE (СЛУ_ИМЯ =
ПРОЕКТ_РУК AND ПРО_ЗАРП > 38000.00)) PROJECT
(СЛУ_ИМЯ, СЛУ_НОМ)
• Это выражение можно было бы прочитать,
например, следующим образом:
– выполнить эквисоединение отношений СЛУЖАЩИЕ и
ПРОЕКТЫ по условию СЛУ_ИМЯ = ПРОЕКТ_РУК;
– ограничить полученное отношение по условию
ПРО_ЗАРП > 18000.00;
– спроецировать результат предыдущей операции на
атрибут СЛУ_ИМЯ, СЛУ_НОМ.
РМД: Реляционное исчисление
• РИ:
– Определяем переменные:
RANGE СЛУЖАЩИЙ IS СЛУЖАЩИЕ
RANGE ПРОЕКТ IS ПРОЕКТЫ
– Выражение с определёнными переменными:
СЛУЖАЩИЙ.СЛУ_ИМЯ, СЛУЖАЩИЙ.СЛУ_НОМ WHERE EXISTS
(СЛУЖАЩИЙ.СЛУ_ИМЯ = ПРОЕКТ.ПРОЕКТ_РУК AND
ПРОЕКТ.ПРО_ЗАРП > 18000.00)
• Можно прочитать следующим образом:
– выдать значения СЛУ_ИМЯ и СЛУ_НОМ для каждого
кортежа из СЛУЖАЩИЕ такого, что существует кортеж из
ПРОЕКТЫ со значением ПРОЕКТ_РУК, совпадающим со
значением СЛУ_НОМ этого кортежа из СЛУЖАЩИЕ , и
значением ПРО_ЗАРП, большим 38000.00
РМД: Реляционное исчисление
• Таким образом, в РИ описан предикат
(условие), которому должны удовлетворять
все кортежи отношения-результата
• Для описания предиката используются
различные логические условия, а также
кванторы общности (FORALL) и
существования (EXISTS)
SQL
Нормализация БД
• Плохо спроектированная БД приводит к многочисленным
проблемам её использования:
– Невозможность добавления данных
– Удаление нужных данных вместе с ненужными
– Дублирование данных, опасное почти неизбежным
рассогласованием данных (что равноценно их потере)
• Теория нормализации БД пытается определить формальные
признаки плохого дизайна БД
• Эти признаки формулируются в виде нормальных форм, в
которых должны находиться переменные отношения в
реляционной БД
• Если переменная отношения не находится в какой-то из
нормальных форм, она должна быть приведена к этой
нормальной форме (как правило, путём декомпозиции без
потерь)
Нормализация БД
• Нормальные формы:
– 1 НФ
– 2 НФ
– 3 НФ
– НФБК (нормальная форма Бойса-Кодда)
– 4 НФ
– 5 НФ (высшая НФ, которой можно достичь при
помощи декомпозиции)
• Если переменная отношения находится в
какой-то НФ, то она удовлетворяет всем более
низким НФ
Функциональная зависимость
• Важнейшим понятием в теории нормализации
является функциональная зависимость (ФЗ)
• Пусть R является переменной отношения, а X и Y —
произвольными подмножествами множества
атрибутов переменной отношения R. Тогда Y
функционально зависимо от X (записывается как
X -> Y , также читается как «X функционально
определяет Y») тогда и только тогда, когда для
любого допустимого значения переменной
отношения R каждое значение множества X
отношения R связано точно с одним значением
множества Y отношения R.
Функциональная зависимость
• ФЗ X->Y означает, что если два кортежа
переменной отношения R совпадают по
значению X, они также совпадают и по
значению Y (для любого допустимого
значения переменной отношения R)
• X – детерминант ФЗ, Y – зависимая часть ФЗ
• Если Y – подмножество X (или Y=X), ФЗ
называется тривиальной
Функциональная зависимость
• Свойства ФЗ (A, B и C – множества атрибутов
переменной отношения, возможно,
пересекающиеся)
• Правила Армстронга:
– Правило рефлексивности.
Если B является подмножеством А, то А -> В,
и такая ФЗ называется тривиальной.
– Правило дополнения.
Если А -> B, то АС -> ВС.
– Правило транзитивности.
Если А -> B и B -> C, то А -> С,
и такая ФЗ называется транзитивной.
• Система правила Армстронга полна и совершенна
Функциональная зависимость
• Дополнительные свойства ФЗ, выводимые
из правил Армстронга
– Правило самоопределения.
А -> А.
– Правило декомпозиции.
Если А -> ВС, то А -> B и A -> C.
– Правило объединения.
Если А -> В и А -> С, то А -> ВС.
– Правило композиции.
Если А -> B и С -> D, то АС -> BD.
Функциональная зависимость
• Y находится в полной (неприводимой
слева по Дейту) функциональной
зависимости от Х, если он функционально
зависит от Х и не зависит функционально от
любого подмножества Х
Декомпозиция без потерь
• Декомпозиция отношения – это разбиение
отношения на проекции
• Декомпозиция переменной отношения –
аналогичная операция, но над переменной
отношения
• Декомпозиция переменной отношения R на
проекции R1, R2, ..., Rn выполняется без потерь,
если R равна естественному соединению R1,
R2, ..., Rn при любом значении R
Теорема Хита
• Пусть дана переменная отношения
R(A, B, C)
• Если R удовлетворяет функциональной
зависимости A -> B, то оно равно
соединению его проекций R(A, B) и R(A, C)
при любых значениях R
1 НФ
• Переменная отношения находится в 1НФ
тогда и только тогда, когда в любом
допустимом значении этой переменной
отношения каждый ее кортеж содержит
только одно значение для каждого из
атрибутов.
• Проще говоря, значения атрибутов
атомарны.
2 НФ
• Переменная отношения находится во
второй нормальной форме тогда и только
тогда, когда она находится в 1 НФ и каждый
неключевой атрибут неприводимо зависит
от ее первичного ключа
• В этом определении предполагается
наличие только одного потенциального
ключа, который и является первичным
ключом отношения
3 НФ
• Переменная отношения находится в третьей нормальной
форме тогда и только тогда, когда она находится во 2 НФ и ни
один неключевой атрибут не является транзитивно
зависимым от ее первичного ключа
• В определении предполагается наличие только одного
потенциального ключа (который является первичным)
• Определение 3НФ неадекватно при выполнении следующих
условий, касающихся определенной переменной отношения:
1.
2.
3.
переменная отношения имеет два (или больше) потенциальных
ключа, таких, что:
эти потенциальные ключи являются составными и
два или больше потенциальных ключей перекрываются (т.е.
имеют по крайней мере один общий атрибут)
НФ Бойса-Кодда
• Переменная отношения находится в нормальной форме БойсаКодда тогда и только тогда, когда каждая ее нетривиальная и
неприводимая слева функциональная зависимость имеет в
качестве своего детерминанта некоторый потенциальный ключ
• (определение Дзаниоло). Предположим, что дана переменная
отношения R, что X является некоторым подмножеством
атрибутов этой переменной отношения R и что А является
некоторым отдельным атрибутом переменной отношения R.
Переменная отношения R находится в НФБК тогда и только
тогда, когда для каждой функциональной зависимости X -> А в
переменной отношения R верно по крайней мере одно из
следующих утверждений.
1.
2.
•
X включает атрибут А (т.е. данная ФЗ тривиальна).
X является суперключом переменной отношения R
Т.е. в НФБК все нетривиальные ФЗ – от суперключей
4 НФ
• Многозначная функциональная зависимость
• Пусть R - переменная отношения, а А, B и C
являются произвольными подмножествами
множества атрибутов переменной отношения R.
• Тогда подмножество B многозначно зависит от
подмножества А (символически выражается
записью А →→ В, также читается как «А
многозначно определяет B»), тогда и только тогда,
когда в каждом допустимом значении R множество
значений B, соответствующее заданной паре
значений А, C, зависит только от значения А и не
зависит от значения C.
4 НФ
• многозначная зависимость А→→ B
выполняется тогда и только тогда, когда
выполняется также многозначная
зависимость А →→ С. Таким образом,
многозначные зависимости всегда
образуют связанные пары, поэтому
обычно их представляют вместе в
символическом виде:
• А →→ В|С
4 НФ
• Теорема Фейгина – более строгая версия
теоремы Хита
• Пусть А, B и С являются множествами
атрибутов переменной отношения R{A, B,
С}. В таком случае переменная отношения R
будет равна соединению ее проекций по
атрибутам {А, B} и {А, С} тогда и только
тогда, когда А →→ B|C.
4 НФ
• Многозначная зависимость (МЗ) А →→ B
является тривиальной, если А является
надмножеством B или объединение АВ
атрибутов А и В составляет весь заголовок
• МЗ является частным случаем
функциональной зависимости (ФЗ)
• То есть, любая ФЗ является также и МЗ
4 НФ
• Переменная отношения R находится в
четвертой нормальной форме (4НФ) тогда и
только тогда, когда когда все нетривиальные
многозначные зависимости в ней являются
функциональными зависимостями
• Переменная отношения R находится в 4НФ
тогда и только тогда, когда каждая её
нетривиальная многозначная зависимость
определяется её потенциальными ключами
5 НФ
• Зависимость соединения
• Пусть R— переменная отношения, а А, B, ..., Z
— произвольные подмножества множества ее
атрибутов. Переменная отношения R
удовлетворяет следующей зависимости
соединения *{А, В, ..., Z} (читается
«звездочка А, В, ..., Z») тогда и только тогда,
когда любое допустимое значение
переменной отношения R эквивалентно
соединению ее проекций по подмножествам
А, B,..., Z множества атрибутов.
5 НФ
• ЗС *{А, В, ..., Z} является тривиальной
тогда и только тогда, когда по крайнем мере
одно из подмножеств A, B,..., Z множества
атрибутов является множеством всех
атрибутов отношения
• ЗС *{А, В, ..., Z} определяется
потенциальным ключом тогда и только тогда,
когда каждое из подмножеств A, B,..., Z
является суперключом
• ЗС – частный случай МЗ, то есть, любая МЗ
является также ЗС
5 НФ
• Переменная отношения находится в пятой
нормальной форме (иначе — в
проекционно-соединительной нормальной
форме) тогда и только тогда, когда каждая
нетривиальная зависимость соединения в
ней определяется потенциальным
ключом (ключами) этой переменной
отношения
НФ 1-5
Нормальная форма
Как запомнить
1НФ
Атомарность атрибутов
2НФ
Зависимости от ключей неприводимы
3НФ
Зависимости от ключей нетранзитивны
НФБК
Отсутствуют зависимости от не-ключей
4 НФ
Отсутствуют многозначные зависимости
от не-ключей
Отсутствуют зависимости соединения от
не-ключей
5 НФ
Правила принадлежности систем к реляционным
(«12 правил Кодда»)
0. Фундаментальное. Любая система, которая представляется как реляционная
СУБД, должна быть способна управлять базами данных исключительно с
помощью реляционных функций.
Это означает, что в СУБД не должны применяться какие-либо нереляционные
операции для определения данных и манипулирования ими.
1. Представление информации. Вся информация в РБД представляется в явном
виде на логическом уровне и только одним способом – в виде значений в
таблицах.
Согласно этому правилу, вся информация, даже метаданные в системном
каталоге, должна храниться в виде отношений и управляться с помощью тех
же функций, которые используются для работы с данными. Упоминание в
этом правиле "логического уровня" означает, что такие физические
конструкции, как индексы, не должны быть представлены в модели, и
пользователь не обязан явно их упоминать в операциях выборки данных,
даже если они существуют.
2. Гарантированный доступ. Для всех и каждого элемента данных
(элементарного значения) реляционной базы данных должен быть
гарантирован логический доступ на основе использования комбинации
имени таблицы, значения первичного ключа и значения имени столбца.
Правила принадлежности систем к реляционным
(«12 правил Кодда»)
3. Систематическая обработка NULL-значений. Неопределенные значения (задаваемые с помощью
определителя NULL, т.е. значения, отличные от пустой символьной строки или строки пробельных
символов, а также от нуля или любого другого числа) поддерживаются как способ систематического
представления отсутствующей или неприемлемой информации, причем независимо от типа данных.
4. Динамический оперативный каталог, построенный по правилам реляционной модели. Описание базы
данных должно быть представлено на логическом уровне таким же образом, как и обычные данные, что
позволяет санкционированным пользователям применять для обращений к этому описанию тот же
реляционный язык, что и при обращении к обычным данным.
Это правило указывает на то, что должен существовать только один язык, предназначенный для
манипулирования как метаданными, так и обычными данными, причем в СУБД для организации хранения
системной информации должна использоваться только одна логическая структура — переменная
отношения.
5. Исчерпывающий подъязык данных. Реляционная система баз данных может поддерживать несколько языков
и различные режимы работы. Однако должен существовать по крайней мере один язык, операторы
которого позволяли бы выражать все следующие конструкции:
1) определение данных;
2) определение представлений;
3) операторы манипулирования данными (доступные как в интерактивном режиме, так и с помощью
программ);
4) ограничения целостности;
5) авторизация пользователей;
6) поэтапная организация транзакций (запуск, фиксация и откат).
Правила принадлежности систем к реляционным
(«12 правил Кодда»)
6. Обновление представления. Все представления, которые являются
теоретически обновляемыми, должны быть обновляемыми и в
данной системе.
В действительности ни одна существующая система не поддерживает
это требование, поскольку все еще не сформулированы условия
определения всех теоретически обновляемых представлений.
7. Высокоуровневые операции вставки, обновления и удаления.
Способность обрабатывать базовые или производные переменные
отношения (т.е. представления) как единый операнд должна
относиться не только к процедурам выборки данных, но и к
операциям вставки, обновления и удаления данных.
8. Физическая независимость от данных. Прикладные программы
должны оставаться логически неизменными при внесении любых
изменений в способы хранения данных или методы доступа к ним.
Правила принадлежности систем к реляционным
(«12 правил Кодда»)
9. Логическая независимость от данных. Прикладные программы должны
оставаться логически неизменными при внесении в базовые таблицы любых
не меняющих информацию изменений, которые теоретически не должны
затрагивать прикладное программное обеспечение.
10. Независимость ограничений целостности. Специфические для данной
реляционной СУБД ограничения целостности должны определяться на
подъязыке реляционных данных и храниться в системном каталоге, а не в
прикладных программах.
11. Независимость от распределения данных. Подъязык манипулирования
данными в реляционной СУБД должен позволять прикладным программам и
запросам оставаться логически неизменными, независимо от того, как
хранятся данные — физически централизованно или в распределенном виде.
12. Правило запрета обходных путей. Если реляционная система имеет
низкоуровневый язык (обрабатывающий данные по одной записи), он не
может быть использован для отмены или обхода правил и ограничений,
составленных на реляционном языке более высокого уровня (с
одновременной обработкой сразу нескольких записей).
Администрирование баз
данных
Проектирование БД – разработчики
Поддержка систем БД на предприятии –
администраторы
Администрирование баз данных – это деятельность,
направленная на развёртывание и поддержку в
работоспособном состоянии баз данных предприятия.
Сотрудник предприятия, занимающийся
администрированием БД – администратор БД (АБД)
Задачи, стоящие перед АБД
•
Установка и конфигурирование аппаратного обеспечения, используемого для
работы СУБД и размещения БД.
•
Установка и конфигурирование СУБД (установка новых продуктов и
обновлений, настройка имеющихся, разворачивание новых БД и настройка
имеющихся, разворачивание тестовых конфигураций БД и систем).
•
Настройка прикладного ПО, которое использует СУБД и БД предприятия.
Проведение работ по внедрению новых систем в части, затрагивающей БД (в
том числе, консультации с разработчиками внедряемой системы).
•
Управление безопасностью БД и приложений БД (настройка прав доступа и
разрешений, интеграция системы безопасности СУБД с системой
безопасности, используемой на предприятии).
•
Выполнение резервного копирования и восстановления данных.
•
Мониторинг производительности и устранение связанных проблем (контроль
роста БД, поиск и устранение «бутылочных горлышек»).
•
Создание корпоративных стандартов (регламентов), определяющих порядок
организации процессов администрирования и использования СУБД и БД.
Классификация задач администрирования БД
•
Оперативные (operational):
–
–
–
–
–
–
–
–
•
Тактические (tactical):
–
–
–
–
•
Манипуляция дисковым пространством
Наблюдение за текущей производительностью системы
Исправление возникающих неисправностей БД
Обновление системного ПО и ПО базы данных
Контроль за структурными изменениями БД
Запуск процедур резервного копирования данных
Запуск процедур восстановления данных
Создание и управление тестовыми конфигурациями БД
Реализация схем размещения информации
Утверждение процедур резервного копирования и восстановления данных
Разработка и внедрение структурных элементов БД: таблиц, столбцов, размеров объектов,
индексов и т.п.; сценариев (scripts) изменения схемы БД; конфигурационных параметров БД
Утверждение плана действий в случае аварийной ситуации
Стратегические (strategic) :
–
–
–
–
–
Выбор поставщика СУБД
Разработка корпоративных стандартов данных
Внедрение методов обмена данными в рамках предприятия
Разработка корпоративной стратегии резервирования и восстановления данных
Разработка корпоративного подхода к ликвидации последствий аварии и обеспечению
доступности данных
Классификация АБД по выполняемым функциям
•
Прикладные (application) АБД:
–
–
–
–
–
•
Системные (system) АБД:
–
–
–
–
–
•
отвечают за все необходимое для резервирования и восстановления данных
контролируют производительность системы в целом
осуществляют поиск и устранение неисправностей
в курсе нынешних и будущих потребностей БД в плане емкости
в курсе текущего состояния и нужд БД
Наемные (contract) АБД:
–
–
–
–
–
•
в курсе информационных нужд компании
помогают в разработке прикладных задач
отвечают за разработку схемы и ее изменения
вместе с системным АБД обеспечивают должный уровень резервирования/восстановления данных
занимаются построением тестовых БД
приглашаются под конкретную задачу или в качестве консультантов
передают персоналу необходимые знания
фиксируют свои действия!
должны прекрасно разбираться в соответствующей области
хороши в качестве временного персонала, для оценки проекта или системы
Администраторы-руководители:
–
–
–
–
–
проводят еженедельные совещания
определяют перечень первоочередных задач
устанавливают и оглашают официальный курс и стратегию
утверждают и корректируют должностные инструкции и список обязанностей
следят за наличием соответствующей документации
Требования к квалификации АБД
1.
Общие знания:
–
–
2.
теории баз данных (особенно в части поддержки ограничений целостности)
процесса проектирования систем БД
Детальные знания администрируемой СУБД в части:
–
–
–
–
–
–
–
–
используемого языка (как правило, это диалект SQL с множеством
индивидуальных функций)
системы безопасности (как организован доступ пользователей к серверам БД,
самим БД и объектам БД)
окружения СУБД (операционная система, контроллер домена, ОС пользователей,
каналы связи, Web-сервер, используемые технологии подключения к серверам
БД, сетевая инфраструктура)
используемых методов физического размещения данных (управление дисками и
файловыми группами)
использования и настройки методов доступа (настройка индексов и статистик,
умение читать и понимать планы исполнения запросов, всё, что касается
оптимизации запросов)
языковых и программных средств мониторинга и диагностики
средств резервного копирования
средств репликации
SQL
• SQL – Structured Query Language
• Прародитель – SEQUEL (Structured English
Query Language)
• Стандарты:
– SQL-86
– SQL-89
– SQL-92
– SQL:1999
– SQL:2003
– SQL:2006
– SQL:2008
Классификация средств SQL
• Data Manipulation Language (DML)
– Манипуляция данными (записями в таблицах)
– SELECT, INSERT, UPDATE, DELETE
• Data Definition Language (DDL)
– Определение схемы
– CREATE, ALTER, DROP
• Data Control Language (DCL)
– Доступ к данным
– GRANT, REVOKE, DENY
• Transaction Control Language (TCL)
– Управление транзакциями
– BEGIN TRAN, COMMIT TRAN, ROLLBACK TRAN
Особенности SQL
• Декларативность (основан на реляционной алгебре
и реляционном исчислении)
• Неполное соответствие РМД
• Наличие стандарта (даёт возможность писать код,
не зависящий от СУБД)
• Отступления от стандартов (мешает писать код, не
зависящий от СУБД)
• Изначально задумывался как язык запросов,
похожий на естественный
• В результате стал исключительно инструментом
разработчика/администратора
Несоответствия SQL реляционной МД
• Значительные отличия в терминологии
• Возможность наличия дубликатов записей в
таблицах и результатах запросов
• Возможность повторения названий атрибутов
в результатах запросов
• Возможность появления безымянных
атрибутов в результатах запросов
• Порядок атрибутов в таблице иногда имеет
значение
• Неопределённые значения (NULL)
Представление (VIEW)
• Представление – это объект схемы базы данных,
который в реляционной схеме выглядит и доступен
как таблица, но на самом деле представляет собой
запрос на чтение, извлекающий данные из других
таблиц БД, называемых по отношению к
представлению базовыми таблицами.
• Поскольку данные, которые отображает
представление, расположены в базовых таблицах,
то изменения в базовых таблицах приведут к тому,
что изменятся данные и в представлении. И
наоборот – изменения данных в представлении
приведут к модификации данных в базовых
таблицах.
Представление (VIEW)
• Представления могут служить средством поддержки внешнего
уровня архитектуры системы по схеме Бахмана (поддерживают
принцип логической независимости от данных)
• Представления избавляют программистов от написания
запросов непосредственно в прикладных программах, вместо
этого можно оформить те же запросы на уровне СУБД, а из
прикладной программы делать прямое обращение к
представлению.
• Представление может скрывать сложность логической
структуры базовых таблиц, а выдавать уже готовый и удобный
для работы набор данных.
• Самое главное: представления являются отдельными
объектами схемы БД, а это значит, что на них можно раздавать
разрешения
Представление (VIEW)
• Обычные представления не принимают на вход параметры (так
же, как и таблицы)
• Представления с параметрами называются
параметризованными представлениями
• С логической точки зрения не должно быть разницы, как СУБД
обеспечивает согласованность данных между представлением
и базовыми таблицами
• На физическом уровне бывает важно различать
нематериализованные и материализованные представления:
– Нематериализованные представления при каждом обращении
делают запрос к базовым таблицам
– Материализованные представления хранят копию данных из
базовых таблиц, СУБД обеспечивает согласованность
дублированных данных
Хранимая процедура
(Stored Procedure)
• Хранимая процедура (ХП) - объект базы данных,
представляющий собой набор SQL-инструкций
• Инструкции могут быть DML, DCL, DDL, TCL, то есть,
практически любыми. В отличие от представлений,
можно использовать переменные, циклы, курсоры,
вызывать другие процедуры.
• В ХП может быть несколько инструкций SELECT и
тогда ХП вернёт несколько наборов данных
• ХП может принимать параметры:
– входные (INPUT)
– выходные (OUTPUT), через которые ХП может
возвращать значения
Хранимая процедура
(Stored Procedure)
• В отличие от представления, даже если ХП
возвращает данные инструкцией SELECT, к
ней нельзя обращаться, как к таблице:
использовать в подзапросах, соединениях с
другими таблицами, делать проекцию по
атрибутам или селекцию по записям
• Как и на другие объекты БД, на ХП можно
раздавать разрешения доступа
Хранимая процедура
(Stored Procedure)
• ХП могут (наряду с представлениями) использоваться для
реализации внешних представлений (по терминологии схемы
Бахмана) и поддержке принципа логической независимости от
данных
• В ХП часто реализуется бизнес-логика системы. Рекомендуется
вместо генерации SQL на клиенте, выделять эти запросы в ХП, а
в клиенте вызывать ХП (особенно это относится к
корпоративным ИС)
• ХП используются для разграничения доступа к данным
• ХП используются для сохранения в БД часто используемых
запросов (особенно при администрировании)
• Если СУБД не поддерживает параметризованные
представления, то вместо них могут использоваться ХП
Триггеры (Triggers)
• Триггер – это процедурный код, который
вызывается каждый раз, когда происходит
определенное событие:
– DML-триггеры срабатывают на операциях
вставки, удаления или обновления данных в
таблицах
– DDL-триггеры срабатывают на операциях
изменения схемы БД
Триггеры (Triggers)
• Триггеры чаще всего используются для:
– проверки и поддержки ограничений целостности,
которые нельзя задать непосредственно с
помощью реляционной схемы или другими
средствами СУБД;
– реализации операций модификации данных в
представлениях;
– реализации бизнес-правил, когда изменения
данных в одних таблицах должны вызвать
изменения данных в других таблицах (например,
аудит);
– иногда для репликации;
