Архитектура данных

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Неподтвержденные материалы могут быть оспорены и удалены. Найти источники:  «Архитектура данных» – новости  · газеты  · книги  · ученый  · JSTOR ( ноябрь 2008 г. ) ( Узнайте, как и когда удалять это сообщение )

Архитектура данных состоит из моделей, политик, правил и стандартов, которые определяют, какие данные собираются и как они хранятся, упорядочиваются, интегрируются и используются в системах данных и в организациях. ^[1] Данные обычно являются одним из нескольких доменов архитектуры , которые формируют столпы архитектуры предприятия или архитектуры решения . ^[2]

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

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

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

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

• Концептуальный — представляет все субъекты хозяйствования .
• Логический — представляет логику того, как связаны сущности.
• Физический — реализация механизмов данных для определенного типа функциональности.

Столбец «данные» в структуре Захмана для корпоративной архитектуры –

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

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

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

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

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

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

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

Требования предприятия

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

Драйверы технологий

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

Экономика

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

Политика ведения бизнеса

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

Потребности в обработке данных

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

• Контролируемый словарный запас
• Сетка данных , доменно-ориентированная архитектура данных
• Разрозненная система
• Архитектура информационной безопасности предприятия (EISA) позиционирует безопасность данных в корпоративной информационной структуре.
• Структура архитектуры предприятия FDIC
• Информационный бункер
• ТОГАФ

• Басс, Л.; Джон, Б.; и Кейтс, Дж. (2001). Достижение удобства использования с помощью архитектуры программного обеспечения , Университет Карнеги-Меллона.
• Льюис, Г.; Комелла-Дорда, С.; Плейс, П.; Плакош, Д.; и Сикорд, Р. (2001). Руководство по архитектуре данных информационной системы предприятия Университет Карнеги-Меллона.
• Адлеман, С.; Мосс, Л.; Абай, М. (2005). Стратегия данных Addison-Wesley Professional.

На Викискладе есть медиафайлы по теме «Архитектура данных» .

• Достижение удобства использования посредством архитектуры программного обеспечения, sei.cmu.edu 2001
• Логическая архитектура данных, Нирмал Байд
• Создание современной архитектуры данных и аналитики
• Архитектура данных «Право на ремонт» с DataOps, блог DataOps
• TOGAF 9: Процесс подготовки