- •Архитектура клиент- сервер.
- •Клиент серверная архитектура.
- •Протокол odbc.
- •Принципы построения систем ориентированных на анализ данных.
- •Хранилище данных.
- •Комбинация многомерного и реляционного подхода: киоски данных.
- •Логическая схема сппр.
- •Гомогенные и гетерогенные распределенные субд.
- •Фундаментальный принцип и 12 целей Дейта.
Протокол odbc.
Запросы нужно писать на ANSI SQL И обновлять драйверы.
03 10 2012
Интерфейс приклодного программмирования ODBC API представляет общие методы лоступа на основ/ое языка sql как к ряляционным так и к не реляционным(ISAM индексно последовательный доступ метод DBF DB cdx) источникам данных.
Для обеспечения доступа и работы с данными ODBC опирается на стандарт ANSI SQL, который прелставляет собой часть полного стандарта SQL 99.
Интерфейс ODBC API реализован как набор расслоённых dll функций. Библиотека ODBC.dll — этот файл будет лежать, это основная библиотека управления драйверами odbc, которая содержит функции вызова спец драйверов для разных поддерживаемчх системой баз данных
Open Database Connectivity, кождый драйвер относиться к 1ой из 2 категорий 1 уровневой или многоуровневой.
Одноуровневые драйверы предназначены для использования с теми источниками данных, которе не могут быть прямо обработаны с использованием ANSI SQL.
Обычно это локальные БД для ПК драйверы соответствующие этим базам переводят компиляцию ANSI SQL в набор инструкций более низкого уровня, которые обрабатываются движком этих СУБД.
Многоуровневые драйверы использует сервер РСУБД (Релячионное СУБД) для обработки SQL операторов. По мимо обработки ANSI SQL они так же могут поддерживать собственные конструкции конкретной СУБД (диалект) поскольку odbc может без трансляции передавать sql операторы источникам данных.
Технология ODBC разрабатывалась как общий независимый от источника данных способ доступа к данным. Применение этой технологии должно облегчить переносимость приложений в среду различных баз данных без переработки самих приложений.
Принципы построения систем ориентированных на анализ данных.
Раньше было OLTP (OnLineTrasactionProcessing) ~ Транзакционные.
OLAP(OnLineAnatiticalProcessing)
СППР(система поддержки принятия решения)
Сильнонормализованные модели данных подходят для OLTP приложений. Типичные примеры OLTP приложений — это банковские системы и системы резирвирования авиабилетов, торговля. Основная функция подобных систем заключаеться в выполнение большого количества коротких транзакций при этом сами транзакции достаточно простые. Например снять деньги со счёта, положить деньги на счёт и т.д. Таких транзакций достаточно много и выполняються они одновременно. Т е необходимо транзакционное управление и блокировки, если возникает ошибка транзакция откатывается. В таких системах большая часть запросов известна заранее, на этапе проектирования, критически важным для OLTP приложений являеться скорость и надёжность выполнения коротких операций обновления данных. Чем выше уровень нормализации тем приложение быстрее и надёжнее.
Другим типо мприложения являються OLAP приложения — это обобщённый термин характеризующий принцип построения СППР(DSS), хранилищ данных(DWH~DW), Системы интелектуального анализа данных (Data Mining)
-такие системы предназначены для нахождения зависимости между данными.
OLAP приложение оперирует с большими массивами данных, которые были накоплены в OLTP приложениях, например, или взяты из электронных таблиц и прочих источников данных. Такие системы характеризуються следующими признаками: 1 добавление в систему новых данных происходит относительно редко и крупными блоками. Например: раз в квартал загружеються данные из OLTP приложения.
Добавленные данные обычно никогда не удаляются.
Перед загрузкой данные проходят процедуры очистки, связанные с тем, ччто в одну систему могут поступать данные из многих источников, имеющих различнеы форматы представления для одних и тех же понятий, данные могут быть не корректными, ошибочными.
Запросы к системе не регламентированные и как правило достаточно сложными.
Скорость выполнения запросов важна, но не критична.
ETM (extract transform load)
Данные OLAP приложений представляютсья в виде одного или нескольких гиперкубов. Гиперкуб может быть реализован на физическом уровне (MOLAP) Multidimentional
Или иммулирован при помощи реяционой модели (ROLAP) Realational.
В ROLAP данные обычно храняться в виде слабо нормализованных отношений, содержащих заранее вычесленные основные итоговые данные. Избыточность данных в таких системах не вызывает проблем, поскольку обновление происходит только в момент загрузки новой порции данных. При эом происходит как и добавление новых данных, так и пересчёт итогов.
