12 правил кодда реферат

Обновлено: 07.07.2024

13 правил Кодда для СУБД

На английском они называются Codd’s 12 rules — 12 правил, на самом деле их 13, которым должна удовлетворять каждая система управления реляционными базами данных.

Правила предложены английским математиком Эдгаром Коддом (Edgar Codd)

В действительности правила столь строго императивны, что все популярные, так называемые “реляционные” СУБД не соответствуют многим критериям, а сами критерии не являются строго логичными.

Правило 1. Основное правило (Foundation Rule)

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

Правило 2. Явное представление данных (The Information Rule)

Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.

Правило 3. Гарантированный доступ к данным (Guaranteed Access Rule)

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

Правило 4. Полная обработка неизвестных значений (Systematic Treatment of Null Values):

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

Правило 5. Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model)

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

Правило 6. Полнота подмножества языка (Comprehensive Data Sublanguage Rule)

Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который

(а) имеет линейный синтаксис,

(б) может использоваться как интерактивно, так и в прикладных программах,

(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).

Правило 7. Возможность модификации представлений (View Updating Rule)

Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, модификации и удаления данных.

Правило 8. Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete)

Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но по отношению к любому множеству строк.

Правило 9. Физическая независимость данных (Physical Data Independence)

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

Правило 10. Логическая независимость данных (Logical Data Independence)

Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

Правило 11. Независимость контроля целостности (Integrity Independence)

Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.

Правило 12. Дистрибутивная независимость (Distribution Independence)

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

Правило 13. Согласование языковых уровней (The Nonsubversion Rule)

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

Знаете ли Вы, что, как и всякая идолопоклонническая религия, релятивизм ложен в своей основе. Он противоречит фактам. Среди них такие:

1. Электромагнитная волна (в религиозной терминологии релятивизма - "свет") имеет строго постоянную скорость 300 тыс.км/с, абсурдно не отсчитываемую ни от чего. Реально ЭМ-волны имеют разную скорость в веществе (например, ~200 тыс км/с в стекле и ~3 млн. км/с в поверхностных слоях металлов, разную скорость в эфире (см. статью "Температура эфира и красные смещения"), разную скорость для разных частот (см. статью "О скорости ЭМ-волн")

2. В релятивизме "свет" есть мифическое явление само по себе, а не физическая волна, являющаяся волнением определенной физической среды. Релятивистский "свет" - это волнение ничего в ничем. У него нет среды-носителя колебаний.

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

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 04.10.2014
Размер файла 17,0 K

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

В 1985 году в двух статьях в журнале Computer World Э.Ф. Кодд сформулировал правила, которым должны соответствовать настоящие реляционные базы данных. Всего правил было двенадцать. Несколько позже Кодд сформулировал 13-е правило и присвоил ему номер 0. Начнем рассмотрение правил с этого последнего или нулевого.

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

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

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

o Уникальность имени таблицы в базе данных.

o Уникальность имени столбца в таблице.

o Уникальность первичного ключа, по крайней мере, в пределах одной таблицы.

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

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

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

Многие разработчики СУБД стараются следовать этому правилу. Так, при создании базы данных в СУБД FoxPro создается файл с расширением .dbc. На поверку, однако, этот файл оказывается таблицей (dbf-формат), которая содержит информацию, описывающую структуру базы данных. В такой СУБД как MS SQL Server описание базы данных хранится в специальных системных таблицах.

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

o Определение структуры данных.

o Определение представлений.

o Модификацию данных (содержимого таблиц).

o Определения условий целостности.

o Определение правил авторизации (идентификация прав доступа).

o Определение границ транзакций.

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

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

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

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

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

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

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

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

кодд реляционный база данных

Подобные документы

Использование нормализации. Вторая и третья нормальные формы. Нормальная форма Бойса-Кодда. Четвертая и пятая нормальная форма. Семантическое моделирование данных, ER-диаграммы. Основные понятия модели Entity-Relationship.

контрольная работа [43,0 K], добавлен 07.08.2007

Назначение и основные функции системы управления базами данных СУБД, особенности и признаки их классификации. Архитектура баз данных (БД). Разработка распределенных БД. Язык структурированных запросов (SQL). Правила Кодда: требования к реляционным БД.

курсовая работа [376,2 K], добавлен 21.07.2012

Особенности систем управления базами данных (СУБД): основные понятия, реляционные базы, основные этапы их проектирования. Концептуальная (логическая) модель БД "Экспресс поставки", её физическая модель, создание в Access и SQL запроса к БД при её работе.

курсовая работа [1,2 M], добавлен 19.11.2012

Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.

реферат [57,1 K], добавлен 20.12.2010

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

курсовая работа [166,6 K], добавлен 18.07.2012

Разработка базы данных средствами СУБД Microsoft SQL Server 2008. Исследование понятия первичного и внешнего ключа. Реляционные отношения между таблицами базы данных. Ссылочная целостность и каскадные воздействия. Проектирование запросов и триггеров.

курсовая работа [1,0 M], добавлен 27.05.2015

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

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.)

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

Доменом называется множество атомарных значений одного и того же типа. Так, на рис. домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.

Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?

Отношение на доменах D1, D2, . Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 3.1 приведен пример отношения для расписания движения самолетов.

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, . An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2. n).


Рис. 3.1. Отношение с математической точки зрения (Ai - атрибуты, Vi - значения атрибутов)

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2. n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, . а степени n – n-арным. Степень отношения "Рейс" – 8.

Кардинальное число или мощность отношения – это число его кортежей. Мощность отношения "Рейс" равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, . An. Говорят, что множество атрибутов K=(Ai, Aj, . Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, . Ak.

2. Минимальность: ни один из атрибутов Ai, Aj, . Ak не может быть исключен из K без нарушения уникальности.

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

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

Отношение – Таблица (иногда Файл),
Кортеж – Строка (иногда Запись),
Атрибут – Столбец, Поле.

При этом принимается, что "запись" означает "экземпляр записи", а "поле" означает "имя и тип поля".

Необходимым условием работы с СУБД является знание реляционной модели БД. Это наиболее популярная модель хранения данных. Доктор Кодд определил 13 правил реляционной модели (которые называют 12 правилами Кодда).

Правил Кодда.

1. Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными.

2. Информационное правило - Вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения таблиц.

3. Гарантированный доступ - Любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичный ключ и имя столбца.

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

5. Активный, оперативный реляционный каталог - Описание БД и его содержимое должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя DML (язык манипулирования данными).

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

7. Правило обновления представлений - Все представления, теоретически обновляемые, могут быть обновлены через систему.

8. Вставка, обновление и удаление - СУБД поддерживает не только запрос данных, но и вставку, обновление и удаление.

9. Физическая независимость данных - Логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения.

10. Логическая независимость данных - Логика программ-приложений остается прежней, в пределах разумного, при изменении структур таблиц.

11. Независимость целостности - Язык БД должен быть способен определять ограничения целостности. Они должны быть доступны из оперативного каталога, и не должно быть способа их обойти.

12. Независимость распределения - Запросы программ-приложений логически не затрагиваются при первом и последующих распределениях данных.

13. Несмешиваемость (может, кто-то знает более удачный перевод термина ?) - невозможность обойти ограничения целостности, используя языки низкого уровня.

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

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

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

Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом*, в то время работавшим в IBM, а впервые опубликованы - в 1970 г.

Работая в компании IBM, он создал реляционную модель данных. Он также внёс существенный вклад в другие области информатики.

Биография

12 правил Кодда (англ. Codd’s 12 rules) — 13 правил (в данном случае исчисление начинается с 0), которым должна удовлетворять каждая система управления реляционными базами данных.

Предложены английским математиком Эдгаром Коддом (Edgar Codd) в 1985 году в статьях в журнале ComputerWorld.

Правило 0: Основное правило (Foundation Rule):

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

Правило 1: Информационное правило (The Information Rule):

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

Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):

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

Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):

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

Правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):

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

Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):

Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который

(а) имеет линейный синтаксис,

(б) может использоваться как интерактивно, так и в прикладных программах,

(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями(begin, commit и rollback).

Правило 6: Возможность изменения представлений (View Updating Rule):

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

Правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):

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

Правило 8: Физическая независимость данных (Physical Data Independence):

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

Правило 9: Логическая независимость данных (Logical Data Independence):

Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализацииодна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

Правило 10: Независимость контроля целостности (Integrity Independence):

Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.

Правило 11: Независимость от расположения (Distribution Independence):

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

Правило 12: Согласование языковых уровней (The Nonsubversion Rule):

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

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

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

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

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

Элементами описания реляционной модели данных на концептуальном уровне являются сущности, атрибуты, домены и связи

Сущность

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

Атрибуты сущности бывают:

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

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

Домен

Домен - это набор всех допустимых значений, которые может содержать атрибут. Понятие "домен" часто путают с понятием "тип данных". Необходимо различать эти два понятия. Тип данных - это физическая концепция, а домен - логическая. Например, "целое число" - это тип данных, а "возраст" - это домен.

Связи

Связи - на концептуальном уровне представляют собой простые ассоциации между сущностями. Например, утверждение "Покупатели приобретают продукты" указывает, что между сущностями "Покупатели" и "Продукты" существует связь, и такие сущности называются участниками этой связи.

Существует несколько типов связей между двумя сущностями: это связи " один к одному ", " один ко многим " и " многие ко многим ".

Диаграмма "сущности-связи" ( Entity-Relationship diagrams, или E/R diagram) служит для описания схемы базы на концептуальном уровне проектирования. Метод был предложен в 1976 г. Питером Пин Шань Ченом (Peter Pin Shan Chen). На диаграммах "сущности-связи" сущностиизображаются в виде прямоугольников, атрибуты - в виде эллипсов, а связи - в виде ромбов (см. рис. 2.6).


Рис. 2.6. Диаграмма "сущности-связи"

В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.).

В рамках реляционной модели данных Э.Ф. Коддом были разработаны принципы нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме.

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

Первая нормальная форма (1НФ) связана с понятиями простого и сложного атрибутов. Простой атрибут - это атрибут, значения которого атомарны (т.е. неделимы). Сложный атрибут может иметь значение, представляющее собой объединение нескольких значений одного или разных доменов. В первой нормальной форме устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты.

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

Для приведения таблиц к 1НФ необходимо разбить сложные атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения.

Вторая нормальная форма (2НФ) применяется к отношениям с составными ключами (состоящими из двух и более атрибутов ) и связана с понятиями функциональной зависимости.

\to

Если в любой момент времени каждому значению атрибута A соответствует единственное значение атрибута B, то B функционально зависит от A (A B). Атрибут (группа атрибутов ) A называется детерминантом.

Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального ключа. Эта часть уникального ключа определяет отдельную сущность.

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

Третья нормальная форма (3НФ) связана с понятием транзитивной зависимости. Пусть A, B, C - атрибуты некоторого отношения. При этом A B и B C, но обратное соответствие отсутствует, т.е. C не зависит от B или B не зависит от A. Тогда говорят, что C транзитивно зависит от A (A C).

В третьей нормальной форме устраняются атрибуты, которые зависят от атрибутов, не входящих в уникальный ключ. Эти атрибуты являются основой отдельной сущности.

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

Существуют также нормальная форма Бойса-Кодда (НФБК), 4НФ и 5НФ. Однако наибольшее значение имеет 1НФ, т.к. последующие НФ связаны с понятиями о составных ключах и сложных зависимостях от ключей, а на практике встречаются обычно более простые случаи.

Моделирование структуры базы данных при помощи алгоритма нормализации имеет серьезные недостатки:

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

Правило гарантированного доступа

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

Правило поддержки недействительных значений .

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

Правило динамического каталога .

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

Правило исчерпывающего подъязыка данных .

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

обработку данных (интерактивную и программную);

идентификация прав доступа;

границы транзакций (начало, завершение и отмена).

Правило обновления представлений

Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

Правило добавления, изменения и удаления .

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

Правило независимости физических данных

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

Правило независимости логических данных.

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

Правило независимости условий целостности.

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

Правило независимости распространения.

Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL). Существенно, что использование нулей инициирует переход с двухзначной логики (да/нет) на трехзначную (да/нет/может быть).

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

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

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

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

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

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

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

Определяться на языке высокого уровня, используемом системой для всех других целей;

Храниться в базе данных, а не в программных приложениях.

Эти возможности в том или ином виде реализованы в большинстве СУБД.

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

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

Двенадцать правил Кодда считаются определением реляционной СУБД. Однако можно сформулировать и более простое определение:

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

11.11.Целостность связей

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

Нарушение соответствия данных, целостности связей может произойти только при операциях изменения данных.

При добавлении дочернего объекта возможны 2 правила:

Запрещено добавлять дочерний объект, если для него не указан родительский объект. Например, запрещено добавлять нового сотрудника, если для него не указано подразделение.

Разрешено добавлять дочерний объект без указания для него родительского объекта. Например, разрешается добавлять новый первичный документ, не указывая для него сводного документа.

Подразумеваются изменения, которые касаются ссылок в дочерних объектах. При изменении родительского или дочернего объекта возможен выбор одного из 4-х правил.

Запрещено изменять в дочернем объекте ссылку на родительский объект так, что она указывает на несуществующий родительский объект.

Например, запрещено указывать для сотрудника несуществующее подразделение.

При изменении родительского объекта каскадно изменяются ссылки на него во всех дочерних объектах, если изменения родительского объекта касаются таких ссылок.

Например, при изменении внутреннего номера подразделения этот номер автоматически изменяется в соответствующем атрибуте для всех сотрудников подразделения.

При изменении родительского объекта, которые касаются ссылок на него, ссылки на него во всех дочерних объектах заполняются значением 0, NULL или пустой строкой.

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

При удалении родительского объекта возможен выбор одного из 4-х правил.

Запрещено удалять родительский объект, если у него имеются дочерние объекты. Можно удалять только родительские объекты, у которых нет дочерних.

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

При удалении родительского объекта каскадно удаляются все его дочерние объекты.

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

При удалении родительского объекта ссылки на него во всех дочерних объектах заполняются значением 0, NULL или пустой строкой.

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

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

Перечисленные правила стандартной целостности стали классическими и поддерживаются во всех СУБД общего назначения.

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

Существуют другие, пока нестандартные правила целостности связей, которые обсуждаются ниже.

Агрегирование . Родительский объект содержит обобщение информации из всех его дочерних объектов.

Удаление последнего . Если удаляется единственный дочерний объект, то удаляется и родитель.

Например, при удалении единственного заказа одного из клиентов, желательно удалить и соответствующую запись в списке клиентов. При добавлении объекта применяется аналогичное правило. Например, при вводе первого заказа для нового клиента автоматически добавляется клиент и о нем запрашивается информация.

Ограниченное добавление. Разрешается добавлять записи, удовлетворяющие определенному условию.

Например, иногда нежелательно обслуживать клиентов из определенных областей. В списке регионов такие области отмечены признаком.

Похожие страницы:

Лекции по информатики (2)

Лекции по Информатики (1)

. п.4.1,4.3,4.4 - читать Конспект урока по информатике. «Основы визуального программирования. Интегрированная . программы. Конспект урока информатики по теме "Информационная . Гейн “Обязательный минимум содержания образования по информатике: и в нем нам хочется .

Курс лекции по Информатике

. университет Кафедра прикладной математики и информатики ИНФОРМАТИКА Конспект лекций для студентов Направления: 010500 - Прикладная . требует от него определенных знаний по информатике. Понятие информации определяется как “знания .

Курс лекций по Информатике (2)

Лекции по философии Кандидатский 2004г

. .) смотреть на рефераты похожие на "Лекции по философии (Кандидатский 2004г.) " С О Д Е Р Ж А Н . технологии конца века (электроника, информатика, космическое производство, биотехнологии и . анализ составит содержание последующих лекций. Находясь в единстве .

Читайте также: