Как работают реляционные базы данных (часть 1)

Отношения и их реализация в реляционной модели данных

Отношение на множестве доменов
— это подмножество декартова произведения этих доменов:

Пример 1. Определены домены: —
множество фамилий преподавателей, —
множество аудиторий, —
множество учебных групп, —
множество учебных дисциплин. Записать отношения: 1) закрепление преподавателей за учебными курсами;
2) расписание занятий в группах.

Решение.

1) закрепление преподавателей за учебными курсами:

.

Это отношение определяет множество преподавателей, ведущих множество учебных дисциплин.

2) расписание занятий в группах:

.

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

Свойства отношений:

• уникальное имя отношения;
• уникальное имя атрибута;
• нет одинаковых кортежей;
• кортежи не упорядочены сверху вниз;
• атрибуты не упорядочены слева направо;
• все значения атрибутов атомарные (нормализованное отношение).

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

Виды отношений:

• именованное отношение;
• базовое отношение;
• производное отношение;
• выражаемое отношение;
• представление (view);
• снимки (snapshot);
• результат запроса;
• промежуточный результат.

Именованное отношение — это переменная отношения, определённая в СУБД (системе управления
базами данных) посредством оператора CREATE (CREATE TABLE, CREATE BASE RELATION, CREATE
VIEW, CREATE SNAPSHOT).

Базовое отношение — это именованное отношение, которое не является производным.
Существование базового отношения не зависит от существования других отношений.

Производное отношение — это отношение, которое определено через другие именованные
отношения. Производное отношение зависит от существования других — базовых — отношений.

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

Представление — это именованное производное отношение. Представлены в базе данных в
виде определения. Представление не хранится в физической памяти системы управления базой данных (СУБД),
а формируется с использованием других именованных отношений.

Снимки (snapshot) — это то же, что и представление, но с физическим сохранением
и с периодическим обновлением.

Результат запроса — это неименованное производное отношение. СУБД не обеспечивает
постоянного существования результатов запросов. Для сохранения результата запроса его можно присвоить
какому-либо именованному отношению.

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

Достоинства документных баз

• Позволяют хранить объекты с разной структурой.
• Могут отображать почти все структуры данных, включая объекты на основе ООП, списки и словари, используя старый добрый JSON.
• Несмотря на то, что NoSQL не схематичны по своей природе, они часто поддерживают проверку схемы. Это значит, что вы можете сделать коллекцию со схемой. Эта схема не будет простой, как таблица: это будет JSON схема со специфическими полями.
• Запросы к NoSQL очень быстрые — каждая запись независима и, следовательно, время запроса не зависит от размера базы. По той же причине эта БД поддерживает параллельность.
• В NoSQL масштабирование БД осуществляется добавлением компьютеров и распределением данных между ними, этот метод называется горизонтальное масштабирование. Оно позволяет автоматически добавлять ресурсы к БД, когда нам нужно, не провоцируя простои.

Объектная модель

Объектные (или объектно-ориентированные) базы данных по большей части основываются на использовании объектно-ориентированных языков программирования,наподобие C++, Java и Smalltalk. В частности, ОСУБД создаются за счет комбинирования возможностей баз данных с функциональностью объектно-ориентированных языков программирования. Из-за этого любая ОСУБД может, по сути, считаться просто расширением объектно-ориентированного языка с добавленными к нему возможностями для обеспечения взаимосовместимости и восстановления данных. Объектно-ориентированный язык применяется и для разработки приложения, и для хранения данных.Кроме того, он используется для создания объектов, которые являются основными компонентами ОСУБД.

• Ниже перечислено несколько терминов, которые в объектно-ориентированных средах имеют особое значение.
• Объектами (objects) называются сущности, содержащие атрибуты объекта реального мира и ассоциируемые с ним действия.
• Свойствами (properties) называются различные атрибуты объекта.
• Методами (methods) в объектном мире называются функции, которые определяют поведение объекта.
• Взаимодействуют объекты друг с другом посредством сообщений (messages).
• Классом (class) называется группа объектов, обладающих одинаковыми атрибутами.
• Экземплярами (instances) называются фактические инкарнации объектов в классе.
• Классы могут делиться на подклассы (subclasses) и тогда иметь родительский класс, называемый суперклассом (superclass).

Ниже перечислены три основных понятия, в которых нужно обязательно разбираться, чтобы работать с объектно-ориентированными системами.

• Полиморфизм (polymorphism). Под полиморфизмом подразумевается способность объектов реагировать по-разному при получении разных наборов информации (в виде параметров). Объектно-ориентированные языки позволяют делать так,чтобы в зависимости от предоставляемых параметров выполнялись разные методы. В языках, не являющихся объектно-ориентированными, обеспечивать выполнение двух различных задач можно только путем создания двух функций с двумя разными именами.
• Инкапсуляция (encapsulation). Под инкапсуляцией подразумевается возможность включать в объекты информацию как о том, что они собой представляют (их свойства), так и о том, что они могут делать (их методы). Другими словами инкапсуляция позволяет упаковывать код и данные вместе. Например, при наличии в модели объекта, представляющего человека, и метода, позволяющего вычислять его ежегодную заработную плату, код (или метод) для вычисления заработной платы будет “инкапсулироваться” вместе с экземпляром объекта (т.е. человека).
• Наследование (inheritance). Под наследованием подразумевается возможность порождения одного класса от другого для того, чтобы тот мог обладать как некоторыми характеристиками своего родителя, так и своими собственными, отличающимися характеристиками. Например, объект, представляющий студента (Student),может являться подклассом класса, представляющего человека (Person).

Устройство реляционной базы данных – таблицы, строки, столбцы

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

Атрибут множества, это название столбца в таблице БД. Математически, атрибут это множество, названий столбцов. Каждое название столбца уникально и неупорядочено. То есть, мы можем «добраться» до уникального названия столбца не затрагивая другие столбцы.

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

О неупорядоченности атрибутов

Математически, множество атрибутов: B.4, B.89, B.55, B.3, B.99, точно такое же, как множество: B.89, B.55, B.4, B.99, B.3. Но на практике, мы не можем вызывать столбцы по названию в произвольном порядке. Для упорядочивания вызова и нужен структурный язык. Для реляционных баз данных структурный язык это язык: SQL. В нем упорядоченный вызов столбцов поатрибутам выглядит так:

SELECT B.4, B.89, B.55, B.3, B.99 FROM B

Или

SELECT B.89, B.55, B.4, B.99, B.3 FROM B

Структура реляционной модели данных

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

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

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

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

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

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

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

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

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

• База данных;
• Таблица;
• Запись.

База данных

База данных — это высокоуровневное понятие, которое означает объединение совокупности данных, хранимых для выполнения одной цели. Если мы делаем современный сайт, то все его данные будут храниться внутри одной базы данных. Для сайта онлайн-дневника наблюдений за погодой тоже понадобится создать отдельную базу данных.

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц. Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц). Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога. Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов. Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel). Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация. В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

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

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

• Создадим для сайта новую БД и дадим ей название «weather_diary».
• Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
  • Город (тип: текст);
  • День (тип: дата);
  • Температура (тип: число);
  • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
  • Были ли осадки (тип: истина или ложь);
  • Комментарий (тип: текст).
• При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

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

Английское слово „relation“ можно перевести как связь, отношение. А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой. Что это за связи? Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации. В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными. Но можно поступить иначе:

• Создать новую таблицу с именем „cities“.
• Все города в России известны, поэтому их все можно добавить в одну таблицу.
• Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
• При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

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

Связи между таблицами в БД бывают разных видов. В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот! Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

Это интересно: Трудовая книжка

Аксиомы Армстронга

Существуют правила вывода новых ФЗ из существующих, называемые аксиомами Армстронга.

Аксиомы Армстронга

1. Правило рефлексивности: если \(B \subset A\), то \(A\rightarrow B\)
2. Правило дополнения: если \(A\rightarrow B\), то \(AC\rightarrow BC\)
3. Правило транзитивности: если \(A\rightarrow B\) и \(B\rightarrow C\), то \(A\rightarrow C\)

Из этих аксиом так же могут быть выведены следующие дополнительные правила:

1. Правило самоопределения: \(A\rightarrow A\)
2. Правило декомпозиции: Если \(A\rightarrow BC\), то \(A\rightarrow B\) и \(A\rightarrow C\)
3. Правило объединения: Если \(A\rightarrow B\) и \(A\rightarrow C\), то \(A\rightarrow BC\)
4. Правило композиции: Если \(A\rightarrow B\) и \(C\rightarrow D\), то \(AC\rightarrow BD\)

Можно заметить, что, вследствие правила рефлексивности, любое множество атрибутов \(A\) подразумевает ФЗ вида \(A\to A\). Такие ФЗ, а так же следующие из них, не представляют интереса, и называются тривиальными.

Тривиальная функиональная зависимость

ФЗ \(A \to B\), такая, что \(B \subset A\).

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

Замыкание множества ФЗ

Замыканием множества ФЗ называется такое множество ФЗ, которое включает все ФЗ исходного множества, а так же все подразумеваемые ими. Другими словами, для отношения \(R\), обладающего функциональными зависимостями \(S\), замыканием \(S^+\) называется множество всех ФЗ, возможных для \(R\), исходя из \(S\).

Как правило, требуется установить, будет ли некая ФЗ \(X\rightarrow Y\) следовать из данного множества ФЗ \(S\). Оказывается, это возможно тогда и только тогда, когда множество атрибутов \(Y\) является подмножеством замыкания атрибутов \(X^+\) в \(S\).

Замыкание атрибутов

Замыканием \(X^+\) атрибутов \(X\) по множеству ФЗ \(S\) называется множество всех атрибутов, которые функционально зависят от какого-либо подмножества \(X\).

Для вычисления замыкания множества атрибутов \(X^+\) по множеству ФЗ \(S\) существует следующее правило: для каждой ФЗ \(A\rightarrow B\) в \(S\), если \(A \subset X^+\), то и \(B \subset X^+\), причем достаточно начать с предположения, что \(X^+ = X\).

Следует заметить, что для любого замыкания \(X^+\), существуют ФЗ вида \(X \to B\), где \(B \subset X^+\), таким образом, замыкания всех атрибутов отношения по его ФЗ описывают замыкание ФЗ этого отношения.

Это правило используется для вычисления неприводимого множества ФЗ, эквивалентного данному (в смысле эквивалентности их замыканий). Уменьшение количества ФЗ при сохранении замыкания (и, следовательно, внутренней логики, описываемой ФЗ) является важным шагом в проектировании БД.

Множество ФЗ называется неприводимым, если:

1. Правая часть каждой ФЗ содержит только один элемент
2. Ни один атрибут ни одной левой части ФЗ множества не может быть удален без изменения замыкания
3. Ни одна ФЗ множества не может быть удалена без изменения замыкания.

Для любого множества ФЗ существует хотя бы одно эквивалентное неприводимое множество. Такое множество называется минимальным покрытием.

Виды баз данных

• Фактографическая – содержит краткую информацию об объектах некоторой системы в строго фиксированном формате;
• Документальная – содержит документы самого разного типа: текстовые, графические, звуковые, мультимедийные;
• Распределённая – база данных, разные части которой хранятся на различных компьютерах, объединённых в сеть;
• Централизованная – база данных, хранящихся на одном компьютере;
• Реляционная – база данных с табличной организацией данных;
• Неструктурированная (NoSQL) — база данных, в которой делается попытка решить проблемы масштабируемости и доступности за счёт атомарности (англ. atomicity) и согласованности данных, но не имеющих четкой (реляционной) структуры.

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

• создание базы;
• запись данных в базу;
• корректировка данных;
• выборка данных из базы по запросам пользователя.

Задачи этого списка называются стандартными.

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

База данных в разных системах имеет различную структуру.

В ПВЭМ обычно используются реляционные БД – в таких базах файл является по структуре таблицей. В ней столбцы называются полями, строки – записями.

В БД содержатся банные некоторого множества объктов. Каждая запись содержит данные одного объекта. Каждая такая БД определяется именем файла, списком полей, шириной полей. Например, БД Школа (Ученик, Класс, Адрес).

Примером БД может служить расписание движения поездов или автобусов. Здесь каждая строчка – запись отражает данные строго одного объекта. База включает поля: номер рейса, маршрута следования, время отправления и т.д.

Классическим примером БД является и телефонный справочник. Запрос к базе данных – это предписание, указывающее, какие данные пользователь желает получить из базы.

Некоторые запросы могут представлять собой серьёзную задачу, для решения которой потребляется составлять сложную программу. Например, запрос к базе – автобусному расписанию: определить разницу в среднем интервале отправления автобусов из Ростова в Таганрог и из Ростова в Шахты.

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

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

• набор данных
• источник данных
• визуальные элементы управления

В нашем случае эта триада реализуется в виде:

• Table
• DataSource
• DBGrid

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

Однако, поскольку Table является невизуальным компонентом, хотя связь с базой и установлена, пользователь не в состоянии увидеть какие – либо данные. Поэтому необходимо добавить визуальные компоненты, отображающие эти данные. В нашем случае это сетка DBGrid. Сетка сама по себе «не знает», какие данные ей нужно отображать, её нужно подключить к Table, что и делается через компонент – посредник .

А зачем нужен компонент – посредник? Почему бы сразу не подключаться к Table?

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

Приложения баз данных – нить, связывающая БД и пользователя:

БД => набор данных –=> источник данных => визуальные компоненты => пользователь

Набор данных:

• Table(таблица, навигационный доступ)
• Query(запрос, реляционный доступ)

Визуальные компоненты:

• Сетки DBGrid, DBCtrlGrid
• Навигатор DBNavigator
• Всяческие аналоги Lable, Editи т.д.
• Компоненты подстановки

Рекомендации по реляционным и NoSQL системам

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

В следующих разделах мы рассмотрим параметры, доступные в облаке Azure для хранения и управления собственными данными в облаке.

Представления о преимуществах и недостатках

Аппаратная составляющая вышла на уровень гарантированной надежности, скорости и эффективности. Дело стало за малым: программная составляющая должна обеспечить свой уровень компетенции.

Одни авторы относят к преимуществам:

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

Другие смотрят на преимущества иначе:

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

Недостатки определяют обычно так:

• сложность, размер, стоимость;
• затраты на аппаратное обеспечение (финансы);
• затраты на преобразование (вычислительные и временные);
• серьезные последствия при выходе системы из строя;
• в контексте сетевых БД: сложность физической реализации, жесткость связи между элементами данных, ограничения на удобство манипуляции данными;
• иерархические БД: громоздкость, сложность физической реализации для больших древовидных структур;
• реляционные БД: отсутствие стандартных средств идентификации каждой записи.

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