http://slava.fateback.com |
38 |
Замечание. Свойство соединения без потерь информации не гарантируется.
Шаг 5. Если свойство соединения без потерь не выполнено, то строим обобщенный ключ X, такой, что X → U. Строим новую декомпозицию ρ0 = ρ X.
Формально это конец алгоритма. Декомпозиция становится схемой БД.
Утверждение 2.5 Все отношения декомпозиции ρ находятся в 3НФ.
Доказательство. Нарушение условий 3НФ может произойти на втором шаге. Пусть X → A1 объединяется с X → A2, и в результате получаем транзитивную зависимость. Пусть она такова: ZA1 → A2, Z X. На третьем шаге построения получаем: ZA1 → A1, X → A2 — а эти зависимости говорят о том, что F — не минимальное покрытие.
Утверждение 2.6 Декомпозиция ρ0 удовлетворяет свойству соединения без потерь информации.
Доказательство. Поскольку X является обобщенным ключом, X+ = U. Упорядочим атрибуты согласной той последовательности, в которой они включаются в X+. При включении Aj в замыкание используется зависимость Y → Aj. При построении декомпозиции ρ гарантируется, что схема отношения Ri, которая содержит Y , Aj. На очередной итерации построения таблицы будут выделены строки для X и для Ri, причем в строке Ri для Aj стоит aj, которое будет переписано в строку X. А так как X+ = U, то в конце концов в строке первичного ключа останутся только aj.
Замечание. В результате построения X может быть неинтерпретируемым (то есть, неназываемым). Причин может быть несколько:
1.Потеряна функциональная зависимость именно на атрибутах из X. Необходим пересмотр множества функциональных зависимостей.
2.Потеряны атрибуты или изменена их семантика. Рекомендуется дополнить атрибут или изменить семантику. Потерянные атрибуты выявляются на шаге 4.
3.В обобщенном ключе имеется многозначная зависимость. В этом случае необходимо провести декомпозицию (шаг 3).
Замечание. Возможна ситуация, когда обобщенный ключ интерпретируем, но на предприятии отсутствует служба, которая будет его заполнять. Выходов два: либо выступить перед руководством с инициативой создания такой службы, либо разнести базы и перейти к обслуживанию нескольких БД.
3Физическая организация базы данных. Алгоритмы работы СУБД
3.1Введение
При проектировании глобального логического описания не учитывалась информация о месте хранения данных и способе их обработки, поскольку это является содержанием только физического уровня. БД может быть расположена на одном компьютере, на разных серверах,
http://slava.fateback.com |
39 |
использовать различные механизмы тиражирования и распределения и так далее. В глобальном логическом описании этого ничего нет, там предполагается, что база едина.
Oracle, Postgress — наиболее перспективные в данном направлении СУБД, причем Postgress интереснее, но еще не запущена в промышленное производство. Разработчики большинства существующих СУБД закладывают один более или менее универсальный метод доступа к данным, и проблемы организации физического уровня в таких СУБД не возникает. Наиболее яркий пример — СУБД Access.
Для проектирования логического уровня наиболее подходящей является реляционная модель данных (так как для нее не возникает проблем с принципом независимости данных), поэтому разработчики реляционных СУБД вынуждены это описание переносить на физическое представление, где оно теряет все преимущества и становится самым неэффективным. Самой же эффективной моделью физического представления является сетевая.
Беда программистов — но не их вина — в том, что отсутствуют алгоритмы преобразования данных для разнотипных моделей данных.
В общем случае должно быть построено преобразование Ω → Ω0, где Ω — исходная модель данных, Ω0 — целевая модель данных. Ω — это алгебраическая система
Ω =< M, D, P, F >, где
M — схема БД.
D — совокупность состояний базы данных.
M и D в совокупности являются носителем системы.
P — совокупность предикатов, ограничивающих допустимые состояния базы данных (т.е. это функциональные зависимости, многозначные зависимости в виде предикатов, зависимости соединения и т. д.)
F — совокупность операций для преобразования БД (f F — элементарная операция, предназначенная для перевода БД из одного состояния в другое).
Пример. Пусть дана схема БД:
R1 |
|
|
R2 |
|
|
A |
B |
|
A |
B C |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
M
Таким образом, задано множество M — схема БД. Теперь D:
AB
a1 b1
a2 b2
Совокупность картежей в этих отношениях задает одно элементарное состояние базы
данных. Изменение хотя бы одного значения в таблице приводит к переходу БД в другое состояние. Пусть Dom обозначает домен. Тогда Dom(R1.A) × Dom(R1.B) × Dom(R2.A) × Dom(R2.B) × Dom(C) есть область всех состояний БД (в данном случае это пятимерное пространство). R1.A и R2.A мы различаем, так как у них могут оказаться разные домены.
Область всех значений по определению — это некоторый гиперкуб.
http://slava.fateback.com |
40 |
Что такое D? На множество всех значений накладываются ограничения в виде предикатов P , и, фактически, множество допустимых значений D есть некоторое подмножество этого гиперкуба.
D
Операция f переводит базу данных из состояния d1 в состояние d2.
D
f
f F ; f : d1 → d2
Таким образом, построение преобразования (согласно Калиниченко) заключается в следующем построении:
1.α : (M, P ) → (M0, P 0)2,
2.β : D → D03,
γ: f → f0
3.([d1 → d2] → [d01 → d02])4.
Построенные функции должны удовлетворять условиям коммутативности:
ξ |
D |
(M, P ) −→ |
|
1. α ↓ |
↓ β Здесь ξ1 и xi0 — функции семантической интерпретации. Калиниченко в |
(M0, P 0) −→ξ0 D0
своей работе предложил так называемый доминантный подход семантической интерпретации — сопоставление допустимых состояний.
2. Второй подход к определению семантической интерпретации:
|
β |
d1 |
−→ d10 |
f ↓ |
↓ f0 |
|
β |
d2 |
→− d20 |
2По исходной схеме и ограничениям целостности ищем целевую схему и ограничения целостности (к примеру, исходная модель реляционная, а целевая — сетевая).
3β — установление соответствия состояний исходной и целевой баз данных.
4Установление соответствия переходов состояний исходной и целевой базы данных.
http://slava.fateback.com |
41 |
Мы можем сначала построить переход f из исходной БД и потом через β получить d02, а можем сначала совершить переход, а уже затем d02. Главное, что попадаем при этом в одно и то же состояние.
3.Функция β должна быть коммутативной. На сайте Омского Госуниверситета www.omsu.omskreg.ru есть методичка Зыкина, посвященная этому вопросу.
3.1.1 Архитектуры современных ЭВМ
Архитектура ЭВМ оказывает существенное влияние на способ представления данных и алгоритмы их обработки.
Рассмотрим классификацию современных ЭВМ, предложенную Михаэлем Флинном в 1968 году. Еще одна классификация предложена Стоунбрейкером в 1995 году (см. журнал «СУБД», он есть на сайте www.osp.ru)
Классификация Михаэля Флинна:
1.ОКОД — одиночные команды, одиночные данные. Принцип — в каждый момент времени одиночное данное обрабатывается одиночной командой. По этому принципу работают первые три поколения ЭВМ. Именно на таких машинах мы работаем сейчас (весна 2003 года). Эта архитектура также называется фон-Неймановской.
2.МКОД — многие команды, одиночные данные. Одиночный поток данных обрабатывается сразу несколькими командами. Эта архитектура называется конвейерной или магистральной обработкой данных.
i 
i+1 
Другими словами, выходные данные процессора i являются входными для процессора i + 1.
Здесь алгоритмы, рассчитанные на ОКОД, без предварительной декомпозиции будут работать неэффективно.
Пример машин с такой архитектурой — машины Cray. Это интересная архитектура для оптимизации и моделирования физических явлений.
3.ОКМД — одиночные команды, многие данные. Самый распространенный пример таких машин - это машины с матричным процессором. Например, схематически матричное устройство умножения имеет следующий вид:
На горизонтальные и вертикальные входные шины одновременно подаются два операнда, в узлах пересечения стоят сумматоры, на выходе которых — результат умножения.
Примеры таких машин — M10 в России, ILIAC-IV в США.