Глава 2. Планирование модели данных финансовых услуг (часть 2)

• Разработка хранилища данных
  Общим драйвером настройки модели данных финансовых услуг является необходимость разработки модели и дизайна хранилища данных. Конкретные потребности включают:
  1. Определить в качестве значений модели данных финансовых услуг размеры, необходимые для схем звезд
  2. Разделить проекты и их логическую последовательность
  3. Согласовать определения ключевых данных в различных областях бизнеса
  4. Определить и управлять владением и распределением данных

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

Планирование внедрения

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

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

Проектная группа должна создать план реализации с участием исполнительного спонсора. Этот документ должен включать следующие элементы:

• Цели проекта
• Критические факторы успеха проекта
• Объем проекта
• Предположения и ограничения проекта
• Участники проекта и организационная структура
• План и график выполнения проекта
• Конечные результаты проекта
• Проектная логистика
• План отслеживания проектов

Этот план должен быть рассмотрен и ратифицирован исполнительным спонсором.

Управление FSDM

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

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

Примеры задач

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

1. Установите базу знаний для требований к информации для вашего Финансового учреждения.
2. Внедрить методологию разработки модели данных.
3. Установите стандарты содержания модели данных.
4. Изменение модели данных управления.
5. Согласовать разрешение содержимого данных и проблем использования.
6. Настройте модель данных.
7. Поддерживайте модель данных.
8. Обеспечить нормализацию логических данных.
9. Обеспечьте целостность модели данных, которая не включает избыточность, нет перекрывающиеся требования и согласованную структуру.
10. Ведение документации по модели данных.
11. Влияние моделирования процессов и разработки приложений.
12. Аудит приложений на соответствие стандартам данных.
13. Протестируйте и подтвердите изменения модели.
14. Выберите среду модели, например: инструменты CASE.
15. Выполните управление конфигурацией модели данных.
16. Обеспечение безопасности, включая доступ к данным и аварийное восстановление.
17. Поддержка миграции данных, моделей и приложений.

Подготовка к проверке, настройке и показу сеансов

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

Предлагаемая методология — совместная разработка приложений (JAD)

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

Существует два этапа JAD: JAD/plan и JAD/design. JAD/plan будет обсуждаться здесь как метод документирования плана реализации и оценки продолжительности и типов участников для сеансов проверки и настройки. JAD/design относится к сеансам для сопоставления данных требованиям к FSDM и настройке FSDM.

Глава 3. Структура модели данных финансовых услуг

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

Теория классификации

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

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

• A-Level — абстракция информации
• B-Level — Классификация информации

Примеры классификационных структур

Ниже приведена классификация для современных людей:

Классификация	Пример
Королевство	Животное
Тип (Phylum)	Хордовые
Подтип (Sub-phyla)	Позвоночные
Класс	Млекопитающие
Подкласс	Theria
Инфра-класс	Eutheria
Порядок	Примат
Подотряд	Simiae
Семья	Гоминид
Род	Гомик
Вид	Sapien

Архитектура и содержание модели данных финансовых услуг

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

Девять концепций данных:

• Схема (AR)
• Пункт направления бизнеса (BD)
• Классификация (CL)
• Условие (CD)
• Событие (EV)
• Участвующая сторона (IP)
• Местоположение (LO)
• Продукт (PD)
• Элемент ресурса (RI)

[IMAGE_2]

Глава 4. Навигация по модели данных финансовых услуг

Термин «навигация» используется для обозначения «обойти» или «пробиться». Эта тема рассматривается с трех точек зрения:

• Как объекты в документации модели данных финансовых услуг соотносятся с их представлением в m1?
• Как объекты на одном уровне модели данных финансовых услуг связаны с другими объектами на том же уровне?
• Как объекты на одном уровне модели данных финансовых услуг связаны с объектами на другом уровне?

[IMAGE_3]

Глава 5. Анализ бизнес-требований

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

Виды проекта и инструмент M1

Бизнес-требование отражается в модели данных финансовых услуг в виде представления проекта. Представления проекта предоставляют возможность создать «представление» модели данных финансовых услуг, а затем включить подмножество объектов в модели данных финансовых услуг в это представление. Представление проекта может охватывать столько объектов в модели данных финансовых услуг, сколько требуется.

Глава 6. Настройка модели данных финансовых услуг

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

Общие рекомендации

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

Глава 7. Генерация логической модели сущности-отношения из уровня данных модели финансовых услуг A/B

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

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

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

Приложение А. Модель управления

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

Разница между DA и администрированием базы данных

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

[IMAGE_4]