Реляционная база данных

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

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

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

Базовые концепты

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

Реляционную базу данных можно рассматривать как набор таблиц (отношений), в которых хранятся записи данных. Каждая строка ( кортеж ) в таблице представляет собой запись данных ( запись ). Каждый кортеж состоит из ряда значений атрибутов ( атрибуты = свойства), столбцов таблицы. Схема отношения определяет количество и тип атрибутов отношения. На рисунке показана связь  R с атрибутами от A 1 до A n в столбцах.

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

Пример отношения «книга»:
Идентификатор книги автор Издательство Год публикации заглавие Дата
1 Ганс плодовитый писатель Образец издателя 2007 г. Учим SQL 13.01.2007
2 Дж. Гутенберг Гутенберг и Ко. 1452 Печать стала проще 01.01.1452
3 Г.И. Цезарь Издатель рукописного ввода -44 Моя жизнь с Астериксом 16.03. - 44
5 Галилео Галилей Inquisition International 1640 Эппур си муове 1641
6-е Чарльз Дарвин Издательство Ватикана 1860 г. Адам и Ева 1862 г.

Связи между таблицами

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

Таблица книг , которая содержит строку для каждой книги:

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

Таблица пользователей , содержащая данные всех зарегистрированных пользователей библиотеки:

  • Атрибуты могут быть, например: ID пользователя, имя, фамилия.
Отношение "пользователь"
ID пользователя Имя Фамилия
10 Ганс Частые читатели
11 Йенс Средний читатель
12-е Эрик Маленький читатель
«Заемное» отношение
ID пользователя Идентификатор книги
10 1
10 2
10 3
12-е 5
12-е 6-е

Вам также понадобится третья таблица, Borrowed , которая содержит информацию о наличии книги. Он будет содержать атрибуты User ID и Book ID . Каждая строка этой заимствованной таблицы присваивает идентификатор книги идентификатору пользователя.

Запись (10,3) будет означать, что пользователь с ID 10 («Hans Vielleser») позаимствовал книгу с ID 3 («Моя жизнь с Астериксом»). Тот же пользователь позаимствовал книгу «Printing Made Easy», о чем свидетельствует запись в таблице (10,2) . В качестве ключа здесь используется набор атрибутов (идентификатор пользователя, идентификатор книги) . В то же время идентификатор пользователя связывает каждую запись в таблице « Заимствованные» с записью в таблице « Пользователи» , а идентификатор книги связывает каждую заимствованную запись с записью в таблице « Книга» . Следовательно, эти атрибуты означают в данном контексте внешний ключ (англ. Foreign key ). Таблицы без внешнего ключа называются плоскими таблицами .

Используемый здесь термин « отношение» описывает не отношения между сущностями (как в модели отношений сущностей ), а взаимосвязь между атрибутами и именем отношения. В приведенном выше примере Hans - это имя (атрибут) пользователя (имя отношения) . Кроме того, отношение обычно используется как синоним таблицы в реляционных базах данных (в основном это связано с типом объекта в ERM).

Демаркация

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

Старые подходы

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

Объектно-ориентированные базы данных

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

Объектно-реляционные базы данных

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

Полуструктурированные базы данных

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

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

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

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

Основы теории реляционных баз данных были заложены Эдгаром Ф. Коддом в 1960-х и 1970-х годах и описаны в его статье «Реляционная модель данных для больших общих банков данных» . Теоретически все операции основаны на реляционной алгебре.

Понимание реляционной алгебры

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

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

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

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

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

Схема базы данных и моделирование

Диаграмма ER в обозначениях Чена

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

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

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

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

сегментация
В реляционном представлении объект хранится сегментированным по множеству различных отношений. Объекты приложения обычно сложные , то есть сами состоят из объектов или списков объектов. Поскольку реляционная модель знает только наборы кортежей, которые состоят из значений , сложные объекты приложения необходимо восстанавливать из отдельных отношений с помощью многочисленных объединений, когда СУБД делает запрос . Это может привести к запутанным запросам, которые необходимо проверять при каждом структурном изменении объекта приложения на предмет необходимости корректировки. Использование объединений, которые должны поддерживаться хорошо подходящими индексами базы данных , делает доступ к объектам более сложным, чем z. Б. в объектной базе данных , как с точки зрения требований к ресурсам, так и с точки зрения усилий по разработке.
Атрибуты искусственного ключа
В некоторых случаях для однозначной идентификации кортежей необходимо использовать искусственные ключи . Это используется, например, Например, для уменьшения размера ключа, если он будет использоваться в качестве внешнего ключа, или для реализации отношений принадлежности. В отношение включаются атрибуты, которые не имеют ничего общего с абстрактным описанием объекта приложения, а являются «всего лишь» административной информацией.
Внешний интерфейс программирования
Поскольку во многих реляционных базах данных доступны только языки манипулирования данными ограниченной мощности, обычно необходимы интерфейсы к более мощным языкам программирования. Это соединение может привести к неудобному обращению, например B. Если ориентированный на наборы SQL должен обрабатываться в ориентированном на наборы C ++ , см. Несоответствие объектно-реляционного импеданса .
Однако существуют также реляционные базы данных с мощными языками программирования, такие как PL / SQL в Oracle или PL / pgSQL в PostgreSQL или T / SQL в Microsoft SQL Server ; В обеих системах баз данных соответствующие языки обработки данных допускают интеграцию других языков программирования. PL / SQL позволяет, например, B. использование программ Java или C ++ в программах PL / SQL. PL / pgSQL, в свою очередь, позволяет программировать серверы на других языках, таких как PHP , Tcl или Python .
Свойства и поведение объекта часто невозможно отобразить
Типичное прикладное поведение объекта не может быть описано в реляционной базе данных. Таким образом, это описание может быть выполнено только вне базы данных в прикладном программном обеспечении. Если несколько приложений используют одну и ту же базу данных, это может привести к избыточной реализации.

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

Сравнение основных терминов

Реляционная база данных Модель отношений Модель отношений сущностей (ERM) Единый язык моделирования (UML)
Диапазон значений (домен, домен)
Заголовок Тип отношения / формат отношения Тип объекта Класс, тип объекта
столбец атрибут атрибут атрибут
стол связь Набор сущностей (-set) Набор объектов, набор экземпляров, класс
Заголовки столбцов Иностранный ключ функциональные отношения ассоциация
ряд Кортеж юридическое лицо Объект , экземпляр
клетка Значение атрибута

Смотри тоже

литература

  • Эдгар Ф. Кодд: Реляционная модель для управления базами данных. Версия 2. Addison-Wesley, Reading et al. 1990, ISBN 0-201-14192-2 .
  • Альфонс Кемпер, Андре Эйклер: Системы баз данных. Введение. Р. Ольденбург Верлаг, Мюнхен 2004 г., ISBN 3-486-27392-2 .
  • Андреас Майер: реляционные и постреляционные базы данных . 7-е издание. Springer-Verlag, Heidelberg 2010, ISBN 978-3-642-05255-2 ( онлайн ).

веб ссылки

Индивидуальные доказательства

  1. ^ Эдгар Ф. Кодд : реляционная модель данных для больших общих банков данных . В: Сообщения ACM . ACM Press, 13 июня 1970 г., ISSN  0001-0782 , стр. 377-387 .