Архитектура данных
Архитектура данных отвечает на вопрос, как информация системы хранится, передаётся и поддерживает целостность. Она находится между предметным смыслом и техническим хранением. Поэтому нельзя просто сказать: “каждый класс станет таблицей”. Иногда это сработает, но часто приведёт к плохому решению.
Прямого соответствия “один концептуальный класс — одна таблица” может не быть. Возможны разные варианты:
- один предметный объект хранится в нескольких таблицах;
- несколько простых предметных понятий объединяются в одну структуру хранения;
- связь между объектами становится внешним ключом;
- связь многие-ко-многим становится таблицей связи;
- объект связи получает собственные атрибуты;
- часть атрибутов не хранится, а вычисляется;
- часть данных приходит из внешней системы и хранится только как ссылка.
Связи из концептуальной модели требуют отдельного анализа. Ассоциация один-ко-многим может стать внешним ключом. Связь многие-ко-многим обычно требует таблицы связи. Если сама связь имеет атрибуты, например дата назначения роли или количество товара в позиции заказа, она может стать отдельной сущностью хранения. Композиция может подсказать зависимость жизненного цикла, но не всегда напрямую определяет физическое хранение.
Архитектура данных также связана с ограничениями. Некоторые бизнес-правила могут быть отражены как ограничения целостности, уникальности или допустимых значений. Другие правила нельзя выразить только на уровне данных и нужно проверять в программной логике.
Данные различаются по назначению:
| Вид данных | Назначение | Пример |
|---|---|---|
| Основное состояние | хранит актуальные предметные объекты | заказ, заявка, запись |
| Справочные данные | задают допустимые значения | типы заявок, статусы, роли |
| Журнал | фиксирует историю изменений | смена статуса, действие пользователя |
| События | передают факт во времени | заказ оплачен, запись отменена |
| DTO | переносит данные через интерфейс | ответ API со списком интервалов |
| Отчётные данные | поддерживают аналитику | количество заявок по статусам |
Отдельно важно понимать источник истины. Если расписание преподавателей хранится во внешней системе, проектируемая ИС может только читать его или хранить локальную копию. Эти решения влияют на синхронизацию, ошибки, актуальность данных и ответственность за изменения.
При этом архитектура данных не должна появляться раньше предметного анализа. Если сначала проектировать таблицы, легко принять техническую структуру за смысловую. Например, таблица users может хранить и студентов, и преподавателей, и администраторов, но в предметной модели это разные роли с разными правилами.
В рамках курса достаточно показать мост: какие предметные объекты нужно хранить, какие связи требуют особого внимания, какие ограничения целостности вытекают из правил и где технические формы данных отличаются от концептуальных объектов.
Для учебного проекта достаточно явно показать несколько решений: какие объекты хранятся постоянно, какие данные являются справочниками, нужна ли история изменений, какие связи требуют таблицы связи или отдельного объекта, какие данные приходят из внешней системы. Этого уже достаточно, чтобы не путать предметную модель с физическим хранением.