Проектирование базы данных: ключевые аспекты и рекомендации

Системное проектирование

Содержание проектирования баз данных и этапность

Замысел проектирования основывается на какой-либо сформулированной общественной потребности. У этой потребности есть среда её возникновения и целевая аудитория потребителей, которые будут пользоваться результатом проектирования. Следовательно, процесс проектирования баз данных начинается с изучения данной потребности с точки зрения потребителей и функциональной среды её предполагаемого размещения. То есть, первым этапом становится сбор информации и определение модели предметной области системы, а также – взгляда на неё с точки зрения целевой аудитории. В целом, для определения требований к системе производится определение диапазона действий, а также границ приложений БД.

Далее проектировщик, уже имеющий определённые представления о том, что ему нужно создать, уточняет предположительно решаемые приложением задачи, формирует их список (особенно, если в проектной разработке большая и сложная БД), уточняет последовательность решения задач и производит анализ данных. Такой процесс – тоже этапная проектная работа, но обычно в структуре проектирования эти шаги поглощаются этапом концептуального проектирования – этапом выделения объектов, атрибутов, связей.

Создание концептуальной (информационной модели) предполагает предварительное формирование концептуальных требований пользователей, включая требования в отношении приложений, которые могут и не быть сразу реализованным, но учёт которых позволит в будущем повысить функциональность системы. Имея дело с представлениями объектов-абстракций множества (без указания способов физического хранения) и их взаимосвязями, концептуальная модель содержательно соответствует модели предметной области. Поэтому в литературе первый этап проектирования БД называется инфологическим проектированием.

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

Следующим этапом проектировщик должен выбрать систему управления базой данных (СУБД), а также инструментальные средства программного характера. После этого концептуальную модель необходимо перенести в совместимую с выбранной системой управления модель данных. Но нередко это сопряжено с внесением поправок и изменений в концептуальную модель, поскольку не всегда взаимосвязи объектов между собой, отражённые концептуальной моделью, могут быть реализованы средствами данной СУБД.

Это обстоятельство определяет возникновение следующего этапа – появления обеспеченной средствами конкретной СУБД концептуальной модели. Данный шаг соответствует этапу логического проектирования (создания логической модели).

Наконец, финальным этапом проектирования БД становится физическое проектирование – этап увязки логической структуры и физической среды хранения.

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

  • инфологического проектирования,
  • формирования требований к операционной обстановке
  • выбора системы управления и программных средств БД,
  • логического проектирования,
  • физического проектирования

Ключевые из них ниже будут рассмотрены подробнее.

Нормализация базы данных

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP), должны быть нормализованы.

Базы данных с интерактивной аналитической обработкой (OLAP), позволяющие проще и быстрее выполнять анализ данных, могут быть более эффективными с определенной степенью денормализации. Основным критерием здесь является скорость вычислений. Каждая форма или уровень нормализации включает правила, связанные с нижними формами.

Первая форма нормализации

Первая форма нормализации (сокращенно 1NF) гласит, что во время логического проектирования базы данных каждая ячейка в таблице может иметь только одно значение, а не список значений. Поэтому таблица, подобная той, которая приведена ниже, не соответствует 1NF:

Возможно, у вас возникнет желание обойти это ограничение, разделив данные на дополнительные столбцы. Но это также противоречит правилам: таблица с группами повторяющихся или тесно связанных атрибутов не соответствует первой форме нормализации. Например, приведенная ниже таблица не соответствует 1NF:

Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу «Реквизиты продаж», которая будет соответствовать конкретным продуктам с продажами. «Продажи» будут иметь связь 1:M с «Реквизитами продаж».

Вторая форма нормализации

Вторая форма нормализации (2NF) предусматривает, что каждый из атрибутов должен полностью зависеть от первичного ключа. Каждый атрибут должен напрямую зависеть от всего первичного ключа, а не косвенно через другой атрибут.

Например, атрибут «возраст» зависит от «дня рождения», который, в свою очередь, зависит от «ID студента», имеет частичную функциональную зависимость. Таблица, содержащая эти атрибуты, не будет соответствовать второй форме нормализации.

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара» зависит от идентификатора продукта, но не от номера заказа:

  • Номер заказа (первичный ключ);
  • ID товара (первичный ключ);
  • Название товара.

Третья форма нормализации

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

В соответствии с 3NF, нельзя хранить в таблице любые производные данные, такие как столбец «Налог», который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:

В свое время были предложены дополнительные формы нормализации. В том числе форма нормализации Бойса-Кодда, четвертая-шестая формы и нормализации доменного ключа, но первые три являются наиболее распространенными.

Многомерные данные

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

Инфологическое проектирование

Идентификация сущностей составляет смысловую основу инфологического проектирования. Сущность здесь – это такой объект (абстрактный или конкретный), информация о котором будет накапливаться в системе. В инфологической модели предметной области в понятных пользователю терминах, которые не зависят от конкретной реализации БД, описывается структура и динамические свойства предметной области. Но термины, при этом берутся в типовых масштабах. То есть, описание выражается не через отдельные объекты предметной области и их взаимосвязи, а через:

  • описание типов объектов,
  • ограничения целостности, связанные с описанным типом,
  • процессы, приводящие к эволюции предметной области – переходу её в другое состояние.

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

  1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
  2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
  3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.

Локальные представления при методическом разделении должны, по возможности, включать в себя информацию, которой бы хватило для решения обособленной задачи или для обеспечения запросов какой-то группы потенциальных пользователей. Каждая из этих областей содержит порядка 6-7 сущностей и соответствует какому-либо отдельному внешнему приложению.

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

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений.При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа, бинарное объединение областей происходит в несколько этапов.

В ходе этого и других промежуточных этапов находит своё отражение итерационная природа проектирования, выражающаяся здесь в том, что для устранения противоречий необходимо возвращаться на этап моделирования локальных представлений для уточнения и изменения (например, для изменения одинаковых названий семантически разных объектов или для согласования атрибутов целостности на одинаковые атрибуты в разных приложениях).

Подготовка эксперимента

Вышеизложенные теоретические рассуждения хотелось бы проверить на практике – это и было целью возникшей на долгих выходных задумки. Для этого необходимо оценить скорость работы нашего «условного приложения» во всех описанных сценариях использования базы, а также рост этого времени с ростом размера социальной сети (n). Целевым параметром, который нас интересует и который мы будем замерять в ходе эксперимента, является время, затраченное «условным приложением», на выполнение одной «бизнес-операции». Под «бизнес-операцией» мы понимаем одну из следующих:

  • Добавление одного нового друга
  • Проверка, является ли пользователь А другом пользователя Б
  • Удаление одного друга

Таким образом, с учетом обозначенных в изначальной постановке требований, сценарий проверки вырисовывается следующий:

  • Запись данных. Сгенерировать случайным образом исходную сеть размером n. Для большего приближения к «реальному миру» количество друзей у каждого пользователя – так же случайная величина. Замерить время, за которое наше «условное приложение» запишет в HBase все сгенерированные данные. Потом полученное время разделить на общее количество добавленных друзей – так мы получим среднее время на одну «бизнес-операцию»
  • Чтение данных. Для каждого пользователя составить список «личностей», для которых надо получить ответ, подписан ли на них пользователь или нет. Длина списка = примерно кол-ву друзей пользователя, причем для половины проверяемых друзей ответ должен быть «Да», а для другой половины – «Нет». Проверка производится в таком порядке, чтобы ответы «Да» и «Нет» чередовались (то есть в каждом втором случае нам придется перебирать все колонки строки для вариантов 1 и 2). Общее время проверки затем разделить на количество проверяемых друзей для получения среднего времени на проверку одного субъекта.
  • Удаление данных. Удалить у пользователя всех друзей. Причем порядок удаления – случайный (то есть «перемешиваем» изначальный список, использовавшийся для записи данных). Общее время проверки затем разделить на количество удаляемых друзей для получения среднего времени на одну проверку.

Сценарии необходимо прогнать для каждого из 5 вариантов моделей данных и для разных размеров социальной сети, чтобы посмотреть, как меняется время с ее ростом. В рамках одного n связи в сети и список пользователей для проверки должны быть, естественно, одинаковыми для всех 5 вариантов.
Для лучшего понимания ниже привожу пример сгенерированных данных для n= 5. Написанный «генератор» дает на выходе три словаря ID-шников:

  • первый – для вставки
  • второй – для проверки
  • третий – для удаления

Как можно заметить, все ID, большие 10 000 в словаре для проверки – это как раз те, которые заведомо дадут ответ False. Вставка, проверка и удаление «друзей» производятся именно в указанной в словаре последовательности.

С учетом вычислительной мощности конкретного ноутбука экспериментально был выбран запуск для n = 10, 30, …. 170 – когда общее время работы полного цикла тестирования (все сценарии для всех вариантов для всех n) было еще более-менее разумным и умещалось во время одного чаепития (в среднем 15 минут).

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

Принципы проектирования баз данных

Выбор подходов к проектированию баз данных (БД) зависит от следующих факторов:

  1. сложность проекта;
  2. технологические и экономические возможности (каким оборудованием располагает проект, сколько времени будет длиться разработка, сколько сотрудников в ней будут участвовать);
  3. корпоративная IT-культура (какие операционные системы и инструменты применяются разработчиками: например, если организация-заказчик предпочитает продукцию компании Microsoft, то, скорее всего, будут выбраны такие инструменты, как Microsoft Access или Microsoft SQL Server, если у заказчика принято использовать ПО категории OpenSource, то, скорее всего, будут задействованы такие продукты, как MySQL, PostgreSQL и т.п.).

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

Замечание 1

Для малочисленных объектов с жестко заданной номенклатурой целесообразно создавать не отдельные таблицы, а ограничения, проверяющие соответствие вводимых данных на соответствие диапазону значений.

Рисунок 1. Этапы проектирования базы данных. Автор24 — интернет-биржа студенческих работ

Следующим этапом проектирования БД может стать подготовка серии диаграмм UML, результатом которой становится диаграмма классов. Между ними устанавливаются связи типов «один-к-одному», «один-к-многим», «многие-к-многим».

Рисунок 2. Диаграмма классов как промежуточный этап проектирования БД. Автор24 — интернет-биржа студенческих работ

Получив необходимую информацию, можно приступать к созданию таблиц реляционной БД. Для этого могут использоваться как визуальные средства (например, в Microsoft Access), так и текстовые запросы, выполняемые непосредственно на языке SQL.

Рисунок 3. Визуальный дизайнер для баз данных MySQL. Автор24 — интернет-биржа студенческих работ

Добавление индексов и представлений

Индекс — это отсортированная копия одного или нескольких столбцов со значениями в возрастающем или убывающем порядке. Добавление индекса позволяет быстрее находить записи. Вместо повторной сортировки для каждого запроса система может обращаться к записям в порядке, указанном индексом.

Хотя индексы ускоряют извлечение данных, они могут замедлять добавление, обновление и удаление данных, поскольку индекс нужно перестраивать всякий раз, когда изменяется запись.

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

Этапы создания базы данных

Надлежащим образом структурированная база данных:

  • Помогает сэкономить дисковое пространство за счет исключения лишних данных;
  • Поддерживает точность и целостность данных;
  • Обеспечивает удобный доступ к данным.

Основные этапы разработки базы данных:

  1. Анализ требований или определение цели базы данных;
  2. Организация данных в таблицах;
  3. Указание первичных ключей и анализ связей;
  4. Нормализация таблиц.

Рассмотрим каждый этап проектирования баз данных подробнее

Обратите внимание, что в этом руководстве рассматривается реляционная модель базы данных Эдгара Кодда, написанная на языке SQL (а не иерархическая, сетевая или объектная модели)

Добавление индексов и представлений

Индекс — это отсортированная копия одного или нескольких столбцов со значениями в возрастающем или убывающем порядке. Добавление индекса позволяет быстрее находить записи. Вместо повторной сортировки для каждого запроса система может обращаться к записям в порядке, указанном индексом.

Хотя индексы ускоряют извлечение данных, они могут замедлять добавление, обновление и удаление данных, поскольку индекс нужно перестраивать всякий раз, когда изменяется запись.

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

Логическое проектирование БД

Логическая структура БД должна соответствовать логической модели предметной области и учитывать связь модели данных с поддерживаемой СУБД

Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность

Предпочтительнее, когда естественная структура данных совпадает с представляющей её моделью. Так, например, если в данные представлены в виде иерархической структуры, то и модель лучше выбирать иерархическую. Однако на практике такой выбор чаще определяется системой управления БД, а не моделью данных. Поэтому концептуальная модель фактически транслируется в такую модель данных, которая совместима с выбранной системой управления БД.

Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.

По завершению этапа должны быть сформированы схемы баз данных обоих уровней архитектуры (концептуального и внешнего), созданные на языке определения данных, поддерживаемых выбранной СУБД.

Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:

  • либо с помощью восходящего подхода, когда работа идёт с нижних уровней определения атрибутов, сгруппированных в отношения, представляющие объекты, на основе существующих между атрибутами связей;
  • либо с помощью обратного, нисходящего, подхода, применяемого при значительном (до сотен и тысяч) увеличении числа атрибутов.

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

Структура базы данных: построение блоков

Следующим шагом будет визуальное представление базы данных. Для этого нужно точно знать, как структурируются реляционные БД. Внутри базы связанные данные группируются в таблицы, каждая из которых состоит из строк и столбцов.

Чтобы преобразовать списки данных в таблицы, начните с создания таблицы для каждого типа объектов, таких как товары, продажи, клиенты и заказы. Вот пример:

Каждая строка таблицы называется записью. Записи включают в себя информацию о чем-то или о ком-то, например, о конкретном клиенте. Столбцы (также называемые полями или атрибутами) содержат информацию одного типа, которая отображается для каждой записи, например, адреса всех клиентов, перечисленных в таблице.

Чтобы при проектировании модели базы данных обеспечить согласованность разных записей, назначьте соответствующий тип данных для каждого столбца. К общим типам данных относятся:

  • CHAR — конкретная длина текста;
  • VARCHAR — текст различной длины;
  • TEXT — большой объем текста;
  • INT — положительное или отрицательное целое число;
  • FLOAT, DOUBLE — числа с плавающей запятой;
  • BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber, который автоматически генерирует уникальный номер в каждой строке.

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

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

Атрибуты, выбранные в качестве первичных ключей, должны быть уникальными, неизменяемыми и для них не может быть задано значение NULL (они не могут быть пустыми). По этой причине номера заказов и имена пользователей являются подходящими первичными ключами, а номера телефонов или адреса — нет. Также можно использовать в качестве первичного ключа несколько полей одновременно (это называется составным ключом).

Когда придет время создавать фактическую БД, вы реализуете как логическую, так и физическую структуру через язык определения данных, поддерживаемый вашей СУБД.

Также необходимо оценить размер БД, чтобы убедиться, что можно получить требуемый уровень производительности и у вас достаточно места для хранения данных.

Денормализация

Денормализация — это умышленное изменение структуры базы, нарушающее правила нормальных форм. Обычно это делается с целью улучшения производительности базы данных.
Теоретически, надо всегда стремиться к полностью нормализованной базе, однако на практике полная нормализация базы почти всегда означает падение производительности. Чрезмерная нормализация базы данных может привести к тому, что при каждом извлечении данных придется обращаться к нескольким таблицам. Обычно в запросе должны участвовать четыре таблицы или менее.
Стандартными приемами денормализации являются: объединение нескольких таблиц в одну, сохранение одинаковых атрибутов в нескольких таблицах, а также хранение в таблице сводных или вычисляемых данных.

4.9
18
Голоса

Рейтинг статьи

SQL для системных аналитиков

Для системного аналитика, владение SQL не просто «буквы для резюме», это ключевой навык, который:

Усиливает логическое мышление. SQL требует строгого и последовательного подхода к структурированию данных. Такой подход улучшает логические навыки, что в свою очередь помогает быстрее и точнее анализировать требования.
Позволяет понимать язык разработчиков и что «под капотом» системы

Когда аналитик знает, как устроена база данных, он может разрабатывать требования, учитывающие эту структуру, что уменьшает количество ошибок и доработок в дальнейшем
То же, что и с умением проектировать БД.
Помогает обращать внимание на «узкие места» в системе, где важно продумать нефункциональные требования по нагрузке, ограничения.Понимая, как устроен запрос и какие ресурсы он потребляет, можно заранее предусмотреть необходимые ограничения. Позволяет с ходу оценивать реализуемость требований
Зная SQL, аналитик может сразу определить, насколько реализуемы требования, которые предлагает заказчик, и как они повлияют на производительность и структуру БД.

Знание SQL позволяет понимать, что происходит на встречах с разработчиками и какие технические детали они обсуждают. Даже знания базовых операторов как SELECT, WHERE, IF, JOIN уже многое дает. А когда речь идет о проектах с несколькими БД, то он лучше понимает последовательные цепочки запросов, обеспечивающие синхронизацию данных.

Определение атрибутов

Атрибут представляет свойство, описывающее сущность. Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте, должны иметь одинаковый тип и обладать одинаковыми свойствами.
В физической модели атрибуты называют колонками.
После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой базы определены некоторые атрибуты.
Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе — нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Итого

  1. Необходимо различать модель данных предметной области и модель данных приложения.

  2. Концептуальная модель данных — всегда для предметной области, физическая модель данных — всегда для приложения, логическая модель данных — может быть как для предметной области, так и для приложения.

  3. Логическая модель данных приложения зависит от типа СУБД (например, реляционная СУБД и документная СУБД), но не от конкретной СУБД (для PostgreSQL и для Oracle может использоваться одна модель). Физическая модель данных приложения зависит и от типа СУБД, и от конкретной СУБД.

  4. В зависимости от специфики проекта может составляться различный набор моделей данных.

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

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

В моих конкретных условиях он оказался оптимальным по отношения «полученная польза / затраченные усилия».

А какие виды моделей данных составляете вы в своих проектах?

P.S. Дополнение 4. Модель данных микросервиса

Модель данных предметной области никак не зависит архитектуры, в том числе наличия или отсутствия микросервисов. Но как организован переход от логической модели к физической в случае микросервисной архитектуре?

Как это было у нас. На этапе сбора требований «по классике» были составлены концептуальная и логическая модели данных предметной области.

После того, как на этапе проектирования были выделены микросервисы и определены зоны их ответственности, была сделана «нарезка» логической модели предметной области — какой микросервис будет хранить какие сущности. Это нужно для того, чтобы передать этот кусок модели (вместе с иными требованиями) той подкоманде, которая будет заниматься микросервисом. Приложение было большим, подкоманд много, некоторые из них субподрядные. Давать всем общую модель было избыточно.

Одна и та же сущность предметной области при «нарезке» могла попасть сразу в несколько микросервисов: например, сведения об организациях были нужны практически во всех микросервисах (с разным реквизитным составом).

Как назвать эту модель? С одной стороны, она остаётся логической моделью предметной области — сущности это понятия предметной области, а не таблицы, уровень детализации соответствует логической модели. С другой стороны, она уже частично привязана к реализации — то есть определён микросервис, в котором эта сущность будет имплементирована.

Таким образом, между логической моделью предметной области и моделью данных приложения (неважно, логической или физической) может существовать еще один промежуточный этап — «логическая модель данных предметной области, планируемая к реализации в рамках компонента архитектуры приложения»

Подводим итоги проектирования

Проектирование БД — процесс небыстрый и достаточно трудоёмкий. Во время проектирования надо хорошо знать предметную область, учитывать все нюансы. Вся информация должна отображаться в виде таких элементов, как объекты, атрибуты, связи, причём проектирование успешно лишь тогда, когда всё сделано максимально рационально.

Вообще, взгляды на проектирование среди разработчиков могут различаться. Некоторые игнорируют теорию, руководствуясь лишь опытом и здравым смыслом. Другие во время проектирования отводят главную роль интуиции, считая проектирование искусством, которым владеют далеко не все. Как бы там ни было, знания никогда не бывают лишними.

Да, реляционная база данных — это не более чем хранилище, где хранятся данные. Однако от того, как грамотно вы его организуете, будет зависеть стабильность работы всего приложения, где используются эти самые данные.

В заключение, добавим, что умение проектировать базы вам никогда не помешает. А научиться всему этому вы сможете на нашем курсе «Реляционные СУБД». Ждём вас!

Оцените статью