Основные модели и инструменты описания архитектуры информации реферат

Обновлено: 19.05.2024

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

На логическом уровне описываются потоки информации между бизнес-процессами и прикладными системами.

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

Способ моделирования данных на логическом уровне-построение моделей "Сущности-Отношения"(ERM – Entity-Relationship Model)

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

Сущностями являются, например, такие объекты как "клиент", "гражданин", "заказ", "место", "вещь или объект" и т.д. Совокупность сущностей одного типа становится таблицей в БД, а строка этой таблицы – реализация некоторой сущности.

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

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

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

Модель данных на физическом уровне

Физическая модель представляет, как данные, приведенные в логической модели, будут хранится в СУБД. Для обеспечения взаимодействия подразделений внутри организации и с внешними системами используется архитектура управления федеративными данными и мета- данными (federated data management). Она обеспечивает управление и доступ к данным и метаданным независимо от их внутренней логической структуры и физических границ расположения.

Уровни абстракции модели данных

Модель управления федеративными данными

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

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

Принципы управления федеративными данными

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

Создание метамоделей

Для определения метамоделей может использоваться стандарт Meta Object Facility (MOF) разработки, управляемой моделями. UML – это один из примеров MOF.

Состоит из четырех слоев (уровней):

уровень M3 определяет язык и его общее описание;

уровень M2 – семантика базовых понятий языка, например, для UML: класс, атрибут, операция, компонент, ассоциация (т.е. правила построения диаграмм UML);

уровень M1 – понятия конкретной модели предметной области (имя, фамилия, должность, т.д.), т.е. имена классов, атрибутов, действий;

уровень M0 – значения атрибутов реальных моделей (экземпляров моделей).

Но одного универсального средства для построения архитектуры информации нет. Перспективными являются средства моделирования, основанные на использовании языков UML, XML и основанных на них стандартах.

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Файл "Архитектура информации" внутри архива находится в папке "Архитектура информации". Документ из архива "Архитектура информации", который расположен в категории " ". Всё это находится в предмете "архитектура корпоративных информационных систем" из раздела "", которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "архитектура корпоративных информационных систем" в общих файлах.

Онлайн просмотр документа "Архитектура информации"

Текст из документа "Архитектура информации"

Московский Государственный Технический Университет имени Н. Э. Баумана

Выполнил:

студент группы ИУ5-109

__________/ Жуков Р.В./

___________/Нестеров Ю.Г./

Архитектура информации 3

Потребность в архитектуре информации 6

Структура архитектуры информации 7

Разработка архитектуры информации 9

Основные модели и инструменты описания архитектуры информации 10

Внешние данные и данные подсистем 13

Список литературы 16

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

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

1) структурированная информация (реляционные и объектные модели);

2) развивающиеся, основанные на XML стандарты для полуструктурированной информации;

3) неструктурированная информация в форме текстов, графиков, образов, сопровождаемая определенными описательными данными (метаданными и каталогами).

Примеры:

структурирование информации, которая будет представлена на сайте;

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

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

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

получение данных из внутренних и внешних источников;

классификация данных по типам;

хранение и извлечение данных;

редактирование (или обновление) данных;

контроль качества (удаление или исправление некорректных данных);

презентация (трансформирование данных для определенной аудитории потребителей);

распространение информации для различных групп потребителей;

оценка (полезности, а также соотношения цены/качества данных);

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

Архитектура информации описывает, как информационные технологии обеспечивают в организации возможности для быстрого принятия решений, распространения информации внутри организации, а также за ее пределы, например, партнерам по бизнесу. Архитектура информации является как бы "зеркальным отражением" бизнес-архитектуры. Бизнес-архитектура отвечает на вопрос: "С учетом нашего общего видения, целей и стратегий, кто и что будет делать?" Архитектура информации отвечает на вопрос: "Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?" Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией. Архитектура должна описывать как те данные, которые требуются для выполнения процессов (операционные), так и аналитические данные и "контент", публикуемый на Web.

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

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

Потребность в архитектуре информации сейчас велика как никогда. Аналитические компании, такие как META Group и Aberden, считают, что при разработке новых систем до 70% времени тратится на решение задач, связанных с идентификацией источников данных, которые должны использоваться прикладной системой, и на написание программного кода для доступа и трансформации данных. Для большинства средних и практически всех крупных предприятий использование нескольких различных СУБД, средств управления и преобразования данных является скорее правилом, чем исключением. Кроме того, в течение последнего десятилетия мы являлись и являемся свидетелями тенденции все более широкого использования готовых прикладных систем (финансового учета, управления кадрами, управления закупками, управления продажами и т.д.), каждая из которых имеет свои модели данных. С учетом наличия и других унаследованных систем тенденция к росту количества источников данных только увеличивается.

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

На рисунке 1 приводится пример упрощенной схемы перемещения данных в процессе работы над ними на некотором гипотетическом предприятии.

Рис. 1. Пример потоков данных на предприятии

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

Рисунок 2 показывает общую картину архитектуры информации, взятую из документов описания архитектуры правительства штата Северная Каролина, США.

Рис. 2. Общая архитектура информации (данных)

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

Для понимания архитектуры информации и того, как данные хранятся и обновляются, важно отличать типы прикладных систем, которые обеспечивают доступ к данным. Два наиболее важных типа таких систем – это системы онлайновой обработки транзакций (OLTP) и системы онлайновой аналитической обработки (OLAP). Третий тип – системы управления неструктурированными данными (контентом).

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

OLAP-системы

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки данных, заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. Реализации технологии OLAP являются компонентами программных решений класса Business Intelligence[1].

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

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

Бизнес-архитектура отвечает на вопрос: "С учетом нашего общего видения, целей и стратегий, кто и что будет делать?" Архитектура информации отвечает на вопрос: "Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?" Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией.

В ходе разработки архитектуры информации решаются следующие задачи:

Для понимания архитектуры информации и того, как данные хранятся и обновляются, важно отличать типы прикладных систем, которые обеспечивают доступ к данным. Два наиболее важных типа таких систем – это системы онлайновой обработки транзакций (OLTP – Online Transaction Processing) и системы он-лайновой аналитической обработки (OLAP – Online Analitical Processing). Третий тип – системы управления неструктурированными данными (контентом).

OLAP-системы используются для анализа, планирования и управления получением отчетов путем обеспечения интерактивного доступа к широкому спектру информации. В OLAP-системах обычно обрабатываются агрегированные данные для получения ответа на такие вопросы: "Сколько было потрачено на покупку офисной техники в прошлом году?", "Каков был объем продаж изделия X в городе N в первом квартале?" Данные для OLAP-систем, как правило, извлекаются из транзакционных OLTP-систем и помещаются или реплицируются в специальные базы данных – хранилища или витрины данных. Витрины данных являются специализированными хранилищами, которые ориентированы на предоставление информации, требующейся для бизнес-анализа на предприятии.

ODS и ETL

Рекомендуемыми первыми шагами на пути создания архитектуры информации являются следующие шаги:

создание словаря данных и репозитория метаданных;
выбор системы записи информации о каждом элементе данных.

Эти шаги впоследствии будут способствовать созданию оперативного хранилища данных (ODS – Operational Data Store), которое обеспечивает стандартные процессы извлечения, трансформации и загрузки данных (ETL – Extract, Transform, Load), а также очистки данных и создания метаданных. Оперативное хранилище является краеугольным камнем для повторного, многократного использования данных, а в последующем – для создания хранилищ и витрин данных.

Архитектура приложений

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

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

В Архитектуре приложений, как правило, выделяют две основные области:

формирование и управление портфелем прикладных систем предприятия;
разработку прикладных систем.

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

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

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

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

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

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

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

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

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

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

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

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

В ходе разработки архитектуры информации решаются следующие задачи:

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

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

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

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

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

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

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

Читайте также: