Реляционная модель. Базовые понятия, свойства реляционной модели. Реляционная целостность.

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

 

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

 

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

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

 

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

 

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

 

Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) (первичный ключ — ОТД_НОМЕР) и СОТРУДНИКИ ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) (первичный ключ — СОТР_НОМЕР).

 

Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.

 

6. Понятие БД и СУБД. Основные типы структур данных: таблица, поле, запись.

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

Основные функции	Дополнительные функции
1) Ввод данных 2) Обновление данных 3) Анализ данных	1) Проверка состояния БД 2) Выдача справочной информации 3) Разграничение прав доступа пользователей к информации

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

 

Таблица – множество одинаковых по структуре записей со значениями в полях.

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

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

 

7. Виды полей: определения, примеры.

Ключевое поле (ключ) – это одно или несколько полей, значение которых однозначно определяет запись в таблице. Ключевые поля бывают первичные и внешние.

Первичные – одно или несколько полей главной таблицы, однозначно индефицирующая к записи (если одно поле – это ключ, иначе – составной). Значение первичного ключа уникально.

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

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

8.Типы связей между таблицами.

При составлении связи между 2 таблица одна из них будет главная (master), а вторая – подчиненная (detail). Различия мейжду ними: в главной таблице всегда доступны все содержащие в ней записи, в подчиненной же таблице доступны только те связи, в которых значения атрибутов внешнего ключа совпадают со значением соответствующих атрибутов текущей записи главной таблицы. Изменение текущей записи главной таблицы приведет к изменению множества доступных записей подчиненной таблицы. А изменение текущей записи подчиненной таблицы не вызовет никаких изменений в главной таблице.

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

Различат 4 типа связи между таблицами в БД:

· Один к одному (1 : 1) – каждой записи одной таблицы соответствует только одна запись другой таблице (университет – ректор).

· Один ко многий (1 : N) – одной записи главной таблицы могут соответствовать несколько записей подчиненной таблицы (университет – студенты)

· Многие к одному (N:1) – нескольким записям главной таблицы может соответствовать одна запись подчиненной таблицы (факультеты – университет)

· Многие ко многим (N:N) – одна запись главной таблицы связана с несколькими записями подчиненной таблицы, а одна запись подчиненной таблицы связана с несколькими записями главной (преподаватели – предметы).

·

Различия между типами связей «один ко многим» и «многие к одному» зависят от того, какая из таблиц выбирается в качестве главной, а какая – в качестве подчиненной.

Жизненный цикл БД.

Процесс проектирования, реализации и поддержания системы БД называется жизненным циклом БД (ЖЦБД).

Процедура создания системы называется ЖЦСистемы.

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

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

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

3. Определение требований – включает выбор целей БД, выяснение информационных требований к системе и требование к оборудованию и операционной системе БД. То есть на данном этапе сбора данных и определения требований создается общая информационная модель, включающая следующие задачи:

 

· Определяются цели системы путем анализа информационной потребности. Здесь так же указываются, какую именно БД следует создавать (распределенную или целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

· Определение пользовательских требований – фиксация функции системы и определение прикладных систем, которые будут выполнять эти требования. Документация – в виде обобщенной информации (комментарий, отчет, опрос, анкет и т. д.).

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

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

 

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

5. Логическое проектирование – осуществляется выбор типов моделей данных. Концептуальная модель отображается в логическую модель, основанную на структурах, характерных для выбранной модели.

6. Реализация (физическое проектирование) – процесс превращения концептуальной и логической моделей в функциональную БД. Она включает в себя следующие этапы:

· Выбор и определение необходимой СУБД

· Преобразования концептуальной (инфологической) модели БД в физическую модель. 1. На основе инфологической модели строится схема данных для конкретной СУБД. 2. Определяются, какие прикладные процесса необходимо реализовать в схеме данных как процедура. 3. Реализовать ограничение, предназначенное для обеспечения целостности данных. 4. Разработать индексирование. 5. Определить уровни доступа пользователей. Разработать и внедрить правила обеспечения безопасности. Создать роли для многопользовательского доступа с уровнями полномочия доступа. 6. Разработать сетевую БД и механизм доступа к удаленным данным.

· Построение словаря данных, который определяет хранение структуры данных БД. Словарь данных также содержим информацию о полномочиях доступа, правилах защиты данных и контроля за ними.

· Заполнение БД.

· Создание прикладных программ, контроль управления.

· Обучение пользователя.

· Оценка и усовершенствование схемы БД – включает опрос пользователей с целью выяснения неучтенных потребностей. При необходимости вносятся изменения, добавления новых программ и элементов данных по мере изменения и расширения потребностей.

Таким образом, ЖЦБД включает в себя:

· Изучение предметной области и представление соответствующей документации (1-3 этапы)

· Построение инфологической модели (4-5 этапы)

· Реализация (6 этап)

· Оценка работы и поддержка БД (7 этап)

 

Требования, предъявляемые к БД

К современным БД предъявляются следующие требования:

· Высокое быстродействие (время отклика – промежуток времени от момента запроса к БД до фактического получения данных. Время доступа – промежуток времени между выдачей командой записи (считывания) и фактическим получением данных. Под доступом понимается операция, поиска чтения данных или их записей.

· Простота обновления данных. Первые два требования противоречивы: повышение быстродействия требует упрощения структуры БД, что, в свою очередь, затрудняет процедуру обновления данных, увеличивает их избыточность.

· Независимость данных – возможность изменения логической и физической структур БД без изменений представлений пользователей.

· Совместное использование данных многими пользователями.

· Безопасность данных – защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения. Безопасность данных включает целостность данных и защиту данных. Целостность данных – устойчивость хранимых данных к разрушению и уничтожению, связанных с неисправностью технических средств системными ошибками и ошибочными действия пользователя. Целостность данных предполагает: Отсутствие неточно введенных данных или двух записей об одном и том же факте, Защита от ошибок при обновлении БД, Каскадное удаление связанных данных разных таблиц, Не искажение данных при работе в многопользовательском режиме и в распределенных БД, Сохранность данных при сбоях техники (восстановление данных). Защита данных предполагает: Введение системы паролей, Получение разрешений от администратора БД, Запрет от администратора БД на доступ к конфиденциальным данным, Формирование видов таблиц (копий), производных от исходных и предназначенных конкретным пользователям.

· Стандартизация построения и эксплуатации БД. Стандартизация упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена интерфейсом пользователя и языка SQL. Это позволило решить задачу взаимодействия различных реляционных СУБД как при локальном, так и при удаленном доступе данных.

· Минимальная избыточность – любой элемент данных должен храниться в единственном экземпляре

· Возможность многократного использования данных.

· Однократный ввод данных

· Адекватность отображения данных соответствующей предметной области

· Дружелюбный интерфейс пользователя.

Этапы проектирования БД

При проектировании реляционной БД должны быть решены следующие проблемы:

· С учетом предметной области необходимо наилучшим образом представить объекты предметной области в виде абстрактной модели данных (дата логическим проектированием). Т. е. определиться со схемой БД: из каких отношений должна состоять, какие атрибуты должны быть у этих отношений, какие связи между отношениями.

· Обеспечить эффективность выполнения забросов в БД (физическое проектирование)

После проведения этапа Дата логическое проектирование должны быть получены следующие документы:

· Построение корректной схемы данных, ориентируясь на реляционную модель данных

· Описание схемы БД в терминах, выбранных в СУБД

· Описание правил поддержки целостности БД

· Разработка процедур поддержки целостности БД

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

· Метод декомпозиции (разбиение). Отношения разбиваются на подмножества, число отношений возрастает

· Метод синтеза – компоновка схемы БД из заданных объектов предметной области.

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

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

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

 

⇐ Предыдущая1234567Следующая ⇒

Поделиться: