Бизнес описание модели данных

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

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

Два типа методов моделей данных:

  1. Модель отношений сущностей (ER)
  2. UML (унифицированный язык моделирования)

Бизнес описание модели данных

Цель технологии: построение модели предприятия в схеме реляционной базы данных с универсальной моделью данных, как основы информационной системы (ИС).

DATALEARN | DE — 101 | МОДУЛЬ 2-4: Модели Данных

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

Универсальная модель данных (УМД)

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

Язык модели данных (ЯМД)

  1. =Конференция;/=Компания;=ООО;=ЗАО; =ОАО; [](строковая,любая,фактическая) =Юридический адрес;[](строковая,любая,фактическая) =Телефон;/=Специалист;=-; [](строковая,любая,фактическая) =Гражданство;[](строковая,любая,фактическая) =Телефон;[](строковая,любая,фактическая) =Эл.адрес;/=Материалы;=-;>,где [ ] ( , , ) — тип характеристики экземпляра объекта ( [единица измерения — только для объекта с численной характеристикой] (тип данных: логическая; строковая; численная; дата, признак нахождения данных в справочнике: справочная; любая, тип характеристики: паспортная; фактическая) ). Данная строка метаописания определяет раздел «Конференция», классы объектов «Компания», «Специалист», «Материалы», их типы «ООО», «ЗАО», «ОАО», «-», иерархии подчиненности классов объектов (класс объектов «Материалы» подчинен классу объектов «Специалист», который в свою очередь подчинен классу объектов самого высшего уровня (без владельцев) — «Компания»), а также типы характеристик объектов «Юридический адрес», «Телефон», «Гражданство», «Эл.адрес» с соответствующими им атрибутами («строковая», «любая», «фактическая»). Исполнение данной строки с помощью приложения, имеющего доступ к БД с УМД, позволит записать все эти метаданные в базу.
  2. =Конференция; /=Компания; =ООО ; =Dbcreator; [](строковая,любая,фактическая) =Юридический адрес; =г.Харьков,пр.Правды,д.3к.7; [](строковая,любая,фактическая) =Телефон; =(057)3331234;>Данная строка метаописания определяет экземпляр объекта «Dbcreator» типа «ООО» и класса объектов «Компания», который (экземпляр) входит в состав раздела «Конференция». А также значения типов характеристик объекта «Юридический адрес» и «Телефон». Исполнение данной строки с помощью приложения, имеющего доступ к БД с УМД, позволит записать все эти данные в базу.
  • описание синтаксиса языка;
  • интерпретатор языка для СУБД Oracle (реализован на языке PL/SQL);
  • описание интерфейса доступа к стандартным процедурам интерпретатора языка;
  • средства формирования строк метаописания элементов данных;
  • методику составления строк метаописания для записи новых данных или проведения конвертации данных из БД других информационных систем, построенных на различных платформах (таких как Oracle, PostgreSQL, Access, Lotus Notes), в БД с УМД;
  • программу конвертации данных.

Программный инструментарий формирования модели предприятия

Программный инструментарий предназначен для формирования модели предприятия путем исполнения операторов (строк метаописаний) ЯМД.

Единая модель данных для бизнеса любого масштаба

  • программный интерфейс доступа к интерпретатору ЯМД;
  • специальные приложения, позволяющие осуществлять просмотр, модификацию, удаление имеющихся, а также запись новых данных в БД с УМД;
  • программа конвертации данных из БД других информационных систем, построенных на различных платформах (таких как Oracle, PostgreSQL, Access, Lotus Notes), в БД с УМД;
  • методики использования вышеперечисленных комплексов программ.

Программный инструментарий разработан в средах Borland Delphi, Borland C.

Вид некоторых приложений приведен на рис.3,4,5,6,7.

  1. Выделение компонентов предприятия, значимых для управления и бизнеса.
  2. Описание предметной области предприятия.
  3. Формализация описанной предметной области предприятия средствами ЯМД.
  4. Загрузка модели предприятия реальными данными путем исполнения строк метаописаний (операторов) ЯМД специальным программным инструментарием.
  5. Просмотр специальной программой реальных данных, представленных в виде связанного иерархического дерева объектов и событий, и их сопоставление с существующими представлениями экспертов предприятия и проектировщиков модели предприятия.
Читайте также:  Как пополнить бизнес карту Тинькофф через банкомат

Выводы

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

Определения

Данные — информация, обработанная и представленная в формализованном виде для дальнейшей обработки.

Информация — сведения об окружающем мире и протекающих в нем процессах, воспринимаемые человеком.

Информационная система — система, предназначенная для хранения, обработки, поиска, распространения, передачи и предоставления информации.

Класс — совокупность однородных элементов, обладающих каким-либо определенным качеством, свойством, отношением.

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

Понятие – смысловое обобщение некоторой совокупности элементов, предметов, пр.

Предмет — все, что представляется ощущениям, обладает свойством и определяется именем, синоним «объект».

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

Событие — любой факт или действие, которое происходит с поименованным объектом в определенный интервал времени (идентифицируется объектом и временем).

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

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

Литература

  1. Кузнецов С.Д. Будущие направления исследований в области баз данных: десять лет спустя, 1999
  2. Кузнецов С.Д. Крупные проблемы и текущие задачи исследований в области баз данных, 2005
  3. Кузнецов С.Д. Предвестники новых манифестов управления данными, 2006
  4. Т.Коннолли, К.Бегг, А.Страчан Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ.: Уч.пос.-М.: Издательский дом “Вильямс”, 2000.
  5. Пергаменцев Ю.А. «Проектирование БД на основе универсальной модели данных» в материалах конференции «Корпоративные базы данных 2002»
  6. Пергаменцев Ю.А. Информационные, функциональные модели и техническое задание на сегмент ОБД “Основные фонды» в Материалах Научно-технического совета ОАО “Газпром” по проекту “Отраслевой банк данных (ОБД)”, Санкт-Петербург, ноябрь 2000г., Москва 2001,С.66.
  7. Єсін В.І. та інші Можливі шляхи створення єдиної бази даних діяльності ХВУ на основі універсальної моделі даних – Харків: ХВУ. Науково-методичний збірник ХВУ,№ 3(89), 2003, C.3-12.

Источник: citforum.ru

Моделирование данных: зачем нужно и как реализовать

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

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

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

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

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

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

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

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

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

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

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

Типы моделей данных

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

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

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

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

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

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

  1. Определите сущности. На этом этапе идентифицируем объекты, события или концепции, представленные в наборе данных, который необходимо смоделировать. Каждая сущность должна быть целостной и логически отделенной от всех остальных.
  2. Определите ключевые свойства каждой сущности. Каждый тип сущности можно отличить от всех остальных, поскольку он имеет одно или несколько уникальных свойств, называемых атрибутами. Например, сущность «клиент» может обладать такими атрибутами, как имя, фамилия, номер телефона и т.д. Сущность «адрес» может включать название и номер улицы, город, страну и почтовый индекс.
  3. Определите связи между сущностями. Самый ранний черновик модели данных будет определять характер отношений, которые каждая сущность имеет с другими. В приведенном выше примере каждый клиент «живет по» адресу. Если бы эта модель была расширена за счет включения сущности «заказы», ​​каждый заказ также был бы отправлен на адрес. Эти отношения обычно документируются с помощью унифицированного языка моделирования (UML).
  4. Полностью сопоставьте атрибуты с сущностями. Это гарантирует, что модель отражает то, как бизнес будет использовать данные. Широко используются несколько формальных шаблонов (паттернов) моделирования данных. Объектно-ориентированные разработчики часто применяют шаблоны для анализа или шаблоны проектирования, в то время как заинтересованные стороны из других областей бизнеса могут обратиться к другим паттернам.
  5. Назначьте ключи по мере необходимости и определите степень нормализации. Нормализация — это метод организации моделей данных, в которых числовые идентификаторы (ключи) назначаются группам данных для установления связей между ними без повторения данных. Например, если каждому клиенту назначен ключ, этот ключ можно связать как с его адресом, так и с историей заказов, без необходимости повторять эту информацию в таблице с именами клиентов. Нормализация помогает уменьшить объем дискового пространства, необходимого для базы данных, но может сказываться на производительности запросов.
  6. Завершите и проверьте модель данных. Моделирование данных — это итеративный процесс, который следует повторять и совершенствовать под потребности бизнеса.
Читайте также:  Основные типы бизнес систем erp

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

Моделирование данных развивалось вместе с системами управления базами данных (СУБД), при этом типы моделей усложнялись по мере роста потребностей предприятий в хранении данных.

Иерархические модели данных представляют отношения «один ко многим» в древовидном формате. В модели этого типа каждая запись имеет единственный корень или родительский элемент, который сопоставляется с одной или несколькими дочерними таблицами. Эта модель была реализована в IBM Information Management System (IMS) ​​в 1966 году и быстро нашла широкое применение, особенно в банковской сфере. Хотя этот подход менее эффективен, чем недавно разработанные модели баз данных, он все еще используется в системах расширяемого языка разметки (XML) и географических информационных системах (ГИС).

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

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

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

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

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

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

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

Сегодня широко используются многочисленные коммерческие и CASE-решения с открытым исходным кодом, в том числе различные инструменты моделирования данных, построения диаграмм и визуализации. Вот несколько примеров:

  • erwin Data Modeler — это инструмент моделирования данных, основанный на языке IDEF1X, который теперь поддерживает и другие нотации, включая нотацию для размерного моделирования.
  • Enterprise Architect — это инструмент визуального моделирования и проектирования, который поддерживает моделирование корпоративных информационных систем и архитектур, программных приложений и баз данных. Он основан на объектно-ориентированных языках и стандартах.
  • ER/Studio — это программа для проектирования баз данных, совместимая с некоторыми из самых популярных СУБД. Она поддерживает как реляционное, так и размерное моделирование данных.
  • Бесплатные инструменты моделирования данных включают решения с открытым исходным кодом, такие как Open ModelSphere.

Для того, чтобы преобразовать данные в структуру, которая соответствует требованиям модели, можно использовать встроенный механизм регулярных запросов, которые выполняются в Google BigQuery, Scheduled Queries и AppScript. Их легко можно освоить, потому что это привычный SQL, но проводить отладку в Scheduled Queries практически нереально. Особенно, если это какой-то сложный запрос или каскад запросов.

Есть специализированные инструменты для управления SQL-запросами, например, dbt и Dataform.

dbt (data build tool) — это фреймворк с открытым исходным кодом для выполнения, тестирования и документирования SQL-запросов, который позволяет привнести элемент программной инженерии в процесс анализа данных. Он помогает оптимизировать работу с SQL-запросами: использовать макросы и шаблоны JINJA, чтобы не повторять в сотый раз одни и те же фрагменты кода.

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

Источник: biconsult.ru

Рейтинг
( Пока оценок нет )
Загрузка ...
Бизнес для женщин