Этапы проектирования: от задумки до реализации

Базы данных. этапы проектирования. создание бд. Системное проектирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключи

Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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

Определение ограниченных контекстов

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

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

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

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

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

В книге Проблемно-ориентированное проектирование Эрик Эванс описывает шаблоны по поддержке целостности модели предметной области при взаимодействии с другим ограниченным контекстом. Одним из основных принципов микрослужб является то, что службы обмениваются данными через четко определенные API. Этот подход соответствует двум шаблонам, которые Эванс называет открытой службой размещения и опубликованным языком. Идея открытой службы размещения заключается в том, что подсистема определяет формальный протокол (API), через который другие подсистемы могут взаимодействовать с ней. Опубликованный язык расширяет эту идею, публикуя API в форме, которую другие команды могут использовать для написания клиентов. В статье проектирование интерфейсов API для микрослужбмы поговорим об использовании спецификации OpenAPI (прежнее название — Swagger) для определения независимых от языка описаний интерфейсов для интерфейсов API, выраженных в формате JSON или YAML.

В оставшейся части этого руководства мы сконцентрируемся на ограниченном контексте доставки.

Физическое проектирование БД

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

Принцип декомпозиции

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

СоставIDEF0-модели состоят из трех типов документов:

  1. · графических диаграмм(главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения)
  2. · текста(используется для объяснений и уточнений характеристик, потоков, внутриблочных соединений и т.д.)
  3. · глоссария (предназначен для определения аббревиатур, ключевых слов и фраз, используемых в качестве имен и меток на диаграммах)

Эти документы имеют перекрестные ссылки друг на друга. В методологии IDEF0 существует 6 типов отношений между блоками в пределах одной диаграммы:

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

MVCC — MultiVersion Concurrency Control

zr1(y)yyy

Как это работает?

  • Когда мы пошли исполнять транзакцию t1, имеется чтение x, т.е. самой изначальной версии.
  • Дальше в t2 мы начинаем записывать y другой версии, потому что он был изменен.
  • В транзакции t1, которая началась раньше, чем мы начали записывать y, до сих пор видно предыдущую версию y, поскольку t2 еще не завершилась, и мы и спокойно начать с ней работать.
  • Поскольку транзакция t1 заканчивается раньше, чем w2(y2), то произойдет перечитываниеy,и после этого в транзакции t выполнится нормальная работа, а другая транзакция просто нормально завершится.

yw2yt1xy

  • В MySQL он внутри InnoDB,
  • В PostgreSQL это отдельная директория, которая наконец в версии 10 стала называться WAL вместо PGX-Log;
  • В Oracle это называется Redo Log;
  • В DB2 — WAL.

Анализ нормальных форм

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

Все 9 таблиц базы данных находятся по меньшей мере в первой нормальной форме, так как:

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

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

Следовательно, все таблицы находятся и во второй нормальной форме.

Во всех таблицах не обнаружено и транзитивной зависимости – функциональной зависимости одного неключевого атрибута от другого неключевого атрибута. Следовательно, все 9 таблиц базы данных находятся в третьей нормальной форме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вступление

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

В этой статье и далее мы рассмотрим следующие шаги, применяя их к приложению доставки помощью Дронов:

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

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

В рамках ограниченного контекста примените тактические шаблоны DDD, чтобы определить сущности, статистические выражения и службы предметных областей.

На основе результатов предыдущего шага идентифицируйте микрослужбы в своем приложении.

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

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

По мере развития приложения можно разбить службу на несколько небольших служб.

Эта статья не предназначена для демонстрации полного и исчерпывающего анализа предметной области. Мы намеренно сохранили пример кратко, чтобы продемонстрировать основные моменты. Общие сведения о проблемно-ориентированном проектировании можно найти в одноименной книге Эрика Эванса (Eric Evans), в которой был впервые представлен этот термин. Другим хорошим справочником является книга Вона Вернона (Vaughn Vernon) Реализация методов предметно-ориентированного проектирования.

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