🗊Презентация Базы данных

Базы данных Преподаватель Фомин Михаил Михайлович

Вводные замечания Количественные параметры курса Лекции 10 вечеров Лабораторные 3 шт. Курсовой проект 0 шт. Экзамен 1 шт. Важность терминологии Литература и первоисточники Можно найти на сайте кафедры Как и когда задавать вопросы Обратная связь m_fomin@mail.ru

Программные средства Oracle Database 11g Express Edition Oracle SQL Developer Oracle SQL Developer Data Modeler Oracle Application Express MS Access

Вопросы?

Особенности этого курса Здесь нет теории… тут груз практики

Кем быть? ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА ФГОС ВО по направлениям бакалавриата – http://fgosvo.ru/fgosvo/92/91/4/9 СВЯЗЬ, ИНФОРМАЦИОННЫЕ И КОММУНИКАЦИОННЫЕ ТЕХНОЛОГИИ Профессиональные стандарты – http://fgosvo.ru/docs/101/69/2/6

Что мы будем здесь изучать То, что Вам надо Аналитик Программист Администратор ИС/БД Менеджер проекта Преподаватель Научный работник

План курса Часть 1. Что такое База данных. Часть 2. Какие бывают Базы данных и СУБД. Часть 3. Проектирование Баз данных и информационных систем. Часть 4. Эксплуатация и обслуживание Баз данных.

Информационная система, что это? Информационная система — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают сбор, обработку и распространение информации

База данных, что это? База данных — представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

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

Иерархическая модель данных

Сетевая модель данных

Сетевая модель данных

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

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

Таблица в реляционной модели

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

Таблица в реляционной модели

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

Связи между таблицами

Правильные связи в правильной базе данных

Заполнение ключевых полей

Типы связей между сущностями

Реализация связей «много – много»

Реализация связей «много – много»

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

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

Холивары связанные с БД Нужна ли нормализация? Должны ли первичные ключи быть осмысленными атрибутами? Так ли уж необходимо значение NULL? Должна ли реляционная СУБД (язык SQL) полностью удовлетворять требованиям реляционной теории?

Теория и практика

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

Соответствие терминов Доказательство возможности представления любой структуры данных при помощи реляционной модели Принципы создания реляционных СУБД Разработка языка SQL

База данных и СУБД

12 правил Кодда 0 Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными. 1 Информационное правило – вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения таблиц. 2 Гарантированный доступ – любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичного ключа и имени столбца. 3 Поддержка пустых значений – СУБД должна уметь работать с пустыми значениями. Пустое значение – это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений. 4 Активный, оперативный реляционный каталог – описание БД и его содержимое должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя DML (язык манипулирования данными). 5 Исчерпывающее подмножество языка данных – по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть самодостаточным. Он должен поддерживать определение данных и манипулирование ими, правила целостности, авторизацию и транзакции. 6 Правило обновления представлений – все представления, теоретически обновляемые, могут быть обновлены через систему. 7 Вставка, обновление и удаление – СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление. 8 Физическая независимость данных – логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения. 9 Логическая независимость данных – логика программ-приложений остается прежней, в пределах разумного, при изменении структур таблиц. 10 Независимость целостности – язык БД должен быть способен определять ограничения целостности. Они должны быть доступны из оперативного каталога, и не должно быть способа их обойти. 11 Независимость распределения – запросы программ-приложений логически не затрагиваются при первом и последующих распределениях данных. 12 Несмешиваемость (Nonsubversion) – невозможность обойти ограничения целостности, используя языки низкого уровня.

Одно правило Фомина СУБД является реляционной если в ней реализована полная поддержка языка SQL

12 правил Кодда 0 Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными. 1 Информационное правило – вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения таблиц. 2 Гарантированный доступ – любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичного ключа и имени столбца. 3 Поддержка пустых значений – СУБД должна уметь работать с пустыми значениями. Пустое значение – это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений. 4 Активный, оперативный реляционный каталог – описание БД и его содержимое должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя DML (язык манипулирования данными). 5 Исчерпывающее подмножество языка данных – по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть самодостаточным. Он должен поддерживать определение данных и манипулирование ими, правила целостности, авторизацию и транзакции. 6 Правило обновления представлений – все представления, теоретически обновляемые, могут быть обновлены через систему. 7 Вставка, обновление и удаление – СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление. 8 Физическая независимость данных – логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения. 9 Логическая независимость данных – логика программ-приложений остается прежней, в пределах разумного, при изменении структур таблиц. 10 Независимость целостности – язык БД должен быть способен определять ограничения целостности. Они должны быть доступны из оперативного каталога, и не должно быть способа их обойти. 11 Независимость распределения – запросы программ-приложений логически не затрагиваются при первом и последующих распределениях данных. 12 Несмешиваемость (Nonsubversion) – невозможность обойти ограничения целостности, используя языки низкого уровня.

Одно правило Фомина СУБД является реляционной если в ней реализована полная поддержка языка SQL

Дерево реляционных СУБД

Классификация СУБД Аналитические системы (OLAP) – способ организации БД, созданных для хранения агрегированной информации на основе больших массивов данных, структурированных по многомерному принципу (суперкубы). Транзакционные системы (OLTP) - способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.

Кубы в OLAP

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

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

Простой пример транзакции (перевод денег между счетами)

ACID, или свойства транзакции Atomic - атомарность. Транзакция это неделимая единица, которая должна быть либо выполнена, либо отменена. Coordination - согласованность. Смысл транзакции состоит в том, чтобы база данных переходила из одного согласованного состояния в другое. Insulativity - изолированность. Каждая транзакция, которая выполняется, не зависит от остальных. Все результаты одного процесса, доступные в промежутках, не должны быть видны другим транзакциям. Duration - надежность. Все результаты, которые были достигнуты в ходе успешной транзакции, наверняка сохраняются в базе данных.

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

Сложный пример транзакции (выдача денег через кассу)

Простой пример транзакции (перевод денег между счетами)

Механизмы транзакций (snapshot)

Окончание транзакции

Блокировки и клинчи

Множественные клинчи

Как выйти из клинча Разорвать порочный круг! А какую транзакцию собственно удалять? Самую старую? Самую новую? А как узнать какая старая, какая новая?

Последовательное выполнение транзакций

Поддержка транзакций в SQL START TRANSACTION /* отмечает начало транзакции */ ...... Тело транзакции ……. SAVEPOINT точка_сохранения /* отмечает промежуточную точку сохранения*/ ...... Тело транзакции ……. Обработка ошибки ROLLBACK [TO SAVEPOINT точка_сохранения] /* откатывает изменения текущей транзакции */ ...... Тело транзакции ……. COMMIT /* сохраняет все изменения текущей транзакции */

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

Журналирование

Зачем нужны журналы транзакций? Анализ работы СУБД и действий пользователей Репликация данных Восстановление данных после сбоев

Копирование базы данных ИЛИ Репликация. Первый шаг Копирование файловой системы Средствами операционной системы делается копия файлов СУБД. На время копирования СУБД надо остановить. Копирование специальными программами Создается копия базы данных средствами СУБД. Копирование устройств Создается копия устройства средствами системы хранения данных (СХД).

Репликация. Второй шаг и рабочая схема

Восстановление данных после сбоев (причины и последствия) Утеряно содержимое оперативной памяти

Восстановление данных после сбоев (крах оперативной памяти) Самовосстановление Загрузка ближайшей точки согласованности Откат транзакций незафиксированных в долговременной памяти (журнал REDO) Накат транзакций из журнала REDO

Восстановление данных после потери (искажения) данных на устройствах долговременной памяти Ручное восстановление Загрузка данных с копии При необходимости правка журнала Archived log Накат транзакций из журнала Archived log

Восстановление данных после сбоев (ошибки неизвестного происхождения) Здесь правил нет!

Поддержка языков БД SQL Процедурное расширение (PL SQL) Прочие языки программирования Язык К PL/Perl и PL/Python

Словарь БД Структура Базы данных – тоже данные! Структура Базы данных тоже может храниться в таблицах Хранимые процедуры на разных языках А еще , например, коды и расшифровки ошибок исполнения SQL А еще имена и пароли пользователей И, конечно, таблица DUAL

Словарь СУБД Oracle

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

Файлы и логические структуры

Управление внешней памятью Файлы и «сырые диски» Устройства, луны и экстенты Добавление, изменение и фрагментация Размещение и последовательное чтение Кеширование, буферизация, тирринг

Контрольные вопросы Зачем придуман механизм транзакций? Зачем нужны журналы?

Как СУБД общаются с клиентами

Клиент-серверная архитектура

Трехзвенная архитектура

Трехзвенная архитектура

Трехзвенная архитектура

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

Трехзвенная архитектура картинки из интернета

Клиент-серверная архитектура картинки из интернета

Клиент-серверная архитектура картинки из интернета