Основное назначение моделей – это облегчение ориентации в пространстве данных и помощь в выделении деталей, важных для развития бизнеса. В современных условиях для успешного ведения бизнеса совершенно необходимо иметь четкое понимание связей между различными компонентами и хорошо представлять себе общую картину организации. Идентификация всех деталей и связей с помощью моделей позволяет наиболее эффективно использовать время и инструменты организации работы компании.
Под моделями данных понимаются абстрактные модели, описывающие способ представления данных и доступ к ним. Модели данных определяют элементы данных и связи между ними в той или иной области. Модель данных – это навигационный инструмент как для бизнес-, так и для IT-профессионалов, в котором используется определенный набор символов и слов для точного объяснения определенного класса реальной информации. Это позволяет улучшить взаимопонимание внутри организации и, таким образом, создать более гибкую и стабильную среду для работы приложений.
3. Шаблон бизнес-модели
Модель данных однозначно определяет значение данных, которые в данном случае представляют собой структурированные данные (в противоположность неструктурированным данным, таким как, например, изображение, бинарный файл или текст, где значение может быть неоднозначным).
Как правило, выделяются модели более высокого уровня (и более общие по содержанию) и более низкого (соответственно, более детальные). Верхний уровень моделирования – это так называемые концептуальные модели данных (conceptual data models), которые дают самую общую картину функционирования предприятия или организации. Концептуальная модель включает основные концепции или предметные области, критичные для функционирования организации; обычно их количество не превышает 12-15. Такая модель описывает классы сущностей, важных для организации (бизнес-объекты), их характеристики (атрибуты) и ассоциации между парами этих классов (т.е. связи). Поскольку в бизнес-моделировании терминология еще окончательно не устоялась, в различных англоязычных источниках концептуальные модели данных могут также носить название subject area model (что можно перевести как модели предметных областей) или subject enterprise data model (предметные корпоративные модели данных).
Следующий иерархический уровень – это логические модели данных (logical data models). Они также могут называться корпоративными моделями данных или бизнес-моделями. Эти модели содержат структуры данных, их атрибуты и бизнес-правила и представляют информацию, используемую предприятием, с точки зрения бизнес-перспективы.
В такой модели данные организованы в виде сущностей и связей между ними. Логическая модель представляет данные таким образом, что они легко воспринимаются бизнес-пользователями. В логической модели может быть выделен словарь данных – перечень всех сущностей с их точными определениями, что позволяет различным категориям пользователей иметь общее понимание всех входных и информационных выходных потоков модели. Следующий, более низкий уровень моделирования – это уже физическая реализация логической модели с помощью конкретных программных средств и технических платформ.
Моделирование данных за 9 минут
Логическая модель содержит детальное корпоративное бизнес-решение, которое обычно принимает форму нормализованной модели. Нормализация – это процесс, который гарантирует, что каждый элемент данных в модели имеет только одно значение и полностью и однозначно зависит от первичного ключа. Элементы данных организуются в группы согласно их уникальной идентификации. Бизнес-правила, управляющие элементами данных, должны быть полностью включены в нормализованную модель с предварительной проверкой их достоверности и корректности. Например, такой элемент данных, как Имя клиента, скорее всего, будет разделен на Имя и Фамилию и сгруппирован с другими соответствующими элементами данных в сущность Клиент с первичным ключом Идентификатор клиента.
Логическая модель данных не зависит от прикладных технологий, таких как база данных, сетевые технологии или инструменты отчетности, и от средств их физической реализации. В организации может быть только одна корпоративная модель данных. Логические модели обычно включают тысячи сущностей, связей и атрибутов. Например, модель данных для финансовой организации или телекоммуникационной компании может содержать порядка 3000 отраслевых понятий.
Важно различать логическую и семантическую модель данных. Логическая модель данных представляет корпоративное бизнес-решение, а семантическая – прикладное бизнес-решение. Одна и та же корпоративная логическая модель данных может быть реализована с помощью различных семантических моделей, т.е. семантические модели могут рассматриваться как следующий уровень моделирования, приближающийся к физическим моделям. При этом каждая из таких моделей будет представлять отдельный «срез» корпоративной модели данных в соответствии с требованиями различных приложений. Например, в корпоративной логической модели данных сущность Клиент будет полностью нормализована, а в семантической модели для витрины данных может быть представлена в виде многомерной структуры.
У компании может быть два пути создания корпоративной логической модели данных: строить ее самостоятельно или воспользоваться готовой отраслевой моделью (industry logical data model). В данном случае различия в терминах отражают лишь разные подходы к построению одной и той же логической модели.
В том случае, если компания самостоятельно разрабатывает и внедряет собственную логическую модель данных, то такая модель, как правило, носит название просто корпоративной логической модели. Если же организация решает воспользоваться готовым продуктом профессионального поставщика, то тогда можно говорить об отраслевой логической модели данных.
Последняя представляет собой готовую логическую модель данных, с высокой степенью точности отражающую функционирование определенной отрасли. Отраслевая логическая модель – это предметно-ориентированный и интегрированный вид всей информации, которая должна находиться в корпоративном Хранилище данных для получения ответов как на стратегические, так и на тактические бизнес-вопросы.
Как и любая другая логическая модель данных, отраслевая модель не зависит от прикладных решений. Она также не включает производные данные или другие вычисления для более быстрого извлечения данных. Как правило, большинство логических структур такой модели находят хорошее воплощение в ее эффективной физической реализации. Такие модели разрабатываются многими поставщиками для самых различных областей деятельности: финансовой сферы, производства, туризма, здравоохранения, страхования и т.д.
Отраслевая логическая модель данных содержит информацию, общую для отрасли, и поэтому не может быть исчерпывающим решением для компании. Большинству компаний приходится увеличивать модель в среднем на 25% за счет добавления элементов данных и расширения определений. Готовые модели содержат только ключевые элементы данных, а остальные элементы должны быть добавлены к соответствующим бизнес-объектам в процессе установки модели в компании.
Отраслевые логические модели данных содержат значительное количество абстракций. Под абстракциями имеется в виду объединение аналогичных понятий под общими названиями, такими как Событие или Участник. Это добавляет отраслевым моделям гибкости и делает их более унифицированными. Так, понятие События применимо ко всем отраслям.
Специалист в области бизнес-аналитики (Business Intelligence) Стив Хобермэн (Steve Hoberman) выделяет пять факторов, которые необходимо принимать во внимание при решении вопроса о приобретении отраслевой модель данных. Первый – это время и средства, необходимые для построения модели. Если организации необходимо быстро добиться результатов, то отраслевая модель даст преимущество. Использование отраслевой модели не может немедленно обеспечить картину всей организации, но способно сэкономить значительное количество времени. Вместо собственно моделирования время будет потрачено на связывание существующих структур с отраслевой моделью, а также на обсуждение того, как лучше ее настроить под нужды организации (например, какие определения должны быть изменены, а какие элементы данных – добавлены).
Второй фактор – это время и средства, необходимые для поддержания модели в работоспособном состоянии. Если корпоративная модель данных не является частью методологии, которая позволяет следить за соблюдением ее точности и соответствия современным стандартам, то такая модель очень быстро устаревает. Отраслевая модель данных может предотвратить риск такого развития событий, поскольку она поддерживается в обновленном состоянии за счет внешних ресурсов. Безусловно, изменения, происходящие внутри организации, должны отражаться в модели силами самой компании, но отраслевые перемены будут воспроизводиться в модели ее поставщиком.
Третий фактор – опыт в оценке рисков и моделировании. Создание корпоративной модели данных требует квалифицированных ресурсов как со стороны бизнеса, так и IT-персонала. Как правило, менеджеры хорошо знают либо работу организации в целом, либо деятельность конкретного отдела.
Лишь немногие их них обладают как широкими (в масштабах всей компании), так и глубокими (в рамках подразделений) знаниями о своем бизнесе. Большинство менеджеров обычно хорошо знают только одну область. Поэтому, для того чтобы получить общекорпоративную картину, требуются существенные бизнес-ресурсы. Это увеличивает и требования к IT-персоналу.
Чем больше бизнес-ресурсов требуется для создания и тестирования модели, тем более опытными должны быть аналитики. Они должны не только знать, как получить информацию от бизнес-персонала, но также уметь находить общую точку зрения в спорных областях и быть способными представлять всю эту информацию в интегрированном виде. Тот, кто занимается созданием модели (во многих случаях это тот же аналитик), должен обладать хорошими навыками моделирования. Создание корпоративных логических моделей требует моделирования «для будущего» и способности конвертировать сложный бизнес в буквальном смысле «в квадраты и линии».
С другой стороны, отраслевая модель позволяет использовать опыт сторонних специалистов. При создании отраслевых логических моделей используются проверенные методологии моделирования и коллективы опытных профессионалов, для того чтобы избежать распространенных и дорогостоящих проблем, которые могут возникнуть при разработке корпоративных моделей данных внутри самой организации.
Четвертый фактор – существующая инфраструктура приложений и связи с поставщиками. Если организация уже использует много инструментов одного и того же поставщика и имеет налаженные связи с ним, то имеет смысл и отраслевую модель заказывать у него же. Такая модель сможет свободно работать с другими продуктами этого же поставщика.
Пятый фактор – внутриотраслевой обмен информацией. Если компании нужно осуществлять обмен данными с другими организациями, работающими в той же области, то отраслевая модель может быть очень полезна в этой ситуации. Организации внутри одной и той же отрасли пользуются схожими структурными компонентами и терминологией. В настоящее время в большинстве отраслей компании вынуждены обмениваться данными для успешного ведения бизнеса.
Наиболее эффективны отраслевые модели, предлагаемые профессиональными поставщиками. Высокая эффективность их использования достигается благодаря значительному уровню детальности и точности этих моделей. Они обычно содержат много атрибутов данных. Кроме того, создатели этих моделей не только обладают большим опытом моделирования, но и хорошо разбираются в построении моделей для определенной отрасли.
Отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход.
Отраслевая модель данных, помимо связей с уже существующими системами, дает большие преимущества при осуществлении общекорпоративных проектов, таких как планирование ресурсов предприятия (Enterprise Resource Planning, ERP), управление основными данными, бизнес-аналитика, повышение качества данных и повышение квалификации сотрудников.
Таким образом, отраслевые логические модели данных являются эффективным инструментом интеграции данных и получения целостной картины бизнеса. Использование логических моделей представляется необходимым шагом на пути создания корпоративных Хранилищ данных.
Публикации
- Стив Хобермэн (Steve Hoberman). Использование отраслевой логической модели данных в качестве корпоративной модели (Leveraging the Industry Logical Data Model as Your Enterprise Data Model).
- Клодиа Имхоф (Claudia Imhoff). Оперативное создание Хранилищ данных и выполнение проектов Business Intelligence с помощью моделирования данных (Fast-Tracking Data Warehousing http://iso.ru/ru/press-center/journal/2222.phtml» target=»_blank»]iso.ru[/mask_link]
Моделирование данных: обзор
В работе мы с коллегами часто видим как компании сталкиваются с проблемой управления данными – когда таблиц и запросов становится сильно много и управлять всем этим очень сложно. В таких ситуациях мы рекомендуем моделировать данные. Чтобы разобраться, что это такое – я перевела статью-обзор про моделирование данных от Towards Data Science, в которой кроме основных терминов и понятий можно найти наглядный пример использования моделирования данных в ритейле. Вперед под кат!
Если вы посмотрите на любое программное приложение, то увидите, что на фундаментальном уровне оно занимается организацией, обработкой и представлением данных для выполнения бизнес-требований.
Модель данных — это концептуальное представление для выражения и передачи бизнес-требований. Она наглядно показывает характер данных, бизнес-правила, управляющие данными, и то, как данные будут организованы в базе данных.
Моделирование данных можно сравнить со строительством дома. Допустим, компании ABC необходимо построить дом для гостей (база данных). Компания вызывает архитектора (разработчик моделей данных) и объясняет требования к зданию (бизнес-требования). Архитектор (модельер данных) разрабатывает план (модель данных) и передает его компании ABC. Наконец, компания ABC вызывает инженеров-строителей (администраторов баз данных и разработчиков баз данных) для строительства дома.
Ключевые термины в моделировании данных
Сущности и атрибуты. Сущности — это «вещи» в бизнес-среде, о которых мы хотим хранить данные, например, продукты, клиенты, заказы и т.д. Атрибуты используются для организации и структурирования данных. Например, нам необходимо хранить определенную информацию о продаваемых нами продуктах, такую как отпускная цена или доступное количество.
Эти фрагменты данных являются атрибутами сущности Product. Сущности обычно представляют собой таблицы базы данных, а атрибуты — столбцы этих таблиц.
Взаимосвязь. Взаимосвязь между сущностями описывает, как одна сущность связана с другой. В модели данных сущности могут быть связаны как: «один к одному», «многие к одному» или «многие ко многим».
Сущность пересечения. Если между сущностями есть связь типа «многие ко многим», то можно использовать сущность пересечения, чтобы декомпозировать эту связь и привести ее к типу «многие к одному» и «один ко многим».
Простой пример: есть 2 сущности — телешоу и человек. Каждое телешоу может смотреть один или несколько человек, в то время как человек может смотреть одно или несколько телешоу.
Эту проблему можно решить, введя новую пересекающуюся сущность «Просмотр записи»:
ER диаграмма показывает сущности и отношения между ними. ER-диаграмма может принимать форму концептуальной модели данных, логической модели данных или физической модели данных.
Концептуальная модель данных включает в себя все основные сущности и связи, не содержит подробных сведений об атрибутах и часто используется на начальном этапе планирования. Пример:
Логическая модель данных — это расширение концептуальной модели данных. Она включает в себя все сущности, атрибуты, ключи и взаимосвязи, которые представляют бизнес-информацию и определяют бизнес-правила. Пример:
Физическая модель данных включает в себя все необходимые таблицы, столбцы, связи, свойства базы данных для физической реализации баз данных. Производительность базы данных, стратегия индексации, физическое хранилище и денормализация — важные параметры физической модели. Пример:
Основные этапы моделирования данных:
Реляционное vs размерное моделирование
В зависимости от бизнес-требований ваша модель данных может быть реляционной или размерной. Реляционная модель — это метод проектирования, направленный на устранение избыточности данных. Данные делятся на множество дискретных сущностей, каждая из которых становится таблицей в реляционной базе данных. Таблицы обычно нормализованы до 3-й нормальной формы. В OLTP приложениях используется эта методология.
В размерной модели данные денормализованы для повышения производительности. Здесь данные разделены на измерения и факты и упорядочены таким образом, чтобы пользователю было легче извлекать информацию и создавать отчеты.
Кейс
Компания ABC имеет 200 продуктовых магазинов в восьми городах. В каждом магазине есть разные отделы, такие как «Товары повседневного спроса», «Косметика», «Замороженные продукты», «Молочные продукты» и т.д. В каждом магазине на полках находится около 20 000 отдельных товаров. Отдельные продукты называются складскими единицами (SKU).
Около 6 000 артикулов поступают от сторонних производителей и имеют штрих-коды, нанесенные на упаковку продукта. Эти штрих-коды называются универсальными кодами продукта (UPC). Данные собираются POS-системой в 2 местах: у входной двери для покупателей, и у задней двери, где поставщики осуществляют доставку.
В продуктовом магазине менеджмент занимается логистикой заказа, хранением и продажами продуктов. Также продолжают расти рекламные активности, такие как временные скидки, реклама в газетах и т.д.
Разработайте модель данных для анализа операций этой продуктовой сети.
Решение
Шаг 1. Сбор бизнес-требований
Руководство хочет лучше понимать покупки клиентов, фиксируемые POS-системой. Модель должна позволять анализировать, какие товары продаются, в каких магазинах, в какие дни и по каким акционным условиям. Кроме того, это складская среда, поэтому необходима размерная модель.
Шаг 2: Идентификация сущностей
В случае размерной модели нам необходимо идентифицировать наши факты и измерения. Перед разработкой модели необходимо уточнить объем требуемых данных. Согласно требованию, нам нужно видеть данные о конкретном продукте в определенном магазине в определенный день по определенной схеме продвижения. Это дает нам представление о необходимых сущностях:
- Date Dimension
- Product Dimension
- Store Dimension
- Promotion Dimension
Количество, которое необходимо рассчитать (например, объем продаж, прибыль и т.д), будет отражено в таблице с фактическими продажами.
Шаг 3: Концептуальная модель данных
Предварительная модель данных будет создана на основе информации, собранной о сущностях. В нашем случае она будет выглядеть так:
Шаг 4: Доработка атрибутов и создание логической модели данных
Теперь необходимо завершить работу над атрибутами для сущностей. В нашем случае дорабатываются следующие атрибуты:
Date Dimension:
Product:
Store:
Promotion:
Sales Fact:
- Номер транзакции.
- Объем продаж (например, количество банок овощного супа с лапшой).
- Сумма продаж в долларах: количество продаж * цена за единицу.
- Стоимость в долларах: стоимость продукта, взимаемая поставщиком.
- Сумма валовой прибыли в долларах: доход от продаж — затраты.
Логическая модель данных будет выглядеть так:
Шаг 5: Создание физических таблиц в базе данных
С помощью инструмента моделирования данных или с помощью кастомных скриптов теперь можно создавать физические таблицы в базе данных.
Думаю, теперь стало достаточно очевидно, что моделирование данных — одна из важнейших задач при разработке программного приложения. И оно закладывает основу для организации, хранения, извлечения и представления данных.
- моделирование данных
- интернет-маркетинг
- веб-аналитика
- работа с данными
- Веб-аналитика
- Интернет-маркетинг
Источник: habr.com
Что такое проектирование баз данных
Перейдем ко второму уровню функциональной декомпозиции процесса проектирования базы данных в рамках его первого этапа — сбор и анализ входных данных . На рис. 3.3 представлена диаграмма декомпозиции процесса проектирования базы данных второго уровня, отражающая основные задачи этапа сбора и анализа входных данных.
Рис. 3.3. Диаграмма декомпозициии процесса проектирования базы данных: второй уровень. Сбор и анализ входных данных
Такими задачами являются:
- сбор документации с результатами анализа предметной области базы данных в виде диаграмм, спецификаций и требований;
- контроль качества результатов анализа предметной области базы данных;
- систематизация требований и спецификаций заказчика к базе данных;
- подготовка плана проектирования базы данных .
В ходе контроля качества основными моментами деятельности являются контроль ER-диаграмм и контроль диаграмм функциональной модели предметной области . На основании ER -диаграмм создается логическая модель реляционной базы данных ; на основании диаграмм функциональной модели разрабатывается серверный код и проектируются модули приложений базы данных .
Систематизация требований заказчика к базе данных проводится с целью их адекватного распределения по этапам проектирования базы данных . Важным результатом систематизации является вывод о достаточности требований и реализуемости базы данных . Заказчик должен точно знать, что он получит и чего не получит в результате создания базы данных ! Особенно важно указать, чего он не получит. Анализ требований на реализуемость базы данных в рамках конкретного ИТ-проекта служит основой для принятия решения менеджером проекта о возможности реализации проекта в целом.
Создав бизнес-модель проектирования базы данных , вы, фактически, составили план проектирования базы данных . Позициями рабочего плана являются работы бизнес-модели процесса проектирования базы данных , которые дополняются сведениями об ответственных исполнителях и сроках исполнения. Каждый уровень декомпозиции процесса уточняет этот план.
В конце каждого модуля курса мы будем рассматривать диаграмму декомпозиции следующего этапа проектирования базы данных . Таким образом, к концу изучения курса у вас будет построена достаточно полная бизнес-модель процесса проектирования реляционной базы данных .
Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных
Продолжим функциональную декомпозицию процесса проектирования реляционной базы данных в рамках его второго этапа — создания логической модели базы данных .
Основной целью этапа создания логической модели базы данных является преобразование информационной модели предметной области базы данных в логическую модель реляционной базы данных . Создание логической модели базы данных предполагает решение следующих основных задач и выполнения операций в рамках таких задач:
- нормализация сущностей предметной области :
- получить список атрибутов сущности ;
- определить функциональные зависимости (ФЗ) в сущности;
- определить детерминанты сущности;
- определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности .
- выполнить нормализацию сущности (преобразовать сущность в отношение);
- для полученного отношения назначить первичные ключи;
- сформировать список кандидатов на внешние ключи, если необходимо;
- сформировать бизнес-правила поддержки целостности сущности , если необходимо;
- нормализовать отношение (разрешить связи);
- назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;
- определить атрибуты связывающих отношений, если необходимо;
- сформировать бизнес-правила поддержки целостности связей;
- проверка отношений на соответствие нормальной форме Бойса-Кодда ;
- проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей ;
- предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
- проверка на отсутствие незамкнутых связей;
- проверка на отсутствие одиночных отношений;
Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных . Отметим, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных , не предусмотренные в информационной модели предметной области , например связывающая сущность при нормализации отношения со степенью связи » многие-ко-многим «. Иногда на этом этапе принимается решение о выборочной денормализации отношений.
На рис. 3.4-рис. 3.6 представлены бизнес-модели процессов создания логической модели базы данных , нормализации сущности предметной области и нормализации отношений логической модели базы данных соответственно.
Рис. 3.4. Бизнес-модель процесса создания логической модели базы данных
Рис. 3.5. Бизнес-модель процесса нормализации сущности
Рис. 3.6. Бизнес-модель процесса нормализации отношенияПредставленные задачи составляют минимально необходимый набор задач, позволяющих спроектировать логическую модель базы данных , и могут рассматриваться как один из возможных способов организации работ в этой области.
Источник: intuit.ru
