Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


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



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

 

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

 

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное 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. Это позволило решить задачу взаимодействия различных реляционных СУБД как при локальном, так и при удаленном доступе данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


Поделиться:



Последнее изменение этой страницы: 2019-04-11; Просмотров: 247; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.041 с.)
Главная | Случайная страница | Обратная связь