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

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

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

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

Слайд 2. Содержание

• Введение
• Основные понятия
• История развития систем
• Кто создал известные системы
• Функции системы управления
• Трёхуровневая архитектура
• Ядро системы управления базами данных
• Клиент-серверная модель
• Путь запроса к данным
• Свойства надёжной транзакции
• Уровни изоляции транзакций
• Журнал и восстановление после сбоя
• Индексы и ускорение поиска
• Оптимизатор запросов
• Виды систем по модели данных
• Известные системы: сравнение
• PostgreSQL и MySQL
• Задачи администратора
• Резервное копирование
• Выводы
• Список литературы

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

Слайд 3. Введение

• Практически любая информационная система — банковское приложение, интернет-магазин, электронный журнал вуза — работает не с файлами напрямую, а через систему управления базами данных.
• Система управления базами данных берёт на себя самое трудное: одновременный доступ сотен пользователей, целостность данных при сбое питания и поиск нужной записи среди миллионов.
• Разработчику важно понимать внутреннее устройство таких систем: от выбора и настройки зависит скорость приложения и сохранность информации.
• В презентации разобраны архитектура, функции, механизм транзакций, индексы, известные системы и задачи администратора.

Доклад: Начну с того, почему тема актуальна. Банковское приложение, интернет-магазин, электронный журнал вуза — все они работают с данными не напрямую через файлы, а через специальную программу-посредника. Именно она берёт на себя одновременный доступ сотен пользователей, сохранность информации при сбое питания и быстрый поиск нужной записи среди миллионов. Разработчику важно понимать это устройство: от выбора и настройки системы напрямую зависит скорость и надёжность продукта.

Слайд 4. Основные понятия

• Система управления базами данных — комплекс программ для создания, хранения, изменения и выдачи данных по запросу
• База данных — сама совокупность упорядоченных данных, которой управляет эта программа
• Сервер базы данных — компьютер и процесс, где работает ядро системы и хранятся файлы данных
• Запрос — сформулированное на языке системы задание на выборку или изменение данных
• Транзакция — неделимая группа операций, которая выполняется либо целиком, либо не выполняется вовсе

Доклад: Договоримся о терминах, чтобы дальше говорить на одном языке. Система управления базами данных — это комплекс программ, а база данных — сами упорядоченные данные, которыми он управляет. Сервер базы данных — машина и процесс, где живёт ядро системы. Запрос — задание на выборку или изменение, а транзакция — неделимая группа операций, которая либо выполняется целиком, либо не выполняется вовсе.

Слайд 5. История развития систем

• За шестьдесят лет системы прошли путь от иерархических хранилищ на магнитных лентах до распределённых облачных кластеров.
• Переломом стала реляционная модель: она отделила логику данных от способа их физического хранения.
• Сегодня рядом с реляционными системами уверенно работают нереляционные — для документов, кэша и графов.
• 1963 — первая промышленная система IDS
• 1970 — реляционная модель Эдгара Кодда
• 1979 — первая коммерческая система Oracle
• 1995 — выход MySQL и PostgreSQL
• 2000 — встраиваемая система SQLite
• 2009 — нереляционная система MongoDB

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

Слайд 6. Кто создал известные системы

• Майкл Стоунбрейкер, род. 1943, Создатель систем Ingres и Postgres, лауреат премии Тьюринга 2014 года
• Ларри Эллисон, род. 1944, Основатель корпорации Oracle, выпустившей первую коммерческую реляционную систему
• Микаэль Видениус, род. 1962, Один из авторов MySQL и создатель ответвления MariaDB

Доклад: За каждой известной системой стоят конкретные люди. Майкл Стоунбрейкер создал Ingres и Postgres и получил за вклад в отрасль премию Тьюринга. Ларри Эллисон основал корпорацию, выпустившую первую коммерческую реляционную систему и до сих пор занимающую банковский сегмент. Микаэль Видениус — один из авторов MySQL, а позже создатель ответвления MariaDB, которое сегодня стоит на многих серверах.

Слайд 7. Функции системы управления

• Хранение данных на диске и управление файлами: страницы, буферный кэш, экономное размещение записей.
• Обработка запросов: разбор задания, построение плана и выдача результата приложению.
• Поддержка транзакций: группа изменений применяется целиком либо полностью отменяется.
• Журналирование и восстановление: система возвращается в согласованное состояние после сбоя.
• Разграничение доступа: учётные записи, роли и права на отдельные таблицы и действия.
• Контроль целостности: проверка типов, ограничений и связей между таблицами при каждом изменении.

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

Слайд 8. Трёхуровневая архитектура

• Разделение уровней предложено в стандарте ANSI/SPARC в 1975 году и используется до сих пор.
• Главная идея — независимость данных: изменение способа хранения не ломает работающие приложения.
• Администратор может добавить индекс или перенести таблицу на другой диск, не переписывая программы.
• Приложение видит только внешний уровень и не знает, как именно данные лежат на диске.
• Внешний уровень — представления данных для конкретных приложений и пользователей
• Концептуальный уровень — единая логическая схема: таблицы, связи, ограничения
• Внутренний уровень — физическое хранение: файлы, страницы, индексы, сжатие

Доклад: Классическая архитектура описана в стандарте ANSI/SPARC ещё в тысяча девятьсот семьдесят пятом году и состоит из трёх уровней. Наверху — внешний уровень, то есть представления для конкретных приложений. В середине — единая логическая схема с таблицами и связями. Внизу — физическое хранение: файлы, страницы, индексы. Главная идея здесь — независимость данных: администратор может добавить индекс или перенести таблицу на другой диск, и ни одна программа от этого не сломается.

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

• Обработчик запросов — разбирает текст задания и проверяет права доступа
• Оптимизатор — выбирает самый дешёвый способ получить результат
• Менеджер транзакций — следит за блокировками и изоляцией параллельной работы
• Менеджер хранения — читает и пишет страницы данных, ведёт буферный кэш
• Подсистема журналирования — фиксирует изменения и восстанавливает базу после сбоя

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

Слайд 10. Клиент-серверная модель

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

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

Слайд 11. Путь запроса к данным

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

Доклад: Проследим путь одного запроса. Клиент открывает сеанс и проходит проверку прав. Текст запроса разбирается в дерево операций. Оптимизатор выбирает план выполнения. Затем страницы читаются из буферного кэша или, если не повезло, с диска. И только потом результат уходит клиенту. Самый дорогой этап здесь — обращение к диску, поэтому система всеми силами старается ответить из оперативной памяти.

Слайд 12. Свойства надёжной транзакции

• Четыре свойства принято обозначать сокращением ACID — это признанный минимум надёжности серьёзной системы.
• 1 — Атомарность — Перевод денег либо проходит целиком, либо отменяется полностью — половины операции не бывает.
• 2 — Согласованность — После транзакции все ограничения и связи между таблицами остаются выполненными.
• 3 — Изолированность — Параллельные транзакции не видят промежуточных, ещё не зафиксированных изменений друг друга.
• 4 — Долговечность — Подтверждённые изменения переживают отключение питания: они уже записаны в журнал на диске.

Доклад: Транзакция считается надёжной, если выполняются четыре свойства, известные под сокращением ACID. Атомарность означает, что перевод денег проходит целиком или отменяется полностью. Согласованность гарантирует, что после операции все ограничения остаются выполненными. Изолированность прячет от других транзакций промежуточные изменения. Долговечность обещает, что подтверждённая операция переживёт отключение питания. Это тот минимум, без которого система не годится для учёта денег.

Слайд 13. Уровни изоляции транзакций

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

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

Слайд 14. Журнал и восстановление после сбоя

• Принцип предзаписи означает: на диск сначала уходит запись о намерении, и лишь затем сами данные.
• Благодаря журналу база после аварийного выключения поднимается за секунды и без потери подтверждённых операций.
• Запись в журнал — изменение сначала попадает в журнал предзаписи и только потом в файлы данных
• Фиксация — при подтверждении транзакции журнал принудительно сбрасывается на диск
• Контрольная точка — состояние страниц периодически сохраняется, чтобы сократить время восстановления
• Восстановление — после сбоя система повторяет подтверждённые операции и откатывает незавершённые

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

Слайд 15. Индексы и ускорение поиска

• Индекс — дополнительная структура, чаще всего сбалансированное дерево, которая позволяет найти строку, не читая всю таблицу.
• Плата за скорость чтения — замедление вставки и обновления, а также дополнительное место на диске.

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

Слайд 16. Оптимизатор запросов

• Запрос получен сервером
• Синтаксический разбор и проверка прав
• Есть подходящий индекс? — построить план полного просмотра таблицы
• Оценка стоимости планов по накопленной статистике
• Выбранный план выполнен, результат отправлен клиенту
• Один и тот же запрос можно выполнить десятками способов, и разница во времени доходит до сотен раз.
• Оптимизатор опирается на статистику: сколько строк в таблице, насколько разнообразны значения столбца.
• Если статистика устарела, система выбирает плохой план — поэтому её обновляют по расписанию.
• Разработчик может посмотреть выбранный план и понять, почему запрос работает медленно.

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

Слайд 17. Виды систем по модели данных

• Единой системы на все задачи нет: модель данных выбирают под характер нагрузки и структуру информации.
• Таблицы и связи
• Строгая схема
• Транзакции
• Учётные системы
• Гибкая структура
• Вложенные поля
• Быстрая разработка
• Каталоги товаров
• Простой доступ
• Хранение в памяти
• Высокая скорость
• Кэш и сессии
• Узлы и связи
• Поиск маршрутов
• Социальные графы
• Рекомендации

Доклад: Единой системы на все случаи жизни не существует, и модель данных выбирают под задачу. Реляционные системы дают строгую схему, связи и полноценные транзакции — это учётные системы и финансы. Документные удобны там, где структура часто меняется. Хранилища «ключ-значение» работают в памяти и держат кэш и пользовательские сессии. Графовые незаменимы, когда важны связи: маршруты, социальные графы, рекомендации.

Слайд 18. Известные системы: сравнение

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

Доклад: В таблице собраны системы, которые встречаются чаще всего. PostgreSQL — свободная реляционная система для сложной логики и аналитики, её активно применяют в государственных проектах. MySQL держит огромную долю сайтов и интернет-магазинов. Oracle Database — платное корпоративное решение для банков. SQLite вообще не требует сервера и живёт внутри мобильных приложений. MongoDB хранит документы там, где структура данных постоянно меняется.

Слайд 19. PostgreSQL и MySQL

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

Доклад: Две самые популярные свободные системы стоит сравнить подробнее. PostgreSQL строже соблюдает стандарт языка запросов, даёт собственные типы данных и расширения вплоть до работы с географией, и особенно хорош в сложной аналитике. MySQL проще в установке, исторически быстрее на типовых операциях чтения и лучше поддержан хостинг-провайдерами. Вывод простой: сложная предметная логика — PostgreSQL, массовое веб-приложение — MySQL.

Слайд 20. Задачи администратора

• Установка, обновление и настройка параметров памяти, кэша и числа соединений
• Управление учётными записями, ролями и правами доступа к таблицам
• Наблюдение за нагрузкой: медленные запросы, блокировки, заполнение диска
• Регулярное резервное копирование и учебные восстановления из копий
• Планирование роста: индексы, разбиение больших таблиц, перенос на новое оборудование

Доклад: Даже идеально выбранная система не работает сама по себе. Администратор настраивает память, кэш и число соединений, управляет учётными записями и правами, следит за медленными запросами, блокировками и свободным местом. Отдельная его обязанность — регулярные резервные копии и учебные восстановления. И наконец, он планирует рост: добавляет индексы, разбивает большие таблицы, готовит переезд на новое оборудование.

Слайд 21. Резервное копирование

• Полная копия снимается по расписанию, между полными копиями сохраняются только изменения.
• Копия, которую ни разу не разворачивали, копией не считается: проверка обязательна.
• Одна из копий должна храниться отдельно от сервера — на другой площадке или в облачном хранилище.
• Вместе с журналом предзаписи копия позволяет восстановить состояние базы на любой момент времени.
• Планирование
• Копирование
• Проверка
• Хранение
• Восстановление

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

Слайд 22. Выводы

• Система управления базами данных — это отдельное сложное программное обеспечение, а не просто способ хранить таблицы: она отвечает за целостность, скорость и доступ.
• Ключевые механизмы — транзакции с четырьмя свойствами надёжности, журнал предзаписи, индексы и оптимизатор запросов.
• Клиент-серверная модель централизует правила и защиту данных, а встраиваемые системы решают задачи одиночных приложений.
• Выбор конкретной системы определяется характером нагрузки, требованиями к транзакциям, бюджетом и опытом команды.
• Надёжная эксплуатация держится на администрировании: настройке, наблюдении, разграничении прав и проверенных резервных копиях.

Доклад: Подведу итоги. Система управления базами данных — это отдельное сложное программное обеспечение, отвечающее за целостность, скорость и разграничение доступа. Её ключевые механизмы — транзакции с четырьмя свойствами надёжности, журнал предзаписи, индексы и оптимизатор запросов. Клиент-серверная модель централизует правила, а встраиваемые системы закрывают задачи одиночных приложений. Выбор конкретной системы определяется характером нагрузки, требованиями к транзакциям и опытом команды, а надёжная работа держится на грамотном администрировании.

Слайд 23. Список литературы

• Гарсиа-Молина, Г. Системы баз данных. Полный курс : учебник / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. — Москва : Вильямс, 2003. — 1088 с.
• Дейт, К. Дж. Введение в системы баз данных : учебник / К. Дж. Дейт. — 8-е изд. — Москва : Вильямс, 2005. — 1328 с.
• Карпова, Т. С. Базы данных: модели, разработка, реализация : учебник / Т. С. Карпова. — Санкт-Петербург : Питер, 2001. — 304 с.
• Коннолли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг. — Москва : Вильямс, 2017. — 1440 с.
• Кузнецов, С. Д. Основы баз данных : учебное пособие / С. Д. Кузнецов. — Москва : Бином. Лаборатория знаний, 2007. — 484 с.

Доклад: При подготовке я опирался на классические учебники по базам данных. Это полный курс Гарсиа-Молины, Ульмана и Уидом, фундаментальное «Введение в системы баз данных» Кристофера Дейта, учебник Карповой по моделям и реализации, практическое руководство Коннолли и Бегг и основы баз данных Кузнецова. Все источники приведены по ГОСТ и расположены в алфавитном порядке.

Слайд 24. Спасибо за внимание!

Доклад: На этом моё выступление закончено. Мы прошли путь от определения до внутреннего устройства, разобрали транзакции, журнал, индексы и оптимизатор, сравнили популярные системы и обсудили работу администратора. Спасибо за внимание, готов ответить на ваши вопросы.