Реаляционная база данных

Реаляционная база данных

1.Общие сведения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Существуют следующие разновидности баз данных:

                   иерархические;

                   реляционные;

                   объектно-ориентированные;

                   гибридные.

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

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

Гибридные СУБД совмещают в себе возможности реляционных и объектно-ориентированных баз данных.

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

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

                   Данные хранятся в таблицах, состоящих из столбцов и строк;

                   На пересечении каждого столбца и строчки стоит в точности одно значение;

                   У каждого столбца есть своё имя, которое служит его названием, и все значения в одном столбце имеют один тип. Например, в столбце id_forum все значения имеют целочисленный тип, а в строке name - текстовый;

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

Главное достоинство таблиц,а значит и  релиционных баз данных — в их понятности. С табличной информацией мы имеем дело практически каждый день. Взять к примеру банальный пример- заглянуть в свой дневник(ежедневник): расписание занятий там представлено в виде таблицы, ведомость с оценками за четверти имеет табличный вид. Когда мы приходим на вокзал, смотрим расписание электричек. Какой вид оно имеет? Это таблица! А еще есть таблица футбольного чемпионата. И журнал учителя, куда он ставит студентам оценки — тоже таблица.

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

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

Каждое поле таблицы имеет имя. Например, в таблице «Игрушки» имена полей такие: НАЗВАНИЕ, МАТЕРИАЛ, ЦВЕТ, КОЛИЧЕСТВО.

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

Например, одна запись о каком либо объекте — это информация об одной игрушке.

Поля — это различные характеристики (иногда говорят — атрибуты) объекта. Значения полей в одной строчке относятся к одному объекту. Разные поля отличаются именами. А чем отличаются друг от друга разные записи? Записи различаются значениями ключей.

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

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

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

В такой таблице у разных записей не могут совпасть только одновременно два поля ГОРОД и НОМЕР ШКОЛЫ. Эти два поля вместе образуют составной ключ: ГОРОД-НОМЕР ШКОЛЫ. Составной ключ может состоять и более чем из двух полей.

С каждым полем связано еще одно очень важное свойство — тип поля.

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

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

 

o                     числовой;

o                     символьный;

o                     дата;

o                     логический.

Числовой тип имеют поля, значения которых могут быть только числами. Например, в БД «Погода» три поля числового типа: ТЕМПЕРАТУРА, ДАВЛЕНИЕ, ВЛАЖНОСТЬ.

Символьный тип имеют поля, в которых будут храниться символьные последовательности (слова, тексты, коды и т.п.). Примерами символьных полей являются поля АВТОР и НАЗВАНИЕ в БД «Домашняя библиотека»; поле ТЕЛЕФОН в БД «Школы».

Тип «дата» имеют поля, содержащие календарные даты в форме «день/месяц/год» (в некоторых случаях используется американская форма: месяц/день/год). Тип «дата» имеет поле ДЕНЬ в БД «Погода».

Логический тип соответствует полю, которое может принимать всего два значения: «да» — «нет» или «истина» — «ложь» или (по-английски) «true» — «false». Если двоичную матрицу представить в виде реляционной БД (табл. 6.4, 6.5), то ее полям, принимающим значения «О» или «1», удобно поставить в соответствие логический тип. При этом «1» заменится на значение «истина», «О» — на значение «ложь».

Итак, значения полей — это некоторые величины определенных типов.

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

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

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

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

        Минимальные затраты. Низкая стоимость хранения и использования данных, минимизация затрат на внесение изменений.

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

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