Базы данных

Содержание

Слайд 2

Понятие информации Зарплата будет выдана 25 сентября. Бухгалтерия. 1 Понятие информации 1.1

Понятие информации

Зарплата будет выдана 25 сентября.
Бухгалтерия.

1

Понятие информации

1.1

Слайд 3

1.3 Понятие информации ИНФОРМАЦИЯ СЕМАНТИКА ПРЕДСТАВЛЕНИЕ Въезд запрещен 1

1.3

Понятие информации

ИНФОРМАЦИЯ

СЕМАНТИКА

ПРЕДСТАВЛЕНИЕ

Въезд запрещен

1

Слайд 4

1.4 Понятие информации ИНФОРМАЦИЯ: Сущность обеспечивающая повышение знаний об окружающем мире

1.4

Понятие информации

ИНФОРМАЦИЯ:
Сущность обеспечивающая повышение знаний об окружающем мире ее получателем.
ОЦЕНКА КАЧЕСТВА

ИНФОРМАЦИИ:
- Достоверность.
- Интерпретируемость.

1

Слайд 5

1.5 Проблемы, возникающие при работе с информацией Рассинхронизация семантики и представления.

1.5

Проблемы, возникающие при работе с информацией

Рассинхронизация семантики и представления.

Слайд 6

1.6 Проблемы, возникающие при работе с информацией Поддержка ограничений реального мира

1.6

Проблемы, возникающие при работе с информацией

Поддержка ограничений реального мира

Слайд 7

1.7 Проблемы, возникающие при работе с информацией Дублирование информации, как источник рассинхронизации

1.7

Проблемы, возникающие при работе с информацией

Дублирование информации, как источник рассинхронизации

Слайд 8

1.8 Понятие информации Проблемы, возникающие при хранении информации : Рассинхронизация семантики

1.8

Понятие информации

Проблемы, возникающие при хранении информации :
Рассинхронизация семантики и представления .
Поддержка

ограничений реального мира.
Дублирование информации, как источник рассинхронизации.
Слайд 9

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

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

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

2.1

Слайд 10

Системы управления базами данных 2.2 СУБД?

Системы управления базами данных

2.2

СУБД?

Слайд 11

Системы управления базами данных 2.3 Система управления базами данных. Отделение семантики

Системы управления базами данных

2.3

Система управления базами данных.
Отделение семантики данных от представления.

Хранение
метаданных о семантике данных:
Сотрудник
Наличие встроенного языка для семантического поиска данных
(язык построения запросов):
Вывести ФИО сотрудников с зарплатой больше 30 тыс. руб.
Слайд 12

Системы управления базами данных 2.4 СУБД База Данных Информационная система на

Системы управления базами данных

2.4

СУБД

База Данных

Информационная система на основе базы данных

База Данных

База

Данных

Клиентское ПО

Клиентское ПО

Сеть

Слайд 13

Системы управления базами данных Разработчик баз данных. Задачи: Проектирование структуры БД,

Системы управления базами данных

Разработчик баз данных.
Задачи:
Проектирование структуры БД, реализация БД в

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

2.5

Слайд 14

Системы управления базами данных Разработчик клиентского ПО. Задачи: Создание внешнего пользовательского

Системы управления базами данных

Разработчик клиентского ПО.
Задачи:
Создание внешнего пользовательского интерфейса для работы

с БД.
Требования к СУБД:
- Удобный станадартизованный доступ к данным.
- Наличие средств построения запросов и манипулирования данными.

2.6

Слайд 15

Системы управления базами данных Администратор БД. Задачи: Обеспечение бесперебойной работы ИС.

Системы управления базами данных

Администратор БД.
Задачи:
Обеспечение бесперебойной работы ИС. Поддержание необходимого QoS.
Требования

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

2.7

Слайд 16

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

Системы управления базами данных

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

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

2.8

Слайд 17

Реляционные базы данных 3 3.4 3.1 Сотрудник 1. Табличное представление данных

Реляционные базы данных

3

3.4

3.1

Сотрудник

1. Табличное представление данных на логическом уровне:
Таблицы
Представление конкретной

сущности из предметной области.
Столбцы
Свойства (атрибуты), описывающие сущность.
Строки
Конкретные экземпляры сущности.
Слайд 18

Реляционные базы данных 3 3.4 3.2 Сотрудник 2. Использование первичных ключей

Реляционные базы данных

3

3.4

3.2

Сотрудник

2. Использование первичных ключей для идентификации экземпляров сущности:
Потенциальный ключ

(Candidate Key)
Минимальный набор атрибутов однозначно идентифицирующих экземпляр сущности.
Первичный ключ (Primary Key)
Один из потенциальных ключей, выбранный для однозначной идентификации сущности.
Суррогатный первичный ключ.
Уникальный аттрибут для идентфикации экземпляра сущности, не имеющий отображения в предметной области
Слайд 19

Реляционные базы данных 3 3.4 3.3 Сотрудник Свойства табличной организации данных.

Реляционные базы данных

3

3.4

3.3

Сотрудник

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

рамках схемы БД.
Имена атрибутов должны быть уникальны в рамках сущности.
Адресация атрибутов допускается только по имени атрибута.
Вывести ФИО Сотрудника
Адресация экземпляров сущности допускается только по значению атрибутов
Найти Сотрудника с ФИО Петров В.В
Слайд 20

Реляционные базы данных 3 3.4 3.4 3. Связь сущностей через миграцию

Реляционные базы данных

3

3.4

3.4

3. Связь сущностей через миграцию первичного ключа:
Внешний ключ (Foreign

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

Отпуск

Слайд 21

Реляционные базы данных 3 3.4 3.5 Свойства организации связей путем миграции

Реляционные базы данных

3

3.4

3.5

Свойства организации связей путем миграции первичного ключа.
Первичный ключ мигрирует

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

Вагон

Место

Слайд 22

Реляционные базы данных 3 3.4 3.6 Правила создания таблиц и связей

Реляционные базы данных

3

3.4

3.6

Правила создания таблиц и связей
Реляционные БД основываются на теории

Эдгара Кодда (Edgar F. Codd), которая впоследствии была развита Кристофером Дейтом (Cristopher J. Date).
В качестве основы разработки послужили три основных принципа:
Независимость от порядка расположения записей в физическом представлении. Необходимо добиться независимости порядка записей в представлении пользователю от порядка расположения записей в физическом представлении.
Независимость от индексирования. Приложения должны оставаться работоспособными при внесении изменений или удаления индексов.
Независимость от пути доступа. Доступ к данным не должен зависеть от их положения в иерархии
Слайд 23

6 5 4 2 Реляционные базы данных 3 3.4 3.7 Правила

 6
     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:

Реляционные базы данных

3

3.4

3

Первая нормальная форма
E. Codd:
Отношение находится в первой нормальной форме

если все его атрибуты являются семантически атомарными.
C. Date:
Отношение находится в первой нормальной форме если оно соответствует следующим условиям:
1) Строки отношения неупорядоченны.
2) Столбцы отношения неупорядочены.
3) Все строки уникальны.
4) Каждая ячейка содержит одно семантически атомарное значение из заданого домена.
Основное различие: Определение Дейта запрещает ячейки с NULL значениями.
Слайд 25

Реляционные базы данных 3 3.4 3.8 Первая нормальная форма Пример нарушения: Нормализация

Реляционные базы данных

3

3.4

3.8

Первая нормальная форма
Пример нарушения:

Нормализация

Слайд 26

Реляционные базы данных 3 3.4 3.9 Первая нормальная форма Пример нарушения

Реляционные базы данных

3

3.4

3.9

Первая нормальная форма
Пример нарушения (если требуется поиск по городам

проживания):

Нормализация

Слайд 27

Реляционные базы данных 3 3.4 3 Функциональная зависимость. Пусть R -

Реляционные базы данных

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 Примеры функциональной зависимости. {Номер телефона,

Реляционные базы данных

3

3.4

3.10

Примеры функциональной зависимости.

{Номер телефона, Номер сотрудника}
→ Телефон

Номер сотрудника

→ ФИО

Номер сотрудника → Дата рождения

Слайд 29

Реляционные базы данных 3 3.4 3.11 Вторая нормальная форма Отношение находится

Реляционные базы данных

3

3.4

3.11

Вторая нормальная форма
Отношение находится во второй нормальной форме если

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

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

Слайд 30

Реляционные базы данных 3 3.4 3.12 Пример нарушения второй нормальной формы

Реляционные базы данных

3

3.4

3.12

Пример нарушения второй нормальной формы

№ Сотрудника → ФИО, № Проекта→ Название 

Функциональные зависимости, нарушающие вторую

нормальную форму :
Слайд 31

Реляционные базы данных 3 3.4 3.13 Проблемы, возникающие при работе с

Реляционные базы данных

3

3.4

3.13

Проблемы, возникающие при работе с текущим отношением:
Дублирование информации о

сотрудника, отделах и проектах.
Аномалии вставки (INSERT):
Нельзя вставить нового сотрудника, пока он не назначен на проект.
Аномалии обновления (UPDATE):
При необходимости изменить название проекта, необходимо изменить его
во всех местах где он встречается.
Аномалии удаления (DELETE):
При удалении информации о проекте удалится информация о сотрудниках
Участвующих только в этом проекте. Аналогичная проблема возникает
при удалении сотрудников, выполняющих определенный проект целиком
Слайд 32

Реляционные базы данных 3 3.4 3 Нормализация до уровня второй нормальной

Реляционные базы данных

3

3.4

3

Нормализация до уровня второй нормальной формы

Сотрудник

Проект
Продолжение схемы на следующем

слайде...
Слайд 33

Реляционные базы данных 3 3.4 3.14 Нормализация до уровня второй нормальной

Реляционные базы данных

3

3.4

3.14

Нормализация до уровня второй нормальной формы (продолжение)

Сотрудник проекта

Выводы:
Рассмотренные выше

аномалии устранены.
Слайд 34

Реляционные базы данных 3 3.4 3.15 Третья нормальная форма Отношение R

Реляционные базы данных

3

3.4

3.15

Третья нормальная форма
Отношение R находится в третьей нормальной форме

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

Транзитивная зависимость.
Если X →Y и Z →X, то зависимость Z→Y называется транзитивной.

Слайд 35

Реляционные базы данных 3 3.4 3.16 Отношение, нарушающее третью нормальную форму.

Реляционные базы данных

3

3.4

3.16

Отношение, нарушающее третью нормальную форму.

Сотрудник

Функциональные зависимости, нарушающие третью нормальную

форму:
№ сотрудника →№ Отдела, №Отдела → Телефон
Зависимость № Сотрудника → Телефон транзитивна.
Слайд 36

Реляционные базы данных 3 3.4 3.17 Проблемы, возникающие при работе с

Реляционные базы данных

3

3.4

3.17

Проблемы, возникающие при работе с текущим отношением:
Дублирование информации об

отделах.
Аномалии вставки (INSERT):
Возможно появление сотрудника с тем же номером отдела,
но с другим телефоном.
Аномалии обновления (UPDATE):
При необходимости изменить телефон отдела, необходимо изменить его
во всех местах где он встречается.
Аномалии удаления (DELETE):
При удалении всех сотрудников, принадлежащих определенному отделу
исчезает информация об отделе.
Слайд 37

Реляционные базы данных 3 3.4 3.18 Нормализация до уровня третьей нормальной

Реляционные базы данных

3

3.4

3.18

Нормализация до уровня третьей нормальной формы

Сотрудник

Отдел
Продолжение схемы на

следующем слайде...
Слайд 38

Реляционные базы данных 3 3.4 3.19 Нормализация до уровня третьей нормальной

Реляционные базы данных

3

3.4

3.19

Нормализация до уровня третьей нормальной формы (продолжение)

Сотрудник отдела

Выводы:
Рассмотренные выше

аномалии устранены.
Слайд 39

Реляционные базы данных 3 3.4 3.20 Нормальная форма Бойса Кодда Отношение

Реляционные базы данных

3

3.4

3.20

Нормальная форма Бойса Кодда
Отношение R находится в нормальной форме

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

Реляционные базы данных 3 3.4 3.21 Поэтому функциональных зависимостей нарушающих 2НФ

Реляционные базы данных

3

3.4

3.21

Поэтому функциональных зависимостей нарушающих 2НФ и 3НФ нет.
Функциональные зависимости нарушающие

форму Бойса Кодда:
№ Сотрудника →ФИО и ФИО → № Сотрудника, т.к их детерминанты не является частью потенциального ключа

Отношение, нарушающее нормальную форму Бойса Кодда.
Сотрудник проекта

В данном отношении два потенциальных ключа: 
{№Сотрудника, № Проекта} и {ФИО, № Проекта}

Слайд 41

Реляционные базы данных 3 3.4 3.22 Проблемы, возникающие при работе с

Реляционные базы данных

3

3.4

3.22

Проблемы, возникающие при работе с текущим отношением:
Дублирование информации о

фамилиях сотрудников.
Аномалии вставки (INSERT):
Отсутствуют
Аномалии обновления (UPDATE):
При необходимости изменить фамилию сотрудника,
нужно провести изменения в нескольких местах.
Аномалии удаления (DELETE):
Отсутствуют.
Слайд 42

Реляционные базы данных 3 3.4 3.23 Нормализация до уровня нормальной формы

Реляционные базы данных

3

3.4

3.23

Нормализация до уровня нормальной формы Бойса Кодда

Сотрудник

Сотрудник проекта

В каждой

из новых сущностей потенциальный ключ один, следовательно нарушения НФБК нет. Данный потенциальный ключ выбирается в  качестве первичного ключа.
Слайд 43

Реляционные базы данных 3 3.4 3.24 Сравнение сильно и слабо нормализованных отношений

Реляционные базы данных

3

3.4

3.24

Сравнение сильно и слабо нормализованных отношений

Слайд 44

Реляционные базы данных 3 3.4 3.25 Сравнение сильно и слабо нормализованных

Реляционные базы данных

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. Вставка нового клиента (№

Свойства операций над базой данных

Проблема №1.

Вставка нового клиента (№ Клиента:13, ФИО:Сидоров,


Дата рождения: 11.03. 1982)

Клиент

4.3

Слайд 48

Свойства операций над базой данных НЕПРОТИВОРЕЧИВОСТЬ (CONSISTENCY) Целостным состоянием БД называется

Свойства операций над базой данных

НЕПРОТИВОРЕЧИВОСТЬ (CONSISTENCY)

Целостным состоянием БД называется состояние
при котором

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

4.4

Слайд 49

Свойства операций над базой данных Проблема № 2. 4.5 Счет Операция

Свойства операций над базой данных

Проблема № 2.

4.5

Счет

Операция начисления зарплаты:
1. Счет №2.

Сумма := Сумма + 3500
СБОЙ
Слайд 50

Свойства операций над базой данных ДОЛГОВЕЧНОСТЬ (DURABILITY) Если операция закончилась успешно,

Свойства операций над базой данных

ДОЛГОВЕЧНОСТЬ (DURABILITY)

Если операция закончилась успешно, то результаты


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

2

Операция начисления зарплаты:
1. Счет №2. Сумма := Сумма + 3500
2. Сохранение результата в БД.
3. Подтверждение успешности выполнения операции
.
СБОЙ

Слайд 51

Свойства операций над базой данных 4.6 Счет Операция перевода денег клиентом

Свойства операций над базой данных

4.6

Счет

Операция перевода денег клиентом № 13 с

долларового счета в евро:
1. Счет № 1. Сумма := Сумма — 5000
2. Новая_Сумма_в Евро := Конвертация 5000 долларов в евро.
СБОЙ
3. Счет №3. Сумма =Сумма + Новая_Сумма_в Евро.

Проблема №3

Слайд 52

Свойства операций над базой данных АТОМАРНОСТЬ (ATOMICITY) Атомарный блок операций должен

Свойства операций над базой данных

АТОМАРНОСТЬ (ATOMICITY)

Атомарный блок операций должен выполнится целиком.
Если

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

4.7

1. Начать атомарный блок.
2. Счет № 1. Сумма := Сумма — 5000
3. Новая_Сумма_в Евро := Конвертация 5000 долларов в евро.
СБОЙ
4. Счет №3. Сумма =Сумма + Новая_Сумма_в Евро.
5. Завершить атомарный блок.

Слайд 53

Свойства операций над базой данных 4.8 Счет Проблема №4 Операция снятия

Свойства операций над базой данных

4.8

Счет

Проблема №4

Операция снятия денег со счета:
1. Начать

атомарный блок
2. Счет №2.Сумма = Сумма - 1000
.
.
.
Ошибка.
Отмена атомарного блока.
.
.
N. Конец атомарного блока

Операция снятия денег со счета:
1. Начать атомарный блок
.
.
i. Счет №2.Сумма = Сумма - 300
.
.
.
N. Конец атомарного блока

Слайд 54

Свойства операций над базой данных ИЗОЛИРОВАННОСТЬ (ISOLATION) Результат выполнения операций не

Свойства операций над базой данных

ИЗОЛИРОВАННОСТЬ (ISOLATION)

Результат выполнения операций не должен зависеть


от графика выполнения операций.

4.9

График выполнения операций — расположение операций
на временной шкале по времени выполнения

Операция 1

Операция j

Операция j+1

t

Слайд 55

Свойства операций над базой данных ТРАНЗАКЦИЯ 4.10 Единица работы в БД,

Свойства операций над базой данных

ТРАНЗАКЦИЯ

4.10

Единица работы в БД, объединяющая набор операций,


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

ACID
Atomicity Consistency Isolation Durability

SQL
BEGIN TRANSACTION — начать транзакцию
COMMIT — зафиксировать работу транзакции
ROLLBACK — откатить транзакцию (отменить транзакцию)

Слайд 56

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

Системы управления базами данных

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

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

5.1

Слайд 57

Безопасность баз данных 5.2 СУБД База Данных Информационная система на основе

Безопасность баз данных

5.2

СУБД

База Данных

Информационная система на основе базы данных

База Данных

База Данных

Клиентское

ПО

Клиентское ПО

Сеть

Клиентское ПО

Слайд 58

Безопасность баз данных 5.3 Контроль доступа (Access Control) Информационная система предназначена

Безопасность баз данных

5.3

Контроль доступа (Access Control)
Информационная система предназначена для работы различных

категорий пользователей (от операторов ввода данных до генерального директора).
Каждая категория пользователей имеет определенный уровень доступа к информации.
Создание пользователей(users) и ролей(roles) в терминологии
СУБД позволяет разграничить доступ к данным.
Разграничение доступа ведется на уровне выдачи привилегий на выполнение CRUD операций (Create Read Update Delete) для каждого объектов БД (таблицы, схемы, процедуры и т.д.)
Слайд 59

Безопасность баз данных 5.4 Аутентификация (Autentification) Логин и пароль как средства

Безопасность баз данных

5.4

Аутентификация (Autentification)

Логин и пароль как средства подтверждения факта,
что

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

Хранение паролей, даже в зашифрованном виде является
плохой практикой. Вместо пароля хранится хеш пароля.
Хеш — односторонняя функция, не позволяющая восстановить
значение аргумента по результату работы.
(MD5, SHA-2, ГОСТ Р 31.11-94)

Пользователи клиентского ПО должны быть сопоставлены
с зарегистрированными пользователями БД и ролями.

Слайд 60

Безопасность баз данных 3 Шифрование (Encryption) Данные физически хранятся в файле

Безопасность баз данных

3

Шифрование (Encryption)

Данные физически хранятся в файле доступ к которому

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

Шифрование физического представления данных позволяет
частично снизить зависимость от защищенности ОС.

Контроль доступа отвечает только за доступ через стандартные средства
СУБД (SQL запросы).

Шифрование не должно использоваться как средство контроля доступа.

Основные алгоритмы: 3DES, AES и их вариации.
Возможно использование как симметричных,
так и ассиметричных протоколов

Слайд 61

Безопасность баз данных 5.5 Аудит (Auditing) Администратор базы данных (Database Administrator,

Безопасность баз данных

5.5

Аудит (Auditing)

Администратор базы данных (Database Administrator, DBA),
- человек

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

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

Человек, - самое уязвимое звено любой системы безопасности

Подсистема аудита фиксирует действия всех пользователей и
является средством с доступом только на чтение для
администратора БД.

Слайд 62

Модели данных 6.1

Модели данных

6.1

Слайд 63

Модели данных 6.2 ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

Модели данных

6.2

ИЕРАРХИЧЕСКАЯ МОДЕЛЬ ДАННЫХ

Слайд 64

Модели данных 6.3

Модели данных

6.3

Слайд 65

Модели данных 6.4

Модели данных

6.4

Слайд 66

Модели данных 6.5 Трехуровневая архитектура ANSI/SPARC ANSI – American National Standard

Модели данных

6.5

Трехуровневая архитектура ANSI/SPARC

ANSI – American National Standard Institute,
SPARC –

Standards Planning and Requirements Committee
Слайд 67

Модели данных 6.6 Общая характеристика моделей данных Модель данных – это

Модели данных

6.6

Общая характеристика моделей данных

Модель данных – это интегрированный набор понятий для

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

МОДЕЛЬ ДАННЫХ

Сильно типизированные

Слабо типизированные

Компоненты:
категория
свойства категории
связи между категориями

Схема:
ВОДИТЕЛЬ (Имя, Возраст, Стаж работы)
АВТОМОБИЛЬ (Модель, Гос. номер, Дата приобретения)
УПРАВЛЯЕТ (ВОДИТЕЛЬ, АВТОМОБИЛЬ)

Слайд 68

Модели данных 6.7 Множества: домены, атрибуты Множество – это собрание правильно

Модели данных

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 Множества: домены, атрибуты Атрибуты – это именованные домены,

Модели данных

6.7

Множества: домены, атрибуты

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

Атрибуты

определяются на доменах и представляют собой интенсионал именованного домена. Значения атрибута – это экстенсионалы.
Слайд 70

Модели данных 6.8 Отношения: сущности Агрегат, построенный на множествах, определяется как

Модели данных

6.8

Отношения: сущности

Агрегат, построенный на множествах, определяется как отношение

Пусть дана

некоторая совокупность доменов D1, D2, …, Dm, не обязательно различных. Отношение, определенное на доменах D1, D2, …, Dm, есть множество упорядоченных кортежей , таких, что d1 ∈ D1, d2 ∈ D2, …, dm ∈ Dm.
Слайд 71

Модели данных 6.8 Отношения: сущности Пример: Даны множества: D1 = {d1i

Модели данных

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 Отношения: сущности Степень отношения (или арность кортежа) –

Модели данных

6.8

Отношения: сущности

Степень отношения (или арность кортежа) – характеристика, относящаяся к

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

Мощность отношения – характеристика, относящаяся к экстенсионалу отношения; количество элементов в конкретной реализации отношения

Слайд 73

Модели данных 6.8 Отношения: сущности Схема отношения – это именованный список

Модели данных

6.8

Отношения: сущности

Схема отношения – это именованный список пар <имя атрибута>:<имя

домена>, имя которого задает имя отношения: R(A1:D1, A2:D2, …, Am:Dm).
Слайд 74

Модели данных 6.9 Отношения: связи Агрегат, построенный на других отношениях, рассматривается

Модели данных

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 Отношения: связи Минимальное и максимальное кардинальные числа не

Модели данных

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 Общая характеристика ограничений целостности Структурными компонентами модели данных

Модели данных

6.9

Общая характеристика ограничений целостности

Структурными компонентами модели данных являются отношения и связи

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

Логические ограничения, накладываемые на данные, называются ограничениями целостности.

Ограничения целостности реализуется средствами языка описания ограничений (ЯОО, или CDL – Constraints Definition Language)

Слайд 77

Реляционная модель данных 7.1 Реляционная модель данных Реляционная модель данных (РМД)

Реляционная модель данных

7.1

Реляционная модель данных

Реляционная модель данных (РМД) была разработана сотрудником IBM

Э.Ф. Коддом (E.F. Codd) в 1969-70 г.г. на основе математической теории отношений.

Реляционная модель данных

Структурная и целостная части

Манипуляционная часть

Язык описания данных (ЯОД)
Data Definition Language (DDL)

Язык манипулирования данными (ЯМД)
Data Manipulation Language (DML)

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

Слайд 78

Реляционная модель данных 7.2 Базовые структурные компоненты реляционной модели данных Домены

Реляционная модель данных

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 Базовые структурные компоненты реляционной модели данных Пример:

Реляционная модель данных

7.2

Базовые структурные компоненты реляционной модели данных

Пример:
Даны два домена D1

= {a, b, c} и D2 = {1, 2}.
Отношение R1 = {, }. Отношение R2 = {, , }.
Свойства отношения:
кортежи отношения не упорядочены,
домены внутри кортежей упорядочены.

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

Схема отношения – это именованная совокупность пар <имя атрибута : имя домена>.
Пример: ОТДЕЛ ( Номер отдела: ЧИСЛО, Название: СТРОКА )

Слайд 80

Реляционная модель данных 7.2 Базовые структурные компоненты реляционной модели данных В

Реляционная модель данных

7.2

Базовые структурные компоненты реляционной модели данных

В задании схемы отношения могут

использоваться и составные домены.
Пример, реализации (экстенсионал) отношения СОТРУДНИК :

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

В данном примере значением одного элемента составного домена является множество пар вида<ГОД, ДЕНЬГИ>

Слайд 81

Реляционная модель данных 7.2 Базовые структурные компоненты реляционной модели данных Нормализация:

Реляционная модель данных

7.2

Базовые структурные компоненты реляционной модели данных

Нормализация: составной домен заменяется составляющими

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

Реляционная модель данных 7.2 Свойства реляционной модели данных Каждый атрибут отношения

Реляционная модель данных

7.2

Свойства реляционной модели данных

Каждый атрибут отношения имеет уникальное в данном

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

Реляционная модель данных 7.3 Представление сущности Представление сущности означает возможность уникальной

Реляционная модель данных

7.3

Представление сущности

Представление сущности означает возможность уникальной идентификации каждого отдельного кортежа

отношения по значениям его атрибутов

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

Первичный ключ (PK – Primary Key) – не избыточный набор атрибутов, значения которых однозначно определяют кортеж отношения.

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

Слайд 84

Реляционная модель данных 7.3 Представление сущности Отношение может иметь только один

Реляционная модель данных

7.3

Представление сущности

Отношение может иметь только один первичный ключ.
Если в

отношении можно выделить несколько наборов атрибутов для первичного ключа, выбирается один, остальные определяются как альтернативные (AK – Alternate Key).

Пример отношения:
КАФЕДРА ( Номер кафедры, Название )
Номер кафедры – PK
Название - AK

Слайд 85

Реляционная модель данных 7.3 Связи Связи между сущностями отражают взаимосвязи между

Реляционная модель данных

7.3

Связи

Связи между сущностями отражают взаимосвязи между конкретными экземплярами сущностей. Эти

взаимосвязи представляются с помощью внешних ключей

Внешний ключ (FK – Foreign Key) – это атрибут или некоторое множество атрибутов отношения R1, которые не являются собственными атрибутами отношения R1, но их значение совпадает со значениями первичного ключа некоторого отношения R2 (возможность идентичности R1 и R2 не исключается).

Основными типами связей между сущностями являются: 1 : n и n : n

Слайд 86

Реляционная модель данных 7.3 Связи Пример, есть отношения: СОТРУДНИК с атрибутами

Реляционная модель данных

7.3

Связи

Пример, есть отношения:
СОТРУДНИК с атрибутами Номер сотрудника (первичный ключ), Имя

и Год рождения
ОТДЕЛ с атрибутами Номер отдела (первичный ключ) и Название.
Слайд 87

Реляционная модель данных 7.3 Связи Схемы отношений: ОТДЕЛ ( Номер отдела,

Реляционная модель данных

7.3

Связи

Схемы отношений:
ОТДЕЛ ( Номер отдела, Название (АК) )
СОТРУДНИК ( Номер

сотрудника, Имя, Год рождения, Номер отдела (FK) )

ОТДЕЛ

СОТРУДНИК

Слайд 88

Реляционная модель данных 7.3 Связи Представление связи 1:n в IDEF1X:

Реляционная модель данных

7.3

Связи

Представление связи 1:n в IDEF1X:

Слайд 89

Реляционная модель данных 7.3 Связи Пример, есть отношения: ПОСТАВЩИК с атрибутами

Реляционная модель данных

7.3

Связи

Пример, есть отношения:
ПОСТАВЩИК с атрибутами Номер поставщика (первичный ключ), Имя

и Адрес, и отношение ДЕТАЛЬ с атрибутами Номер детали (первичный ключ), Название и Цена.
Слайд 90

Реляционная модель данных 7.3 Связи Схемы отношений : ПОСТАВЩИК ( Номер

Реляционная модель данных

7.3

Связи

Схемы отношений :
ПОСТАВЩИК ( Номер поставщика, Имя, Адрес )
ДЕТАЛЬ (

Номер детали, Название, Цена )
ПОСТАВКА ( Номер поставщика (FK1), Номер детали (FK2), Количество )

Поставщик

Деталь

Поставка

Слайд 91

Реляционная модель данных 7.3 Связи Представление и разрешение связи n:n в IDEF1X:

Реляционная модель данных

7.3

Связи

Представление и разрешение связи n:n в IDEF1X:

Слайд 92

Реляционная модель данных 7.4 Ссылочная целостность Пример отношения: ОТДЕЛ ( Номер

Реляционная модель данных

7.4

Ссылочная целостность

Пример отношения:
ОТДЕЛ ( Номер отдела, Название (АК) )
СОТРУДНИК (

Номер сотрудника, Имя, Год рождения, Номер отдела (FK) )

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

Слайд 93

Реляционная модель данных 7.4 Языковые средства описания данных Язык определения данных

Реляционная модель данных

7.4

Языковые средства описания данных

Язык определения данных (DDL) для реляционной модели

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

Соответствие между компонентами РМД и элементами базы данных

Слайд 94

Реляционная модель данных 7.4 Типы ограничений целостности Основные предложения DDL(ЯОД): CREATE

Реляционная модель данных

7.4

Типы ограничений целостности

Основные предложения DDL(ЯОД):
CREATE тип_объекта – создать соответствующий

объект базы данных,
ALTER тип_объекта – изменить соответствующий объект базы данных,
DROP тип_объекта – удалить указанный объект базы данных.
Слайд 95

Реляционная модель данных 7.4 Способы именования объектов Идентификаторы Обычный идентификатор Идентификатор

Реляционная модель данных

7.4

Способы именования объектов

Идентификаторы

Обычный идентификатор

Идентификатор с ограничителями

Текст заключен в двойные кавычки.

Чувствительны к регистру, можно использовать зарезервированные слова.
Примеры: ”WKLY-SAL” ”Department Name” ”UNION”

Последовательность букв, цифр и символов подчеркивания (_), начинающаяся с буквы. Не чувствителен к регистру. Не совпадает с зарезервированными словами.
Примеры: A12 Tab_Name
DeptID

Слайд 96

Реляционная модель данных 7.4 Типы данных Числовые - используются для представления целых, вещественных и десятичных чисел.

Реляционная модель данных

7.4

Типы данных

Числовые - используются для представления целых, вещественных и десятичных

чисел.
Слайд 97

Реляционная модель данных 7.4 Типы данных Строковые типы данных используются для

Реляционная модель данных

7.4

Типы данных

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

Типы

данных дата – время используются для представления даты и времени
Слайд 98

Реляционная модель данных 7.4 Основные операции Операция конкатенации (CONCAT или ||

Реляционная модель данных

7.4

Основные операции

Операция конкатенации (CONCAT или || или +) - можно

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

Арифметические операции можно использовать с операндами числовых типов.
Бинарные операции (/, *, +, -) определяют сложение, вычитание, умножение и деление, соответственно

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

Слайд 99

SQL 8.0 Создание таблиц CREATE TABLE имя_таблицы ( имя_колонки тип_данных [ограничение_обязательности]

SQL

8.0

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

CREATE TABLE имя_таблицы
(
имя_колонки тип_данных [ограничение_обязательности] [ограничение_целостности_на_колонку] [спецификация_генерируемого_значения]
[, …]
[, ограничение_целостности_на_таблицу]
[, … ]
)

имя_таблицы

– идентификатор, задает имя таблицы;
имя_колонки – идентификатор, уникальный в пределах данной таблицы;
тип_данных – тип данных для колонки;
ограничение_обязательности – задает ограничение обязательности значения данной колонки;
ограничение_целостности_на_колонку – ограничение целостности, накладываемое на данную колонку;
Слайд 100

SQL 8.0 Создание таблиц ограничение_целостности_на_таблицу – ограничение целостности, накладываемое на одну

SQL

8.0

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

ограничение_целостности_на_таблицу – ограничение целостности, накладываемое на одну или несколько колонок

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

Ограничения целостности:
[CONSTRAINT имя_ограничения] ограничение
имя_ограничения – задает имя ограничения. Уникально в пределах данной таблицы;
ограничение – задает конкретное ограничение целостности.

Слайд 101

SQL 8.0 Создание таблиц. Правила задания ограничений Ограничения обязательности NULL NOT

SQL

8.0

Создание таблиц. Правила задания ограничений

Ограничения обязательности

NULL

NOT NULL

Ограничения уникальности( всегда Not Null)

UNIQUE

PRIMARY

KEY

Ограничение уникальности на колонку : UNIQUE или PRIMARY KEY. Ограничение уникальности на таблицу : UNIQUE(имя_колонки, …) или PRIMARY KEY(имя_колонки, …).
UNIQUE – определяет альтернативный ключ, может быть несколько
PRIMARY KEY – определяет первичный ключ, может быть только одно

Слайд 102

SQL 8.0 Создание таблиц. Правила задания ограничений Ограничение допустимости значений CHECK(условие)

SQL

8.0

Создание таблиц. Правила задания ограничений

Ограничение допустимости значений

CHECK(условие) Условие, записанное в ограничении на

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

Условие

Предикаты:
BETWEEN, IN, LIKE
Результат предиката:
TRUE, FALSE, NULL

Логические операции:
NOT, AND, OR

Слайд 103

SQL 8.0 Создание таблиц. Правила задания ограничений Правила вычисления логических операций

SQL

8.0

Создание таблиц. Правила задания ограничений

Правила вычисления логических операций

Слайд 104

SQL 8.0 Создание таблиц. Правила задания ограничений Основной предикат: выражение операция_отношения

SQL

8.0

Создание таблиц. Правила задания ограничений

Основной предикат: выражение операция_отношения выражение
операции_отношения: операции = (равно),

<> (не равно), < (меньше), > (больше), <= (меньше или равно), >= (больше или равно).

Предикат BETWEEN
выражение1 [NOT] BETWEEN выражение2 AND выражение3
должно выполняться соотношение: выражение2 ≤ выражение3
Пример:
выражение1 BETWEEN выражение2 AND выражение3,
тоже самое что и:
выражение1 >= выражение2 AND выражение1 <= выражение3.

Слайд 105

SQL 8.0 Создание таблиц. Правила задания ограничений Предикат IN выражение [NOT]

SQL

8.0

Создание таблиц. Правила задания ограничений

Предикат IN
выражение [NOT] IN (список_выражений)
список_выражений - перечисление

выражений через запятую в произвольном порядке
Результат вычисления IN:
«истина», если значение выражения совпадает хотя бы с одним значением из списка;
«ложь», если значение выражения не совпадает ни с одним значением из списка, и в списке нет неопределенных(NULL) значений;
не определено(NULL), если значение выражения не совпадает ни с одним значением из списка, и в списке есть неопределенные значения.
Результат значения NOT IN противоположен IN.
Слайд 106

SQL 8.0 Создание таблиц. Правила задания ограничений Предикат LIKE выражение [NOT]

SQL

8.0

Создание таблиц. Правила задания ограничений

Предикат LIKE
выражение [NOT] LIKE шаблон [ESCAPE escape-символ]
Предикат

LIKE проверяет, соответствует ли строка, являющаяся результатом вычисления выражения, заданному шаблону.
Результат вычисления LIKE :
«истина», если значение выражения удовлетворяет шаблону,
«ложь», если не удовлетворяет,
не определено, если хотя бы один из аргументов имеет значение NULL
Результат значения NOT LIKE противоположен LIKE.

Шаблон это строка использующая специальные метасимволы:
_ (символ подчеркивания) – соответствует одному (любому) символу,
% – соответствует любой (возможно, пустой) цепочке символов.

Слайд 107

SQL 8.0 Создание таблиц. Правила задания ограничений Ссылочное ограничение На колонку:

SQL

8.0

Создание таблиц. Правила задания ограничений

Ссылочное ограничение

На колонку:
REFERENCES имя­_родительской_таблицы [(имя_колонки_PK, …)] [ON

DELETE правило_удаления] [ON UPDATE правило_обновления]
На таблицу :
FOREIGN KEY (имя_колонки_FK, …) REFERENCES имя­_родительской_таблицы [(имя_колонки_PK, …)] [ON DELETE правило_удаления] [ON UPDATE правило_обновления]

имя_колонки_FK – имена колонок внешнего ключа в создаваемой (дочерней) таблице. Порядок перечисления принципиален; имя­_родительской­­_таблицы – имя родительской таблицы, на которую ссылается создаваемая дочерняя таблица; имя_колонки_PK – имена колонок первичного ключа в родительской таблице.

Слайд 108

SQL 8.0 Создание таблиц. Правила задания ограничений Ссылочное ограничение правило_удаления –

SQL

8.0

Создание таблиц. Правила задания ограничений

Ссылочное ограничение

правило_удаления – определяет, какие действия должны

быть выполнены при удалении записи из родительской таблицы. Допускаются значения: RESTRICT ИЛИ NOACTION, CASCADE, SET NULL

правило_обновления – определяет, какие действия должны быть выполнены при модификации первичного ключа в родительской таблице. Допускаются значения RESTRICT или NO ACTION

RESTRICT выполняется перед проверкой всех остальных ограничений
NO ACTION выполняется после проверки всех ограничений

Слайд 109

SQL 8.0 Создание таблиц. Правила задания ограничений Спецификация генерируемого значения Значение

SQL

8.0

Создание таблиц. Правила задания ограничений

Спецификация генерируемого значения

Значение по умолчанию

Автоинкрементное значение

DEFAULT

значение

IDENTITY [опции] Опции: начальное значение, шаг, максимальное, минимальное, повторное выполнение

Слайд 110

SQL 8.0 Создание таблиц. Пример: Схемы отношений : ПОСТАВЩИК ( Номер

SQL

8.0

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

Пример:

Схемы отношений :
ПОСТАВЩИК ( Номер поставщика, Имя, Адрес )
ДЕТАЛЬ

( Номер детали, Название, Цена )
ПОСТАВКА ( Номер поставщика (FK1), Номер детали (FK2), Количество )
Слайд 111

SQL 8.0 Создание таблиц. Пример: Схема отношений : ДЕТАЛЬ ( Номер

SQL

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 – условие: значение атрибута должно быть строго положительным.

Слайд 112

SQL 8.0 Создание таблиц. Пример: Схема отношений : ПОСТАВЩИК ( Номер

SQL

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 – ограничения первичного ключа на таблицу;

Слайд 113

SQL 8.0 Создание таблиц. Пример: Схема отношений : ПОСТАВКА ( Номер

SQL

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 –определяется внешний ключ (ограничение на таблицу).

Слайд 114

SQL 8.0 Удаление и модификация таблиц. DROP TABLE имя_таблицы – удаление

SQL

8.0

Удаление и модификация таблиц.

DROP TABLE имя_таблицы – удаление таблицы

ALTER TABLE

имя_таблицы операция [операция …]

Модификация таблиц

Операции: Добавление новых колонок:
ADD [ COLUMN ] определение_колонки определение_колонки тоже что и в CREATE TABLE
Пример:
ALTER TABLE EQUIPMENT
ADD COLUMN Equip_QTY SMALLINT
NOT NULL WITH DEFAULT 1

Слайд 115

SQL 8.0 Удаление и модификация таблиц. Операции: Изменение характеристик колонок: ALTER

SQL

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 – удаляет для указанной колонки установленный для нее атрибут автоинкрементного значения.
Слайд 116

SQL 8.0 Удаление и модификация таблиц. Операции: Добавление ограничений целостности: ADD

SQL

8.0

Удаление и модификация таблиц.

Операции: Добавление ограничений целостности:
ADD [CONSTRAINT имя_ограничения] ограничение Ограничение

задается точно так же, как и табличное ограничение в предложении CREATE TABLE
Пример1:
ALTER TABLE EQUIPMENT
ADD CONSTRAINT DeptQuip
FOREIGN KEY(Equip_Owner)
REFERENCES DEPT
ON DELETE SET NULL
Слайд 117

SQL 8.0 Удаление и модификация таблиц. Пример2: ALTER TABLE EMPLOYEE ADD

SQL

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

Слайд 118

SQL 9.0 Предложения языка манипулирования данными Предложение INSERT INSERT INTO имя_таблицы

SQL

9.0

Предложения языка манипулирования данными

Предложение INSERT

INSERT INTO имя_таблицы [(имя_колонки, …)] VALUES (значение,

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

Свойства:
Одно и то же имя колонки не должно указываться дважды;
Если список имен колонок опущен, порядок колонок определяется в соответствии с CREATE TABLE;
Для неуказанных колонок определяется атрибут NULL или DEFAULT;

Слайд 119

SQL 9.0 Предложения языка манипулирования данными Предложение INSERT Свойства: Количество значений,

SQL

9.0

Предложения языка манипулирования данными

Предложение INSERT

Свойства:
Количество значений, указанных в каждой строке, должно

соответствовать явному или неявному списку имен колонок;
Тип вставляемых значений должен соответствовать типу соответствующих им колонок

Строки, добавляемые в таблицу, получены в результате запроса:
INSERT INTO имя_таблицы [(имя_колонки, …)] запрос
Количество колонок в результате выполнения запроса должно совпадать с количеством колонок, указанным (явно или неявно) в списке.

Слайд 120

SQL 9.0 Предложения языка манипулирования данными Предложение INSERT Пример1: 1) INSERT

SQL

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’)
Слайд 121

SQL 9.0 Предложения языка манипулирования данными Предложение INSERT Пример1: 4) INSERT

SQL

9.0

Предложения языка манипулирования данными

Предложение INSERT

Пример1:

4) INSERT INTO DEPARTMENT (DeptNo, DeptName, AdmrDept)

VALUES (’B11’, ’PURCHASING’, ’B01’),
(’E41’, ’DATABASE ADMINISTRATION’, ’E01’)
Слайд 122

SQL 9.0 Предложения языка манипулирования данными Предложение INSERT Пример2: CREATE TABLE

SQL

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%’

Слайд 123

SQL 9.0 Предложения языка манипулирования данными Предложение DELETE DELETE FROM имя_таблицы

SQL

9.0

Предложения языка манипулирования данными

Предложение DELETE

DELETE FROM имя_таблицы [WHERE условие_поиска]

имя_таблицы – должно

указывать существующую таблицу базы данных.
условие_поиска – определяет условие отбора удаляемых строк

Свойства:
В условии поиска в конструкции WHERE могут быть использованы только колонки таблицы, указанной в предложении DELETE; Условие поиска применяется к каждой строке таблицы, и удаляются те строки, для которых результатом условия поиска является значение true; При удалении строк из родительской таблицы проверяются ограничения ссылочной целостности; Если при выполнении DELETE, возникла ошибка, никакие изменения в базе данных не происходят

Слайд 124

SQL 9.0 Предложения языка манипулирования данными Предложение DELETE Примеры Пример 1.

SQL

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)
Слайд 125

SQL 9.0 Предложения языка манипулирования данными Предложение UPDATE UPDATE имя_таблицы SET

SQL

9.0

Предложения языка манипулирования данными

Предложение UPDATE

UPDATE имя_таблицы SET имя_колонки = значение, …

[WHERE условие_поиска]

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

Слайд 126

SQL 9.0 Предложения языка манипулирования данными Предложение UPDATE Свойства: В условии

SQL

9.0

Предложения языка манипулирования данными

Предложение UPDATE

Свойства:
В условии поиска в конструкции WHERE могут

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