Информационное обеспечение систем управления

Администратор базы данных

Администратор базы данных – человек (или группа лиц), имеющий полное представление об одной или нескольких базах данных и контролирующий их проектирование и использование. Отвечает за состояние базы данных в организации (учреждении) на протяжении ее жизненного цикла. Функциями АБД являются [12, 17]:
– решение вопросов организации данных об объектах предметной области и установлении связей между этими данными с целью объединения информации о различных объектах; согласование представлений пользователей;
– координация всех действий по проектированию, реализации и ведению БД; учет перспективных и текущих требований пользователей;
– решение вопросов, связанных с расширением БД в связи с изменением границ предметной области;
– разработка и реализация мер по обеспечению защиты данных от некомпетентного использования, от сбоев технических средств, по обеспечению секретности определенной части данных и разграничению доступа к данным;
– выполнение работ по ведению словаря данных; контроль неизбыточности и непротиворечивости данных, их достоверности;
– обеспечение заданной производительности БД, чтобы обработка запросов выполнялась за приемлемое время;
– изменение при необходимости методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определение степени влияния изменений на всю БД;
– координация вопросов технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию;
– координация работы системных программистов разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы;
– координация работы прикладных программистов разрабатывающих новые пакеты программ и выполнение их проверки и включение в состав программного обеспечения системы.
Таким образом, при реализации достаточно сложных проектов, группа АБД может включать ряд специалистов, представленных на рис. 1.10 [17].

Рис. 1.10. Состав группы АБД

Аксиомы вывода функциональных зависимостей

Для отношения  в любой момент существует некоторое семейство F-зависимостей, которым это отношение удовлетворяет. Здесь может возникнуть та же проблема, что и с ключами: одно состояние отношения может удовлетворять F-зависимости, а другое – нет.
Требуется выявить семейство F-зависимостей , которому удовлетворяют все допустимые состояния. Чтобы найти , необходимы семантические знания об отношении . Поэтому можно считать семейство F-зависимостей заданным в схеме отношения. В этом случае любое отношение  должно удовлетворять всем F-зависимостям из . Не всегда ясно, что является первичным: множество допустимых состояний отношения, которое определяет F-зависимости, или F-зависимости накладывают ограничения на схему отношения [10].
Множество функциональных зависимостей, применимых к отношению, конечно, так как существует только конечное число подмножеств множества. Таким образом, всегда можно найти все F-зависимости, которым удовлетворяет . Однако этот подход требует большого количества шагов и, соответственно, много времени.
Если известны некоторые F-зависимости из , то часто можно вывести остальные.
Множество F-зависимостей  влечет за собой зависимость, если каждое отношение, удовлетворяющее всем зависимостям в F, удовлетворяет также зависимости.
Аксиома вывода – это правило, устанавливающее, что если отношение удовлетворяет определенным F-зависимостям, то оно должно удовлетворять и некоторым другим F-зависимостям.
Сформулировано шесть аксиом вывода F-зависимостей [10]. В этих формулировках используется обозначение r для отношения на  и , ,  и  – для подмножеств .
Fl. Рефлексивность. .
F2. Пополнение.  влечет за собой .
F3. Аддитивность.  и  влечет за собой .
F4. Проективность. влечет за собой.
F5. Транзитивность.  и  влечет за собой .
F6. Псевдотранзитивность.   и  влечет за собой .
Некоторые аксиомы вывода могут быть получены из других. Например, транзитивность F5 является частным случаем псевдотранзитивности F6 при .
Приведенная система аксиом F1-F6 является полной. Это означает, что каждая F-зависимость, которая следует из множества Р, может быть выведена путем одно- или многократного применения к F этих аксиом.

Из аксиом Fl, F2 и F6 можно вывести остальные, а значит, они образуют полное подмножество для F1-F6. Аксиомы Fl, F2 и F6 являются также независимыми: ни одна из этих аксиом не может быть получена из двух других. Иногда эти три аксиомы называются аксиомами Армстронга.

Пусть  – множество F-зависимостей для отношения . Замыкание , обозначаемое , - это наименьшее содержащее  множество, такое, что при применении к нему аксиом Армстронга нельзя получить ни одной F-зависимости, не принадлежащей . Так как  должно быть конечно, то можно вычислить его, начиная с  путем применения Fl, F2 и F6 и добавления полученных F-зависимостей к  до тех пор, пока не перестанут получаться новые зависимости. Замыкание  зависит от схемы.

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

Пример 2.5. Пусть  – множество F-зависимостей на .

Тогда:







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

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

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

Суперключ – это любая совокупность атрибутов, содержащая ключ.

Нормализация – формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей) и существующих функциональных зависимостей [2, 7,10].

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

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


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

В теории реляционных баз данных разработано несколько нормальных форм (НФ), которые подчиняются правилу вложенности (рис. 2.25).

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

При реализации реляционной БД важно понимать, что только удовлетворение требований первой нормальной формы (1НФ) обязательно для создания отношений приемлемого качества. Все остальные формы могут использоваться по желанию проектировщика. Однако чтобы избежать аномалий обновления, описываемых ниже, нормализацию рекомендуется проводить как минимум до 3НФ.

Аксиомы вывода многозначных зависимостей

В разд. 2.4.3.2 определены аксиомы вывода функциональных зависимостей.
Первые шесть аксиом вывода, приведенные ниже, являются аналогами одноименных аксиом для F-зави-симостей, однако только первые три из них содержат похожие утверждения. Аксиома М7 не имеет аналога в F-зависимостях [10]. Пусть г – отношение со схемой R и W, X, У, Z – подмножества R.
Ml. Рефлексивность.
Отношение г удовлетворяет XX.
М2. Пополнение. Если r  удовлетворяет XY, то оно удовлетворяет XZУ.
МЗ. Аддитивность. Если r удовлетворяет ХY   и XZ, то оно Удовлетворяет XYZ..
М4. Проективность. Если г удовлетворяет XY и XZ, то оно удовлетворяет XYZ  и  ХУ-Z.
М5. Транзитивность. Если r удовлетворяет ХY и УZ, то г удовлетворяет XZ-Y.
M6. Псевдотранзитивность. Если r удовлетворяет XY и YWZ, то r удовлетворяет XWZ-(YW).
M7. Дополнение. Если r удовлетворяет XY и Z=R-(XY), то r удовлетворяет XZ.
Система аксиом вывода Ml – М7 для MV-зависи-мостей является полной [10].
Обратимся к следствиям, которые можно вывести из множества F- и MV-зависимостей. Для их комбинации существуют только две аксиомы.
Пусть r – отношение со схемой R; W, X, Y, Z – подмножества R.
С1. Копирование. Если r удовлетворяет XY, то r удовлетворяет XY.
С2. Объединение. Если r удовлетворяет XY и ZW, где  WY и YZ=Ø, то г удовлетворяет XW.
Системы аксиом F1 – F6, Ml – М7, С1 и С2 для множеств F- и MV-зависимостей являются полными [10].

Архитектура многопользовательских СУБД

В этом разделе приводятся различные типовые архитектурные решения, используемые при реализации многопользовательских СУБД, а именно схемы обычной телеобработки, файловый сервер и технология «клиент/сервер» [7].
Телеобработка
Традиционной архитектурой многопользовательских систем раньше считалась схема, получившая название «телеобработки», при которой один компьютер с единственным процессором был соединен с несколькими терминалами так. как показано на рис. 1.6 [7]. При этом вся обработка выполнялась в рамках единственного компьютера, а присоединенные к нему пользовательские терминалы были типичными «неинтеллектуальными» устройствами, не способными функционировать самостоятельно. С центральным процессором терминалы были связаны с помощью кабелей, по которым они посылали сообщения пользовательским приложениям (через подсистему управления обменом данными операционной системы). В свою очередь, пользовательские приложения обращались к необходимым службам СУБД. Таким же образом сообщения возвращались назад на пользовательский терминал. Недостатком является то, что при такой архитектуре основная и чрезвычайно большая нагрузка возлагалась на центральный компьютер, который должен был выполнять не только действия прикладных программ и СУБД, но и значительную работу по обслуживанию терминалов (например, форматирование данных, выводимых на экраны терминалов).

Рис. 1.6. Топология телеобработки
В последние годы был достигнут существенный прогресс в разработке высокопроизводительных персональных компьютеров и составленных из них сетей. При этом во всей индустрии наблюдается заметная тенденция к децентрализации (downsizing), т.е. замене дорогих мейнфреймов более эффективными, с точки зрения эксплуатационных затрат, сетями персональных компьютеров, позволяющими получить такие же результаты, если не лучше. Эта тенденция привела к появлению следующих двух типов архитектуры СУБД: технологии файлового сервера и технологии «клиент/сервер».
Файловый сервер
В среде файлового сервера обработка данных распределена в сети, обычно представляющей собой локальную вычислительную сеть (ЛВС).
Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлам – как показано на рис. 1.7[7].



Рис. 1.7. Архитектура с использованием файлового сервера

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

Архитектура с использованием файлового сервера обладает следующими основными недостатками.

1. Большой объем сетевого графика.

2. На каждой рабочей станции должна находиться полная копия СУБД.

3. Управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.

Технология «клиент/сервер»

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

процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы они находились на одном и том же компьютере. На практике принято размещать сервер на одном узле локальной сети, а клиенты – на других узлах. На рис. 1.8 показана архитектура типа «клиент/сервер» [7].



Рис. 1.8. Общая схема построения систем с архитектурой «клиент/сервер»

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


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

полнение запроса и обновление данных. Помимо этого поддерживается управление параллельностью и восстановлением. Выполняемые клиентом и сервером операции приведены в табл. 1.1 [7].

Таблица 1.1

Клиент	Сервер
Управляет пользовательским интерфейсом	Принимает и обрабатывает запросы к базе данных со стороны клиентов
Принимает и проверяет синтаксис введенного пользователем запроса	Проверяет полномочия пользователей
Выполняет приложение	Гарантирует соблюдение  ограничений целостности
Генерирует запрос к базе данных и передает его серверу	Выполняет запросы/обновления  и возвращает результаты клиенту
Отображает полученные данные пользователю	Поддерживает системный каталог
	Обеспечивает параллельный доступ к базе данных
	Обеспечивает управление восстановлением

Этот тип архитектуры обладает приведенными ниже преимуществами.

– Обеспечивается более широкий доступ к существующим базам данных.

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

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


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

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

– Эта архитектура весьма естественно отображается на архитектуру открытых систем.

Некоторые разработчики баз данных использовали эту архитектуру для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети. Однако, несмотря на то, что архитектура «клиент/сервер» вполне может быть использована для организации распределенной СУБД, сама по себе она не образует распределенную СУБД. Более подробно распределенные СУБД обсуждаются в главе 5.

Архитектура распределенных СУБД

Трехуровневая архитектура АЫ81-8РАЕС для СУБД, обсуждавшаяся в разделе 1.3, представляет собой типовое решение для централизованных СУБД. Однако распределенные СУБД имеют множество отличий, которые сложно отразить в некотором эквивалентном архитектурном решении, приемлемом для большинства случаев.
Один из примеров рекомендуемой архитектуры СУРБД представлен на рис. 5.3. Он включает следующие элементы [7]:
– набор глобальных внешних схем;
– глобальную концептуальную схему;
– схему фрагментации и схему распределения;
– набор схем для каждой локальной СУБД, отвечающих  требованиям трехуровневой архитектуры АМ81-8РАКС.

Рис. 5.3. Рекомендуемая архитектура СУРБД
Соединительные линии на схеме представляют преобразования, выполняемые при переходе между схемами различных типов. В зависимости от поддерживаемого уровня прозрачности некоторые из уровней рекомендуемой архитектуры могут быть опущены.
Глобальная концептуальная схема
Глобальная концептуальная схема представляет собой логическое описание всей базы данных, представляющее ее так, как будто она не является распределенной. Этот уровень СУРБД соответствует концептуальному уровню архитектуры АЫ81-8РАЕС и содержит определения сущностей, связей, требований защиты и ограничений поддержки целостности информации. Он обеспечивает физическую независимость данных от распределенной среды. Логическую независимость данных обеспечивают глобальные внешние схемы.
Схемы фрагментации и распределения
Схема фрагментации содержит описание того, как данные должны логически распределяться по разделам. Схема распределения является описанием того, где расположены имеющиеся данные. Схема распределения учитывает все организованные в системе процессы репликации.
Локальные схемы
Каждая локальная СУБД имеет свой собственный набор схем. Локальная концептуальная и локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры АК81-8РАЕС.
Локальная схема отображения используется для отображения фрагментов в схеме распределения во внутренние объекты локальной базы данных. Эти элементы являются зависимыми от типа используемой СУБД и служат основой для построения гетерогенных СУРБД.

Независимо от рекомендованной общей архитектуры СУРБД компонентная архитектура СУРБД должна включать четыре следующих важнейших компонента (рис. 5.4) [7]:

1) локальную СУБД;

2) компонент передачи данных;

3) глобальный системный каталог;

4) распределенную СУБД (СУРБД).



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

Локальная СУБД

Компонент локальной СУБД представляет собой стандартную СУБД, предназначенную для управления локальными данными на каждом из сайтов, входящих в состав распределенной базы данных. Локальная СУБД имеет свой собственный системный каталог, в котором содержится информация о данных, сохраняемых на этом сайте. В гомогенных системах на каждом из сайтов в качестве локальной СУБД используется один и тот же программный продукт. В гетерогенных системах существуют, по крайней мере, два сайта, использующих различные типы СУБД и/или различные типы вычислительных платформ.

Компонент передачи данных

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

Глобальный системный каталог

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

Что касается отношений, созданных на некотором сайте (сайте создания),

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

Распределенная СУБД

Компонент распределенной СУБД является управляющим по отношению ко всей системе элементом. В предыдущем разделе описаны основные функциональные возможностями, которыми должен обладать этот компонент.

Бинарный поиск

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

В этом случае можно построить более эффективные алгоритмы поиска, поскольку после сравнения значения (условие поиска Q: ) со значением ключа -й записи файла ясно, в какой части файла продолжать поиск [17].
Методы поиска записей в упорядоченном файле различаются друг от друга стратегией выбора очередной записи из файла для выполнения операции сравнения ключа в соответствии с заданным условием Q. Метод бинарного поиска основан на делении интервала поиска пополам.
Поиск по равенству . Алгоритм поиска заключается в следующем. Файл считают упорядоченным по возрастанию ключа. Сравнивают значения ключа средней записи , где со значением . Если  то поиск удачный и алгоритм заканчивает свою работу. Если , то для продолжения поиска выбирается средняя запись правой половины файла: , где

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

Процесс деления интервала пополам продолжается до тех пор, пока не будет найдена искомая запись (), либо пока в интервале не останется всего одна запись. Если значение ее ключа не удовлетворяет условию поиска, то поиск неудачный и искомой записи в файле нет.
Бинарный поиск можно выполнять, работая с блоками файла, а не с записями. При считывании блока в оперативную память поиск записи в блоке может быть последовательным. В этом случае в качестве характеристик блока используются граничные значения ключей записей, находящихся в блоке.
Поиск по интервалу значений . Алгоритм поиска следующий. Вначале выполняется бинарный поиск записи, значение ключа которой удовлетворяет условию , либо, если такой записи нет в файле, то значение ключа которой является наиболее близким к  по условию . Далее последовательно читаются записи в блоках файла до тех пор, пока не будет нарушено условие: .

Цели и подходы к проектированию баз данных

Процесс проектирования БД представляет собой сложный процесс проектирования отображения [17]:
«Описание предметной области» ?? «схема внутренней модели базы данных».
Этот процесс представляется последовательностью более простых, обычно итеративных, процессов проектирования менее сложных отображений между промежуточными моделями данных, т.е. последовательностью проектирования моделей уровней абстрагирования. Основные уровни абстрагирования в БД [17]:
– информационный,
– внешний,
– концептуальный,
– внутренний.
В процессе проектирования БД разрабатываются схемы моделей названных уровней, проверяется возможность отображения объектов одной модели в объекты другой модели.
Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы).
Наличие постоянных и разовых пользователей в автоматизированных информационных системах, и, следовательно, наличие потока регламентированных и произвольных по содержанию запросов требуют разработки специальных подходов к определению границ ПО и проектированию состава элементов информационной модели. Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений [5, 17]. (Так в больших городах создается не одна, а несколько овощных баз, расположенных в разных районах.)
Если бы в АИС существовал только поток регламентированных запросов и не ожидалось развитие системы, то можно было бы определить границы ПО и осуществить проектирование исходя из анализа содержания всей совокупности запросов пользователей – это так называемый подход к проектированию «от запросов пользователей» [17].

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

Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, «чистый» проект БД – «Каждый факт в одном месте» [5, 8].

При проектировании базы данных решаются две основных проблемы.

1. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

2. Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных [5, 8].

Четвертая нормальная форма

Известно, что каждое отношение r(R), удовлетворяющее MV-зависимости ХY, разлагается без потерь на отношения со схемами ХY и XZ, где Z=R-(XY). Однако в случае если XY – единственная зависимость в R, то R находится в ЗНФ. Таким образом, ЗНФ не определяет все возможные декомпозиции.
MV-зависимость ХY называется тривиальной. Для произвольной схемы R, содержащей ХY, если любое отношение r(R) удовлетворяет XY  [10].
Пусть F – множество F- и MV-зависимостей над U. Схема отношения RU находится в четвертой нормальной форме (4НФ) относительно F, если для каждой MV-зависимости XY, выводимой из F a приложимой к R, либо MV-зависимость тривиальна либо X является суперключом для R [10].
Схема базы данных R находится в четвертой нормальной форме относительно F, если каждая входящая в нее схема отношения находится в четвертой нормальной форме относительно F.
Множество F из F-зависимостей и MV-зависимостей, аналогично тому как это делается для построения схем баз данных в ЗНФ, может быть использовано для построения декомпозиций схемы отношения R, находящихся в 4НФ. Для этого, начав с R, ищем выводимую из F нетривиальную MV-зависимость ХY  , для которой X не является ключом R. Далее R разлагаем на два отношения R1=(X, Y) и R2=(X, Z), где Z=R-(XY). MV-зависимость ХY  теперь тривиальна в R1 и неприложима к R2. Процесс декомпозиции повторяем для той из схем R1 и R2, которая не находится в 4НФ относительно F. Поскольку используемые MV-зависимости не являются тривиальными, обе возникающие реляционные схемы содержат меньше атрибутов, чем исходные. Таким образом, процесс декомпозиции неизбежно закончится.

Даталогические модели данных

Модель данных – фиксированная система понятий и правил для представления структуры данных, состояния и динамики проблемной области в базах данных [12]. Как правило, задается языком определения данных и языком манипулирования данными. Примерами модели данных, получившими широкое распространение, являются модели данных сетевая, иерархическая, реляционная и др.
Модель данных состоит из трех компонент [11].
1. Структура данных для представления точки зрения пользователя на базу данных.
2. Допустимые операции, выполняемые на структуре данных. Они составляют основу языка данных рассматриваемой модели данных. Одной лишь хорошей структуры данных недостаточно. Необходимо иметь возможность работать с этой структурой при помощи различных операций языка определения данных и языка манипулирования данными. Богатая структура данных ничего не стоит, если нет возможности оперировать ее содержимым.
3. Ограничения для контроля целостности. Модель данных должна быть обеспечена средствами, позволяющими сохранять ее целостность и защищать ее.
Схема – это средство, с помощью которого определяется модель данных приложения. В действительности схема содержит не только модель данных: в ней присутствует также некоторая семантическая информация, относящаяся к конкретному приложению. В модели данных можно определить, например, что база данных будет хранить информацию об организациях и служащих. Однако, тот факт, что данный служащий не может работать более чем в одной организации, отражает семантику приложения. Это семантическое ограничение должно выполняться для каждого отдельного экземпляра записи базы данных об этом служащем. Поддержка ограничений заданной модели данных в базе данных также является частью функций СУБД по обеспечению защиты и целостности.
Прежде, чем перейти к детальному и последовательному изучению реляционных систем БД, целесообразно ознакомиться с ранними СУБД [8]. В этом есть смысл по трем причинам: во-первых, эти системы исторически предшествовали реляционным, и для правильного понимания причин повсеместного перехода к реляционным системам нужно знать хотя бы что-нибудь про их предшественников; во-вторых, внутренняя организация реляционных систем во многом основана на использовании методов ранних систем; в-третьих, некоторое знание в области ранних систем будет полезно для понимания путей развития постреляционных СУБД. Подробный сравнительный анализ даталогических моделей приведен в прил. 3.

Достоинства и недостатки даталогических моделей

Сначала остановимся коротко на ранних (дореляционных) СУБД. Ограничимся рассмотрением только общих особенностей ранних систем, а именно, систем, основанных на иерархических и сетевых моделях [8].
1. Эти системы активно использовались в течение многих лет, дольше, чем используется какая-либо из реляционных СУБД. На самом деле некоторые из ранних систем используются даже в наше время, накоплены громадные базы данных, и одной из актуальных проблем информационных систем является использование этих систем совместно с современными системами.
2. Все ранние системы не основывались на каких-либо абстрактных моделях. Как упоминалось, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков! у различных конкретных систем.
3. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
4. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
5. После появления реляционных систем большинство ранних систем было оснащено «реляционными» интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме (на низком физическом уровне).
Обобщая перечисленные особенности, можно сформулировать достоинства и недостатки ранних систем.
Достоинства:
– развитые средства управления данными во внешней памяти на низком уровне;

– возможность построения вручную эффективных прикладных программ;

– возможность экономии памяти.

Недостатки:

– сложность практического использования;

– необходимость знания физической организации данных;

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

– логика перегружена деталями организации доступа к БД.

По сравнению с ранними моделями, реляционный подход обладает следующими особенностями [2, 5, 8, 17].

Достоинства:

– наличие относительно небольшого набора абстракций;

– наличие простого, но мощного математического аппарата (в основе реляционного подхода – теория множеств);

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

Недостатки:

– ограниченность использования в нетрадиционных предметных областях;

– относительно неполная адекватность отражения семантики предметной области.

В главе 4 рассматривается самая сильная сторона реляционного подхода - математический аппарат для выполнения операций над отношениями реляционной модели.

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

Достоинства и недостатки СУБД

СУБД призваны решить недостатки файловых систем (см. прил.1), но при этом имеют и ряд специфических недостатков [7].
Достоинства СУБД
– Контроль за избыточностью данных.
– Непротиворечивость данных.
– Больше полезной информации при том же объеме хранимых данных.
– Совместное использование данных.
– Поддержка целостности данных.
– Повышенная безопасность.
– Применение стандартов.
– Повышение эффективности с ростом масштабов системы.
– Возможность нахождения компромисса при противоречивых требованиях.
– Повышение доступности данных.
– Улучшение показателей производительности.
– Упрощение сопровождения системы за счет независимости данных.
– Улучшенное управление параллельностью.
– Развитые службы резервного копирования и восстановления.
Контроль за избыточностью данных
Традиционные файловые системы неэкономно расходуют внешнюю память, сохраняя одни и те же данные с нескольких файлах. При использовании базы данных предпринимается попытка исключить избыточность данных за счет интеграции информации файлов, Однако реально полностью избыточность информации в базах данных не исключается, а лишь контролируется ее степень. В одних случаях ключевые элементы данных необходимо дублировать для моделирования связей, а в других случаях некоторые данные потребуется дублировать из соображений повышения производительности системы.
Непротиворечивость данных
Устранение избыточности данных или контроль над ней позволяют сократить риск возникновения противоречивых состояний. Если элемент данных хранится в базе только в одном месте, то для изменения его значения потребуется выполнить только одну операцию обновления, причем новое значение станет доступным сразу всем пользователям.
Если этот элемент данных с ведома системы хранится в базе данных в нескольких местах, то такая система сможет следить за тем, чтобы копии не противоречили друг другу.

Больше полезной информации при том же объеме хранимых данных

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

Совместное использование данных

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

Поддержка целостности данных

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

Повышенная безопасность

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


Применение стандартов

Интеграция позволяет АБД определять и применять необходимые стандарты. Например, стандарты отдела и организации, государственные и международные стандарты могут регламентировать формат данных при обмене между системами, соглашения об именах, форму представления документации, процедуры обновления и правила доступа.

Повышение эффективности с ростом масштабов системы

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

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

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

Повышение доступности данных

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

Улучшение показателей производительности

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


Упрощение сопровождения системы за счет независимости данных

В СУБД описания данных отделены от приложений, а потому приложения защищены от изменений в описаниях данных. Эта особенность называется независимостью данных. Наличие независимости данных от программ, использующих их, значительно упрощает обслуживание и сопровождение приложений, работающих с базой данных.

Улучшенное управление параллельностью

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

Развитые службы резервного копирования и восстановления

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

Недостатки СУБД

– Сложность.

– Размер.

– Стоимость.

– Дополнительные затраты на аппаратное обеспечение.

– Затраты на преобразование.

– Производительность.

– Серьезные последствия при выходе системы из строя.

Сложность

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


Размер

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

Стоимость

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

Дополнительные затраты на аппаратное обеспечение

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

Затраты на преобразование

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

Производительность

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

Серьезные последствия при выходе системы из строя

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

Фрагментация

Необходимость фрагментации вызывают следующие причины [7].
– Условия использования. Чаще всего приложения работают с некоторыми представлениями, а не с полными базовыми отношениями. Следовательно, с точки зрения распределения данных, целесообразнее организовать работу приложений с определенными фрагментами отношений, выступающими как распределяемые элементы.
– Эффективность.
Данные хранятся в тех местах в которых они чаще всего используются. Кроме того, исключается хранение данных, которые не используются локальными приложениями.
– Параллельность.
Поскольку фрагменты являются распределяемыми элементами, транзакции могут быть разделены на несколько подзапросов, обращающихся к различным фрагментам. Такой подход дает возможность повысить уровень параллельности обработки в системе, т.е. позволяет транзакциям, которые допускают это, безопасно выполняться в параллельном режиме.
– Защищенность.
Данные, не используемые локальными приложениями, не хранятся на сайтах, а значит, неавторизированные пользователи не смогут получить к ним доступ.
Механизму фрагментации свойственны два основных недостатка.
– Производительность.
Производительность приложений, требующих доступа к данным из нескольких фрагментов, расположенных на различных сайтах, может оказаться недостаточной.
– Целостность данных. Поддержка целостности данных может существенно осложняться, поскольку функционально зависимые данные могут оказаться фрагментированными и размещаться на различных сайтах.
При проведении фрагментации следует обязательно придерживаться трех следующих правил [7].
1. Полнота. Если экземпляр отношения К разбивается на фрагменты, например R1,R2, ..., Rn,
то каждый элемент данных, присутствующий в отношении К, должен присутствовать, по крайней мере, в одном из созданных фрагментов.
Выполнение этого правила гарантирует, что какие-либо данные не будут утрачены в результате выполнения фрагментации.

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

3. Непересекаемость. Если элемент данных di присутствует во фрагменте Ri, то он не должен одновременно присутствовать в каком-либо ином фрагменте. Исключением из этого правила является операция вертикальной фрагментации, поскольку в этом случае в каждом фрагменте должны присутствовать атрибуты первичного ключа, необходимые для восстановления исходного отношения. Данное правило гарантирует минимальную избыточность данных во фрагментах.

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

Существуют два основных типа фрагментации (рис. 5.5, а,

б):

– горизонтальная,

– вертикальная.

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

Кроме того, различают смешанную (рис. 5.5, в,

г) и производную (вариант горизонтальной) фрагментации.



Рис. 5.5. Типы фрагментации: а) горизонтальная; б) вертикальная; в) горизонтально разделенные вертикальные фрагменты; г) вертикально разделенные горизонтальные фрагменты

Горизонтальный фрагмент - выделенный по горизонтали фрагмент отношения, состоящий из некоторого подмножества кортежей этого отношения.

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


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

Стратегия определения типа фрагментации предполагает поиск набора минимальных

(т.е. полных и релевантных) предикатов, которые можно будет использовать как основу для построения схемы фрагментации [7].

Набор предикатов является полным тогда и только тогда, когда вероятность обращения к любым двум кортежам одного и того же фрагмента со стороны любого приложения будет одинакова.

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

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

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

Вертикальные фрагменты определяются путем установки родственности

одного атрибута по отношению к другому. Один из способов решить эту задачу состоит в создании матрицы, содержащей количество обращений с выборкой каждой из пар атрибутов. Например, транзакция, которая осуществляет доступ к атрибутам А1, А2, и А4 отношения R, состоящего из набора атрибутов (А1, А2, А3, А4), может быть представлена следующей матрицей.



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


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

Подобный подход носит название расщепления (splitting) и впервые был предложен группой разработчиков в 1984 году [7]. Он позволяет выделить неперекрывающихся фрагментов, которые гарантированно будут отвечать определенному выше правилу непересекаемости. Фактически требование непересе- каемости касается только атрибутов, не входящих в первичный ключ отношения. Атрибуты первичного ключа должны присутствовать в каждом из выделенных вертикальных фрагментов, а потому могут быть исключены из анализа.

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

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

Смешанная фрагментация определяется с помощью операций выборки и проекции реляционной алгебры.

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


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

Производный фрагмент – горизонтальный фрагмент отношения, созданный на основе горизонтального фрагмента родительского отношения.

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

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

Последний вариант возможной стратегии при разработке распределенных БД состоит в отказе от фрагментации отношения [7].

Функции распределенных СУБД

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

Функции службы репликации

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

РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ И СУБД

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

Иерархическая модель

Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи [8].
Пример типа дерева (схемы иерархической БД) представлен на рис. 2.19.

Рис. 2.19. Пример схемы иерархической БД
На рис. 2.19 ОТДЕЛ является предком для НАЧАЛЬНИК и СОТРУДНИКИ, а НАЧАЛЬНИК и СОТРУДНИКИ - потомки ОТДЕЛ. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (рис. 2.20, показан один экземпляр дерева) [8].

Рис. 2.20. Реализация иерархической БД
Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. Для БД определен полный порядок обхода - сверху-вниз, слева-направо.
Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие [8].
– Найти указанное дерево БД (например, отдел 42).
– Перейти от одного дерева к другому.
– Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику).
– Перейти от одной записи к другой в порядке обхода иерархии.
– Вставить новую запись в указанную позицию.
– Удалить текущую запись.
Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя. Заметим, что аналогичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается.
В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии.
Примером представления приведенной выше БД может быть следующая иерархия (рис. 2.21) [8].



Рис. 2.21. Пример схемы иерархической БД

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

Иерархическая структура реализует отношение ОДИН-КО-МНОГИМ между исходным и порожденным типами записей. Это отображение полностью функционально, т.к. дерево не может содержать порожденный узел без исходного узла (за исключением «корня»). Следовательно, отображения ОДИН-К-ОДНОМУ и ОДИН-КО-МНОГИМ могут непосредственно представляться иерархическими структурами. Однако для представления отображения МНОГИЕ-КО-МНОГИМ необходимо дублирование деревьев, а значит, реализация сложных связей требует больших затрат памяти.

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

Индекс - «бинарное дерево»

Любой бинарный алгоритм поиска в упорядоченном файле БД можно представить с помощью соответствующего бинарного дерева [17]. Это бинарное дерево можно реализовать в виде самостоятельного файла (или индекса). При этом операции поиска будут освобождены от необходимости каждый раз вычислять адреса записей (они будут сформированы один раз при начальной загрузке файла БД и при последующих добавлениях в файл новых записей).
На рис. 3.8 представлено бинарное дерево, построенное для файла из 15 записей [17]. Запись бинарного дерева состоит из поля ключа записи и двух полей указателей. Один указатель для левого поддерева, другой – для правого поддерева. Листовые записи бинарного дерева содержат указатели на блоки файла основных записей (файла данных). Для уменьшения количества операций обмена с внешней памятью при выполнении поиска соседние записи в бинарном дереве объединяются в блоки. На слайде объединяемые в один блок записи бинарного дерева очерчены штриховой линией.
Записи бинарного дерева обычно меньше по объему памяти записей основного файла , так как содержат только одно поле данных (поле ключа) и два служебных поля для хранения индексов, то при одинаковых размерах блоков количество записей в блоке бинарного дерева больше, чем в блоке основного файла. Это позволяет еще больше сократить количество обращений к внешней памяти.

Рис. 3.8. Пример бинарного дерева
Реализация бинарного дерева позволяет сократить время поиска данных по сравнению с бинарным поиском, однако возрастает требуемый объем внешней памяти [17].

Инфологическое проектирование базы данных

Все этапы проектирования БД подразумевают создание моделей данных об интересующей предметной области. Моделирование данных упрощает понимание смысла элементов данных, способствует более плодотворному общению пользователей и разработчиков.
Исходя из важности адекватного отображения предметной области, к моделям данных предъявляют ряд требований, и выдвигают комплекс критериев для оценки их эффективности (оптимальности) (табл. 2.1).
Инфологическое (концептуальное) проектирование – процесс создания внешней (инфологической) модели данных о предметной области, не зависящее от любых физических аспектов ее представления.
На этом этапе используется информация, объединяющая требования пользователей. Инфологическое проектирование базы данных не зависит от таких подробностей ее реализации, как тип выбранной СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип вычислительной системы и т.п. При разработке инфологическая модель постоянно подвергается критической оценке, проверке на соответствие требованиям пользователей, и при необходимости модифицируется. От качества созданной инфологической модели в определяющей степени зависит эффективность конечной базы данных.
Таблица 2.1

Критерий		Пояснение
Структурная достоверность		Соответствие способу определения и организации информации в данной предметной области
Простота		Легкость понимания модели разработчиками и пользователями информационной системы
Выразительность		Способность представлять отличия между разными типами данных, связи между данными и ограничения
Отсутствие избыточности		Исключение излишней информации, т.е. любая часть данных должна быть представлена только в одном месте
Готовность к совместному использованию		Отсутствие принадлежности к какому-то особому приложению или технологии
Расширяемость		Способность эволюционировать с целью включения новых требований с минимальным влиянием на существующих пользователей
Целостность		Согласованность по способам использования и управления информацией
Представление в виде диаграмм		Способность представления модели с помощью понятных широкому кругу пользователей обозначений

Инвертированный файл

В рассмотренных выше способах индексирования данных расчет делался на поиск по значению ключевого поля. Но часто требуется осуществить выборку данных по значениям неключевых полей. В этом случае неключевые поля также должны быть проиндексированы (т.е. для каждого из них строится особый индекс). Индексы, построенные для неключевых полей используются при организации многоаспектного поиска. Широко распространены на практике методы многоаспектного поиска по инвертированным файлам. Пусть имеется основной файл , упорядоченный либо неупорядоченный по значениям вторичного ключа . Строится дополнительный файл  по правилу [17]:
1) записи файла  имеют формат где  - поле, принимающее значение вторичного ключа  записи основного файла;  – указатели на записи основного файла , имеющие данное значение вторичного ключа ,
2) записи файла , упорядочены по полю .
Построенный дополнительный файл . называется инвертированным. В этом случае об основном файле говорят, что он инвертирован по полю . Количество записей в инвертированном файле  определяется количеством значений вторичного ключа  в записях основного файла . Пример инвертированного файла по полю  для основного файла  приведен на рис. 3.12.
Рассмотренный способ организации инвертированного файла предполагает использование записей переменной длины. Инвертированный файл можно организовать и с помощью записей фиксированной длины, если в каждой записи инвертированного файла выделять фиксированное число полей для указателей . Если фиксированного числа поле для некоторых записей окажется недостаточно, то организуется еще дополнительный служебный файл для хранения неуместившихся цепочек указателей.
, то для поиска записей можно использовать любой из рассмотренных выше методов поиска в упорядоченном файле (например, бинарный поиск или В-дерево). Чтобы выполнить многоаспектный поиск по  ключам, необходимо построить  инвертированных файлов [17].

Этапы проектирования баз данных

На рис. 2.2 приведены основные этапы проектирования баз данных. Так, весь сложный процесс создания БД может быть разбит на инфологическое и даталогическое проектирование. Последнее подразделяется на логическое и физическое проектирование. В зависимости от этапов проектирования различают: концептуальную инфологическую модель и концептуальную даталогическую модель, внешнюю инфологическую модель и внешнюю даталогическую модель [17].

Рис. 2.2. Этапы проектирования базы данных
Задача инфологического моделирования базы данных - получение семантических (смысловых) моделей, отражающих информационное содержание конкретной ПО. На этом этапе выполняется восприятие реальной действительности, абстрагирование, изучение и описание предметной области. Вначале выделяется из воспринимаемой реальности ПО, определяются ее границы, происходит абстрагирование от несущественных частей для данного конкретного применения базы данных. В результате этих действий определяются объекты, их свойства и связи, которые будут существенны для будущих пользователей системы.
После этого изучается предметная область, накапливаются знания о ней. Эти знания представляются в какой-либо языковой системе, обычно это неформализованное описание с использованием естественного языка, математических формул, диаграмм, связей и т.д. Выполняется структуризация знаний о предметной области: выделяются и классифицируются множества составляющих ПО, стандартизуется терминология.
Затем компонуется концептуальная инфологическая модель, основное значение при этом имеют потребности пользователей. Описывается информация, требуемая каждому конкретному пользователю, т.е. описываются запросы к БД. Каждый запрос соотносится с определенным фрагментом предметной области. Формируются описания внешних инфологических моделей, их взаимная увязка с концептуальной инфологической моделью. Полученные описания инфологических моделей отражают составляющие (сущности) предметной области, связи между ними, но эти описания не должны зависеть от методов представления данных в конкретной СУБД.
Концептуальная инфологическая модель призвана обеспечить прочную и долговременную работу всей системы, выдерживать замену одной используемой СУБД на другую.

Задача логического этапа проектирования – организация данных, выделенных на предыдущем этапе проектирования в форму, принятую в выбранной конкретной СУБД. Иными словами, требуется разработать схему концептуальной модели и схемы внешних моделей данных о предметной области, пользуясь только теми типами моделей данных и их особенностями, которые поддерживаются этой СУБД. На этом этапе проектирования обычно не прорабатываются вопросы, связанные с организацией хранения и доступа к данным на внутреннем уровне. Но целесообразно уже здесь получить вполне определенные рекомендации по выбору методов доступа.

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

Классификация сущностей, расширение ER-модели

Один из активных разработчиков реляционной модели К. Дейт [2] выделил три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.
Стержневая сущность (стержень) – это независимая сущность.
В рассмотренных ранее примерах стержни - это-
СТУДЕНТ, КВАРТИРА, МУЖЧИНА, ПРЕПОДАВА-ГТЕЛЬ, и другие, названия которых помещены в прямоугольники.
Ассоциативная сущность (ассоциация) - это связь? вида МНОГИЕ-КО-МНОГИМ (-КО-МНОГИМ и т.д.) между двумя или более сущностями или экземпляра- Ч ми сущности. Ассоциации рассматриваются как полноправные сущности:
– могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;
– могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь.
Характеристическая сущность (характеристика) - это связь вида МНОГИЕ-К-ОДНОМУ или ОДИН-КОД НОМУ между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько жен (пример 2.1), книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, ...) и т.д.
Существование характеристики полностью зависит, от характеризуемой сущности: женщины лишают статуса жен, если умирает их муж.
Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:
(ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)
{СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.
Часто используют расширенный язык ER-диаграмм {5, 7] (Enhanced ER-диаграммы), в котором для изображения характеристики используют трапецию (рис. 2.10).

Рис. 2.10. Элементы расширенного языка ER-диаграмм
Обозначающая сущность или обозначение - это связь вида МНОГИЕ-К-ОДНОМУ или ОДИН-К-ОДНОМУ между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

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

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

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, )[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ]

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

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

Метод непосредственных оценок

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

Метод последовательных предпочтений

Алгоритм последовательных предпочтений предназначен для повышения достоверности информации, полученной от экспертов методом непосредственных оценок. Он позволяет каждому эксперту провести самоконтроль суждений на основе сопоставления трех подходов: ранжирования критериев, числовой оценки их ценности и сравнения п–2 пар специально подобранных абстрактных объектов.
Последняя процедура, отражающая сущность метода последовательных предпочтений, основана на следующей гипотезе. Если ценность i-го критерия объекта некоторого класса для j-го эксперта есть Сij, то ценность объекта по всем критериям определяется  .В процессе коррекции оценок эксперт должен ответить на ряд вопросов: для i=1, 2, .... (п–2) какой из двух объектов лучше – обладающий только i-м критерием или совокупностью из (i±1, i±2, ..., п) критериев? В зависимости от ответа на i-й вопрос составляется одно из трех соотношений:
, где R Î [>,<,=].
В результате будут получены (n– 2) условия:

Далее производится последовательная проверка каждого из этих условий, начиная с последнего, на соответствие ранее выбранным оценкам Сij и их ранжировке. При выявлении противоречий в i-м условии эксперт должен либо изменить знак отношения R, либо откорректировать значение величины Сij. В последнем случае он обязан убедиться в том, что не оказалась нарушенной первоначальная ранжировка критериев. При нарушении ее необходимо либо изменить порядок критериев, либо откорректировать значение Сij. После исправления последней оценки Сij ее значение может отличаться от единицы. Следует отметить, что в этом случае психологические ограничения не дают использовать метод последовательных предпочтений, когда число рассматриваемых критериев превышает семь [3]. Рассмотрим пример.
Пример 2.3. Пусть некоторый эксперт выставил следующий ряд коэффициентов Сi, отражающих его мнение об относительной ценности шести частных критериев некоторого объекта (табл. 2.4) [3].
Таблица 2.4

i		1		2		3		4		5		6
Сij		1,0		0,9		0,7		0,6		0,3		0,1

<
Для уточнения оценок коэффициентов Сi, эксперту предлагается сравнивать четыре пары абстрактных объектов. Каждому объекту соответствует вектор х=(x1, x2, ..., хi, ..., x6), где xi=(0; 1): 1 –учитывается полезность i-го критерия, 0 – не учитывается; тогда:

1) (100000) хуже (011111);

2) (010000) лучше (001111);

3) (001000) хуже (000111);

4) (000100) лучше (000011).

Эксперт вынес систему решений. Соотношение x(1) лучше x(2) соответствует большей предпочтительности для эксперта объекта х(1) по сравнению с объектом х(2).

Непротиворечивость принятых решений должна подтверждаться выполнением системы неравенств:



Проверка неравенств начинается с последнего (четвертого). Третье и четвертое неравенства выполняются, второе – нет; значит, необходимо скорректировать значения коэффициента С2. Примем значение С2=2. Однако одновременно необходимо изменить значение С1 таким образом, чтобы, во-первых, сохранился первоначальный порядок критериев, определенный экспертом, т. е. С1>С2, и, во-вторых, выполнялось первое неравенство. Принимаем, например, значение C1=2,5. В результате применения метода последовательных предпочтений получили непротиворечивый ряд оценок (табл. 2.5), которые в дальнейшем необходимо масштабировать.

Таблица 2.5

i	1	2	3	4	5	6
Ci	2,5	2,0	0,7	0,6	0,3	1,0

Метод ранжировки

В соответствии с данным методом производится нумерация всех критериев полученного ряда, причем все неразличимые критерии, которые оказались на одном месте, нумеруются в произвольном порядке [3]. В результате данной процедуры каждый критерий получает свой номер. Ранг критерия определяется его номером, если на его месте в ряду отсутствуют какие-либо другие. Если на одном месте находится несколько неразличимых критериев, то ранг каждого из них равен среднему арифметическому их новых номеров.
Пример 2.2 ([3]). Пусть имеется следующий ряд упорядоченных критериев q1, q2, ..., q8   для j-го эксперта:

Ранги критериев, вычисленные в соответствии с вышеуказанной процедурой, сведены в табл. 2.2.
Таблица 2.2

i		1		2		3		4		5		6		7		8
rij		8,0		4,5		1,0		4,5		2,5		2,5		7,0		6,0

Переход от рангов к коэффициентам Сij. производится на основе гипотезы о линейной зависимости между рангом и относительной ценностью критерия. Чем ниже ранг, тем более важным является соответствующий критерий. Определение коэффициентов Сij для произвольного rij(1 < rij £ п) производится в соответствии со следующей формулой:

Для рассмотренного примера коэффициенты Сij сведены в табл. 2.3.
Таблица 2.3

i		q1		q2		qз		q4		q5		q6		q7		q8
Cij		0,125		0,433		1,000		0,433		0,812		0,812		0,250		0,375

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

Методы поиска и индексирования данных

При рассмотрении последующего учебного материала используются модели, приведенные в разд. 3.1, 3.2.

Многозначные зависимости

Выше было показано, что присутствие функциональных зависимостей в реляционной схеме означает возможность декомпозиции схемы, уменьшающей избыточность и при этом сохраняющей информацию. Однако существование F-зависимостей не является необходимым условием такой декомпозиции. Рассмотрим состояние отношения Назначение табл. 2.8.
Кортеж  в отношении Назначение означает, что рейс № f может выполняться в день недели d
на самолёте типа p. В отношении не выполняются ни F-зависимость РЕЙСДЕНЬ-НЕДЕЛИ, ни РЕЙСТИП-САМОЛЁТА и РЕЙС-ТИП-САМОЛЁТА (табл. 2.9).
Рассмотрим другое состояние отношения Назначение, задаваемое табл. 2.10. Если разложить это состояние на схемы (РЕЙС, ДЕНЬ-НЕДЕЛИ) и (РЕЙС, ТИП-САМОЛЁТА), то снова получится вариант из табл. 2.9. Однако соединение отношений табл. 2.9 не восстанавливает исходного отношения.
Таблица 2.8

Назначение		РЕЙС		ДЕНЬ-НЕДЕЛИ		ТИП-САМОЛЁТА
		106		Понедельник		747
		106		Четверг		747
		106		Понедельник		1011
		106		Четверг		1011
		204		Среда		707
		204		Среда		727

Таблица 2.9

День назначения		РЕЙС		ДЕНЬ-НЕДЕЛИ
		106		Понедельник
		106		Четверг
		204		Среда

Тип самолёта назначения		РЕЙС		ТИП-САМОЛЁТА
		106		747
		106		1011
		204		707
		204		727

Таблица 2.10

Назначение		РЕЙС		ДЕНЬ-НЕДЕЛИ		ТИП-САМОЛЁТА
		106		Понедельник		747
		106		Четверг		747
		106		Четверг		1011
		204		Среда		707
		204		Среда		727

Каковы же свойства первого состояния отношения Назначение, отсутствующие у второго, которые обеспечивают декомпозицию без потери информации? В первом случае, если самолет некоторого типа использован для выполнения маршрута в один день, он может быть использован для выполнения этого маршрута в любой другой день. Это свойство отсутствует во втором состоянии отношения Назначение, поскольку рейс №106 может использовать тип 1011 в четверг, но не в понедельник.
Отношение в первом состоянии следует подвергнуть декомпозиции, ибо при заданном рейсе ДЕНЬ-НЕДЕЛИ не содержит информации об атрибуте ТИП-САМОЛЕТА, и наоборот.

Сформулируем это свойство по-другому. Если в отношении Назначение существуют кортежи  и , то должен быть кортеж . Формальное определение следующее [10].

Пусть R – реляционная схема, X и Y - непересекающиеся подмножества R, и пусть Z=R–(XY). Отношение r(R) удовлетворяет многозначной зависимости (MV-зависимости) XУ, если для любых двух кортежей tl и t2 из r, для которых t1(X)=t2(X), в r существует кортеж t3, для которого выполняются соотношения t3(X)=t1(X), t3(Y)=t1(Y), t3(Z)=t2(Z).

Из симметрии определения относительно t1 и t2 следует, что в r

существует также t4 для которого

t4(X)=t1(X), t4(Y)=t1(Y), t4(Z)=t2(Z).

Пример 2.17. MV-зависимость РЕЙСДЕНЬ-НЕДЕЛИ выполняется для отношения Назначение в состоянии табл. 2.8, но не табл. 2.10. Состояние табл. 2.8 удовлетворяет также MV-зависимости РЕЙСТИП-САМОЛЕТА. Тот факт, что состояние отношения Назначение (табл.2.8) удовлетворяет двум MV-зависимостям, не является случайным [10].

Модель «сущность-связь»

Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить на доступном широкому кругу пользователей и разработчиков языке. Известны следующие средства создания внешних моделей:
– семантические сети;
– язык инфологического моделирования;
– ЕR-диаграммы.
Наибольшую популярность из-за доступности, наглядности и компактности приобрел подход моделирования «сущность-связь».
Модель «сущность-связь» (Entity-Relationship model) разработана Ченом в 1976 году с целью упрощения концептуального проектирования баз данных.
Основными элементами этой модели являются:
– сущности;
– атрибуты;
– связи.
Сущность представляет собой различимое множество объектов (экземпляров сущности) реального мира с одинаковым набором атрибутов.
Сущность идентифицируется именем и списком свойств (атрибутов). База данных о сколько-нибудь значительной предметной области содержит много (несколько) сущностей. Каждый экземпляр сущности обладает уникальным набором значений атрибутов.
На ER-диаграммах сущность представляется прямоугольником с именем сущности внутри.
Атрибут – неотъемлемое свойство сущности или связи. Именно по значениям атрибутов можно идентифицировать экземпляр сущности. Значения атрибутов представляют основную часть сведений, хранящихся в БД.
На ER-диаграммах атрибут представляется овалом (эллипсом), соединенным с соответствующей сущностью линией и с именем атрибута внутри.
С понятием атрибута тесно связано понятие домена.
Домен – множество значений, которые может принимать атрибут. Разработчика не должен удивлять тот факт, что домены могут быть бесконечными (хотя и перечислимыми) множествами

Атрибуты делятся на:

– простые;

– составные;

– однозначные;

– многозначные;

– производные.

Простой атрибут состоит из одного компонента с независимым существованием.

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

Однозначный атрибут содержит одно значение для одного экземпляра сущности.

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

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

Вопрос однозначной идентификации экземпляров сущности связан с понятием ключа.

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

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

На ER-диаграммах имена атрибутов, выбранных в качестве первичного ключа, подчеркиваются.

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

Ассоциирование двух или более сущностей называется связью.

Связи, также как и сущности и атрибуты идентифицируют именем.

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

Пример ER-диаграммы с обозначениями сущностей, их атрибутов и связей представлен на рис. 2.3.



Рис. 2.3. Пример ER-диаграммы

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

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


В общем случае связь между п сущностями называется n - арной. Примеры различных связей представлены на рис. 2.4.



Рис. 2.4.Примеры связей: а) – бинарной; б) – тернарной; в) – кватернарной; г) – унарной (рекурсивной)

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

Рекурсивная связь часто называют унарной. Пример такой связи представлен на рис. 2.4,2. В приведенном примере каждый студент из сущности СТУДЕНТ может исполнять обязанности дежурного по отношению к другим студентам той же сущности.

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

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

Показатель кардинальности указывает количественное соотношение экземпляров сущностей для каждой связи [5, 7].

Классическими признаны бинарные связи с показателями кардинальности «ОДИН-К-ОДНОМУ», «ОДИН-КО-МНОГИМ», «МНОГИЕ-КО-МНОГИМ».

Пусть в предметной области выделены сущности А и В.

1. Связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому экземпляру сущности А соответствует не более одного экземпляра сущности В (рис. 2.5).



Рис. 2.5. Связь ОДИН-К-ОДНОМУ

Декан осуществляет свою деятельность на одном факультете вуза.

2. Связь ОДИН-КО-МНОГИМ (1:М): каждому экземпляру сущности А соответствуют О, 1 или несколько представителей сущности В (рис. 2.6).



Рис. 2.6. Связь ОДИН-КО-МНОГИМ

В квартире может проживать несколько жильцов.

3. Связь МНОГИЕ-КО-МНОГИМ (М:М): каждому экземпляру сущности А соответствуют 0, 1 или несколько представителей сущности В, каждому экземпляру сущности В соответствуют 0, 1 или несколько представителей сущности А (рис. 2.7).



Рис. 2.7. Связь МНОГИЕ-КО-МНОГИМ

Процесс обучения осуществляется множеством преподавателей с множеством студентов.

Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможных представления такой связи (рис. 2.8) [5].


Характер связей между сущностями может оказаться более сложным (рис. 2.9) [5, 7].



Рис. 2.8. Пример связи БРАК между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ



Рис. 2.9. Пример множества связей между сущностями ПРЕПОДАВАТЕЛЬ и СТУДЕНТ

В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграмах. Так, ввод лишь нескольких основных атрибутов в описание значительно усложняет ER-диаграмму. В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Для представления полных инфологических моделей предметной области применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ) [5], в котором сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2, ..., атрибут n)

Связь [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]

(атрибут 1, атрибут 2, ..., атрибут n),

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

Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом.

ПРЕПОДАВАТЕЛЬ (УслНомерП,

Фамилия, Имя, Отчество, УчСтепень)

СТУДЕНТ (УслНомерС.

Фамилия, Имя, Отчество,

Адрес, Специальность, Пол)

Лектор [ПРЕПОДАВАТЕЛЬ 1, СТУДЕНТ М]

(УслНомерП, УслНомерС)

Консультант [ПРЕПОДАВАТЕЛЬ М, СТУДЕНТ Р]

(УслНомерП, УслНомерС).

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

Модель внешней памяти

Данные хранятся во внешней памяти на магнитных дисках, магнитных лентах и т.д., а их обработка выполняется в оперативной памяти ЭВМ. Поэтому при обработке некоторые порции данных пересылаются из внешней памяти в оперативную либо наоборот [17].
При больших объемах данных в БД может потребоваться несколько томов внешней памяти. Однако обмен между внешней и оперативной памятью выполняется небольшими порциями данных – обычно объемом не более нескольких сотен байт. С этой целью внешняя память разбивается на части, называемые блоками или страницами. Данные пересылаются блоками. Операции пересылки еще называют обменом данными между внешней и оперативной памятью. Такой обмен называется чтением блока, а в обратном направлении - записью блока.
При чтении блока, последний помещается в оперативной памяти в специально отведенный (буферный) участок памяти. Может отводиться участок под несколько буферов (буферный пул). Чем больше буферный пул, тем эффективнее обработка данных. При считывании другого блока из внешней памяти в тот же самый буфер предыдущее содержимое буфера теряется. При внесении изменений в блок вначале блок считывается в буфер, затем выполняются изменения и далее блок записывается во внешнюю память.
Для организации каждого файла в зависимости от его размера во внешней памяти ему выделяется от одного до  блоков, где размещаются записи файла. Предположим, что в одном блоке размещаются записи только одного файла. В зависимости от соотношения объемов записей и блоков может оказаться, что в одном блоке размещается либо одна, либо несколько записей файла, либо одна запись размещается в нескольких блоках. Обычно запись занимает несколько десятков байт.
Каждый байт в блоке пронумерован: . Номер байта блока, с которого начинается запись, определяет относительный адрес записи файла в блоке.
В качестве адресов записей файла во внешней памяти используют: машинный адрес, относительный адрес, ключ записи [17].
В качестве относительного адреса записи файла используют ее номер по порядку (внутрисистемный номер) в файле либо комбинацию таких составляющих адреса, как номер блока и относительный адрес в блоке, ибо номер блока и значение ключа.
В последнем случае, после считывания блока в буфер оперативной памяти, доступ к записи в буфере осуществляется с помощью какого-либо метода поиска записей в файле по значению ключа.

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

Запись обычно состоит из:

1) служебных полей, в которых хранятся указатели, реализующие связи с другими записями, и другая информация, необходимая для организации управления файлом,

2) полей хранимых данных.

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

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

,

где  - обозначает целую часть числа;  и - соответственно объем блока и записи в байтах.

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

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

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


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

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



где  < 1 – незаполненная часть блока; - количество записей в файле.

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

,

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

,

где - среднее время выполнения операции обмена; - время считывания, приведенное к одному байту (т.е. время считывания одного байта); - время подготовки устройства к выполнению операции обмена.

Время поиска данных в файле:

,

где - время выполнения операции поиска; - среднее время выполнения в процессоре одной операции сравнения; - количество операций обмена; - количество операций сравнения.

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

На скорость поиска данных в файле наибольшее влияние оказывают следующие характеристики файла и технических устройств внешней памяти, использованных для его организации [17]:


– объем блока;

– объем байта;

– количество записей в блоке файла ;

– количество записей в блоке индекса;

– количество блоков в файле данных ;

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

– длина  поля, отведенного для указателя;

– количество записей в файле ;

– размер записи ;

– длина ключевого поля записи;

– число записей файла, удовлетворяющих условию поиска Q;

– среднее число блоков переполнения на один блок файла;

– среднее время обмена .

На рис. 3.7 изображен файл со следующими характеристиками: =10; =4;  =0,5. Записи файла описываются схемой: , т.е. =4. При начальной загрузке при таких характеристиках для организации файла требуется 5 блоков.

Моментальные снимки таблиц

Метод моментальных снимков таблиц позволяет асинхронно распространять результаты изменений, выполненных в отдельных таблицах, группах таблиц, представлениях или фрагментах таблиц в соответствии с заранее установленным графиком [7].
Общий подход к созданию моментальных снимков состоит в использовании файла журнала восстановления базы данных, который позволяет минимизировать уровень дополнительной нагрузки на систему. Основная идея состоит в том, что файл журнала является лучшим источником для получения сведений об изменениях в исходных данных. Достаточно иметь механизм, который будет обращаться к файлу журнала для выявления изменений в исходных данных, после чего распространять обнаруженные изменения на целевые базы данных, не оказывая никакого влияния на нормальное функционирование исходной системы. Различные СУБД реализуют подобный механизм по-разному:
в некоторых случаях данный процесс является частью самого сервера СУБД, тогда как в других случаях он Реализуется как независимый внешний сервер.
Для отправки сведений об изменениях на другие байты целесообразно применять метод организации очередей. Если произойдет отказ сетевого соединен! или целевого сайта, сведения об изменениях могут с храниться в очередях до тех пор, пока соединение I будет восстановлено. Для гарантии сохранения согласованности данных порядок доставки сведений на  целевые сайты должен сохранять исходную очередное внесения изменений.

Недостатки нормализации посредством декомпозиции

При нормализации схемы отношения посредством декомпозиции возникает ряд проблем.
Во-первых, временная сложность процесса не ограничивается полиномиальной [10]. В терминах размера схемы отношения и заданного множества F-зависимостей схема отношения может обладать экспоненциальным числом ключей. Кроме того, проверка атрибута схемы на непервичность является NP-полной задачей.
Во-вторых, число порожденных процессом схем отношения может оказаться большим, чем в действительности необходимо для 3НФ.
Пример 2.13. Пусть заданы схема   и . Ключами  относительно  являются  и . Используя транзитивную зависимость  от  через , разлагаем R следующим образом:
               K
                     K
Далее в  используем транзитивную зависимость Е от АВ через В для получения
                 K
                    K
Окончательная схема базы данных в 3НФ имеет вид
R
Существует декомпозиция R в ЗНФ с двумя схемами отношений, а именно:
                  K
                 K
Третья проблема состоит в том, что при декомпозиции схемы отношения могут возникнуть частичные зависимости. Эти зависимости могут породить в окончательной схеме базы данных больше схем, чем это в действительности необходимо.
Пример 2.14. Для схемы отношения  и . атрибут А является единственным ключом в R относительно . Атрибут  транзитивно зависит от  через . Разлагая, получаем
                  K
                 K
Фактическим ключом  является, но  от него частично зависит. Следовательно,  транзитивно зависит от . Схему  следует разложить в
                    K
                             K
Схемы ,  и  образуют схему базы данных в 3НФ для . Однако схемы отношений  и  также образуют схему базы данных в 3НФ для .
Этих недостатков можно избежать, если при декомпозиции следить за тем, чтобы промежуточное множество атрибутов в разлагаемой транзитивной зависимости было минимальным. В примере 2.14 атрибут  транзитивно зависел через от , но  не минимально. Атрибут  транзитивно зависит от  только через .

Четвертая проблема состоит в том, что для построенной схемы базы данных заданное множество F-зависимостей может оказаться ненавязанным [10].

Пример 2.15. Пусть заданы схема  и . Исключив транзитивную зависимость  от  через , получаем

              K

                 K.

Множество  ненавязано схеме базы данных R из-за того, что зависимость  невыводима из F-зависимостей в , приложимых к  или  (это утверждение должно быть подтверждено вычислением ).

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

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

                  K

                     K.

Несмотря на то, что ,  формально находятся в 3НФ, в  существует «скрытая» транзитивная зависимость  от .

Чтобы избежать проблем, возникающих при декомпозиции схем отношений, необходимо использовать другие методы получения третьей нормальной формы, например, метод синтеза 3НФ [10].

Неплотный индекс

Пусть основной файл  упорядочен по полю ключа . Построим дополнительный файл  (рис. 3.9) по правилу [17]:
 имеют формат , где  -поле, принимающее значение ключа первой записи блока основного файла ;  – указатель на этот блок;
2) записи файла  упорядочены по полю . Полученный файл  называется неплотным индексом. Количество записей файла  равно количеству блоков основного файла . Для организации файла  требуется дополнительная внешняя память.
, где  – количество записей в блоке индекса. Такое дерево должно иметь в каждом узле не менее зависимых узлов и все листья должны располагаться на одном уровне.
Для осуществления последовательного поиска блоки первого уровня могут быть связаны в цепь по возрастанию значения ключа. Поиск в В-дереве выполняется так же, как и в неплотном индексе. Удачный и неудачный поиск записи в В-дереве требует  обменов, где  – число уровней В-дерева.
При поиске по интервалу значений  вначале выполняется поиск по  в В-дереве, а затем – последовательный поиск по условию в блоках 1-го уровня В-дерева.

Нормализация через декомпозицию

Всегда можно начать с того, что, взяв некоторую схему отношения , не находящуюся в 3НФ относительно множества F-зависимостей , разложить ее в схему базы данных, имеющую 3НФ относительно .
Разложение схемы отношений означает разбиение схемы отношения на пару схем отношений  и  (возможно, пересекающихся) так, чтобы любое отношение , удовлетворяющее , разлагалось без потерь на  и . Возможно, нужно будет повторить процесс декомпозиции отношений  и , если какое-нибудь из них не окажется в 3НФ. Декомпозиция продолжается до тех пор, пока все полученные отношения не окажутся в третьей нормальной форме относительно .
На самом деле процесс декомпозиции схемы не бесконечен. Каждый раз, когда разлагается схема отношения, обе получившиеся в результате схемы становятся меньше, а в схеме отношения, содержащей только два атрибута, не может быть никакой транзитивной зависимости [10].
Пример 2.12. Пусть
 (РЕЙС, ПУНКТ-ОТПРАВЛЕНИЯ, ПУНКТ-НАЗНАЧЕНИЯ, ВРЕМЯ-ВЫЛЕТА, ВРЕМЯ-ПРИБЫТИЯ, ДЛИТЕЛЬНОСТЬ-ПОЛЕТА, ТИП-САМОЛЕТА, I-КЛАСС, II-КЛАСС, КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ, ПИТАНИЕ)
где I-КЛАСС и II -КЛАСС – количество посадочных мест в каждом салоне. Пусть множество выделенных ключей
К={РЕЙС, ПУНКТ-ОТПРАВЛЕНИЯ ПУНКТ-НАЗНАЧЕНИЯ ВРЕМЯ-ВЫЛЕТА, ПУНКТ-ОТПРАВЛЕНИЯ ПУНКТ-НАЗНАЧЕНИЯ ВРЕМЯ-ПРИБЫТИЯ}.
Предполагается, что в одно и то же время не может быть двух рейсов с одинаковыми пунктами отправления и назначения. Пусть все выделенные ключи действительно являются ключами, и пусть имеются также следующие F-зависимости в множестве :
ТИП-САМОЛЕТАI-КЛАСС II-КЛАСС КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ,
ВРЕМЯ-ВЫЛЕТА ДЛИТЕЛЬНОСТЬ-ПОЛЕТАПИТАНИЕ,
ВРЕМЯ-ПРИБЫТИЯ ДЛИТЕЛЬНОСТЬ-ПОЛЕТАПИТАНИЕ,
I-КЛАСС II-КЛАССКОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ,
I-КЛАСС КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ-Ш-КЛАСС,
II-КЛАСС  КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТI-КЛАСС.
Казалось бы, ВРЕМЯ-ВЫЛЕТА ВРЕМЯ-ПРИБЫТИЯДЛИТЕЛЬНОСТЬ-ПОЛЕТА также должна быть F-зависимостью, но, из-за того что время прибытия и время отправления указывается местное, ДЛИТЕЛЬНОСТЬ-ПОЛЕТА зависит от часовых поясов, к которым принадлежат соответствующие аэропорты.

Сначала удалим транзитивную зависимость атрибута ПИТАНИЕ от РЕЙСА через ВРЕМЯ-ВЫЛЕТА ДЛИТЕЛЬНОСТЬ-ПОЛЕТА. Получим схему отношения

(РЕЙС, ПУНКТ-ОТПРАВЛЕНИЯ, ПУНКТ-НАЗНАЧЕНИЯ, ВРЕМЯ-ПРИБЫТИЯ, ДЛИТЕЛЬНОСТЬ-ПОЛЕТА, ТИП-САМОЛЕТА, I-КЛАСС, II-КЛАСС, КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ)

с выделенными ключами

={РЕЙС, ПУНКТ-ОТПРАВЛЕНИЯ ПУНКТ-НАЗНАЧЕНИЯ ВРЕМЯ-ВЫЛЕТА, ПУНКТ-ОТПРАВЛЕНИЯ ПУНКТ-НАЗНАЧЕНИЯ ВРЕМЯ-ПРИБЫТИЯ}

и схему отношения

(ВРЕМЯ-ОТПРАВЛЕНИЯ, ДЛИТЕЛЬНОСТЬ-ПОЛЕТА,

ПИТАНИЕ)

с выделенным ключом

={ВРЕМЯ-ОТПРАВЛЕНИЯ ДЛИТЕЛЬНОСТЬ-ПОЛЕТА}.

Схема  находится в 3НФ, а схема  – нет, так как I-КЛАСС, II-КЛАСС и КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ транзитивно зависят от РЕЙСА через ТИП-САМОЛЕТА. Схема  разлагается на схему

(РЕЙС, ПУНКТ-ОТПРАВЛЕНИЯ, ПУНКТ-НАЗНАЧЕНИЯ, ВРЕМЯ-ВЫЛЕТА, ВРЕМЯ-ПРИБЫТИЯ, ДЛИТЕЛЬНОСТЬ-ПОЛЕТА, ТИП-САМОЛЕТА)

с выделенными ключами

={РЕЙС, ПУНКТ-ОТПРАВЛЕНИЯ ПУНКТ-НАЗНАЧЕНИЯ ВРЕМЯ-ВЫЛЕТА, ПУНКТ-ОТПРАВЛЕНИЯ ПУНКТ-НАЗНАЧЕНИЯ ВРЕМЯ-ПРИБЫТИЯ}

и схему

(ТИП-САМОЛЕТА, I-КЛАСС, II-КЛАСС, КОЛИЧЕСТВО-ПОСАД ОЧНЫХ-МЕСТ)

с выделенным ключом

К12={ТИП-САМОЛЕТА}.

Схема отношения  находится теперь в 3НФ относительно , a – нет, поскольку КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ транзитивно зависит от ТИПА-САМОЛЕТА через 1-КЛАСС II-КЛАСС. Схема  разлагается на

(ТИПА-САМОЛЕТА, I-КЛАСС, II-КЛАСС)

с выделенным ключом

={ТИП-САМОЛЕТА}.

и схему отношения

(1-КЛАСС, II-КЛАСС, КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ)

с выделенным ключом

={I-КЛАСС II-КЛАСС}.

Декомпозиция реализована до такой стадии, когда каждая схема отношения находится в 3НФ относительно . Следовательно, схема базы данных

R

находится в 3НФ.

Схема базы данных R не однозначна. Есть точки, в которых можно выбирать пути декомпозиции определенного отношения с целью удаления транзитивно зависимого атрибута. Так, на первом шаге можно было выбрать

 (ВРЕМЯ-ПРИБЫТИЯ, ДЛИТЕЛЬНОСТЬ-ПОЛЕТА, ПИТАНИЕ),

так как ПИТАНИЕ также транзитивно зависит от РЕЙСА через ВРЕМЯ-ПРИБЫТИЯ ДЛИТЕЛЬНОСТЬ-ПОЛЕТА. На третьем шаге существует три варианта декомпозиции  (Какие?) Некоторые ключи для схем отношений не указаны как выделенные, например I-КЛАСС КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ и II-КЛАСС КОЛИЧЕСТВО-ПОСАДОЧНЫХ-МЕСТ для .

Нормальная форма Бойса–Кодда (НФБК)

Схема отношения  находится в нормальной форме Бойса-Кодда (НФБК) относительно множества F-зависимостей , если она находится в 1НФ и никакой атрибут в  не зависит транзитивно ни от одного ключа  [10].
Схема базы данных R находится в нормальной форте Бойса-Кодда (НФБК) относительно множества F-зависимостей , если каждая схема отношения  находится в НФБК относительно . НФБК включает в себя ЗНФ [10].  
Схема отношения  находится в нормальной форме Бойса-Кодда (НФБК) относительно множества F-зависимостей , если для каждого подмножества  из  и каждого атрибута  из  следует  при , т.е. если  нетривиально определяет произвольный атрибут из , то  есть сверхключ .
Для схемы отношения, не находящейся в НФБК, можно всегда провести декомпозицию в схему базы данных в НФБК [10].
С одной стороны, НФБК в некотором смысле является более сильной, чем 3НФ, а значит, более желательной. Но, с другой стороны, НФБК имеет свои проблемы [10]. Из предыдущего изложения следует, что при заданном множестве F-зависимостей над  можно найти схему базы данных в ЗНФ, полностью характеризующую . Для НФБК это неверно. Множество F-зависимостей может не иметь полной НФБК схемы базы данных, кроме того, проверка свойства НФБК для заданной схемы базы данных является NP-полной задачей.
Пример 2.16. Пусть заданы схема и . Атрибуты  являются ключом F, а В частично зависит от AD. При декомпозиции получаем




Несмотря на то чт R1, R2 формально находятся в ЗНФ, в Rl существует «скрытая» транзитивная зависимость С от AD.
Чтобы избежать проблем, возникающих при декомпозиции схем отношений, необходимо использовать другие методы получения третьей нормальной формы, например, метод синтеза ЗНФ [10].
2.4.3.8. Нормальная форма Бойса–Кодда (НФБК)
Схема отношения R находится в нормальной форме Бойса-Кодда
(НФБК) относительно множества F-зависимостей F, если она находится в 1НФ и никакой атрибут в Л не зависит транзитивно ни от одного ключа R [10].
Схема базы данных R находится в нормальной форме Бойса-Кодда

(НФБК) относительно множества F- зависимостей F, если каждая схема  отношения  находится в НФБК относительно F.

НФБК включает в себя 3НФ [10].

отношения R находится в нормальной форме Бойса-Кодда

(НФБК) относительно множества F-зависимостей F, если для каждого подмножества Y из R и каждого атрибута из следует  при F, т.е. если Y

нетривиально определяет произвольный атрибут из R, то Y

есть сверхключ R.

Для схемы отношения, не находящейся в НФБК, ложно всегда провести декомпозицию в схему базы данных в НФБК [10].

С одной стороны, НФБК в некотором смысле является более сильной, чем ЗНФ, а значит, более желательной. Но, с другой стороны, НФБК имеет свои проблемы [10]. Из предыдущего изложения следует, что при заданном множестве F-зависимостей над R можно найти схему базы данных в ЗНФ, полностью характеризующую F. Для НФБК это неверно. Множество F-зависимостей может не иметь полной НФБК схемы базы данных, кроме того, проверка свойства НФБК для заданной схемы базы данных является NP-полной задачей.

Обеспечение прозрачности

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

Обобщение этапов нормализации

Упрощенная обобщенная схема этапов нормализации отношений с привязкой к известным нормальным формам, выполняемая на этапе логического проектирования базы данных, представлена на рис. 2.28.

Рис. 2.28. Обобщённая схема процесса нормализации
Глава 3. ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ДАННЫХ В СУБД.. 2
3.1. Списковые структуры.. 2
3.1.1. Последовательное распределение памяти. 3
3.1.2. Связанное распределение памяти. 5
3.2. Модель внешней памяти. 9
3.3. Методы поиска и индексирования данных. 12
3.3.1 Последовательный поиск. 12
3.3.2. Бинарный поиск. 14
3.3.3. Индекс - «бинарное дерево». 14
3.3.4. Неплотный индекс. 16
3.3.5. Плотный индекс. 18
3.3.6. Инвертированный файл. 19
Глава 4. МАТЕМАТИЧЕСКИЕ ОСНОВЫ МАНИПУЛИРОВАНИЯ РЕЛЯЦИОННЫМИ ДАННЫМИ.. 21
4.1. Теоретические языки запросов. 21
4.1.1. Реляционная алгебра. 21
4.1.2. Реляционное исчисление кортежей. 27
4.1.3. Реляционное исчисление доменов. 32
4.1.4. Сравнение теоретических языков. 33
4.2. Определение реляционной полноты.. 34

Обобщенная архитектура СУБД

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

Рис. 1.1. Связь программ и данных при использовании СУБД
СУБД должна предоставлять доступ к данным посредством прикладных программ любым пользователям, включая и тех, которые практически не имеют представления о:
– физическом размещении в памяти данных и их описаний;
– механизмах поиска запрашиваемых данных;
– проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
– способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
– поддержании баз данных в актуальном состоянии и множестве других функций СУБД [5, 8, 17].
При выполнении основных из этих функций СУБД должна использовать различные описания данных. Очевидно, что в таких описаниях обязательно должны быть учтены:
– сущности
интересующей предметной области;
– атрибуты,
характеризующие неотъемлемые свойства каждой сущности;
– связи,
ассоциирующие выделенные сущности.
С самых общих позиций, в архитектуре современных СУБД выделяют три уровня абстракции, т.е. три уровня описания элементов хранимых данных. Эти уровни составляют трехуровневую архитектуру, представленную на рис. 1.2, которая охватывает внешний, концептуальный и внутренний уровни [7].

Рис. 1.2. Трехуровневая архитектура ANSI/SPARC
Представленный подход к описанию данных предложен комитетом ANSI/SPARC (Комитет Планирования Стандартов и Норм Национального Института Стандартизации США) и имеет целью отделение пользовательского представления о базе данных от ее физической организации.
Такое отделение обеспечивает независимость хранимых данных и желательно по следующим причинам.

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

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

– Администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе так, чтобы эти изменения оставались «прозрачными» для остальных пользователей.

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

Внешний уровень - представление базы данных с точки зрения конкретных пользователей.

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

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

На внешнем уровне создается инфологическая модель БД (внешняя схема), полностью независимая от платформы (т.е. вычислительной системы, на которой будет использоваться). Инфологическая модель является человеко-ориентированной: средой ее хранения может быть память человека, а не ЭВМ. Инфологическая модель не изменяется до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

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


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

– сущности, их атрибуты и связи;

– ограничения, накладываемые на данные;

– семантическую информацию о данных;

– информацию о мерах обеспечения безопасности.

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

На концептуальном уровне создается даталогическая модель

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

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

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

На внутреннем уровне осуществляется взаимодействие СУБД с методами доступа операционной системы с целью эффективного размещения данных на носителях, создания индексов и т.д. На этом уровне используется следующая информация:

– карта распределения дискового пространства для хранения данных и индексов;

– описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);


– сведения о размещении записей;

– сведения о возможном сжатии данных и выбранных методах их шифрования.

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

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

Соответствующие трехуровневой архитектуре ANSI/ SPARC три уровня моделей данных для описания предметной области и реализации базы данных представлены на рис.1.3 [5].

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

Основные программные компоненты СУБД представлены на рис. 1.4 [7].



Рис. 1.3. Уровни моделей данных



Рис. 1.4. Основные компоненты типичной СУБД

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

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


Затем контроллер базы данных вызывает контроллер файлов для выполнения поступившего запроса. Компоненты контроллера базы данных показаны на рис. 1.5 [7].

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

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

– Компилятор языка DDL. Компилятор языка DDL преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация - в заголовках файлов с данными.

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



Рис. 1.5. Компоненты контроллера БД

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

– Контроль прав доступа. Этот модуль проверяет наличие у данного пользователя полномочии для выполнения затребованной операции.

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

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


– Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса.

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

– Планировщик.

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

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

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

Для воплощения базы данных на физическом уровне помимо перечисленных выше модулей нужны некоторые другие структуры данных. К ним относятся файлы данных и индексов, а также системный каталог (см. гл. З).

Общая классификация пользователей БД

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

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

Оценка результатов экспертного анализа

При использовании всех рассмотренных выше методов возникает естественный вопрос: насколько можно доверять результатам оценки коэффициентов Сij, полученным из субъективных мнений экспертов? Достоверность результатов экспертного анализа чаще всего характеризуется степенью согласованности данных ими оценок. Для количественной оценки степени согласованности часто используется коэффициент конкордации [3]:

где

гij – место, которое заняло i-е свойство в ранжировке j-м экспертом.
Коэффициент W позволяет оценить, насколько согласованы между собой ряды предпочтительности, построенные каждым экспертом. Его значение находится в пределах 0£W£1, причем W=0 означает полную противоположность, а W=1 - полное совпадение ранжировок. Практически достоверность считается хорошей, если W=0,7¸0,8.
На основе рассмотренных методов могут быть определены значения коэффициентов Сij (j=1, 2, ..., m; i=1, 2, ..., п), по которым будут вычислены коэффициенты b., линейной формы интегрального критерия. При использовании такого подхода к формированию интегрального критерия в дальнейшем считается, что единица измерения каждого свойства системы, отраженного в соответствующем частном критерии, выбрана по принципу «чем больше, тем лучше». Отсюда следует, что качество решения по выбору альтернативы тем лучше, чем больше значение показателя эффективности.
Так как критерии qi могут иметь различную размерность, то при использовании их в качестве аргументов функции Е необходимо провести нормирование, т. е. привести их к общей размерности, и в частности к безразмерному виду.
Для придания равномерности влияния каждого из критериев на значение интегрального критерия необходимо выровнять диапазоны изменения значений критериев путем масштабирования и сведения их к диапазону [0; 1].
Проведение преобразований типов нормирования и масштабирования требует, чтобы для каждого из критериев были определены понятия «негодного» и «идеального» объектов, а это означает, что должны быть заданы допустимые области изменений значений критериев qi, qiн


где qiотн, qiн, qiв - относительное, нижнее и верхнее значения критерия qi соответственно.

В случае такого преобразования чувствительность шкалы изменения qi во всем диапазоне изменений qi постоянна. Если же разработчика особенно интересуют альтернативы в окрестности некоторой точки qi*, то можно повысить разрешающую способность частного критерия в окрестности этой точки за счет использования соответствующих нелинейных преобразований [3].

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

0 < qiотн £ 1, i=1, 2, ..., п.

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



Заканчивая рассмотрение вопросов, связанных с построением обобщенного критерия эффективности сложных систем на основе метода экспертных оценок, следует еще раз обратить внимание на то, что на многих этапах его построения приходится опираться на субъективные мнения специалистов при выборе:

– наиболее существенных частных критериев;

– процедуры и единицы измерения для критериев;

– «идеального» значения критерия;

– значения, дающего наибольшую разрешающую способность критерия;

– нормирующего и масштабирующего преобразований;

– структуры функции обобщенного критерия;

– значений весовых коэффициентов.

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


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

Как указывалось выше, для оценки СУБД могут использоваться самые разнообразные параметры, которые могут быть сгруппированы следующим образом:

– параметры определения данных;

– физические параметры;

– параметры доступности;

– параметры обработки транзакций;

– утилиты;

– средства разработки... и т.д.

Рекомендуемые параметры (показатели) для оценки СУБД приведены в табл. 2.6 [7].

Таблица 2.6

Наименование группы	Наименование параметра
Определение данных	Расширенная поддержка первичных ключей
Определение внешних ключей
Предусмотренные типы данных
Расширяемость типов данных
Определение доменов
Простота реструктуризации
Средства поддержки целостности данных
Реализация механизма представлений
Поддержка словаря данных
Независимость данных
Тип базовой модели организации данных
Поддержка эволюции схемы
Физические параметры	Предусмотренные файловые структуры
	Поддержка определения файловых структур
Простота реорганизации
Средства индексирования
Поля/записи с переменной длиной
Сжатие данных
Возможности шифрования
Требования к памяти
Требования к устройствам хранения данных
Доступность	Язык запросов: совместимость со стандартами SQL
Интерфейс для других систем
Интерфейс для языков третьего поколения
Многопользовательский доступ
	Защита базы данных: управление доступом к данным, поддержка механизма авторизации
Обработка транзакций	Процедуры резервного копирования и восстановления
Поддержка контрольных точек
Средства ведения системного журнала
Поддерживаемый уровень детализации параллельности
Возможные стратегии разрешения тупиковых ситуаций
Поддержка усовершенствованных моделей управления транзакциями
Параллельная обработка запросов
Утилиты	Измерение производительности
Настройка производительности базы данных
Инструменты загрузки/выгрузки данных
Контроль активности пользователей
Поддержка процедур администрирования базы данных
Средства разработки	Инструменты, использующие языки четвертого и пятого поколений
Case-инструменты
Инструменты для работы с оконным инструментом
Поддержка хранимых процедур, триггеров и правил
Другие параметры	Способность к модернизации
Стабильность производителя СУБД
База пользователей
Обучение и поддержка пользователей
Взаимодействие с другими СУБД и прочими системами
Поддержка работы в Internet
Утилиты репликации
Возможности распределенной работы
Качество и полнота документации
`Наименование группы	Наименование параметра
Требуемая операционная система
Стоимость
Оперативная справочная система
Используемые стандарты
Управление версиями
Расширенная оптимизация запросов
Масштабируемость
Переносимость
Требуемое аппаратное обеспечение
Поддержка работы в сети
Объектно-ориентированные свойства
Поддержка двух- или трехуровневой архитектуры «клиент/сервер»
Производительность
Пропускная способность при обработке транзакций
Максимальное количество одновременно работающих пользователей

Определение реляционной полноты

Пусть реляционная база данных содержит множество отношений R{R1, R2, …, Rп}, а множество C(R)
представляет собой множество отношений, полученных из R с помощью операций реляционной алгебры. Множество C(R) отражает все связи, имеющиеся в базе данных. Говорят, что язык обладает реляционной полнотой, если он может охватить все связи, представленные C(R). Это означает, что язык имеет такую же выразительную мощность, как реляционная алгебра и реляционное исчисление [11].
Для обеспечения реляционной полноты при реализации языка необходимы две следующие операции [11]:
1) операция присваивания, т.е. возможность создавать новые отношения для хранения результатов операций реляционной алгебры, являющихся также отношениями. R1 помещается во вновь созданное отношение R1;
2) операция транзитивного замыкания, допускающая рекурсию или вложенность операций реляционной алгебры для построения выражений произвольной сложности. Например, выражение
R1<((R2[A, B]*R3)[B]*R4)[C]
содержит вложенные выражения и присваивание, необходимые для получения результата.

Основные определения, классификация распределенных систем

Основной причиной разработки систем, использующих базы данных, является стремление интегрировать все обрабатываемые в организации данные в единое Целое и обеспечить к ним контролируемый доступ. Хотя интеграция и предоставление контролируемого доступа могут способствовать централизации, последняя не является самоцелью. На практике создание компьютерных сетей приводит к децентрализации обработки данных. Децентрализованный подход отражает организационную структуру компании, логически состоящую из отдельных подразделений, отделов, проектных групп и тому подобного, которые физически распределены по разным офисам, отделениям, предприятиям или филиалам, причем каждая отдельная единица имеет дело с собственным набором обрабатываемых данных [7, 9].
Разработка распределенных баз данных позволяет сделать данные, поддерживаемые каждым из существующих подразделений организации, общедоступными, обеспечив при этом их сохранение именно в тех местах, где они чаще всего используются. Подобный подход расширяет возможности совместного использования информации, одновременно повышая эффективность доступа к ней.
Распределенные системы призваны разрешить проблему островов информации.
Базы данных иногда рассматривают как некие электронные острова, представляющие собой отдельные и, в общем случае, труднодоступные места, подобные удаленным друг от друга островам. Данное положение может являться следствием географической разобщенности, несовместимости используемой компьютерной архитектуры, несовместимости используемых коммутационных протоколов и т.д. Интеграция отдельных баз данных в одно логическое целое способна изменить подобное положение дел.
Распределенная база данных – набор логически связанных между собой разделяемых данных (и их описаний), которые физически распределены в некоторой компьютерной сети.
Распределенная СУБД – программный комплекс, предназначенный для управления распределенными базами данных и позволяющий сделать распределенность информации прозрачной для конечного пользователя.

Система управления распределенными базами дан-яйХ (СУРБД) состоит из единой логической базы дан-яых, разделенной на некоторое количество фрагментов.

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

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

– Набор логически связанных разделяемых данных.

– Сохраняемые данные разбиты на некоторое количество фрагментов.

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

– Фрагменты и их реплики распределены по различным сайтам.

– Сайты связаны между собой сетевыми соединениями.

– Работа с данными на каждом сайте управляется СУБД.

– СУБД на каждом сайте способна поддерживать     автономную работу локальных приложений.

– СУБД каждого сайта поддерживает хотя бы одно глобальное приложение.

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



Рис. 5.1. Топология системы управления распределенной базой данных


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

Назначение обеспечения прозрачности состоит в том, чтобы распределенная система внешне вела себя точно так, как и централизованная. В некоторых случаях требование называют основным принципом построения распределенных СУБД [7]. Данный принцип требует предоставления конечному пользователю существенного диапазона функциональных возможностей, но, к сожалению, одновременно ставит перед программным обеспечением СУРБД множество дополнительных задач.

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

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

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

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

Параллельная СУБД – система управления базой Данных, функционирующая с использованием нескольких процессоров и устройств жестких дисков, что позволяет ей (если это возможно) распараллеливать выполнение некоторых операций с целью повышения °б1цей производительности обработки.

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


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

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

– системы с разделением памяти;

– системы с разделением дисков;

– системы без разделения.



Рис. 5.2. Архитектура систем с параллельной обработкой: а) с разделением памяти; б) с разделением дисков; в) без разделения

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

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


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

ограничивающее производительность всей системы.

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

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

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


Подобные системы нуждаются в доступе к большому объему данных и должны обеспечивать приемлемое время реакции на запрос. Параллельные СУБД могут использовать различные вспомогательные технологии, позволяющие повысить производительность обработки сложных запросов за счет применения методов распараллеливания операций сканирования, соединения и сортировки, что позволяет нескольким процессорным узлам автоматически распределять между собой текущую нагрузку [7].

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

[7].

В гомогенных системах все сайты используют один и тот же тип СУБД.

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

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

Гетерогенные системы обычно возникают в тех случаях, когда независимые сайты, уже эксплуатирующие свои собственные системы с базами данных, интегрируются во вновь создаваемую распределенную систему. В гетерогенных системах для организации взаимодействия между различными типами СУБД потребуется организовать трансляцию передаваемых сообщений. Для обеспечения прозрачности в отношении типа используемой СУБД пользователи каждого из сайтов должны иметь возможность вводить интересующие их запросы на языке той СУБД, которая используется на данном сайте. Система должна взять на себя локализацию требуемых данных и выполнение трансляции», передаваемых сообщений. В общем случае данные могут быть затребованы с другого сайта, который характеризуется такими особенностями, как:

– иной тип используемого оборудования;• иной тип используемой СУБД;


– иной тип применяемых оборудования и СУБД,

Если используется иной тип оборудования, однако да сайте установлен тот же самый тип СУБД, методы выполнения трансляции вполне очевидны и включают замену кодов и изменение длины слова. Если типы используемых на сайтах СУБД различны, процедура трансляции усложняется тем, что необходимо отображать структуры данных одной модели в соответствующие структуры данных другой модели. Например, отношения в реляционной модели данных должны быть преобразованы в записи и наборы, типичные для сетевой модели данных. Кроме того, потребуется транслировать текст запросов с одного используемого языка на другой (например, запросы с SQL-оператором STLECT потребуется преобразовать в запросы с операторами FIND и GET языка манипулирования данными сетевой СУБД). Если отличаются и тип используемого оборудования, и тип программного обеспечения, потребуется выполнять оба вида трансляции. Все изложенное выше чрезвычайно усложняет обработку данных в гетерогенных СУБД.

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

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

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

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


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

В настоящее время организована рабочая группа (Specification Working Group – 8ЛУО) для подготовки спецификаций, регламентирующих инфраструктуру среды базы данных, включающую следующие элементы [7].

1. Унифицированный и достаточно мощный интерфейс языка SQL (SQL API), позволяющий создавать клиентские приложения таким образом, чтобы они не были привязаны к конкретному типу используемой СУБД.

2. Унифицированный протокол доступа к базе данных, позволяющий СУБД одного типа непосредственно взаимодействовать с СУБД другого типа, без необходимости использования какого-либо шлюза.

3. Унифицированный сетевой протокол, позволяющий осуществлять взаимодействие СУБД различного типа.

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

Одной из разновидностей распределенных СУБД, являются мультибазовые системы.

Мулътибазовая система – распределенная система управления базами данных, в которой управление каждым из сайтов осуществляется совершенно автономно.

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

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


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

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

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

Первая нормальная форма

Схема отношения  находится в первой нормальной форме (1НФ), если значения в домене являются атомарными для каждого атрибута  в . Другими словами, значения в домене не являются ни списками, ни множествами простых или сложных значений [10].
Схема базы данных R находится в первой нормальной форме, если каждая схема отношения в R
находится в 1НФ.
Определить понятие атомарности трудно: значение атомарное в одном приложении, может быть неатомарным в другом. Можно руководствоваться общим принципом, что значение неатомарно, если в приложении оно используется по частям.
Пример 2.6. Имеется отношение Сотрудники:

Сотрудники		НОМЕР		ФИО
		23		Вербов Александр Владимирович
24		Фисенко Александр Сергеевич
25		Фатхи Дмитрий Владимирович

Если понадобится указать только фамилии сотрудников, то указанное отношение не находится в 1НФ, так как требуемые значения являются частью атрибута ФИО. Чтобы отношение в таких условиях находилось в 1НФ, атрибут ФИО должен быть разбит на части, как показано ниже.

Сотрудники		НОМЕР		ФАМИЛИЯ		ИМЯ		ОТЧЕСТВО
		23		Вербов		Александр		Владимирович
24		Фисенко		Александр		Сергеевич
25		Фатхи		Дмитрий		Владимирович

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

Род		ИМЯ		ПОЛ
		Иван, Александр, Сергей		мужской
Мария, Ирина		женский

Чтобы отношение Род находилось в 1НФ, оно должно быть представлено следующим образом.

Род		ИМЯ		ПОЛ
		Иван		мужской
Александр		мужской
		Сергей		мужской
Мария		женский
Ирина		женский

В чем преимущество применения 1НФ? В том, что 1НФ позволяет выражать F-зависимости с той степенью детализации, с какой требует приложение, что невозможно без 1НФ.
Но и 1НФ обладает рядом существенных недостатков [2, 7, 10]. На первых этапах проектирования базы данных, после анализа предметной области и определения состава информации для хранения в БД обычно формируется так называемое универсальное отношение.

Универсальное отношение – одна таблица, находящаяся в 1НФ, в которой может храниться вся информация об интересующей предметной области. Другими словами схему этого отношения образует весь перечень интересующих атрибутов предметной области [5].

При использовании универсального отношения возникают следующие проблемы [5, 10].

1. Избыточность. Данные многих столбцов многократно повторяются. Повторяются и некоторые наборы данных.

2. Аномалии обновления:

а) аномалии добавления;

б) аномалии изменения;

в) аномалии удаления.

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

Рассмотрим отношение График.

График	РЕЙС	ДАТА	ПИЛОТ	ГАЛЕРЕЯ
	112	6 июня	Иванов	7
112	7 июня	Петров	7
203	8 июня	Иванов	12

Атрибуты РЕЙС ДАТА являются ключом отношения График, и это отношение должно также удовлетворять F-зависимости РЕЙСГАЛЕРЕЯ. Пусть требуется обновить отношение, указав значение ключа и задавая значения всем остальным атрибутам. Однако если выполнить операцию

ИЗМЕНИТЬ (График; 112, 6 июня, ПИЛОТ=Иванов, ГАЛЕРЕЯ=8),

то отношение перестанет удовлетворять F-зависимости РЕЙСГАЛЕРЕЯ. Чтобы избежать нарушения F-зависимости, необходимо после каждого выполнения операции обновления просмотреть полученное отношение и везде (во всех кортежах), где появляется указанный в операторе номер рейса, изменить номер галереи на указанный в операторе. А требовалось всего лишь изменить один кортеж. Кроме того, информация о связи между номером рейса и номером галереи дублируется с рассмотренном отношении, что ведет к избыточности информации.

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

Пилот-График	РЕЙС	ДАТА	ПИЛОТ
	112	6 июня	Иванов
112	7 июня	Петров
203	8 июня	Иванов

Галерея-График	РЕЙС	ГАЛЕРЕЯ
	112	6 июня
112	7 июня
203	8 июня

При этом сохраняется возможность восстановить первоначальное отношение График из двух новых отношений (см. гл.4). Указанной аномалии обновления больше не существует, так как нужно изменить только один кортеж, чтобы поменять назначение галереи. При этом устраняется и некоторая избыточность данных, так как каждая пара (номер рейса, номер галереи) записывается только однажды.

Пятая нормальная форма

Целью поиска декомпозиций без потери информации является устранение избыточности из отношений. В терминах поиска декомпозиций без потерь 4НФ не является наилучшим решением.
J-зависимость *[R1,  R2,..., Rp] над R называется тривиальной, если она удовлетворяется в любом отношении r(R) [10].
J-зависимость соединения *[R1,  R2, ..., Rp] приложима к реляционной схеме, если R=R1R2...R.
Пусть R – схема отношения и F – множество F- и J-зависимостей над R. Схема R находится в пятой нормальной форме (5НФ) относительно F, если для каждой J-зависимости *[R1, R2, ..., R ], выводимой из F и приложимой к R, J-зависимость тривиальна или каждое Ri является сверхключом R [10].
Схема базы данных R находится в пятой нормальной форме относительно F, если в этой форме находится каждая схема R из R.
Приведем еще одно определение 5НФ [10].
Пусть R - схема отношения и F – множество F- и J-зависимостей. R находится в пятой нормальной форме (5НФ) относительно F, если для каждой J-зависимости *[R1, R2, ..., Rp], выводимой из F и приложимой к R, зависимость *[R1, R2, …, Rp ] выводима из ключевых F-зависимостей в R.

Плотный индекс

Пусть по каким-либо причинам невозможно упорядочить основной файл  по ключу . Построим дополнительный файл  по правилу [17]:
1) записи файла  имеют формат , где  – поле, принимающее значение ключа записи основного Файла ;  – указатель на эту запись;
2) записи файла  упорядочены по полю . Полученный файл называется плотным индексом. Он строится почти так же, как и неплотный индекс. Различие заключается в том, что для каждого значения ключа  в файле  имеется отдельная запись, а в неполном индексе – только для значения ключа пер. вой записи блока.
Пример плотного индекса представлен на рис. 3.11. Над плотным индексом можно также построить В-дерево.

Рис. 3.11. Пример плотного индекса

Понятие базы данных

База данных (БД) – именованная совокупность данных, отображающих состояние объектов и их отношений в рассматриваемой предметной области. Организуется так, что данные собираются однажды и централизованно хранятся (и модифицируются) в виде, доступном всем специалистам или системам программирования, которые могут их использовать.
Особенности организации данных в БД по сравнению с файловыми системами обеспечивают использование одних и тех же данных в различных приложениях, позволяют решать различные задачи планирования, исследования и управления. БД сводят к минимуму дублирование данных, прибегая к дублированию только для ускорения доступа к данным или для обеспечения восстановления БД при ее разрушении. Одна из важных черт БД – независимость данных от особенностей прикладных программ, которые их используют, а также возможность создания этих программ в такой форме, что изменение особенностей хранения, логической структуры или значений данных не требует изменения программ их обработки. Другой важной чертой БД является возможность изменения физических особенностей хранения данных без изменения их логической структуры.
Можно четко сформулировать требования к БД со стороны внешних пользователей [17]. База данных должна:
1. удовлетворять актуальным информационным потребностям пользователей, обеспечивать возможность хранения и модификации больших объемов многоаспектной информации;
2. обеспечивать заданный уровень достоверности хранимой информации и ее непротиворечивость;
3. обеспечивать доступ к данным только пользователей с соответствующими полномочиями;
4. обеспечить возможность поиска информации по произвольной группе признаков;
5. удовлетворять заданным требованиям производительности при обработке запросов;
6. иметь возможность реорганизации и расширения при изменении границ предметной области;
7. обеспечивать выдачу информации пользователям в различной форме;

8. обеспечивать простоту и удобство обращения внешних пользователей за информацией;

9. обеспечивать возможность одновременного обслуживания большого числа внешних пользователей.

Соответственно двум понятиям – «информация» и «данные» – в базах данных различают два аспекта рассмотрения вопросов: инфологический и даталогический

[5, 17].

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

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

Данные соответствуют зарегистрированным фактам об объектах реального мира. Чтобы в дальнейшем использовать эти данные, требуется их смысловое содержание - семантика данных. Поэтому в информационной системе должны быть сформулированы правила смысловой интерпретации данных.

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

Понятие функциональной зависимости

Создание баз данных преследует две основные цели [2, 10, 17]:
– понизить избыточность хранимых данных;
– повысить их надежность.
Любое априорное знание о различного рода ограничениях, накладываемых на совокупности данных, может принести большую пользу для достижения указанных целей.
Один из способов формализации этих знаний – установление зависимостей между элементами данных. Известно два основных типа таких зависимостей:
1) функциональные зависимости;
2) многозначные зависимости.
Функциональная зависимость является обобщением понятия ключа.
В табл. 2.7 представлено отношение График (ПИЛОТ, РЕЙС, ДАТА, ВРЕМЯ-ВЫЛЕТА). Это отношение показывает, какой пилот участвует в данном рейсе в данный день и каково время вылета самолета. Не любое сочетание значений атрибутов ПИЛОТ, РЕЙС, ДАТА и ВРЕМЯ-ВЫЛЕТА допустимо в таком расписании.
Таблица 2.7

График		ПИЛОТ		РЕЙС		ДАТА		ВРЕМЯ-ВЫЛЕТА
		Мовчан		83		9 августа		10:15
		Мовчан		116		10 августа		13:25
		Синицын		281		8 августа		05:50
		Синицын		301		12 августа		18:35
		Синицын		83		11 августа		10:15
		Федотов		83		13 августа		10:15
		Федотов		116		12 августа		13:25
		Вишневский		281		9 августа		05:50
		Вишневский		281		13 августа		05:50
		Вишневский		412		15 августа		13:25

На табл. 2.7 накладываются следующие ограничения.
1. Для каждого рейса назначается только одно время вылета.
2. Для данного пилота, даты и времени вылета возможен только один рейс.
3. Для данного рейса и даты назначается только один пилот.
Эти ограничения являются примерами F-зависимостей (F-зависимость – функциональная зависимость между данными).
F-зависимость имеет место тогда, когда значения кортежа на одном множестве атрибутов единственным образом определяют эти значения на другом множестве атрибутов.
Указанные выше ограничения можно сформулировать следующим образом.

1. ВРЕМЯ функционально зависит от РЕЙСА.

2. РЕЙС функционально зависит от {ПИЛОТ, ДАТА, ВРЕМЯ}.

3. ПИЛОТ функционально зависит от {РЕЙС, ДАТА}. Порядок в этих последовательностях могут менять и говорить, что РЕЙС, ДАТА функционально определяют ПИЛОТ, или символически:

{РЕЙС, ДАТА}ПИЛОТ.

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

, то

для любых кортежей  и  в .

В F-зависимости подмножество  называется левой частью, a – правой частью.

Понятие информационной системы, информационное обеспечение

Информационные системы – системы обработки данных о какой-либо предметной области со средствами накопления, хранения, обновления, поиска и выдачи данных [12].
Данные – информация (факты и идеи), представленная в формализованном виде, позволяющем передавать или обрабатывать ее при помощи некоторого процесса (и соответствующих технических средств).
В последнем определении под «передачей» данных подразумевается и процесс их хранения, т.к. с теоретических позиций – хранение равносильно передаче данных, но не в пространстве, а во времени (соответственно схемы памяти рассматриваются как каналы передачи данных во времени).
В широком смысле под информацией понимают любые сведения о каком-либо событии, сущности, процессе и т.п., являющиеся объектом некоторых операций: восприятия, передачи, преобразования, хранения или использования.
Процесс осмысливания понятия информации и ее роли в жизни и деятельности человека продолжается. Понятие информации вместе с другими научными понятиями позволяет более глубоко познать законы развития материального мира. На современном этапе считается, что оно является общим для всех видов и форм движения материи и связывается с тем или иным неотъемлемым свойством или атрибутом материи [17].
Все многообразие информационных систем можно классифицировать по ряду признаков.
По средствам выполнения информационной задачи различают информационные системы ручные, механизированные и автоматизированные; по выполняемой функции – информационно-поисковые, управляющие, моделирующие, обучающие, экзаменующие и др.; по области применения – медицинские, финансовые, лингвистические и др.
Автоматизированная информационная система (АИС) – информационная система, использующая ЭВМ на этапах ввода, обработки и выдачи информации по различным запросам пользователей. Представляя собой развитие информационно-поисковых систем, обеспечивающих выполнение информационного поиска с помощью прикладных программ, АИС характеризуется преимуществами системного направления развития ЭВМ:

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

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

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

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

Для полного решения какой-либо информационной задачи в этих системах необходимо, чтобы ЭВМ понимала смысл текста, написанного на естественном языке, что тесно связано с проблемой искусственного интеллекта [17].

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

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

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

Понятие независимости данных

Трехуровневая архитектура позволяет обеспечить независимость
хранимых данных от использующих их программ и пользователей [2, 5, 17]. АБД может при необходимости переписать хранимые данные на дру гие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель (внутреннюю схему) данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель (концептуальную схему). Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся «прозрачными» для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Таким образом, различают два типа независимости данных – логическую
и физическую.
Логическая независимость данных – полная защищенность внешних схем (инфологической модели) от изменений, вносимых в концептуальную схему (даталогическую модель).
Физическая независимость данных – полная защищенность концептуальной схемы (даталогической модели) от изменений, вносимых во внутреннюю схему (физическую модель).
Структура СУБД определяется используемой моделью данных. В этом смысле для СУБД являются обязательными следующие функции [12]:
а) трансляция схемы, определяющей структуру хранимых данных, в некоторое внутреннее представление, используемое СУБД при дальнейшей работе с данными (схема обычно составляется администратором базы данных на основании требований предполагаемых пользователей и записывается на языке определения данных,
принятом в СУБД); б) загрузка данных в базу данных (создание БД), сопровождаемая максимально возможной проверкой их правильности;
в) реализация запросов пользователей (формулируемых на специальном языке, принятом в данной СУБД) на отбор и извлечение некоторой части базы данных по задаваемым ими критериям отбора; этот процесс может сопровождаться некоторыми процедурами редактирования и обработки отобранной информации;
г) обновление некоторых частей базы данных без изменения структуры данных; критерии определения обновляемой части обычно аналогичны критериям отбора данных и задаются пользователем.

Понятие системы управления базами данных

Функционирование БД обеспечивается совокупностью языковых и программных средств, называемых системой управления базами данных (СУБД).
Система управления базами данных – совокупность языковых и программных средств, предназначенных для создания, ведения и конкурентного использования базы данных многими пользователями [12].
Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, называются в свою очередь базами данных.
Создание и применение СУБД призвано к максимальному удовлетворению требований, предъявляемых к эффективным базам данных. Это приводит к необходимости решения вопроса централизованного управления данными.
Концепция централизованного управления данными имеет ряд неоспоримых преимуществ по сравнению с файловыми системами (см. прил.1).
1. Минимальная избыточность хранимых данных.
2. Непротиворечивость хранимых данных.
3. Многоаспектное использование данных.
4. Комплексная оптимизация.
5. Возможность стандартизации представления и обмена данными.
6. Возможность обеспечения санкционированного доступа к данным.
Но, предоставляя весомые преимущества, централизованное управление данными предъявляет к СУБД требование независимости данных от использующих их прикладных программ.
Современные СУБД реализуют централизованное управление данными и, кроме того, обеспечивают:
а) определение данных, подлежащих хранению в БД (определение логических свойств данных, соответствующих представлениям пользователя и называемых структурами данных в БД, а также физическая организация хранения данных, называемая структурами хранения БД);
б) первоначальную загрузку данных в БД – так называемое создание БД;
в) обновление данных;
г) доступ к данным по различным запросам пользователя, отбор и извлечение некоторой части БД, редактирование извлеченных данных и выдачу их пользователю. Перечисленные действия принято называть процессом получения справок из БД.
Специальные средства СУБД обеспечивают секретность данных, т.е. защиту данных от неправомочного воздействия, и целостность данных – защиту от непредсказуемого взаимодействия конкурирующих процессов, приводящих к случайному или преднамеренному разрушению данных, а также от отказов оборудования.

Последовательное распределение памяти

Последовательное распределение – простой и естественный способ хранения линейного списка. В этом случае узлы списка размещаются в последовательных элементах памяти (рис.3.1) [17].
При последовательном распределении вектор данных логически отделен от описания структуры хранимых данных. Например, если структура данных представляет собой линейный список (файл записей фиксированной длины), то описание структуры хранится в отдельной записи и содержит:

В случае линейного списка адресная функция состоит из операций смещения и масштабирования. Любые отношения, которые можно выразить на языке целых чисел, можно истолковать как отношения между элементами памяти, получая при этом всевозможные варианты структур.
В качестве примера (из [17]) рассмотрим реализацию с помощью линейного списка при последовательном распределении памяти для логической структуры типа регулярного двоичного дерева (рис. 3.2). Идея способа заключается в том, что начиная с элемента памяти ?(1), делают его корнем дерева, размещают там данные, соответствующие узлу У1. В элементах памяти ?(2) и ?(3) размещают непосредственных потомков узла У1
– узлы У2 и У3, и т.д. В общем случае, непосредственные потомки узла Ук размещаются по адресам: ?(2k) и ?(2k+1). Адресная функция имеет вид

где k – номер узла древовидной структуры; р – базовый адрес; т – размер элемента памяти, который требуется для хранения данных узлов дерева (каждый узел представляет собой запись фиксированной длины). По дереву, которое при этом получается, можно двигаться в обоих направлениях, так как от узла Ун можно перейти к его потомкам, удвоив k (или удвоив k и прибавив единицу).
Можно двигаться к узлу, являющемуся исходным для узла Ун, разделив k пополам и отбросив дробную часть. Адрес соответствующего узлу элемента памяти определяется по адресной функции.

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



где  - знак округления до ближайшего меньшего целого.



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

Корень дерева размещается в середину вектора. В элементах памяти от г-то до (m-l)-ro включительно размещается левое поддерево. В элементах памяти от (m+1)-го до j-го включительно размещается правое поддерево. Аналогично процесс повторяется для размещения каждого поддерева. Приведенный способ позволяет реализовать двоичное сбалансированное дерево.

Существует ряд других способов представления древовидных структур [4, 13, 17]. С помощью приемов, основанных на свойствах целых чисел, можно с помощью последовательного распределения организовать в памяти некоторые сетевые структуры. Однако для представления сложных сетевых структур требуются более гибкие методы построения в памяти ЭВМ, которые невозможно получить с помощью последовательного распределения памяти. В этом случае используется связанное распределение памяти.

Последовательный поиск

Последовательный поиск заключается в последовательной проверке всех записей файла на их соответствие условию поиска Q [17]. Записи, значения полей которых удовлетворяют условию Q, выдаются в качестве результата поиска.
, где – значение ключевого поля. Алгоритм поиска заключается в последовательном просмотре записей файлы и проверке условия . Если запись найдена, то алгоритм заканчивает свою работу (удачный поиск). В противном случае поиск заканчивается просмотром последней записи файла (неудачный поиск).
Если ключ  с равной вероятностью может принимать любое из заданных значений, то в среднем для выполнения поиска требуется время:

Поиск по интервалу значений ключа . Алгоритм поиска заключается в последовательном просмотре всех записей файла, так как заранее неизвестно, какие записи удовлетворяют условию Q, а какие не удовлетворяют.
Требуемое время на поиск:

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

Преимущества и недостатки распределенных СУБД

Системы с распределенными базами данных имеют дополнительные преимущества перед традиционными централизованными системами баз данных [7]. Но эта технология не лишена и некоторых недостатков (табл. 5.1).
Комплексный учет всех предоставляемых выигрышей и проигрышей является сложной задачей, методология решения которой в настоящее время не определена. Ответственность за принятие решения по разработке и внедрению распределенной системы может взять на себя группа смелых специалистов.
Таблица 5.1

Преимущества		Недостатки
Отражение структуры организации		Повышение сложности
Разделяемость и локальная автономность		Увеличение стоимости
Повышение доступности данных		Проблемы защиты
Повышение надежности		Усложнение контроля за целостностью данных
Повышение производительности		Отсутствие стандартов
Экономические выгоды		Недостаток опыта
Модульность системы		Усложнение процедуры разработки базы данных

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

Повышение доступности данных

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

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

Повышение надежности

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

Повышение производительности

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

Экономические выгоды

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


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

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

Модульность системы

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

Недостатки

Повышение сложности

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

Увеличение стоимости


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

Проблемы защиты

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

Усложнение контроля за целостностью данных

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

Отсутствие стандартов

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

Недостаток опыта

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

Усложнение процедуры разработки базы данных

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

КРАТКАЯ ИСТОРИЯ АЗВИТИЯ СУБД

Предшественницами СУБД были файловые системы, обладающие существенными недостатками (прил.1). Однако появление СУБД не привело к пол- ному исчезновению файловых систем. Для выполнения некоторых специализированных задач подобные файловые системы используются до сих пор. Считается, что развитие СУБД началось еще в 60-е годы, когда разрабатывался проект полета корабля Apollo на Луну. Этот проект был начат по инициативе президента США Дж.Ф.кеннеди, поставившего задачу вы- садить человека на Луну к концу десятилетия. В то время не существовало никаких систем, способных обрабатывать или как-либо управлять тем огромным количеством данных, которое было необходимо для реализации этого проекта [7].
В результате специалисты основного подрядчика – фирмы North American Aviation (теперь эта фирма называется Rockwell International) –. разработали программное обеспечение под названием GUAM (Generalized Update Access Method). Основная идея GUAM была построена на том, что малые компоненты объединяются вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Эта соответствующая инвертированному дереву структура часто называется иерархической структурой (hierarchical structure). В середине 60-х годов корпорация IBM присоединилась к фирме NAA для совместной работы над GUAM, в результате чего была создана система IMS (Information Management System). Причина, по которой корпорация IBM ограничила функциональные возможности IMS только управлением иерархиями записей, заключалась в том, что необходимо было обеспечить работу с устройствами хранения с последовательным доступом, а именно с магнитными лентами, которые были основным типом носителя в то время. Спустя некоторое время это ограничение удалось преодолеть. Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов [7].
Следующим заметным достижением середины 60-х годов было появление системы ПЭ8 (Integrated Data Store) фирмы General Electric.
Несмотря на то, что этот отчет официально не был одобрен Национальным Институтом Стандартизации США (American National Standards Institute – ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG. Теперь они называются CODASYL-системами, или DBTG-системами. СОРА8'Л -системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Однако этим двум моделям присущи приведенные ниже недостатки.

– Даже для выполнения простых запросов с использованием переходов и доступом к определенным записям необходимо создавать достаточно сложные про- граммы.

– Независимость от данных существует лишь в минимальной степени.

– Отсутствие общепризнанных теоретических основ.

В 1970 году Э.Ф.Кодд (Е.F.Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал очень важную и весьма своевременную статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х - начале 80-х годов. Особенно следует отметить проект System В, разработанный в исследовательской лаборатории корпорации IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданный в конце 70-х годов (Astrahan et al., 1976). Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.

– Был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД.

– В 80-х годах были созданы различные коммерческие реляционные СУБД – например, DB2 или SQL/DS корпорации IBM или Oracle корпорации Oracle Corporation.


В настоящее время существует несколько сотен раз- личных реляционных СУБД для мейнфреймов и микрокомпьютеров, хотя для многих из них определение реляционной модели носит несколько преувеличенный характер. В качестве примера многопользовательских СУБД может служить система СА-OpenIngres фирмы Computer Associates и систему Informix фирмы Informix Software, Inc. Примерами реляционных  СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim. Реляционные  СУБД относятся к СУБД второго поколения. Однако реляционная модель также обладает некоторыми недостатками – в частности, ограниченными возможностями моделирования сложных предметных областей. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель <сущность-связь» (Entity-Relationship model – ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных.

В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели – RM/Т (1979), затем еще одну версию – RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).

В ответ на все возрастающую сложность приложений баз данных  появились две новые системы: объектно-ориентированные СУБД, или ООСУБД (Object-Oriented DBMS – OODBMS), и объектно-реляционные СУБД, или ОРСУБД (Object-Relational DBMS - ORDBMS). Однако, в отличие от предыдущих моделей, действительная  структура этих моделей не совсем ясна. Попытки реализации подобных моделей представляют собой СУБД третьего поколения.

КРАТКИЙ ТОЛКОВЫЙ СЛОВАРЬ

Автоматизированная информационная система (АИС) – информационная система, использующая ЭВМ на этапах ввода, обработки и выдачи информации по различным запросам потребителей. Представляя собой развитие информационно-поисковых систем, обеспечивающих выполнение лишь одной функции поиска информационного с помощью прикладных программ, АИС характеризуется преимуществами системного направления развития ЭВМ. многофункциональностью, т.е. способностью решать разнообразные задачи; одноразовостью подготовки и ввода данных; независимостью процесса сбора и обновления (актуализации) данных от процесса их использования прикладными программами; независимостью прикладных программ от физической организации базы данных; развитыми средствами лингвистического обеспечения. Для полного решения какой-либо информационной задачи в этих системах необходимо, чтобы ЭВМ понимала смысл текста, написанного на естественном языке, что тесно связано с проблемой искусственного интеллекта. АИС подразделяют на автоматизированные информационные системы документографические и автоматизированные информационные системы фактографическое.
Автоматизированные системы управления (АСУ) – человеко-машинные системы, основанные на комплексном использовании экономико-математических методов и технических средств обработки информации для решения задач управления. Внедрение АСУ обусловлено необходимостью совершенствования системы планирования и управления народным хозяйством и повышения эффективности производства. Основной предпосылкой создания АСУ является возможность автоматизации информационных процессов. АСУ характеризуется применением развитого комплекса технических средств, предназначенных для выполнения основных процессов сбора и обработки информации в ходе решения задач управления в соответствии с технологией планово-экономических работ. Используя технические средства, включая ЭВМ, выполняют определенные операции в общем информационном процессе и осуществляют следующие операции: фиксацию или сбор первичных данных в местах их возникновения, формирование первичной документации, передачу данных между пунктами их возникновения и использования, хранение данных обработку данных, предоставление сведений, формирование документов для специалистов аппарата управления.
Функционирование АСУ повышает эффективность управленческого труда, дает возможность в короткие сроки и с высокой степенью достоверности обрабатывать большие объемы информации, необходимой для управления. АСУ подразделяют на три основные группы: автоматизированные системы управления предприятием (АСУП), отраслевые автоматизированные системы управления (ОАСУ) и специализированные АСУ.

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

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

Алгоритм - совокупность правил, определяющих эффективную процедуру решения любой задачи из некоторого заданного класса задач. Понятие алгоритма использовалось в математике давно, но как математический объект исследуется в связи с решением ряда проблем оснований математики с 30-х гг. 20 века. Тогда же были разработаны основные понятия теории алгоритмов. В связи с развитием ЭВМ и их широким применением понятие алгоритма стало одним из центральных в прикладной математике. Уточнения понятия алгоритма, основанные, например, на понятиях частично-рекурсивной функции или машин Тьюринга, успешно использовались при решении принципиальных вопросов теории алгоритмов (таких, как существование алгоритмически неразрешимых проблем и др.), но оказались мало пригодными для практического применения в ЭВМ. Вместо них широкое распространение получили алгоритмические языки, которые можно рассматривать как современное уточнение понятия алгоритма.


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

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

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


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

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

б) первоначальную загрузку данных в БД – так называемое создание БД;

в) обновление данных;

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

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


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

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

Включающий язык (базовый язык) – язык программирования в СУБД, для которого строятся расширения, обеспечивающие взаимодействие программы на включающем языке с системой управления базой данных. Эти расширения получили название языка манипулирования данными.

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

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

Время отклика на запрос – промежуток времени между вводом запроса к базе данных в ЭВМ и завершением обработки запроса с предоставлением результатов.

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

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

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


Тип данных определяет множество значений, которые могут принимать соответствующие ему данные. Примерами свойств типа могут быть имя данного, категория значения (число, строка литер, дата или географическая координата), замок защиты для управления доступом к данному и др. База данных составляется из структур или элементов различного типа, причем структуры одного типа могут состоять или конструироваться из структур других типов. Класс структур данных, допустимых в конкретной базе данных, можно задать определением типов допустимых в нем структур и способов их композиции. Описание каждой структуры в терминах свойств, присущих всем данным, принадлежащим к структуре данного типа, составляет схему данных. Допустимые структуры можно представить как композиции пяти порождающих типов структур: элемента, группы, группового отношения, записи (или статьи) и файла. Для каждого из этих типов можно рассматривать свойства, присущие его схеме, и свойства отдельных экземпляров. Элемент представляет собой логически неделимую структуру данных, из которых в конечном итоге составляются структуры всех остальных типов. Схема элемента может определять его имя, категорию его значения, особенности представления значения (с плавающей запятой, в закодированном виде и т.д.), синтаксис его значения (задаваемый, например, шаблоном, длиной, диапазоном и т.д.) и др. правила проверки достоверности значения, способы редактирования значения при выдаче и т.д. В экземплярах элемента указываются: степень достоверности значения дата или источник его поступления и др. Группа есть именованная совокупность элементов и/или других групп. Соответственно схема группы состоит из схем ее составляющих - схем элементов и/или схем групп. Схема группы может быть повторяющейся - в каждом экземпляре объемлющей ее структуры может появляться несколько экземпляров повторяющейся группы. В схеме группы может указываться ее имя, число повторений или упорядоченность экземпляров повторяющейся группы, замки защиты для управления доступом к содержащимся в группе значениям элементов и др.


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

Домен (от франц. domaine – владение) 1) область значений некоторого данного; 2) область значений атрибута в модели данных реляционной.

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

Доступ к базе данных удаленный – доступ к базе данных одного или более пользователей, работающих за удаленным терминалом или на удаленной ЭВМ. Терминалы или ЭВМ считаются удаленными по отношению к БД, если требуется применение средств дистанционной связи. Удаленный доступ использует способность БД обслуживать более одного пользователя одновременно (коллективный доступ к БД).

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


Вызывается обращением пользователя с запросом к базе данных на языке манипулирования данными. Доступ к данным реализуется либо с помощью выборки или размещения данных непосредственно по их адресу на запоминающем устройстве (прямой доступ к данным), либо с помощью последовательной обработки записей файла (последовательный доступ к данным).

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

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

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

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


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

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

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

Информационные системы – системы обработки данных о какой-либо предметной области со средствами накопления, хранения, обновления, поиска и выдачи данных. По средствам выполнения информационной задачи различают информационные системы ручные, механизированные и автоматизированные; по выполняемой функции - информационно - поисковые, управляющие, моделирующие, обучающие, экзаменующие и др.; по области применения - медицинские, финансовые, лингвистические и др.

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


С общей стороны информация – связь в любых целенаправленных системах, определяющая их целостность, устойчивость, уровень функционирования. Информацию можно выразить математически и измерять с помощью информационной единицы – бита. Как отражение явлений реального мира, понятие информации раскрывается указанием действий, в которых она участвует: передачи, преобразования и хранения. Хранение информации предполагает наличие носителя информации. Передача информации предполагает наличие передатчика, приемника и канала связи, способного отображать состояние передатчика в состояние приемника. Обработка информации – выполнение любого алгоритма, исходные данные для которого отождествляются с состоянием того или другого носителя. Различают дискретную и непрерывную форму информации. Как в естественных, так и в искусственных процессах, в которых участвует информация, одни ее формы переходят в другие. Изучение общих свойств информации независимо от ее смыслового содержания является предметом теории информации.

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

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


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

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

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

Кодда модель базы данных – модель данных реляционная.

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

QBE (англ. Query by Example – запрос на примере) – язык запросов к базам данных в модели данных реляционной и модели данных иерархической. Разработан в 1975 году М. Злуфом (США). Основан на исчислении предикатов, где в запросах требуемое множество кортежей определяется путем спецификации предиката, которому должны удовлетворять эти кортежи, запрос формулируется посредством экрана видеотерминала, на котором пользователю показывается так называемый макет отношения – заголовки столбцов таблицы, под которыми можно задать параметры своего запроса. Если в столбец помещается какое-либо значение атрибута, это означает, что требуется найти кортеж с заданным значением атрибута. Если значение атрибута отмечается подчеркиванием (или другим способом), это значит, что приведен только пример значения атрибута, который нас интересует. Специальные буквы, указанные в столбце перед значением атрибута, определяют требуемые манипуляции для атрибута: выдачу на печать, замену, исключение или добавление. QBE позволяет строить сложные запросы, является реляционно полным языком, удобен для любых пользователей.

Манипулирование данными – действия по извлечению или изменению данных в базе данных. Описываются не языке манипулирования данными модели базы данных.


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

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

Меню – способ взаимодействия с пользователем в диалоговых системах программирования, при котором пользователю предлагается (обычно на экране видеотерминала) перечень возможных действий, из которых он может выбрать и отметить (напри мер, посредством клавиши или курсора) одно, подлежащее выполнению. Использование меню позволяет определять требуемые действия программы на удобном для пользователя языке его профессиональной деятельности, экономить его усилия по формулировке задачи; меню широко применяется в массовых системах взаимодействия с ЭВМ (например, автоматизированных обучающих системах).

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

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

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


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

Модель данных бинарная – представление о проблемной области в виде бинарных отношений, характеризуемых триадой (объект, атрибут, значение). Используется в области искусственного интеллекта.

Модель данных иерархическая – представление о проблемной области в виде иерархий или деревьев объектов, когда каждый объект может иметь несколько «подчиненных» объектов, но только один «старший». Соответственно, язык манипулирования данными иерархической модели обладает средствами манипулирования объектами в терминах их иерархических связей. Иерархическая модель реализована в ряде широко распространенных СУБД.

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

Модель данных кодасиловская – модель данных сетевая, разработанная  рабочей  группой по базам данных  при  комитете CODASYL (США). Цель модели – создание интегральной многоцелевой базы данных, доступной для многих приложений, использующих различные языки программирования. Данные, централизованно хранящиеся в базе данных, логически описываются схемой данных, для записи которой предлагается язык определения данных высокого уровня, обеспечивающий независимость данных от способов их использования и языка манипулирования данными. Функции составления и поддержания схемы выполняются администратором базы данных. Для отдельных областей применения базы данных конструируются подсхемы данных. Язык описания подсхемы позволяет задавать подмножество базы данных, используемое в соответствующей области, в терминах языка программирования, ориентированного на эту область. Язык манипулирования данными, включаемый в этот язык программирования, используется для организации передач данных между базой данных и рабочей областью задачи.


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


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

Модель данных реляционная – модель данных, предложенная в 1970 году американским ученым Е.Ф.Коддом. Основана на представлении данных в виде отношений между ними, при этом представление этих отношений подвергается нормализации – пошаговому процессу приведения их к двумерной табличной форме с полным сохранением информации о них. К двумерной табличной форме могут быть приведены и отношения, имеющие структуру дерева, и наиболее общий вид отношений – сетевые, которые могут быть сведены к нескольким деревьям. Представление данных в виде двумерных таблиц является естественным и легкодоступным для пользователей. Под таблицами понимают прямоугольные массивы, обладающие следующими свойствами: элементу данных соответствует единственный вход в таблицу; в каждой из колонок таблицы располагаются элементы некоторого вида, каждой колонке присваивается имя; не допускаются строки таблиц с совпадающими значениями всех колонок; колонки и строки таблиц могут просматриваться в любой последовательности. Отношения в реляционной модели представлены таблицами, в которых каждая из строк содержит значения свойств (или атрибутов), которыми обладает некоторый объект данного типа; каждый из столбцов соответствует множеству значений, которые принимает некоторый атрибут этого типа, т.е. отношение есть множество векторов из n элементов – кортежей (

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


Возможны три уровня сопряжения пользователя с базой данных: на высшем уровне пользователь формулирует свои запросы в терминах реляционного исчисления, определяя, какие новые отношения он желает образовать из существующих; на среднем уровне запрос формулируется как последовательность операций реляционной алгебры, выполняемых над отношениями; на самом низком уровне пользователь определяет шаги получения некоторого кортежа отношения, т.е. полностью управляет поиском данных в базе данных. Реляционная модель основана на представлениях пользователя о данных и не касается физического представления структур хранения. Таким образом, пользователь освобождается от знания деталей физического представления данных и особенностей программирования, что существенно облегчает процесс обучения. Отношения базы данных трактуются как множества, чьи упорядоченность, организация и физическое представление не известны большинству пользователей и изменяются без предупреждения. Однако пользователь может определить упорядоченность получения элементов, передаваемых из его рабочего поля в базу данных. Гибкий аппарат получения файлов для различных областей использования данных с помощью просто реализуемых операций над отношениями единой базы данных позволяет обеспечить независимость данных. Язык манипулирования данными реляционной модели послужил основой ряда популярных языков запросов (SQL, QBE и др.).

Модель данных сетевая – представление о проблемной области в виде объектов, связанных бинарными отношениями «многие-ко-многим», т.е. каждый объект может иметь несколько «подчиненных» и несколько «старших», благодаря чему сетевая модель может быть представлена ориентированным графом. Наиболее известной сетевой моделью является модель данных кодасиловская.

Модель данных «сущность-связь» - представление о проблемной области в виде объектов (называемых сущностями), между которыми фиксируются связи. Для каждой связи устанавливается число связываемых ею объектов. Модель «сущность-связь» имеет наглядное графическое представление: сущности изображаются прямоугольниками, связи – ромбами, число связываемых объектов указывается на линии соединения объекта связью.


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

Набор данных - представление группового отношения в кодасиловской модели данных.

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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

SQL, SEQUEL (от англ. Structured English Query Language – структурный английский язык запросов) – язык запросов, базирующийся на реляционной алгебре. Разработан в начале 70-х гг. в США. Центральным оператором языка является так называемое отображение исходных отношений на некое производное отношение, образованное из отдельных атрибутов исходных отношений при соблюдении для них заданных условий. Имеются средства композиции отображений, в том числе отображения могут быть вложенными, к ним можно применять теоретико-множественные операции, можно именовать кортежи производных отношений, к совокупности значений некоторого атрибута в отношении можно применять функции вычисления числа таких значений, их суммы, среднего, минимального и максимального значения. SQL является реляционно полным языком. Широко распространен, ведутся работы по его стандартизации.

Совместимость базы данных – свойство, характеризующее способность базы данных к интеграции баз данных. Является необходимым, но недостаточным условием для интегрированного представления базы данных. Выделяют совместимость по моделям данных и соответствие типу СУБД, по физическому представлению базы данных (текстовая и графическая) и др.

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

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

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


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

Сущность – элемент модели предметной области, означающий объект, предмет, понятие и т.п.

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

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

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


Файл (англ. file – досье, картотека) в языках программирования – рассматриваемая как единое целое совокупность однотипных по структуре и способу использования записей, относящихся к определенному этапу управленческих работ. Как правило, файл содержит большие объемы информации и размещается на внешних носителях памяти ЭВМ. При обработке файла его записи поочередно вызываются в оперативную память. Кроме записей, файл обычно содержит некоторые сведения, позволяющие отличить один файл от другого, определить последнюю запись файла и т.д.

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

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

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

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

НЕДОСТАТКИ ФАЙЛОВЫХ СИСТЕМ

Ограничения файловых систем, закрывающие перспективы их использования при обработке значительных объемов информации большим количеством кон- курирующих пользователей следующие [7, 1Ц.
1. Разделение и изоляция данных.
2. Дублирование данных.
3. Зависимость данных.
4. Несовместимость форматов файлов.
5. Фиксированный набор запросов, быстрое увеличение количества приложений.
1. Разделение и изоляция данных
Данные изолированы в отдельных файлах, доступ к ним затруднен. Например, для создания списка всех домов, отвечающих требованиям потенциальных арендаторов, предварительно нужно создать временный файл со списком арендаторов, желающих арендовать недвижимость типа «дом». Затем в соответствующих файлах следует осуществить поиск объектов недвижимости типа «дом» с арендной платой ниже установленного арендатором максимума. Выполнять подобную об- работку данных в файловых системах достаточно сложно. Для извлечения соответствующей поставленным условиям информации программист должен организовать синхронную обработку двух файлов. Трудности существенно возрастают, когда необходимо извлечь данные из более чем двух файлов.
2. Дублирование данных
Из-за децентрализованной работы с данными про- водимой в каждом отделе организации независимо от других отделов, в файловой системе фактически поощряется бесконтрольное дублирование данных, что, в принципе, неизбежно. Бесконтрольное дублирование данных нежелательно по двум причинам:
1) дублирование данных сопровождается неэкономным расходованием ресурсов. Во многих случаях дублирования данных можно избежать за счет совместного использования файлов;
2) дублирование данных может привести к нарушению их целостности, данные из разных файлов могут стать противоречивыми. Поскольку не существует ни- какого автоматического способа обновления данных одновременно и в нескольких файлах, подобные противоречия с какой-то вероятностью будут возникать.

3. Зависимость данных

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

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

4. Несовместимость форматов файлов

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

5. Фиксированный набор запросов, быстрое увеличение количества приложений

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

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

Все перечисленные ограничения файловых систем являются следствием двух факторов.

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

2. Помимо приложений не предусмотрено никаких других инструментов доступа к данным и их обработки.

ОБОБЩЕННАЯ МЕТОДИКА ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

Процесс разработки баз данных включает три фазы:
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

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

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

ПРАВИЛА РАСПРЕДЕЛЕННЫХ СУБД

Двенадцать правил (или целей) были сформулированы Дейтом для типичной РСУБД. Основой для построения всех этих правил является то, что распределенная СУБД должна восприниматься конечным пользователем точно так же, как и централизованная СУБД. Данные правила сходны с двенадцатью правилами Кодда для реляционных систем, представленными в [7].
Правило 1
Основной принцип. Локальная автономность
С точки зрения конечного пользователя распределенная система должна выглядеть в точности так, как и обычная, нераспределенная система.
Сайты в распределенной системе должны быть автономными. В данном контексте автономность означает следующее:
– локальные данные принадлежат локальным владельцам и сопровождаются локально;
– все локальные процессы остаются чисто локальными;
– все процессы на заданном сайте контролируются только этим сайтом.
Правило 2
Отсутствие опоры на центральный сайт
В системе не должно быть ни одного сайта, без которого система не сможет функционировать. Это означает, что в системе не должно существовать центральных серверов таких служб, как управление транзакциями, выявление взаимных блокировок, оптимизация запросов и управление глобальным системным каталогом.
Правило 3
Непрерывное функционирование
В идеале, в системе никогда не должна возникать потребность в плановом останове ее функционирования для выполнения таких операций, как:
– добавление или удаление сайта из системы;
– динамическое создание или удаление фрагментов из одного или нескольких сайтов.
Правило 4
Независимость от расположения
Независимость от расположения эквивалентна прозрачности расположения. Пользователь должен получать доступ к базе данных с любого из сайтов. Более того, пользователь должен получать доступ к любым данным так, как если бы они хранились на его сайте, независимо от того, где они физически сохраняются.
Правило 5
Независимость от фрагментации

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

Правило 6

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

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

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

Правило 7

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

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

Правило 8

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

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

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

Правило 9

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

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

Правило 10

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

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

Правило 11

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

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

Правило 12

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

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

ПРИМЕР ИНФОЛОГИЧЕСКОГО ПРОЕКТА БАЗЫ ДАННЫХ

В [5] приведен отличный («классический») пример построения инфологической модели базы данных «Питание», где должна храниться информация о блюдах (рис.П.4.1), их ежедневном потреблении, продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов. Информация предназначена для использования поваром и руководителем небольшого предприятия общественного питания, а также его посетителями.

1. Лобио по грузински Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки, рейган (базилик) и довести до готовности. Затем запечь в духовке. Фасоль стручковая (свежая или консервированная) 200, Лук зеленый 40, Масло сливочное 30, Зелень 10. Выход 210. Калорий 725.

Рис. П.4.1 Пример кулинарного рецепта
С помощью потенциальных пользователей выделены следующие объекты и характеристики проектируемой базы данных.
1. Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты: номер блюда (например, из книги кулинарных рецептов), название блюда, вид блюда (закуска, суп, горячее и т. п.), рецепт (технология приготовления блюда), выход (вес порции), название, калорийность и вес каждого продукта, входящего в блюдо.
2. Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.
3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.
Анализ объектов позволяет выделить:
– стержни Блюда, Продукты и Города;
– ассоциации Состав (связывает Блюда с Продуктами) и Поставки (связывает Поставщиков с Продуктами);
– обозначение Поставщики;
– характеристики Рецепты и Расход.
ER-диаграмма модели показана на рис. П.4.2 а модель на языке ЯИМ имеет следующий вид.
БЛЮДА (БЛ, Блюдо, Вид)
ПРОДУКТЫ (ПР, Продукт, Калорийность)
Поставщики (ПОС, Город, Поставщик) [ГородА]
Состав [Блюда М, Продукты N] (БЛ, IIP, Вес (г))
Поставки [Поставщики М, Продукты И] (ПЯС, ПР, Дата П, Цена, Вес (кг))
ГОРОДА (Город, Страна)
Рецепты (БЛ, Рецепт) {Блюда}
Расход (БЛ, Лата Р, Порций) {Блюда}
В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.

Рис. П.4.2. Инфологическая модель базы данных «Питание»

ПРИНЦИПЫ ОРГАНИЗАЦИИ КОМПЬЮТЕРНЫХ СЕТЕЙ

Компьютерная сеть – множество автономных компьютеров, соединенных между собой и способных обмениваться информацией [1]. Компьютерные сети представляют собой сложную и интенсивно развивающуюся область компьютерной индустрии, однако определенные знания в этой области совершенно необходимы для понимания принципов построения распределенных СУБД. За последних несколько десятилетий был пройден путь от использования полностью автономных отдельных компьютеров до современного состояния, когда сети компьютером, получили повсеместное распространение. Размеры компьютерных сетей варьируются от нескольких соединенных между собой персональных компьютеров до сетей глобального масштаба, насчитывающих тысячи машин и сотни тысяч пользователей. В нашем конкретном случае распределенные СУБД устанавливаются поверх компьютерной сети таким образом, что работа последней оказывается полностью скрыта от конечного пользователя.
Локальная вычислительная сеть (ЛВС) – совместное подключение нескольких компьютерных рабочих мест (рабочих станций) к единому каналу передачи данных.
ЛВС – географически ограниченная (территориально или производственно) аппаратно-программная реализация, в которой несколько компьютерных систем связанны друг с другом последовательностью соответствующих средств коммутации. Благодаря такому со
единению пользователь может взаимодействовать с другими рабочими местами, подключенными к этой ЛВС. Посредством ЛВС в систему объединяются ПК, расположенные на многих удаленных рабочих местах, которые используют совместное оборудование, программные средства и информацию. Преимущества сетевого объединения следующие [1].
1. Разделение ресурсов: позволяет экономично использовать ресурсы, управлять периферийными устройствами, такими как лазерные печатающие устройства, со всех присоединенных рабочих станций.
2. Разделение данных: предоставляет возможность доступа и управления БД с периферийных рабочих мест, нуждающихся в информации.
3. Разделение программных средств: предоставляет возможность одновременного использования централизованных, ранее установленных программных средств.

4. Разделение ресурсов процессора: дает возможность использовать вычислительные мощности для обработки данных двумя системами, входящими в сеть. Эта возможность заключается в том, что на имеющиеся ресурсы не «набрасываются» моментально, а только лишь через специальный процессор, доступный каждой станции.

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

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

Отличие ЛВС от систем на основе мини-ЭВМ

Основными структурами в используемых ЛВС считаются ВС с расположенной в центре мини-ЭВМ. Однако более перспективны ВС на основе ПК. Объясняется это следующим [1].

1. Система с мини-ЭВМ располагает одним процессорным устройством. производительность такой системы определяется при проектировании. Дополнительно увеличить производительность очень дорого.

2. К мини-ЭВМ подключают терминалы, являющиеся «глупыми» рабочими местами. Поэтому необходимо распределить вычислительные мощности между такими рабочими местами.

3. Локальные терминалы в такой системе зависят от центрального процессора и применяемого программного обеспечения.

4. Локальные рабочие места в ЛВС обладают собственным интеллектом. Это увеличивает производительность вычислительной сети. Производительность возрастает при подключении к системе новых РМ и наоборот.

5. Локальные РМ обладают и собственными внешними носителями данных. Поэтому облегчается внешний обмен данными.

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

7. ЛВС просто и недорого соединяется с другим ЛВС.

8. Для ПК существует необозримое множество приложений ПО и аппаратных решений (самые гибкие системы).


9. Производительность ПК сравнима с производительностью мини-ЭВМ. В ЛВС аккумулируется производительность всех присоединенных ПК.

10. ПК, подключенный как РМ в системе с ЦП не использует свои «интеллектуальные» возможности. Из-за этого теряются вычислительные мощности РМ, и в особенности, возможность передачи данных между ПК РМ и централизованными накопителями данных – файловыми серверами.

При использовании ЛВС, можно утверждать, что прикладные программы практически не влияют на; эффективность функционирования системы в целом. Обработка выполняется в рабочей станции на локальном уровне и не зависит от производительности ЦП сервера. Многотерминальная система с небольшим количеством РМ является более быстродействующей и производительной по сравнению с ЛВС.

Топология ВС

Под топологией ВС понимают конфигурацию физических соединений компонентов ВС.

Тип топологии определяет производительность и надежность сети РМ, для которой имеет значение время обращения к серверу.

1. Топология типа «звезда»

Вся информация между двумя РМ проходит через центральный узел ВС (рис. П.6.1). Пропускная способность сети определяется вычислительной мощностью узла и гарантируется для каждой рабочей станции. Коллизий (столкновений) данных не возникает. Кабельное соединение простое. Затраты на прокладку высокие. Расширение дорогое. Является наиболее быстродействующей. Частота запросов передачи информации от одной станции к другой невысокая.



Рис. П.6.1. Топология типа «звезда»

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

2. Кольцо

Коммуникационная связь замыкается в кольцо (рис.П.6.2). Прокладка может быть дорогой. Пересылка очень эффективна. Продолжительность передачи информации пропорциональна количеству РМ.



Рис. П.6.2. Топология типа «кольцо»

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


Неисправности локализируются легко.

Подключение нового РМ требует кратковременного отключения сети. Ограничения на протяженность не существуют, так как определяется расстоянием между .соседними РМ.

Специальной формой кольцевой топологии является логическая кольцевая сеть (рис. П.6.3). Физически это соединение звездных топологий. Отдельные звезды включаются специальными коммутаторами (концентраторами).

Активные концентраторы (АК) содержат усилители для подключения от 4-х до 16-ти РМ.

Пассивные концентраторы (ПК) – разветвительное устройство (mах – 3 РМ).



Рис. П.6.3. Топология типа «логическое кольцо»

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

3. Шинная топология

При данной топологии среда передачи информации представляется в форме коммуникационного пути, доступного для всех РМ, к которым они все должны быть подключены (рис.П.6.4). Все РМ могут вступить в контакт с любым РМ, имеющимся в сети.



Рис. П.6.4. Топология типа «шина»

РМ в любое время, без прерывания работы всей ВС, могут быть подключены к ней или отключены. Функционирование ВС не зависит от состояния отдельной РМ. Очень легко прослушивать информацию. В ЛВС с прямой (немодулированной) передачей данных всегда может существовать только одна передающая станция. В ЛВС с модулируемой широкополосной передачей каждой станции присваивается своя частота, на которой они принимают и отправляют информацию. Одновременно транспортируется большой объем информации.

4. Древовидная структура ЛВС

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


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



Рис. П.6.5. Древовидная структура

Объединение ВС

Классификация региональных соединений следующая[1].

GAN - глобальная сеть, общепланетное соединение ВС.

WAN – широкомасштабная, континентальное на уровне государства объединение ВС.

MAN – междугородная сеть, междугороднее и областное объединение сетей.

LAN (ЛВС) -локальная, функционирует в пределах нескольких зданий, территории предприятия.

Соединение ВС будет лишь тогда гибким и широко используемым, если различные системы, которые в обычных условиях не могут взаимодействовать (Macintosh и MS-DOS) находят взаимопонимание посредством пересылки информации друг другу.

Объединение таких ВС осуществляется через мосты (bridges) или межсетевые шлюзы (gateways).

Скорость передачи данных в глобальных сетях обычно находится в пределах от 2 до 2000 Убит/с. Скорость передачи данных в локальных сетях намного больше и составляет от 10 до 100 Мбит/с, а надежность установленных соединений существенно выше. Очевидно, что распределенные системы, построенные на основе локальных сетей, будут обеспечивать меньшее время реакции' системы, чем системы, использующие глобальные сети.

Если классифицировать сети на основе метода выбора пути (или маршрутизации), то их можно разделить на широковещательные и одноадресные.

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

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

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

Таблица П.6.1

Глобальные сети	Локальные сети
Удаленность узлов до тысяч километров	Удаленность узлов до нескольких километров
Связывают автономные компьютеры	Связывает компьютеры, совместно использующие распределенные приложения
Сеть управляется независимой организацией (используются телефонные или спутниковые каналы связи)	Сеть управляется ее пользователями (используются собственные кабельные соединения)
Скорость передачи данных до 2 Мбит/с (линии T1) или до 45 Мбит/с (линии T3)	Скорость передачи данных до 100 Мбит/с
Сложные протоколы	Более простые протоколы
Используется одноадресная маршрутизация	Используется широковещательная маршрутизация
Используется нерегулярная топология	Используется топология шины или звезды
Вероятность ошибки порядка 1:105	Вероятность ошибки порядка 1:109

<


Международная организация стандартов (ISO) установила набор правил (или протоколов), регламентирующих способы взаимодействия систем [7]. Выбранный подход состоит в разделении сетевого аппаратного и программного обеспечения на несколько уровней, каждый из которых предоставляет определенные услуги расположенным выше уровням, одновременно скрывая от них все подробности реализации нижних уровней. Протокол, получивший название «модель OSI» (Open System Interconnection), предусматривает использование семи уровней, логически не зависящих от изготовителя оборудования или программ. Отдельные уровни отвечают за передачу последовательностей битов информации по сети, за установку соединений и

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

Уровень 1: физический – битовые протоколы передачи информации.

Уровень 2: канальный – формирование кадров, управление доступом к среде.

Уровень 3: сетевой – маршрутизация, управление потоком данных.

Уровень 4: транспортный – обеспечение взаимодействия удаленных процессов.

Уровень 5: сеансовый – поддержка, диалога между удаленными процессами.

Уровень 6: представления данных – интерпретация передаваемых данных.

Уровень 7: прикладной – пользовательское управление данными.

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

Так как пользователи нуждаются в эффективном управлении, система вычислительной сети представляется как комплексное строение, которое координирует взаимодействие задач пользователей.

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


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

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

Уровень 1. Физический

На этом уровне определяются электрические,, механические, функциональные и процедурные параметры для физической связи в системах. Физическая связь и неразрывная с ней эксплуатационная готовность являются основной функцией 1-го уровня.

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

Уровень 2. Канальный

Канальный уровень формирует из данных, передаваемых 1-ым уровнем, так называемые «кадры» или последовательности кадров. На этом уровне осуществляется управление доступом к передающей среде, используемой несколькими ЭВМ, синхронизация, обнаружение и исправление ошибок.

Уровень 3. Сетевой

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

Уровень 4. Транспортный

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

Уровень 5. Сеансовый

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


Уровень 6. Представления данных

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

Уровень 7. Прикладной

На этом уровне необходимо предоставить в распоряжение пользователей уже переработанную информацию. С этим может справиться системное и пользовательское прикладное программное обеспечение. Для передачи информации по коммутационным ЛС данные преобразуются в цепочку друг за другом следующих битов («0» и «1»).

Передаваемые знаки представляются с помощью битовых комбинаций. Битовые комбинации располагают в определенной кодовой таблице, содержащей 4-х, 5-и, 6-и, 7-и или 8-и битовые коды.

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

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

Протокол передачи данных требует определения следующих аспектов обмена информацией [1].

1. Синхронизация – механизм распознавания начала блока данных и его конца.

2. Инициализация – установление соединения между взаимодействующими процессами.

3. Блокирование – разбиение передаваемой информации на блоки данных строго определенной длины.

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

5. Обнаружение ошибок – установка битов четности и вычисление контрольных битов.

6. Нумерация блоков – позволяет установить ошибочно передаваемую или терявшуюся информацию.


7. Управление потоком данных – для распределения и синхронизации информационных потоков. Так, например, если не хватает места в буфере устройства данных или данные недостаточно быстро обрабатываются в периферийных устройствах (например, принтерах), сообщения и/или запросы накапливаются.

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

9. Разрешение доступа – для распределения, контроля и управления разграничением доступа к данным. Вменяется в обязанность пункта разрешения доступа.

Международный консультативный комитет по телеграфии и телефонии (CCITT) разработал стандарт, получивший название Х.25 и охватывающий три нижних уровня описанной выше модели. Большинство распределенных СУБД было разработано с целью использования поверх протокола Х.25. Однако позже были выпущены новые стандарты, охватывающие более высокие уровни модели и способные предоставить СУРБД полезные дополнительные функциональные возможности. К ним можно отнести протоколы RDA (Remote Database Access – ISO, 9579) и DTP (Distribution Transaction Processing – IS0, 10026).

Время передачи

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

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

Задачей СУРБД является минимизация как времени передачи данных по сети, так и сокращение количества передач данных.

СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА ДАТАЛОГИЧЕСКИХ МОДЕЛЕЙ

Сетевая модель данных
– Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.
– Поддержание бинарных связей и связей более высоких степеней типа М:N с помощью декомпозиции.
– Поддерживает рекурсивные связи с помощью декомпозиции.
– Типы записи непосредственно связаны друг с другом с помощью конструкции «тип набора».
– Целостность на уровне ссылок поддерживается за счёт конструкций «тип набора».
– Обладает ограниченной гибкостью по отношению к изменению требований к данным и методам доступа.
– Доступ к типам записей осуществляется путем «перемещения» (навигации) по структуре. В зависимости от конкретного расположения типа записи по отношению к начальной точке в структуре, для доступа к данным могут использоваться различные специальные команды.
Иерархическая модель данных
– Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.
– Бинарные связи более высоких степеней типа М:N поддерживаются только с помощью декомпозиции и дублирования данных в разных иерархиях.
– Рекурсивные связи поддерживаются только с помощью декомпозиции и дублирования данных.
– Типы записей непосредственно связаны между собой с помощью иерархической структуры.
– Целостность на уровне ссылок поддерживается в тех случаях, когда зависимый дочерний тип записи полностью участвует в связи со своим родительским типом записи.
– Не обладает гибкостью по отношению к изменению требований к данным и методам доступа.
– Доступ к типам записей осуществляется путем «перемещения» (навигации) от корневого типа записи к типам записи более низкого уровня в данной иерархии при ее прямом или обратном обходе.

Реляционная модель данных

– Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М, а также рекурсивные связи типа 1:1 и 1:М.

– Бинарные связи более высоких степеней типа М:N поддерживаются с помощью декомпозиции.

– Рекурсивные связи типа М:N поддерживаются с помощью декомпозиции и Типы записей связанны друг с другом символически с помощью конструкции «первичный/внешний ключ».

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

– Обладает гибкостью по отношению к изменению требований к данным и методам доступа

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

Сводная характеристика систем баз данных

Критерий	CODASYL (сетевая система)	IMS (иерархическая система)	Реляционная система
Период создания	1960-1970 годы	1960-1970 годы	1960-настоящее время
Над чем ведется работа сейчас	Разделение физических и логических концепций	Обеспечение взаимодействия с другими системами и типами СУБД	Повышение производительности, обеспечение совместимости с SQL2, а также добавление объектно-ориентированных компонентов
Реализация	Записи и указатели	Обычно записи и указатели, но могут быть и просто физически смежные записи	Записи со значениями, которые могут использоваться как логические указатели
Базовая физическая структура данных	Сеть, в которой записи связаны друг с другом в один набор с помощью указателей. Могут содержать встроенные в них указатели	Обобщенная древовидная структура, в которой один тип записи образует корень, а все другие типы записей - зависимые от корня узлы	Двумерная таблица
Общая структура файлов и методы доступа к ним	Прямые методы доступа и индексно-последовательные методы доступа (включая метод VSAM)	Методы доступа HIDAM, HDAM, HISAM, HSA М. Варианты прямого доступа и индексно-последователь-ных методов доступа (включая метод VSAM)	Разные методы доступа от последовательных файлов с индексами и методов прямого доступа вплоть до сложных древовидных поисковых структур
Логическая структура данных	Набор, в котором один тип записи-владельца может быть связан со многими типами записей-членов. Сложные сети создаются с помощью типов наборов	Обобщенная древовидная структура	Набор двумерных таблиц
Поддерживаемые типы связей	Связи типа 1:1 и 1:М.Связи типа M:N и рекурсивные связи поддерживаются с помощью декомпозиции. С ними проще всего работать в иерархической системе	Связи типа 1:1и 1:М. Связи типа M:N обычно поддерживаются с помощью логических указателей, которые связывают разные физические структуры данных. Рекурсивные связи поддерживаются с помощью декомпозиции и дублирования	Связи типа 1:1 и 1:М.Связи типа M:N и рекурсивные поддерживаются с помощью декомпозиции
Поддержка целостности на уровне ссылок для связей типа «родитель-потомок»	Обеспечивается средствами СУБД с использованием правил вставки и сохранения для структуры наборов. Если записи-члены закреплены за записью-владельцем, то удаление записи-владельца приводит к каскадному удалению записей-членов. Если записи-члены не обязательно являются частью набора, то удаление записи-владельца эквивалентно заданию неопределенной связи (NULL). Можно запрограммировать и другие варианты действий. Обычно внешние ключи в типах записей не требуются	Обеспечивается средствами СУБД с использованием зависимостей в древовидной структуре. То есть при удалении корня дерева (или поддерева)будут удалены все зависящие от него узлы, что эквивалентно каскадному удалению. Обычно в типах записей внешние ключи не нужны. Сложности могут возникнуть в случаях,когда связи M:N представляются с помощью логических указателей	Поддержка варьируется от разработки процедур, правил или триггеров, используемых непосредственно средствами СУБД, вплоть до процедур, реализуемых в прикладных программах. Стандарт SQL92 требует реализации этой функции механизмами самой СУБД
Логическая независимость от данных	Концептуальная схема моет быть расширена без изменения подсхем. При перестройке или удалении из концептуальной схемы типов записи, поля набора потребуется ввести поправки только в те представления, в которых они используются	Полностью аналогична CODASYL-системам	Полностью аналогична CODASYL-системам
Физическая независимость от данных	Концептуальная схема должна быть изменена в соответствии с изменениями структуры хранения в тех местах схемы, в которых описаны детали физического хранения. Это может вызвать необходимость изменения прикладных программ. Следовательно, реализация макета базы данных может значительно усложниться	При изменении структуры хранения может потребоваться изменить концептуальную схему (ОБД) и внести поправку в логику обработки данных в приложениях. Для упрощения процесса изменения структур хранения предусмотрены специальные утилиты	В тех случаях когда не допускается выбор из нескольких возможных физических структур данных, некоторые СУБД при необходимости позволяют определять различные структуры файлов и вторичных индексов
Гибкость при изменении приложений	Новые или изменённые приложения могут не обладать достаточной производительностью, потому что база данных структурирована для существовавших ранее приложений. Поэтому может оказаться не возможным эффектно поддерживать все требуемые приложения	Новые или изменённые приложения могут быть неэффективны, потому что базовые структуры подогнаны под исходные приложения. Изменить базовую структуру так, чтобы обеспечить удовлетворительную работу базы данных со всеми требуемыми приложениями,достаточно сложно или даже вообще не возможно. Вероятно, для этого потребуется создать дополнительные структуры	Настройка для работы с новыми или изменёнными приложениями может быть выполнена без особых затруднений. В СУБД, "" поддерживающей выбор структуры файлов,для разных таблиц могут быть выбраны самые подходящие структуры данных
Простота проектирования	Вероятно, потребуется квалифицированная помощь, особенно при определении необходимых структур данных и при разработке связанных с ними прикладных программ	Проектирование могут выполнить только опытные специалисты-эксперты	Большинство пользователей (включая конечных пользователей) легко поймут логическую структуру данных,а потому смогут спроектировать базу данных и отобразить её на физические структуры. К сожалению, недостаточное знание методов проектирования баз данных может привести к созданию слабых, неэффективных и негибких макетов
Доступ к базе данных	Стандартные методы доступа посредством API: приложение содержит встроенные вызовы процедур для работы с СУБД, команды обрабатывают записи последовательно, по одной, хотя потенциально они могут оказывать влияние и на другие записи. Дополнительные программные конструкции необходимы для навигации по базе данных и обработки наборов записей	Здесь также доступ осуществляется исключительно посредством API. Команды обрабатывают записи по одной, но при этом они могут влиять и на зависимые записи. Благодаря использованию специальных команд навигации по базе данных пользователь может перемещаться к разным местам иерархической структуры. Для обработки наборов записей могут потребоваться специальные программные конструкции	Доступ может варьироваться от использования API до таких интерактивных языков, как SQL или QBE. Языки запросов позволяют конечным пользователям опрашивать базу данных в произвольной манере. Кроме того, SQL-команды могут внедряться в прикладные программы
Стандарты	Для CODASYL-совместимой модели данных существует набор стандартных концепций,хотя между разными реализациями есть некоторые различия	Для иерархической модели данных не существует строгого набора стандартных концепций, а реализации этой модели не соответствуют какому-либо особому стандарту	Для реляционных моделей данных существует набор стандартных концепций, хотя между разными реализациями есть некоторые различия

Проблемы ER-моделирования

В процессе создания инфологической модели на языке ER-диаграмм, могут возникать нежелательные ситуации, которые в литературе называются ловушками соединения. Причины этих проблем кроются в неправильной интерпретации семантики предметной области, в том числе смысла некоторых связей между выделенными сущностями. Очень важно своевременно выявлять в модели данных ловушки соединения, иначе • они могут привести к неадекватному описанию пред-, меткой области и необходимости перестройки всей концептуальной модели [7].
Наиболее распространенными являются два вида

ловушек соединения:
– ловушки разветвления;
– ловушки разрыва.
Ловушка разветвления имеет место в том случае, если модель отображает связь между сущностями, но путь между отдельными экземплярами этих сущностей однозначно не определяется.
Ловушка разветвления возникает в случае, когда две или больше связей ОДИН-КО-МНОГИМ разветвляются из одной сущности. Потенциальная ловушка разветвления показана на рис. 2.11, где две связи типа 1:М выходят из одной и той же сущности ФАКУЛЬТЕТ. Проанализировав модель, можно сделать вывод, что на одном факультете осуществляется обучение по нескольким специальностям, и на факультете учится множество студентов. Проблема может возникнуть при попытке выяснить, по какой специальности обучается каждый из студентов факультета.

Рис. 2.11. Пример ловушки разветвления
Для обнаружения этой проблемы удобно пользоваться семантическими сетями – (рис, 2.12). С помощью семантической сетевой модели на конкретном примере невозможно дать однозначный ответ на вопрос: «По какой специальности обучается студент Гаврюхов?» -это ловушка разветвления» Эта неприятность произошла из-за неправильной трактовки связей между сущностями ФАКУЛЬТЕТ, СПЕЦИАЛЬНОСТЬ, СТУДЕНТ. Устранить такой дефект можно только путем перестройки исходной модели.

Рис. 2.12. Семантическая сеть ER-модели с ловушкой разветвления
Результат адекватного преобразования модели представлен на рис. 2.13.
В таком варианте легко определяется, что студент Гаврюхов учится на экономическом факультете по специальности «Налоговая работа и аудиторский контроль».



Рис. 2.13. Преобразованная ER-модель

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



Рис. 2.14. Семантическая сеть преобразованной ER-моделт

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

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

На рис. 2.15 потенциальная ловушка разрыва показана на примере связей между сущностями ОБЩЕЖИТИЕ, СТУДЕНТ и КОМНАТА.



Рис. 2.15. Пример ловушки-разрыва

С помощью семантической сети ER-модели с рис. 2.15 (представлена на рис. 2.16), невозможно дать ответ на вопрос: «В каком общежитии находится комната под условным номером 703?». Это причина проявления ловушки разрыва, возникающей из-за неправильной интерпретации связей между сущностями ОБЩЕЖИТИЕ, СТУДЕНТ и КОМНАТА.



Рис. 2.16. Преобразованная ER-модель

Устранить эту проблему можно только путем перестройки ER-модели для представления правильного взаимоотношения между этими сущностями. Преобразованная ЕR-модель показана на рис. 2.17. В модель добавлена связь Размещение между сущностями ОБЩЕЖИТИЕ и КОМНАТА.



Рис. 2.17. Семантическая сеть ER-модели с ловушкой разрыва

Если исследовать новую структуру на уровне отдельных сущностей (как показано на рис. 2.18), то можно дать ответ на поставленный вопрос: «Комната с условным номером 703 находится в общежитии №1».



Рис. 2.18. Семантическая сеть преобразованной ER-модели

Прозрачность использования

Прозрачность использования СУБД позволяет скрыть от пользователя тот факт, что на разных сайтах могут функционировать различные локальные СУБД. Данный тип прозрачности является самым сложным, и применим только для гетерогенных распределенных систем.
Таким образом, концепция прозрачности не может быть отнесена к типу «все или ничего, так как может быть организована на нескольких различных уровнях. Каждый из уровней подразумевает определенный на- бор соглашений между сайтами системы. Так, при полной прозрачности сайты должны следовать общему соглашению по вопросам модели данных, интерпретации схем, представления данных и т.п. В непрозрачных системах единственным соглашением является формат обмена данными и набор функциональных возможностей, предоставляемых каждым сайтом в системе.
С точки зрения конечного пользователя полная прозрачность желательна. Но с точки зрения АБД локальной базы полностью прозрачный доступ связан с трудностями осуществления контроля. Традиционный способ работы с представлениями, используемый для построения защитного механизма, в такой ситуации может оказаться неэффективным. Например, механизм работы с представлениями языка SQL позволяет ограничивать доступ к базовым таблицам или подмножеству данных базовой таблицы и разрешать его только конкретным пользователям. Однако он не позволяет также легко ограничивать доступ к данным на основе набора критериев, отличных от имени пользователя.
Проще обеспечить подобный тип функциональности с помощью процедур, которые будут запускаться удаленным пользователем. В этом случае локальной пользователи смогут работать с данными так же, как они работали прежде, при использовании стандартного механизма защиты СУБД. Однако удаленные пользователи смогут получать только такой тип доступа в данным, который реализован в предоставленном  наборе процедур, подобно тому, как это делается в объектно-ориентированных системах. Подобный тип федеральной архитектуры реализовать проще, чем обеспечить полную прозрачность системы, к тому же он предоставляет более высокий уровень локальной автономности.
В приложении 7 сведены правила, при выполнении которых СУБД может считаться распределенной.

Прозрачность распределенности

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

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

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

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

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

– утрата определенной части локальной автономии;

– появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);

– снижение доступности – если центральный сайт по какой-    либо причине станет недоступным, все остальные сайты системы не смогут создавать никаких новых объектов базы данных [7].

Альтернативное решение состоит в использовании префиксов, помещаемых в имена объектов в качестве идентификатора сайта, создавшего этот объект

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

Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных [7]. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.

Прозрачность транзакций

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

Если существует большое количество копий данных, .то вероятность успешного завершения транзакции уменьшается в экспоненциальной зависимости от их числа. Альтернативной стратегией является ограничение распространения сведений об изменении только теми сайтами, которые в данный момент доступны. На остальные сайты сведения об изменении поступят, как только они вновь станут доступными.

Дополнительной стратегией могла бы быть выдача разрешения обновлять копии асинхронно, через некоторое время после внесения исходного обновления. За- держка в восстановлении целостности может варьироваться от нескольких секунд до нескольких часов [7].

Любая централизованная СУБД должна включать механизм восстановления, который в подверженной различным сбоям и отказам среде будет гарантировать атомарность выполнения транзакций – либо все операции транзакции будут завершены, либо ни одна из них. Если транзакция выполнена, внесенные ею изменения приобретают длительный характер. Среди отказов централизованных СУБД выделяют: сбои системы, отказ носителей, ошибки в программах, небрежность персонала, стихийные бедствия и действия злоумышленников. В распределенных СУБД необходимо дополнительно учитывать следующее:

– возможность потери сообщения;

– возможность отказа линии связи;

– аварийный останов одного из сайтов;

– расчленение сетевых соединений.

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

Прозрачность выполнения

Прозрачность выполнения требует, чтобы работа в среде СУРБД выполнялась аналогично работе в централизованной СУБД. В распределенной среде не должно быть видно снижение производительности из-за наличия медленных сетевых соединений и т.д. Прозрачность выполнения требует также, чтобы СУРБД могла находить наиболее эффективные стратегии выполнения запросов.
В централизованной СУБД обработчик запросов оценивает каждый запрос на доступ к данным и находит оптимальную стратегию его выполнения в виде упорядоченной последовательности операций с базой данных. В распределенной среде обработчик запросов отображает запрос на доступ к данным в упорядоченную последовательность операций с локальными базами данных. При этом дополнительная сложность возникает из-за необходимости учитывать наличие фрагментации, репликации и определенной схемы размещения данных.
Обработчик распределенных запросов должен знать:
– к какому фрагменту следует обратиться;
– какую копию фрагмента использовать, если его данные реплицируются;
– какое из местоположении должно использоваться [7].
Обработчик распределенных запросов вырабатывает стратегию выполнения, которая является оптимальной с точки зрения некоторой стоимостной функции. Обычно используются следующие показатели:
– время доступа, включающее физический доступ к данным на диске;
– время работы центрального процессора, затрачиваемое на обработку данных в первичной памяти;
– время, необходимое для передачи данных по сетевым соединениям.
Первые два фактора аналогичны тем, которые учитываются в централизованных системах для оптимизации выполнения запросов. Но в СУРБД доминирующую роль играет время передачи данных по сетевым соединениям, что особенно актуально для глобальных сетей. Скорость передачи в таких каналах может составлять лишь несколько Кбайт в секунду. В подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и использование ЦП. Однако некоторые сетевые соединения имеют скорость пере- дачи данных, сравнимую со скоростью доступа к дискам (в локальных сетях). В этом случае целесообразно учитывать все три указанных показателя.

Распределение данных

Существуют четыре альтернативные стратегии размещения данных в системе
[7]:
1) централизованное;
2) раздельное (фрагментированное);
3) размещение с полной репликацией;
4) размещение с выборочной репликацией.
Централизованное размещение
Данная стратегия предусматривает создание на одном из сайтов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети («распределенная обработка»). В этом случае локальность ссылок минимальна для всех сайтов, за исключением центрального, поскольку для получения любого доступа к данным требуется установка сетевого соединения. Соответственно уровень затрат на передачу данных будет высок. Уровень надежности и доступности в системе низок, поскольку отказ на центральном сайте вызовет паралич работы всей системы.
Раздельное (фрагментированное) размещение
В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из сайтов системы. Если элемент данных будет размещен на том сайте, на котором он чаще всего используется, полученный уровень локальности ссылок будет высок. При отсутствии репликации стоимость хранения данных будет минимальна, но при этом будет невысок также уровень надежности и доступности данных в системе. Однако он будет выше, чем в предыдущем варианте, поскольку отказ на любом из сайтов вызовет утрату доступа только к той части данных, которая на нем хранилась. При правильно выбранном способе распределения данных уровень производительности в системе будет относительно высоким, а уровень затрат на передачу данных – низким.
Размещение с полной репликацией
Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из сайтов системы. Следовательно, локальность ссылок, надежность и доступность данных, а также уровень производительности системы будут максимальны. Однако стоимость устройств хранения данных и уровень затрат на передачу данных в этом случае также будут самыми высокими.
Для преодоления части этих проблем в некоторых случаях используется технология моментальных снимков. Моментальный снимок представляет собой копию базы данных в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени – например, один раз в час или в неделю, – а потому они не всегда будут актуальными в текущий момент. Иногда в распределенных системах моментальные снимки используются для реализации представлений, что позволяет улучшить время выполнения в базе данных операций с представлениями.

Размещение с выборочной репликацией

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

Сводные характеристики всех рассмотренных выше стратегий приведены в табл. 5.2.

Таблица 5.2

	Локальность ссылок	Надежность и доступность	Производительность	Стоимость устройств хранения данных	Затраты на передачу
Централизованное	Самая низкая	Самая низкая	Неудовлетворительная	Самая низкая	Самая высокая
Фрагментированное	Высокая	Низкая для отдельных элементов; высокая для системы в целом	Удовлетворительная	Самая низкая	Низкая
Полная репликация	Самая высокая	Самая высокая	Хорошая для операций чтения	Самая высокая	Высокая для операций обновления, низкая для операций чтения
Выборочная репликация	Высокая	Низкая для отдельных элементов; высокая для системы	Удовлетворительная	Средняя	Низкая

Разделение функций администрирования

В некоторых очень сложных предметных областях функции администрирования автоматизированной информационной системы могут быть распределены между администратором данных (АД) и администратором базы данных (АБД).
Специфика обязанностей АД и АБД на этапах жиз-ненного цикла автоматизированной информационной системы представлена в табл. 1.2 [7].
Таблица 1.2

Этап		Основная роль		Вспомогательная роль
Планирование разработки базы данных		АД		АБД
Определение требований к системе		АД		АБД
Сбор и анализ требований пользователей		АД		АБД
Концептуальное проектирование базы данных		АД		АБД
Выбор целевой СУБД		АБД		АД
Логическое проектирование базы данных		АБД		АД
Разработка приложений		АБД		АД
Физическое  проектирование базы данных		АБД		АД
Создание прототипов		АБД		АД
Реализация		АБД		АД
Конвертирование и первичная загрузка данных		АБД		АД
Тестирование		АБД		АД
Эксплуатация и сопровождение		АБД		АД

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

– Взаимодействие с АБД и разработчиками приложений.

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

– Постоянная модернизация используемых информационных систем и технологий.

– Обеспечение полноты всей требуемой документации.

– Поддержка словаря данных.

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

Деятельность АДБ по сравнению с АД является в большей мере технической. Основные задачи администратора БД при наличии АД следующие [7].

– Оценка и выбор целевой СУБД.

– Логическое и физическое проектирование базы данных.

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

– Определение требований защиты и поддержки целостности данных.

– Взаимодействие с разработчиками приложений баз данных.

– Разработка стратегии тестирования.

– Обучение пользователей.

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

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

– Регулярное резервное копирование.

– Разработка требуемых механизмов и процедур восстановления.

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


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

Результаты сравнительного анализа задач администрирования данных и администрирования базы данных представлены в табл. 1.3 [7], из которой видно, что работа АД является в большей степени управленческой, а работа АБД - технической.

Таблица 1.3

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

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

В главе 2 была приведена методология концептуального и логического проектирования централизованных реляционных баз данных. В данном разделе рассматриваются следующие дополнительные факторы, которые должны приниматься во внимание при разработке распределенных реляционных баз данных [7].
– Фрагментация.
Любое отношение может быть разделено на некоторое количество частей, называемых фрагментами, которые затем распределяются по различным сайгам. Существуют два основных типа фрагментов: горизонтальные и вертикальные.
Горизонтальные фрагменты представляют собой подмножества кортежей, а вертикальные – подмножества атрибутов.
– Распределение.
Каждый фрагмент сохраняется на сайте, выбранном с учетом «оптимальной» схемы их размещения.
– Репликация.
СУРБД может поддерживать актуальную копию некоторого фрагмента на нескольких различных сайтах.
Определение и размещение фрагментов должно проводиться с учетом особенностей использования базы данных. Это подразумевает выполнение анализа приложений. Как правило, провести анализ всех приложений не представляется возможным, поэтому следует сосредоточить усилия на самых важных из них.
Проектирование должно выполняться на основе как количественных, так и качественных показателей. Количественная информация используется в качестве основы для распределения, тогда как качественная служит базой при создании схемы фрагментации. Количественная информация включает такие показатели:
– частота запуска приложения на выполнение;
– сайт, на котором запускается приложение;
– требования к производительности транзакций и
приложений.
Качественная информация может включать перечень выполняемых в приложении транзакций, используемые отношения, атрибуты и кортежи, к которым осуществляется доступ, тип доступа (чтение или запись), предикаты, используемые в операциях чтения.

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

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

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

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

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

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

Реляционная алгебра

В этом разделе на ряде примеров рассматриваются операции реляционной алгебры [11]. Для представления каждой операции будем использовать терминологию как алгебры, так и исчисления. Последняя базируется на системе понятий, использованной Коддом. Пять операций являются основными:
– проекция;
– объединение;
– разность;
– декартово произведение;
– селекция.
Другие часто используемые операции пересечения, соединения и деления можно выразить через пять основных операций. Ниже представлены отношения, используемые в примерах [11].

P(D 1		D2,		D3)		Q(D4		D5)		R(M,		P,		Q,		T)		S(A,		B)
1		11		x		x		1		x		101		5		a		5		a
2		11		у		x		2		y		105		3		a		10		b
3		11		z		y		1		z		500		9		a		15		c
4		12		x						w		50		1		b		2		d
										w		10		2		b		6		a
										w		300		4		b		1		b

Описание каждого отношения состоит из имени отношения, за которым в круглых скобках следует список атрибутов (это описание называется интенсионалом или схемой отношения). Под описанием приведено некоторое заполнение кортежей отношения (экстенсинал отношения). В последующих примерах буквы R и S
используются для обозначения отношений, а буквы A и B – для обозначения списка атрибутов (для простоты можно считать, что список состоит из единственного атрибута).
Проекция

Алгебра		Исчисление
R[A]		{t[A] t ?R}

Операция проекции представляет собой выборку из каждого кортежа отношения значений атрибутов, входящих в A, и удаление из полученного отношения повторяющихся строк. В исчислении t обозначает «кортежную» переменную, значениями которой являются кортежи исходного отношения R, a t[A] – часть кортежа R с атрибутами из A.
В соответствии с определением отношения неявно предполагается удаление дубликатов кортежей результирующего отношения.

Пример



Объединение

Алгебра	Исчисление
R S	{t| t ?R  ?t ?S}

Для того чтобы объединение было возможным, отношения-операнды (R и S) должны быть совместимы по объединению, т.е. их атрибуты должны быть определены над совместными данными.

Пример



Разность

Алгебра	Исчисление
R –S	{t| t ?R  ?t ?S}

Пример



Декартово произведение

Алгебра	Исчисление
R  S	{(r||s) | r ?R  ?r ?S}

Из обозначений видно, что операция декартова произведения осуществляется между кортежами отношений-аргументов, а результатом является конкатенация (обозначаемая ||) соответствующих кортежей. При этом

Степень(RS)= Степень(R)+Степень(S),

Мощность(RS)= Мощность(R)× Мощность(S).

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

RA=R[M,T] и RB=R[Q,T]S,

т.е.



Тогда



Степень результирующего отношения равна 4(2+2), а мощность – 8 (2×4).

Селекция (Ограничение)

Алгебра	Исчисление
(a) R[A?v]	{t| t ?R  ?(t[A]?v)}
(б) R[A?B]	{t| t ?R  ?(t[A]?t[B])}

В приведенном определении v обозначает константу, а В – атрибут отношения R, отличный от А. Символ ?

используется для обозначения одной из операций сравнения (<, ?, =, ?, ?, >).

Примеры

P[D1>D2]=Ø (пустое множество) поскольку в отношении отсутствуют кортежи, где D1>D2.



Пересечение

Алгебра	Исчисление
R S	{t| t ?R  ?t ?S}

Пересечение RS=R-(R-S), что соответствует области, отмеченной звездочкой на диаграмме Венна для операции разности.

Пример



Соединение

Алгебра	Исчисление
R[A?B]S	{(r||s) | r ?R  ?s ?S ?(r[A]?s[B])}

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


Имеется несколько вариантов операции соединения:

а) тета- и эквисоединение. При этой операции A и B являются совместимыми атрибутами соединения, а степень результирующего отношения равна сумме степеней отношений-операндов. Такое соединение называется ?-соединением (тета-соединением). В случае сравнения на равенство соединение называется экви-соединение;

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

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

Примеры

Тета-соединение R[Q>A]S

При выполнении соединения необходимо для каждого кортежа из R взять значение атрибута Q и сравнить его со значением атрибута A из каждого кортежа S. В результате получим



Следует отметить, что кортеж отношения R не вошел в результирующее отношение.

Естественное соединение P[D3 =D4]Q



Деление

Алгебра	Исчисление
R[A÷B]S	{r[] | r ?R  ?s ?S[B]gR(r[])}

Атрибуты A и

B являются совместимыми и/или общими атрибутами деления. Для упрощения объяснения можно считать R бинарным отношением, состоящим из A и дополнения A, которое обозначается  и содержит атрибуты, отличные от A. Для каждого раздела из R[], т.е. для каждого уникального кортежа r[], необходимо выполнить следующее:

• выбрать допустимые строки кортежей r[]

из R[], обозначив полученное множество кортежей через T=gR(r[]). Множество T называется также множеством-образом;

• в результирующее отношение входят кортежи r, для которых выполняется S[B]HgR(r[]).

Примеры

Р[D3>÷D4]=Ø (пустое множество), так как





Следовательно, подходящие  отсутствуют.

Реляционная модель

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F. A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин «реляционная модель данных».
Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [2, 5, 7, 10].
Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.
Доменом называется множество атомарных значений одного и того же типа. Так, на рис. 2.23 домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.
Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос «Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву»), Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?
Отношение на доменах D1, D2, ..., Dп (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 2.23 приведен пример отношения для расписания движения самолетов.

Рис. 2.23. Отношение в реляционной модели

Заголовок состоит из такого фиксированного множества атрибутов А1, А2, ..., Ап, что существует взаимно однозначное соответствие между этими атрибутами Аi и определяющими их доменами Di

= (i=1, 2, ..., n).

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Аi:Vi), (i=1, 2, ..., n), по одной такой паре для каждого атрибута Аi в заголовке. Для любой заданной пары атрибут-значение (Аi:Vi) Vi  является значением из единственного домена Di, который связан с атрибутом Аi.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два - бинарным, степени три – тернарным, ..., а степени n – n-арным,

Кардинальное число или мощность отношения

– это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

Изменение кардинального числа отношения связано с изменением состояния отношения.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами А1, А2, ..., Ап. Говорят, что множество атрибутов К=(Аi, Аj, ..., Аk) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия [5].

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Аi, Аj, ..., Аk

2. Минимальность: ни один из атрибутов Аi, Аj, ..., Аk не может быть исключен из К без нарушения уникальности.

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

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


Однако для массового пользователя реляционных СУБД можно использовать неформальные эквиваленты этих понятий:

Отношение – Таблица (иногда Файл),

Кортеж – Строка (иногда Запись),

Атрибут - Столбец, Поле.

При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и тип поля».

Математическое определение реляционной модели приводится в [10, 17].

Отношение рассматривается как подмножество декартова произведения доменов.

Декартовым произведение доменов D1, D2, ..., Dk



где   …, называется множество всех кортежей длины k, т. е. состоящих из k элементов – по одному из каждого домена Di.

Пример 2.4. Если D1{А2, 2}, D2={B, С}, D3={4, 5, D}, то k=3 и соответственно декартово произведение:

D= D1 X D2 X D2 ={(А, B, 4), (А, В, 5), (А, B, D), (А, С,4), (А, С, 5), (А, С, D), (2, B, 4), (2, B, 5), (2, Б, D), (2, С, 4), (2, С, 5), (2, С, D}.

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

Отношением К на множествах D1, D2, ..., Dk называется подмножество декартова произведения D=D1 х D2 х ...х DK. Отношение R, определенное на множествах D1,D2, ..., DK (причем не обязательно, чтобы эти множества были различными), есть некоторое множество кортежей арности k: (d1.i1, d2.i2, …, di,ik), таких, что d1.i1 принадлежит D1, d2.i2  -  D2  и т.д.:

Элементами отношения являются кортежи. Арность кортежа определяет арность отношения. Поскольку отношение есть множество, то в нем не должны встречаться одинаковые кортежи и порядок кортежей в отношении несуществен.

Отношение может использоваться двояко [17]:

1) для представления набора объектов;

2) для представления связей между наборами объектов.

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


Отношение выполняет роль описания всего набора объектов.

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

Список имен атрибутов отношения называется схемой отношения. Если отношение называется R и его схема имеет атрибуты с именами А1, А2, ..., Аk, то схема отношения

R(A1, А2, ..., Аk).

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



Другими словами - реляционная база данных - это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц. Так на рис. 2.24 показаны таблицы базы данных, построенные по инфологической модели базы данных «Питание» (прил. 4) [5].



Рис. 2.24. База данных «Питание» (см. прил. 4)

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

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

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

4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).

5. Полное информационное содержание базы данных представляется в виде явных значений данных, и такой метод представления является единственным. В частности, не существует каких-либо специальных «связей» или указателей, соединяющих одну таблицу с другой.Так, связи между строкой с БЛ=2 таблицы «Блюда» на рис. 2.24 и строкой с ПР=7 таблицы продукты (для приготовления Харчо нужен Рис), представляется не с помощью указателей, а благодаря существованию в таблице «Состав» строки, в которой номер блюда равен 2, а номер продукта - 7.

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

Реляционное исчисление доменов

В реляционном исчислении с переменными на доменах используются те же операторы, что и в реляционном исчислении с переменными-кортежами.
Атомы формул могут быть двух типов [11, 17].
1. R(x1x2…xk),
где R - k-арное отношение; xi - константа или переменная на некотором домене.
Атом R(x1x2…xk)
указывает, что значения тех xi, которые являются переменными, должны быть выбраны так, чтобы (x1x2…xk) было кортежем отношения R.
2. xy, где x и y – константы или переменные на некотором домене, ? –оператор сравнения.
Атом xy указывает, что x и y представляют собой значения, при которых истинно xy.
Формулы в реляционном исчислении с переменными на доменах также используют логические связки ?, ?, ¬ и кванторы (x), (x), где x – переменная на домене. Аналогично используются понятия свободных и связанных переменных.
Реляционное исчисление с переменными на доменах имеет вид
{x1x2…xk | ?(x1 , x2 ,…, xk)},
где ? – формула, обладающая тем свойством, что только ее свободные переменные на доменах являются различными переменными x1 , x2 ,…, xk. Например, выражение
{x1x2 | R1(x1x2) ?(y)(¬R2(x1y) ?¬R2(x2y))}
имеет место для бинарных отношений R1
и R2 и означает множество кортежей в R1, таких, что ни один из их компонентов не является первым компонентом какого-либо кортежа отношения R2.
С целью учета ограничения – конечности реальных отношений – аналогично вводятся безопасные выражения.
Реляционное исчисление с переменными на доменах называется безопасным, если выполняются следующие условия:
1) из истинности ?(x1 , x2 ,…, xk) следует, что xi принадлежит –D(?);
2) если (u)(?1(u)) является подформулой ?, то из истинности ?1(u), следует, что u принадлежит D(?);
3) если (u)(?1(u)) является подформулой ?, то из истинности ?1(u), следует, что u не принадлежит D(?).
Выражение исчисления с переменными на доменах, эквивалентное заданному выражению исчисления с переменными-кортежами {t| ?(t) строится следующим образом:

1) если t является кортежем арности k, то вводится k новых переменных на доменах t1, t2, …, tk;

2) атомы R(t) заменяются атомами R(t1, t2, …, tk);

3) каждое свободное вхождение t[i] заменяется на ti;

4) для каждого квантора (u) или (u) вводится m новых переменных на доменах u1, u2, …, um,

где m – арность кортежа u. В области действия этой квантификации выполняются замены:

R(u) на R(u1u2…um),

u[i] заменяется на ui,

(u) на (u1)(u1)…(um),

(u) на (u1)(u1)…(um);

5) выполняется построение выражения

{t1t2…tk | ?'(t1, t2, …, tk)},

где ?' – это ?, в которой выполнены соответствующие замены.

Например, {t| R1(t) ?R2(t)} перепишется так:

В реляционном исчислении с переменными на доменах существуют следующие две теоремы.

Теорема 4.2. Для каждого безопасного выражения реляционного исчисления с переменными-кортежами существует эквивалентное безопасное выражение реляционного исчисления с переменными на доменах [17].

Теорема 4.3. Для каждого безопасного выражения реляционного исчисления с переменными на доменах существует эквивалентное ему выражение реляционной алгебры [17].

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

Реляционное исчисление кортежей

В выражениях реляционной алгебры всегда явно задается некий порядок выполнения запроса. В реляционном же исчислении указывается что необходимо извлечь, а не как.
Реляционное исчисление никак не связано с дифференциальным и интегральным исчислениями в математике, а его название произошло от части символьной логики, которая называется логикой предикатов.
В логике первого порядка или теории исчисления предикатов под предикатом подразумевается истинностная функция с аргументами. При подстановке вместо аргументов значений, функция становится выражением, называемым суждением, которое может быть истинным или ложным. Например, предложения «студент Шепе-лявцев учится на третьем курсе вуза» и «средний балл успеваемости студента Шепелявцева выше, чем у студента Мамаева» являются суждениями, поскольку можно определить их истинность или ложность. В первом случае функция «учится на третьем курсе вуза» имеет один аргумент («студент Шепелявцев»), а во втором случае функция «средний балл выше» имеет два аргумента («студент Шепелявцев» и «студент Мамаев»).
Если предикат содержит переменную, например в виде «x учится на третьем курсе вуза», то у этой переменной должна быть область определения. При подстановке вместо переменной x одних значений из ее области определения данное суждение может оказаться истинным, а при подстановке других – ложным.
Если P – предикат, то множество всех значений переменной x, при которых суждение Р становится истинным, можно символически записать следующим образом:
{x| P(x)}.
Предикаты могут соединяться с помощью логических операторов ?, ?, ¬ с образованием составных предикатов.
В реляционном исчислении кортежей задача состоит в нахождении таких кортежей, для которых предикат является истинным.
Выражение реляционного исчисления с переменными-кортежами записывается в виде [17]
{t| ?(t)},
где t – свободная переменная-кортеж, обозначающая кортеж фиксированной длины (если необходимо указать арность кортежа, то используют запись t(i); i-арность кортежа t); ? – некоторая формула, построенная по специальным правилам.

Например, выражение {t| R1(t) ?R2(t)}, где в качестве формулы выступает конструкция R1(t) ?R2(t), означает, что необходимо получить множество всех кортежей t, причем таких кортежей, которые принадлежат отношениям R1 или R2. Формула (R1(t) ?R2(t))) имеет смысл только тогда, когда отношения R1 и R2 имеют одинаковую арность, поскольку переменная-кортеж t задана как переменная фиксированной длины. Выражение { t| R1(t) ?R2(t)} эквивалентно операции объединения (R1R2

реляционной алгебры.

Формулы в реляционном исчислении строятся из атомов и совокупности арифметических и логических операторов.

Атомы формул могут быть трех типов [17]:

1) R(t), где R – имя отношения. Этот атом означает, что t – это кортеж в отношении R;

2) s[i]?u[j], где s и u - переменные-кортежи; ? – арифметический оператор (<, >, =, ?, ?, ?); i, j – номера или имена необходимых компонентов (столбцов) в соответствующих кортежах; s[i] – i-тый компонент в кортеже-переменной s; u[j] - j-тый компонент в кортеже-переменной и. Например, атом (s[3] ? u[5]) означает, что третий компонент переменной s больше или равен пятому компоненту переменной u;

3) s[i]?a или a?s[i], где a – константа. Например, атом (s[4]=70), означает, что четвертая компонента переменной-кортежа s

равна 70.

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

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



все вхождения переменной x связаны, первое и последнее вхождения y свободны, остальные вхождения переменной y связаны, все вхождения переменной z свободны, единственное вхождение переменной r связано.


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

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

Правильно построенные формулы определяются рекурсивно следующим образом [11, 17].

1. Каждый атом – это формула. Все вхождения переменных-кортежей, упомянутые в атоме, являются свободными.

2. Если ?1 и ?2 - формулы, то выражения ?1 ??2

(утверждает, что ?1 и ?2 истинны), ?1

??2

(утверждает, что ?1 или ?2, или обе истинны), ¬?1 (утверждает, что ?1 не истинна), также являются формулами.

Экземпляры переменных-кортежей – свободные или связанные в формулах (?1 ??

2), (?1 ??

2) и (¬?1) так же, как и в ?1 и ?2. Таким образом, свободными (связанными) являются те и только те вхождения переменных, которые происходят от свободных (связанных) вхождений переменных ?1 и ?2. Некоторое вхождение переменной может быть связанным в ?1 например, в то время как другое – свободным в ?2 и т.п.

3. Если ? – формула, то (s)(?) – также формула. Свободные вхождения переменной s

в формуле ? становятся связанными квантором (s) в формуле (s)(?). Формула (s)(?) утверждает, что при подстановке любого кортежа подходящей арности вместо свободных вхождений s формула становится истинной.

4. Если ? – формула, то (s)(?) - также формула. Свободные вхождения переменной з в формуле ? также становятся связанными квантором (s) в формуле (s)(?). Формула (s)(?) утверждает, что существует значение s, при подстановке которого вместо всех свободных вхождений s

в формулу ? эта формула становится истинной.


Например, формула (s)(R(s)) означает, что отношение не пусто, т.е. существует некоторый кортеж s, принадлежащий R.

5. Формулы могут при необходимости заключаться в скобки. Используется следующий порядок старшинства:

§ арифметические операторы сравнения;

§ кванторы  и ;

§ ?, ?, ¬.

6. Ничто иное не является формулой.

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

.

Введем ограничения на конечность реальных отношений в БД, чтобы исключить возможность формирования выражений типа {t|-R(t)}, не имеющих смысла. Это выражение обозначает все возможные, не принадлежащие R кортежи, арность которых согласуется с t.

С этой целью в реляционном исчислении рассматривают только безопасные выражения {t|?(t)}, для которых выполняется условие, что каждый компонент (элемент столбца) любого кортежа t, удовлетворяющего ?(t) является элементом некоторого множества элементов D(?). Множество D(?) определяется как функция фактических отношений, которые указываются в ?(t), и констант, присутствующих в формуле ?(t) и элементов кортежей тех отношений, которые указаны в ?(t). Так как все отношения в БД предполагаются конечными, то и множество D(?) – конечно:

D(?)={a1.?}{a2.?}…{an.?}?1(R1) ?2(R1)… ?k(Rn),

где a1.?, a2.?, ..., an.? – константы, встретившиеся в формуле ?(t); ?1(R1), …, ?k(Rn) – проекции кортежей фактических отношений R1, ..., Rn, встретившихся в формуле ?(t) (в данном случае – компоненты кортежей).

При таком определении множества D(?) справедливо следующее:

D(?1(t) ??2(t))= D(?1)D(?2),

D(?1(t) ??2(t))= D(?1)D(?2),

D(?1(t) ?¬?2(t))= D(?1)D(?2) и т.п.

Например, если задано выражение {t|c ?R(t)}, где R – бинарное отношение, то

D(?)={c}?1(R) ?2(R).


Реляционное исчисление является безопасным, если выполнятся следующие условия:

1) из истинности ?(t) следует, что каждый компонент кортежа t принадлежит – D(?);

2) для любой подформулы вида (u)(?1(u)), входящей в состав ф, из истинности ?1(u) следует, что u принадлежит – D(?1);

3) для любой подформулы вида (u)(?1(u)), входящей в состав ?, из истинности ?1(u) следует, что u не принадлежит D(?1), или же, что то же самое, из истинности ¬?1(u) следует, что u принадлежит D(?1).

При выполнении этих условий выражение {t|?(t)} является безопасным. Выражению (u)(?1(u)) эквивалентно выражение ¬(u)(¬?1(u)).

На основании вышеизложенного можно утверждать, что если формула ?(t) такова, что любая ее подформула вида (u)(?i(u)) или (u)(?j(u)) безопасна, то безопасно каждое выражение вида

{t|R(t) ??(t)}. Действительно, любой кортеж, удовлетворяющий формуле (R(t) ??(t)), принадлежит в соответствии с этой формулой отношению R. Следовательно, каждый из его компонентов будет принадлежать также и множеству элементов D(R(t) ??(t)). Тогда в силу выполнения условия 1 (выполнение условий 2 и 3 задано как исходная предпосылка) выражение { t|R(t) ??(t)} – безопасное. Если в ?(t) найдется хотя бы одна из подформул вида (u)(?i(u)) или (u)(?j(u)), которая окажется не безопасной, то тогда и выражение {t|R(t) ??(t)} не будет безопасным. Если в формуле ?(t) вообще отсутствуют подформулы вида (u)(?i(u)) или (u)(?j(u)) – или соответствующие им эквивалентные -¬(u)(¬?i(u)) или ¬(u)(¬?j(u)), – то выражение {t|R(t) ??(t)} всегда является безопасным.

Например, если ?(t)=¬R2(t) то получим безопасное выражение {t|R1(t) ?¬R2(t)} соответствующее операции разности отношений в реляционной алгебре (R1–R2).

Безопасным является также выражение {t|R(t)}, соответствующее выражению R (точнее – переменной R, обозначающей отношение).


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

Теорема 4.1. Если E - выражение реляционной алгебры, то существует эквивалентное ему безопасное выражение в реляционном исчислении с переменными-кортежами [17].

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

1. Операции объединения (R1R2)

соответствует выражение

соответствует выражение

{t|R1(t) ?R2(t)}.

2. Операции разности (R1-R2) соответствует выражение

соответствует выражение

{t|R1(t) ?¬R2(t)}.

Рассматривается все множество кортежей t, таких, что t принадлежит R1 и не принадлежит R2.

3. Операции декартова произведения (R1R2) соответствует выражение

{t(k+m)|(u)(v)(R1(u) ?R2(v) ?t[1]=u[1] ?… ?t[k]=

=u[k] ?t[k+1]=v[1] ?… ?t[k+m]=v[m])}.

Рассматривается все множество кортежей t арности (k+m), таких, что существует кортеж u, принадлежащий R1, и существует кортеж v, принадлежащий R2, причем k первых компонентов кортежа t образуют компоненты кортежа и, а следующие m компонентов кортежа t образуют компоненты кортежа v.

4. Операции проекции соответствует выражение

{t(k)|(u)(R1

?t[1]=u[i1] ?… ?t[k]= u[ik])}

5. Операции селекции соответствует выражение {t|R(t) ?F'}, где F' – это выражение F, в котором каждый операнд, обозначающий компонент i, заменен на t[i].

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

– языков на основе преобразований;

– графических языков.

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

Репликация

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

Сетевая модель

Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков. С точки зрения теории графов сетевой модели соответствует произвольный граф (возможно имеющий циклы и петли). В узлах графа помещаются типы записей, а ребра интерпретируются как связи между типами записей.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи [8].
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка Р и типом записи потомка С должны выполняться следующие два условия:
– каждый экземпляр типа Р является предком только в одном экземпляре L;
– каждый экземпляр С является потомком не более, чем в одном экземпляре L.
На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации [8].
А. Тип записи потомка в одном типе связи L1 может
быть типом записи предка в другом типе связи L2
(как в иерархии).
В. Данный тип записи Р может быть типом записи предка в любом числе типов связи.
С. Данный тип записи Р может быть типом записи потомка в любом числе типов связи.
D. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка Р и одним и тем же типом записи потомка С, то правила, по которым образуется родство, в разных связях могут различаться.
Е. Типы записи X и У могут быть предком и потомком в одной связи и потомком и предком - в другой.

F. Предок и потомок могут быть одного типа записи.

Простой пример сетевой схемы БД приведен на рис. 2.22.



Рис. 2.22. Пример схемы сетевой БД

Примерный набор операций при использовании сетевой модели может быть следующим [8].

– Найти конкретную запись в наборе однотипных записей (инженера Петрова).

– Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 42).

– Перейти к следующему потомку в некоторой связи (от Петрова к Иванову).

– Перейти от потомка к предку по некоторой связи (найти отдел Петрова).

– Создать новую запись.

– Уничтожить запись,

– Модифицировать запись.

– Включить в связь.

– Исключить из связи.

– Переставить в другую связь и т. д.

Схемы владения данными

Владение данными определяет, какому из сайтов будет предоставлена привилегия обновления данных Основными типами схем владения являются [7]:
– «ведущий/ведомый»;
– «рабочий поток»;
– «повсеместное обновление».
Последний вариант иногда называют одноранговой, или симметричной репликацией.
При организации владения данными по схеме «ведущий/ведомый» асинхронно реплицируемые данные принадлежат одному из сайтов, называемому ведущим, или первичным, и могут обновляться только на нем. Здесь можно провести аналогию между издателем и подписчиками. Издатель (ведущий сайт) публикует свои данные. Все остальные сайты только лишь подписываются на данные, принадлежащие ведущему сайту, т.е. имеют собственные локальные копии, доступные им только для чтения. Потенциально каждый из сайтов может играть роль ведущего для различных, не перекрывающихся наборов данных. Однако в системе может существовать только один сайт, на котором располагается ведущая обновляемая копия каждого конкретного набора данных, а это означает, что конфликты обновления данных в системе полностью исключены. Ниже приводится несколько примеров возможных вариантов использования этой схемы репликации.
– Системы, поддержки принятия решений (ППР). Данные из одной или более распределенных баз данных могут выгружаться в отдельную, локальную систему ППР, где они будут только считываться при выполнении различных видов анализа.
– Централизованное распределение или распространение информации. Распространение данных имеет место в тех случаях, когда данные обновляются только в центральном звене системы, после чего реплицируются их копии, доступные только для чтения. Этот вариант репликации данных показан на рис.5.6,а.
– Консолидация удаленной информации. Консолидация данных имеет место в тех случаях, когда обновление данных выполняется локально, поле чего их копии, доступные только для чтения, отсылаются в общее хранилище.
В этой схеме каждый из сайтов автономно владеет некоторой частью данных. Этот вариант репликации данных показан на рис. 5.6, б.

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



Рис. 5.6. Владение данными по схеме «ведущий/ведомый»: а) распределение данных; б) консолидация данных

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

Как и в случае схемы «ведущий/ведомый», в модели «рабочий поток»

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

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


Каждое приложение обновляет данные о заказе по очереди тогда и только тогда, когда состояние заказа указывает, что предыдущий этап обработки уже завершен. В модели владения «рабочий поток» приложения могут быть распределены по различным сайтам, и когда данные реплицируются и пересылаются на следующий сайт в цепочке, вместе с ними передается и право на их обновление, как показано на рис. 5.7.



Рис. 5.7. Схема владения «рабочий поток»

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

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

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

Сохранение целостности транзакций

Первые попытки реализации механизма репликации по самой своей сути не предусматривали сохранения целостности транзакций [7]. Данные копировались без сохранения свойства атомарности транзакций, что потенциально могло привести к утрате целостности Распределенных данных. Этот подход проиллюстрирован на рис. 5.8, а.
В данном случае транзакция, состоящая на исходном сайте из нескольких операций обновления данных в различных таблицах, в процессе репликации преобразовывалась в серию отдельных транзакций, каждая из которых обновляла данные в одной из таблиц. Если часть этих транзакций на целевом сайте завершалась успешно, а остальная часть – нет, то согласованность информации между двумя базами данных утрачивалась.
В противоположность этому, на рис. 5.8, б показан пример репликации с сохранением структуры транзакции в исходной базе данных.

Рис. 5.8. Репликация транзакций: а) без соблюдения свойства атомарности; б) с соблюдением атомарности транзакций

Списковые структуры

В системах обработки данных в качестве данных выступают описания (представления) фактов и понятий рассматриваемой предметной области на точном и формализованном входном языке системы - языке описания данных [17]. С помощью входного языка при описании фактов и понятий ПО между элементами данных конструируются логические структурные отношения. В качестве логических структур (см. гл.2) используют либо таблицы, представляющие собой двумерный или re-мерный массив данных, либо древовидные иерархически структуры, либо сетевые структуры, представляющие собой сложную многосвязную структуру с большим количеством взаимных соединений и т.п. Чтобы правильно использовать вычислительную машину, необходимо хорошо представлять себе структурные отношения между данными, знать способы представления таких структур в памяти машины и методы работы с ними. Структура данных и представление этой структуры в памяти ЭВМ – два важных, но Различных между собой понятия [17]. Так, например, некоторая логическая структура данных типа «дерево» может быть представлена в памяти ЭВМ несколькими различными способами.
Таким образом, любое представление структуры данных в памяти ЭВМ должно включать в себя как сами данные, так и задаваемые взаимосвязи, которые и определяют логическое структурирование.
Форма представления структур данных в памяти ЭВМ зависит от предполагаемого использования данных, поскольку для различных типов структур эффективность выполнения тех или иных операций обработки данных различна. Основное различие форм представления структур данных в памяти ЭВМ определяются в первую очередь тем, как адресуются элементы структуры данных в памяти машины – по месту или по содержимому. В первом случае указываются логические или физические адреса данных, определяющие местоположение данных в памяти машины. Во втором случае размещение данных и их выборка осуществляются по известному значению ключа, т.е. определяются содержимым самих данных [4].
Наиболее простой формой хранения данных в памяти ЭВМ является одномерный линейный список.

Линейный список – это множество n>0 объектов (узлов) Х[1], Х[2], ..., Х[п], структурные свойства которого связаны только с линейным (одномерным) относительным расположением узлов. Если п>0, то Х[1] является первым узлом; для 1
Линейный список X рассматривают как последовательность Х[1], Х[2], ..., Х[i], ..., Х[п], компоненты которой идентифицированы порядковым номером, указывающим их относительное расположение в X.

Одномерный линейный список, используемый для хранения данных в памяти машины, называют еще вектором данных или физической структурой хранения данных. Использование линейного списка в качестве физической структуры хранения данных определяется свойствами памяти вычислительной машины. Так, оперативная память ЭВМ представляет вектор, в котором байты упорядочены по возрастанию их адресов от 0 до наивысшего, т.е. проидентифицирова-ны адресом.

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

При реализации адресной функции используют два основных метода [17]:

– последовательное распределение памяти;

– в связанное распределение памяти.

Сравнение теоретических языков

Рассмотренные выше три абстрактных языка запросов служат основой реальных языков манипулирования данными реляционных систем.
Каждый из трех рассмотренных языков эквивалентен по своей выразительности двум другим. Однако языки исчисления – это непроцедурные языки, поскольку их средствами можно выразить все, что необходимо и не обязательно указывать, как это получить (выражение в исчислении описывает лишь свойства желаемого результата, фактически не указывая, как его получить). Выражение реляционной алгебры, напротив, специфицируют конкретный порядок выполнения операций.
В первом случае определение наиболее эффективного порядка вычисления для реализации запроса пользователя выполняется транслятором или интерпретатором. Во втором случае пользователь обычно сам должен выполнить оптимизацию своего запроса при его формулировке. Однако, например, в соответствии с теоремой 1 транслятор на первом шаге трансляции запроса может выполнить преобразование алгебраического выражения в эквивалентное выражение исчисления и далее определить эффективный порядок вычислений [7, 17].
В общем случае языки манипулирования данными выходят за рамки теоретических языков, поскольку для обработки данных требуются операции, выходящие за рамки возможностей реляционного исчисления. Это прежде всего следующие команды: включить данные; модифицировать данные; удалить данные. Кроме этих операций обычно представляются следующие дополнительные возможности:
– арифметические вычисления и сравнения могут включаться в формулы селекции реляционных алгебраических выражений или в атомы в выражениях реляционного исчисления;
– команды печати;
– агрегатные функции – функции, применяемые к столбцам отношений, в результате выполнения которых вычисляется одна-единственная величина, например максимальное или минимальное значение, сумма, среднее.
Так как реальные языки могут реализовывать функции, не имеющие аналогов ни в реляционной алгебре, ни в реляционном исчислении, то в действительности они являются более чем полными. Причем, полным считается язык, в котором реализуются все возможности реляционного исчисления или реляционной алгебры.
Перспективной категорией языков запросов являются языки четвертого поколения (4-generation languages – 4GL), которые позволяют создавать полностью готовое и соответствующее требованиям заказчика прикладное приложение с помощью ограниченного набора команд и в то же время предоставляют дружественную по отношению к пользователю среду разработки, чаще всего построенную на использовании команд меню. В некоторых системах даже используются некоторые разновидности естественного языка, т.е. ограниченной версии обычного английского языка, который иногда называется языком пятого поколения (5GL) [7].

Средства администрирования баз данных

Учитывая сложность и важность функций АБД, легко предположить, что для их успешного выполнения, У администратора должны быть специальные средства администрирования
К основным из таких средств администрирования можно отнести:
1) язык определения данных;
2) язык манипулирования данными,
3) словарь данных (системный каталог)
Вкратце остановимся на назначении перечисленных средств.
Для работы с данными в СУБД предусмотрен внутренний язык, состоящий из двух частей: языка определения данных (Data Definition Language - DDL) и языка манипулирования данными (Data Manipulation Language - DML).
Эти языки еще называются подъязыками данных, т. к. в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы на языках высокого уровня. В этом случае язык высокого уровня принято называть базовым или включающим языком.
Язык определения данных (ЯОД, DDL) - формальный закон, используемый в некоторой модели данных для определения структуры баз данных [12].
Результат компиляции операторов ЯОД - набор таблиц хранимых в особых файлах, называемых словарями данных или системными каталогами.
Посредством ЯОД обычно определяются подразделения данных, типовые структуры и правила их композиции, присваиваются имена данным, определяются типы элементов данных посредством задания присущих им свойств, учреждаются ключи базы данных, а также определяются отношения между данными, упорядоченность данных внутри их совокупностей, правила проверки достоверности данных и замки защиты от неправомочного использования их.
Обычно в ЯОД не определяются техника запоминания или поиска данных на физических носителях и другие особенности их физической организации, что обусловлено одной из основных концепций базы данных - независимостью логической структуры данных от физических особенностей их хранения.

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

Язык манипулирования данными (ЯМД, DML) - совокупность языковых средств для организации доступа к данным в некоторой модели данных и в соответствующих ей СУБД [12].

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

К основным операциям манипулирования данными относятся:

– вставка в БД новых сведений;

– модификация сведений, хранимых в БД;

– извлечение сведений, содержащихся в БД;

– удаление сведений из БД.

ЯМД отличаются базовыми конструкциями манипулирования данными. Отличают два их типа:

а) процедурные ЯМД;

б) непроцедурные (декларативные) ЯМД.

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

С помощью непроцедурных языков пользователь указывает какие

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

В общем случае язык запросов – часть ЯМД, высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке данных из БД.


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

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

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

Ключевой особенностью архитектуры ANSI/SPARC является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т.д. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. В зависимости от типа используемой СУБД количество информации и способ ее применения могут варьироваться. Обычно в системном каталоге хранятся следующие сведения:

– имена, типы и размеры элементов данных;

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

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

– имена зарегистрированных пользователей, которым предоставлено право доступа к данным;

– внешняя, концептуальная и внутренняя схемы и отображения между ними;

– статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.

СТРУКТУРА СЛОВАРЯ ДАННЫХ 1. БАЗА ДАННЫХ – полное название базы и имя файла Описание назначения и общего содержания БД, а также лиц, которые могут ею пользоваться. Список приложений, работающих с базой, информация о других БД, использующих данные из этой базы. Если имеются, то сюда же включаются диаграммы БД. А. ОБЛАСТЬ ДАННЫХ - название группы, к которой принадлежат таблицы Если таблицы классифицируются по группам, то включается описание каждой группы. 1. ТАБЛИЦА- таблицы, входящие в область данных а) ДОСТУП - права пользователей на доступ к таблице б) ЗАПИСЬ - общее определение элементов данных (1) ПЕРВИЧНЫЙ КЛЮЧ - поле (поля) первичного ключа (а) ИНДЕКС - описание индекса первичного ключа (2) ВНЕШНИЕ КЛЮЧИ - внешние ключевые поля (а) ИНДЕКС - индексы внешних ключей

<


Рис. 1.11. Примерная структура словаря данных

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

преимуществ, перечисленных ниже.

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

– другому ресурсу.

– Можно определить смысл данных, что поможет другим пользователям понять их предназначение.

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

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

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

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

– Меры обеспечения безопасности могут быть дополнительно усилены.

– Появляются новые возможности организации поддержки целостности данных.

– Может выполняться аудит сохраняемой информации.

Системный каталог СУБД является одним из фундаментальных компонентов системы. Многие перечаленные в разд.1.3 [7] программные компоненты стройся на использовании данных, хранящихся в системном каталоге. Например, модуль контроля прав доступа использует системный каталог для проверки наличия у пользователя полномочий, необходимых для выполнения запрошенных им операций. Для проведения подобной проверки системный каталог должен включать следующие компоненты:


– имена пользователей, для которых разрешен доступ к базе данных;

– имена элементов данных в базе данных;

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

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

– имена элементов данных из базы данных;

– типы и размеры элементов данных;

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

Термин «словарь данных» часто используется для программного обеспечения более общего типа, чем просто каталог СУБД. Система словаря данных может быть либо пассивной, либо активной. Активная система всегда согласуется со структурой базы данных, поскольку она автоматически поддерживается этой системой. Пассивная система может противоречить состоянию базы данных из-за инициируемых пользователями изменений. Если словарь данных является частью базы данных, то он называется интегрированным словарем данных. Изолированный словарь данных обладает своей собственной специализированной СУБД. Его предпочтительно использовать на начальных этапах проектирования базы данных для некоторой организации, когда требуется отложить на какое-то время привязку к конкретной СУБД. Однако недостаток этого подхода заключается в том, что после выбора СУБД и воплощения базы данных изолированный словарь данных значительно труднее поддерживать в согласии с состоянием базы данных.

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

Связанное распределение памяти

Связанное представление линейного списка называется связанным списком. При связанном распределении памяти для построения структуры необходимо задать отношения следования и предшествования элементов с помощью указателей. Указателями служат адреса, хранимые в записях данных. В отличие от последовательного распределения памяти, при котором с помощью адресной функции вычисляется адрес следующего элемента, при связанном распределении памяти значение адресной функции можно получить только путем просмотра хранящихся указателей. Такой метод распределения памяти позволяет расширить либо сократить структуру без перемещения самих данных в памяти ЭВМ, однако при этом требуется больше памяти для хранения структуры по сравнению с последовательным распределением [16, 17].
Связанное распределение - более сложный, но и более гибкий способ хранения линейного списка. Каждый узел содержит указатель на следующий узел списка, т.е. адрес следующего узла списка (рис. 3.3). При связанном распределении не требуется, чтобы список хранился в последовательных элементах памяти. Наличие адресов связи в данном способе хранения позволяет размещать узлы списка произвольно в любом свободном участке памяти. При этом линейная структура списка обеспечивается указателями.
Структура линейного списка, представленная с помощью связанного распределения, называется также Цепной структурой или цепью.
Для достижения большей гибкости при работе с линейными списками в каждый узел X[i] вводятся два Указателя. Один из указателей реализует связь рас сматриваемого узла с узлом Х[М], а другой - с узлом X[i+l] (рис. 3.4).

Рис. 3.3. Примеры связанных линейных списков: а) – однонаправленный список; б) – тот же список после удаления узла 4 и включения узлов 2а и 5
Связанные списки - удобная форма представления динамически изменяющихся линейных структур. Любое произвольное изменение порядка записей, сокращение или расширение вектора данных в какой-либо записи не требуют перемещения записей в памяти ЭВМ.
Для выполнения этих операций достаточно лишь изменить значения полей связи.

Однако доступ к конкретному узлу может оказаться намного длительнее, чем при последовательном распределении памяти. Чтобы получить доступ к данным, хранящимся в узле X[i], необходимо сделать i итераций, используя указатели и поля связи в узлах X[k], где k=1, 2, ..., i, т.е. последовательно просмотреть все предшествующие узлы списка. Этот недостаток можно устранить различными способами.

 где n– количество элементов списка.

Число групп





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

В этот узел помещается указатель на первый узел списка.


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

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



Рис. 3.6. Пример однонаправленного циклического списка

Наряду с однонаправленными используются двунаправленные циклические списки. В ряде случаев удобно использовать циклический список с указателями на голову списка из каждого узла, за исключением последнего узла, поскольку используется прямой указатель на голову списка [17].

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

Таким образом, основой построения связанных списковых структур являются указатели.

При практической реализации на ЭВМ можно использовать три типа указателей (адресов записей):

– машинный (действительный);

– относительный;

– символический (идентификатор).

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


Если возникнет необходимость переместить список на новое место в памяти ЭВМ, то потребуется выполнить работу изменению указателей во всех записях.

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

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

С точки зрения организации структуры данных различают два типа указателей [17]:

– встроенные указатели;

– справочник указателей.

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

Указатели имеют следующие возможные пути использования [17]:

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

2) соединяют вместе связанные по смыслу данные;

3) отображают ориентированные ребра в древовидных или сетевых структурах;

4) связывают память на дисках и организуют цепочки дисковых страниц и т. п.

Применение многосвязанных списков – это основной механизм, позволяющий разработчикам СУБД реализовывать сложные нелинейные структуры. Однако следует избегать слишком большого количества указателей, поскольку на них тратится память и время на переходы по указателям. Кроме того, при большом количестве указателей основная структура, представляемая в памяти ЭВМ, теряет четкость, и могут возникнуть связи, которые в отображаемой структуре отсутствуют.

Теоретические языки запросов

Для получения информации из отношений необходим язык манипулирования данными, способный выполнять соответствующие операции над отношениями. Наиболее важной частью ЯМД является его раздел для формулировки запросов. Поскольку запросы в общем случае представляют собой произвольные функции над отношениями, необходимо решить вопрос о требуемой выразительности языка запросов. Для исследования этого вопроса были разработаны три типа теоретических языков [2, 17]:
1) реляционная алгебра;
2) реляционное исчисление с переменными-кортежами;
3) реляционное исчисление с переменными-доменами.
Языки запросов первого типа – алгебраические языки – позволяют выражать запросы средствами специализированных операторов, применяемых к отношениям.
Языки запросов второго и третьего типов – языки исчисления – позволяют выражать запросы путем спецификации предиката, которому должны удовлетворять требуемые кортежи или домены.
Теоретические языки служат эталоном для оценки существующих реальных языков запросов [17]. Они были предложены Коддом для представления минимальных возможностей любого разумного языка запросов для реляционной модели данных. По своей выразительности все три языка оказались эквивалентными между собой.

Третья нормальная форма

Рассмотрим другое отношение График, представленное ниже. Предположим, что это отношение имеет ключ РЕЙС ДЕНЬ и к тому же удовлетворяет функциональным зависимостям КОД-ПИЛОТАИМЯ и ИМЯКОД-ПИЛОТА.
Если выполнить операцию обновления
ИЗМЕНИТЬ   (График;   112,    6   июня,
КОД-ПИЛОТА=31039,   ИМЯ=Иванов),
то изменяется функциональная зависимость ИМЯКОД-ПИЛОТА. Кроме того, имеется избыточная информация в виде пар КОД-ПИЛОТА, ИМЯ.
Проблема здесь не из-за частичной зависимости непервичного атрибута, хотя решение получается то же самое.
Это отношение можно представить в виде базы данных следующим образом.

Пилот-График		РЕЙС		ДАТА		КОД-ПИЛОТА
		112		6 июня		31174
112		7 июня		30046
203		9 июня		31174

Код		КОД-ПИЛОТА		ИМЯ
		31174		Иванов
30046		Петров

Возможность восстановления первоначального отношения сохраняется.
Перед определением третьей нормальной формы характеризуется транзитивная зависимость атрибутов.
Для данной схемы отношения , подмножества  множества , атрибута  в  и множества функциональных зависимостей  атрибут  называется транзитивно зависимым от  в , если существует подмножество , такое, что, не определяет функционально ,  относительно  и  [10].
Пример 2.10. Пусть  (РЕЙС, ДАТА, КОД-ПИЛОТА, ИМЯ) и множество ={РЕЙС ДАТАКОД-ПИЛОТА ИМЯ, КОД-ПИЛОТАИМЯ, ИМЯКОД-ПИЛОТА}.
Атрибут ИМЯ является транзитивно зависимым от РЕЙС ДАТА, так как РЕЙС ДАТА® КОД-ПИЛОТА, КОД-ПИЛОТА не определяет функционально РЕЙС ДАТА и КОД-ПИЛОТА®ИМЯ.
Схема отношения  находится в третьей нормальной форме (3НФ) относительно множества функциональных зависимостей , если она находится в 1НФ и ни один из первичных атрибутов в  не является транзитивно зависимым от ключа для  [10].
Схема базы данных R находится в третьей нормальной форме относительно , если каждая схема отношения  в R находится в 3НФ относительно .
Пример 2.11. Пусть  и множество  те же, что и в примере 2.10, R={}.
Схема базы данных R не находится в 3НФ относительно , потому что ИМЯ является транзитивно зависимым от РЕЙС ДАТА.
Если R={(PEЙC, ДАТА, КОД-ПИЛОТА); (КОД-ПИЛОТА, ИМЯ)}, то R находится в 3НФ относительно .
Следует заметить, что любая схема отношения, находящаяся в 3НФ относительно , находится в 2НФ относительно  [10].

Триггеры базы данных

Альтернативный подход заключается в предоставлении пользователям возможности создавать собственные приложения, выполняющие репликацию данных с использованием механизма триггеров базы данных.
В этом случае на пользователей возлагается ответственность за написание тех триггерных процедур, которые будут вызываться при возникновении соответствующих событий, например при создании новых записей или обновлении уже существующих. Хотя подобный подход предоставляет большую гибкость, чем механизм создания моментального снимка, ему также присущи определенные недостатки.
– Отслеживание запуска и выполнение триггерных процедур создает дополнительную нагрузку на систему.
– Триггеры выполняются при каждом изменении строки в ведущей таблице. Если ведущая таблица подвержена частым обновлениям, вызов триггерных процедур может создать существенную дополнительную нагрузку на приложения и сетевые соединения. В противоположность этому, при использовании моментальных снимков все выполненные изменения пересылаются за одну операцию.
– Триггеры не могут выполняться в соответствии с     некоторым графиком. Они выполняются в тот момент, когда происходит обновление данных в ведущей таблице. Моментальные снимки могут создаваться в соответствии с установленным графиком или даже вручную. В любом случае это позволяет исключить дополнительную нагрузку от репликации данных в периоды пиковой нагрузки на систему.
– Если реплицируется несколько связанных таблиц, синхронизация их репликации может быть достигнута за счет использования механизма групповых обновлений. Решить эту задачу с помощью триггеров существенно сложнее.
– Аннулирование результатов выполнения триггер-ной процедуры в случае отмены или отката транзакции – достаточно сложная задача.

Виды репликации

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

Вторая нормальная форма

Для данной схемы отношения , атрибута  в  и множества функциональных зависимостей  на  атрибут А называется первичным в  относительно , если  содержится в каком-нибудь ключе схемы . В противном случае  называется непервичным в .
Ключи в этом определении не следует путать с выделенными ключами для , так как последние могут быть на самом деле суперключами. Кроме того, могут существовать ключи для , не являющиеся выделенными.
Пример 2.8.
Пусть  (РЕЙС, ДАТА, ПИЛОТ, ГАЛЕРЕЯ) и множество ={РЕЙС ДАТА  ПИЛОТ ГАЛЕРЕЯ, РЕЙСГАЛЕРЕЯ}.
Атрибуты РЕЙС и ДАТА являются первичными, ПИЛОТ и ГАЛЕРЕЯ – непервичными. (Допустимо, чтобы один пилот имел два рейса в день, так что ПИЛОТ ДАТА ключом не является.)
Схема отношения  находится во второй нормальной форме (2НФ) относительно множества функциональных зависимостей , если она находится в первой нормальной форме (1НФ) и каждый непервичный атрибут полностью зависит от каждого ключа для  [10].
Схема базы данных R имеет вторую нормальную форму относительно , если каждая схема отношения  из R находится в 2НФ относительно .
Пример 2.9. Пусть (РЕЙС, ДАТА, ПИЛОТ, ГАЛЕРЕЯ) и множество ={РЕЙС ДАТА  ПИ-ЛОТ ГАЛЕРЕЯ, РЕЙСГАЛЕРЕЯ}, R={}.
Схема не находится в 2НФ, так как ГАЛЕРЕЯ частично зависит от РЕЙС ДАТА. Если положить R={(PEЙC, ДАТА, ПИЛОТ); (РЕЙС, ГАЛЕРЕЯ)}, тогда схема будет находиться во второй нормальной форме. РЕЙС теперь является ключом для схемы отношения (РЕЙС, ГАЛЕРЕЯ).

Выбор СУБД

Важным этапом жизненного цикла информационной системы и, в частности, проектирования базы данных, является выбор целевой СУБД.
Предлагаемые в разделе методы пригодны и к оценке новых продуктов, поступающих на рынок.
Основная цель при подборе СУБД – выбор системы, удовлетворяющей текущим и прогнозируемым требованиям организации при оптимальном уровне затрат.
Затраты могут включать расходы на приобретение СУБД и дополнительного аппаратного и программного обеспечения, а также расходы, связанные с переходом к новой системе и необходимостью переобучения персонала.
Сложность и комплексность проблем, возникающих при проектировании сложных систем, в том числе и информационных систем, основанных на базах данных, привели к тому, что вопросы формирования критериев для анализа и синтеза систем перестали быть только искусством, основанным на инженерной интуиции, а превратились в серьезное научное направление, важность которого возрастает с каждым днем [3].
Если раньше выбор инструментальных средств (в том числе СУБД) производился исходя из предпочтений разработчика вне зависимости от специфики предметной области и перспектив использования базы данных, то на современном этапе развития программного обеспечения, когда на рынке предлагается необозримое количество СУБД, выбор средства реализации БД становится сложной задачей. Принятие строго оптимального решения в таких условиях желательно, но затруднено.
В общем виде процесс выбора СУБД включает следующие этапы:
1) определение списка показателей; по которым будут оцениваться СУБД;
2) определение списка сравниваемых СУБД;
3) оценка продуктов по выбранным показателям;
4) принятие обоснованного решения, подготовка отчета.
Современные СУБД имеют множество основных и дополнительных функций, предоставляющих разработчику мощный инструментарий для реализации, поддержки и ведения баз данных. Какую из них выбрать в каждом конкретном случае?
Известны математические методы для решения задач оптимизации.
В частности при выборе СУБД по множеству показателей очевидно применение методов линейного или целочисленного программирования. К числу сходных задач относится, например, задача о наименьшем покрытии, а универсальный метод для решения таких задач – метод ветвей и границ. Но эти задачи относятся к классу NР-полных, а значит, сложность их решения может сравниться (или превзойти) сложную многоэтапную задачу проектирования информационной системы.

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

Общая постановка задачи принятия решений выглядит следующим образом [3].

А. Имеется некоторое множество альтернатив (в рассматриваемом случае – СУБД) А, причем каждая альтернатива а

характеризуется определенной совокупностью свойств a1, а2, ..., аn.

Б. Имеется совокупность критериев q = (q1, q2, ..., qi, ..., qп), отражающих количественно множество свойств системы, т.е. каждая альтернатива характеризуется вектором q(а) = [q1(а), q2(а), ..., qi(а), ..., qn(а)].

В. Необходимо принять решение о выборе одной из альтернатив (СУБД), причем решение называется простым, если выбор производится по одному критерию, и сложным, если выбранная альтернатива не является наилучшей по какому-то одному критерию, но может оказаться наиболее приемлемой для всей их совокупности.

Г. Задача принятия решения по выбору альтернативы на множестве критериев формально сводится к отысканию отображения j, которое каждому вектору q ставит в соответствие действительное число

E=j(q)=j(q1,q2,…,qn)

определяющее степень предпочтительности данного решения.

Оператор j называют интегральным (обобщенным) критерием. Интегральный критерий присваивает каждому решению по выбору альтернативы соответствующее значение эффективности Е. Это позволяет упорядочить множество решений по степени предпочтительности.

В данном разделе предлагается использовать аддитивное преобразование при построении обобщенного показателя эффективности, известное из теории полезности [3]:




Однако в этом случае значения коэффициентов bi отражают полезность (ценность) критерия qi при принятии сложного решения о выборе альтернативы. Определение их значений производится в результате предварительного опроса группы из т экспертов (специалистов в данной области). Один из возможных путей получения этих значений заключается в следующем. Каждый j-й эксперт вначале определяет набор чисел Сij, отражающих его мнение об относительной ценности i-го критерия, причем числа Сij, записаны в произвольном масштабе. Затем они масштабируются, в результате получают



Окончательные значения коэффициентов bi, вычисляются в результате осреднения значений bij (j =1, 2, ..., m), получаемых от всех экспертов. Если компетентность экспертов в группе считается одинаковой, то



Если же компетентность j-го эксперта оценивается числом  ,то



Ниже рассматриваются основные методы формирования коэффициентов Сij, отражающих мнение j-го эксперта о ценности i-го критерия. В дальнейшем предполагается, что вначале каждый эксперт провел ранжировку всех критериев, т.е. упорядочил их в соответствии с относительной ценностью так, что на первом месте находится самый главный критерий.

Выявление и разрешение конфликтов

Когда несколько сайтов могут независимо вносить изменения в реплицируемые данные, необходимо использовать некоторый механизм, позволяющий выявлять конфликтующие обновления данных и восстанавливать согласованность информации в базе. Простейший механизм обнаружения конфликтов в отдельной таблице состоит в рассылке исходным сайтом как новых, так и исходных значений измененных данных Для каждой строки, которая была обновлена с момента последней синхронизации копий. На целевом сайте сервер репликации должен сравнить с полученными эвачениями каждую строку в целевой базе данных, которая была локально изменена за данный период. Однако этот метод требует установки дополнительных Оглашении для обнаружения других типов конфликтов, например нарушения ссылочной целостности между двумя таблицами.
Было предложено несколько различных механизмов разрешения конфликтов, однако чаще всего применяются следующие [7].
– Самая ранняя или самая поздняя временная отметка. Изменяются соответственно данные с самой ранней или самой поздней временной отметкой.
– Приоритеты сайтов. Применяется обновление, поступившее с сайта с наибольшим приоритетом.
– Дополняющие и усредненные обновления. Введенные изменения обобщаются. Этот вариант разрешения конфликтов может использоваться в тех случаях, когда обновление атрибута выполняется операциями, записанными в форме отклонений.
– Минимальное или максимальное значение. Применяются обновления, соответствующие столбцу с минимальным или максимальным значением.
– По решению пользователя. АБД создает собственную процедуру разрешения конфликта. Для устранения различных типов конфликтов могут быть подготовлены различные процедуры.
– Сохранение информации для принятия решения вручную. Сведения о конфликте записываются в журнал ошибок для последующего анализа и устранения администратором базы данных вручную.

Зависимости соединения

Многозначные зависимости представляют собой попытку выделения декомпозиций без потери информации, сохраняющих это свойство для всех отношений с заданной схемой. Однако MV-зависимости не полностью в этом смысле адекватны. Отношение может иметь нетривиальную декомпозицию без потерь на три схемы, но не обладать таким свойством для любых двух из них.
В Пример 2.18. Отношение r со схемой ABC на рис. 2.26 разлагается без потерь на схемы АВ, АС и БС (рис.2.27). Однако r не удовлетворяет никаким нетривиальным MV-зависимостям и, следовательно, не имеет декомпозиций без потери информации на пары R1, R2, такие, что R1 (A, B, C) и R2(A, B, C).
Y  тогда и только тогда, когда r разлагается без потерь на XY и XZ, где Z=R-(XY). Условие совпадает с J-зависимостью *[XY, XZ]. С другой стороны, зависимость соединения *[Rr R2] имеет тот же смысл, что MV-зависимость R1R2R1.
Для J-зависимости можно привести определение, аналогичное определению MV-зависимости [10]. Пусть r удовлетворяет зависимости *[R1,R2, ..., Rp]. Если r содержит кортежи t1,  t2, ..., t , такие, что для всех i, j
ti(RiRj)=Ti(RiRj),
то r содержит кортеж t, такой, что t(Ri) = ti(Ri),1

Жизненный цикл информационной системы

Рассмотрение вопросов проектирования эффективных баз данных целесообразно начать с обзора жизненного цикла автоматизированных информационных систем.
Типичная автоматизированная информационная система включает следующие компоненты [7].
– База данных.
– Программное обеспечение базы данных.
– Прикладное программное обеспечение.
– Аппаратное обеспечение, в том числе устройства хранения.
– Персонал, использующий и разрабатывающий систему.
База данных является фундаментальным компонентом информационной системы, а ее разработку и использование следует рассматривать с точки зрения самых широких требований организации. Таким образом, жизненный цикл ИС неотъемлемо связан с жизненным циклом лежащей в основе базы данных. I
Жизненный цикл любой сложной системы и, безусловно, ИС, основанной на базе данных, обычно состоит из нескольких этапов:
1) планирование;
2) сбор и анализ требований к системе;
3) проектирование системы (в том числе проектирование базы данных);
4) создание прототипа;
5) реализация;
6) тестирование;
7) преобразование;
8) сопровождение.
Учитывая специфику разработки приложения базы данных, можно специфицировать этапы, представленные на рис.2.1 [7]. Общепризнанным является тот факт, что указанные этапы не являются строго последовательными, а подразумевают повторы предыдущих этапов с помощью циклов обратной связи. Процесс разработки БД является итеративным, предполагает многократные возвраты и анализ полученных результатов с целью максимально адекватного описания предметной области. На рис.2.1 показаны наиболее очевидные циклы обратной связи, и их множество не является окончательным.

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

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

Планирование самого эффективного способа реализации этапов жизненного цикла системы.

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

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

Сбор и анализ требований пользователей

На этом этапе производится сбор и анализ требований пользователей из всех возможных областей применения БД.

Проектирование базы данных

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

Выбор целевой СУБД

Выполняется подбор наиболее подходящей СУБД для приложения базы данных.

Разработка приложений

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

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

Реализация

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

Конвертирование и загрузка данных (первичное наполнение)

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

Тестирование

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

Эксплуатация и сопровождение

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

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

В последующих разделах подробно рассматриваются проблемные вопросы проектирования баз данных.



    Работа с информацией: Cистемы - Технологии - Рынок

• Анализ информационных систем
  
• Методы информационных систем
  
• Интернет как информационная система
  
• Искусственный интеллект в информационных системах
  
• Обработка информации информационными системами
  
  
• Информационные системы в офисе
  
• Управление информационными системами
  
• Технологии информационных систем
  
• Теория информационных систем
  
• Почта - информационная система
  
  
• Outlook и информационные системы
  
  
• Информационный рынок
  
• Информационный рынок - IT
  
• Технологии информационного рынка
  
• Безопасность на информационном рынке
  

---

---