Что такое «реляционная модель данных», каковы ее особенности? 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Что такое «реляционная модель данных», каковы ее особенности?



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

Основными элементами модели являются реляционные таблицы[†] и связи между ними. В каждой таблице содержатся сведения об одной сущности. В исходных таблицах, из которых данные вводятся в таблицы БД, столбцы должны иметь уникальные имена, содержать данные только одного типа (либо числа, либо текст и т.п.), быть неделимыми и не иметь пустых и повторяющихся строк. Структура таблицы определяется составом и последовательностью ее полей с указанием типа элементарного данного, размещаемого в поле. Основными типами данных являются: числовой, текстовый, дата/время, логический. Содержание таблицы заключено в ее записях. Каждая запись содержит данные о конкретном экземпляре сущности. Для однозначного определения каждой записи таблица должна иметь уникальный ключ (ключевое поле или совокупность нескольких полей), называемый первичным ключом. Так в таблице «Заказ» (табл.2.2) ключевым полем может быть «Номер заказа», если нумерация не зависит от даты заказа, и «Номер заказа + Дата заказа», если каждый день вводится новая нумерация (1, 2, …, N). По значению ключа отыскивается единственная запись.

Связи между таблицами дают возможность совместно использовать данные из разных таблиц. Это связи вида «один – к – одному» (1:1) и «один - ко - многим» (1:M). В последнем случае одному значению первичного ключа в одной таблице соответствует несколько записей с таким же значением соответствующего поля (вторичного ключа) в другой. При этом первая таблица называется главной, а вторая подчиненной. Например, при связывании таблиц «Клиент» и «Заказ» (рис. 2.1 и табл. 2.2, табл. 2.3) одной записи со значением поля «Код Клиента», равным 1251, может соответствовать несколько записей с таким же значением поля «Код клиента» 1251 в таблице «Заказ» (один клиент может сделать несколько заказов). Таким образом, связь каждой пары таблиц обеспечивается одинаковыми полями, в них – ключом связи, являющимся первичным ключом главной таблицы. Связь вида M:N («многие - ко - многим») преобразуется с использованием дополнительной таблицы-вставки в две связи вида «один - ко - многим». При этом ключ таблицы-вставки будет совокупностью ключей исходных таблиц.

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

 

Таблица 4.1.

Должность

 

Некоторые виды функциональной зависимости могут приводить к избыточности данных в базе. Для ее устранения (минимизации) при проектировании реляционных БД используется нормализация – процесспреобразования данных от одной нормальной формы к другой, боле высокой. Нормальные формы (НФ) формируются последовательно и по возрастанию (1НФ, 2НФ, 3НФ), и чем больше номер, тем больше ограничений на хранимые значения должно соблюдаться в соответствующей реляционной таблице. Любая реляционная таблица находится в первой нормальной форме (1НФ).

Во второй нормальной форме (2НФ) в таблице не должно быть полей, зависящих только от части составного ключа (а не от него целиком). Так, например, в таблице «Булочная» (табл. 4.2), содержащей поля «Хлебозавод», «Продукт», «Цена» и «Количество», цена на одинаковые продукты разных заводов может быть назначена одна. В этом случае ключом будет совокупность полей «Хлебозавод + Продукт». Так как батоны нарезные хлебозаводов «Пекаря», «Кушелевского» и «Каравая» будут стоить одинаково, поле «Цена» будет зависеть только от части ключа – от поля «Продукт». Для устранения неполной функциональной зависимости необходимо разделить исходную таблицу на две. В первой таблице будут поля «Хлебозавод», «Продукт» и «Количество», а во второй – «Продукт» и «Цена».

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

 

 

Таблица 4.2

Булочная

 

 

Таблица 4.3.

Сотрудник

 

Для обеспечения целостности данных в реляционных БД должны выполняться определенные правила. Так для любой таблицы первичный ключ должен быть уникальным и не пустым (иметь конкретное значение). Для связанных таблиц все связи должны быть реальными, т.е. каждый вторичный ключ в подчиненной таблице должен ссылаться на действующий первичный ключ в главной таблице. В примере «Клиент – Заказ» (рис. 2.12 и табл. 2.1, 2.2) это означает, что если есть записи в таблице «Заказ» с номером клиента 1274, то должна быть запись в таблице «Клиент» с таким номером клиента. Для связанных таблиц правила ссылочной целостности предусматривают действия, которые должны выполняться при вставке, обновлении и удалении записей в одной из таблиц. Так, например, правило «Каскад» требует при удалении (или обновлении) записи в главной таблице удаления (или обновления) всех соответствующих записей в подчиненной таблице. В нашем примере это означает, что если удаляется запись с номером клиента 1251 в таблице «Клиент», то в таблице «Заказ» будут удалены все записи с заказами, сделанными этим клиентом. Правила ссылочной целостности устанавливаются при проектировании БД.

Возможности ускоренного поиска данных в реляционной базе обеспечиваются созданием индексов, в которые выносятся упорядоченные значения (по возрастанию или убыванию) ключа и номера записей исходной таблицы, соответствующие этим значениям. Индексы позволяют при поиске использовать не последовательный просмотр записей до нахождения требуемой, а специальные алгоритмы, простейшим из которых является алгоритм помещения указателя в средину индекса и сравнения ближайшего значения ключа с искомым. Если ближайшее значение ключа в индексе больше искомого значения, то указатель перемещается в средину «верхней» половины таблицы, меньше – в средину «нижней», и опять производится сравнение. Если в таблице N записей, то при самом неблагоприятном варианте искомое значение ключа будет в последней записи, и придется проделать N шагов. Для рассмотренного простейшего алгоритма число шагов при поиске определяется как log 2 N.

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

 

 

11. Приведите пример реляционной модели БД

 

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

Так в простейшей БД «ЗАКАЗ» могут быть созданы две таблицы: «Заказ» и «Клиент», - связанные между собой (табл.2.2 и табл. 2.3).

 

Таблица 2.2.

Клиент

 

 

Таблица 2.3.

Заказ

 

 

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

В современных БД, помимо взаимосвязанных таблиц, сохраняются такие объекты как запросы, а также объекты приложений: формы, отчеты, страницы, макросы и модули.

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

Формы предназначены для ввода и редактирования данных, отчёты – для формирования выходных документов и вывода их на печать.

Представление таблиц и связей между ними отображается Схемой данных (рис.2.1).

 

 

Рис.2.1. Схема данных «Заказ»


 



Поделиться:


Последнее изменение этой страницы: 2017-01-27; просмотров: 420; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 44.203.235.24 (0.021 с.)