Реляционная модель данных
Классификация БД
По технологии обработки данных БД подразделяются на централизованные и распределенные.
Централизованная БД хранится целиком в памяти одной вычислительной системы. Если система входит в состав сети, то возможен доступ к этой БД других систем.
Распределенная БД состоит из нескольких, возможно пересекающихся или дублирующих друг друга БД, хранимых в памяти разных вычислительных систем, объединенных в сеть.
По способу доступа к данным БД различают локальный (автономный) и удаленный (сетевой) доступ.
Локальный доступ предполагает, что СУБД обрабатывает БД, которая хранится на том же компьютере.
Удаленный доступ – это обращение к БД, которая хранится на одном из компьютеров, входящих в компьютерную сеть. Удаленный доступ может быть выполнен по принципу файл-сервер или клиент-сервер.
Архитектура файл-сервер (толстый клиент) предполагает выделение одного из компьютеров сети (сервер) для хранения централизованной БД. Все остальные компьютеры сети (клиенты) исполняют роль рабочих станций, которые копируют требуемую часть централизованной БД в свою память, где и происходит обработка. Однако при большой интенсивности запросов к централизованной БД увеличивается нагрузка на каналы сети, что приводит к снижению производительности ИС в целом.
При одновременном обращении нескольких клиентов к одному файлу, например, с целью его обновления, могут возникнуть проблемы, связанные с неоднозначностью определения его содержимого. Поэтому каждое изменение общедоступного файла выделяется в транзакцию – элементарную операцию по обработке данных, имеющую фиксированные начало, конец (успешное или неуспешное завершение) и ряд других характеристик.
Архитектура клиент-сервер (тонкий клиент) предполагает, что сервер, выделенный для хранения централизованной БД, дополнительно производит обработку клиентских запросов. Клиенты получают по сети уже обработанные данные. Учитывая широкое распространение БД в самых различных областях, в последнее время архитектура клиент-сервер применяется и на одиночных вычислительных системах. В этом случае клиент — программа, которой понадобились данные из БД, посылает запрос серверу — программе, управляющей ведением БД, на специальном универсальном языке запросов. Сервер пересылает программе данные, являющиеся результатом поиска в БД по ее запросу. Этот способ удобен тем, что программа-клиент не обязана содержать все функции поддержания и ведения БД, этим занимается сервер. В результате упрощается написание программ-клиентов. Кроме того, к серверу может обращаться любое количество клиентов.
Многозвенная архитектура предполагает наличие сервера приложений, на котором выполняется вся вычислительная работа, что позволяет уменьшить нагрузку на сервер БД.
Ещё более высокой надёжностью обладает распределенная архитектура, в которой вычислительная система состоит из нескольких компонент, распределённых по разным серверам. Специальные программы-мониторы следят за корректностью работы каждого из компонентов и, при необходимости, запускают дублирующие компоненты на других компьютерах.
Для реализации основных функций в ИС используются различные принципы описания данных. Ядром любой БД является модель представления данных. Рассмотрим реляционную модель данных, характеризующейся организацией данных в виде двумерных таблиц и возможностью использования формального аппарата алгебры отношений. Реляционная (от английского слова relation – отношение) модель данных является наиболее универсальной, к ней могут быть сведены другие модели (иерархическая и сетевая).
Важнейшим понятием реляционных моделей данных является сущность. Сущность — это объект любой природы, данные о котором хранятся в БД. Для представления данных об объектах и их взаимосвязях используются отношения. Каждое отношение – это реляционная таблица. Каждый конкретный экземпляр сущности представляется совокупностью элементов строки, которая называется кортежем (или записью). Каждый столбец есть домен (альтернативные названия – атрибут и поле) по имени которого группируются данные различных экземпляров сущности. Строка заголовков называется схемой отношения. Количество доменов определяет степень отношения, количество кортежей — его мощность.
Каждая реляционная таблица должна обладать следующими свойствами:
• один элемент таблицы — один элемент данных;
• все столбцы таблицы содержат однородные по типу данные (целочисленный, числовой, текстовый, и т.д.);
• каждый столбец имеет уникальное имя;
• число столбцов задается при создании таблицы;
• порядок записей в отношении может быть произвольным;
• записи не должны повторяться;
• количество записей в отношении не ограничено.
Структура простейшей базы, состоящей из одной таблицы, представлена полями (столбцами) и записями (строками). Даже если в базе нет ни одной записи (пустая база), это всё равно полноценная база – в ней содержится информация о методах хранения данных, хотя сами данные пока отсутствуют – её структура представлена набором полей. Например, простейшая телефонная записная книжка имеет чёткую структуру (имя абонента и его телефонный номер), что позволяет отличить её от блокнота или ежедневника, даже если в неё не записали ни одной строки.
Первичным ключом отношения называется поле или группа полей, однозначно определяющие запись. В отношении СТУДЕНТ первичным ключом может быть поле ФАМИЛИЯ, если во всем списке нет однофамильцев — это будет простой ключ. Если есть однофамильцы, то совокупность полей — фамилия, имя, отчество — создадут составной первичный ключ. На практике обычно в качестве простого первичного ключа выбирают поле, в котором совпадения заведомо исключены. Для рассматриваемого примера таким полем может служить номер зачетной книжки или читательского билета, или другой идентификатор, код которого уникален для каждого студента.
Обычно в базе содержится не одна а несколько связанных таблиц. Например, если в отношении СТУДЕНТ надо описать вуз, в котором он обучается, то, на первый взгляд, можно было бы включить в отношение СТУДЕНТ следующие поля: ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГРУППА, НАЗВАНИЕ вуза, АДРЕС вуза. Но при заполнении такой таблицы для каждого студента придется указывать довольно длинное наименование вуза и его адрес, что неудобно. Более того, любая незначительная ошибка во вводе этих полей приведет к нарушению непротиворечивости базы данных. Например, ошибка в адресе вуза приведет к тому, что в БД появятся два вуза с одинаковым наименованием и разными адресами.
Поступают в таком случае так: в отношение СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ГРУППА) вводят поле «КОД вуза» (целое число) и добавляют еще одно отношение ВУЗ (КОД вуза, НАЗВАНИЕ, АДРЕС). Таблицы СТУДЕНТ и ВУЗ при этом будут связаны по полю «КОД вуза». В отношении ВУЗ поле «КОД вуза» будет первичным ключом, а в отношении СТУДЕНТ поле «КОД вуза» будет внешним ключом. При работе с такими таблицами повторяться могут только данные в поле «КОД вуза», а все необходимые сведения о вузе можно взять из отношения ВУЗ.
Итак, для связи реляционных таблиц необходимо ввести в обе таблицы одинаковые по типу поля, по которым определится связь между записями обеих таблиц. Связи бывают нескольких типов:
• один к одному (1:1) – любая запись одной таблицы может быть связана только с одной записью другой и наоборот. По сути, каждая пара записей является одной записью, поля которой разделены на две таблицы. То есть часть полей находится в одной таблице, а оставшаяся часть – в другой, являющейся продолжением первой;
• один ко многим (1:М или 1:∞) – любая запись одной таблицы может быть связана с несколькими записями другой, но любая запись второй таблицы связана только с одной записью первой таблицы. Связь «один ко многим» была установлена в вышеприведенном примере, так как одной записи таблицы ВУЗ соответствует множество записей таблицы СТУДЕНТ;
• многие ко многим (М:М или ∞:∞) – любая запись одной таблицы может быть связана с несколькими записями другой и наоборот. В явном виде эта связь может не поддерживаться, обычно она организуется путём создания дополнительных таблиц. Например, у каждого студента несколько преподавателей (по разным дисциплинам), а у каждого преподавателя – несколько студентов.