Сценарий содержит дословные формулировки прямой речи преподавателя, методические ремарки и адаптацию тайминга для двух форматов: основного (80 минут) и сокращенного (60 минут).
«Здравствуйте, уважаемые студенты! Садитесь, пожалуйста. Прошу старосту группы назвать отсутствующих... Благодарю.
Сегодня мы начинаем изучение фундаментальной дисциплины профессионального цикла — «Основы проектирования баз данных». В современном мире программной инженерии любой код — будь то веб-сервис, мобильное приложение или корпоративная ERP-система — является лишь надстройкой над данными. Код меняется, фреймворки устаревают за три года, но данные предприятий живут десятилетиями.
Давайте начнем с простого жизненного вопроса. Представьте, что вы пришли работать IT-специалистом в крупную оптовую компанию. У них 50 сотрудников, 10 000 наименований товаров и сотни заказов в день. Руководитель говорит: "Зачем нам тратить деньги на серверы баз данных и программистов? Давайте просто положим один файл Excel в общую папку в локальной сети, и пусть все менеджеры в нем работают!".
Скажите, пожалуйста, что произойдет с этим файлом уже к концу первого рабочего дня?»
(Преподаватель выслушивает гипотезы студентов: блокировка файла, перезапись чужих заказов, потеря строк, зависание при открытии).
«Совершенно верно! Файл либо заблокируется намертво первым же открывшим его пользователем в режиме "только для чтения", либо — что гораздо страшнее — начнется тихая катастрофа: менеджер Иванов запишет заказ, а менеджер Петров через секунду сохранит свой файл и напрочь затрет изменения Иванова. Это классическая аномалия потерянного обновления (Lost Update).
Именно поэтому тема сегодняшней пары — "Основные понятия теории баз данных". Мы разберем, чем данные отличаются от информации, как устроена промышленная архитектура хранения данных ANSI/SPARC, почему СУБД спасает бизнес от потери миллиардов и какие типы хранилищ существуют на рынке».
«Прежде всего, зафиксируем четкий понятийный аппарат. В обыденной речи слова "данные" и "информация" используют как синонимы, но для инженера это грубейшая ошибка.
Данные — это объективно зафиксированные факты или сигналы на носителе. Например, я напишу на доске: "39.5". Что это? Данные. Но несут ли они пользу? Нет, пока мы не знаем контекста. А вот если я добавлю: "Температура пациента в палате №4 составляет 39.5 °C" — это уже информация! Информация — это данные в прикладном контексте, которые снимают неопределенность и побуждают к действию (в данном случае — срочно вызвать врача).
Теперь о второй частой ошибке. Никогда не говорите фразы вроде: "Я скачал базу данных PostgreSQL". Вы не можете скачать базу данных с сайта разработчиков! PostgreSQL — это СУБД (Система управления базами данных). А база данных появится только тогда, когда вы создадите таблицы и наполните их сведениями.
Запомните метафору: База данных — это книги на полках библиотеки. А СУБД — это библиотекарь. Читатель не имеет права сам бегать по хранилищу и переставлять книги. Читатель отдает запрос библиотекарю на понятном языке (SQL), библиотекарь по картотеке (индексам) мгновенно находит нужную страницу, делает копию и выдает читателю, сохраняя оригинал в идеальном порядке».
«В 1975 году комитет ANSI/SPARC разработал фундаментальную модель, по которой строятся все профессиональные базы данных мира. Модель состоит из трех уровней абстракции:
1. Внешний уровень (External Level / Views). Это то, что видит конкретный пользователь или программа. Представьте электронную регистратуру поликлиники. Врач-терапевт в своем окне видит диагноз, анализы и историю болезни. Регистратор в окне записи видит ФИО, полис ОМС и свободные талоны, но диагнозы от него закрыты ради врачебной тайны и 152-ФЗ. А пациент в мобильном приложении видит только свои данные. База одна, а внешних представлений — множество!
2. Концептуальный уровень (Conceptual Level). Это единая логическая модель всей базы: сущности Пациенты, Врачи, Талоны, связи между ними и строгие бизнес-правила (например, номер СНИЛС обязан быть уникальным).
3. Внутренний уровень (Internal Level). Это физическое хранение на диске: в каких дисковых блоках по 8 килобайт лежат строки, какие B-Tree индексы построены, включено ли сжатие.
Зачем нужно такое разделение? Ради независимости данных! Если завтра сисадмин заменит жесткий диск на быстрый NVMe SSD и перестроит индексы (изменился внутренний уровень), программисту не придется переписывать ни единой строчки прикладного кода! Это называется физической независимостью данных».
«По модели хранения современные СУБД делятся на четыре основных класса:
1. Реляционные (SQL): PostgreSQL, MySQL, Oracle. Данные хранятся в строгих таблицах со связями. Это основа корпоративного учета, финансов и транзакций с гарантией ACID.
2. Документные NoSQL: MongoDB. Данные хранятся в гибких JSON-документах. Незаменимы для каталогов товаров интернет-магазинов, где у пылесоса одни характеристики, а у платья — совершенно другие.
3. Ключ-значение (Key-Value): Redis. Сверхбыстрые хранилища в ОЗУ для кэширования сессий пользователей.
4. Графовые: Neo4j. Хранят узлы и связи между ними. На них работают социальные сети (поиск друзей) и антифрод-системы банков (поиск цепочек обнальщиков).
Управляет всей этой сложнейшей экосистемой специалист высочайшей квалификации — DBA (Database Administrator). Он отвечает за резервное копирование, восстановление после сбоев, распределение памяти и безопасность».
«Перейдем к демонстрации интерактивной презентации на экране. Обратите внимание на слайды 5 и 6: перед вами наглядная схема трехуровневой модели ANSI/SPARC и таблица базовых функций СУБД.
А теперь давайте взглянем на финальный слайд 15. Это самый легендарный мем в истории информационных технологий — комикс xkcd про "Little Bobby Tables" (автор Рэндалл Манро, лицензия Creative Commons).
В комиксе мама регистрирует сына в школе и дает ему необычное имя: Robert'); DROP TABLE Students;--. Школьная программа наивно склеила это имя с SQL-запросом без валидации и параметров, в результате чего база данных послушно удалила всю таблицу студентов со всеми оценками!
В чем глубокий методический смысл этого мема? В том, что грамотная архитектура СУБД и разделение уровней абстракции требуют надежного барьера между пользовательским вводом и ядром базы данных. Если программист пренебрегает разграничением уровней ANSI/SPARC и правами пользователей — информационную систему ждет крах».
«Коллеги, открываем на ваших компьютерах файл zanyatie.html. Введите свои реальные фамилию, имя и учебную группу в шапке листа.
Перед вами 4 варианта прикладного архитектурного анализа:
— Вариант 1: Складской учет оптовой базы. Вы детально сопоставите хранение в файлах Excel с реляционной базой PostgreSQL и смоделируете аномалию Lost Update при списании остатков.
— Вариант 2: Электронная регистратура поликлиники. Вы разложите систему по трем уровням ANSI/SPARC и обоснуете защиту персональных данных по 152-ФЗ.
— Вариант 3: Каталог интернет-магазина. Вы сравните реляционную модель PostgreSQL и документную NoSQL MongoDB на примере каталога товаров с вариативными характеристиками.
— Вариант 4: Информационная система деканата. Вы спроектируете ролевую матрицу доступа (студент, преподаватель, диспетчер, администратор) и опишете действия DBA.
Ваша работа оценивается по строгой 4-балльной критериальной матрице: понятийный аппарат — 2 балла, архитектурный анализ — 1 балл, разбор контрпримера и самопроверка — 1 балл. Приступайте к выполнению!»
«Завершаем заполнение полей. Нажмите кнопку "Сохранить в хранилище", чтобы ваши ответы зафиксировались.
Давайте кратко подведем итоги. Кто из выполнявших Вариант 1 готов назвать главное последствие аномалии Lost Update? ... Верно, искажение складских остатков и финансовые убытки. А для Варианта 2 — почему регистратор не должен видеть медицинский диагноз? ... Правильно, соблюдение врачебной тайны и разделение внешних представлений в ANSI/SPARC.
Оцените свою работу в блоке самоконтроля от 1 до 4 баллов и нажмите кнопку "Печать / Экспорт в PDF". Сохраненный PDF-файл вы загружаете в электронный журнал для проверки.
Важное объявление о домашнем задании: Файл domashnee_zadanie.html является резервным дистанционным заданием. Если вы присутствовали на сегодняшней очной паре и успешно сдали рабочий лист, домашнее задание выполнять не требуется. Оно предназначено исключительно для тех студентов, кто пропустил пару по болезни или уважительной причине, либо если я выдам индивидуальное персональное назначение.
Всем спасибо за активную инженерную работу на паре! До свидания!»