Классический сценарий канонического проектированияЕсть такая замечательная штука - каноническое проектирование РБД. К чему оно сводится?
- Опишите предметную область.
- Постройте на основе описаний модель сущностей и связей (вариант - классов UML).
- Превратите эту концептуальную модель в модель таблиц и атрибутов, применив правила преобразования.
- Убедитесь в нормальности (3-5НФ) полученной модели, либо доведите её до таковой.
- Превратите логическую модель в физическую, используя свойства целевой РСУБД и создайте необходимые физические структуры, опираясь на типовые запросы и нефункциональные требования.
Вот такие вроде простые 5 шагов.
Место проектирования в учебных курсахЕсли посмотрим талмуды БД-гуру, то увидим следующие типовые разделы базовых фундаментальных учебников:
- Основные понятия.
- Реляционная модель.
- Проектирование.
- SQL.
- Транзакции.
- Нереляционные БД.
С одной стороны - проектирование (а тут оно только каноническое) занимает центральное место в курсе, с другой - на него отводится не более 100 страниц из 1000 страниц тома. Неужели и правда всё так просто?
Практика показывает, что нет. Реально на этапе 1 (описание предметной области) есть два принципиально разных категории предметных областей - существующая и создаваемая. Вот только вторая тихой сапой откладывается до этапа 5.
Анализ как моделирование существующего (настоящего ) и проектирование как моделирование несуществующего (будущего)Существующая предметная область - это то, что уже есть и описание чего можно извлечь из своего жизненного опыта, интервьюирования экспертов предметной области, альбомов отраслевых моделей (которые мы рассмотрим позже), нормативной и производственной документации. Фактически построение модели структуры существующей предметной области является сугубо аналитической, а не проектировочной деятельностью, особенно если не прибегать к конструированию из альбомов типовых моделей.
Сотрудники-Отделы-Детали-Заказы-Клиенты-Документы-Рейсы - это всё сюда.
Создаваемая предметная область - это те концепции и понятия, которые нет сейчас в автоматизируемом пространстве, и которые возникнут только уже внутри системы в момент её создания. Речь идёт о структурах, которые призваны обеспечить работу ПО (системы) исходя из функциональных требований, а не существующей предметной области.
Ключевое слово-Учётная запись-Узел-Категория-Версия.
(Если всему этому есть какие-то более удобные и традиционные термины - подскажите, плиз).
Утерянное искусство проектированияТак вот, я хочу сказать, что деятельность по моделированию и созданию структур данных, содержащих информационные модели уже существующих объектов (бизнес-объектов, этапы 1-4) является довольно банальной и прямолинейной. И хотя именно ей уделяется больше всего места в учебных курсах, она не является определяющей в умении создавать промышленные системы. А это и не проектирование вовсе! А всего лишь анализ + применение правил трансформации :(
В отличие от истинного проектирования (БД) - создания структурных моделей того, чего пока нет.
В качестве примера приведу такие распространённые задачи проектирования, как
организация версионирования объектов, аудита изменений, управление метаданными, организация хранения иерархий, организация подсистемы поиска.
Конечно, кто-то может сказать, что это задачи проектирования системы вцелом, а не только проектирования БД и будет по своему прав, но я хочу напомнить, что в этих задачах правильный выбор (aka "проектирование") реляционных (и не только) структур является одним из ключевых навыков.
Но где и как этим навыкам можно научиться? Мне на ум приходит только каноническая Кнутовская "Алгоритмы и структуры данных", но не помню, чтобы там рассматривались задачи такого рода. Может вы знаете достойные стандартные источники?
