Файл: Реляционная модель данных, её особенности (РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ).pdf
Добавлен: 06.07.2023
Просмотров: 140
Скачиваний: 14
ВВЕДЕНИЕ
Реляционные базы данных уже давно используются в программировании. В своё время они обрели популярность благодаря простоте и удобству реляционной модели работы с данными. Практически все разработчики современных приложений, предусматривающих связь с системами баз данных, ориентируются на реляционные СУБД. В настоящее время абсолютными лидерами рынка СУБД являются компании Oracle, IBM и Microsoft
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Коддом в 1970 году и вызвавшей всеобщий интерес. Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы.
К сожалению, практическое определение понятия "реляционная база данных" оказалось гораздо более расплывчатым, чем точное математическое определение,
данное этому термину Коддом в 1970 году. Во-первых, реляционных СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот пробел был
восполнен только впоследствии. По мере роста популярности реляционной концепции
реляционными стали называться многие базы данных, которые на деле таковыми не
являлись.
В ответ на неправильное использование термина "реляционный" Кодд в 1985 году написал статью, где сформулировал 12 правил, которым должна удовлетворять любая база данных, претендующая на звание реляционной. С тех пор двенадцать правил Кодда считаются определением реляционной СУБД. Однако можно сформулировать и
более простое определение: Реляционной называется база данных, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.
Проблемы информатизации производства и обработки информации, то есть проблемы создания и развития современного машинного производства в информационной сфере, порождены противоречием между необходимостью своевременного использования во всех сферах человеческой деятельности больших объемов высококачественной информации и невозможностью оперативно формировать такие объемы с помощью Баз Данных.
В соответствии с реляционной моделью база данных представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры и реляционного исчисления. В реляционной модели операции над объектами базы данных имеют теоретико-множественный характер.
Концепции реляционной модели данных связаны с именем известного специалиста в области систем баз данных Е. Кодда. Именно поэтому реляционную модель данных часто называют моделью Кодда.
Часто, говоря о базе данных, имеют в виду просто некоторое автоматизированное хранилище данных. Такое представление не вполне корректно.
Действительно, в узком смысле слова, база данных — это некоторый набор данных, необходимых для работы (актуальные данные). Однако данные — это абстракция; никто никогда не видел "просто данные"; они не возникают и не существуют сами по себе. Данные суть отражение объектов реального мира. Пусть, например, требуется хранить сведения о деталях, поступивших на склад. Как объект реального мира — деталь — будет отображена в базе данных? Для того, чтобы ответить на этот вопрос, необходимо знать, какие признаки или стороны детали будут актуальны, необходимы для работы. Среди них могут быть название детали, ее вес, размеры, цвет, дата изготовления, материал, из которого она сделана и т.д. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями — entities, а их актуальные признаки — атрибутами (attributes).
Принято считать, что реляционный подход к организации баз данных был заложен в конце 1960-х гг. Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными системах баз данных, основанных на языке SQL, в действительности нарушаются некоторые важные принципы классического реляционного подхода). Достоинствами реляционного подхода принято считать следующие свойства: реляционный подход основывается на небольшом числе интуитивно понятных абстракций, на основе которых возможно простое моделирование наиболее распространенных предметных областей; эти абстракции могут быть точно и формально определены; теоретическим базисом реляционного подхода к организации баз данных служит простой и мощный математический аппарат теории множеств и математической логики; реляционный подход обеспечивает возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. Компьютерный мир далеко не сразу признал реляционные системы. В 70-е года прошлого века, когда уже были получены почти все основные теоретические результаты и даже существовали первые прототипы реляционных СУБД, многие авторитетные специалисты отрицали возможность добиться эффективной реализации таких систем. Однако преимущества реляционного подхода и развитие методов и алгоритмов организации и управления реляционными базами данных привели к тому, что к концу 80-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.
Помимо таблиц, в базе данных могут храниться и другие объекты, такие как экранные формы, отчеты (reports), представления (views) и даже прикладные программы, работающие с базой данных.
Для пользователей информационной системы недостаточно, чтобы база данных просто отражала объекты реального мира. Важно, чтобы такое отражение было однозначным и непротиворечивым. В этом случае говорят, что база данных удовлетворяет условию целостности (integrity).
Для того, чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).
ОГРАНИЧИТЕЛЬНЫЕ УСЛОВИЯ, ПОДДЕРЖИВАЮЩИЕ ЦЕЛОСТНОСТЬ
В реляционной модели Кодда есть несколько ограничительных условий, используемых для проверки данных в базе данных, а также для придания осмысленности структуре данных. Принято выделять следующие ограничения:
- Категорная целостность;
- Целостность на уровне ссылок;
- Функциональные зависимости.
ДВЕНАДЦАТЬ ПРАВИЛ КОДДА
В статье, опубликованной в журнале "Computer World", Тэд Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных. Двенадцать правил Кодда являются полуофициальным определением понятия реляционная база данных. Перечисленные правила основаны на теоретической работе Кодда, посвященной реляционной модели данных.
Двенадцать правил Кодда, которым должна соответствовать
реляционная СУБД.
1. Правило информации. Вся информация в базе данных должна быть предоставлена исключительно на логическом уровне и только одним способом - в виде значений,
содержащихся в таблицах.
2. Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путём использования комбинации имени таблицы, первичного ключа и имени столбца.
3. Правило поддержки недействительных значений. В настоящей реляционной базе данных должна быть реализована поддержка недействительных значений, которые отличаются от строки, символов нулевой длинны, строки пробельных символов, и от нуля или любого другого числа и используются для представления отсутствующих
данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной модели. Описание базы данных на логическом уровне должно быть представлено в том же виде, что и
основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они применяют для работы с основными данными.
5.Правило исчерпывающего подъязыка данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать по крайней мере один язык, операторы которого можно представить в виде строк символов в соответствии с
некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы: — определение данных; — определение представлений; —
обработку данных (интерактивную и программную); — условия целостности; — идентификация прав доступа; — границы транзакций (начало, завершение и отмена).
6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.
7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при
добавлении, обновлении и удалении данных.
8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых
изменениях способов хранения данных или методов доступа к ним.
9. Правило независимости логических данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении
в базовые таблицы любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.
10. Правило независимости условий целостности. Должна существовать возможность определять условия целостности, специфические для конкретной реляционной базы данных, на подъязыке реляционной базы данных и хранить их в каталоге, а не в прикладной программе.
11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.
12. Правило единственности. Если в реляционной системе есть низкоуровневой язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности, выраженные на реляционном языке высокого уровня (обрабатывающем несколько записей за один раз).
ОТНОШЕНИЯ ПРЕДОК/ПОТОМОК.
Одним из отличий реляционной модели от первых моделей представления данных было то, что в ней отсутствовали явные указатели, используемые для реализации отношений предок/потомок в иерархической модели данных. Однако вполне очевидно, что отношения предок/потомок существуют и в реляционных базах данных. Отношение предок/потомок, существующее между офисами и работающими в них людьми, в реляционной модели не потеряно; просто оно реализовано в виде одинаковых значений данных, хранящихся в двух таблицах, а не в виде явного указателя. Все отношения, существующие между таблицами реляционной базы данных, реализуются в таком виде.
ОРГАНИЗАЦИЯ ДАННЫХ
Слово «реляционная» происходит от английского relation — отношение. Для пояснения математического понятия «отношение» вспомним два определения.
Декартово произведение. Пусть D1, D2,…D n — произвольные конечные множества и не обязательно различные. Декартовым произведением этих множеств D1 Х D2 Х … Х D n -называется множество n-к вида: < d1 , d2 , …, d n >, где d1 принадлежит D1, d2 — D2 , а d n -D n .
Рассмотрим простейший пример. Пусть первое множество состоит из двух элементов D1= {а1, а2}, второе—из трех: D2 ={b1, b2, b3}, Тогда их декартово произведение есть: D1 Х D2 = {а1 b1 ,а1 b2, а1b3, а2 b1, а2 b2, а2b3}.
Отношение. Отношением R, определенным на множествах D1, D2,…D n , называется подмножество декартова произведения D1 Х D2 Х … Х D n . При этом множества D1, D2,…D n называются доменами отношения, а элементы декартова произведения - кортежами отношения. Число n определяет степень (арность) отношения, а количество кортежей - его мощность.
Отношения удобно представлять в виде таблиц. При этом строки таблицы соответствуют кортежам, а столбцы - атрибутам. Каждый атрибут определен на некотором домене. Доменом называют множество атомарных значений. Несколько атрибутов отношения могут быть определены на одном и том же домене. Атрибут определяет роль домена в отношении.
Атрибуты разных отношений также могут быть определены на одном и том же домене.
Атрибут, значения которого идентифицируют кортежи, называется ключом (ключевым атрибутом).
В некоторых отношениях кортежи идентифицируются конкатенацией значений нескольких атрибутов. Тогда говорят, что отношение имеет составной ключ. Отношение может содержать и несколько ключей. Один из ключей отношения объявляется первичным. Значения первичного ключа не могут обновляться. Все прочие ключи отношения называются возможными ключами.
Отметим важную особенность реляционной модели данных. Если в сетевых и иерархических моделях данных для отражения ассоциаций между записями использовались групповые отношения, то в реляционной модели данных такого понятия не существует. Для отражения ассоциаций между кортежами отношении используется дублирование их ключей.
Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами.
Перечень атрибутов отношения и его свойства определяет схему отношения. Два отношения называются односхемными, если они построены, но единой схеме.
Первоначальная модель Кодда содержала небольшой набор средств ограничения целостности: не допускались кортежи с одинаковыми значениями первичного ключа и обеспечивалась возможность наложения ограничений на значения доменов и, следовательно, атрибутов. Механизмов поддержания семантики ассоциаций (речь идет о таких ограничениях целостности, как режим включения и класс членства) в реляционной модели нет. Отношения существуют независимо друг от друга, хотя между кортежами этих отношений возникают порой достаточно сложные ассоциации.
Неразвитость средств ограничения целостности послужила толчком к последующему развитию модели Кодда, которое получило название расширенной реляционной модели данных. Последняя предполагает поддержку ряда служебных отношений, хранящих сведения об ассоциациях предметной области, а процедуры обработки пользовательских отношений учитывают эти сведения. Расширенная модель Кодда представляет существенно более развитые средства для поддержки ограничений целостности.
НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ
Одна из важнейших проблем проектирования схемы БД заключается в выделении типов записей (отношений), определении состава их атрибутов. Группировка атрибутов должна быть рациональной, т. е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Сначала эти вопросы решались интуитивно. Однако интуиция может подвести даже опытного специалиста, поэтому Коддом был разработан в рамках реляционной модели данных аппарат, называемый нормализацией отношений. И хотя идеи нормализации сформулированы в терминологии реляционной модели данных, они в равной степени применимы и для других моделей данных.
Коддом выделено три нормальных формы отношений. Самая совершенная из них - третья. Предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. В процессе таких преобразований могут выделяться новые отношения.