|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Создание физической модели хранилища данных. Метаданные в хранилищах данных
На практике ХД создаются и эксплуатируются как БД под управлением конкретной СУБД. БД, реализующие ХД, создаются на основе физической модели данных, разработанной проектировщиком ХД и реализованной в виде объектов БД. Физическая модель данных, напротив, зависит от конкретной СУБД, в ней содержится информация обо всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД и ее диалекта SQL. Следовательно, одной и той же логической модели данных могут соответствовать несколько разных физических моделей. Основными объектами логической модели данных являются сущности, атрибуты и взаимосвязи. Физическая модель данных, как правило, создается на основе логической, поэтому каждому объекту логической модели соответствует объект физической модели (хотя соответствие может быть неоднозначным). В физической модели данных сущности логической модели данных соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы. Кроме перечисленных выше объектов, физическая модель может содержать объекты, тип которых зависит от СУБД: индексы, представления, последовательности, триггеры, процедуры и т.п. Если в логической модели данных не имеет большого значения, какой конкретно тип данных у атрибута, то в физической важно описать всю информацию о конкретных объектах. Далее, при изложении материала, мы будем предполагать, что имеем дело с реляционными или объектно-реляционными СУБД и соответствующими им диалектами SQL. Можно выделить два этапа создания физической модели данных. Основными целями первого этапа являются: -удовлетворение потребности в хранении данных предметной области в рамках реляционной модели данных, т.е. должны быть созданы базовые таблицы для хранения информации обо всех сущностях предметной области; -удовлетворение требования целостности данных, т.е. должны быть определены типы колонок и наложены ограничения на значения колонок базовых таблиц, которые бы следовали из бизнес-правил предметной области; -удовлетворение требования ссылочной целостности (referential integrity, RI), т.е. в случае принятия решения о поддержки ссылочной целостности встроенными средствами СУБД должны быть наложены ограничения ссылочной целостности на таблицы, исходя из бизнес-правил ссылочной целостности предметной области; -удовлетворение (частично) требования независимости представления данных для конечного пользователя от характера физического хранения данных.
На первом этапе в рамках требований реляционной модели создаются объекты хранения данных, соответствующие сущностям и взаимосвязям логической модели данных — таблицы, индексы, представления и т.д. Главной целью второго этапа является обеспечение требуемого уровня производительности. Для достижения этой цели необходимо учитывать как особенности реализации СУБД, для которой создается физическая модель, так и особенности функционирования будущей информационной системы в целом. Обычно производительность БД измеряется в терминах производительности транзакций (transaction performance). Для повышения производительности транзакций могут быть модифицированы объекты, созданные на первом этапе, или созданы новые объекты БД. Другими словами, разработка физической модели представляет собой итерационный процесс, причем итераций (создание объектов – анализ транзакций – модификация объектов – анализ транзакций) может быть несколько. Вопросы повышения производительности транзакций будут рассмотрены в одной из следующих лекций.
Базовые компоненты метаданных ХД не сильно отличаются от базовых компонент систем операционной обработки данных. Это описание таблиц, их атрибутов, ключей и т.д. Существенное отличие для ХД — поддержка версионности метаданных. Базовые компоненты говорят нам, какие данные сохраняются в ХД. Следующая, характерная для ХД, группа компонентов метаданных — описание преобразований. Как правило, описание преобразований данных для ХД включает в себя: -идентификацию полей источников данных; -соответствие между атрибутами сущностей источников данных и атрибутами объектов ХД; -преобразования атрибутов; -физические характеристики преобразований; -преобразования таблиц кодировки и ссылочных таблиц; -изменения наименований (соответствие имен источников и объектов ХД); -изменение ключевых атрибутов; -значение полей по умолчанию; -логика (алгоритмы) формирования данных ХД из нескольких источников (приоритетность источников); -алгоритмы трансформации данных и т. д.
Компоненты преобразования говорят нам о том, как данные в ХД были получены.
Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.) |