Рекомендуемая архитектура распределенных СУБД.

СУБД имеет множество отличий которые являются причиной того, что единого стандарта архитектуры нет. Рекомендуется оптимальная архитектура СУРБД, которая состоит из:

1) Набор глобальных внешних схем.

2) Глобальную концептуальную схему.

3) Схема фрагментации и схема распределения.

4) Набор схем для каждой локальной СУБД. Они должны удовлетворять 3-х уровневой архитектуре.

Разработка распределенных реляционных БД.

Рассмотрим 3 важнейших аспекта:

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

Распределение – каждый фрагмент сохраняется на сайте с учетом схемы их распределения.

Репликация – СУБД может поддерживать актуальную схему некоторого фрагмента на нескольких сайтах одновременно.

Проектирование выполняется на основе количественных и качественных показателей.

Количественная информ включает: кол-во запусков приложения на выполнение; сайт на котором выполняется приложение; требования к производительности трансакций и приложений.

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

Правил Дейта для СУРБД.

0) Основной принцип. Для конечного пользователя распределенная Бд должна выглядеть как не распределенная система.

1) Локальная автономность. Сайты СУРБД должны быть автономны, т.е. локальные данные принадлежат локальным владельцам, сопровождаются локально, контролируются все процессы на сайте только этим сайтом.

2) Отсутствие опоры на централизованный сайт. В системе не должно быть ни одного сайта без которого система не смогла бы работать.

3) Непрерывность функционирования.

4) Независимость от расположения.

5) Независимость от фрагментации.

6) Независимость от репликации.

7) Обработка распределенных запросов. Система должна обрабатывать данные расположенные более чем на одном сайте.

8) Обработка распределенных трансакций.

9) Независимость от типа оборудования.

10) Независимость от ОС.

11) Независимость от сетевой архитектуры.

12) Независимость от типа СУБД. СУБД должна иметь возмжность работать с различными моделями локальных СУБД.

Четыре последних правила при проектировании удовлетворяются частично.

Объектно-ориентированные СУБД. Требования к ООСУБД.

Развитие ООП привело к созданию объектно-ориентированных СУБД. ООП это эффективный подход к созданию сложных программ объединяющих в себе понятия инкапсуляция, полиморфизм и наследование. ООСУБД объединяют в себе возможности языка ООП с ф-циями управления данными традиционных СУБД.

ООСУБД должны удовлетворять:

(По Майеру): 1)Обеспечивать функционирование БД. 2)Поддерживать идентичность объектов. 3)Удовлетворять инкапсуляции. 4)Поддерживать объекты со сложным состоянием.

(По Хашафяну)ж 1) «Объектно-ориентированный подход»= «абстрактные типы данных» + «наследование» + «идентичность объектов». 2) «ООСУБД» = «Объекьно-ориентироанный подход» + «возможности БД.»

Объектно-реляционные СУБД.

Для расширения возможностей реляц БД необходимо пополнить их следующ. ф-циям.

Использование объектно-ориентированных компонентов.

1)Расширение пользовательских типов.

2)Инкапсуляция – объединение деклоративных и исполняемых частей.

3)Наследование (позволяет определить новый объект как потомок или предок уже описанного).

4)Полиморфизм – возможность иметь несколько методов с одним и тем же именем для разных объектов одной иерархии, т.е. это средство для развития объектов в потомках.

5)Динамическое связывание методов.

6)Использование составных объектов.

7)Поддержка идентичности объектов.

В каждом конкретном случае при построении ОРСУБД использ свойственные данному приложению ф-ции – кроме стандартных. Не взирая на разнообразие все они построены на базе реляционных таблиц и языка запросов, включают понятия объекта. Понятно, что разработка ОРСУБД построена на расширении стандартов языка запросов SQL3.

Концепция ОРСУБД как комбинация концепций ООСУЬД и РСУБД необыкновенно притягательна за счет применения всех тех богатейших знаний и опыта кот. были накоплены за время разработки реляц.БД.

Структура языка SQL.

Назначение SQL:

1) Создавать БД и таблицы с полным описанием их структур.

2) Выполнять основные операции манипулируя данными такие как вставка, модификация, удаление данных из табл.

3) Выполнять простые и сложные запросы осуществляя преобразование данных в нужную информ.

Языку предъявляются следующие требования, он должен быть прост и доступен, универсален (обеспечивать переход к другим СУБД). Язык состоит из 2-х основных компонентов:

1)DDL для определения структуры данных;

2)DML для обеспечения доступа к данным и их модификации.

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

Типы данных языка SQL.

Тип данных столбца определяет возможные операции со столбцом.

1) Символьные данные – буквы, цифры, спец. символы и имеют 2 основных типа: char(n) – строка фиксированной длины, всегда хранит указанное кол-во символов, отсутствующие заменяются пробелом справа; varchar – строка переменной длинны хранит столько символов, сколько введено. Данные заключаются в одинарные кавычки, в некоторых диалектах двойные.

2) Только числовые данные – состоят из чисел, не обязательно десятичной точки, не обязательно знаками. Данные определяются значностью и длиной дробной части. Значность – общее кол-во цифр без точки (12,345 – значность 5, длина дробной части 3).

DICIMAL[(P,C)]

NUMERIC[(P,C)] – по умолчанию длина дробной части =0;

INTEGER (INT) – целое число, используется для хранения больших целых чисел занимающих 4байта.

SMALLINT – использ для хранения целых чисел занимающих 2байта. Максимальное число в этом типе 32767.

Выбор одного из данных типов определяется только размером числа.

3) Приблизительно числовые (округленные) числа – использ для определения данных, которые нельзя точно определить в ПК, к ним относятся действительные числа, кот записываются с помощью мантисы.

REAL – действительное число, соответствующее вещественному типу с плавающей запятой, имеет меньшую точность чем следующие.

FLOAT[(n)] – действительные числа, записанные в формате с плавающей запятой, n – кол-во байт зарезервированных для числа.

DOUBLE PRECISION – числа с двойной точностью, обычно используются для инженерных расчетов.

4) Битовые данные служат для определения битовых строк (наборы нулей и единиц) могут иметь фиксированную или переменную длину BIT(n) и BIT VARIYING(n). Эти строки обычно использ для задания флагов, масок, изображений, кодов.

5) Дата и время использ для определения момента времени с установленной точностью. Стандарт делится на подгруппы: YEAR – год, MONTH – месяц, DAY – день, HOUR – час, MINUTE – минуты, SECOND – секунды, TIME ZONE_HOUR – временная зона час, TIME ZONE_MINUTE – зональная минута. Два последних типа определяют сдвиг времени от Гринвичского меридиана (времени).

DATE – дата, для хранения календарных дат, использ поля год, месяц, день.

TIME STAMP – совместное хранение даты и времени. TIME[точность] [TIME_ZONE]. Если точность опускается то по умолчанию = 0, для TIME STAMP точность = 6. Тип TIME дает возможность складывать и вычитать даты.

6) Данные типа интервалов – используются для предоставления периодов времени. Может использовать поля: YEAR, MONTH, DAY, HOUR, MINUTE, SECOND. Существует 2 типа интервалов: 1 – Интервал год, месяц (использует 2 поля год и/или месяц); 2 – Интервал день, время (использует 2 поля день и/или время). Данный тип предполагает сложение и вычитание дат.