49302 (Управление базами данных)

Введение

Тема курсовой работы «Управление базами данных».

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

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

- поддержание логически согласованного набора файлов;

- обеспечение языка манипулирования данными;

- восстановление информации после разного рода сбоев;

- реально параллельная работа нескольких пользователей.

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

1. Реляционные СУБО

1. Основные понятия

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

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

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

Атрибут - это поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Например, АДРЕС может быть определен для многих сущностей: СОТРУДНИК, ОРГАНИЗАЦИЯ и т. д. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности СОТРУДНИК являются ФАМИЛИЯ, ИМЯ, ОТЕЧЕСТВО, ДОЛЖНОСТЬ, ОКЛАД, ПРИКАЗ, АДРЕС и т. д.

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

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

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

1. Типы связей

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

Связь «один-к-одному» (1:1). В каждый момент времени каждому представителю (экземпляру) сущности А только один экземпляр сущности В. Например, каждый СОТРУДНИК имеет один внутренний ПАСПОРТ.

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

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи «многие-к-одному» (М:1) (обратный связи «один-ко-многим») и «многие-ко-многим» (M:N), когда каждому экземпляру сущности А может соответствовать 0, 1 или не-сколько экземпляров сущности В, и наоборот. Как пример такой связи можно представить соотношение между СОТРУДНИКАМИ и ЯЗЫКАМИ (иностранными).

1. Первичные и внешние ключи

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

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

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

1. Целостность

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

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

Выделяют три группы правил целостности:

- целостность по сущностям;

- целостность по ссылкам;

- целостность, определяемая пользователем.

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

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

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

Основными понятиями реляционной модели являются (рис. 1.1):

- отношение (таблица);

- домен (значения столбца);

- атрибут (столбец, поле);

- кортеж (строка, запись).

Рис. 1.1. Определяющие компоненты реляционной базы данных

Наименьшая единица данных реляционной модели - это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой - как три различных значения. Наиболее правильной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен «Фамилия» в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут отображать фамилию. Данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов ФАМИЛИЯ и ИМЯ относятся к типу строковых данных, но не являются сравнимыми.

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

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

Рис. 1.2. Графическое представление отношений в настольной базе данных Access 2000

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

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

1. Реляционная БД

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

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

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

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

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

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

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

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

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

Управление данными во внешней памяти.

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

Управление оперативной памятью.

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

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

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

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

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

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

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

Поддержка языков БД.