чч. Конспект лекций по дисциплине Хранилища данных для образовательной программы 09. 04. 03 Прикладная информатика

• Название: Конспект лекций по дисциплине Хранилища данных для образовательной программы 09. 04. 03 Прикладная информатика
• Дата: 05.03.2023
• Размер: 1.29 Mb.
• Имя файла: Lk.doc
• Тип: Конспект лекций; #969120
• страница: 12 из 18

Подсистема администрирования хранилища

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

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

Методология построения хранилищ данных

Существуют различные подходы к стратегии построения корпоративного хранилища данных (ХД):

1. 
   Построение сверху вниз.
   

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

Такая идея ограничила возможности разработчиков в структуре информационных множеств БД, в использовании вариантов экранных форм, алгоритмов расчёта и, следовательно, лишила возможности принципиально расширить круг решаемых задач. Заложенные “сверху” жёсткие рамки (“общие для всех”) ограничивают возможности ИС. Стало очевидным, что для успешной реализации задач полной автоматизации организации следует менять идеологию построения автоматизированных информационных систем (АИС).

2. 
   Построение снизу вверх.
   

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

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

3. 
   Динамическая интеграция данных.
   

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

Рис. 14а. Спиральная модель разработки	Рис. 14б. Стратегия построения СППР

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

постановка задачи,

проектирование,

реализация,

внедрение.

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