Реляционная модель данных. Корпоративные информационные системы

Отраслевые модели данных

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

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

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

Как правило, выделяются модели более высокого уровня (и более общие по содержанию) и более низкого (соответственно, более детальные). Верхний уровень моделирования – это так называемые концептуальные модели данных (conceptual data models), которые дают самую общую картину функционирования предприятия или организации. Концептуальная модель включает основные концепции или предметные области, критичные для функционирования организации; обычно их количество не превышает 12-15. Такая модель описывает классы сущностей, важных для организации (бизнес-объекты), их характеристики (атрибуты) и ассоциации между парами этих классов (т.е. связи). Поскольку в бизнес-моделировании терминология еще окончательно не устоялась, в различных англоязычных источниках концептуальные модели данных могут также носить название subject area model (что можно перевести как модели предметных областей) или subject enterprise data model (предметные корпоративные модели данных).

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

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

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

Важно различать логическую и семантическую модель данных. Логическая модель данных представляет корпоративное бизнес-решение, а семантическая – прикладное бизнес-решение. Одна и та же корпоративная логическая модель данных может быть реализована с помощью различных семантических моделей, т.е. семантические модели могут рассматриваться как следующий уровень моделирования, приближающийся к физическим моделям. При этом каждая из таких моделей будет представлять отдельный «срез» корпоративной модели данных в соответствии с требованиями различных приложений. Например, в корпоративной логической модели данных сущность Клиент будет полностью нормализована, а в семантической модели для витрины данных может быть представлена в виде многомерной структуры.

У компании может быть два пути создания корпоративной логической модели данных: строить ее самостоятельно или воспользоваться готовой отраслевой моделью (industry logical data model). В данном случае различия в терминах отражают лишь разные подходы к построению одной и той же логической модели. В том случае, если компания самостоятельно разрабатывает и внедряет собственную логическую модель данных, то такая модель, как правило, носит название просто корпоративной логической модели. Если же организация решает воспользоваться готовым продуктом профессионального поставщика, то тогда можно говорить об отраслевой логической модели данных. Последняя представляет собой готовую логическую модель данных, с высокой степенью точности отражающую функционирование определенной отрасли. Отраслевая логическая модель – это предметно-ориентированный и интегрированный вид всей информации, которая должна находиться в корпоративном Хранилище данных для получения ответов как на стратегические, так и на тактические бизнес-вопросы. Как и любая другая логическая модель данных, отраслевая модель не зависит от прикладных решений. Она также не включает производные данные или другие вычисления для более быстрого извлечения данных. Как правило, большинство логических структур такой модели находят хорошее воплощение в ее эффективной физической реализации. Такие модели разрабатываются многими поставщиками для самых различных областей деятельности: финансовой сферы, производства, туризма, здравоохранения, страхования и т.д.

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

Отраслевые логические модели данных содержат значительное количество абстракций. Под абстракциями имеется в виду объединение аналогичных понятий под общими названиями, такими как Событие или Участник. Это добавляет отраслевым моделям гибкости и делает их более унифицированными. Так, понятие События применимо ко всем отраслям.

Специалист в области бизнес-аналитики (Business Intelligence) Стив Хобермэн (Steve Hoberman) выделяет пять факторов, которые необходимо принимать во внимание при решении вопроса о приобретении отраслевой модель данных. Первый – это время и средства, необходимые для построения модели. Если организации необходимо быстро добиться результатов, то отраслевая модель даст преимущество. Использование отраслевой модели не может немедленно обеспечить картину всей организации, но способно сэкономить значительное количество времени. Вместо собственно моделирования время будет потрачено на связывание существующих структур с отраслевой моделью, а также на обсуждение того, как лучше ее настроить под нужды организации (например, какие определения должны быть изменены, а какие элементы данных – добавлены).

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

Третий фактор – опыт в оценке рисков и моделировании. Создание корпоративной модели данных требует квалифицированных ресурсов как со стороны бизнеса, так и IT-персонала. Как правило, менеджеры хорошо знают либо работу организации в целом, либо деятельность конкретного отдела. Лишь немногие их них обладают как широкими (в масштабах всей компании), так и глубокими (в рамках подразделений) знаниями о своем бизнесе. Большинство менеджеров обычно хорошо знают только одну область. Поэтому, для того чтобы получить общекорпоративную картину, требуются существенные бизнес-ресурсы. Это увеличивает и требования к IT-персоналу. Чем больше бизнес-ресурсов требуется для создания и тестирования модели, тем более опытными должны быть аналитики. Они должны не только знать, как получить информацию от бизнес-персонала, но также уметь находить общую точку зрения в спорных областях и быть способными представлять всю эту информацию в интегрированном виде. Тот, кто занимается созданием модели (во многих случаях это тот же аналитик), должен обладать хорошими навыками моделирования. Создание корпоративных логических моделей требует моделирования «для будущего» и способности конвертировать сложный бизнес в буквальном смысле «в квадраты и линии».

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

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

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

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

Отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход.

Отраслевая модель данных, помимо связей с уже существующими системами, дает большие преимущества при осуществлении общекорпоративных проектов, таких как планирование ресурсов предприятия (Enterprise Resource Planning, ERP), управление основными данными, бизнес-аналитика, повышение качества данных и повышение квалификации сотрудников.

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

Публикации

  1. Стив Хобермэн (Steve Hoberman). Использование отраслевой логической модели данных в качестве корпоративной модели (Leveraging the Industry Logical Data Model as Your Enterprise Data Model).
  2. Клодиа Имхоф (Claudia Imhoff). Оперативное создание Хранилищ данных и выполнение проектов Business Intelligence с помощью моделирования данных (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Зайцев С.Л., к.ф.-м.н.

Повторяющиеся группы

Повторяющимися группами являются атрибуты, для которых единственный экземпляр сущности может иметь более одного значения. Например, персона может иметь более одного навыка. Если, с точки зрения требований бизнеса, нам нужно знать уровень владения навыком для каждого, и каждая персона может иметь только два навыка, мы можем создать сущность, показанную на рис. 1.6. Здесь представлена сущность ПЕРСОНА с двумя атрибутами для хранения навыков и уровня владения навыками для каждого.

Рис. 1.6. В данном примере используются повторяющиеся группы.

Проблема повторяющихся групп заключается в том, что мы не можем точно знать, сколько навыков может иметь персона. В реальной жизни у некоторых людей есть один навык, у некоторых - несколько, а у некоторых - пока ни одного. На рисунке 1.7 представлена модель, приведенная к первой нормальной форме. Обратите внимание на добавленный Идентификатор навыка , который уникально определяет каждыйНАВЫК.

Рис. 1.7. Модель, приведенная к первой нормальной форме.

Один факт в одном месте

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

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

В предыдущем примере НАВЫК зависит отИдентификатора персоны и отИдентификатора навыка. Это значит, что у вас не появитсяНАВЫК до тех пор, пока не появитсяПЕРСОНА, обладающая этим навыком. Это так же усложняет изменение Названия навыка. Необходимо найти каждую запись с Названием навыка и изменить ее для каждой Персоны, владеющей этим навыком.

На рисунке 1.8 представлена модель во второй нормальной форме. Заметьте, что добавлена сущность НАВЫК , и атрибут НАЗВАНИЕ навыка перенесен в эту сущность. Уровень навыка остался, соответственно, на пересеченииПЕРСОНЫ и НАВЫКА.

Рис. 1.8. Во второй нормальной форме повторяющаяся группа вынесена в другую сущность. Это обеспечивает гибкость при добавлении необходимого количества Навыков и изменении Названия навыка или Описания навыка в одном месте.

Каждый атрибут зависит от ключа

Каждый атрибут сущности должен зависеть от первичного ключа этой сущности. В предыдущем примере Название школы иГеографический район присутствуют в таблице ПЕРСОНА , но не описывают персону. Для достижения третьей нормальной формы необходимо переместить атрибуты в сущность, где они будут зависеть от ключа. Рисунок 1.9. показывает модель в третьей нормальной форме.

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

Отношения многие-ко-многим

Отношения многие-ко-многим отражают реальность окружающего мира. Обратите внимание, что на рисунке 1.9 существует отношение многие-ко-многим междуПЕРСОНОЙ иШКОЛОЙ . Отношение точно отражает тот факт, чтоПЕРСОНА может учиться во многихШКОЛАХ и вШКОЛЕ может учиться многоПЕРСОН. Для достижения четвертой нормальной формы создается ассоциативная сущность, которая устраняет отношение моногие-ко-многим за счет формирования отдельной записи для каждой уникальной комбинации школы и персоны. На рисунке 1.10 представлена модель в четвертой нормальной форме.

Рис. 1.10. В четвертой нормальной форме отношение моногие-ко-многим между ПЕРСОНОЙ и ШКОЛОЙ разрешается за счет введения ассоциативной сущности, в которой отводится отдельная запись для каждой уникальной комбинации ШКОЛЫ и ПЕРСОНЫ.

Формальные определения нормальных форм

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

В заданном отношении R атрибут Y функционально зависит от атрибута X. В символьном виде R.X -> R.Y (читается как "R.X функционально определяет R.Y") - в том и только в том случае если каждое значение X в R ассоциируется строго с одним значением Y в R (в каждый конкретный момент времени). Атрибуты X и Y могут быть составными (Дейт К. Дж. Введение в системы баз данных. 6-е издание. Изд. Вильямс: 1999, 848 с.).

Отношение R соответствует первой нормальной форме (1NF) тогда и только тогда, когда все принадлежащие ему домены содержат только атомарные значения (Дейт, там же).

Отношение R соответствует второй нормальной форме (2NF) тогда и только тогда, когда оно соответствует 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа (Дейт, там же).

Отношение R соответствует третьей нормальной форме (3NF) тогда и только тогда, когда оно соответствует 2NF, и каждый неключевой атрибут не транзитивно зависит от первичного ключа (Дейт, там же).

Отношение R соответствует нормальной форме Бойса-Кодда (BCNF) тогда и только тогда, когда каждый детерминант является кандидатом на использование в качестве ключа.

ПРИМЕЧАНИЕ Ниже приводится краткое объяснение некоторых аббревиатур, используемых в определениях Дейта.

MVD (multi-valued dependency) - многозначная зависимость. Используется только для сущностей с тремя и более атрибутами. При многозначной зависимости значение атрибута зависит только от части первичного ключа.

FD (functional dependency) - функциональная зависимость. При функциональной зависимости значение атрибута зависит от значения другого атрибута, который не является частью первичного ключа.

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

Отношение соответствует четвертой нормальной форме (4NF) тогда и только тогда, когда в R существует MVD, например A®®B. При этом все атрибуты R функционально зависят от A. Другими словами, в R присутствуют только зависимости (FD или MVD) формы K®X (т.е. функциональная зависимость атрибута X от кандидата на использование в качестве ключа K). Соответственно R отвечает требованиям 4NF, если оно соответствует BCNF и все MVD фактически являются FD (Дейт, там же).

Для пятой нормальной формы отношение R удовлетворяет зависимости по объединению (JD)*(X, Y, …, Z) тогда и только тогда, когда R эквивалентно его проекциям на X, Y,..., Z, где X, Y,..., Z подмножества множества атрибутов R.

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

Бизнес-нормальные формы

В своей книге Клайв Финклештейн (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) применил другой подход к нормализации. Он определяет бизнес-нормальные формы в терминах приведения к этим формам. Многие разработчики моделей, считают этот подход интуитивно более ясным и прагматичным.

Первая бизнес-нормальная форма (1BNF) выносит повторяющиеся группы в другую сущность. Эта сущность получает собственное имя и первичные (составные) ключевые атрибуты из исходной сущности и ее повторяющейся группы.

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

Третья бизнес-нормальная форма (3BNF) выносит атрибуты, не зависящие от первичного ключа, в другую сущность, где они полностью зависят от первичного ключа этой сущности.

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

Пятая бизнес-нормальная форма (5BNF) проявляется как структурная сущность, если есть рекурсивная или другая зависимость между экземплярами вторичной сущности, или если рекурсивная зависимость существует между экземплярами ее первичной сущности.

Завершенная логическая модель данных

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

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

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

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

ПРИМЕЧАНИЕ Множественность связи описывает максимальное число экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной сущности. Необходимость существования или возможность отсутствия связи служит для определения минимального числа экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной сущности.

Физическая модель данных

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

В ERwin физическая модель является графическим представлением реально реализованной базы данных. Физическая база данных будет состоять из таблиц, столбцов и связей. Физическая модель зависит от платформы, выбранной для реализации, и требований к использованию данных. Физическая модель для IMS будет серьезно отличаться от такой же модели для Sybase. Физическая модель для OLAP-отчетов будет выглядеть иначе, чем модель для OLTP (оперативной обработки транзакций).

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

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

Сбор требований к использованию данных

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

    Требования к доступу и производительности

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

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

    Суммарные, сводные и другие вычисляемые или производные данные, которые могут рассматриваться в качестве кандидатов для хранения в долговременных структурах данных

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

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

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

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

Компоненты физической модели данных

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

Обратное проектирование

Когда логическая модель недоступна, возникает необходимость воссоздания модели из существующей базы данных. В ERwin этот процесс называется обратным проектированием. Обратное проектирование может производиться несколькими способами. Разработчик модели может исследовать структуры данных в базе данных и воссоздать таблицы в визуальной среде моделирования. Вы можете импортировать язык описания данных (DDL - data definitions language) в инструмент, который поддерживает проведение обратного проектирования (например, Erwin). Развитые средства, такие как ERwin, включают функции, обеспечивающие связь через ODBC с существующей базой данных, для создания модели путем прямого чтения структур данных. Обратное проектирование с использованием ERwin будет подробно обсуждаться в одной из последующих публикаций.

Использование корпоративных функциональных границ

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

ПРИМЕЧАНИЕ Некоторые из моих коллег называют эти корпоративные функциональные границы моделированием реального мира. Моделирование реального мира побуждает разработчика модели рассматривать информацию в терминах реально присущих ей отношений и взаимосвязей.

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

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

Корпоративная модель данных (EDM - enterprise data model) содержит сущности, атрибуты и отношения, которые представляют информационные потребности корпорации. EDM обычно подразделяется в соответствие с предметными областями, которые представляют группы сущностей, относящихся к поддержке конкретных нужд бизнеса. Некоторые предметные области могут покрывать такие специфические бизнес-функции, как управление контрактами, другие - объединять сущности, описывающие продукты или услуги.

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

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

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

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

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

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

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

    IDEF1X (Integration Definition for Information Modeling - интегрированное описание информационных моделей).

    IE (Information Engineering - информационная инженерия).

IDEF1X - хорошая методология и использование ее нотации широко распространено

Интегрированное описание информационных моделей

IDEF1X- высоко структурированная методология моделирования данных, расширяющая методологию IDEF1, принятую в качестве стандарта FIPS (Federal Information Processing Standards - федеральный орган стандартов обработки информации). IDEF1X использует строго структурированный набор типов конструкций моделирования и приводит к модели данных, которая требует понимания физической природы данных до того, как такая информация может стать доступной.

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

Информационный инжиниринг

Клайва Финклештейна часто называют отцом информационного инжиниринга, хотя подобные же концепции излагал вместе с ним и Джеймс Мартин (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Информационный инжиниринг использует для управления информацией подход, направляемый бизнесом, и применяет другую нотацию для представления бизнес-правил. IE служит расширением и развитием нотации и базовых концепций методологии ER, предложенной Питером Ченом.

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

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

Заключение

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

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

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

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

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

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

ПРИМЕЧАНИЕ Множественность связи описывает максимальное число экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной сущности. Необходимость существования или возможность отсутствия связи служит для определения минимального числа экземпляров вторичной сущности, которые могут быть связаны с экземпляром исходной

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

Эпилог

При подготовке данной статьи я постаралась ориентироваться прежде всего на архитекторов, аналитиков и разработчиков, которые непосредственно работают с хранилищами данных. Но получилось, что неизбежно «брала тему чуть шире» - и поле зрения попадали другие категории читателей. Какие-то моменты покажутся спорны, какие-то не понятны, какие-то очевидны. Люди разные – с разным опытом, бэкграундом и позицией.
Например, типичные вопросы менеджеров - «когда привлекать архитекторов?», «когда надо заниматься архитектурой?», «архитектура – не будет ли это слишком дорого?» звучат для нас (разработчиков, проектировщиков) довольно странно, потому что для нас архитектура системы появляется с ее рождением – не важно, осознаем мы это, или нет. И даже если формально роли архитектора в проекте нет, нормальный разработчик всегда «включает своего внутреннего архитектора».

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

“Уникальность антихрупкости состоит в том, что она позволяет нам работать с неизвестностью, делать что-то в условиях, когда мы не понимаем, что именно делаем, – и добиваться успеха” /Нассим Н.Талеб/
Поэтому, кризис и высокая степень неопределенности – это не оправдание в пользу отсутствия архитектуры, а факторы, усиливающие ее необходимость.

Теги:

  • архитектура
  • хранилище данных
Добавить метки

Всё чаще IT-специалисты обращают своё внимание на решения по управлению данными, основанные на стандартных отраслевых моделях данных и шаблонах бизнес-решений. Готовые к загрузке комплексные модели физических данных и отчёты бизнес-аналитики для конкретных сфер деятельности позволяют унифицировать информационную составляющую деятельности предприятия и значительно ускорить выполнение бизнес-процессов. Шаблоны решений позволяют поставщикам услуг использовать возможности нестандартной информации, скрытой в существующих системах, сокращая тем самым сроки выполнения проектов, затраты и риски. Например, реальные проекты показывают, что модель данных и шаблоны бизнес-решений могут сократить объём трудозатрат на разработку на 50%.

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

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


Пример модели “ГИС для органов власти и местного самоуправления”.

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

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

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

Модели данных под платформу Esri ArcGIS представляют собой рабочие шаблоны для применения в ГИС-проектах и создания структур данных для разных прикладных областей. Формирование модели данных включает создание концептуального дизайна, логической и физической структуры, которые затем можно использовать для построения персональной или корпоративной базы геоданных. ArcGIS предоставляет инструменты для создания и управления схемой базы данных, а шаблоны модели данных используются для быстрого запуска ГИС-проекта по разным сферам применения и отраслям. Специалисты Esri вместе с сообществом пользователей потратили значительное количество времени на разработку ряда шаблонов, которые могут обеспечить возможность быстрого начала проектирования базы геоданных предприятия. Эти проекты описаны и задокументированы на веб-сайте support.esri.com/datamodels . Ниже, в порядке их упоминания на этом сайте, представлен смысловой перевод названий отраслевых моделей Esri:

  • Адресный реестр
  • Сельское хозяйство
  • Метеорология
  • Базовые пространственные данные
  • Биоразнообразие
  • Внутреннее пространство зданий
  • Учет парниковых газов
  • Ведение административных границ
  • Вооружённые силы. Разведка
  • Энергетика (включая новый протокол ArcGIS MultiSpeak)
  • Экологические сооружения
  • МЧС. Пожарная охрана
  • Лесной кадастр
  • Лесное хозяйство
  • Геология
  • ГИС национального уровня (e-gov)
  • Подземные и сточные воды
  • Здравоохранение
  • Археология и охрана памятных мест
  • Национальная безопасность
  • Гидрология
  • Международная гидрографическая организация (IHO). Формат S-57 для ENC
  • Ирригация
  • Земельный кадастр
  • Муниципальное правительство
  • Морская навигация
  • Государственный кадастр
  • Нефтегазовые структуры
  • Трубопроводы
  • Растровые хранилища
  • Батиметрия, рельеф морского дна
  • Телекоммуникации
  • Транспорт
  • Водопровод, канализация, ЖКХ

Эти модели содержат все необходимые признаки отраслевого стандарта, а именно:

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

Специалисты Esri входят в экспертную группу независимых органов, которые рекомендуют к использованию различные отраслевые модели, например PODS (Pipeline Open Data Standards - открытый стандарт для нефтегазовой отрасли; в настоящее время имеется реализация PODS в качестве базы геоданных Esri PODS Esri Spatial 5.1.1) или база геоданных (БГД) из ArcGIS for Aviation, которая учитывает рекомендации ICAO и FAA, а также стандарт обмена навигационными данными AIXM 5.0. Кроме того, существуют рекомендованные модели, строго соответствующие существующим отраслевым стандартам, например S-57 и ArcGIS for Maritime (морские и прибрежные объекты), а также модели, созданные по результатам выполненных работ Esri Professional Services и являющиеся «де-факто» стандартами в соответствующей области. Например, GIS for the Nation и Local Government ("ГИС для органов государственной власти и местного самоуправления") оказали влияние на стандарты NSDI и INSPIRE, а Hydro и Groundwater (гидрология и грунтовые воды) активно используются в свободно доступном профессиональном пакете ArcHydro и коммерческих продуктах третьих фирм. Нужно отметить, что Esri поддерживает и стандарты "de-facto", например NHDI. Все предлагаемые модели данных документированы и готовы к использованию в IT-процессах предприятия. Сопроводительные материалы к моделям включают:

  • UML-диаграммы связей сущностей;
  • структуры данных, домены, справочники;
  • готовые шаблоны баз геоданных в формате ArcGIS GDB;
  • примеры данных и примеры приложений;
  • примеры скриптов загрузки данных, примеры утилит анализа;
  • справочники по предлагаемой структуре данных.

Компания Esri обобщает свой опыт построения отраслевых моделей в виде книг и локализует публикуемые материалы. Компанией Esri CIS локализованы и изданы следующие книги:

  • Геопространственная сервис-ориентированная архитектура (СОА);
  • Проектирование баз геоданных для транспорта;
  • Корпоративные геоинформационные системы;
  • ГИС: новая энергия электрических и газовых предприятий;
  • Нефть и газ на цифровой карте;
  • Моделирование нашего мира. Руководство Esri по проектированию базы геоданных;
  • Думая о ГИС. Планирование ГИС: руководство для менеджеров;
  • Географические информационные системы. Основы;
  • ГИС для административно-хозяйственного управления;
  • Веб-ГИС. Принципы и применение;
  • Стратегии проектирования систем, 26-е издание;
  • 68 выпусков журнала ArcReview с публикациями компаний и пользователей ГИС-систем;
  • ... и множество других тематических заметок и публикаций.

Например, книга "Моделирование нашего мира… " (перевод) - это всестороннее руководство и справочник по моделированию данных в ГИС вообще, и по модели данных базы геоданных в частности. Книга показывает, как вырабатывать правильные решения по моделированию данных, решения, которые участвуют в каждом аспекте проекта ГИС: от проектирования базы данных и сбора данных до пространственного анализа и визуального представления. Подробно описывается, как спроектировать географическую БД, соответствующую проекту, настроить функциональность базы данных без программирования, управлять потоком работ в сложных проектах, моделировать разнообразные сетевые структуры, такие как речные, транспортные или электрические сети, внедрять данные космосъёмки в процесс географического анализа и отображения, а также создавать 3D-модели данных ГИС. Книга "Проектирование баз геоданных для транспорта " содержит методологические подходы, опробованные на большом количестве проектов и полностью соответствующие законодательным требованиям Европы и США, а также международным стандартам. А в книге "ГИС: новая энергия электрических и газовых предприятий " с использованием реальных примеров показаны преимущества, которые корпоративная ГИС может дать компании-поставщику энергии, включая такие аспекты как обслуживание клиентов, эксплуатация сетей и другие бизнес-процессы.


Некоторые из книг, переводных и оригинальных, изданных на русском языке компаниями Esri CIS и DATA+. В них затрагиваются как концептуальные вопросы, связанные с технологией ГИС, так и многие прикладные аспекты моделирования и развертывания ГИС разного масштаба и назначения.

Применение отраслевых моделей рассмотрим на примере модели данных BISDM (Building Interior Space Data Model, информационная модель внутреннего пространства здания) версии 3.0. BISDM является развитием более общей модели BIM (Building Information Model, информационная модель здания) и предназначена к использованию в задачах проектирования, строительства, эксплуатации и вывода из эксплуатации зданий и сооружений. Используется в ПО ГИС, позволяет эффективно обмениваться геоданными с другими платформами и взаимодействовать с ними. Относится к общей группе задач FM (управление инфраструктурой организации). Перечислим основные преимущества модели BISDM, применение которой позволяет:

  • организовать обмен информацией в гетерогенной среде по единым правилам;
  • получить «физическое» воплощение концепции BIM и рекомендуемых правил управление проектом строительства;
  • поддерживать средствами ГИС единое хранилище на всем жизненном цикле здания (от проекта до вывода из эксплуатации);
  • координировать работу различных специалистов в проекте;
  • визуализировать заложенный календарный план и этапы строительства для всех участников;
  • давать предварительную оценку стоимости и сроков возведения (4D- и 5D-данные);
  • контролировать ход реализации проекта;
  • обеспечить качественную эксплуатацию здания, включая обслуживание и ремонты;
  • стать частью системы управления активами, включая функции анализа эффективности использования площадей (сдача в аренду, складские помещения, менеджмент сотрудников);
  • проводить расчёт и осуществлять управление задачами энергоэффективности здания;
  • моделировать перемещения людских потоков.

BISDM определяет правила работы с пространственными данными на уровне внутренних помещений в здании, в том числе предназначение и виды использования, проложенные коммуникации, установленное оборудование, учёт ремонтов и обслуживание, протоколирование инцидентов, взаимосвязи с другими активами компании. Модель помогает создавать единое хранилище географических и негеографических данных. Был использован опыт ведущих мировых компаний для выделения сущностей и моделирования на уровне БГД (базы геоданных) пространственных и логических взаимосвязей всех физических элементов, формирующих как само здание, так и его внутренние помещения. Следование принципам BISDM позволяет существенно упростить задачи интеграции с другими системами. На первом этапе это, как правило, интеграция с CAD. Затем, при эксплуатации здания, используется обмен данными с ERP и EAM-системами (SAP, TRIRIGA, Maximo и др.).


Визуализация структурных элементов BISDM средствами ArcGIS.

В случае использования BISDM заказчик/владелец объекта получает сквозной обмен информацией от идеи создания объекта до разработки полного проекта, контроль строительства с получением актуальной информации к моменту ввода объекта в эксплуатацию, контроль параметров во время эксплуатации, и даже при реконструкции или выводе объекта из эксплуатации. Следуя парадигме BISDM, ГИС и создаваемая с её помощью БГД становятся общим хранилищем данных для связанных систем. Часто в БГД оказываются данные, созданные и эксплуатируемые сторонними системами. Это нужно учитывать при проектировании архитектуры создаваемой системы.

На определённом этапе накопленная «критическая масса» информации позволяет перейти на новый качественный уровень. К примеру, по завершению этапа проектирования нового здания, в ГИС возможно автоматически визуализировать обзорные 3D-модели, составить перечень устанавливаемого оборудования, подсчитать километраж прокладываемых инженерных сетей, выполнить ряд поверок и даже дать предварительную финансовую оценку стоимости проекта.

Ещё раз отметим, что при совместном использовании BISDM и ArcGIS появляется возможность автоматического построения 3D-моделей по накопленным данным, поскольку БГД содержит полное описание объекта, включая z-координаты, принадлежность к этажу, виды соединений элементов, способы установки оборудования, материал, доступные пути перемещения персонала, функциональное назначение каждого элемента и т.д. и т.п. Нужно учесть, что после выполнения первоначального импорта всех проектных материалов в BISDM БГД возникает потребность дополнительного информационного наполнения для:

  • простановки на обозначенных местах 3D-моделей объектов и оборудования;
  • сбора сведений о стоимости материалов и порядка их укладки и монтажа;
  • контроля проходимости по габаритам устанавливаемого нестандартного оборудования.

За счёт применения ArcGIS упрощается импорт дополнительных 3D-объектов и справочников из внешних источников, т.к. модуль ArcGIS Data Interoperability позволяет создавать процедуры по импорту подобных данных и корректному их размещению внутри модели. Поддерживаются все используемые в данной отрасли форматы, в том числе IFC, AutoCAD Revit, Bentlye Microstation.

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

IBM предоставляет набор инструментов и моделей управления хранением данных для различных областей деятельности:

  • IBM Banking and Financial Markets Data Warehouse (финансы)
  • IBM Banking Data Warehouse
  • IBM Banking Process and Service Models
  • IBM Health Plan Data Model (здравоохранение)
  • IBM Insurance Information Warehouse (страхование)
  • IBM Insurance Process and Service Models
  • IBM Retail Data Warehouse (розничная торговля)
  • IBM Telecommunications Data Warehouse (телекоммуникации)
  • InfoSphere Warehouse Pack:
    - for Customer Insight (для понимания клиентов)
    - for Market and Campaign Insight (для понимания компании и рынка)
    - for Supply Chain Insight (для понимания поставщиков).

Например, модель IBM Banking and Financial Markets Data Warehouse предназначена для решения специфических проблем банковской отрасли с точки зрения данных, а IBM Banking Process and Service Models - с точки зрения процессов и СОА (сервис-ориентированной архитектуры). Для телекоммуникационной отрасли представлены модели IBM Information FrameWork (IFW) и IBM Telecommunications Data Warehouse (TDW) . Они помогают существенно ускорить процесс создания аналитических систем, а также снизить риски, связанные с разработкой приложений бизнес-анализа, управлением корпоративными данными и организацией хранилищ данных с учётом специфики телекоммуникационной отрасли. Возможности IBM TDW охватывают весь спектр рынка телекоммуникационных услуг - от интернет-провайдеров и операторов кабельных сетей, предлагающих услуги проводной и беспроводной телефонии, передачи данных и мультимедийного контента, до транснациональных компаний, предоставляющих услуги телефонной, спутниковой, междугородней и международной связи, а также организации глобальных сетей. На сегодняшний день TDW используется крупными и мелкими поставщиками услуг проводной и беспроводной связи по всему миру.

Инструмент под названием InfoSphere Warehouse Pack for Customer Insight представляет собой структурированное и легко внедряемое бизнес-содержимое для всё большего числа бизнес-проектов и отраслей, среди которых банковское дело, страхование, финансы, программы медицинского страхования, телекоммуникации, розничная торговля и дистрибуция. Для бизнес-пользователей InfoSphere Warehouse Pack for Market and Campaign Insight помогает максимально повысить эффективность мероприятий по анализу рынка и маркетинговых кампаний благодаря пошаговому процессу разработки и учёта специфики бизнеса. С помощью InfoSphere Warehouse Pack for Supply Chain Insight организации имеют возможность получать текущую информацию по операциям цепочек поставок.


Позиция Esri внутри архитектуры решений IBM.

Особого внимания заслуживает подход IBM для электроэнергетических компаний и предприятий ЖКХ. Для того чтобы удовлетворить растущие запросы потребителей, энергоснабжающим предприятиям необходима более гибкая архитектура по сравнению с используемой сегодня, а также стандартная отраслевая объектная модель, что упростит свободный обмен информацией. Это повысит коммуникативные возможности энергетических компаний, обеспечивая взаимодействие в более экономичном режиме, и предоставит новым системам лучшую видимость всех необходимых ресурсов независимо от того, где они располагаются в пределах организации. Базой для такого подхода служит СОА (сервис-ориентированная архитектура), компонентная модель, устанавливающая соответствие между функциями подразделений и сервисами различных приложений, которые можно многократно использовать. «Службы» таких компонентов обмениваются данными посредством интерфейсов без жёсткой привязки, скрывая от пользователя всю сложность стоящих за ними систем. В таком режиме предприятия могут легко добавлять новые приложения независимо от поставщика программного обеспечения, операционной системы, языка программирования или иных внутренних характеристик ПО. На основе СОА реализуется концепция SAFE (Solution Architecture for Energy), она позволяет компании электроэнергетической отрасли получить основанное на стандартах целостное представление своей инфраструктуры.

Esri ArcGIS ® - признанная во всём мире программная платформа для геоинформационных систем (ГИС), обеспечивающая создание и управление цифровыми активами электроэнергетических, газотранспортных, распределительных, а также телекоммуникационных сетей. ArcGIS позволяет провести наиболее полную инвентаризацию компонентов электрической распределительной сети с учётом их пространственного расположения. ArcGIS существенно расширяет архитектуру IBM SAFE, предоставляя инструменты, приложения, рабочие процессы, аналитику и информационно-интеграционные возможности, необходимые для управления интеллектуальным энергопредприятием. ArcGIS в рамках IBM SAFE позволяет получать из различных источников информацию об объектах инфраструктуры, активах, клиентах и сотрудниках с точными данными об их местоположении, а также создавать, хранить и обрабатывать геопривязанную информацию об активах предприятия (опоры, трубопроводы, провода, трансформаторы, кабельная канализация и т.д.). ArcGIS внутри инфраструктуры SAFE позволяет динамически объединить основные бизнес-приложения, комбинируя данные из ГИС, SCADA и систем обслуживания клиентов с внешней информацией, например об интенсивности трафика, погодных условиях или спутниковыми снимками. Энергопредприятия используют такую комбинированную информацию для различных целей, от С.О.Р. (общей картины оперативной обстановки) до инспектирования объектов, технического обслуживания, анализа и планирования сетей.

Информационные компоненты энергоснабжающего предприятия можно смоделировать с помощью нескольких уровней, которые ранжируются от самого низкого - физического - до верхнего, наиболее сложного уровня логики бизнес-процессов. Эти уровни можно интегрировать, чтобы обеспечить соответствие типичным отраслевым требованиям, например, при автоматизированной регистрации измерений и управлении системой диспетчерского контроля и сбора данных (SCADA). Выстраивая архитектуру SAFE, энергоснабжающие компании делают значительные шаги в продвижении общеотраслевой открытой объектной модели под названием «Общая информационная модель для энергетических компаний» (Common Information Model (CIM) for Energy and Utilities). Эта модель обеспечивает необходимую базу для продвижения множества предприятий к сервис-ориентированной архитектуре, поскольку она поощряет использование открытых стандартов для структуризации данных и объектов. За счёт того, что все системы используют одни и те же объекты, путаница и неэластичность, связанные с различными реализациями одинаковых объектов, будут сокращены до минимума. Таким образом, определение объекта «клиент» и прочих важных бизнес-объектов будет унифицировано во всех системах энергоснабжающего предприятия. Теперь с помощью CIM поставщики и потребители услуг могут использовать общую структуру данных, облегчая вывод дорогостоящих компонентов бизнеса на аутсорсинг, так как CIM устанавливает общую базу, на которой можно построить обмен информацией.

Заключение

Комплексные отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход и рост эффективности.

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


Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

  • 1. Реляционная модель данных
    • 1.1 Реляционная модель данных. Основные определения
    • 1.2 Операции над отношениями
  • 2. Корпоративные информационные системы
  • Список используемой литературы

1. Реляционная модель данных

1.1 Реляционная модель данных. Основные определения

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

Основные понятия:

* Отношение представляет собой двумерную таблицу, содержащую некоторые данные.

* Сущность - объект любой природы, данные о котором хранятся в БД. Атрибуты - свойства, характеризующие сущность (столбцы).

* Степень отношения - количество столбцов.

* Схема отношения - список имен атрибутов, например, СОТРУДНИК (№, ФИО, Год рождения, Должность, Кафедра).

* Домен - совокупность значений атрибутов отношения (тип данных).

* Кортеж - строка таблицы.

* Кардинальность (мощность) - количество строк в таблице.

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

* Внешний ключ - это атрибут (атрибуты) одной таблицы, который может служить первичным ключом другой таблицы. Является ссылкой на первичный ключ другой таблицы.

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

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

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

1.2 Операции над отношениями

Чтобы привести таблицу к первой нормальной форме (1НФ), нужно соблюсти два правила:

1. Атомарность или неделимость. Каждая колонка должна содержать одно неделимое значение.

2. Таблица не должна содержать повторяющихся колонок или групп данных.

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

Начинать нормализацию следует с проверки структуры БД на совместимость с 1НФ. Все столбцы, которые не являются атомарными, должны быть разбиты на составляющие их столбцы. Если в таблице есть повторяющиеся столбцы, то им нужно выделить отдельную таблицу.

Чтобы привести таблицу к первой нормальной форме, следует:

* Найти все поля, которые содержат многосоставные части информации.

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

* Вынести повторяющиеся данные в отдельную таблицу.

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

Для приведения таблиц ко второй нормальной форме (2НФ), приводимые таблицы должны быть уже в 1НФ. Нормализация должна проходить по порядку.

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

Чтобы привести базу ко второй нормальной форме, надо:

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

* Создать необходимые поля в таблицах users и forums, выделить из существующих полей или создать из новых первичные ключи.

* Для каждой таблицы нужен свой первичный ключ

* Создать внешние ключи и обозначаем их отношения между таблицами. Конечным шагом нормализации до 2НФ будет являться выделение внешних ключей для связи с ассоциированными таблицами. Первичный ключ одной таблицы должен быть внешним ключом в другой.

Подсказки:

Другой способ приведения схемы к 2НФ -- посмотреть на отношения между таблицами. Идеальный вариант -- создать все отношения вида один-к-многим. Отношения вида многие-к-многим нуждаются в реструктуризации.

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

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

Чтобы привести базу к третьей нормальной форме, надо:

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

* Создать соответствующие таблицы. Если есть проблемный столбец в шаге 1, создать раздельные таблицы для него.

* Создать или выделить первичные ключи. Каждая таблица должна иметь первичный ключ.

* Создать необходимые внешние ключи, которые образуют любое из отношений.

В четвертой нормальной форме дополнительное правило - необходимо исключать многозначные зависимости. Другими словами, все строки таблицы должны быть независимыми друг от друга. Наличие какой-то строки X, не должно означать, что строка Y тоже где-то есть в этой таблице.

2. Корпоративные информационные системы

реляционный модель данные система

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

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

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

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

4. Архитектура системы -- совокупность свойств системы, существенных для пользователя.

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

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

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение:

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

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

* одиночные;

* групповые;

* корпоративные.

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

Корпоративной Информационной Системой может считаться система, автоматизирующая более 80 % подразделений предприятия.

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

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

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

* системы обработки транзакций;

* системы принятия решений;

* информационно-справочные системы;

* офисные информационные системы.

Список используемой литературы

1. Агальцов, В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник / В.П. Агальцов. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013.

2. Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2012.

3. Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. - СПб.: Питер, 2013.

4. Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ-Петербург, 2012.

5. Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2009.

6. Г.Н. Федорова. Информационные системы. - М.: Академия, 2013.

7. А.Е. Сатунина, Л.А. Сысоева. Управление проектом корпоративной информационной системы предприятия. - М.: Финансы и статистика, Инфра-М, 2009.

Размещено на Allbest.ru

...

Подобные документы

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

    курсовая работа , добавлен 29.01.2011

    Корпоративные информационные системы и базы данных, их использование для совершенствования и отлаживания ведения бизнеса. Классификация корпоративных информационных систем. Информационные системы класса OLTP. Оперативная аналитическая обработка.

    курсовая работа , добавлен 19.01.2011

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

    реферат , добавлен 20.12.2010

    Понятие системы базы данных. Реляционная модель и ее характеристики. Целостность в реляционной модели. Реляционная алгебра. Вопросы проектирования БД. Нормальные формы отношений. Проектирование БД методом сущность-связь. ER-диаграммы. Язык SQL.

    курс лекций , добавлен 03.10.2008

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

    презентация , добавлен 14.10.2013

    Базы данных и их использование в вычислительной технике. Особенности и основная конструктивная единица сетевой модели данных. Иерархическая модель, объекты предметной области. Реляционная модель, ее наглядность, представление данных в табличной форме.

    реферат , добавлен 19.12.2011

    Виды и функции системы управления базами данных Microsoft Access. Иерархическая, сетевая, реляционная модель описания баз данных. Основные понятия таблицы базы данных. Особенности создания объектов базы данных, основные формы. Доступ к Internet в Access.

    контрольная работа , добавлен 08.01.2011

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

    научная работа , добавлен 08.06.2010

    Модели данных в управлении базами данных. Концептуальные модели данных. Роль баз данных в информационных системах. Реляционная модель данных. Определение предметной области. Построение модели базы данных для информационной системы "Домашние животные".

    курсовая работа , добавлен 19.04.2011

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