РЕЛЯЦИОННЫЙ ПОДХОД К ОРГАНИЗАЦИИ БАЗЫ ДАННЫХ
1. БАЗОВЫЕ ПОНЯТИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
2. ФУНДАМЕНТАЛЬНЫЕ СВОЙСТВА ОТНОШЕНИЙ
3. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
4. БАЗИСНЫЕ СРЕДСТВА МАНИПУЛИРОВАНИЯ РЕЛЯЦИОННЫМИ ДАННЫМИ
4.1. РЕЛЯЦИОННАЯ АЛГЕБРА
4.2. РЕЛЯЦИОННОЕ ИСЧИСЛЕНИЕ
Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).
Примерами реляционных СУБД являются следующие:
dBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxPro ранних версий и FoxBase (Fox Software), Paradox и dBASE for Windows (Borland), FoxPro более поздних версий, Visual FoxPro и Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems), Oracle (Oracle).
К отечественным СУБД реляционного типа относятся системы; ПАЛЬМА (ИК АН УССР), а также система H-Tech (МИФИ).
Заметим, что последние версии реляционных СУБД имеют некоторые свойства объектно-ориентированных систем. Такие СУБД часто называют объектно-реляционными. Примером такой системы можно считать продукты Oracle 8.x.
Достоинства реляционного подхода:
 Наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными.
Наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных.
Возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти.
Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс. При этом проявляется ограниченность реляционной модели данных в следующих аспектах:
Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к проблеме представления ограничений целостности.
Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить усилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.
Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.
Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области («сущностей») и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.
Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение.
Эти понятия рассматриваются на примере базы данных по сотрудникам некоторой организации
Тип данных. Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. В современных реляционных БД могут использоваться следующие типы данных:
символьные фиксированной длины
символьные переменной длины, предназначенные для хранения текстовой информации большой длины, например, документа
числовые (целые, с фиксированной точкой, с плавающей точкой)
специализированных числовых данных (таких как "деньги")
временные и дата-временные, предназначенные для хранения информации о времени и/или дате
двоичные, предназначенные для хранения графических объектов, аудио- и видеоинформации, пространственной, хронологической и другой специальной информации
гиперссылки, предназначенные для хранения ссылок на различные ресурсы (узлы, файлы, документы и т.д.), находящиеся вне базы данных, например, в сети Internet, корпоративной сети Intranet или на жестком диске компьютера.
Домен. Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных.
Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена. Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).
Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. Например, значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми.
В ряде реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.
Атрибут. Атрибут представляет собой элемент данных. Для элемента данных используются также термины "колонка”, "столбец”, "поле”. Столбцы обязательно именуются уникальными именами. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов.
Схема отношения, схема базы данных. Схема отношения — это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается}. Степень или "арность" схемы отношения определяет мощность этого множества.
Например, степень схемы отношения СОТРУДНИКИ равна четырем, то есть множество является 4-арным.
Схема БД (в структурном смысле) — это набор именованных схем отношений.
|