Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

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



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

Эти стандарты опираются на современные исследования и общемировую практику создания хранилищ данных и аналитических систем.

В общем виде архитектура корпоративной информационно-аналитической системы описывается схемой с тремя выделенными слоями (рис. 2.7):

– извлечение, преобразование и загрузка данных;

– хранение данных;

– анализ данных (рабочие места пользователей).

На рис. 2.8 показаны основные этапы проектирования информационно – аналитической системы.



Рис. 2.7. Архитектура информационно-аналитической системы


       
   
 
 


Рис. 2.8. Этапы проектирования базы данных

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

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

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

· структура данных в источниках

· основные предметные области, связанные с задачей

· требования пользователей

На этой же стадии вводится четко определенный и согласованный со всеми участниками проекта критерий завершенности проекта или его очередной итерации.

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

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

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

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

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

Атрибуты представляют данные об объектах, которые необходимо иметь корпорации. Атрибуты представляются именами существительными, которые описывают характеристики сущностей.

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

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

Физическое проектирование транслирует сущности, атрибуты и отношения между ними в таблице, колонки и физические зависимости, которые описываются посредством SQL и проецируется на выбранную технологию для хранения и управления базами данных. При построении физической модели для хранилища данных, необходимо учитывать огромное количество запросов в данной базе, по сравнению с операционной базой данных. Поэтому получение данных из хранилища требует совершенно иного подхода. Одними из популярных средств физического проектирования хранилищ данных является CA ERwin Process Modeler 7.3 (ранее BPwin) и AllFusion ERwin Data Modeler 7.3 (ERwin).

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

CA ERwin Process Modeler (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. CA ERwin Process Modeler повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.

AllFusion ERwin Data Modeler (ранее: ERwin) - CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.
AllFusion ERwin Data Modeler (ERwin) предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. AllFusion ERwin Data Modeler позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.

AllFusion ERwin Data Modeler (ERwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion ERwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоемких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию в вашей организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.

Программные средства CA ERwin Process Modeler и AllFusion ERwin Data Modeler, являясь самыми современными средствами проектирования информационных аналитических систем, имеют ряд недостатков. Во-первых, они имеют только англоязычный интерфейс и, во-вторых, не имеют доступного по стоимости учебного варианта (в отличие от того же Дедуктора).

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





Дата публикования: 2014-11-02; Прочитано: 2202 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2024 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.006 с)...