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

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

Что такое моделирование данных?

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

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

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

Почему моделирование данных важно

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

  • Общее понимание. Построение модели заставляет разобраться в структуре данных, их связях и ограничениях, давая всем участникам проекта единое представление о данных.
  • Меньше ошибок. Чёткая модель помогает избежать неоднозначностей и неточностей до того, как они попадут в продакшн, улучшает непрерывность, надёжность и достоверность данных, выявляя проблемы на раннем этапе.
  • Общий язык. Она предоставляет общий словарь и фреймворк, или схему, для более эффективных практик управления данными в командах.
  • Более глубокие аналитические выводы. Хорошо смоделированный набор данных облегчает преобразование сырых данных в паттерны, тенденции и связи, на которые стоит реагировать.
  • Эффективное хранение и извлечение. Грамотное проектирование схемы сокращает избыточность, устраняет бесполезные данные и оптимизирует извлечение через организованное хранение, снижая стоимость и повышая производительность системы.

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

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

Три уровня моделирования данных

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

Концептуальное моделирование данных

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

Логическое моделирование данных

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

Физическое моделирование данных

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

Распространённые типы и техники моделирования данных

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

Реляционное моделирование и моделирование «сущность-связь»

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

sql
CREATE TABLE customer (
  customer_id INT PRIMARY KEY,
  name        VARCHAR(120)
);

CREATE TABLE "order" (
  order_id    INT PRIMARY KEY,
  customer_id INT REFERENCES customer(customer_id),
  total       DECIMAL(10,2)
);

Один клиент имеет много заказов, и внешний ключ на order.customer_id, это связь, воплощённая физически. Именно это единственное ограничение ER-диаграмма абстрактно фиксирует до создания какой-либо таблицы.

Размерное моделирование и схема «звезда»

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

NoSQL и документное моделирование

NoSQL-моделирование использует нереляционные базы данных для хранения полуструктурированных, гибких данных, и поскольку эти базы данных нереляционны, техника отличается от реляционного моделирования. Данные обычно хранятся как пары ключ-значение, документы или графовые структуры. При колоночном моделировании данные хранятся в столбцах, где каждое семейство столбцов группирует связанные столбцы вместе. При графовом моделировании данные хранятся как узлы и рёбра, представляющие сущности и связи между ними. Документные модели, распространённые в хранилищах вроде MongoDB, хранят связанные данные вложенными в единой записи, что подходит для данных, форма которых варьируется или меняется, именно ситуация, с которой часто сталкиваются при работе со скрапинговыми данными. Если вы выбираете между плоскими и вложенными форматами для вывода, наша заметка о JSON против CSV охватывает компромиссы, которые этот выбор влечёт.

Объектно-ориентированное и UML-моделирование

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

Моделирование потоков данных и хранилищ данных

Моделирование потоков данных описывает, как данные перемещаются между процессами, используя диаграммы, показывающие, как процесс и его подпроцессы взаимосвязаны и как данные передаются между ними. Моделирование хранилищ данных, в свою очередь, используется для проектирования хранилищ и витрин данных для бизнес-аналитики и отчётности. Оно применяет описанный выше размерный подход, организуя данные в факты и измерения и размещая их в схеме «звезда» или «снежинка», поддерживающей эффективные запросы. Эти два типа часто встречаются вместе: модели потоков данных описывают, как информация достигает хранилища, а модель хранилища описывает, как она хранится после поступления.

Процесс моделирования данных шаг за шагом

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

Шаг 1: Сбор требований

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

Шаг 2: Концептуальное моделирование

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

Шаг 3: Логическое моделирование

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

Шаг 4: Физическое моделирование

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

Советы по эффективному моделированию данных

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

Сначала определите цель и область применения

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

Привлекайте заинтересованные стороны и экспертов по предметной области

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

Следуйте устоявшимся стандартам и нотациям

Последовательно используйте отраслевые нотации моделирования, такие как диаграммы «сущность-связь» (ER), унифицированный язык моделирования (UML) или нотацию и модель бизнес-процессов (BPMN). Следование стандартной нотации делает модель ясной и понятной всем, кто будет её читать впоследствии.

Работайте совместно

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

Документируйте и доносите модель

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

Crawlbase Crawling API

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

Сценарии использования моделирования данных

Моделирование данных поддерживает широкий спектр бизнес-целей в различных отраслях. Наиболее распространённые применения включают:

  • Аналитика и предиктивное моделирование. Статистические и математические модели прогнозируют будущее на основе исторических данных для прогноза продаж, распределения ресурсов, контроля качества и планирования спроса, выявляя при этом новые паттерны и возможности.
  • Сегментация клиентов. Деление клиентов на группы по поведению, предпочтениям, демографии или другим характеристикам, популярный сценарий использования моделирования, движущий адресной стратегией.
  • Обнаружение мошенничества. Модели, изучающие нормальные паттерны, могут помечать несоответствия, например, множественные претензии сразу после начала действия полиса, для обнаружения мошенничества по мере его возникновения.
  • Рекомендательные системы. Сайты электронной коммерции, поисковые системы и стриминговые сервисы опираются на модели, созданные для быстрого доступа, хранения и обработки данных, чтобы рекомендации оставались актуальными без ущерба для производительности.
  • Обработка естественного языка. Техники вроде тематического моделирования и распознавания именованных сущностей (NER) классифицируют и извлекают смысл из текста в социальных сетях, мессенджерах и других источниках.
  • Управление данными и интеграция. Моделирование лежит в основе управления, отслеживая данные от происхождения до конечного состояния, поддерживая метаданные и обеспечивая безопасность и соответствие требованиям; оно также разрешает неоднозначности при интеграции данных из нескольких источников в единую базу.

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

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

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

Инструменты моделирования данных

Существует ряд инструментов для проектирования и поддержания моделей данных. Шесть наиболее зрелых стоит знать:

  • ERwin. Популярный инструмент моделирования с API, позволяющим разработчикам создавать нестандартный инструментарий моделирования данных и интегрировать дополнительную функциональность, адаптируя инструмент под нужды команды.
  • SAP PowerDesigner. Высоко настраиваемый, со скриптами на VBScript, JScript и PerlScript для автоматизации задач, применения правил валидации и выполнения сложных вычислений, а также шаблонами и расширениями модели для предметно-специфичных концепций.
  • Oracle SQL Developer Data Modeler. Мощный инструмент для проектирования и управления структурами данных, такими как ER-диаграммы, типы данных и ограничения; расширяем Java-плагинами и поддерживает совместное использование для согласованных моделей в командах.
  • Toad Data Modeler. Поддерживает как реляционное, так и NoSQL-моделирование, включая ER-диаграммы, обратную разработку и генерацию схем, и интегрируется с другими инструментами управления данными.
  • Microsoft Visio. Инструмент для создания диаграмм общего назначения с шаблонами для диаграмм «сущность-связь», диаграмм потоков данных и других распространённых форматов моделирования.
  • MySQL Workbench. Инструмент с открытым исходным кодом для проектирования и взаимодействия с базами данных MySQL, со встроенными ER-диаграммами, прямой и обратной разработкой и генерацией схем.

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

Итоги

Ключевые выводы

  • Моделирование данных определяет, чем являются ваши данные. Оно фиксирует сущности, атрибуты, связи и правила, чтобы данные оставались согласованными, запрашиваемыми и дешёвыми в развитии.
  • Модели детализируются через три уровня. Концептуальный фиксирует сущности и связи, логический добавляет атрибуты, ключи и ограничения, физический закрепляет реальные таблицы, столбцы, типы и индексы.
  • Техники подбираются под данные. Реляционное и ER-моделирование подходит для структурированных записей, размерные схемы «звезда» питают аналитику, а NoSQL или документное моделирование обрабатывает гибкие, переменные структуры.
  • Процесс выполняется по порядку. Собирайте требования, затем моделируйте концептуально, потом логически, потом физически, привлекая заинтересованных лиц и документируя на протяжении всего пути.
  • Моделирование структурирует скрапинговые данные. Целевая схема превращает беспорядочные веб-извлечения в чистый набор данных, готовый для аналитики, хранилищ данных и пайплайнов машинного обучения.

Часто задаваемые вопросы

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

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

Каковы три уровня моделирования данных?

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

В чём разница между концептуальной, логической и физической моделями?

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

В чём разница между реляционным и размерным моделированием?

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

Как моделирование данных помогает при веб-скрапинге?

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

Какой инструмент моделирования данных мне следует использовать?

Это зависит от проекта и вашего стека. ERwin и SAP PowerDesigner, высоко настраиваемые корпоративные варианты, Oracle SQL Developer Data Modeler и MySQL Workbench подходят командам, уже работающим в этих экосистемах баз данных, Toad Data Modeler охватывает как реляционный, так и NoSQL-подходы, а Microsoft Visio работает как универсальный выбор для создания диаграмм. Выбирайте тот, который соответствует вашей базе данных, масштабу и нотациям, которые уже использует ваша команда.

Начать создавать

Обходите любой сайт в масштабе, без борьбы с инфраструктурой.

Crawlbase берёт на себя прокси, отпечатки и CAPTCHA, чтобы ваша команда выпускала конвейеры данных вместо поддержки обвязки краулинга. 1 000 запросов бесплатно, без карты.

Самообслуживание · Звонок отдела продаж не требуется · Доступны корпоративные объёмы краулинга