Размещено на http://www.allbest.ru/

Контрольная работа

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

Содержание

• Базы данных и системы управления
• Файловые системы
• Концепция баз данных
• Основные функции СУБД
• Управление буферами оперативной памяти
• Управление транзакциями
• Журнализация
• Поддержка языков баз данных
• Трехуровневая модель архитектуры систем баз данных
• Модели данных
• Реляционный подход
• Ключи и целостность реляционных данных
• Моделирование концептуальной схемы базы данных
• Литература

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

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

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

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

Файловые системы

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

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

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

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

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

2. Данные

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

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

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

Номер рейса	Дни недели	Пункт отправл.	Время вылета	Пункт назнач.	Время прибыт.	Тип самолета	Стоимость билета
138	2_4_7	Минск	21.12	Москва	0.52	ИЛ-86	115.00
57	3_6	Ереван	7.20	Киев	9.25	ТУ-154	92.00
1234	2_6	Москва	22.40	Минск	23.50	ТУ-134	73.50
242	1 по 7	Киев	14.10	Москва	16.15	ТУ-154	57.00
86	2_3_5	Минск	10.50	Сочи	13.06	ИЛ-86	78.50
137	1_3_5	Москва	17.15	Минск	18.44	ИЛ-86	115.00
241	1 по 7	Москва	9.05	Киев	11.05	ТУ-154	57.00
577	1_3_5	Рига	21.53	Таллинн	22.57	АН-24	21.50
78	3_6	Сочи	18.25	Минск	20.12	ТУ-134	44.00
578	2_4_6	Таллинн	6.30	Рига	7.37	АН-24	21.50

Рис. 1. Разделение данных и их интерпретации

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

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

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

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

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

Концепция баз данных

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

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

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

СОЗДАТЬ ТАБЛИЦУ Расписание (Номер_РейсаЦелое, Дни_НеделиТекст (8), Пункт_Отправления Текст (24), Время_ВылетаВремя, Пункт_НазначенияТекст (24), Время_Прибытия Время, Тип_Самолета Текст (8), Стоимость_Билета Денежный);

и хранить его вместе с данными в файле базы данных "Аэропорт".

Язык запросов СУБД позволяет формулировать задачу поиска данных, например, запрос

ВЫБРАТЬ Номер_Рейса, Дни_Недели, Время_Вылета ИЗ ТАБЛИЦЫ Расписание ГДЕ Пункт_Отправления = 'Москва' И Пункт_Назначения = 'Минск' И Время_Вылета > `17';

позволяет получить расписание "Москва-Минск" на вечернее время, а по запросу

ВЫБРАТЬ КОЛИЧЕСТВО (Номер_Рейса) ИЗ ТАБЛИЦЫ Расписание ГДЕ Пункт_Отправления = 'Москва' И Пункт_Назначения = 'Минск';

получим количество рейсов "Москва-Минск".

Язык запросов применяется и для изменения таблиц. Например, расширить таблицу можно следующим способом:

ДОБАВИТЬ В ТАБЛИЦУ Расписание Длительность_Полета Время;

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

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

Основные функции СУБД

В отличие от приложений, почти все СУБД являются коммерческими продуктами, причем, подавляющую часть рынка захватили пять систем: Oracle, Access и SQL Server (Microsoft), FoxPro (Borland) и DB2 (IBM).

К числу основных функций СУБД принято относить следующие:

· создание самой базы данных, ее объектов и структур - таблиц, индексов…;

· модификация объектов и структур базы данных;

· ввод, чтение и изменение данных;

· обеспечение целостности данных;

· обеспечение безопасности данных;

· управление параллельной обработкой данных;

· создание резервных копий.

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

Непосредственное управление данными во внешней памяти

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

Управление буферами оперативной памяти

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

Управление транзакциями

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

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

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

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

- Атомарность - транзакции атомарны (выполняется все или ничего).

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

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

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

Журнализация

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

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

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

При ведении журнала придерживаются стратегии "упреждающей" записи (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта базы данных должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части базы данных. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления базы данных после любого сбоя.

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

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

Поддержка языков баз данных

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы базы данных (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил, главным образом, для определения логической структуры базы данных, т.е. той структуры базы данных, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в базу, удалять, модифицировать или выбирать существующие данные. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базами данных, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).

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

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

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

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



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

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

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

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

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

Модели данных

Итак, инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них является модель "сущность-связь" (Entity-Relationship или ER-диаграмма), которая была предложена Питером Ченом (Peter Chen) в 1975 году. Различные варианты этой модели используются для построения концептуальных схем. Ее базовыми элементами являются сущности, атрибуты, ключи и связи.

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

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

Между двумя сущностями А и В возможны три типа связей.

Связь "один-к-одному" (1:

1): в каждый момент времени каждому представителю сущности А соответствует 1 или 0 представителей сущности В, а каждому представителю сущности В соответствует 1 или 0 представителей сущности А (рис.4).

Взаимосвязь между данными при отношении между объектами 1:1

Студенты		Личное дело
Код студента (номер зачетной книжки)	Фамилия
0125	Ильин
0134	Петров
Код студента	Личное дело
0134	№1
0125	№2

Рис. 4.

Связь "один-ко-многим" (1: М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В, а любому представителю сущности В соответствует 1 или 0 представителей сущности А (рис. 5).

Взаимосвязь между данными при отношении между объектами 1: М

Студенты		Номер группы
Код студента	Фамилия	Номер группы
0125	Ильин	1
0134	Петров	1
0086	Комаров	2
Номер группы	Кафедра
1
2

Рис. 5.

Связь "многие-ко-многим" (N: М): каждому представителю сущности А может соответствовать множество представителей сущности В, а каждому представителю сущности В может соответствовать множество представителей сущности А (рис. 6).

Взаимосвязь между данными при отношении между объектами N: М

Фамилия		Изучаемые дисциплины
Фамилия
Ильин
Петров
Комаров
Изучаемые дисциплины
Топография
Молекулярная биология
Этика

Рис.6.

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

Иногда тип связи называют кардинальностью.

Компьютерно-ориентированные модели данных

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

В 1968 году компания IBM предложила первую СУБД - систему управления информацией IMS (Information Manager System), которая основана на иерархической модели данных. Такие модели строятся по принципу иерархии типов объектов, в которых должен быть только один корневой тип. На рис.7показан пример иерархической модели, в которой хранятся данные о клиентах (имя, фирма, адрес, телефон и т.п.), товарах (наименование, производитель, цена, количество в наличии и т.п.) и заказах на товары (дата, товар, количество, кто принял, кто выполнил, скидки и т.п.). Корневой тип объекта - КЛИЕНТЫ, который соединен связями "владения" с подчиненным (дочерним) объектом ЗАКАЗЫ. Он, в свою очередь, также владеет подчиненным объектом ТОВАРЫ. В такой модели можно создавать связи типа "один-ко-многим" и только в одном направлении. Все связи в модели сводятся к одной корневой сущности КЛИЕНТЫ.

Рис. 7. Иерархическая модель данных

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

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

Любой объект в сетевой модели может одновременно выступать и в роли главного, и в роли подчиненного, участвуя в связях различного типа. Связи - это набор физических указателей, которые задают отношения владения между сущностями без ограничения направления владения. На рис. 8 изображена сетевая модель, в которой сущность КЛИЕНТЫ участвует в связи типа "один-ко-многим" с сущностью ЗАКАЗЫ, а она, в свою очередь, - в связи такого же типа с сущностью КОЛИЧЕСТВО. Одновременно связь типа "один-ко-многим" организована между сущностями ТОВАРЫ и КОЛИЧЕСТВО. Связи типа "многие-ко-многим" с сетевых моделях непосредственно не задаются, а реализуются через третий объект. В нашем примере базовые сущности ЗАКАЗЫ и ТОВАРЫ, которые имеют тип связи "многие-ко-многим", соединены через сущность КОЛИЧЕСТВО двумя встречными наборами связей типа "один-ко-многим".

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

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

Рис. 1.6.5. Сетевая модель данных

Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных. Реляционная модель данных была предложена Е. Коддом (E. F. Codd) в 1970 году и в 80-х годах получила признание как наиболее эффективная модель разработки СУБД. Название "реляционная" возникло от английского термина "relation" - отношение. Это, по существу, математическое название для таблицы. Поэтому в большинстве случаев термины "отношение" и "таблица" можно считать синонимами.

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

Идея реляционной модели данных состоит в том, что строки таблицы с n колонками, состоящими из элементов множеств A1, A2, …, An, можно представить как подмножество в прямом произведении A1A2… An. Строки образуют список из n элементов, по одному из каждого множества Ai, а вся таблица представляет собой n-арное отношение. Например, таблица КЛИЕНТЫ можно рассматривать как подмножество множества A1A2A3A4, где A1 - множество кодов клиентов, A2 - множество имен клиентов, A3 - множество их адресов, An - множество названий организаций. Один из элементов этого отношения - строка К1, Андрей, Минск, ИНКО. Представленные таким образом таблицы можно обрабатывать, используя алгебру отношений на множествах.

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

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

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

Реляционный подход

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

база реляционная управление файл

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

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

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

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

Пример создания и удаления доменов:

CREATE DOMAIN Фамилия CHAR (20);

CREATE DOMAIN Зарплата NUMERIC (5);

DESTROY DOMAIN Зарплата;

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

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

Нет одинаковых кортежей;

Кортежи не упорядочены сверху вниз;

Атрибуты не упорядочены слева направо;

Все значения атрибутов атомарны.

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

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

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

Например, предикат отношения, изображенного на рис.10, может быть следующим: Сотрудник с определенным табельным номером (атрибут Табель) имеет определенную фамилию (атрибут Фамилия), определенную зарплату (атрибут Зарплата) и зарегистрирован в определенном отделе (атрибут Код_отдела); кроме того, нет двух сотрудников с одинаковыми табельными номерами. При обновлении атрибута Зарплата в кортеже

Табель='В3'; Фамилия= 'Котов'; Код_отдела='А3'; Зарплата='200';

предикат имеет значение истина, а в кортеже

Табель='В3'; Фамилия= 'Котов'; Код_отдела='А1'; Зарплата='200';

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

Ключи и целостность реляционных данных

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

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

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

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

Свойством уникальности (нет двух различных кортежей в отношении R с одинаковым значением K).

Свойством неизбыточности (никакое из подмножеств K не обладает свойством уникальности).

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

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

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

Сотрудники WHERE Табель='В3'

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

Сотрудники WHERE Код_отдела='А1'

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

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

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

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

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

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

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