Л. Партыка, И. И. Попов системы управления базами данных
жүктеу/скачать 4,64 Mb.
|
Голицына О Л Партыка Т Л Попов И И Системы
ЗаключениеОтметим, что требование интеграции ресурсов появилось в связи с необходимостью комплексирования ресурсов, и в первую очередь систем БД, основанных на разных моделях данных и управляемых разными СУБД. Основной задачей такой интеграции являются предоставление пользователям интегрированной системы некоторой глобальной схемы БД, обеспечение метода доступа к данным, в том числе автоматическое преобразование операторов манипулирования данными в операторы, понятные соответствующим локальным СУБД, организация доступа к данным на сетевом уровне. Среди направлений исследований и разработок последних лет, в той или иной степени ориентированных на решение этих задач и получивших не только развитие, но также нашедших практическое воплощение и применение, можно выделить следующие: объектно-ориентированные базы данных как развитие метода построения баз данных на основе хорошо формализованных моделей, ориентированные на расширение возможностей использования атрибутивных представлений объектов и процессов предметной области, а также учет поведенческого аспекта; ориентированная на интеграцию данных технология Хранилища данных — построение систем неоднородных БД, объединяющая на логическом или физическом уровне наследованные форматированные данные, архивные текстовые документы, звуковые и видеоархивы и включающая средства оперативной аналитической обработки данных, необходимые виды «дружественных» интерфейсов; интеграция с Internet-технологиями — не только включение в состав СУБД средств и интерфейсов поддержки Internet-доступа, но и создание Internet-протоколов и технологий, ориентированных на задачи информационного (документального) поиска. Одна из главных задач, которую призваны решать системы управления — это интеграция данных из различных источников, в том числе со слабоструктурированными данными. Системы интеграции данных должны обрабатывать запросы, для ответа на которые могут потребоваться извлечение и обобщение данных из различных источников. При этом возможны следующие варианты: регулярные источники, где представление и организация данных в той или иной степени формализованы, хотя при этом могут использоваться различные модели данных и интерфейсы доступа к ним или данные источника могут быть не структурированными (HTML-файлы, текстовые файлы и т. д.); источники уникальные, т. е. взаимодействовать с источником можно только через предоставляемый им интерфейс, и нет никакой возможности повлиять на его внутренние процессы. Хранилища данных становятся реальной информационной основой для принятия решений и интеллектуального анализа информации в науке и задачах управления. Особенно широко методы аналитической обработки применяются в бизнесе аналитиками и руководителями организационных структур. Инструментальные средства, основанные на использовании хранилищ данных, позволяют пользователям, не имеющим достаточной математической подготовки, решать достаточно сложные задачи обработки данных. Системы аналитической обработки типа OLAP (Online Analytical Processing) используют многомерное представление (но не хранение!) агрегируемых данных. В этом случае многомерный анализ представляется как одновременный анализ по нескольким «измерениям», каждое из которых — это некоторый способ объединения элементов данных БД. Причем каждое измерение может иметь несколько уровней обобщения. Соответственно система предоставляет средства выбора уровня детализации информации и перемещения по каждому измерению. Это также заставляет на новой основе ставить вопрос о разработке интегрированной совокупности интерфейсов пользователя: они должны создавать естественные условия для работы с информацией и функциями, причем вне зависимости от того, к какому классу хранимых данных разработчик должен был бы отнести сегодня его (пользователя) информацию. В заключение считаем целесообразным привести требования и рекомендации к «новым» методам и инструментам проектирования БД, практически подтверждающие, что все новое есть в той или иной степени забытое старое. Об исключении избыточности в данных. Требование однократного ввода данных в БД сохраняется как разумное, и прежде всего для защиты от возникновения противоречий (нарушении логической целостности) при актуализации хранимых данных. Однако в условиях глобального информационного пространства и компонентного проектирования контекст этих требований должен быть пересмотрен. Несомненно, в операционных БД рационально планировать «острова» нормализованных и в классическом смысле без избыточных кластеров отношений или объектов. Эти «острова» чаще всего и будут являться давно известными предметными БД. Кроме того, заранее нерегламентированный поток информации из Internet в корпоративную БД потребует разработки или увеличения возможностей «процедур отождествления» экземпляров информационных структур, т. е. выяснения того, что эти экземпляры описывают один и тот же предмет реального мира. Проблема консервации проблем проектирования. Сам характер дисциплины проектирования, предусмотренный каскадной схемой, методами структурного проектирования, подталкивает проектировщиков фиксировать достаточно жестко определенные модели предметной области. Технология проектирования БД должна быть изменена таким образом, чтобы исключить консервацию существующих проблем предприятий в жестких, «цельных» структурах БД. Для этого может потребоваться изменение не только технологии, но и инструментов проектирования. Компонентная открытость и смысловая интероперабельность. Замена некоторой функциональной компоненты ИС на подобную, но спроектированную другим разработчиком потребует структурной замены некоторой части корпоративной БД. Такая замена должна поддерживаться как постоянный процесс перепроектирования БД. При замене компоненты БД интерфейсы имеющихся приложений и их пользователи должны получать точно ту же в смысловом отношении информацию, что и ранее. Реальное компонентное проектирование БД может основываться на формировании и использовании общей для комплексируемых компонент понятийной модели и поддержании соответствий между моделями компонент БД (и связанных с ними приложений) и общей понятийной моделью. Необходимость использования общих понятийных моделей заставляет заново рассматривать и использование нормативно-справочной информации и систем кодирования. До сих пор часто встречается мнение, что системы классификации и кодирования (СКК) — это средство сокращенного представления информации в БД. На самом деле отсутствие СКК или использование некорректно построенных СКК приводит к смысловой несовместимости информации, хранимой в различных БД или даже в одной БД.
жүктеу/скачать 4,64 Mb. Достарыңызбен бөлісу:
|