ОП.08 Основы проектирования баз данных СИЭУиП СПО 09.02.06 Тема 1 §2.2 с.7

Методическое руководство преподавателя: Анализ предметной области: сущности и свойства

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

Дисциплина ОП.08 Основы проектирования БД
Официальная тема Анализ предметной области: сущности и свойства
Регламент времени 80 минут (основной) / 60 минут (сокращенный)
Вид занятия Урок с объяснением теории
Оцениваемый результат 4-балльная шкала (рубрика в .rubrika.md)
Ключевой метод Проблемное изложение + Кейс-стади

1. Детальный поминутный тайминг учебного занятия (80 и 60 минут)

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

Этап занятия Основной регламент (80 мин) Сокращенный регламент (60 мин) Дидактический фокус и содержание работы
Этап 1. Актуализация и мотивация 5 минут 5 минут Приветствие, входная проверка связи понятий «данные/БД/СУБД» с прошлого занятия. Постановка проблемы: «Как преобразовать вербальное интервью с заказчиком в математически строгую схему?». Формулировка темы.
Этап 2. Сообщение новых знаний (Теория) 30 минут 20 минут Инфологический анализ; Сущность (Entity) vs Экземпляр (Instance); Классификация атрибутов по 3 осям (простые/составные, однозначные/многозначные, хранимые/производные); Понятие домена и целостность; Потенциальные ключи (Candidate Keys); Естественные vs суррогатные ключи. В 60-мин варианте углубленная формализация доменов выносится на практику.
Этап 3. Закрепление и тренинг 30 минут 22 минуты Работа с интерактивным рабочим листом zanyatie.html по 4 вариантам. Анализ предметных областей (Логистика, Гостиница, Библиотека, Сервисный центр), составление спецификаций сущностей, классификация атрибутов, выделение доменов и ключей.
Этап 4. Итог, рефлексия, ДЗ 15 минут 13 минут Критериальная самооценка по 4-балльной рубрике, разбор типовых ошибок аудитории, инструктаж по резервному дистанционному заданию (для пропустивших пару), фиксация данных в LocalStorage.

2. Теоретический базис: Инфологический анализ предметной области

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

Золотое правило инфологического анализа: Ошибка, допущенная на этапе выделения сущностей и атрибутов, обходится при эксплуатации в десятки раз дороже, чем ошибка в написании SQL-запроса. Если сущность спроектирована неверно, базу данных придется перестраивать заново с потерей данных.

Сущность (Entity) и Экземпляр сущности (Instance)

Сущность (Тип сущности / Entity)

Множество однотипных объектов, явлений или процессов реального мира, информация о которых имеет ценность для информационной системы.

Примеры: Студент, Автомобиль, Заказ, Книга.

Сущность определяет схему (структуру) данных.

Экземпляр сущности (Instance / Tuple)

Конкретный представитель сущности, обладающий определенным и идентифицируемым набором значений атрибутов.

Примеры: «Студент Иванов Иван, билет №102», «Тягач КамАЗ, госномер А123ВС86», «Заказ №1409 от 01.10.2026».

Экземпляр соответствует строке (кортежу) в реляционной таблице.

3. Полная классификация атрибутов и теория доменов

Атрибут (Attribute / Property) — поименованная характеристика сущности, принимающая значения из некоторого допустимого множества. В теории баз данных атрибуты классифицируются по трем независимым ортогональным осям:

Классификационная ось Типы атрибутов Определение и суть Примеры и влияние на реляционную схему
Ось 1: Структурная сложность Простые (атомарные) Не содержат составных частей, неделимы с точки зрения бизнес-логики. Возраст, Оклад, Тариф. Напрямую транслируются в столбцы таблицы.
Составные (декомпозируемые) Состоят из нескольких логически самостоятельных компонентов. ФИО (Фамилия, Имя, Отчество), Адрес (Город, Улица, Дом, Кв). В реляционной БД требуют декомпозиции на отдельные столбцы для обеспечения 1НФ.
Ось 2: Количество значений Однозначные Принимают ровно одно значение для каждого экземпляра в конкретный момент времени. Дата_рождения, VIN_код, Инвентарный_номер.
Многозначные Могут принимать набор (множество) значений для одного экземпляра. Телефоны у клиента, Авторы у книги, Категории_прав у водителя. В реляционной модели запрещено хранить через запятую в одной ячейке; требуют выделения дочерней сущности!
Ось 3: Способ получения Базовые (хранимые) Вводятся непосредственно из внешнего источника и хранятся физически. Дата_заезда, Суточный_тариф, Показания_одометра.
Производные (вычисляемые) Значение может быть однозначно рассчитано на основе других хранимых атрибутов. Стоимость = Дней * Тариф, Возраст = NOW() - Дата_рождения. Как правило, в БД не хранятся, а вычисляются запросом (или GENERATED ALWAYS AS).

Домены атрибутов (Attribute Domains)

Домен — это математическое понятие, обозначающее универсальное множество всех допустимых значений атрибута. Домен шире, чем просто технический тип данных (INT, VARCHAR) в языке SQL. Домен включает в себя:

  1. Базовый тип данных: числовой, строковый, дата/время, логический, бинарный.
  2. Смысловой диапазон (диапазонные ограничения): например, атрибут Оценка — целое число от 2 до 5; атрибут Количество_мест — целое число > 0.
  3. Формат представления (маска): например, номер телефона +7(XXX)XXX-XX-XX, VIN-код из 17 алфавитно-цифровых символов без I, O, Q.
  4. Перечислимый набор (дискретные состояния): статус заказа ENUM('Принят', 'В работе', 'Готов', 'Выдан').
  5. Ограничение определенности (Nullability): допустимость отсутствия значения (NOT NULL vs NULL).

4. Теория идентификации: Потенциальные, естественные и суррогатные ключи

В реляционной теории экземпляр сущности не имеет адреса в памяти или физического указателя. Единственный способ сослаться на конкретный экземпляр — использовать его значения атрибутов.

Потенциальные ключи (Candidate Keys)

Потенциальный ключ — это минимальный поднабор атрибутов сущности, удовлетворяющий двум фундаментальным свойствам:

Из множества потенциальных ключей проектировщик выбирает один, который объявляется первичным ключом (Primary Key, PK). Все остальные потенциальные ключи становятся альтернативными ключами (Alternate Keys, AK) и защищаются ограничением уникальности (UNIQUE).

Инженерная дилемма: Естественные vs Суррогатные ключи

Критерий сравнения Естественный ключ (Natural Key) Суррогатный ключ (Surrogate Key)
Происхождение Существует в реальном мире независимо от информационной системы (VIN автомобиля, ISBN книги, СНИЛС, паспорт). Искусственно генерируется системой специально для идентификации записи (автоинкрементный INT, BIGINT, UUID/GUID).
Семантический смысл Несет смысловую нагрузку, понятен человеку без обращения к внешним справочникам. Полностью лишен бизнес-смысла («чистый суррогат»).
Стабильность во времени Низкая: регламенты пересматриваются, форматы документов меняются, люди меняют паспорта и фамилии. Смена PK требует тяжелых каскадных обновлений! Абсолютная: суррогатный ID никогда не изменяется на протяжении всего жизненного цикла записи.
Размер и производительность Часто строковый (VARCHAR(17), CHAR(20)), что увеличивает объем индексов B-Tree и замедляет операции JOIN. Компактное целое число (4 или 8 байт), обеспечивает максимальную скорость индексации и объединения таблиц.
Рекомендация проектировщику Использовать как альтернативный ключ (UNIQUE) для бизнес-валидации. Использовать как первичный ключ (PRIMARY KEY) для реляционных связей.

5. Типовые ошибки студентов и педагогические приемы преподавателя

Топ-5 когнитивных искажений начинающих студентов:
  1. Смешение класса (сущности) и объекта (экземпляра): Студент пытается создать отдельную сущность для каждой модели («Таблица КамАЗ», «Таблица Газель»). Прием: Задать вопрос: «А если в автопарк купят Вольво, программист должен бросать все дела и дописывать код базы? Сущность — это чертеж, а машина — деталь».
  2. Превращение атрибута в изолированную пустую сущность: Создание сущности «Статус» с единственным полем «Название». Прием: Проверить, есть ли у статуса собственные атрибуты. Если нет — это доменное перечисление (ENUM).
  3. Встраивание производных атрибутов: Хранение «Итоговой суммы» наряду с «Количеством» и «Ценой». Прием: «Что произойдет, если бухгалтер исправит цену, а сумму забудет? База данных окажется во лжи».
  4. Склеивание многозначных атрибутов через запятую: Поле «Телефоны» со значением «22-33-44, 55-66-77». Прием: «Попробуйте написать запрос, который найдет клиента по номеру телефона без тормозящего сканирования LIKE %...%».
  5. Слепая вера в незыблемость паспорта или VIN: Прием: «А что если оператор опечатался в одной цифре паспорта при регистрации клиента, и на этот паспорт уже завязано 20 договоров? Суррогатный ключ спасает от катастрофы».

Педагогические приемы ведения занятия