Презентация на тему «Базы данных и язык SQL»

Слайд 1. Базы данных и язык SQL

• Как устроено хранение данных в информационных системах и с помощью чего им управляют

Доклад: Здравствуйте! Тема нашей презентации — «Базы данных и язык SQL». Мы разберём, как устроено упорядоченное хранение информации в современных информационных системах и с помощью какого инструмента ею управляют. Постараемся пройти путь от базовых определений до практических приёмов проектирования и защиты данных.

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

• Введение
• База данных и система управления
• Реляционная модель данных
• Классификация баз данных
• Три уровня представления данных
• Этапы развития технологии
• Создатели теории баз данных
• Ключи и связи между таблицами
• Нормализация отношений
• Язык структурированных запросов
• Как строится запрос на выборку
• Соединения таблиц
• Агрегатные функции и группировка
• Свойства транзакции
• Индексы и скорость запросов
• Табличные и документные хранилища
• Защита данных
• Этапы проектирования базы данных
• Базы данных в работе организаций
• Выводы
• Список литературы

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

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

• Практически любая информационная система — от банковского приложения до электронного дневника — держится на базе данных, поэтому умение проектировать её стало обязательной частью подготовки специалиста.
• Мировой объём создаваемых данных вырос с 2 зеттабайт в 2010 году до примерно 180 зеттабайт в 2025 году, и без упорядоченного хранения работать с таким потоком невозможно.
• Язык структурированных запросов SQL остаётся отраслевым стандартом более сорока лет и поддерживается всеми промышленными системами управления базами данных.
• Ошибки проектирования обходятся дороже всего: неверная структура таблиц приводит к потере целостности данных и переписыванию системы целиком.

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

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

• База данных — именованная совокупность взаимосвязанных данных, организованных по определённым правилам и хранимых во внешней памяти компьютера.
• Система управления базами данных — программный комплекс, который создаёт базу, обеспечивает доступ к ней, поддерживает целостность и разграничивает права пользователей.
• Разделение труда простое: прикладная программа формулирует, ЧТО нужно получить, а система управления сама решает, КАК физически найти данные на диске.
• Именно система управления берёт на себя резервное копирование, восстановление после сбоя и одновременную работу тысяч пользователей с одними и теми же таблицами.

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

Слайд 5. Реляционная модель данных

• Реляционная модель, предложенная Эдгаром Коддом в 1970 году, представляет все данные единообразно — в виде таблиц-отношений, состоящих из строк-записей и столбцов-атрибутов. Никаких «указателей» и «путей доступа»: связь между таблицами создаётся только совпадением значений в полях.
• 1970 — год публикации модели — Статья Кодда о реляционной модели данных
• 3 — базовых понятия — Отношение, кортеж, атрибут
• 8 — операций алгебры — Объединение, выборка, проекция, соединение и другие

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

Слайд 6. Классификация баз данных

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

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

Слайд 7. Три уровня представления данных

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

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

Слайд 8. Этапы развития технологии

• Технология прошла путь от жёстко связанных структур к гибким табличным моделям.
• Каждое поколение решало проблему предыдущего: дублирование, негибкость, ограничения масштаба.
• 1960-е — первые иерархические системы
• 1970 — реляционная модель Кодда
• 1974 — прототип языка запросов в компании Ай-Би-Эм
• 1986 — первый международный стандарт языка
• 1996 — рождение свободной системы PostgreSQL
• 2009 — волна нереляционных хранилищ

Доклад: История технологии — это последовательное преодоление ограничений. Шестидесятые дали первые иерархические системы, жёстко связанные и негибкие. 1970 год — реляционная модель Кодда, 1974-й — прототип языка запросов в лабораториях компании Ай-Би-Эм, 1986-й — первый международный стандарт. В 1996 году появилась свободная система PostgreSQL, а к 2009 году веб-нагрузки породили волну нереляционных хранилищ.

Слайд 9. Создатели теории баз данных

• Эдгар Франк Кодд, 1923–2003, Автор реляционной модели данных и правил, которым обязана отвечать реляционная система управления.
• Дональд Чемберлин, род. 1944, Один из двух создателей языка структурированных запросов и первой его реализации в системе Систем Ар.
• Майкл Стоунбрейкер, род. 1943, Руководитель проектов Ingres и Postgres, лауреат премии Тьюринга 2014 года за вклад в системы баз данных.

Доклад: За теорией стоят конкретные люди. Эдгар Франк Кодд, математик компании Ай-Би-Эм, придумал реляционную модель и сформулировал правила, которым обязана отвечать реляционная система. Дональд Чемберлин вместе с Реймондом Бойсом создал язык структурированных запросов и его первую реализацию в системе Систем Ар. Майкл Стоунбрейкер руководил проектами Ingres и Postgres и в 2014 году получил премию Тьюринга за вклад в развитие систем баз данных.

Слайд 10. Ключи и связи между таблицами

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

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

Слайд 11. Нормализация отношений

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

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

Слайд 12. Язык структурированных запросов

• Определение данных — создание, изменение и удаление таблиц, схем и ограничений
• Манипулирование данными — вставка, изменение, удаление и выборка строк
• Управление доступом — выдача и отзыв прав на объекты базы данных
• Управление транзакциями — фиксация и откат группы связанных изменений

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

Слайд 13. Как строится запрос на выборку

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

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

Слайд 14. Соединения таблиц

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

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

Слайд 15. Агрегатные функции и группировка

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

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

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

• Атомарность — выполняется всё или ничего
• Согласованность — правила целостности не нарушаются
• Изолированность — транзакции не мешают друг другу
• Долговечность — результат переживёт отключение питания

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

Слайд 17. Индексы и скорость запросов

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

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

Слайд 18. Табличные и документные хранилища

• Реляционные базы десятилетиями были безальтернативным решением, но рост веб-нагрузок породил нереляционные хранилища. Сравнение помогает понять, где какой подход уместнее.
• Жёсткая схема таблиц, заданная заранее
• Строгие транзакции и ссылочная целостность
• Единый стандартный язык запросов
• Масштабирование преимущественно вертикальное
• Финансы, учёт, отчётность, документооборот
• Гибкая схема, поля добавляются на лету
• Часто жертвуют строгой согласованностью ради скорости
• Свой интерфейс запросов у каждого продукта
• Горизонтальное масштабирование на сотни узлов
• Журналы событий, кэш, каталоги, потоковые данные

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

Слайд 19. Защита данных

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

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

Слайд 20. Этапы проектирования базы данных

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

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

Слайд 21. Базы данных в работе организаций

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

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

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

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

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

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

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

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

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

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