Главная | Обратная связь | Поможем написать вашу работу!

Постреляционная модель данных

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

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

Объектно-ориентированная модель данных

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

· Отсутствие строгой математической модели объектно-ориентированной базы данных. Для реляционной модели такое строгое описание имеется

· Наличие огромного количества данных в имеющихся реляционных базах данных и существенные затраты на их конвертацию в объектно-ориентированную БД.

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

Неформальное введение в реляционную модель

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

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

Таблицы и связи

Доктор Кодд выделил 12 принципов (правил) реляционных баз данных. Начнем с первого правила, которое позволит понять суть реляционной модели:

вся информация логически представлена в виде таблиц.

Таблица состоит из строк и столбцов (в реляционной теории строке соответствует кортеж, а столбцу — атрибут, однако в стандарте SQL используются общепринятые термины «строка» и «столбец»).

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

Например, пусть в базе данных коммерческой фирмы необходимо хранить ряд сведений о клиентах фирмы:

· порядковый номер (личный код) клиента;

· фамилия, имя, отчество;

· контактные телефоны.

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

Возможный вариант заполнения таблиц показан на рис. 1.10

Рис.1.10 - Информация о клиентах с указанием контактных телефонов

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

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

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

Рис. 1.11 - Информация о товарах и их поставщиках

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒