Реляційна бд. Переваги та недоліки.
Ці моделі характеризуються простотою структури даних, зручним для користувача табличним поданням і можливістю використання формального апарата алгебри відносин і реляційного обчислення для обробки даних.
Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця являє собою двовимірний масив і має наступні властивості:
кожен елемент таблиці - один елемент даних
всі осередки в стовпці таблиці однорідні, тобто всі елементи в стовпці мають однаковий тип (числовий, символьний і т. д.)
кожен стовпець має унікальне ім'я
однакові рядки в таблиці відсутні
порядок проходження рядків і стовпців може бути довільним
Базовими поняттями реляційних СУБД є:
атрибут
ставлення
кортеж
Відносини та їх властивості. Домени. Властивості домену.
Відношення в реляційному моделюванні — набір кортежів, інакше відомий як таблиця бази даних. Поняття відношення покладено в основу реляційних моделей, яке подають у вигляді двовимірної таблиці. Реляційна БД — це набір взаємопов’язаних відношень. Кожне відношення (таблиця) в ЕОМ подається як файл. Відношення можна поділити на два класи: об’єктні і зв’язкові.
Об’єктні відношення зберігають дані про інформаційні об’єкти предметної області. Наприклад: клієнт (код клієнта, назва клієнта, адреса, телефон) є об’єктним відношенням. В об’єктному відношенні один з атрибутів однозначно ідентифікує окремий об’єкт. Такий атрибут називається первинним ключем відношення. В наведеному відношенні роль ключа виконує атрибут «код клієнта». Ключ може вмикати кілька атрибутів, тобто бути складеним. В об’єктному відношенні не повинно бути рядків з однаковим ключем, тобто не допускається дублювання об’єктів. Це основне обмеження реляційної моделі для забезпечення цілісності даних.
Зв’язкове відношення зберігає ключі двох або більше об’єктних відношень. Ключі зв’язкового відношення мають на меті встановлення зв’язків між об’єктними відношеннями. Наприклад, розглянемо ще одне об’єктне відношення БАНК(код банку, назва банку, адреса банку). Тоді зв’язкове відношення БАНК-КЛІЄНТ (код банку, код клієнта) буде сполучним між двома об’єктними відношеннями БАНК іКЛІЄНТ. У зв’язковому відношенні можуть дублюватися ключові атрибути. Крім ключів, за якими встановлюють зв’язок у зв’язковому відношенні, можуть бути ще й інші атрибути, які функціонально залежать від цього складового ключа. Ключі в зв’язкових відношеннях називаються зовнішніми ключами, оскільки вони є первинними ключами інших відношень. Реляційна модель накладає на зовнішні ключі обмеження, яке називають посилковою цілісністю. Воно необхідне для забезпечення цілісності даних. Це означає, що кожному зовнішньому ключеві має відповідати рядок якогось об’єктного відношення.
У реляційній БД накладається ще одне обмеження — відношення мають бути нормалізовані.
Рівні моделювання баз даних.
При разработке базы данных обычно выделяется несколько уровней моделирования, при помощи которых происходит переход от предметной области к конкретной реализации базы данных средствами конкретной СУБД.
Можно выделить следующие уровни:
Сама предметная область
Модель предметной области
Логическая модель данных
Физическая модель данных
Собственно база данных и приложения
Предметная область - это часть реального мира, данные о которой мы хотим отразить в базе данных. Таким образом, важность данных зависит от выбора предметной области.
Модель предметной области. Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п.
Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью.
Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных.
Физическая модель данных. На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур.
Собственно база данных и приложения. И, наконец, как результат предыдущих этапов появляется собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных. Но опять решения, принятые на предыдущем уровне - уровне физического проектирования, определяют границы, в пределах которых можно принимать решения по выбору программно-аппаратной платформы и настройки СУБД.
Таким образом ясно, что решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования.