Слайд 1Базы данных
Москва
2011
НИЯУ "МИФИ"
Слайд 2Понятие информации
Зарплата будет выдана 25 сентября.
Бухгалтерия.
1
Понятие информации
1.1
Слайд 31.3
Понятие информации
ИНФОРМАЦИЯ
СЕМАНТИКА
ПРЕДСТАВЛЕНИЕ
Въезд запрещен
1
Слайд 41.4
Понятие информации
ИНФОРМАЦИЯ:
Сущность обеспечивающая повышение знаний об окружающем мире ее получателем.
ОЦЕНКА
КАЧЕСТВА ИНФОРМАЦИИ:
- Достоверность.
- Интерпретируемость.
1
Слайд 51.5
Проблемы, возникающие при работе с информацией
Рассинхронизация семантики и представления.
Слайд 61.6
Проблемы, возникающие при работе с информацией
Поддержка ограничений реального мира
Слайд 71.7
Проблемы, возникающие при работе с информацией
Дублирование информации, как источник рассинхронизации
Слайд 81.8
Понятие информации
Проблемы, возникающие при хранении информации :
Рассинхронизация семантики и представления
.
Поддержка ограничений реального мира.
Дублирование информации, как источник рассинхронизации.
Слайд 9Системы управления базами данных
Базы данных – большой объем информации, предназначенный
для хранения в компьютерных системах, таким образом, чтобы облегчить поиск
и изменение данных.
2.1
Слайд 10Системы управления базами данных
2.2
СУБД?
Слайд 11Системы управления базами данных
2.3
Система управления базами данных.
Отделение семантики данных от
представления. Хранение
метаданных о семантике данных:
Сотрудник
Наличие встроенного языка для семантического поиска
данных
(язык построения запросов):
Вывести ФИО сотрудников с зарплатой больше 30 тыс. руб.
Слайд 12Системы управления базами данных
2.4
СУБД
База Данных
Информационная система на основе базы данных
База
Данных
База Данных
Клиентское ПО
Клиентское ПО
Сеть
Слайд 13Системы управления базами данных
Разработчик баз данных.
Задачи:
Проектирование структуры БД, реализация БД
в рамках заданной СУБД.
Требования к СУБД:
- Наличие средств решения проблем,
возникающих при работе с информацией.
- Стандартизованные средства создания БД и манипулирования данными.
2.5
Слайд 14Системы управления базами данных
Разработчик клиентского ПО.
Задачи:
Создание внешнего пользовательского интерфейса для
работы с БД.
Требования к СУБД:
- Удобный станадартизованный доступ к данным.
-
Наличие средств построения запросов и манипулирования данными.
2.6
Слайд 15Системы управления базами данных
Администратор БД.
Задачи:
Обеспечение бесперебойной работы ИС. Поддержание необходимого
QoS.
Требования к СУБД:
- Обеспечение контроля доступа.
- Надежность.
- Высокая производительность.
- Поддержка
больших объемов хранимой информации.
- Масштабируемость системы.
2.7
Слайд 16Системы управления базами данных
Требования к СУБД:
Наличие стандартизованных средств проектирования структуры
БД, устойчивой к проблемам хранения информации.
Наличие стандартизованных средств построения запросов
и манипулирования данными.
Обеспечение вопросов безопасности и надежности
Высокая производительность и поддержка хранения больших объемов информации.
Масштабируемость системы.
2.8
Слайд 17Реляционные базы данных
3
3.4
3.1
Сотрудник
1. Табличное представление данных на логическом уровне:
Таблицы
Представление
конкретной сущности из предметной области.
Столбцы
Свойства (атрибуты), описывающие сущность.
Строки
Конкретные экземпляры
сущности.
Слайд 18Реляционные базы данных
3
3.4
3.2
Сотрудник
2. Использование первичных ключей для идентификации экземпляров сущности:
Потенциальный
ключ (Candidate Key)
Минимальный набор атрибутов однозначно идентифицирующих экземпляр сущности.
Первичный ключ (Primary Key)
Один из потенциальных
ключей, выбранный для однозначной идентификации сущности.
Суррогатный первичный ключ.
Уникальный аттрибут для идентфикации экземпляра сущности, не имеющий отображения в предметной области
Слайд 19Реляционные базы данных
3
3.4
3.3
Сотрудник
Свойства табличной организации данных.
Имена сущностей должны быть уникальны
в рамках схемы БД.
Имена атрибутов должны быть уникальны в рамках
сущности.
Адресация атрибутов допускается только по имени атрибута.
Вывести ФИО Сотрудника
Адресация экземпляров сущности допускается только по значению атрибутов
Найти Сотрудника с ФИО Петров В.В
Слайд 20Реляционные базы данных
3
3.4
3.4
3. Связь сущностей через миграцию первичного ключа:
Внешний ключ
(Foreign Key)
Аттрибут (совокупность аттрибутов), совпадающий с первичным ключом внешней сущности,
использующийся для установки связи между сущностями.
Сотрудник
Отпуск
Слайд 21Реляционные базы данных
3
3.4
3.5
Свойства организации связей путем миграции первичного ключа.
Первичный ключ
мигрирует целиком. Составной первичный ключ не может мигрировать отдельными частями.
Сущность
из которой произошла миграция ключа носит название родительской. Сущность в которую произошла миграция ключа носит название дочерней.
Внешний ключ может входить в состав первичного ключа дочерней сущности. В данном случае связь называется идентифицирующей
Вагон
Место
Слайд 22Реляционные базы данных
3
3.4
3.6
Правила создания таблиц и связей
Реляционные БД основываются на
теории Эдгара Кодда (Edgar F. Codd), которая впоследствии была развита
Кристофером Дейтом (Cristopher J. Date).
В качестве основы разработки послужили три основных принципа:
Независимость от порядка расположения записей в физическом представлении. Необходимо добиться независимости порядка записей в представлении пользователю от порядка расположения записей в физическом представлении.
Независимость от индексирования. Приложения должны оставаться работоспособными при внесении изменений или удаления индексов.
Независимость от пути доступа. Доступ к данным не должен зависеть от их положения в иерархии
5
4
2
Реляционные базы данных
3
3.4
3.7
Правила создания
таблиц и связей
Для оценки качества схемы реляционной БД было введено понятие
нормальных форм.
Нормальная форма.
Совокупность правил, следование которым повышает целостность БД и снижает количество потенциальных аномалий при манипуляции данными.
1
BCNF
3
2
1
BCNF — Boyce Codd Normal Form
(Нормальная форма Бойса Кодда )
Слайд 24Реляционные базы данных
3
3.4
3
Первая нормальная форма
E. Codd:
Отношение находится в первой нормальной
форме если все его атрибуты являются семантически атомарными.
C. Date:
Отношение находится
в первой нормальной форме если оно соответствует следующим условиям:
1) Строки отношения неупорядоченны.
2) Столбцы отношения неупорядочены.
3) Все строки уникальны.
4) Каждая ячейка содержит одно семантически атомарное значение из заданого домена.
Основное различие: Определение Дейта запрещает ячейки с NULL значениями.
Слайд 25Реляционные базы данных
3
3.4
3.8
Первая нормальная форма
Пример нарушения:
Нормализация
Слайд 26Реляционные базы данных
3
3.4
3.9
Первая нормальная форма
Пример нарушения (если требуется поиск по
городам проживания):
Нормализация
Слайд 27Реляционные базы данных
3
3.4
3
Функциональная зависимость.
Пусть R - отношение. Множество атрибутов Y
функционально зависимо
от множества атрибутов X, тогда и только тогда,
когда
для любого состояния отношения R для любых кортежей из того,
что r1.X = r2.X следует что r1.Y = r2.Y
(т.е. во всех кортежах, имеющих одинаковые значения атрибутов X,
значения атрибутов Y так же совпадают в любом состоянии отношения ).
Обозначение.
X →Y
Y функционально зависит от X.
X функционально определяет Y.
X детерминант,
Y зависимая часть
Следствие.
Если атрибуты X составляют потенциальный ключ отношения,
то любой атрибут отношения функционально зависит от X.
Слайд 28Реляционные базы данных
3
3.4
3.10
Примеры функциональной зависимости.
{Номер телефона, Номер сотрудника}
→ Телефон
Номер
сотрудника → ФИО
Номер сотрудника → Дата рождения
Слайд 29Реляционные базы данных
3
3.4
3.11
Вторая нормальная форма
Отношение находится во второй нормальной форме
если оно находится в первой нормальной форме и отсутствуют функциональные
зависимости неключевых атрибутов от части составного потенциального ключа.
Отношение находится в 2НФ тогда и только тогда, когда оно находится в 1НФ, и каждый его не ключевой атрибут функционально полно зависит от любого возможного ключа этого отношения.
Замечание. Отношения удовлетворяющие первой нормальной форме
c простыми первичными ключами удовлетворяют второй нормальной
форме без дополнительных проверок.
Слайд 30Реляционные базы данных
3
3.4
3.12
Пример нарушения второй нормальной формы
№ Сотрудника → ФИО, № Проекта→ Название
Функциональные зависимости, нарушающие
вторую нормальную форму :
Слайд 31Реляционные базы данных
3
3.4
3.13
Проблемы, возникающие при работе с текущим отношением:
Дублирование информации
о сотрудника, отделах и проектах.
Аномалии вставки (INSERT):
Нельзя вставить нового сотрудника,
пока он не назначен на проект.
Аномалии обновления (UPDATE):
При необходимости изменить название проекта, необходимо изменить его
во всех местах где он встречается.
Аномалии удаления (DELETE):
При удалении информации о проекте удалится информация о сотрудниках
Участвующих только в этом проекте. Аналогичная проблема возникает
при удалении сотрудников, выполняющих определенный проект целиком
Слайд 32Реляционные базы данных
3
3.4
3
Нормализация до уровня второй нормальной формы
Сотрудник
Проект
Продолжение схемы на
следующем слайде...
Слайд 33Реляционные базы данных
3
3.4
3.14
Нормализация до уровня второй нормальной формы (продолжение)
Сотрудник проекта
Выводы:
Рассмотренные
выше аномалии устранены.
Слайд 34Реляционные базы данных
3
3.4
3.15
Третья нормальная форма
Отношение R находится в третьей нормальной
форме если оно находится во второй нормальной форме и отсутствуют
транзитивные зависимости атрибутов от потенциального ключа.
Транзитивная зависимость.
Если X →Y и Z →X, то зависимость Z→Y называется транзитивной.
Слайд 35Реляционные базы данных
3
3.4
3.16
Отношение, нарушающее третью нормальную форму.
Сотрудник
Функциональные зависимости, нарушающие третью
нормальную форму:
№ сотрудника →№ Отдела, №Отдела → Телефон
Зависимость № Сотрудника
→ Телефон транзитивна.
Слайд 36Реляционные базы данных
3
3.4
3.17
Проблемы, возникающие при работе с текущим отношением:
Дублирование информации
об отделах.
Аномалии вставки (INSERT):
Возможно появление сотрудника с тем же номером
отдела,
но с другим телефоном.
Аномалии обновления (UPDATE):
При необходимости изменить телефон отдела, необходимо изменить его
во всех местах где он встречается.
Аномалии удаления (DELETE):
При удалении всех сотрудников, принадлежащих определенному отделу
исчезает информация об отделе.
Слайд 37Реляционные базы данных
3
3.4
3.18
Нормализация до уровня третьей нормальной формы
Сотрудник
Отдел
Продолжение схемы
на следующем слайде...
Слайд 38Реляционные базы данных
3
3.4
3.19
Нормализация до уровня третьей нормальной формы (продолжение)
Сотрудник отдела
Выводы:
Рассмотренные
выше аномалии устранены.
Слайд 39Реляционные базы данных
3
3.4
3.20
Нормальная форма Бойса Кодда
Отношение R находится в нормальной
форме Бойса Кодда если оно находится в третьей нормальной форме
и все функционально определяющие совокупности атрибутов являются потенциальным ключом.
Нормализованное отношение находится в НФБК тогда и только тогда, когда каждый детерминант является потенциальным ключом.
До определения НФБК, предполагалось, что в отношении один потенциальный ключ, который и является первичным. НФБК может
нарушаться в случае, когда потенциальных ключей несколько.
Слайд 40Реляционные базы данных
3
3.4
3.21
Поэтому функциональных зависимостей нарушающих 2НФ и 3НФ нет.
Функциональные зависимости
нарушающие форму Бойса Кодда:
№ Сотрудника →ФИО и ФИО → №
Сотрудника, т.к их детерминанты не является частью потенциального ключа
Отношение, нарушающее нормальную форму Бойса Кодда.
Сотрудник проекта
В данном отношении два потенциальных ключа:
{№Сотрудника, № Проекта} и {ФИО, № Проекта}
Слайд 41Реляционные базы данных
3
3.4
3.22
Проблемы, возникающие при работе с текущим отношением:
Дублирование информации
о фамилиях сотрудников.
Аномалии вставки (INSERT):
Отсутствуют
Аномалии обновления (UPDATE):
При необходимости изменить фамилию
сотрудника,
нужно провести изменения в нескольких местах.
Аномалии удаления (DELETE):
Отсутствуют.
Слайд 42Реляционные базы данных
3
3.4
3.23
Нормализация до уровня нормальной формы Бойса Кодда
Сотрудник
Сотрудник проекта
В
каждой из новых сущностей потенциальный ключ один, следовательно нарушения НФБК
нет. Данный потенциальный ключ выбирается в качестве первичного ключа.
Слайд 43Реляционные базы данных
3
3.4
3.24
Сравнение сильно и слабо нормализованных отношений
Слайд 44Реляционные базы данных
3
3.4
3.25
Сравнение сильно и слабо нормализованных отношений
Операция выборки, -
одна из основных операций в БД, так как ИС на
основе БД предполагают использование данных для проведения аналитики и построения отчетов.
В связи с этим на практике, как правило, проводят денормализацию сущностей для увеличения скорости операций построения отчетов.
Один из пунктов денормализации, - включение вычисляемых полей в сущности.
Слайд 45Системы управления базами данных
Требования к СУБД:
Наличие стандартизованных средств проектирования структуры
БД, устойчивой к проблемам хранения информации.
Наличие стандартизованных средств построения запросов
и манипулирования данными.
Обеспечение вопросов безопасности и надежности
Высокая производительность и поддержка хранения больших объемов информации.
Масштабируемость системы.
.
4.1
Слайд 46Средства построения запросов
Запросы на получение и манипуляцию данными.
Доступ к данным
разрешен только путем исполнения текстовых запросов на языку SQL.
Язык SQL
является языком декларативного программирования (мы описываем результат, а не последовательность действий, приводящих к его получению).
Все СУБД поддерживают начальную часть SQL92 и дополнительные несовместимые расширения SQL.
Microsoft: Transact SQL
Oracle: PL/SQL
IBM: DB2 SQL
4.2
Слайд 47Свойства операций над базой данных
Проблема №1.
Вставка нового клиента (№ Клиента:13,
ФИО:Сидоров,
Дата рождения: 11.03. 1982)
Клиент
4.3
Слайд 48Свойства операций над базой данных
НЕПРОТИВОРЕЧИВОСТЬ (CONSISTENCY)
Целостным состоянием БД называется состояние
при
котором выполняются все явные и неявные ограничения.
Все операции должны переводить
базу данных из одного
целостного состояния в другое.
Операции, нарушающие целостность БД не фиксируются
(т.е. результаты их выполнения не сохраняются в БД).
4.4
Слайд 49Свойства операций над базой данных
Проблема № 2.
4.5
Счет
Операция начисления зарплаты:
1. Счет
№2. Сумма := Сумма + 3500
СБОЙ
Слайд 50Свойства операций над базой данных
ДОЛГОВЕЧНОСТЬ (DURABILITY)
Если операция закончилась успешно, то
результаты
ее выполнения должны быть зафиксированы в БД
вне зависимости
от последующих аппаратных
или программных сбоев.
2
Операция начисления зарплаты:
1. Счет №2. Сумма := Сумма + 3500
2. Сохранение результата в БД.
3. Подтверждение успешности выполнения операции
.
СБОЙ
Слайд 51Свойства операций над базой данных
4.6
Счет
Операция перевода денег клиентом № 13
с долларового счета в евро:
1. Счет № 1. Сумма :=
Сумма — 5000
2. Новая_Сумма_в Евро := Конвертация 5000 долларов в евро.
СБОЙ
3. Счет №3. Сумма =Сумма + Новая_Сумма_в Евро.
Проблема №3
Слайд 52Свойства операций над базой данных
АТОМАРНОСТЬ (ATOMICITY)
Атомарный блок операций должен выполнится
целиком.
Если в ходе выполнения произошла ошибка или сбой, то
результаты
всех операций блока должны быть отклонены
4.7
1. Начать атомарный блок.
2. Счет № 1. Сумма := Сумма — 5000
3. Новая_Сумма_в Евро := Конвертация 5000 долларов в евро.
СБОЙ
4. Счет №3. Сумма =Сумма + Новая_Сумма_в Евро.
5. Завершить атомарный блок.
Слайд 53Свойства операций над базой данных
4.8
Счет
Проблема №4
Операция снятия денег со счета:
1.
Начать атомарный блок
2. Счет №2.Сумма = Сумма - 1000
.
.
.
Ошибка.
Отмена атомарного блока.
.
.
N. Конец атомарного блока
Операция снятия денег со счета:
1. Начать атомарный блок
.
.
i. Счет №2.Сумма = Сумма - 300
.
.
.
N. Конец атомарного блока
Слайд 54Свойства операций над базой данных
ИЗОЛИРОВАННОСТЬ (ISOLATION)
Результат выполнения операций не должен
зависеть
от графика выполнения операций.
4.9
График выполнения операций — расположение операций
на временной шкале по времени выполнения
Операция 1
Операция j
Операция j+1
t
Слайд 55Свойства операций над базой данных
ТРАНЗАКЦИЯ
4.10
Единица работы в БД, объединяющая набор
операций,
гарантирующая соблюдение принципов атомарности,
непротиворечивости, изоляции и долговечности работы
операций.
Транзакция – это последовательность команд SQL, которые БД обрабатывает как единое целое (Все результаты транзакции или целиком сохраняются (фиксируются), или.целиком отменяются (откатываются назад))
ACID
Atomicity Consistency Isolation Durability
SQL
BEGIN TRANSACTION — начать транзакцию
COMMIT — зафиксировать работу транзакции
ROLLBACK — откатить транзакцию (отменить транзакцию)
Слайд 56Системы управления базами данных
Требования к СУБД:
Наличие стандартизованных средств проектирования структуры
БД, устойчивой к проблемам хранения информации.
Наличие стандартизованных средств построения запросов
и манипулирования данными.
Обеспечение вопросов безопасности и надежности
Высокая производительность и поддержка хранения больших объемов информации.
Масштабируемость системы.
.
5.1
Слайд 57Безопасность баз данных
5.2
СУБД
База Данных
Информационная система на основе базы данных
База Данных
База
Данных
Клиентское ПО
Клиентское ПО
Сеть
Клиентское ПО
Слайд 58Безопасность баз данных
5.3
Контроль доступа (Access Control)
Информационная система предназначена для работы
различных категорий пользователей (от операторов ввода данных до генерального директора).
Каждая
категория пользователей имеет определенный уровень доступа к информации.
Создание пользователей(users) и ролей(roles) в терминологии
СУБД позволяет разграничить доступ к данным.
Разграничение доступа ведется на уровне выдачи привилегий на выполнение CRUD операций (Create Read Update Delete) для каждого объектов БД (таблицы, схемы, процедуры и т.д.)
Слайд 59Безопасность баз данных
5.4
Аутентификация (Autentification)
Логин и пароль как средства подтверждения факта,
что текущий клиент действительно является
зарегистрированными пользователем БД.
Хранение паролей, даже
в зашифрованном виде является
плохой практикой. Вместо пароля хранится хеш пароля.
Хеш — односторонняя функция, не позволяющая восстановить
значение аргумента по результату работы.
(MD5, SHA-2, ГОСТ Р 31.11-94)
Пользователи клиентского ПО должны быть сопоставлены
с зарегистрированными пользователями БД и ролями.
Слайд 60Безопасность баз данных
3
Шифрование (Encryption)
Данные физически хранятся в файле доступ к
которому регламентируется
средствами ОС и лежит вне области контроля СУБД.
(Уязвимости
несанкционированного чтения и модификации данных)
Шифрование физического представления данных позволяет
частично снизить зависимость от защищенности ОС.
Контроль доступа отвечает только за доступ через стандартные средства
СУБД (SQL запросы).
Шифрование не должно использоваться как средство контроля доступа.
Основные алгоритмы: 3DES, AES и их вариации.
Возможно использование как симметричных,
так и ассиметричных протоколов
Слайд 61Безопасность баз данных
5.5
Аудит (Auditing)
Администратор базы данных (Database Administrator, DBA),
-
человек с очень высоким уровнем доступа к базе данных.
Максимально возможный
доступ к БД является необходимым
для работы администратора, однако сильно снижает
защищенность системы
Человек, - самое уязвимое звено любой системы безопасности
Подсистема аудита фиксирует действия всех пользователей и
является средством с доступом только на чтение для
администратора БД.
Слайд 63Модели данных
6.2
ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
Слайд 66Модели данных
6.5
Трехуровневая архитектура ANSI/SPARC
ANSI – American National Standard Institute,
SPARC
– Standards Planning and Requirements Committee
Слайд 67Модели данных
6.6
Общая характеристика моделей данных
Модель данных – это интегрированный набор понятий
для описания данных, связей между ними и ограничений, накладываемых на
данные в некоторой организации.
МОДЕЛЬ ДАННЫХ
Сильно типизированные
Слабо типизированные
Компоненты:
категория
свойства категории
связи между категориями
Схема:
ВОДИТЕЛЬ (Имя, Возраст, Стаж работы)
АВТОМОБИЛЬ (Модель, Гос. номер, Дата приобретения)
УПРАВЛЯЕТ (ВОДИТЕЛЬ, АВТОМОБИЛЬ)
Слайд 68Модели данных
6.7
Множества: домены, атрибуты
Множество – это собрание правильно идентифицированных объектов, удовлетворяющих
правилу принадлежности
МНОЖЕСТВО
Интенсионал(intentional)
Экстенсионал
{2, 8, 16, 46}, {12, 10, 8,
100, 32}, {2, 4, 8, 16, 32, 64}
{2, 4, 8, 16, 32, 64}
Домены – это множества, элементы которых более или менее однородны.
Слайд 69Модели данных
6.7
Множества: домены, атрибуты
Атрибуты – это именованные домены, представляющие семантически значимые
объекты.
Атрибуты определяются на доменах и представляют собой интенсионал именованного домена.
Значения атрибута – это экстенсионалы.
Слайд 70Модели данных
6.8
Отношения: сущности
Агрегат, построенный на множествах, определяется как отношение
Пусть
дана некоторая совокупность доменов D1, D2, …, Dm, не обязательно
различных. Отношение, определенное на доменах D1, D2, …, Dm, есть множество упорядоченных кортежей
, таких, что d1 ∈ D1, d2 ∈ D2, …, dm ∈ Dm.
Слайд 71Модели данных
6.8
Отношения: сущности
Пример:
Даны множества:
D1 = {d1i | d1i –
строчная буква английского алфавита} – интенсионал множества, его экстенсионал, например,
{a, b, c, d, e}
D2 = {d2j | d2j – десятичная цифра} – интенсионал множества, его экстенсионал,
например, {1, 3, 5}
Определим на этих доменах отношение R:
R = {
| d1i ∈ D1, d2j ∈ D2} – интенсионал отношения; задает двух символьные кортежи, в которых первый символ – буква, второй – десятичная цифра. Экстенсионалом данного отношения может быть конкретное множество R1 = {, , }.
R1
Слайд 72Модели данных
6.8
Отношения: сущности
Степень отношения (или арность кортежа) – характеристика, относящаяся
к интенсионалу отношения; количество образующих данное отношение множеств.
Мощность отношения –
характеристика, относящаяся к экстенсионалу отношения; количество элементов в конкретной реализации отношения
Слайд 73Модели данных
6.8
Отношения: сущности
Схема отношения – это именованный список пар
атрибута>:, имя которого задает имя отношения: R(A1:D1, A2:D2, …,
Am:Dm).
Слайд 74Модели данных
6.9
Отношения: связи
Агрегат, построенный на других отношениях, рассматривается как связь между
этими отношениями
R = { | s1i ∈ S1,
s2j ∈ S2}
Два отображения:
прямое – R : S1 ? S2
обратное – R-1 : S2 ? S1
Кардинальное число отображения определяется количеством элементов одного множества, связанных с одним элементом другого множества.
R ( S1 (m1, n1) : S2 (m2, n2 ) )
каждый элемент из S1 связан минимум с m2, максимум с n2 элементами из S2,
каждый элемент из S2 связан минимум с m1, максимум с n1 элементами из S1.
Слайд 75Модели данных
6.9
Отношения: связи
Минимальное и максимальное кардинальные числа не определены:
R (
S1 ( 0, ∞ ) : S2 (0, ∞ )
), или R ( S1 : S2 ).
Типы отображений:
Рис. 1. Полностью определенное отображение на S1
R ( S1 ( 0, ∞ ) : S2 (1, ∞ ) )
Рис. 2 Неполное функциональное отображение
R ( S1 ( 0, ∞ ) : S2 ( 1, 1 ) )
Рис. 2. Полное функциональное отображение
( S1 ( 0, ∞ ) : S2 ( 0, 1 ) )
Связи, для которых хотя бы одно отображение является функциональным (полным или неполным), часто называют связями типа 1 : n, или «один ко многим». Связи, в которых оба отображения являются нефункциональными, называют связями типа n : n, или «многие ко многим».
Слайд 76Модели данных
6.9
Общая характеристика ограничений целостности
Структурными компонентами модели данных являются отношения и
связи между ними;
Отношения задаются своими схемами;
Схема отношения определяется через атрибуты,
определенные на доменах.
Логические ограничения, накладываемые на данные, называются ограничениями целостности.
Ограничения целостности реализуется средствами языка описания ограничений (ЯОО, или CDL – Constraints Definition Language)
Слайд 77Реляционная модель данных
7.1
Реляционная модель данных
Реляционная модель данных (РМД) была разработана сотрудником
IBM Э.Ф. Коддом (E.F. Codd) в 1969-70 г.г. на основе
математической теории отношений.
Реляционная модель данных
Структурная и целостная части
Манипуляционная часть
Язык описания данных (ЯОД)
Data Definition Language (DDL)
Язык манипулирования данными (ЯМД)
Data Manipulation Language (DML)
Особенности реляционной модели данных:
определена манипуляционная часть – конкретный набор операций, функциональные возможности,
имеются конкретные языки описания данных, ограничений, накладываемых на данные, и манипулирования данными,
современные реляционные СУБД используют единый язык – SQL, в котором объединены и ЯОД, и ЯМД.
Слайд 78Реляционная модель данных
7.2
Базовые структурные компоненты реляционной модели данных
Домены и атрибуты
Отношения
Связи
Домен –
множество элементов одного типа.
Пример:
Простой домен: ГОД = {1985,
2003, 2000}; ДЕНЬГИ = {500, 1000, 850}
Составной домен: ИСТОРИЯ ЗАРПЛАТЫ = {{<1985, 500>, <2000, 1000>}, {<2000, 850>}, {<1985, 850>, <2000, 500>, <2003, 1000>}}
Пусть дана совокупность множеств D1, D2, …, Dn, не обязательно различных.
Тогда отношение R, определенное на этих множествах, есть множество упорядоченных кортежей таких, что di ∈ Di для каждого i из [1:n].
В реляционной модели данных множества Di представляют собой домены.
Слайд 79Реляционная модель данных
7.2
Базовые структурные компоненты реляционной модели данных
Пример:
Даны два домена
Слайд 80Реляционная модель данных
7.2
Базовые структурные компоненты реляционной модели данных
В задании схемы отношения
могут использоваться и составные домены.
Пример, реализации (экстенсионал) отношения СОТРУДНИК :
Нормализованное отношение – это отношение, в котором каждое значение атрибутов является атомарным.
В данном примере значением одного элемента составного домена является множество пар вида<ГОД, ДЕНЬГИ>
Слайд 81Реляционная модель данных
7.2
Базовые структурные компоненты реляционной модели данных
Нормализация: составной домен заменяется
составляющими его простыми доменами, а в реализации отношения значения атрибутов,
определенных на других доменах, повторяются для каждого кортежа составного домена
Слайд 82Реляционная модель данных
7.2
Свойства реляционной модели данных
Каждый атрибут отношения имеет уникальное в
данном отношении имя.
Каждый атрибут определен на каком-то одном домене.
На одном
и том же домене может быть определено несколько атрибутов.
Имя атрибута может совпадать с именем домена.
Порядок следования атрибутов не устанавливается.
В отношении нет совпадающих кортежей (каждый кортеж уникален).
Порядок следования кортежей не устанавливается.
Отношение имеет имя, которое в схеме базы данных отличается от имен всех других отношений.
Слайд 83Реляционная модель данных
7.3
Представление сущности
Представление сущности означает возможность уникальной идентификации каждого отдельного
кортежа отношения по значениям его атрибутов
Ключ – это совокупность
атрибутов, которая однозначно идентифицирует каждый кортеж данного отношения.
Первичный ключ (PK – Primary Key) – не избыточный набор атрибутов, значения которых однозначно определяют кортеж отношения.
Первичный ключ не избыточен, если:
состоит из одного атрибута,
состоит из нескольких атрибутов, но ни один из этих атрибутов не является лишним для однозначной идентификации каждого кортежа.
Слайд 84Реляционная модель данных
7.3
Представление сущности
Отношение может иметь только один первичный ключ.
Если
в отношении можно выделить несколько наборов атрибутов для первичного ключа,
выбирается один, остальные определяются как альтернативные (AK – Alternate Key).
Пример отношения:
КАФЕДРА ( Номер кафедры, Название )
Номер кафедры – PK
Название - AK
Слайд 85Реляционная модель данных
7.3
Связи
Связи между сущностями отражают взаимосвязи между конкретными экземплярами сущностей.
Эти взаимосвязи представляются с помощью внешних ключей
Внешний ключ (FK
– Foreign Key) – это атрибут или некоторое множество атрибутов отношения R1, которые не являются собственными атрибутами отношения R1, но их значение совпадает со значениями первичного ключа некоторого отношения R2 (возможность идентичности R1 и R2 не исключается).
Основными типами связей между сущностями являются: 1 : n и n : n
Слайд 86Реляционная модель данных
7.3
Связи
Пример, есть отношения:
СОТРУДНИК с атрибутами Номер сотрудника (первичный ключ),
Имя и Год рождения
ОТДЕЛ с атрибутами Номер отдела (первичный ключ)
и Название.
Слайд 87Реляционная модель данных
7.3
Связи
Схемы отношений:
ОТДЕЛ ( Номер отдела, Название (АК) )
СОТРУДНИК (
Номер сотрудника, Имя, Год рождения, Номер отдела (FK) )
ОТДЕЛ
СОТРУДНИК
Слайд 88Реляционная модель данных
7.3
Связи
Представление связи 1:n в IDEF1X:
Слайд 89Реляционная модель данных
7.3
Связи
Пример, есть отношения:
ПОСТАВЩИК с атрибутами Номер поставщика (первичный ключ),
Имя и Адрес, и отношение ДЕТАЛЬ с атрибутами Номер детали
(первичный ключ), Название и Цена.
Слайд 90Реляционная модель данных
7.3
Связи
Схемы отношений :
ПОСТАВЩИК ( Номер поставщика, Имя, Адрес )
ДЕТАЛЬ
( Номер детали, Название, Цена )
ПОСТАВКА ( Номер поставщика (FK1),
Номер детали (FK2), Количество )
Поставщик
Деталь
Поставка
Слайд 91Реляционная модель данных
7.3
Связи
Представление и разрешение связи n:n в IDEF1X:
Слайд 92Реляционная модель данных
7.4
Ссылочная целостность
Пример отношения:
ОТДЕЛ ( Номер отдела, Название (АК) )
СОТРУДНИК
( Номер сотрудника, Имя, Год рождения, Номер отдела (FK) )
Требование
ссылочной целостности: значение атрибута внешнего ключа в любом кортеже дочернего отношения должно соответствовать значению атрибута первичного ключа в некотором кортеже родительского отношения.
Слайд 93Реляционная модель данных
7.4
Языковые средства описания данных
Язык определения данных (DDL) для реляционной
модели данных включает следующие возможности:
создание домена,
создание отношения,
определение ограничений целостности.
Соответствие между
компонентами РМД и элементами базы данных
Слайд 94Реляционная модель данных
7.4
Типы ограничений целостности
Основные предложения DDL(ЯОД):
CREATE тип_объекта – создать
соответствующий объект базы данных,
ALTER тип_объекта – изменить соответствующий объект базы
данных,
DROP тип_объекта – удалить указанный объект базы данных.
Слайд 95Реляционная модель данных
7.4
Способы именования объектов
Идентификаторы
Обычный идентификатор
Идентификатор с ограничителями
Текст заключен в двойные
кавычки. Чувствительны к регистру, можно использовать зарезервированные слова.
Примеры: ”WKLY-SAL”
”Department Name” ”UNION”
Последовательность букв, цифр и символов подчеркивания (_), начинающаяся с буквы. Не чувствителен к регистру. Не совпадает с зарезервированными словами.
Примеры: A12 Tab_Name
DeptID
Слайд 96Реляционная модель данных
7.4
Типы данных
Числовые - используются для представления целых, вещественных и
десятичных чисел.
Слайд 97Реляционная модель данных
7.4
Типы данных
Строковые типы данных используются для представления символьных строк
Типы данных дата – время используются для представления даты и
времени
Слайд 98Реляционная модель данных
7.4
Основные операции
Операция конкатенации (CONCAT или || или +) -
можно использовать с операндами строкового типа. Операция выполняет сцепление двух
строковых операндов и образует строковое выражение.
Арифметические операции можно использовать с операндами числовых типов.
Бинарные операции (/, *, +, -) определяют сложение, вычитание, умножение и деление, соответственно
Операции над датой и временем. Значения даты и времени можно увеличивать, уменьшать и вычитать. Эти операции могут включать десятичные числа – продолжительность. Продолжительность – это число, представляющее интервал времени.
Слайд 99SQL
8.0
Создание таблиц
CREATE TABLE имя_таблицы
(
имя_колонки тип_данных [ограничение_обязательности] [ограничение_целостности_на_колонку] [спецификация_генерируемого_значения]
[, …]
[, ограничение_целостности_на_таблицу]
[, …
]
)
имя_таблицы – идентификатор, задает имя таблицы;
имя_колонки – идентификатор, уникальный в
пределах данной таблицы;
тип_данных – тип данных для колонки;
ограничение_обязательности – задает ограничение обязательности значения данной колонки;
ограничение_целостности_на_колонку – ограничение целостности, накладываемое на данную колонку;
Слайд 100SQL
8.0
Создание таблиц
ограничение_целостности_на_таблицу – ограничение целостности, накладываемое на одну или несколько
колонок создаваемой таблицы.
генерируемое_значение – значения по умолчанию, если в операции
вставки значение данной колонки не указано
Ограничения целостности:
[CONSTRAINT имя_ограничения] ограничение
имя_ограничения – задает имя ограничения. Уникально в пределах данной таблицы;
ограничение – задает конкретное ограничение целостности.
Слайд 101SQL
8.0
Создание таблиц. Правила задания ограничений
Ограничения обязательности
NULL
NOT NULL
Ограничения уникальности( всегда Not
Null)
UNIQUE
PRIMARY KEY
Ограничение уникальности на колонку : UNIQUE или PRIMARY KEY.
Ограничение уникальности на таблицу : UNIQUE(имя_колонки, …) или PRIMARY KEY(имя_колонки, …).
UNIQUE – определяет альтернативный ключ, может быть несколько
PRIMARY KEY – определяет первичный ключ, может быть только одно
Слайд 102SQL
8.0
Создание таблиц. Правила задания ограничений
Ограничение допустимости значений
CHECK(условие)
Условие, записанное в ограничении
на колонку, может содержать имя только данной колонки;
Условие, записанное в
ограничении на таблицу, может содержать любые (одно или более) имена колонок из данной таблицы.
Условие
Предикаты:
BETWEEN, IN, LIKE
Результат предиката:
TRUE, FALSE, NULL
Логические операции:
NOT, AND, OR
Слайд 103SQL
8.0
Создание таблиц. Правила задания ограничений
Правила вычисления логических операций
Слайд 104SQL
8.0
Создание таблиц. Правила задания ограничений
Основной предикат:
выражение операция_отношения выражение
операции_отношения: операции =
(равно), (не равно), < (меньше), > (больше),
или равно), >= (больше или равно).
Предикат BETWEEN
выражение1 [NOT] BETWEEN выражение2 AND выражение3
должно выполняться соотношение: выражение2 ≤ выражение3
Пример:
выражение1 BETWEEN выражение2 AND выражение3,
тоже самое что и:
выражение1 >= выражение2 AND выражение1 <= выражение3.
Слайд 105SQL
8.0
Создание таблиц. Правила задания ограничений
Предикат IN
выражение [NOT] IN (список_выражений)
список_выражений -
перечисление выражений через запятую в произвольном порядке
Результат вычисления IN:
«истина», если
значение выражения совпадает хотя бы с одним значением из списка;
«ложь», если значение выражения не совпадает ни с одним значением из списка, и в списке нет неопределенных(NULL) значений;
не определено(NULL), если значение выражения не совпадает ни с одним значением из списка, и в списке есть неопределенные значения.
Результат значения NOT IN противоположен IN.
Слайд 106SQL
8.0
Создание таблиц. Правила задания ограничений
Предикат LIKE
выражение [NOT] LIKE шаблон [ESCAPE
escape-символ]
Предикат LIKE проверяет, соответствует ли строка, являющаяся результатом вычисления выражения,
заданному шаблону.
Результат вычисления LIKE :
«истина», если значение выражения удовлетворяет шаблону,
«ложь», если не удовлетворяет,
не определено, если хотя бы один из аргументов имеет значение NULL
Результат значения NOT LIKE противоположен LIKE.
Шаблон это строка использующая специальные метасимволы:
_ (символ подчеркивания) – соответствует одному (любому) символу,
% – соответствует любой (возможно, пустой) цепочке символов.
Слайд 107SQL
8.0
Создание таблиц. Правила задания ограничений
Ссылочное ограничение
На колонку:
REFERENCES имя_родительской_таблицы [(имя_колонки_PK, …)]
[ON DELETE правило_удаления] [ON UPDATE правило_обновления]
На таблицу :
FOREIGN KEY (имя_колонки_FK,
…) REFERENCES имя_родительской_таблицы [(имя_колонки_PK, …)] [ON DELETE правило_удаления] [ON UPDATE правило_обновления]
имя_колонки_FK – имена колонок внешнего ключа в создаваемой (дочерней) таблице. Порядок перечисления принципиален;
имя_родительской_таблицы – имя родительской таблицы, на которую ссылается создаваемая дочерняя таблица;
имя_колонки_PK – имена колонок первичного ключа в родительской таблице.
Слайд 108SQL
8.0
Создание таблиц. Правила задания ограничений
Ссылочное ограничение
правило_удаления – определяет, какие действия
должны быть выполнены при удалении записи из родительской таблицы. Допускаются
значения: RESTRICT ИЛИ NOACTION, CASCADE, SET NULL
правило_обновления – определяет, какие действия должны быть выполнены при модификации первичного ключа в родительской таблице. Допускаются значения RESTRICT или NO ACTION
RESTRICT выполняется перед проверкой всех остальных ограничений
NO ACTION выполняется после проверки всех ограничений
Слайд 109SQL
8.0
Создание таблиц. Правила задания ограничений
Спецификация генерируемого значения
Значение по умолчанию
Автоинкрементное значение
DEFAULT значение
IDENTITY [опции]
Опции: начальное значение, шаг, максимальное, минимальное, повторное выполнение
Слайд 110SQL
8.0
Создание таблиц.
Пример:
Схемы отношений :
ПОСТАВЩИК ( Номер поставщика, Имя, Адрес
)
ДЕТАЛЬ ( Номер детали, Название, Цена )
ПОСТАВКА ( Номер поставщика
(FK1), Номер детали (FK2), Количество )
Слайд 111SQL
8.0
Создание таблиц.
Пример:
Схема отношений :
ДЕТАЛЬ ( Номер детали, Название, Цена
)
CREATE TABLE P(
P_ID INT NOT NULL CONSTRAINT P_PK PRIMARY KEY,
--1
PNAME VARCHAR(20) NOT NULL CONSTRAINT P_UQ_01 UNIQUE,--2
PRICE DECIMAL(6,0) NOT NULL CONSTRAINT P_CH_01
CHECK(PRICE > 0) --3
)
1 – ограничения первичного ключа и обязательности значения;
2 – ограничения уникальности и обязательности значения;
3 – условие: значение атрибута должно быть строго положительным.
Слайд 112SQL
8.0
Создание таблиц.
Пример:
Схема отношений :
ПОСТАВЩИК ( Номер поставщика, Имя, Адрес
)
CREATE TABLE S(
S_ID INT NOT NULL,
SNAME VARCHAR(30) NOT NULL,
ADDRESS VARCHAR(80),
CONSTRAINT
S_PK PRIMARY KEY(S_ID) -- 4
)
4 – ограничения первичного ключа на таблицу;
Слайд 113SQL
8.0
Создание таблиц.
Пример:
Схема отношений :
ПОСТАВКА ( Номер поставщика (FK1), Номер
детали (FK2), Количество )
CREATE TABLE SP(
S_ID INT NOT NULL CONSTRAINT
SP_FK_01 REFERENCES S, --5
P_ID INT NOT NULL,
QTY INT NOT NULL CONSTRAINT SP_CH_01 CHECK(QTY > 0),
CONSTRAINT SP_PK PRIMARY KEY(S_ID, P_ID), --6
CONSTRAINT SP_FK_02 FOREIGN KEY(P_ID) REFERENCES P --7
)
5 – внешний ключ(ограничения на колонку)
6 – ограничение первичного ключа(ограничение на таблицу)
7 –определяется внешний ключ (ограничение на таблицу).
Слайд 114SQL
8.0
Удаление и модификация таблиц.
DROP TABLE имя_таблицы – удаление таблицы
ALTER
TABLE имя_таблицы операция [операция …]
Модификация таблиц
Операции:
Добавление новых колонок:
ADD [
COLUMN ] определение_колонки
определение_колонки тоже что и в CREATE TABLE
Пример:
ALTER TABLE EQUIPMENT
ADD COLUMN Equip_QTY SMALLINT
NOT NULL WITH DEFAULT 1
Слайд 115SQL
8.0
Удаление и модификация таблиц.
Операции:
Изменение характеристик колонок:
ALTER COLUMN имя_колонки
тип_данных
Примеры:
ALTER TABLE EQUIPMENT ALTER COLUMN Equip_Desc VARCHAR(50) – изменится длину
строки в колонке на 50
ALTER TABLE EQUIPMENT ALTER COLUMN имя_колонки DROP DEFAULT – удаляет установленное для колонки текущее значение по умолчанию;
ALTER COLUMN имя_колонки DROP IDENTITY – удаляет для указанной колонки установленный для нее атрибут автоинкрементного значения.
Слайд 116SQL
8.0
Удаление и модификация таблиц.
Операции:
Добавление ограничений целостности:
ADD [CONSTRAINT имя_ограничения]
ограничение
Ограничение задается точно так же, как и табличное ограничение в
предложении CREATE TABLE
Пример1:
ALTER TABLE EQUIPMENT
ADD CONSTRAINT DeptQuip
FOREIGN KEY(Equip_Owner)
REFERENCES DEPT
ON DELETE SET NULL
Слайд 117SQL
8.0
Удаление и модификация таблиц.
Пример2:
ALTER TABLE EMPLOYEE
ADD CONSTRAINT
Revenue
CHECK(Salary + Comm > 30000)
Удаление ограничений
целостности
DROP тип_ограничения имя_ограничения
тип_ограничения: FOREIGN KEY, UNIQUE, CHECK, CONSTRAINT
Пример:
ALTER TABLE EMPLOYEE
DROP CONSTRAINT Revenue
Слайд 118SQL
9.0
Предложения языка манипулирования данными
Предложение INSERT
INSERT INTO имя_таблицы [(имя_колонки, …)] VALUES
(значение, …), (…), …
имя_таблицы –указывает существующую таблицу базы данных, в
которую вставляются новые значения (строки).
(имя_колонки, …) – указывает имена колонок, для которых в данном предложении представляются значения.
Свойства:
Одно и то же имя колонки не должно указываться дважды;
Если список имен колонок опущен, порядок колонок определяется в соответствии с CREATE TABLE;
Для неуказанных колонок определяется атрибут NULL или DEFAULT;
Слайд 119SQL
9.0
Предложения языка манипулирования данными
Предложение INSERT
Свойства:
Количество значений, указанных в каждой строке,
должно соответствовать явному или неявному списку имен колонок;
Тип вставляемых значений
должен соответствовать типу соответствующих им колонок
Строки, добавляемые в таблицу, получены в результате запроса:
INSERT INTO имя_таблицы [(имя_колонки, …)] запрос
Количество колонок в результате выполнения запроса должно совпадать с количеством колонок, указанным (явно или неявно) в списке.
Слайд 120SQL
9.0
Предложения языка манипулирования данными
Предложение INSERT
Пример1:
1) INSERT INTO DEPARTMENT
VALUES (’E31’, ’ARCHITECTURE’,
’00390’, ’E01’);
2) INSERT INTO DEPARTMENT (DeptNo, DeptName, AdmrDept)
VALUES (’E31’, ’ARCHITECTURE’,
’E01’);
3) INSERT INTO DEPARTMENT
VALUES (’E31’, ’ARCHITECTURE’, NULL, ’E01’)
Слайд 121SQL
9.0
Предложения языка манипулирования данными
Предложение INSERT
Пример1:
4) INSERT INTO DEPARTMENT (DeptNo, DeptName, AdmrDept)
VALUES (’B11’, ’PURCHASING’, ’B01’),
(’E41’, ’DATABASE ADMINISTRATION’, ’E01’)
Слайд 122SQL
9.0
Предложения языка манипулирования данными
Предложение INSERT
Пример2:
CREATE TABLE MA_EMP_ACT (
EmpNo CHAR(6)
NOT NULL,
ProjNo CHAR(6) NOT NULL,
ActNo SMALLINT NOT NULL,
EmpTime DEC(5,2),
EmStDate DATE,
EmEnDate DATE )
INSERT INTO MA_EMP_ACT
SELECT * FROM EMP_ACT
WHERE ProjNo LIKE ’MA%’
Слайд 123SQL
9.0
Предложения языка манипулирования данными
Предложение DELETE
DELETE FROM имя_таблицы [WHERE условие_поиска]
имя_таблицы –
должно указывать существующую таблицу базы данных.
условие_поиска – определяет условие
отбора удаляемых строк
Свойства:
В условии поиска в конструкции WHERE могут быть использованы только колонки таблицы, указанной в предложении DELETE;
Условие поиска применяется к каждой строке таблицы, и удаляются те строки, для которых результатом условия поиска является значение true;
При удалении строк из родительской таблицы проверяются ограничения ссылочной целостности;
Если при выполнении DELETE, возникла ошибка, никакие изменения в базе данных не происходят
Слайд 124SQL
9.0
Предложения языка манипулирования данными
Предложение DELETE
Примеры
Пример 1. Удалить из таблицы DEPARTMENT
отдел с номером (DeptNo) ‘D11’
DELETE FROM DEPARTMENT
WHERE DeptNo
= ’D11’
Пример 2. Удалить из таблицы DEPARTMENT все строки.
DELETE FROM DEPARTMENT
Пример 3. Удалить из таблицы EMPLOYEE сотрудников, выполняющих операции SALESREP или FIELDREP, кто не выполнял продажи в 1995 г.
DELETE FROM EMPLOYEE
WHERE Job IN (’SALESREP’,’FIELDREP’)
AND
LastName NOT IN (SELECT Sales_Person
FROM SALES
WHERE YEAR(Sales_Date)=1995)
Слайд 125SQL
9.0
Предложения языка манипулирования данными
Предложение UPDATE
UPDATE имя_таблицы SET имя_колонки = значение,
… [WHERE условие_поиска]
имя_таблицы – должно указывать имя существующей таблицы
базы данных
Конструкция SET определяет, какие колонки таблицы и каким образом изменяют свои значения.
имя_колонки – указывает колонку, значение которой должно быть модифицировано.
значение – указывает новое значение колонки.
условие_поиска – условие, определяющее, какие строки должны быть модифицированы
Слайд 126SQL
9.0
Предложения языка манипулирования данными
Предложение UPDATE
Свойства:
В условии поиска в конструкции WHERE
могут быть использованы только колонки таблицы, указанной в предложении UPDATE;
Условие
поиска применяется к каждой строке таблицы, и модифицируются те строки, для которых результатом условия поиска является значение true;
Все ограничения проверяются, и если хотя бы одно из них будет нарушено, соответствующая таблица изменена не будет, а предложение UPDATE завершится с ошибкой.
Слайд 127SQL
9.0
Предложения языка манипулирования данными
Предложение UPDATE
Примеры
Пример 1.
UPDATE EMPLOYEE
SET
JOB = ’LABORER’
WHERE EMPNO = ’000290’
Пример 2.
UPDATE
PROJECT
SET PRSTAFF = PRSTAFF + 1.5
WHERE DEPTNO = ’D21’
Пример 3. Для всех сотрудников, кроме менеджера отдела (WORKDEPT) ‘E21’, были сделаны временные переназначения. Установить в таблице EMPLOYEE должность (JOB) соответствующих сотрудников в NULL и их оплату (SALARY, BONUS, COMM) в 0.
UPDATE EMPLOYEE
SET JOB=NULL, SALARY=0, BONUS=0, COMM=0
WHERE WORKDEPT = ’E21’ AND JOB <> ’MANAGER’