Какие типы содержатся в реляционных базах данных
РЕЛЯЦИОННАЯ
БАЗА ДАННЫХ И ЕЕ ОСОБЕННОСТИ. ВИДЫ СВЯЗЕЙ МЕЖДУ РЕЛЯЦИОННЫМИ ТАБЛИЦАМИ
Реляционная
база данных — это совокупность взаимосвязанных таблиц, каждая
из которых содержит информацию об объектах определенного типа. Строка
таблицы содержит данные об одном объекте (например, товаре, клиенте),
а столбцы таблицы описывают различные характеристики этих объектов — атрибутов
(например, наименование, код товара, сведения о клиенте). Записи, т. е.
строки таблицы, имеют одинаковую структуру — они состоят из полей, хранящих
атрибуты объекта. Каждое поле, т. е. столбец, описывает только одну характеристику
объекта и имеет строго определенный тип данных. Все записи имеют одни
и те же поля, только в них отображаются различные информационные свойства
объекта.
В реляционной базе
данных каждая таблица должна иметь первичный ключ — поле или комбинацию
полей, которые единственным образом идентифицируют каждую строку таблицы.
Если ключ состоит из нескольких полей, он называется составным. Ключ должен
быть уникальным и однозначно определять запись. По значению ключа можно
отыскать единственную запись. Ключи служат также для упорядочивания информации
в БД.
Таблицы реляционной
БД должны отвечать требованиям нормализации отношений. Нормализация
отношений
— это формальный аппарат ограничений на формирование таблиц, который
позволяет устранить дублирование, обеспечивает непротиворечивость
хранимых
в базе данных, уменьшает трудозатраты на ведение базы данных.
Пусть создана таблица
Студент, содержащая следу-рэщие поля: № группы, ФИО, № зачетки, дата рождения,
шазвание специальности, название факультета. Такая организация хранения
информации будет иметь ряд недостатков:
- дублирование информации
(наименование специальности и факультета повторяются для каждого студента),
следовательно, увеличится объем БД; - процедура обновления
информации в таблице затрудняется из-за необходимости редактирования
каждой записи
таблицы.
Нормализация таблиц
предназначена для устранения этих недостатков. Имеется три нормальные
формы отношений.
Первая нормальная
форма. Реляционная таблица приведена к первой нормальной форме тогда
и только тогда, когда ни одна из ее строк не содержит в любом своем поле
более одного значения и ни одно из ее ключевых полей не пусто. Так, если
из таблицы Студент требуется получать сведения по имени студента, то поле
ФИО следует разбить на части Фамилия, Имя, Отчество.
Вторая нормальная
форма. Реляционная таблица задана во второй нормальной форме, если
она удовлетворяет требованиям первой нормальной формы и все ее поля, не
входящие в первичный ключ, связаны полной функциональной зависимостью
с первичным ключом. Чтобы привести таблицу ко второй нормальной форме,
необходимо определить функциональную зависимость полей. Функциональная
зависимость полей — это зависимость, при крторой в экземпляре информационного
объекта определенному значению ключевого реквизита соответствует только
одно значение описательного реквизита.
Третья нормальная
форма. Таблица находится в третьей нормальной форме, если она удовлетворяет
требованиям второй нормальной формы, ни одно из ее неключевых полей не
зависит функционально от любого другого неключевого поля. Например, в
таблице Студент (№ группы, ФИО, № зачетной книжки, Дата рождения, Староста)
три поля — № зачетной книжки, № группы, Староста находятся в транзитивной
зависимости. № группы зависит от № зачетной книжки, а Староста зависит
от № группы. Для устранения транзитивной зависимости необходимо часть
полей таблицы Студент перенести в другую таблицу Группа. Таблицы примут
следующий вид: Студент (№ группы, ФИО, № зачетной книжки, Дата рождения),
Группа (№ группы, Староста).
Над реляционными
таблицами возможны следующие операции:
- Объединение таблиц
с одинаковой структурой. Результат— общая таблица: сначала первая, затем
вторая (конкатенация). - Пересечение таблиц
с одинаковой структурой. Результат — выбираются те записи, которые находятся
в обеих таблицах. - Вычитание таблиц
с одинаковой структурой. Результат — выбираются те записи, которых нет
в вычитаемом. - Выборка (горизонтальное
подмножество). Результат — выбираются записи, отвечающие определенным
условиям. - Проекция (вертикальное
подмножество). Результат — отношение, содержащее часть полей из исходных
таблиц. - Декартово произведение
двух таблиц Записи результирующей таблицы получаются путем объединения
каждой записи первой таблицы с каждой записью другой таблицы.
Реляционные таблицы
могут быть связаны друг с другом, следовательно, данные могут извлекаться
одновременно из нескольких таблиц. Таблицы связываются между собой для
того, чтобы в конечном счете уменьшить объем БД. Связь каждой пары таблиц
обеспечивается при наличии в них одинаковых столбцов.
Существуют следующие
типы информационных связей:
- один-к-одному;
- один-ко-многим;
- многие-ко-многим.
Связь один-к-одному
предполагает, что одному атрибуту первой таблицы соответствует только
один атрибут второй таблицы и наоборот.
Связь один-ко-многим
предполагает, что одному атрибуту первой таблицы соответствует несколько
атрибутов второй таблицы.
Связь многие-ко-многим
предполагает, что одному атрибуту первой таблицы соответствует несколько
атрибутов второй таблицы и наоборот.
Особенности реляционных БД
БД используются для организации хранения данных. Структура реляционной базы данных полностью определяется перечнем названия полей с указанием их типов и свойств. Все записи имеют одинаковые поля, но в них показываются разные свойства объекта. Аналогом реляционной БД считается двумерная таблица. Характерные особенности файла БД:
- Уникальное имя для каждой таблицы.
- Фиксированное число полей.
- На пересечении строки и столбца всегда есть только одно значение.
- Записи отличаются друг от друга хотя бы одним значением элемента.
- Полям присваиваются индивидуальные имена.
- В каждый из столбцов необходимо вставлять однородные данные: целые числа, даты, суммы, имена или фамилии, названия предметов.
Реляционная БД чаще всего не ограничивается одной таблицей. Обычно создаются несколько таблиц со связанной информацией. Это позволяет исполнять более сложные операции над данными. Таблицы реляционной БД обязаны соответствовать требованиям понятия нормализации отношений, то есть ограничениям на формирование, которые позволят избежать дублирования и обеспечат непротиворечивость хранимой информации. Пусть создана таблица «Прокат», содержащая следующие поля: Шифр Клиента, Ф. И. О., Вид устройства, Дата выдачи, Оплата, Срок возврата. Эта организация хранения информации имеет несколько недостатков:
- дублирование информации (вид устройства повторяется для разных клиентов), что увеличивает объём БД;
- для обновления информации требуется обрабатывать каждую запись.
Для устранения этих недостатков необходима нормализация с разделением данных на разные таблицы.
Связывание таблиц
Для любой таблицы реляционной БД задаётся первичный ключ (primary key) — поле или сочетание полей, которые определяют каждую запись. Внешний или вторичный ключ (foreign key) — это одно или несколько полей, ссылающихся на поле primary key другой таблицы.
Составной ключ называется так, потому что создаётся из нескольких полей. При образовании составных ключей не рекомендуется включать в них поля, значения которых точно определяют запись. Например, не следует образовывать ключ, в котором находятся вместе поля «номер паспорта» и «шифр клиента», потому что оба эти атрибута однозначно определяют запись. Поля с повторяющимися в таблице значениями тоже нельзя делать составной частью ключа. По значению ключа возможно найти только одну запись.
Ячейка — это наименьший структурный элемент, который задаёт определённое значение соответствующего поля. Таблицы связываются друг с другом, и поэтому данные могут выбираться сразу из нескольких таблиц. Связь создаётся, если в них присутствуют одинаковые поля. Типы связей:
- один к одному;
- один ко многим;
- многие ко многим.
Связи «один к одному» встречаются довольно редко. «Один ко многим» применяются чаще, например, кассир продаёт много билетов. «Многие ко многим» тоже встречаются часто. Например, студент изучает много предметов. Связи «многие ко многим» нельзя организовывать непосредственно. Для установления отношения необходимо сопоставить каждому primary key внешний ключ, который представляет собой primary key другой таблицы. Реляционные системы базируются на теории реляционной модели, которая включает в себя три аспекта:
- структурный — данные в базе рассматриваются как набор отношений, то есть упорядоченных пар, составленных из заголовка и полей;
- целостности — состоит в проверке правильности согласования данных при обновлении;
- обработки — использование операторов манипулирования таблицами, таких как реляционная алгебра и реляционное исчисление, которые генерируют новые таблицы на основании уже имеющихся.
Управление созданием и использованием БД осуществляется системами управления базами данных (СУБД).
Под их руководством:
- производится добавление, определение, удаление и поиск записей;
- изменяются значения полей.
Для проведения этих операций организуются запросы. Итогом выполнения запросов будут либо изменения в таблицах, либо получение таблицы данных. При этом поддерживается принцип безопасности информации. Для реляционной БД основным языком управления является SQL.
Стадии и пример проектирования хранилища
Приступая к созданию базы, разработчик составляет для объектов манипулирования и их связей представление в терминах реляционной БД (таблицы, поля, записи). Проектирование проходит несколько стадий:
- Первая стадия — это анализ требований. Разработчик должен разрешить главные проблемы: какие элементы данных будут содержаться, как и кто должен к ним обращаться.
- В следующей стадии проектируется логическая структура БД.
- В завершающей стадии проектирования логическая структура БД трансформируется в физическую. Элементы данных определяются как табличные столбцы.
Преимущества этой модели данных состоят в том, что информация отображается в удобной для пользователя форме, а для манипуляций используется развитой математический аппарат.
Примером реляционной базы данных может послужить проект оптимизации деятельности пункта проката. Требуется автоматизировать такие процедуры: учёт клиентов; регистрацию инвентаря, выданного в прокат; отслеживание даты выдачи, сроков возврата, оплаты; получение информации по этим позициям; формирование отчёта по задолженностям. Реляционная БД может быть задана в виде трёх связанных таблиц.
Используя имеющиеся данные, следует определить отношения и объекты этих отношений. Объектами будут являться клиенты и устройства. Отношения между ними состоят в том, что каждый клиент может брать в прокат одно или несколько устройств.
Атрибутами для сопоставления объектов друг другу должны выступать ячейки с уникальным содержимым. В таблицах есть по одному полю с уникальными данными. В № 1 «Клиент» — это шифр клиента, а в № 3 «Склад» — шифр устройства. Это и будут primary keys. Каждая строка таблицы «Прокат» будет связывать два внешних ключа между собой:
- Шифр Клиента — foreign key, ссылающийся на primary key в таблице «Клиент».
- Шифр устройства — foreign key, ссылающийся на первичный ключ в таблице «Склад».
Проблемы модели
Преимущество реляционных хранилищ состоит в том, что они способны обеспечить наилучшее соотношение устойчивости, производительности, гибкости, совместимости и масштабируемости. Реляционные БД предоставляют лёгкий доступ к составляемым отчётам и обеспечивают высокую надёжность и целостность информации из-за отсутствия избыточных данных. Но сейчас, когда всё большее количество приложений работает с высокой нагрузкой, увеличивается значение фактора масштабируемости.
Реляционные БД легко масштабируются, только когда они расположены на одном сервере. Если потребуется увеличить количество серверов и разделить нагрузку между ними, то возрастёт сложность хранилищ, что значительно снизит возможность использовать их как платформу для мощных распределённых систем. Поэтому приходится применять другие типы БД, которые обладают лучшей масштабируемостью и отказываться от возможностей, предоставляемых реляционными хранилищами.
Реляционная БД — это совокупность связей, которые способны структурировать данные, что даёт возможность рационального хранения и эффективного использования информационных материалов.
Типы баз данных, называемых также моделями БД или семействами БД, представляют собой шаблоны и
структуры, используемые для организации данных в системе управления базами
данных (СУБД). Выбор типа повлияет на то, какие операции сможет выполнять приложение, как будут представлены данные, на функции СУБД для разработки и рантайма.
Начнём с трёх типов БД, которые всё ещё могут встречаться в специализированных средах, но в основном заменены надежными и производительными альтернативами.
1. Простые структуры
данных
Первый и простейший способ хранения данных – текстовые файлы. Метод применяется и сегодня для работы с небольшими объёмами информации. Для разделения полей используется специальный символ: запятая или точка с запятой в csv-файлах датасетов, двоеточие или пробел в *nix-подобных
системах:
/etc/passwd в *nix системе
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
bob:x:1000:1000:Bob Smith,,,:/home/bob:/bin/bash
Следствия:
- ограничен тип и уровень сложности хранимой информации;
- трудно установить связи между компонентами данных;
- отсутствие функций параллелизма;
- практичны только для систем с небольшими требованиями к чтению и записи;
- используются для хранения конфигурационных данных;
- нет необходимости в стороннем программном обеспечении.
Примеры:
- /etc/passwd и /etc/fstab в *nix-системах
- csv-файлы
2. Иерархические базы данных
В отличие от текстовых таблиц, в следующем типе БД появляются связи между объектами. В иерархических базах данных каждая запись имеет одного «родителя». Это создаёт
древовидную структуру, в которой записи классифицируются по их отношениям с цепочкой родительских записей.
Пример построения иерархических связей
Следствия:
- информация организована в виде древовидной структуры с отношениями «предок-потомок»;
- каждая запись может иметь не более одного родителя;
- связи между записями выполнены в виде физических указателей;
- невозможно реализовать отношения «многих-ко-многим».
Примеры:
- файловые системы
- DNS
- LDAP
3. Сетевые базы данных
Сетевые базы данных расширяют
функциональность иерархических: записи
могут иметь более одного родителя. А значит, можно моделировать сложные отношения.
Пример связей в сетевой базе данных
Следствия:
- сетевые базы данных представляются не деревом, а общим графом
- ограничены теми же шаблонами доступа, что иерархические БД
Примеры:
- IDMS
4. SQL базы данных
Реляционные базы данных – старейший тип до сих пор широко используемых БД общего назначения. Данные и связи между данными организованы с помощью таблиц. Каждый столбец в таблице имеет имя и тип. Каждая строка представляет отдельную
запись или элемент данных в таблице, который содержит значения для каждого из
столбцов.
Следствия:
- поле в таблице, называемое внешним ключом, может содержать ссылки на столбцы в других таблицах, что позволяет их соединять;
- высокоорганизованная структура и гибкость делает реляционные БД мощными и адаптируемыми ко различным типам данных;
- для доступа к данным используется язык структурированных запросов (SQL);
- надёжный выбор для многих приложений.
Примеры:
- MySQL
- MariaDB
- PostgreSQL
- SQLite
NoSQL
– группа типов БД, предлагающих подходы,
отличные от стандартного реляционного шаблона. Говоря NoSQL, подразумевают либо «не-SQL», либо «не только SQL», чтобы уточнить, что иногда
допускается SQL-подобный запрос.
5. Базы данных «ключ-значение»
В базах данных «ключ-значение» для хранения
информации вы предоставляте ключ и объект данных, который нужно сохранить. Например, JSON-объект, изображение или текст. Чтобы запросить данные, отправляете ключ и получаете blob-объект.
Следствия:
- хранилища обеспечивают быстрый и малозатратный доступ;
- часто хранят данные конфигураций и информацию о состоянии данных, представленных словарями или хэшем;
- нет жёсткой схемы отношения между данными, поэтому в таких БД часто хранят одновременно различные типы данных;
- разработчик отвечает за определение схемы именования ключей и за то, чтобы значение имело соответствующий тип/формат.
Примеры:
- Redis
- memcached
- etcd
6. Документная база данных
Документные базы
данных (также документоориентированные БД или хранилища
документов), совместно используют базовую семантику доступа и поиска хранилищ
ключей и значений. Такие БД также используют ключ для уникальной
идентификации данных. Разница между хранилищами «ключ-значение» и документными
БД заключается в том, что вместо хранения blob-объектов,
документоориентированные базы хранят данные в структурированных форматах – JSON,
BSON или XML.
Следствия:
- база данных не предписывает опредёленный формат или схему;
- каждый документ может иметь свою внутреннюю структуру;
- документные БД являются хорошим выбором для быстрой разработки;
- в любой момент можно менять свойства данных, не изменяя структуру или сами данные.
Примеры:
- MongoDB
- RethinkDB
7. Графовая база данных
Вместо сопоставления связей с таблицами и внешними ключами, графовые базы данных устанавливают связи, используя узлы, рёбра и свойства.
Графовые базы
представляют данные в виде отдельных узлов, которые могут иметь любое
количество связанных с ними свойств.
Следствия:
- выглядят аналогично сетевым;
- фокусируются на связях между элементами;
- явно отображает связи между типами данных;
- не требуют пошагового обхода для перемещения между элементами;
- нет ограничений в типах представляемых связей.
Примеры:
- Neo4j
- JanusGraph
- Dgraph
8. Колоночные базы данных
Колоночные базы данных
(также нереляционные колоночные хранилища или базы данных с
широкими столбцами) принадлежат к семейству NoSQL БД, но внешне похож на реляционные БД.
Как и реляционные, колоночные БД хранят данные, используя строки и
столбцы, но с иной связью между элементами.
В реляционных БД все строки должны соответствовать фиксированной схеме. Схема определяет, какие столбцы будут в таблице, типы данных и другие критерии. В колоночных базах вместо
таблиц имеются структуры – «колоночные семейства». Семейства содержат строки,
каждая из которых определяет собственный формат. Строка состоит из уникального
идентификатора, используемого для поиска, за которым следуют наборы имён и
значений столбцов.
Следствия:
- БД удобны при работе с приложениями, требующими высокой производительности;
- данные и метаданные записи доступны по одному идентификатору;
- гарантировано размещение всех данных из строки в одном кластере, что упрощает сегментацию и масштабирование данных.
Примеры:
- Cassandra
- HBase
9. Базы данных временных
рядов
Базы данных временны́х рядов созданы для сбора и управления элементами, меняющимися с течением времени. Большинство таких БД организованы в структуры, которые записывают значения для одного
элемента. Например, можно создать таблицу для отслеживания температуры процессора.
Внутри каждое значение будет состоять из временной метки и показателя
температуры. В
таблице может быть несколько метрик.
Следствия:
- ориентированы на запись;
- предназначены для обработки постоянного потока входных данных;
- производительность зависит от количества отслеживаемых элементов, интервала опроса между записью новых значений и фактической полезной нагрузки данных.
Примеры:
- OpenTSDB
- Prometheus
- InfluxDB
- TimescaleDB
NewSQL и многомодельные БД являются разными типами баз данных, но решают одну группу проблем, вызванных полярными подходами SQL или NoSQL-стратегии. Почему бы не объединить преимущества обеих групп?
10. NewSQL базы данных
NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более
современных, масштабируемых конструкций. Цель – обеспечить
большую масштабируемость, нежели реляционные БД, и более высокие гарантии
согласованности, чем в NoSQL. Компромисс между согласованностью и доступностью
является фундаментальной проблемой распределённых баз данных, описываемой
теоремой CAP.
Следствия:
- возможность горизонтального масштабирования;
- высокая доступность;
- большая производительность и репликация;
- небольшой функционал и гибкость;
- немалое потребление ресурсов и необходимость специализированных знаний для работы с базой данных.
Примеры:
- MemSQL
- VoltDB
- Spanner
- Calvin
- CockroachDB
- FaunaDB
- yugabyteDB
11. Многомодельные базы данных
Многомодельные базы
данных – базы, объединяющие функциональные возможности нескольких видов БД.
Преимущества такого подхода очевидны – одна и та же система может использовать
различные представления для разных типов данных.
Совместное размещение
данных из нескольких типов БД в одной системе позволяет выполнять новые
операции, которые в противном случае были бы затруднены или невозможны.
Например, многомодельные базы могут позволить юзерам получить доступ к данным,
хранящимся в разных типах БД, и управлять ими в рамках одного запроса, а также поддерживают
согласованность данных при выполнении операций, изменяющих информацию сразу в
нескольких системах.
Следствия:
- помогают уменьшить нагрузку на СУБД;
- позволяют расширяться до новых моделей по мере изменения потребностей без внесения изменений в базовую инфраструктуру;
- обеспечивают непрерывный доступ и простое распределение данных;
- имеют линейную масштабируемость и просты для разработки.
Примеры:
- ArangoDB
- OrientDB
- Couchbase
Заключение
Изменение типов хранимых данных, требования к скорости и производительности привели и к продолжающемуся расширению типов баз данных. При этом каждый из них продолжает быть нужным в своей нише, где взаимосвязи между данными ассоциируются с определенной схемой строения базы данных.