Приложение

	ностью, потому что база дан-					структуры подогнаны под ис-		труднений. В СУБД, "" поддерживаю-
	ных структурирована для су-					ходные приложения. Изменить		щей выбор структуры файлов,для раз-
	ществовавших		ранее прило-			базовую структуру так, чтобы		ных таблиц могут быть выбраны самые
	жений. Поэтому может ока-					обеспечить	удовлетворитель-	подходящие структуры данных
	заться не возможным эф-					ную работу базы данных со
	фектно	поддерживать			все	всеми требуемыми приложе-
	требуемые приложения					ниями,достаточно сложно или
						даже вообще не возможно. Ве-
						роятно, для этого потребуется
						создать	дополнительные
						структуры
Простота проек-	Вероятно, потребуется ква-					Проектирование могут выпол-		Большинство пользователей (включая
тирования	лифицированная			помощь,		нить только опытные специа-		конечных пользователей) легко поймут
	особенно	при		определении		листы-эксперты		логическую структуру данных,а пото-
	необходимых		структур		дан-			му смогут спроектировать базу данных
	ных и при разработке связан-							и отобразить её на физические струк-
	ных с ними прикладных про-							туры. К сожалению, недостаточное
	грамм							знание методов проектирования баз
								данных может привести к созданию
								слабых, неэффективных и негибких
								макетов

Доступ к	базе	Стандартные методы до-		Здесь также доступ осу-			Доступ может варьироваться от ис-
данных		ступа посредством API: при-		ществляется	исключительно		пользования API до таких интерактив-
		ложение содержит встроен-		посредством	API.	Команды	ных языков, как SQL или QBE. Языки
		ные вызовы процедур для ра-		обрабатывают записи по од-			запросов позволяют конечным пользо-
		боты с СУБД, команды обра-		ной, но при этом они могут			вателям опрашивать базу данных в
		батывают записи	последова-	влиять и на зависимые записи.			произвольной манере. Кроме того,
		тельно, по одной, хотя потен-		Благодаря использованию спе-			SQL-команды могут внедряться в при-
		циально они могут оказывать		циальных команд		навигации	кладные программы
		влияние и на другие записи.		по базе данных пользователь
		Дополнительные	программ-	может перемещаться к разным
		ные конструкции	необходи-	местам иерархической струк-
		мы для навигации по базе		туры. Для обработки наборов
		данных и обработки наборов		записей могут потребоваться
		записей		специальные	программные
				конструкции

Стандарты	Для CODASYL-совместимой		Для иерархической модели	Для реляционных моделей данных су-
	модели	данных существует	данных не существует строго-	ществует набор стандартных концеп-
	набор	стандартных концеп-	го набора стандартных кон-	ций, хотя между разными реализация-
	ций,хотя между разными реа-		цепций, а реализации этой мо-	ми есть некоторые различия

	лизациями	есть некоторые	дели не соответствуют какому-
	различия		либо особому стандарту

Приложение 4. ОБОБЩЕННАЯ МЕТОДИКА ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

Процесс разработки баз данных включает три фазы:

1.концептуальное (инфологическое) проектирование;

2.логическое проектирование;

3.физическое проектирование [7, 17].

ЭТАП 1

Создание локальной концептуальное модели данных исходя из представлений о предметной области каждого из типов пользователей

Построение локальной концептуальной модели данных организации с точки зрения представления о функционировании организации каждого из существующих типов пользователей.

1.1. Определение типов сущностей

Определение основных типов сущностей, присутствующих в представлении данного пользователя о предметной области приложения. Документирование выделенных типов сущностей.

1.2. Определение типов связей

Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе. Определение кардинальности связей и ограничений участия их членов. Документирование типов связей. При необходимости могут использоваться диаграммы «сущность-связь» (ER-диаграммы).

1.3. Определение атрибутов и связывание их с типами сущностей и свя-

зей

Связывание атрибутов с соответствующими типами сущностей или связей. Идентификация простых и составных атрибутов. Документирование сведений об атрибутах.

1.4. Определение доменов атрибутов

Определение доменов для всех атрибутов в каждой локальной концептуальной модели данных. Документирование сведений о доменах атрибутов.

1.5.Определение атрибутов, являющихся потенциальными и первичными ключами

Определение потенциального ключа для каждого типа сущности; если таких ключей окажется несколько, выбор среди них первичного ключа. Документирование сведений о первичных и альтернативных ключах для каждой сильной сущности.

1.6.Специализация или генерализация типов сущностей (необязатель-

но)

Определение суперклассов и подклассов для типов сущностей (при необходимости).

1.7.Создание диаграммы «сущность-связь»

Разработка диаграмм ~сущность-связь» (KR-диаграмм), содержащих концептуальное отражение представлений пользователей о предметной области приложения.

1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями

Обсуждение локальных концептуальных моделей данных с конечными пользователями для получения подтверждений того, что данная модель корректно отражает представления пользователей о приложении и организации.

ЭТАП 2 Построение и проверка локальной логической модели данных на осно-

ве представлений о предметной области каждого из типов пользователей

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

2.1.Преобразование локальной концептуальной модели данных в локальную логическую

модель Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных. Удаление связей типа М:N, сложных связей, рекурсивных связей, множественных атрибутов, связей с атрибутами и избыточных связей. Перепроверка связей типа 1:1.

2.2.Определение набора отношений исходя из структуры локальной логической модели данных

Определение на основе локальных логических моделей данных набора отношений, необходимого для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения. Документирование сведений о новых первичных или потенциальных ключах, которые были определены в процессе создания отношений на основе логической модели данных.

2.3.Проверка модели с помощью правил нормализации

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

2.4. Проверка модели в отношении транзакций пользователей

Цель выполнения этого этапа – убедиться в том, что локальная логическая модель данных позволяет выполнить все транзакции, предусмотренные данным представлением пользователя. 2.5. Создание диаграмм «сущность-связь» Создание диаграмм «сущность-связь» (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.

2.6. Определение требований поддержания целостности данных

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

2.7.Обсуждение разработанных локальных логических моделей данных

сконечными пользователями

Назначение данного этапа – убедиться в том, что созданные локальные модели данных точно отражают представления пользователей о предметной области приложения.

ЭТАП 3 Создание и проверка глобальной логической модели данных

Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных, представляющую ту часть организации, которая охватывается данным приложением.

3.1.Слияние локальных логических моделей данных в единую глобальную модель данных

Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных организации. В круг решаемых при этом задач включены следующие:

–анализ имен сущностей и их первичных ключей

–анализ имен связей;

–слияние общих сущностей из отдельных локальных моделей;

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

–слияние общих связей из отдельных локальных моделей;

–включение (без слияния) связей, уникальных для каждого локального представления;

–проверка на наличие пропущенных сущностей и связей;

–проверка корректности внешних ключей;

–проверка соблюдения ограничений целостности;

–выполнение чертежа глобальной логической модели данных;

–обновление документации.

3.2.Проверка глобальной логической модели данных

Проверка глобальной логической модели данных с помощью методов нормализации и контроль возможности выполнения требуемых транзакций. На этом этапе выполняются действия, аналогичные тем, которые производились на этапах 2.3 и 2.4 при проверке каждой из локальных логических моделей данных.

3.3. Проверка возможностей расширения модели в будущем

Определение вероятности внесения каких-либо существенных изменений в созданную модель данных в обозримом будущем и оценка того, насколько данная модель приспособлена для внесения подобных изменений.

3.4. Создание окончательного варианта диаграммы «сущность-связь»

Создание окончательного варианта диаграммы «сущность-связь», представляющей глобальную логическую модель данных организации.

3.5. Обсуждение глобальной логической модели данных с пользователями

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

ЭТАП 4 Перенос глобальной логической модели данных в среду целевой СУБД

Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.

4.1. Проектирование таблиц базы данных в среде целевой СУБД.

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

4.2. Реализация бизнес правил организации в среде целевой СУБД

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

ЭТАП 5 Проектирование физического представления базы данных

Определение файловой структуры и методов доступа, которые будут использоваться для представления таблиц базы данных. Другими словами, определение способа хранения таблиц и их строк во вторичной памяти.

5.1. Анализ транзакций

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

5.2. Выбор файловой структуры

Определение самого эффективного файлового представления для каждой из таблиц базы данных.

5.3. Определение вторичных индексов

Определение того, будет ли добавление вторичных индексов способствовать повышению производительности системы.

5.4.Анализ необходимости введения контролируемой избыточности

данных

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

5.5.Определение требований к дисковой памяти

Определение объема дискового пространства, необходимого для размещения базы данных.

ЭТАП б Разработка механизмов защиты

Разработка механизмов защиты базы данных в соответствии с требованиями пользователей.

6.1. Разработка пользовательских представлений (видов)

Разработка пользовательских представлений (видов), которые были выделены на первом этапе концептуального проектирования базы данных.

6.2. Определение прав доступа

Определение прав доступа к таблицам базы данных для каждого из представлений пользователей. Документирование результатов разработки средств защиты и прав представлений пользователей.

ЭТАП 7 Организация мониторинга и настройка функционирования системы

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

Приложение 6. ПРАВИЛА РАСПРЕДЕЛЕННЫХ СУБД

Двенадцать правил (или целей) были сформулированы Дейтом для типичной РСУБД. Основой для построения всех этих правил является то, что распределенная СУБД должна восприниматься конечным пользователем точно так же, как и централизованная СУБД. Данные правила сходны с двенадцатью правилами Кодда для реляционных систем, представленными в [7].

Правило 1 Основной принцип. Локальная автономность

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

Сайты в распределенной системе должны быть автономными. В данном контексте автономность означает следующее:

–локальные данные принадлежат локальным владельцам и сопровождаются локально;

–все локальные процессы остаются чисто локальными;

–все процессы на заданном сайте контролируются только этим сайтом.

Правило 2 Отсутствие опоры на центральный сайт

В системе не должно быть ни одного сайта, без которого система не сможет функционировать. Это означает, что в системе не должно существовать центральных серверов таких служб, как управление транзакциями, выявление взаимных блокировок, оптимизация запросов и управление глобальным системным каталогом.

Правило 3 Непрерывное функционирование

В идеале, в системе никогда не должна возникать потребность в плановом останове ее функционирования для выполнения таких операций, как:

–добавление или удаление сайта из системы;

–динамическое создание или удаление фрагментов из одного или нескольких сайтов.

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

Независимость от расположения эквивалентна прозрачности расположения. Пользователь должен получать доступ к базе данных с любого из сайтов. Более того, пользователь должен получать доступ к любым данным так, как если бы они хранились на его сайте, независимо от того, где они физически сохраняются.

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

Пользователь должен получать доступ к данным независимо от способа их фрагментации.

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

Пользователь не должен нуждаться в сведениях о наличии репликации данных.

Это значит, что пользователь не будет иметь средств для получения прямого доступа к конкретной копии элемента данных, а также не должен заботиться об обновлении всех имеющихся копий элемента данных.

Правило 7 Обработка распределенных запросов

Система должна поддерживать обработку запросов, ссылающихся на данные, расположенные на более чем одном сайте.

Правило 8 Обработка распределенных транзакций

Система должна поддерживать выполнение транзакций, как единицы восстановления.

Система должна гарантировать, что выполнение как глобальных, так и локальных транзакций будет происходить с сохранением четырех основных свойств транзакций, а именно: атомарности, согласованности, изолированности и продолжительности.

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

СУРБД должна быть способна функционировать на оборудовании с различными вычислительными платформами.

Правило 10 Независимость от операционной системы

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

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

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

Правило 12 Независимость от типа СУБД

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