Построение реляционной модели
Смотришь иной раз на чужую реляционную модель и думаешь: ну вот как они столько сущностей, атрибутов и связей напридумывали? Что у них там в голове творится, для чего понадобилась такая сложная схема?
Сложная реляционная модель
А они тебе: «И это только четверть от модели, потому что ты смотришь на старую версию, а новую мы в графическом виде и не рисовали». И точно: в базе данных в четыре раза больше таблиц, чем на картинке.
На моей практике самая сложная модель данных состояла из двух сотен сущностей. Рисовать её никто не решился. Была только упрощённая модель со связями без уточнения атрибутов. Проблема даже не сущностях, а связях между ними. Схему может построить даже phpMyAdmin последних версий, но бесконечное количество нитей-связей превращают картинку в паутину или клубок.
Навигация по пунктам плана
• Предметная область (Domain Knowledge) • Базовые сущности (Primary Entities) • Роли (Roles) • Сценарии использования (Use Cases) • Примеры •
Бывает, что количество сущностей небольшое, а схемы отношений между ними легко обозримая, даже можно не рисовать. Трёх сущностей и трёх связей хватит, чтобы сделать персональный микро-блог или фото-галерею. Ещё две сущности и две связи — если хотим добавить теги. Вся схема при некотором уровне навыков проектирования легко укладывается в голове и реализуется в проекте. Ещё две сущности и три отношения — и готовы вложенные категории. Ещё … Стоп. Уже не вмещается в лист.
Тут, неверное, уместно было бы отправить читать толстые книги по UML, реляционной алгебре и теории баз данных. Но я попытаюсь объяснить практические методы, которыми пользуюсь сам, из моего опыта. Нужна некоторая техника построения модели. Если нужны книги — они в конце статьи.
Прежде всего надо обозначить базовые сущности, с которых начнётся построение модели. В этом поможет анализ предметной области.
Предметная область (Domain Knowledge)
Предметная область — часть реального мира, с которой предстоит работать в рамках практической задачи, то есть реализовать в виде прикладной программы или веб приложения. Например, это может быть объект или процесс некоторой деятельности человека. Нужно найти и перечислить их. Назову это извлечением сущностей (не думаю что это устоявшийся термин). В процессе извлечения обычно принимают специалисты, которые уже работают в этой предметной области. Специалисты описывают, с чем они работают, что это из себя представляет, как они сами могут отличить одно от другого, как они взаимодействуют с объектами и между собой, какими данными обмениваются, какими протоколами пользуются.
Слишком мутно, да?
Рассмотрю обычную школьную библиотеку. Специалистами будут библиотекари и ученики. Некоторым специалистам может быть всего 7 лет 🙂
Предположим, что я пообщался со специалистами и выяснил, что
• объектами деятельности являются книги и читатели
• процессами — регистрация читателей и учёт книг
• протоколами — регистрация нового читателя, регистрация выданной книги в карточке читателя, регистрация акта на списание ветхих книг
Базовые сущности (Primary Entities)
Чтобы не углубляться в теорию, покажу сущности и процессы на примере той же библиотеки. Определю их на основе личного опыта пользования библиотекой:
- Книги имеют следующие атрибуты, которые позволяют отличить одну книгу от другой: название, имя автор, название издательства, год выпуска, код ISBN; для переводных книг также важны оригинальное название и язык перевода; качество книги можно описать такими атрибутами как тип обложки, наличие схем, иллюстраций, цветных врезок и приложений на дисках
- Читатели имеют имя, адрес, дату рождения
- В процессе регистрации читателя его данные заносятся в алфавитную карточку, чтобы можно было найти человека по имени
- Процесс выдачи книги выполняется по следующему протоколу: выполняется запись в книжный формуляр, который затем вкладывается в карточку читателя
- В процессе возврата книги книжный формуляр книги извлекается из карточки читателя
Возможно, принцип деятельности библиотеки намного сложнее. Упрощение моделей — определённый навык. Не надо хранить больше сущностей, чем требуется для решения практических задач. Не нужно пытаться описать сущности лишними атрибутами, которые ни на что не влияют и которые ты не знаешь, как определить. Возможно их как-то можно применить, но пока ты не придумал что делать с этой информацией — не добавляй её в модель.
Например, подумай — тебе точно нужно хранить список музыкальных инструментов, на которых умеет играть читатель библиотеки? Как ты будешь это использовать? А как собирать такие сведения? А как будешь поддерживать их актуальность? С моей точки зрения, это лишняя информация.
Тебе понятен принцип выделения сущностей, которым я пользуюсь?
Показать на твоём примере? Присылай.
Хорошо, теперь есть объекты, процессы, протоколы, что в итоге даёт набор базовых сущностей в новой реляционной модели. Надо определить, кто будет работать с этой моделью в твоей прикладной программе или через программный интерфейс (API).
С моделью школьной библиотеки мог бы работать библиотекарь. Да, в модели учтена базовая сущность «читатель», но он обычно не взаимодействует напрямую с этой моделью. Хотя бывает всякое — может быть, у библиотеки есть поисковая система, чтобы читатели искали книги.
Далее нужно определить, бывают ли пользователи с разными ролями.
Роли (roles)
Надо подумать, какими возможностями должны обладать пользователи. В этом помогают должностные инструкции, в которых прописаны обязанности сотрудников на разных должностях. Если он должен что-то делать, значит надо дать ему такую возможность. Список таких должностей и мог бы стать списком ролей. Возможно, что обязанности пересекаются или исполняются одним человеком, но правильнее было бы предусмотреть, что эти люди могут работать независимо.
Если если нет должностных инструкций, я бы расспросил специалистов, какие у них есть обязанности. Если обязанностей нет, то выслушал бы их пожелания на тему «Что бы они хотели делать«. Все эти «хотелки» и фантазии анализируются, и на их основе строится предположение о ролях.
Я не читал должностные инструкции библиотек и вот моё предположение о списке ролей: один библиотекарь регистрирует читателей, ищет задолжников и обзванивает их, другой — выдаёт книги и принимает обратно, ещё один занимается пополнением фонда и списанием ветхих книг. Возможно это всё один человек, но у него эти три роли.
- библиотекарь регистрирует читателя
- библиотекарь выдаёт книгу читателю
- библиотекарь принимает книгу обратно от читателя
- сотрудник по работе с должниками ищет читателей-задолжников
- сотрудник по работе с должниками обзванивает читателей-задолжников
- сотрудник по работе с фондом регистрирует новые книги
- сотрудник по работе с фондом списывает ветхие книги
На самом деле я перечислил сценарии использования, то есть описания взаимодействия пользователей с базовыми сущностями.
Сценарии использования (Use Cases)
Рассмотрение каждого отдельного сценария использования может повлечь за собой создание новых сущностей, добавления атрибутов в сущности, создание связей между ними.
• библиотекарь выдаёт книгу читателю: я бы предположил, что появляется сущность «ВыданныеКниги» с указанием связи с «Читатель» и «Книга».
• сотрудник по работе с должниками ищет читателей-задолжников: я бы предположил, что в сущности «ВыданныеКниги» должен быть атрибут «Дата возврата»
• сотрудник по работе с должниками обзванивает читателей-задолжников: я бы предположил, что в сущности «Читатель» должен быть атрибут «КонтактныйТелефон»
• сотрудник по работе с книжным фондом списывает ветхие книги: я бы предположил, что в сущности «Книга» может быть признак «Ветхая», который косвенным образом можно попробовать вычислить, если есть атрибуты «Дата поступления в библиотеку» + «Срок службы» или «Количество раз выдано на руки» + «Лимит выдачи»
Такой принцип добавления сущностей, атрибутов и связей ясен? Если нет — задавай вопросы в комментариях.
Примеры
Постепенное введение новых базовых сущностей, ролей, сценариев поведения приводит к постепенному нарастанию модели. Вот пример модели базы данных о музыкальных треках, альбомах и исполнителях MusicBrainz:
Пример построения реляционной модели для OpenSource проекта Diglot, который мы разрабатываем с группой курсантов по программе наставничества при изучении веб-технологий Твой веб-ментор.
Ссылка на видео: youtube.com
В видео используются документ Google Doc и сервис проектирования реляционных моделей Vertabelo.
Полезные ссылки
- Книга «UML. Основы. Краткое руководство по стандартному языку объектного моделирования» для тех, кто заинтересовался понятиями Roles и Use Cases
- Старые, немного туманные, но полезные статьи «Основы проектирования реляционных баз данных«
