Комплект практических и самостоятельных работ по теме «Базы данных»

Реляционная база данных – база данных, построенная на основе реляционной модели[1]. В реляционной базе каждый объект задается записью (строкой) в таблице. Реляционная база создается и затем управляется с помощью реляционной системы управления базами данных.Фактически реляционная база данных это тело связанной информации, сохраняемой в двухмерных таблицах. Связь между таблицами может находить свое отражение в структуре данных, а может только подразумеваться, то есть присутствовать на неформализованном уровне. Каждая таблица БД представляется как совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы – атрибутам (признакам, характеристикам, параметрам) объекта, события, явления. Реляционные базы данных предоставляют более простой доступ к оперативно составляемым отчетам (обычно через SQL) и обеспечивают повышенную надежность и целостность данных благодаря отсутствию избыточной информации.

История

Реляционные системы берут свое начало в математической теории множеств. Эдгар Кодд, сотрудник исследовательской лаборатории корпорации IBM в Сан-Хосе, по существу, создал и описал концепцию реляционных баз данных в своей основополагающей работе «Реляционная модель для крупных, совместно используемых банков данных» (A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, июнь 1970).

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

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

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

Правило 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):

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

Сущность реляционной базы данных

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

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

Особенностью реляционной базы данных является использование в ней реляционной модели данных и вытекающие из этого последствия:

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

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

Реляционная система управления базой данных (РСУБД)

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

Доступ к реляционным базам данных осуществляется через реляционные системы управления базами данных (РСУБД). Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее. Причины такого доминирования неочевидны. На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.

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

Реляционная система управления базой данных содержит:

  • командный язык;
  • язык программирования с ориентацией на обработку таблиц;
  • интерпретирующую и/или компилирующую систему; и
  • пользовательскую оболочку.

Источники

Ссылки

Что такое реляционная модель?

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

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

Некоторые популярные системы управления реляционными базами данных:

  • DB2 и динамический сервер Informix — IBM
  • Oracle и RDB — Oracle
  • SQL Server и доступ — Microsoft

В этом уроке вы узнаете

Концепции реляционной модели

  1. Атрибут: каждый столбец в таблице. Атрибуты — это свойства, которые определяют отношение. например, Student_Rollno, NAME и т. д.
  2. Таблицы. В реляционной модели отношения сохраняются в формате таблицы. Он хранится вместе со своими сущностями. Таблица имеет два свойства строк и столбцов. Строки представляют записи, а столбцы представляют атрибуты.
  3. Tuple — это всего лишь одна строка таблицы, которая содержит одну запись.
  4. Схема отношений: Схема отношений представляет имя отношения с его атрибутами.
  5. Степень: общее количество атрибутов, которое в отношении называется степенью отношения.
  6. Количество элементов : общее количество строк в таблице.
  7. Столбец: столбец представляет набор значений для определенного атрибута.
  8. Экземпляр отношенияЭкземпляр отношения — это конечный набор кортежей в системе RDBMS. Экземпляры отношений никогда не имеют повторяющихся кортежей.
  9. Ключ отношения — каждая строка имеет один, два или несколько атрибутов, которые называются ключом отношения.
  10. Домен атрибута — каждый атрибут имеет предварительно определенное значение и область действия, известную как домен атрибута.

Ограничения реляционной целостности

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

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

  1. Доменные ограничения
  2. Ключевые ограничения
  3. Ограничения ссылочной целостности

Ограничения домена

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

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

Пример:

Create DOMAIN CustomerName CHECK (value not NULL)

Показанный пример демонстрирует создание ограничения домена таким образом, что CustomerName не NULL

Ключевые ограничения

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

Пример:

В данной таблице CustomerID является ключевым атрибутом Customer Table. Скорее всего, он будет иметь один ключ для одного клиента, CustomerID = 1 только для CustomerName = «Google».

Пользовательский ИД Имя покупателя Положение дел
1 Google активный
2 Амазонка активный
3 яблоко Неактивный

Ограничения ссылочной целостности

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

Пример:

В приведенном выше примере у нас есть 2 отношения, Клиент и Биллинг.

Tuple для CustomerID = 1 упоминается дважды в отношении Billing. Итак, мы знаем, что CustomerName = Google имеет сумму счета 300 долларов

Операции в реляционной модели

Четыре основные операции обновления, выполненные на модели реляционной базы данных:

Вставьте, обновите, удалите и выберите.

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

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

Операция вставки

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

Операция обновления

Вы можете видеть, что в приведенной ниже таблице отношений CustomerName = ‘Apple’ обновляется с Неактивно на Активно.

Удалить операцию

Чтобы указать удаление, условие для атрибутов отношения выбирает кортеж для удаления.

В приведенном выше примере CustomerName = «Apple» удаляется из таблицы.

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

Выберите операцию

В приведенном выше примере выбрано CustomerName = «Amazon»

Лучшие практики для создания реляционной модели

  • Данные должны быть представлены как совокупность отношений
  • Каждое отношение должно быть четко обозначено в таблице
  • Строки должны содержать данные об экземплярах объекта
  • Столбцы должны содержать данные об атрибутах сущности
  • Ячейки таблицы должны содержать одно значение
  • Каждому столбцу должно быть присвоено уникальное имя
  • Два ряда не могут быть одинаковыми
  • Значения атрибута должны быть из одного домена

Преимущества использования реляционной модели

  • Простота : реляционная модель данных проще, чем иерархическая и сетевая модель.
  • Структурная независимость : реляционная база данных связана только с данными, а не со структурой. Это может улучшить производительность модели.
  • Простота в использовании : реляционная модель проста, так как таблицы, состоящие из строк и столбцов, довольно естественны и просты для понимания.
  • Возможность запроса : позволяет высокоуровневому языку запросов, такому как SQL, избегать сложной навигации по базе данных.
  • Независимость данных : структура базы данных может быть изменена без необходимости изменения какого-либо приложения.
  • Масштабируемость . Что касается количества записей или строк и количества полей, база данных должна быть расширена для повышения ее удобства использования.

Недостатки использования реляционной модели

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

Резюме

  • Модель реляционной базы данных представляет базу данных как совокупность отношений (таблиц).
  • Атрибут, таблицы, кортеж, схема отношений, степень, мощность, столбец, экземпляр отношения — некоторые важные компоненты реляционной модели
  • Ограничения реляционной целостности относятся к условиям, которые должны присутствовать для действительного отношения
  • Ограничения домена могут быть нарушены, если значение атрибута не отображается в соответствующем домене или оно не имеет соответствующего типа данных
  • Вставка, Выбор, Изменение и Удаление — операции, выполняемые в реляционной модели.
  • Реляционная база данных связана только с данными, а не со структурой, которая может улучшить производительность модели.
  • Преимуществами реляционной модели являются простота, структурная независимость, простота использования, возможность запросов, независимость данных, масштабируемость.
  • Немногие реляционные базы данных имеют ограничения на длину полей, которые нельзя превышать.

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий