Развернутый сценарий занятия: Анализ предметной области: сущности и свойства

«Здравствуйте, коллеги! Рассаживайтесь по рабочим местам. На прошлом вводном занятии мы познакомились с базовой триадой: Данные, База данных и Система управления базами данных (СУБД). Мы поняли, что СУБД — это программный двигатель, а база данных — организованное хранилище.

Но представьте жизненную ситуацию: к вам приходит директор крупной транспортной компании или главврач больницы. Он не умеет писать код, не знает команд CREATE TABLE и типов данных VARCHAR. Он говорит на языке своего бизнеса: "У меня двадцать тягачей, пятнадцать водителей, каждый день они выходят в рейсы, привозят кипы путевых листов, путают километраж и чеки на бензин!".

Как превратить этот эмоциональный поток слов в строгую, математически надежную и неизбыточную структуру таблиц? С чего начинается путь любого дата-инженера? Он начинается с инфологического анализа. Тема нашего сегодняшнего занятия — «Анализ предметной области: сущности и свойства». Запишите тему в конспекты».

«Переходим к слайду 2. Что такое инфологическая модель? Это семантическая схема реального мира, которая абсолютно независима от СУБД. Ей всё равно, где потом будут лежать данные — в PostgreSQL, Oracle или файлах JSON.

Главный строительный блок этой модели — Сущность (Entity). Посмотрите на слайд 3. Сущность — это множество однотипных объектов, явлений или процессов реального мира, о которых нам жизненно необходимо хранить данные. Это может быть материальный предмет — Автомобиль, человек — Водитель, или процесс-документ — Путевой лист.

Запомните важнейшее правило (слайд 4): не путайте Сущность и её Экземпляр! Сущность — это чертеж, класс, схема будущей таблицы (например, "Студент"). Экземпляр — это конкретная деталь по этому чертежу, строка в таблице: "Иванов Иван, зачетка №105". Создавать в базе отдельную сущность под каждого студента — тяжелейшая архитектурная ошибка!».

«Слайды 5–8. Любая сущность описывается характеристиками — атрибутами. В профессиональном проектировании атрибуты оцениваются по трем независимым осям:

1. По структуре: Простые (атомарные) и Составные. Возраст — прост и неделим. А вот ФИО или Адрес — составные! В базе данных мы обязаны декомпозировать адрес на Индекс, Город, Улицу и Дом, иначе мы никогда не сможем сделать быструю сортировку по городу или поиск по улице.

2. По кардинальности: Однозначные и Многозначные. Дата рождения — строго однозначна. А сколько номеров телефонов может быть у человека? Один, два, три! Никогда не склеивайте многозначные атрибуты через запятую в одну строку! Это нарушение первой нормальной формы. Многозначный атрибут — это повод создать отдельную связанную сущность.

3. По происхождению: Хранимые и Производные. Посмотрите на отель: у нас есть Дата заезда и Дата выезда, есть Суточный тариф. Нужно ли физически сохранять в таблицу поле "Стоимость проживания"? Нет! Потому что Стоимость = (Дата выезда - Дата заезда) * Тариф. Если мы сохраним эту сумму, а завтра гость продлит проживание на два дня, сумма перестанет сходиться. Производные поля вычисляются на лету запросами!».

«Слайды 9–13. Атрибуты не висят в воздухе. Каждому атрибуту принадлежит Домен. Домен — это не просто тип INT или VARCHAR в SQL. Домен — это смысловое ограничение предметной области: возраст человека не может быть равен -500 или +2000, хотя тип INT такое число с радостью проглотит.

И наконец, ключи. Каждый экземпляр сущности должен быть уникален. Набор атрибутов, который однозначно идентифицирует экземпляр и не содержит лишних полей, называется Потенциальным ключом (Candidate Key). Из них мы выбираем один Первичный ключ (Primary Key).

Что выбрать: Естественный ключ (VIN-код машины, паспорт гражданина) или искусственный Суррогатный ключ (ID_авто, сгенерированный СУБД)? Естественный ключ нагляден, но люди меняют паспорта, а в VIN-коде из 17 букв операторы делают опечатки. Изменение первичного ключа парализует базу. Поэтому мировой стандарт: первичным ключом делаем компактный суррогатный ID, а естественный код защищаем ограничением UNIQUE!».

«Коллеги, открываем на мониторах файл zanyatie.html. Введите свои реальные ФИО и группу в карточку учащегося.

Перед вами 4 практических кейса:

• Вариант 1 (1-й ряд): Логистический автопарк. Особое внимание — сущности Автомобиль, Водитель, Путевой лист и выбору между VIN и ID_авто.
• Вариант 2 (2-й ряд): Гостиничный комплекс. Обратите внимание на производный атрибут Стоимости и домен категории номера.
• Вариант 3 (3-й ряд): Библиотечная система. Ключевая ловушка: разграничьте абстрактную Книгу и конкретный физический Экземпляр с инвентарным номером, выделите многозначный атрибут авторов.
• Вариант 4 (4-й ряд): Сервисный центр ремонта техники. Проанализируйте статусы заказа и доменные ограничения дат приема и выдачи.

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

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

Давайте обратимся к слайду 15 нашей презентации. Посмотрите на этот классический комикс разработчиков xkcd #327: школьная база данных удалила все записи за год, потому что мама назвала сына именем Robert'); DROP TABLE Students;--.

В чем мораль этого мема? В нашей сегодняшней теме! Если бы проектировщик школы строго задал домен атрибута ФИО — указав, что имя может содержать только буквы и дефисы, и не может содержать кавычки и команды SQL — база данных была бы в абсолютной безопасности! Санитизируйте входные данные и строго задавайте домены!

Оценивание ваших работ проводится по 4-балльной закрытой рубрике: 2 балла за выделение сущностей, 1 балл за классификацию атрибутов и доменов, 1 балл за обоснование ключей. Для тех, кто пропустил пару или хочет повысить уровень, подготовлено дистанционное задание в файле domashnee_zadanie.html. Спасибо за продуктивную работу! Занятие окончено».