39801

БАЗЫ И БАНКИ ДАННЫХ

Книга

Информатика, кибернетика и программирование

ВВЕДЕНИЕ В БАЗЫ И БАНКИ ДАННЫХ 1. Понятие базы и банка данных Развитие вычислительной техники и появление емких внешних запоминающих устройств прямого доступа предопределило интенсивное развитие автоматических и автоматизированных систем разного назначения и масштаба в первую очередь заметное в области бизнесприложений.1 Другими направлениями стимулировавшими развитие стали с одной стороны системы управления физическими экспериментами обеспечивающими сверхоперативную обработку в реальном масштабе времени огромных потоков данных от...

Русский

2013-10-08

5.08 MB

72 чел.

1. ВВЕДЕНИЕ В БАЗЫ И БАНКИ ДАННЫХ

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

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

Рис. 1.1. Схема автоматизированной информационной системы

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

Банк данных (БнД) — это система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2. Компоненты банка данных

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

В структуре банка данных выделяют следующие компоненты (подсистемы):

информационная база;

лингвистические средства;

программные средства;

технические средства;

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

1.2.1. Информационная база

Данные, отражающие состояние определенной предметной области и используемые информационной системой, принято называть информационной базой. Информационная база состоит из двух компонент: 1) коллекции записей собственно данных; 2) описания этих данных — метаданных.

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

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

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

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

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

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

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

Рис. 1.2. Уровни представления данных

1.2.2. Лингвистические средства

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

Работа с базами данных предполагает несколько этапов:

описание БД;

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

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

загрузка БД и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее распространенным языком для работы с базами данных является SQL (Structured Query Language), в своих последних реализациях предоставляющий не только средства для спецификации и обработки запросов на выборку данных, но также и функции по созданию, обновлению, управлению доступом и т. д.

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

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

1.2.3. Программные средства

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

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

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

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

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

Рис. 1.3. Программные средства СУБД

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

Именно централизованное управление данными обеспечивает:

сокращение избыточности в хранимых данных;

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

стандартизацию   представления  данных,   упрощающую   эксплуатацию БД;

разграничение доступа к данным;

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

1.2.4. Технические средства

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

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

Для повышения надежности хранения часто используют специализированные дисковые подсистемы — RAID (Redundant Array of Inexpensive Disks). Один логический RAID-диск — это несколько физических дисков, объединенных в одно устройство, управляемое специализированным контроллером, что позволяет распределять основные и системные данные между несколькими носителями (дисками), в том числе дублировать данные. Таким образом, в случае повреждения одного из дисков, можно оперативно восстановить потерянные данные.

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

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

1.2.5. Организационно-административные подсистемы

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

1.3. Пользователи баз данных

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

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

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

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

1.4. Типология баз данных

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

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

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

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

По топологии хранения данных различают локальные и распределенные БД.

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

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

По сфере возможного применения можно различать универсальные и специализированные (или проблемно-ориентированные) системы.

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

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

1.4.1. Типология баз данных с точки зрения информационных процессов

С другой стороны, БД могут соотноситься с различными уровнями информационных процессов: уровень информационных технологий (ИТ), уровень системы (ИС), уровень информационных ресурсов (ИР).

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

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

При рассмотрении на уровне информационных ресурсов БД трактуется как элемент мировых ИР. Основной характеристикой здесь является содержание БД, хотя и структуры данных также немаловажны.

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

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

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

Среди АИ ПС в узком смысле принято выделять:

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

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

В более широком смысле под АИПС подразумеваются также программные оболочки, ориентированные на разработку продуктов типа АИПС (в узком смысле). Это связанно с тем фактом, что первые системы типа СУБД и оболочек АИПС были предложены в 60-е—70-е гг. фирмой IBM (и сотрудничавшими с ней организациями) и включали в себя:

IMS/360  (Information  Management  System)  —  по-видимому, первую реальную СУБД, поддерживавшую так называемую иерархическую модель данных (понятие появилось позже, в связи с необходимостью систематизации СУБД), нашедшую достаточно широкое применение (в частности, для информационного обеспечения проекта Apollo, завершившегося,  как известно, высадкой граждан США на Луну в 1969 г.);

DPS/360 (Document Processing System) — первый промышленный пакет прикладных программ (ППП), предназначенный для реализации документальных АИПС. В дальнейшем на основе развития принципов DPS, фирмой в 1972 г. был выпущен пакет STAIRS (STorage And Information Retrieval System), предназначенный для диалогового,обслуживания  множества (удаленных) пользователей;

IRMS (Information Retrieval and Management System), TEXT-РАС и другие аналогичные пакеты.

Как это следует из наименований продуктов, разработчики понимали под АИПС именно ППП-оболочки.

Системы управления базами данных и программирования АИС. Среди различных программных средств данного класса следует различать три типа:

СУБД в «чистом виде» (IMS, CETOP и пр.);

СУБД с элементами систем программирования АИС (ADABAS/NATURAL, ORACLE);

системы программирования АИС с элементами СУБД (FoxBase / FoxPro, Clipper).

Первый тип фактически относится к начальному этапу развития систем второго (реже — третьего) типов. В этом случае СУБД состоит только из системы интерпретации вызовов (обращений) из пользовательской программы (call-interface) на выборку (корректировку, занесение) информации из/в БД, причем программа написана на одном из универсальных языков программирования (ЯП), таких как Кобол, Фортран, Паскаль и пр., получивших название включающие языки СУБД. Данная система в последующих СУБД (второй тип) получила наименование ядра. Соглашения о форматах и структурах такого взаимодействия обычно пытаются оформить в виде некоторого формального языка (языка ядра). В частности, вдохновленная успехами в разработке и распространении универсального ЯП PL/1 (Programming Language #1), фирма IBM разработала описание форматов интерфейса пользовательских программ с БД IMS в форме языка DL/1 (Data Language #1), который, однако, значительного успеха не имел.

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

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

установление и поддержание связей между зависимыми данными;

удобство использования данных.

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

1.5. Семантика баз данных

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

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

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

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

Рис. 1.4. Информационная модель преобразования

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

Соотношение понятий «величина», «контекст» и «значение» приведено на рис.1.5. Здесь значение, получаемое на уровне 1, на следующем рассматривается в свою очередь как величина, которая будет интерпретироваться в соответствии с контекстом своего уровня6.

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

Рис. 1.5. Соотношение понятий «величина», «контекст» и «значение»

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

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

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

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

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

В отличие от ранее рассмотренного фактографического представления, для вербальной формы представления факта (выражениями языка с использованием лингвистических переменных) характерно то, что для задания имени, значения и контекста может использоваться единый способ и средства — лингвистические переменные одного и того же языка. Например, описание весовых свойств может быть представлено несколькими, но имеющими один смысл, вариантами предложений: «Чугунная заготовка весом 29 килограммов» или «Чугунная заготовка имеет свойство m = 29, где m — вес в килограммах».

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

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

Рис. 1.6. Схема процесса автоматизированного решения задач

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

  1.  Хорошо  структурированная  информация,  представляемая  в графическом или специальном формате. Например, структурные химические формулы, конструкторская документация и т. д. В этом случае для автоматической обработки требуются узкоспециализированные средства, что приводит к общей неунифицированности представления семантических элементов (например, графических примитивов) на уровне данных.
  2.  Информация, точная по содержанию, но вариантно представляемая по форме. Например, описание в текстовом виде численно задаваемых  параметров  изделия.  Лингвистические  переменные  в этом случае имеют точное значение, однако построение универсальной процедуры автоматического выделения факта из текста трудоемко и потому нецелесообразно.
  3.  Слабоструктурированная  информация, обычно представляемая в текстовой форме. Например, учебная или научная публикация, где новые понятия строятся на основании ранее определенных. В этом случае лингвистические переменные могут принимать новые,  ранее не определенные значения,  которые определяются контекстом — ближним (словосочетания) или общим (темой сообщения).

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

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

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

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

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

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

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

контекстным определением — использованием специализированных языков разметки (например, HTML или XML), задающим индивидуальные особенности представления материала каждого документа.

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

1.6. Типология моделей

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

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

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

Рис. 1.7. Система моделей представления информации

Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются более статичным элементом, чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа, как диаграммы потоков данных (Data Flow Diagram). Развитие реляционных баз данных в свою очередь стимулировало развитие методик построения моделей данных, и в частности, ER-диаграмм (Entity Relationship Diagram). Однако и функциональная декомпозиция и диаграммы потоков данных дают только некоторый срез исследуемой предметной области, но не позволяют получить представление системы в целом.

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

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

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

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

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

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

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

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

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

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

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

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


2. БАЗОВЫЕ ТЕХНОЛОГИИ И ОСНОВНЫЕ ЭТАПЫ РАЗВИТИЯ МАШИННОЙ ОБРАБОТКИ ДАННЫХ

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

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

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

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

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

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

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

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

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

Рис. 2.1. Примерная схема организации ввода-вывода

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

2.2. Примерная схема организации файлового ввода-вывода

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

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

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

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

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

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

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

  1.  Определение адреса записи в координатах устройства (например, для файлов с записями фиксированной длины — пересчет номера нужной записи в относительный адрес сектора и далее определение абсолютного номера сектора на диске).
  2.  Перемещение головки чтения в соответствующую координату:
    позиционирование к дорожке и сектору на дорожке, складывающееся из двух действий — собственно радиального перемещения головки на расстояние от текущего положения до нужной дорожки и ожидания подхода указанного сектора вращающегося диска к позиции, где находится головка. Следует также отметить, что высокая плотность записи данных означает, что промежуток между секторами
    12 и дорожками сравнительно мал (сопоставим с погрешностями механизма перемещения и тепловым расширением), и поэтому правильность позиционирования определяется по служебным данным заголовка13 сектора, считываемым до начала передачи прикладных данных.
  3.  Пересылка данных, расположенных в области кластера, в буфер, который физически может быть как частью устройства, так и областью оперативной памяти.
  4.  Завершение операции (проверка корректности чтения, например по контрольной сумме) и возврат управления ОС для обработки считанных данных.
  5.  Выделение системой данных, относящихся к затребованным записям. Причем во многих случаях в системный буфер считываются не только данные логической записи, нужные прикладной программе, но и соседние. Это позволяет сократить суммарные затраты времени при чтении нескольких записей, исключив наиболее долгую операцию позиционирования. Указание на такое блокирование может выдаваться явно прикладной программой при открытии файла или операционной системой, использующей собственные механизмы кэширования для оптимизации14 ввода-вывода.
  6.  Передача в рабочую область прикладной программы данных запрошенной ею логической записи или указателя на соответствующую область памяти в системном буфере.

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

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

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

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

Практическое решение состоит во введении контролируемой функциональной и информационной избыточности, обеспечивающей сокращение времени доступа за счет: 1) специализации компонент, т. е. упрощения процедур преобразований; 2) построения вспомогательных структур (в той или иной степени дублирующих основную информацию). Основой этого подхода является принцип выделения и представления описательных составляющих в виде самостоятельных операционных объектов, хранимых отдельно от определяемых ими данных15.

2.3. Эволюция концепций обработки данных

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

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

2.3.1. Простые (линейные) файлы данных (начало 60-х гг.)

Для линейных «простых» файлов организация хранения и доступа характеризуется следующими особенностями (рис. 2.2):

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

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

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

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

Рис. 2.2. Линейные файлы данных

2.3.2. Методы доступа к записям (конец 60-х гг.)

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

Рис. 2.3. Методы доступа к записям

Организация хранения и доступа в этом случае характеризуется следующими особенностями:

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

файл создается в прикладной программе как набор данных с
последовательным, индексно-последовательным или с прямым доступом (по физическому адресу). Возможен последовательный или произвольный доступ к записям (но не к полям). Поиск по многим ключам, как правило, не используется. Если используются иерархические файлы, то взаимосвязь «исходный — порожденный» программируется в прикладной программе;

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

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

2.3.3. Первые системы управления базами данных (начало 70-х гг.)

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

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

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

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

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

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

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

2.3.4. Системы управления базами данных

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

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

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

Для этого вводятся два уровня независимости данных (рис. 2.5).

Рис. 2.5. Два уровня независимости данных

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

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

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

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

Для систем управления базами данных также характерны следующие особенности:

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

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

2.4. Схема управления данными в СУБД

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

(1) — прикладная программа (клиентское приложение) формирует и выдает системе управления базами данных запрос на чтение необходимых данных, содержащихся в базе;

(2—3) — СУБД отыскивает описание затребованных данных в структуре описания данных прикладного уровня (внешняя модель);

(4—5) — СУБД по глобальному описанию БД (концептуальная схема) определяет необходимые данные на логическом уровне;

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

(8—9) — СУБД через подсистему управления потоками данных выдает операционной системе запрос на чтение хранимой записи;

(10—11) — подсистема управления вводом-выводом операционной системы осуществляет физическое чтение записи в системный буфер ОС;

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

Рис. 2.6. Схема обработки запроса на выборку данных из БД

2.5. Данные и управление их обработкой

2.5.1. Типы, форматы, структуры данных

Структура информационных единиц, обрабатываемых на ЭВМ, определяется следующими понятиями:

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

структуры данных — способы композиции простых данных в агрегаты и операции над ними;

форматы файлов — представление информации им уровне
взаимодействия операционной системы с прикладными программами.

Типы данных. Ранние языки программирования — Фортран, Алгол — были ориентированы исключительно на вычисления и не содержали систем типов и структур данных. Типы числовых данных Алгола: INTEGER (целое число), REAL (действительное) — различаются диапазонами изменения, внутренними представлениями и применяемыми командами процессора ЭВМ (соответственно арифметика с фиксированной и плавающей точкой). Нечисловые данные представлены типом BOOLEAN — логические, имеющие диапазон значений {TRUE, FALSE}.

Появившиеся позже языки программирования COBOL, PL/1, Pascal уже предусматривают новые типы данных:

символьные (цифры, буквы, знаки препинания и пр.);

числовые символьные для вывода;

числовые двоичные для вычислений;

числовые десятичные (цифры 0—9) для вывода и вычислений.

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

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

Появление СУБД и АИ ПС приводит к появлению новых разновидностей структур:

множественные поля данных;

периодические групповые поля;

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

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

Например, в системе OS/360 основную роль играли два типа файлов:

символьные (исходные программы или данные);

двоичные (программы в машинных кодах).

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

2.5.2. Описание и обработка файлов

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

По-видимому достаточно подробное описание структур данных и установление их связи с файлами было впервые сделано в языке программирования Cobol (Common Business Oriented Language). Эта проблема была решена следующим образом — файл (набор данных на внешнем носителе) рассматривается как совокупность записей одинаковой структуры, каждая из которых представляет собой набор (агрегат) разнородных данных (в более поздних языках программирования — PL/1, Pascal, С, за подобными объектами так и закрепилось название «структура – structure»).

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

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

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

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

Рис. 2.7. Варианты размещения данных и их описания: а — в прикладной программе; б — в файле данных; в — отдельным набором данных (словарь данных)

2.6. Особенности и компромиссы реализаций баз данных

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

Файлы обладают следующими свойствами:

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

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

Базы данных имеют следующие особенности:

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

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

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

Коренное же отличие СУБД от файловых систем ОС состоит в том, что СУБД устанавливает связь между содержанием и адресом, а ОС — между именем и адресом данных.

В то же время эта граница постоянно подвергается «атакам» с обеих сторон. Например, ОС-360 с «индексным доступом к данным», IN-PICK, включающая язык поиска записей файлов по содержанию, UNIX, включающая команды сортировки, коррекции или объединения содержимого текстовых файлов, наподобие того, как это осуществляется с таблицами данных в СУБД. Тем не менее, следует признать это скорее исключением, чем правилом и в компетенцию ОС надо относить только связь «имя—адрес», оставляя другие зависимости на ответственность прикладных программ и оболочек СУБД и АИ ПС (автоматизированные информационно-поисковые системы).

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

1. Каким образом сложные нелинейные структуры данных представить в виде линейных — наиболее соответствующих принципу последовательного представления (хранения) в машинной памяти?

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

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

  1.  эффективность — простота;
  2.  скорость выборки — стоимость (сложность) аппаратных
    средств;
  3.  скорость выборки — сложность процедур доступа;
  4.  плотность данных — время доступа и сложность процедур;
  5.  независимость данных — производительность;
  6.  гибкость средств поиска — избыточность данных;
  7.  гибкость поиска — скорость поиска;
  8.  сложность процедур доступа — простота обслуживания.


3
. МОДЕЛИ И СТРУКТУРЫ ДАННЫХ

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

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

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

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

3.1. Многоуровневые модели предметной области

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

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

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

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

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

Соотношение этих понятий приведено на рис. 3.1.

Рис. 3.1. Соотношение понятий концептуальной и внутренней схем

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

Теоретически вопрос о многообразии уровней абстракции был решен еще в 60—70-х гг. Основой для его решения является концепция многоуровневой архитектуры системы базы данных. Например, в отчете CODASYL предусматривался архитектурный уровень подсхемы, который позволял для каждого конкретного приложения строить свое собственное «видение» используемого подмножества базы данных путем определения его «персональной» подсхемы базы данных.

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

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

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

Рис. 3.2. Варианты решений трехуровневого представления

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

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

Рассмотренная трехуровневая архитектура обеспечивает выполнение основных требований, предъявляемых к системам баз данных:

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

возможность взаимодействия с БД разных пользователей при
решении разных прикладных задач;

обеспечение независимости программ и данных;

надежность функционирования БД и защита от несанкционированного доступа.

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

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

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

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

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

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

3.2. Идентификация объектов и записей

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

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

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

Так же как и в реальном мире, отдельный объект всегда уникален (уже хотя бы потому, что мы именно его выделяем среди других). Соответственно, запись, содержащая данные о нем, также должна быть узнаваема однозначно (по крайней мере, в рамках предметной области), т. е. иметь уникальный идентификатор, причем никакой другой объект не должен иметь такой же идентификатор. Поскольку идентификатор — суть значение элемента данных, в некоторых случаях для обеспечения уникальности требуется использовать более одного элемента. Например, для однозначной идентификации записей о дисциплинах учебного плана необходимо использовать элементы СЕМЕСТР и НАИМЕНОВАНИЕ ДИСЦИПЛИНЫ, так как возможно преподавание одной дисциплины в разных семестрах.

Предложенная выше схема представляет атрибутивный способ идентификации содержания объекта (рис. 3.3).

Рис. 3.3. Атрибутивный способ идентификации

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

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

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

3.3. Поиск записей

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

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

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

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

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

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

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

Рис. 3.4 Способы хранения ключа и атрибута

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

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

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

В контексте задач поиска можно сказать, что существуют два основных способа организации данных. Первый соответствует примеру, приведенному на рис. 3.3, и представляет прямую организацию массива. Второй способ является инверсией первого, он соответствует рис. 3.4. Прямая организация массива удобна для поиска по условию «Каковы свойства указанного объекта?», а инвертированная — для поиска по условию «Какие объекты обладают указанным свойством?».

Приведем следующую типологию простых (атомарных) запросов:

  1.  А(Е) = ? Каково значение атрибута А для объекта Е?
  2.  А(?) = V Какие объекты имеют значение атрибута, равное V?
  3.  ?(Е) = V Какие атрибуты объекта Е имеют значение, равное V?
  4.  ?(Е) = ? Какие значения атрибутов имеет объект I?
  5.  А(?) = ? Какие значения имеет атрибут А в наборе?
  6.  ?(?) = V Какие атрибуты объектов набора имеют значение,
    равное
    V?

Здесь в запросах типов 2, 3, 6 вместо оператора равенства может быть использован другой оператор сравнения (больше, меньше, неравно или другие).

Запросы типа 1 выполняются поиском по «прямому» массиву: доступ к записи производится по первичному ключу. Запросы типа 2 выполняются поиском по инвертированному списку: доступ к записи(ям) производится по указателю, выбираемому из списка по значению вторичного ключа. Ответом в этих случаях будет значение атрибута или идентификатора. Запросы типа 3 имеют ответом имя атрибута.

Запросы типа 2, 5, 6 относятся к нескольким атрибутам, и в этом случае могут быть построены несколько индексов, облегчающих поиск по этим ключам.

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

Следует отметить, что в контексте обработки запросов 2-го типа «Какие объекты имеют заданное значение атрибута?» можно выделить три следующих типа архитектур доступа.

  1.  Системы с вторичными индексами. В этих системах последовательность расположения записей соответствует последовательности
    значений первичного ключа. Как правило, используется один первичный индекс и несколько вторичных.
  2.  Системы частично инвертированных файлов. В этих системах
    записи могут располагаться в произвольной последовательности.
    В отличие от систем первого типа первичный индекс отсутствует. Вторичные индексы применяются для прямой адресации записей, что существенно облегчает включение в файл новых записей, так как допускается их размещение в любом свободном участке файла.
  3.  Системы полностью инвертированных файлов. В этих системах предусмотрено наличие файлов, содержащих значения отдельных элементов данных, входящих в состав записей, — допускается раздельное хранение элементов данных записи. Значения элементов данных, составляющих конкретную запись или кортеж, в общем случае могут размещаться в памяти  произвольно. Для ускорения процесса поиска в системе используют два набора индексов: индекс экземпляров (значений ключей) и индекс данных (инвертированный список). С помощью индекса экземпляров можно найти в файле элементы данных, имеющих заданное значение. С помощью индекса данных можно найти записи, связанные с заданными значениями элементов. Такая организация характерна для организации данных документальных информационных систем.

3.4. Представление предметной области и модели данных

Если бы назначением базы данных было только хранение и поиск данных в массивах записей, то структура системы и самой базы была бы простой. Причина сложности в том, что практически любой объект характеризуется не только параметрами-величинами, но и взаимосвязями частей или состояний. Есть различия и в характере взаимосвязей между объектами предметной области: одни объекты могут использоваться только как характеристики остальных объектов, другие — независимы и имеют самостоятельное значение (рис. 3.6).

Рис. 3.6. Этапы преобразования представлений предметной области

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

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

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

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

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

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

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

Необходимо отметить, что предметные среды с точки зрения описания целесообразно условно разделить на два полярных случая:

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

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

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

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

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

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

как средство спецификации типов данных и их организации,
разрешенных в конкретной БД;

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

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

• как основа разработки семейства языков запросов и языков
манипулирования данными;

• как основа архитектуры СУБД;

• как основа изучения динамических свойств различных организаций данных.

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

Модель базы данных охватывает более широкий спектр понятий. Основное назначение модели базы данных состоит в том, чтобы:

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

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

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

3.5. Структуры данных

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, структура данных — это способ отображения значений в памяти: размер области и порядок ее выделения (который и определит характер процедуры адресации/выборки). Зачастую именно успешность структурирования данных определяет сложность процедур их обработки.

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

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

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

3.5.1. Линейные структуры

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

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

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

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

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

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

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

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

3.5.2. Нелинейные структуры

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

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

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

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

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

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

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

Рис. 3.7. Пример структуры типа дерево

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

1. Самый верхний уровень иерархии имеет один узел, называемый корнем.

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

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

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

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

Выделяют три метода обхода: сверху вниз, слева направо, снизу вверх.

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

Рис. 3.8. Примеры сбалансированных и не- Рис. 3.9. Пример несбаланси-
                сбалансированных деревьев             рованного двоичного дерева

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

Двоичные деревья — это особая категория сбалансированных древовидных структур, в которой допускается не более двух ветвей для одного узла. На рис. 3.9 показано несбалансированное двоичное дерево.

Любые связи в дереве можно представить в виде двоичных древовидных структур. Рис. 3.10 иллюстрирует представление дерева в виде двоичного дерева.

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

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

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

Рис. 3.10. Пример представления дерева в виде двоичного

3.5.3. Сетевые структуры

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

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

Рис. 3.11. Примеры сетевых структур

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

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

На рис. 3.12 показана неоднородная сетевая структура с пятью типами элементов. Ни одна из их соединяющих линий не имеет сдвоенных стрелок в обоих направлениях. Каждое отношение может рассматриваться как отношение «исходный — порожденный». Запись ЗАКАЗ-НА-ЗАКУПКУ является порожденной по отношению к записи ИЗДЕЛИЕ и исходной по отношению к записи ПАРТИЯ-ТОВАРА.

Рис. 3.12. Пример простой сетевой структуры

Желательно отличать структуры, в которых представление отношений «порожденный — исходный» является простым или не используется, от структур, в которых представление отношений между какими-то двумя типами данных является сложным в обоих направлениях. Для структур второго типа на одной из линий схемы будут сдвоенные стрелки, указывающие в разные стороны. Этот тип схемы назовем сложной сетевой структурой, а схему, в которой ни на одной из линий нет сдвоенных стрелок в обоих направлениях, — простой сетевой структурой. На рис. 3.12 показана простая сетевая структура. Она станет сложной, если ввести отношение ЗАКАЗ-НА-ЗАКУПКУ — ИЗДЕЛИЕ, когда один заказ может быть сделан сразу на несколько изделий. Для образования сложной сетевой структуры достаточно двух типов элементов. Например, ПОСТАВЩИК может иметь несколько порожденных записей, потому что может поставляться более одного вида изделий. С другой стороны, элемент ИЗДЕЛИЕ может иметь более одного исходного элемента, поскольку это изделие может поставляться различными поставщиками.

В некоторых случаях один элемент данных может быть связан с целой совокупностью других элементов данных. Например, одно изделие может поставляться несколькими поставщиками, каждый из которых установил свою цену на это изделие. Элемент данных ЦЕНА не может быть ассоциирован только с элементом ИЗДЕЛИЕ или только с элементом ПОСТАВЩИК, а должен быть связан одновременно с двумя. Информация такого рода, т. е. данные, ассоциированные с совокупностью элементов, называют иногда данными пересечения.

Некоторые структуры содержат циклы. Циклом считается ситуация, в которой предшественник узла является в то же время его последователем. Отношения «исходный — порожденный» образуют при этом замкнутый контур. Например, завод выпускает различную продукцию. Некоторые изделия производятся на других заводах-субподрядчиках. С одним контрактом может быть связано производство нескольких изделий. Представление этих отношений и образует цикл.

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

Рис. 3.13. Пример сетевой структуры с петлей

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

3.6. Реляционная модель данных

3.6.1. Основные понятия реляционной модели данных

Реляционная21 модель является удобной и наиболее привычной формой представления данных в виде таблицы. В отличие от иерархической и сетевой моделей, такой способ представления: 1) понятен пользователю-непрограммисту; 2) позволяет легко изменять схему — присоединять новые элементы данных и записи без изменения соответствующих подсхем; 3) обеспечивает необходимую гибкость при обработке непредвиденных запросов. К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

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

Рис 3.14. Основные понятия реляционной модели

Таблица 3.1

Домен

Совокупность допустимых значений

Кортеж

Таблица

Кардинальность

Количество строк в таблице

Атрибут

Поле, столбец таблицы

Степень отношения

Количество полей (столбцов)

Первичный ключ

Уникальный идентификатор

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

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

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

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

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

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

Модель предъявляет к таблицам следующие требования:

  1.  данные в ячейках таблицы должны быть структурно неделимыми22;
  2.  данные в одном столбце должны быть одного типа;
  3.  каждый столбец должен быть уникальным (недопустимо дублирование столбцов);
  4.  столбцы размещаются в произвольном порядке;
  5.  строки размещаются и таблице также в произвольном порядке;
  6.  столбцы имеют уникальные наименования.

В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда.

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

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

определение данных;

определение представлений;

обработку данных (интерактивную и программную);

условия целостности;

идентификацию прав доступа;

границы транзакций (начало, завершение и отмена).

  1.  Правило обновления представлений. Все представления, которые
    теоретически можно обновить, должны быть доступны для обновления.
  2.  Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при добавлении, обновлении и удалении данных.
  3.  Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом
    уровне оставаться нетронутыми при любых изменениях способов
    хранения данных или методов доступа к ним.
  4.  Правило независимости логических данных. Прикладные программы и утилиты для работы с данными должны на логическом
    уровне оставаться нетронутыми при внесении в базовые таблицы
    любых изменений, которые теоретически позволяют сохранить не
    тронутыми содержащиеся в этих таблицах данные.
  5.  Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной
    базы данных и хранить их в каталоге, а не в прикладной программе.
  6.  Правило независимости распространения. Реляционная СУБД
    не должна зависеть от потребностей конкретного клиента.
  7.  Правило единственности. Если в реляционной системе есть
    низкоуровневый язык (обрабатывающий одну запись за один раз),
    то должна отсутствовать возможность использования его для того,
    чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).

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

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

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

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

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

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

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

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

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

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

3.6.2. Основы реляционной алгебры

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

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

Реляционная алгебра в том виде, в котором она была определена Э. Ф. Коддом, состоит из двух групп по четыре оператора.

  1.  Традиционные операции над множествами (но модифицированные с учетом того, что их операндами являются отношения, а не произвольные множества): объединение, пересечение, разность и декартово произведение.
  2.  Специальные реляционные операции: выборка, проекция, соединение, деление.

Рассмотрим подробнее операции реляционной алгебры.

Объединение возвращает отношение, содержащее все кортежи, которые принадлежат либо одному из двух заданных отношений, либо им обоим (рис. 3.15).

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

Разность возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух заданных отношений и не принадлежат второму (рис. 3.17).

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

Выборка возвращает отношение, содержащие все кортежи из заданного отношения, которые удовлетворяют указанным условиям (рис. 3.19)

Рис. 3.15. Объединение

Рис. 3.16. Пересечение

Рис.3.17. Разность

Рис.3.18. Произведение

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

 

Рис. 3.19. Выборка

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

Рис. 3.20. Проекция

Рис. 3.21. Соединение

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

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

Рис. 3.22. Деление

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

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

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

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

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

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

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

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

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

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

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


4. ФИЗИЧЕСКИЕ МОДЕЛИ БАЗ ДАННЫХ

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

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

4.1. Организация данных на машинных носителях

С общепринятой точки зрения к вопросам организации данных относятся:

выбор типа записи — единицы обмена в операциях ввода-вывода;

выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;

• выбор способа адресации и метода доступа к записям.

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

4.1.1. Типы записей

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

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

Рис. 4.1. Способы организации файлов данных

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

На логическом уровне выделяют следующие типы:

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

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

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

Рис. 4.2. Физическая организация логических записей

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

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

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

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

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

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

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

4.1.2. Организация файлов — способ размещения записей

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

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

Выбор последовательности связывается с одним из следующих обстоятельств:

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

Можно выделить две «чистые» стратегии определения места (адреса) для размещения записей: последовательное (sequential) и произвольное (random) размещение. В этом смысле алгоритм размещения определяет тип организации файла.

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

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

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

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

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

Рис. 4.3. Способы организации файлов

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

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

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

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

4.1.3. Способы адресации и методы доступа к записям

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

В некоторых файлах записи имеют несколько ключей. Запись ЗАКУПКА может иметь различные НОМЕР ПОСТАВЩИКА и НОМЕР ПОКУПАТЕЛЯ, каждый из которых является ключом.

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

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

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

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

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

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

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

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

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

Таким образом, двоичный поиск более пригоден для поиска в индексе файла, чем в самом файле.

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

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

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

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

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

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

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

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

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

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

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

Более экономичным является указание на область, в которой размещается группа записей. Эта область называется участком записей (slot, bucket).

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

  1.  Ключ записи преобразуется в квазислучайное число, находящееся в диапазоне от 1 до числа участков, используемых для размещения записей.
  2.  Число преобразуется в адрес участка и, если на участке есть
    свободное место, то логическая запись размещается на нем.
  3.  Если участок заполнен, запись должна быть размещена на участке переполнения — следующий по порядку участок либо участок в отдельной области переполнения.

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

Из-за вероятностной природы алгоритма в этом способе не удается достичь 100 % плотности заполнения памяти, однако для большинства файлов может быть достигнута плотность 80 или 90 %; при этом память для индексов не требуется. Большинство записей можно найти за одно обращение, но для некоторых потребуется второе обращение (при переполнении). Для очень небольшой части записей потребуется третье или четвертое обращение к файлу.

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

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

4.1.4. Схемы организации данных на внешних носителях

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

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

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

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

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

На рис. 4.4 приведена схема индексно-последовательного файла, в который добавлены три новые записи.

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

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

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

Рис. 4.4. Схема индексно-последовательного файла после добавления записей

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

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

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

Резюмируя, перечислим способы включения в файл новых записей.

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

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

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

4.2. Физическое представление иерархических структур

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

  1.  Физически последовательное размещение.
  2.  Указатели.
  3.  Цепи и кольца.

На рис. 4.5 и 4.6 представлен пример иерархической структуры до и после обновления.

Рис. 4.5. Пример древовидной структуры

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

Рис. 4.6. Пример древовидной структуры после обновления

4.2.1. Физически последовательное размещение

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

Рис. 4.7. Пример реализации древовидной структуры до обновления

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

Последовательность элементов на рис. 4.7 иногда называется левосписковой структурой (последовательность типа «сверху вниз — слева направо»).

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

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

А1(В2(С5С12С6)В1(С12С9)ВЗ(С14С11С7С18))

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

4.2.2. Левосписковые структуры с переполнениями

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

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

Рис. 4.9. Пример реализации древовидной структуры методом переполнения

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

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

4.2.3. Использование указателей на «подобные» и «порожденные»

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

указатели на порожденные записи;

указатели на подобные записи;

указатели на исходные записи.

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

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

Рис. 4.11. Пример реализации древовидной структуры (см. рис. 4.5) с использованием ссылок «порожденный — подобный» (штрихованные области означают конец списка)

Рис. 4.12. Пример реализации древовидной структуры с использованием кольцевых ссылок

На рис. 4.12 ссылки образуют кольца двух типов: подобных записей и кольца «исходный порожденный». В записях самого нижнего уровня показаны указатели на исходные записи. Для единообразия здесь каждая запись имеет два указателя. Однако кольца большей частью создаются двусторонними. В этом случае число указателей в каждой записи увеличится до четырех.

4.3. Физическое представление сетевых структур

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

4.3.1. Физически последовательное размещение

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

Рис. 4.13. Пример простой сетевой структуры

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

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

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

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

4.3.2. Использование указателей

Если для реализации сетевых структур используются указатели, то они должны представлять все связи, причем какие-то записи должны называться исходными (например, верхние), а какие-то — порожденными (нижние записи).

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

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

Рис. 4.15. Пример реализации сетевой структуры с использованием указателей

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

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

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

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

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

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

На рис. 4.17 и 4.18 приведен пример разделения линейных записей исходной таблицы «Штатное расписание факультета» (рис. 4.16) на связи и собственно данные.

Рис. 4.16. Пример набора записей табличного типа

Рис. 4.17. Пример разделения на связи и данные набора записей табличного типа (данные)

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

Такое представление обладает следующими важными свойствами:

каждый элемент таблицы — это один элемент данных;

таблица не содержит одинаковых строк, т. е. содержащих попарно равных значений элементов данных;

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

Рис. 4.18. Пример разделения на связи и данные набора записей табличного типа (связи)

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

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

Однородность реляционных баз данных, построенных на основе бинарных отношений, обеспечивает:

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

простоту расширения состава логической записи.

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

4.4. Архитектура файловой организации баз данных

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

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

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

4.4.1. Файл-ориентированная организация данных

Этот подход отражает точку зрения «идейно чистого» программирования, выражающуюся в стремлении к построению модульных процедур, ориентированных на обработку регулярных однородных данных27: «сколько типов структур записей — столько и файлов» (рис. 4.19).

Рис. 4.19. Два подхода к организации данных

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

4.4.2. Страничная организация данных

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

позволило реализовать даже однофайловую28 физическую  структуру СУБД.

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

При распределении дискового пространства рассматривается следующая схема структуризации пространства в зависимости от типов данных:

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

Каждый экстент используется для хранения одного из нескольких типов страниц: страницы данных, страницы индексов, страницы blob-объектов29 (неструктурированных данных, например, большие текстовые или двоичные данные). То есть данные на одной странице являются однородными: страница, например, может хранить только данные или только индексы.

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

Все страницы данных имеют одинаковую структуру, включающую:

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

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

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

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

4.5. Модели распределения данных по физическим носителям

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

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

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

Примером, иллюстрирующим подход с точки зрения практических компромиссов выбора решения, являются RAID-массивы. На рис. 4.20 приведены два варианта: RAID-0, обеспечивающий максимальную производительность при «стандартной» надежности, и RAID-1, обеспечивающий «двойную» надежность при «стандартной» производительности.

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

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

Рис. 4.20. Распределение данных в RAID-массивах

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

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

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

 5. МОДЕЛИ И ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

5.1. Модели многоуровневой архитектуры систем баз данных

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

Опубликованный в 1975 году отчет ANSI/X3/SPARC зафиксировал не только широкое признание концепций многоуровневой архитектуры систем баз данных, но и необходимость явного выделения специального концептуального уровня представления базы данных, единого для всех ее приложений и независимого от них. Кроме этого уровня предусматривались еще два уровня: внутренний уровень, который должен обеспечивать поддержку представления хранимой базы данных, и внешний, поддерживающий представления базы данных «с точки зрения» приложений. На каждом архитектурном уровне предполагалось использование той или иной модели данных. Кроме того, на внешнем (прикладном, пользовательском) уровне таких моделей может быть несколько. Модели, а также схемы, специфицируемые на их основе, называются соответственно внешней, концептуальной и внутренней.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О развитии и конкурировании моделей. По аналогии с ситуацией 70-х гг., когда велись споры о преимуществах сетевой, иерархической и реляционной модели данных (как известно, завершившиеся «ничейным» исходом открытой дискуссии Ч. Бахмана и Э. Кодда на Конференции ACM SIGMOD в 1975 г.), в настоящее время сформировались новая тройка конкурентов — реляционная, объектная и многомерная модели.

Хотя, строго говоря, здесь речь идет лишь о двух моделях. Действительно, многомерные модели, коммерческие реализации которых появились в начале 90-х гг. для поддержки технологий OLAP не основаны на каких-либо радикально новых идеях. Они представляют собой некоторое расширение активно исследовавшейся в 70—80-х п. модели универсальных отношений новыми операционными возможностями, обеспечивающими, в частности, необходимые для OLAP функции агрегирования данных. Таким образом, многомерные модели представляют собой особую разновидность реляционной модели.

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

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

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

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

5.2. Стадии проектирования и объекты моделирования

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

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

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

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

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

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

Характер взаимосвязей (и, соответственно, отличий) проявляется и в процессе проектирования системы баз данных. Модель предметной области скорее ассоциируется с неформальным33 уровнем семантического моделирования, а модель базы данных — с формализованным уровнем системы (и в частности, СУБД). В идеале целью семантического моделирования является формирование систематического основания для хорошо формализованного процесса проектирования базы данных. Здесь необходимо вспомнить следующие требования, предъявляемые к базам данных, и, в частности, к способам описания данных:

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

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

Забегая несколько вперед, рассмотрим взаимосвязь двух известных методов семантического моделирования инфологического уровня — ER-диаграммы (EREntity Relation) и метода нормализации, воспринимаемых зачастую как альтернативные. На самом деле нормализация с помощью хорошо формализованных методов обеспечивает декомпозицию исходных отношений (переменных) большой размерности к возможно большему набору отношений, но меньшей размерности. Эти методы не зависят от особенностей предметной области (семантики обрабатываемых данных), но вследствие этого и не позволяют определить исходное отношение. Для этого удобнее использовать методики, подобные ER-диаграммам — для них свойственны подходы технологии нисходящего проектирования, которые дают представление «в целом», но именно поэтому (из-за сравнительной простоты) не позволяют провести полноценное проектирование базы. То есть, можно сказать, что метод нормализации и ER-диаграммы по существу являются взаимодополняющими.

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

Рассмотрим основные стадии процесса34 моделирования, представленные на рис. 5.1.

Рис. 5.1. Стадии и объекты процесса проектирования

5.3. Системный анализ предметной области

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

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

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

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

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

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

Есть простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее «обеспечения», а также их основные взаимосвязи. На рис. 5.2 показана таблица, аналогичная схеме Захмана. Три столбца обозначают три раздела обеспечения системы: информационный (ДАННЫЕ), функциональный (ФУНКЦИИ) и коммуникационный (СЕТЬ).

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

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

Рис. 5.2. Модель информационной системы Захмана

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

Рис. 5.3. Развитие модели информационной системы Захмана

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

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

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

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

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

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

5.4. Модели и технологии инфологического проектирования реляционных БД

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

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

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

для многих приложении трудно моделировать предметную область на основе плоских таблиц;

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

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

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

5.4.1. Инфологическое проектирование и семантическая модель

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

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

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

формализованность, обеспечивающую возможность автоматизированной обработки, в том числе, например, автоматический контроль непротиворечивости;

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

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

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

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

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

5.4.2. Модель «Сущность — связь»

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

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

Семантическую основу ER-модели составляют следующие предположения:

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

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

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

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

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

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

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

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

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

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

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

Рис, 5.4. Пример ER диаграммы

Сущность имеет имя, уникальное в пределах модели. При этом имя сущности — это имя типа, а не некоторого конкретного экземпляра.

Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности — сильной по отношению к ней. Например, сущность «Подчиненный» является слабой no отношению к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны быть удалены.

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

Свойство может быть множественным или единичным — т. е. атрибут, задающий свойство, может одновременно иметь несколько значений или, соответственно, ТОЛЬКО одно. Например, сотрудник может имен, несколько специальностей, но единственное значение — «Табельный номер».

Свойство может быть простым (не подлежащим дальнейшему делению с точки зрения прикладных задач) или составным — если его значение составляется из значений простых свойств. Например, свойство «Год рождения» является простым, а свойство «Адрес» — составным, так как включает значения простых свойств «Город», «Улица», «Дом».

В некоторых случаях полезно различать базовые и производные свойства. Например, «Поставщик» может иметь свойство «Общее количество поставляемых деталей», которое вычисляется суммированием количества деталей, поставляемых им по проекту.

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

Значения свойств могут быть постоянными – статическими или динамическими, т. е. меняться со временем. Например, свойство «Табельный номер» является статическим, а «Адрес» — динамическим. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано.

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

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

Как и сущность, связь является типовым понятием, т.e. все экземпляры связываемых сущностей подчиняются правилам связывания типов. Принципиальность различия типов связей между типами и экземплярами иллюстрируется ЕR-диаграммами для типов и экземпляров, представленными на рис. 5.5.

Рис. 5.5. Примеры ER-диаграмм для типов и экземпляров сущностей

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

Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае — неполным (или необязательным).

Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1:M), «многие к одному» (М:1), «многие ко многим» (М:М)39.

Следует отметить, что инструмент связей — это средство представления сложных объектов, каждый из которых может рассматриваться как множество некоторым образом взаимосвязанных простых объектов. Деление на простые и сложные объекты, также как и характер взаимосвязи, является условным и определяется особенностями анализа предметной области, т. е. в конце концов — характером использования данных о предметах в решаемых прикладных задачах. При этом с точки зрении, например, конструктора, ДЕТАЛЬ является сложным объектом, а с точки зрения поставщика — простым.

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

Отношение «часть — целое» используются для представления составных объектов. Например, МАШИНЫ состоят из УЗЛОВ, УЗЛЫ состоят из ДЕТАЛЕЙ. Здесь возможны как отношения «один ко многим», так и «многие ко многим».

Отношение «род – вид» для представления обобщенных объектов. Например, СОТРУДНИКИ подразделяются по профессии на КОНСТРУКТОРОВ, ПРОГРАММИСТОВ, РАБОЧИХ; ПРОГРАММИСТЫ на ПРИКЛАДНЫХ ПРОГРАММИСТОВ и СИСТЕМНЫХ ПРОГРАММИСТОВ. Иерархические отношения, и в частности «родо-видовые», обычно используются как основа классификации объектов по наборам характеристических признаков. Причем «видовые» объекты наследуют свойства «родовых».

Другой широко используемой разновидностью взаимосвязи является агрегирование объединение простых объектов в сложный по принципу их принадлежности агрегату или их совместного участия в некотором процессе. Агрегирование, рассматриваемое здесь как более общий случай иерархических отношений, объединяет объекты разной природы с единственным общим свойством «совместное участие». Агрегированные объекты именуются обычно отглагольными существительными, например, «Состав»: ПОДРАЗДЕЛЕНИЕ состоит из СОТРУДНИКОВ; «Поставка»: ПОСТАВЩИК поставляет ДЕТАЛИ.

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т. е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например, ПРОЧИЕ.

Подтип наследует свойства и связи супертипа. Например, тип сущности ПРОГРАММИСТ является подтипом сущности СОТРУДНИК. Программисты обладают всеми свойствами сотрудников и участвуют во всех связях, однако обратные утверждения неверны.

Тип сущности, его подтипы, подтипы этих подтипов и т. д. образуют иерархию типов сущности, пример которой приведен на рис. 5.6.

Рис. 5.6. Пример иерархии типов сущности

5.4.3. ER диаграмма

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

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

Сущности. Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника, содержащего имя сущности. В качестве имени обычно используются существительные (или обороты существительного) в единственном числе. Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями. Например, в рассматриваемой далее ER-диаграмме, приведенной на рис. 5.4, ПОДЧИНЕННЫЙ — сущность слабого типа.

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

Имена ключевых свойств подчеркиваются, например, свойство «Табельный номер» сущности СОТРУДНИК.

Контур эллипса рисуется двойной линией, если свойство многозначное, например, свойство «Специальность» сущности СОТРУДНИК.

Контур эллипса рисуется штриховой линией, если свойство производное, например, свойство «Кол-во» сущности ПОСТАВЩИК.

Эллипс соединяется пунктирной линией, если свойство условное, например, свойство «Иностранный язык» сущности СОТРУДНИК.

Если свойство составное, то составляющие его свойства отображаются другими эллипсами, соединенными с ЭЛЛИПСОМ составного, например, СВОЙСТВО «Адрес» сущности СОТРУДНИК состоит из простых свойств «Город», «Улица», «Дом».

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

Стороны ромба рисуют двойными линиями, если это связь сущности слабого типа с сущностью, от которой она зависит. Например, связь «Подчинение», связывающая сущность слабого типа ПОДЧИНЕННЫЙ с сущностью СОТРУДНИК, от которой она зависит.

Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны. Например, связь «Подчинение» со стороны сущности ПОДЧИНЕННЫЙ.

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

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать многие сотрудники.

5.4.4. Нормальные формы ER-диаграмм

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

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

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

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

На рис. 5.7 представлена ER-диаграмма рис. 5.4 в третьей нормальной форме.

Рис. 5.7. Пример ER-диаграммы в третьей нормальной форме

5.5. Даталогические модели

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

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

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

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

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

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

5.5.1. Получение реляционной схемы из ER диаграммы

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

  1.  Каждый атрибут становится возможным столбцом с тем же
    именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие
    обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.
  2.  Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, то к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
  3.  Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.
  4.  Индексы создаются для первичною ключа (уникальный индекс), а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах.
  5.  Если в концептуальной схеме присутствуют подтипы, то возможны два варианта.

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

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

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

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

5.6. Физические модели

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

выбор способа организации базы данных, основные из которых были рассмотрены ранее;

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

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

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

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

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


6. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

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

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

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

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

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

6.1. Универсальное отношение

Рассмотрим задачу проектирования БД на базе сводной таблицы, пример которой приведен на рис. 6.1. Предложенная таблица отражает результаты сдачи сессии (шкала оценок: 0 — незачет; 1 — зачет; 2, 3, 4, 5 — экзаменационная оценка).

Этот вариант таблицы «Сессия» не является отношением, так как большинство ее столбцов не атомарны. Атомарными являются лишь значения столбцов «ФИО студента», «Семестр». Остальные столбцы таблицы — множественные.

ФИО

студента

Семестр

Дисциплина

Форма отчетности

Оценка

Количество часов

ФИО

преподавателя

Иванов В.П.

1

Английский язык

зачет

1

60

Цветкова А.Ю.

Математический анализ

зачет

1

28

Рыбин К. К.

Математический анализ

экзамен

5

32

Раков И.И.

Программирование

зачет

1

36

Незабудкина З.П.

Программирование

экзамен

5

32

Зайчиков А.А.

Линейная алгебра

зачет

1

24

Волков Г.И.

Линейная алгебра

экзамен

4

28

Волков Г.И.

История Отечества

экзамен

5

24

Москвин А.П.

Петрова А.П.

1

Английский язык

зачет

1

60

Цветкова А. Ю.

Математический анализ

зачет

1

28

Рыбин К. К.

Математический анализ

экзамен

3

32

Раков И.И.

Программирование

зачет

1

36

Незабудкина З.П.

Программирование

экзамен

4

32

Зайчиков А.А.

Линейная алгебра

зачет

1

24

Волков Г.И.

Линейная алгебра

экзамен

4

28

Волков Г.И.

История Отечества

экзамен

5

24

Москвин А.П.

Сидоров К.К.

3

Английский язык

зачет

1

60

Цветкова А.Ю.

Математический анализ

зачет

1

28

Карпов К.Ю.

Математический анализ

экзамен

5

32

Раков И.И.

Программирование

зачет

1

36

Незабудкина З.П.

Теория вероятностей

и математическая статистика

экзамен

4

32

Соболев И.Г.

Операционные системы, среды и оболочки

зачет

1

36

Незабудкина З.П.

Операционные системы, среды и оболочки

экзамен

4

32

Незабудкина З.П.

Экономическая теория

зачет

1

24

Лабиринтов Е.Н.

Рис. 6.1. Исходные данные для создания БД «Сессия»

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

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

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

ФИО

студента

Семестр

Дисциплина

Форма отчетности

Оценка

Количество часов

ФИО

преподавателя

Иванов В.П.

1

Английский язык

зачет

1

60

Цветкова А.Ю.

Иванов В.П.

1

Математический анализ

зачет

1

28

Рыбин К. К.

Иванов В.П.

1

Математический анализ

экзамен

5

32

Раков И.И.

Иванов В.П.

1

Программирование

зачет

1

36

Незабудкина З.П.

Иванов В.П.

1

Программирование

экзамен

5

32

Зайчиков А.А.

Иванов В.П.

1

Линейная алгебра

зачет

1

24

Волков Г.И.

Иванов В.П.

1

Линейная алгебра

экзамен

4

28

Волков Г.И.

Иванов В.П.

1

История Отечества

экзамен

5

24

Москвин А.П.

Петрова А.П.

1

Английский язык

зачет

1

60

Цветкова А. Ю.

Петрова А.П.

1

Математический анализ

зачет

1

28

Рыбин К. К.

Петрова А.П.

1

Математический анализ

экзамен

3

32

Раков И.И.

Петрова А.П.

1

Программирование

зачет

1

36

Незабудкина З.П.

Петрова А.П.

1

Программирование

экзамен

4

32

Зайчиков А.А.

Петрова А.П.

1

Линейная алгебра

зачет

1

24

Волков Г.И.

Петрова А.П.

1

Линейная алгебра

экзамен

4

28

Волков Г.И.

Петрова А.П.

1

История Отечества

экзамен

5

24

Москвин А.П.

Сидоров К.К.

3

Английский язык

зачет

1

60

Цветкова А.Ю.

Сидоров К.К.

3

Математический анализ

зачет

1

28

Карпов К.Ю.

Сидоров К.К.

3

Математический анализ

экзамен

5

32

Раков И.И.

Сидоров К.К.

3

Программирование

зачет

1

36

Незабудкина З.П.

Сидоров К.К.

3

Теория вероятностей

и математическая статистика

экзамен

4

32

Соболев И.Г.

Сидоров К.К.

3

Операционные системы, среды и оболочки

зачет

1

36

Незабудкина З.П.

Сидоров К.К.

3

Операционные системы, среды и оболочки

экзамен

4

32

Незабудкина З.П.

Сидоров К.К.

3

Экономическая теория

зачет

1

24

Лабиринтов Е.Н.

Рис. 6.2. Универсальное соотношение «Сессия»

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

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

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

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

Студенты

Преподаватели

Дисциплины

ФИО студента

ФИО преподавателя

Дисциплина

1

Иванов В.П.

1

Волков Г.И.

1

Алгоритмы и структуры данных

2

Петрова А.П.

2

Зайчиков А.А.

2

Английский язык

3

Сидоров К.К.

3

Карпов К.Ю.

3

История Отечества

4

Лабиринтов Е.Н.

4

Линейная алгебра

5

Москвин А.П.

5

Математический анализ

6

Незабудкина З.П.

6

Операционные системы

7

Раков И.И.

7

Программирование

8

Рыбин К.К.

8

Теория вероятностей и математическая статистика

9

Соболев И.Г.

9

Экономическая теория

10

Цветкова А.Ю.

Учебный план

Результаты сессии

Дисциплина

Семестр

Кол-во часов

Форма отчетности

Препода-ватель

Студент

Учебный план

Оценка

1

2

1

60

зачет

10

1

1

1

2

3

1

24

экзамен

5

1

2

5

3

4

1

24

зачет

1

1

3

1

4

4

1

28

экзамен

1

1

4

4

5

5

1

28

зачет

8

1

5

1

6

5

1

32

экзамен

7

1

6

5

7

7

1

36

зачет

6

1

7

1

8

7

1

32

экзамен

2

1

8

5

9

2

3

60

зачет

10

2

1

1

10

5

3

20

зачет

3

2

2

5

11

5

3

28

экзамен

7

2

3

1

12

1

3

32

экзамен

2

2

4

4

13

8

3

32

экзамен

9

2

5

1

14

6

3

36

зачет

6

2

6

3

15

6

3

32

экзамен

6

2

7

1

16

9

3

24

зачет

4

2

8

4

Рис. 6.3. Разделение универсального соотношения «Сессия»

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

Теперь при изменении названия «Математический анализ» на «Мат.анализ» исправляется единственное значение в таблице «Дисциплины». И даже если оно вводится с ошибкой, то это не может повлиять на связь между дисциплиной, преподавателем и студентом (в связующей таблице «Результаты сессии» используются номера дисциплин учебною плана, а не их названия).

6.2. Функциональная и многозначная зависимости

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

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

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

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

Функциональная зависимость, по сути, является связью типа «многие к одному» между множествами атрибутов (столбцов) рассматриваемого отношения.

Например, в таблице «Учебный план» (см. рис. 6.3) столбцы Дисциплина, Семестр и Форма отчетности функционально зависят от ключа №(порядковый номер) в учебном плане, а в таблице «Результаты сессии» столбец Оценка функционально зависит oт составного ключа (Студент, Учебный план).

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

В качестве примера рассмотрим фрагмент таблицы «Прием экзаменов (зачетов)», изображенный на рис. 6.4. Таблица отражает связь дисциплины и формы отчетности с фамилией преподавателя. В этой таблице существует многозначная зависимость «Дисциплина Преподаватель»: дисциплину «Математический анализ» ведут несколько преподавателей (Раков И. И., Рыбин К. К., Карпов К. Ю.) и, соответственно, все они могут участвовать в приеме экзаменов (зачетов). Другая многозначная зависимость – «Дисциплина — Форма отчетности»: по одной и той же дисциплине могут проводиться и экзамен, и зачет. При этом Форма отчетности и Преподаватель не связаны функциональной зависимостью, что приводит к появлению избыточности (чтобы добавить фамилию еще одного преподавателя, придется ввести в таблицу две новые строки).

Дисциплина

Преподаватель

Форма отчетности

Математический анализ

Раков И. И.

экзамен

Математический анализ

Рыбин К. К.

экзамен

Математический анализ

Карпов К. Ю.

экзамен

Математический анализ

Раков И. И.

зачет

Математический анализ

Рыбин К. К.

зачет

Математический анализ

Карпов К. Ю.

зачет

Рис. 6.4. Фрагмент таблицы «Прием экзаменов (зачетов)»

6.3. Нормальные формы

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

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

Из таблиц, рассмотренных ранее, не удовлетворяет этим требованиям (т. е. не находится в 1НФ) только таблица на рис. 6.1.

Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее атрибуты (столбцы), не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.

Не удовлетворяют этим требованиям таблицы, представленные на рис. 6.1 и на рис. 6.2. Таблица 6.2 имеет составной первичный ключ (ФИО студента, Семестр, Дисциплина, Форма отчетности) и содержит множество неключевых атрибутов (Оценка, Количество часов, ФИО преподавателя), зависящих лишь от той или иной части первичною ключа. Так, атрибуты Количество часов и ФИО преподавателя зависят только от атрибутов Семестр, Дисциплина, Форма отчетности. Следовательно, эти атрибуты не связаны с первичным ключом полной функциональной зависимостью.

Ко второй нормальной форме приведены все таблицы рис. 6.3.

Таблица находится в третьей нормальной форме (3НФ), если она удовлетворяет определению 2НФ и ни один из ее неключевых атрибутов не связан функциональной зависимостью с любым другим неключевым атрибутом.

Таблица «Учебный план» (рис. 6.3), очевидно, не находилась бы в третьей нормальной форме, если включала бы в себя столбец Должность преподавателя, в этом случае необходимо было бы про вести декомпозицию таблицы «Учебный план» и в результате получить дополнительную таблицу «Кадровый состав» с атрибутами: , ФИО преподавателя, Должность преподавателя.

Следует отметить, что в таблице «Учебный план» на самом деле существует функциональная зависимость между атрибутами Количество часов и ФИО преподавателя, с одной стороны, и совокупностью атрибутов Семестр, Дисциплина и Форма отчетности с другой. Однако тройка атрибутов (Семестр, Дисциплина и Форма отчетности) в свою очередь может выступать в качестве первичного ключа, который представлен в таблице атрибутом Порядковый номер. Чтобы избегать в процессе нормализации подобных противоречий, Кодд, и Бойс обосновали и предложили более строгое определение для ЗНФ, которое учитывает, что в таблице может быть несколько первичных ключей.

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

В соответствии с этой формулировкой таблица «Учебный план» находится в НФБК или в 3НФ.

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

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

Например, применив операцию соединения (см. п. 3.6.2) к таблицам, приведенным на рис. 6.3, можно получить таблицу, приведенную на рис. 6.2. Следовательно, совокупность таблиц рис. 6.3 является полной декомпозицией таблицы «Сессия», приведенной на рис. 6.2.

Далее дадим определения высших нормальных форм.

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

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

6.4. Процедура нормализации

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

Рассмотрим процедуру приведения таблиц к НФБК.

Такая процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А→К, где К – первичный ключ, а А – некоторый атрибут. Принцип «один факт в одном месте» говорит о том, что не должно существовать в рамках таблицы никаких других функциональных зависимостей. Цель нормализации и состоит в удалении этих «других» функциональных зависимостей. Рассмотрим два возможных случая.

  1.   Таблица имеет составной первичный ключ вида, скажем, (K1,
    К2), и включает также атрибут А, который функционально зависит
    от части этого ключа (например, от К2), но не от полного ключа.
    В этом случае рекомендуется сформировать другую таблицу, содержащую атрибуты К2 и А (первичный ключ К2), и удалить атрибут
    А из первоначальной таблицы;
  2.  Таблица имеет первичный (возможный) ключ К, атрибут А1, который не является возможным ключом, но функционально зависит от К, и другой неключевой атрибут А2, который функционально зависит от А1. Решение здесь, по существу, то же самое, что и прежде формируется другая таблица, содержащая атрибуты А1 и А2, с первичным ключом A1, а атрибут А2 удаляется из первоначальной таблицы.

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

Применим приведенные правила для полной нормализации универсального отношения «Сессия» (рис. 6.2).

1. Определение первичного ключа таблицы.

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

ФИО студента, Дисциплина, Семестр, Форма отчетности.

2. Выявление атрибутов, функционально зависящих от части составного ключа.

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

Учебный план (Дисциплина, Семестр, Форма отчетности, Количество часов, ФИО преподавателя).

Из исходной таблицы при этом удаляются атрибуты Количество часов и ФИО преподавателя:

Результаты сессии (ФИО студента, Дисциплина, Семестр, Форма отчетности, Оценка).

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

Учебный план (№Учебного плана, Дисциплина, Семестр, Форма отчетности, Количество часов, ФИО преподавателя).

Результаты сессии (ФИО студента, №Учебного плана, Оценка).

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

6.5. Пример проектирования реляционной БД

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

выполнение текущего учебного плана;

формирование ведомостей по отдельным дисциплинам для групп студентов;

формирование листов зачетных книжек студентов;

формирование сводной ведомости курса;

расчет среднего балла по дисциплинам и т. п.

Приведем этапы построения инфологической и даталогической моделей (ЕR-диаграммы и реляционной схемы) для решения такой задачи.

6.5.1. Построение ЕR-диаграммы

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

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

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

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

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

ER-диаграмма рассматриваемой задачи представлена на рис 6.5.

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

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

 

Рис. 6.5. ER-диаграмма рассматриваемой задачи

Взаимодействие новой сущности с сущностью «Дисциплина учебного плана» осуществляется посредством новой связи «Читает». Мощность связи – «Многие к одному» (М:1), т. е. несколько дисциплин учебного плана может читать один преподаватель.

Измененная ER-диаграмма представлена на рис. 6.6. Новый вариант ЕК диаграммы находится в третьей нормальной форме, так как сущности не имеют свойств, зависящих от неключевых.

Рис. 6.6. Нормализованная ER-диаграмма

 6.5.2. Построение реляционной схемы

Следующий этап проектирования – построение даталогической модели. В рассматриваемом случае задача этого этапа — преобразование ER-диаграммы в реляционную схему (см. п. 5.5.1).

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

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

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

Рис. 6.7. Реляционная схема после первого этапа преобразования

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

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

Связь «Читает» предполагает добавление в таблицу «Учебный план» столбца ID_Преподаватель. Реляционная схема со связями представлена на рис. 6.8.

Рис. 6.8. Реляционная схема со связями

6.5.3. Нормализация таблиц

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

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

Рассмотрим подробнее таблицу «Учебный_план», которая содержит перечень дисциплин текущего учебного плана. Первичным ключом таблицы служит столбец ID_План, который однозначно характеризует каждую дисциплину учебного плана с точностью до семестра, т. е. для дисциплин, протяженность изучения которых более одного семестра, в таблице будет отведено столько строк, сколько семестров длится изучение дисциплины. Тогда хранение наименований дисциплин в таблице «Учебный_план» становится избыточным: например, если изучение английского языка длится шесть семестров, то наименование «Английский язык» будет повторено в шести записях и есть вероятность сделать шесть различных ошибок при вводе одного и того же наименования.

Чтобы избежать этого, проведем декомпозицию отношения «Учебный план», выделив наименования дисциплин в отдельное отношение. В результате получим дополнительную таблицу «Дисциплины» со столбцами ID_Дисциплина и Наименование, а столбец Наименование в таблице «Учебный план» заменим столбцом ID__Дисциплина, сформировав тем самым вторичный ключ, связывающий новую таблицу с таблицей «Учебный_план».

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

«Студенты» — содержит по одной строке для каждого из студентов;

«Учебный_план» — содержит по одной строке для отдельной
дисциплины отдельного семестра;

«Дисциплины» — содержит по одной строке для наименования дисциплины;

«Сводная_ведомость» — содержит по одной строке дня каждого результата сдачи отдельным студентом отдельной дисциплины;

«Кадровый_состав» — содержит по одной строке для каждого
из преподавателей.

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

Рис. 6.9. Структура базы данных «Сессия»

Все таблицы базы данных «Сессия» находятся в третьей нормальной форме:

каждый столбец таблицы неделим, и в рамках одной таблицы
нет столбцов с одинаковыми по смыслу значениями (1НФ);

первичные ключи однозначно определяют запись и неизбыточны, все поля каждой из таблиц зависят от ее первичного ключа (2НФ);

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

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

Исходя из особенностей данных и их функционального назначения, требуется задать способ представления и границы возможных изменений для каждого из столбцов таблиц. При этом необходимо ответить на вопрос: данные каких типов должны храниться в столбцах и какова их максимальная длина (например, если в столбце предполагается хранить процентные значения, то достаточно будет целого типа данных длиной 1 байт, так как диапазон возможных значений — от 0 до 255; если для данных столбца выбирается тип «строка символов», то желательно указать максимальный размер данных столбца и т. п.).

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

Следующий важный момент – задание для столбцов значений
по умолчанию. Значение по умолчанию впоследствии будет автоматически вводиться в указанный столбец для каждой строки таблицы. Например, в столбец
Дата_сдачи таблицы «Сводная ведомость» при заполнении очередной строки может автоматически заносится текущая дата.

Ниже, на рис.6.10 представлены таблицы базы данных «Сессия» с типами данных столбцом и предлагаемыми ограничениями целостности.

Таблица «Студенты»

Наименование столбца

Тип данных

Ограничения

ID_Студент

Целое число

Значение уникально

Фамилия

Строка символов размером 30

Значение не должно быть пустым

Имя

Строка символов размером 15

Значение не должно быть пустым

Отчество

Строка символов размером 20

Значение не должно быть пустым

Номер группы

Целое число

Значение не должно быть пустым

Адрес

Строка символов размером 30

Телефон

Строка символов размером 8

Таблица «Дисциплины»

Наименование столбца

Тип данных

Ограничения

ID_Дисциплина

Целое число

Значение уникально

Наименование

Строка символов размером 20

Значение уникально

Таблица «Кадровый_состав»

Наименование столбца

Тип данных

Ограничения

ID_Преподаватель

Целое число

Значение уникально

Фамилия

Строка символов размером 30

Значение не должно быть пустым

Имя

Строка символов размером 15

Значение не должно быть пустым

Отчее ню

Строка символов размером 20

Значение не должно быть пустым

Должность

Строка символов размером 20

Значение не должно быть пустым

Кафедра

Строка символов размером 3

Значение не должно быть пустым

Адрес

Строка символов размером 30

Телефон

Строка символов размером 8

Таблица «Учебный план»

Наименование столбца

Тип данных

Ограничения

ID_План

Целое число

Значение уникально

ID_Дисциплина

Целое число

Значение не должно быть пустым

Семестр

Целое число

Значение не должно быть пустым и должно находиться в интервале от 1 до 10

Количество часов

Целое число

ID_Преподаватель

Целое число

Таблица «Сводная ведомость»

Наименование столбца

Тип данных

Ограничения

ID_Студент

Целое число

Значение не должно быть пустым

ID_План

Целое число

Значение не должно быть пустым

Оценка

Целое число

Значение не должно быть пустым и должно находиться в интервале от 0 до 5

Дата сдачи

Дата-время

Значение не должно быть пустым, по умолчанию – текущая дата

Рис.6.10. Таблицы базы данных «Сессия»


7. ТРАНЗАКЦИИ И ЦЕЛОСТНОСТЬ БД

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

Рассмотрим два аспекта целостности — на уровне отдельных объектов и операций и на уровне базы данных в целом.

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

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

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

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

Транзакция – неделимая с точки зрения воздействия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации), такая, что:

1) либо результаты всех операторов, входящих в транзакцию, отображаются в БД;

2) либо воздействие всех этих операторов полностью отсутствует.

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

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

Рис. 7.1. Выполнение и откат транзакции

7.1. Модели транзакций

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

Автоматическое выполнение транзакций.

В стандарте ANSI/ISO зафиксировано, что транзакция автоматически начинается с выполнения пользователем или программой первой инструкции SQL. Далее происходит последовательное выполнение инструкций до тех пор, пока транзакция не завершается одним из двух способом (рис. 7.2):

инструкцией COMMIT, которая выполняет завершение транзакции: изменения, внесенные в БД, становятся постоянными, а новая транзакция начинается сразу после инструкции COMMIT;

инструкцией ROLLBACK, которая отменяет выполнение текущей транзакции и возвращает БД к состоянию начала транзакции, новая транзакция начинается сразу после инструкции ROLLBACK.

Такая модель создана на основе модели, принятой в СУБД DB2.

Управляемое выполнение транзакций.

Отличная от модели ANSI/ISO модель транзакций используется в СУБД Sybase, где применяется диалект Transact-SQL, в котором для обработки транзакций служат четыре инструкции (см. рис. 7.3):

инструкция BEGIN TRANSACTION сообщает о начале транзакции, т. е. начало транзакции задается явно;

инструкция COMMIT TRANSACTION сообщает об успешном выполнении транзакции, но при этом новая транзакция не начинается автоматически;

инструкция SAVЕ TRANSACTION позволяет создать внутри транзакции точку сохранения и присвоить сохраненному состоянию имя точки сохранения, указанное в инструкции;

• инструкция ROLLBACK отменяет выполнение текущей транзакции и возвращает БД к состоянию, где была выполнена инструкция SAVE TRANSACTION (если в инструкции указана точка сохранения — ROLLBACK TO имя точки сохранения), или к состоянию начала транзакции.

Рис. 7.2. Модель автоматического выполнения транзакций

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

7.2. Журнал транзакций

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

Основным принципом согласованной политики записи изменений в журнал и непосредственно в базу данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) — «пиши сначала в журнал», и состоит в том, что если требуется сохранить во внешней памяти измененный объект базы данных, то перед этим нужно гарантировать сохранение во внешней памяти журнала записи о его изменении.

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

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

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

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

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

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

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

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

Для восстановления базы данных СУБД имеют в своем составе сервисные программные средства:

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

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

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

Программы отката ликвидируют последствия выполнения определенной транзакции в БД.

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

7.3. Параллельное выполнение транзакций

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

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

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

7.3.1. Пропавшие обновления

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

Диспетчер 1 начинает работу по изменению таблицы «Учебный план» для Дисциплины 1 с количеством часов, равным 50.

В столбец ID_Преподаватель для этой дисциплины предполагается внести значение 5. Запрос текущей нагрузки преподавателя возвращает значение 350, и Диспетчер 1 подтверждает изменение таблицы «Учебный_план». При этом выполняются дополнительные действия по изменению столбца Нагрузка в таблице «Кадровый_состав» для строки с ID_Преподаватель = 5 (в столбец заносится значение 400).

Рис. 7.4. Проблема пропавшего изменения

До завершения операции Диспетчер 2 начинает те же действия для Дисциплины 2 с количеством часов 32, которую должен читать тот же преподаватель (ID_Преподаватель = 5). Запрос текущей нагрузки преподавателя также возвращает значение 350, с которым и работает дальше Диспетчер 2. Выполнив те же операции, что и Диспетчер 1 (но после него), Диспетчер 2 помещает в столбец Нагрузка значение 382, отменив тем самым предыдущие изменения (рис. 7.4).

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

7.3.2. Чтение «грязных» данных

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

Рис. 7.5. Проблема чтения «грязных» данных

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

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

7.3.3. Чтение несогласованных данных

Рассмотрим ситуацию, которая приводит к получению несогласованных данных при выполнении операций над БД (рис. 7.6).

Рис. 7.6. Проблема чтения несогласованных данных

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

Начинам работу практически одновременно с Диспетчером 1, Диспетчер 2 получает следующие сведения: нагрузка первого преподавателя (ID_Преподаватель = 5) составляет 350 часов, а нагрузка второго преподана геля (ID Преподаватель = 7) составляет 370 часов. Далее Диспетчер 2 принимает решение в пользу первого преподавателя, но повторный запрос нагрузки возвращает значение 400, так как Диспетчер 1 уже сохранил новые данные в таблице « Кадровый_состав».

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

7.3.4. Строки-призраки

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

Диспетчер 1 инициирует Транзакцию 1, которая выполняет оператор выборки строк таблицы в соответствии с некоторым условием (например, формирование списка студентов, сдавших дисциплину с ID_Дисциплина — N, по таблице «Сводная_ведомость»). До завершения Транзакции 1 Транзакция 2, вызванная Диспетчером 2, вставляет в таблицу «Сводная ведомость» новую строку, удовлетворяющую условию отбора Транзакции 1 (данные о результате сдачи дисциплины N еще одним студентом), и успешно завершается. Транзакция 1 повторно выполняет оператор выборки, и в результате появляется строка, которая отсутствовала при первом выполнении оператора. Конечно, такая ситуация противоречит идее изолированности транзакций.

7.4. Сериализация транзакций

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

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

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

На самом деле между транзакциями могут существовать следующие виды конфликтов:

Транзакция 2 пытается изменять объект, измененный незакончившейся Транзакцией 1 (W-W — конфликт);

Транзакция 2 пытается изменять объект, прочитанный незакончившейся Транзакцией 1 (R-W — конфликт);

Транзакция 2 пытается читать объект, измененный незакончившейся Транзакцией 1 (W-R — конфликт).

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

7.5. Захват и освобождение объекта

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

совместный режим — S (Shared), означающий разделяемый захват объекта и необходимый для выполнения операции чтения объекта;

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

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