Реляционная база данных. что это такое и как работает

Операция разности

Разность двух отношений R1 и R2 () состоит из кортежей (или записей, или строк),
которые имеются в отношении R1, но отсутствуют в отношении R2. Отношения R1 и R2 должны быть
совместимы по объединению. Операция разности реляционной алгебры идентична операции разности множеств,
которая также описана в материале «Множества и операции над множествами»
.

Запрос SQL

SELECT A1, A2, A3 from R2 EXCEPTSELECT A1, A2, A3 from R1

Установим, что получится в результате выполнения этой операции
реляционной алгебры и соответствующего ей запроса SQL. Вновь даны два отношения R1 и R2:

R1 R2
A1 A2 A3 A1 A2 A3
Z7 aa w11 X8 pp k21
B7 hh h15 Q2 ee h15
X8 pp w11 X8 pp w11

Из отношения R2 исключаем строку, которая есть также в отношении R2 —
третью — и получаем новое отношение:

R
A1 A2 A3
X8 pp w11
Q2 ee h15

В некоторых диалектах SQL отсутствует ключевое слово EXCEPT. Поэтому, например, в
MySQL и других, операция пересечения множеств может реализована с применением предиката NOT EXISTS.

История

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

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

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

[править] Основные шаги проектирования РБД с использованием объектного подхода

  1. Выделить объекты ПО и определить связи между ними (1:1, 1:М, М:N).
  2. Представить каждый объект ПО в виде таблицы, определив для нее первичный ключ и описав ограничения на значения данных.
  3. Представить каждую взаимосвязь вида 1:1 или 1:М с помощью внешнего ключа, добавив его в таблицу, находящуюся со стороны «многие».
  4. Представить каждую взаимосвязь вида М:N в виде отдельной таблицы с составным первичным ключом. Ввести в эту таблицу атрибуты, описывающие связь.
  5. Выполнить процедуру нормализации отношений (таблиц) в БД.
  6. Повторить перечисленные шаги пока не будет получен окончательный проект БД.

БД считается правильно спроектированной когда «один факт хранится один раз».

О выборе NoSQL-баз данных

  1. Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных.
  2. Использование облачных вычислений и хранилищ. Облачные хранилища — отличное решение, но они требуют, чтобы данные можно было легко распределить между несколькими серверами для обеспечения масштабирования. Использование, для тестирования и разработки, локального оборудования, а затем перенос системы в облако, где она и работает — это именно то, для чего созданы NoSQL базы данных.
  3. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы, применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз.

O(1) vs O(n2)

В настоящее время многие разработчики не заботятся о временной сложности алгоритмов … и они правы!

Но когда вы имеете дело с большим количеством данных (я не говорю о тысячах) или если вы боретесь за миллисекунды, становится критически важным понять эту концепцию. И как вы понимаете, базы данных должны иметь дело с обеими ситуациями! Я не заставлю вас потратить больше времени, чем необходимо чтобы ухватить суть. Это поможет нам позже понять концепцию оптимизации на основе затрат (cost based optimization).

Концепция

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

Например, когда я говорю «этот алгоритм имеет сложность O (some_function() )», это означает, что для обработки определенного объема данных алгоритму требуется some_function(a_certain_amount_of_data) операций.

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

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

  • O(1) или постоянная сложность остаются постоянными (иначе это не будет называться постоянной сложностью).
  • O(log(n)) остается низкой даже с миллиардами данных.
  • Наихудшая сложность — O(n2), где количество операций быстро растет.
  • Две другие сложности так же быстро увеличиваются.

Примеры

При небольшом количестве данных разница между O(1) и O(n2) незначительна. Например, предположим, что у вас есть алгоритм, который должен обрабатывать 2000 элементов.

  • Алгоритм O (1) обойдется вам в 1 операцию
  • Алгоритм O (log (n)) обойдется вам в 7 операций
  • Алгоритм O (n) обойдется вам в 2 000 операций
  • Алгоритм O (n * log (n)) обойдется вам в 14 000 операций
  • Алгоритм O (n2) обойдется вам в 4 000 000 операций

Как я уже сказал, по-прежнему важно знать эту концепцию при работе с огромным количеством данных. Если на этот раз алгоритм должен обработать 1 000 000 элементов (что не так уж много для базы данных):

  • Алгоритм O (1) обойдется вам в 1 операцию
  • Алгоритм O (log (n)) обойдется вам в 14 операций
  • Алгоритм O (n) обойдется вам в 1 000 000 операций
  • Алгоритм O (n * log (n)) обойдется вам в 14 000 000 операций
  • Алгоритм O (n2) обойдется вам в 1 000 000 000 000 операций

Я не делал расчетов, но я бы сказал, что с помощью алгоритма O (n2) у вас есть время выпить кофе (даже два!). Если вы добавите еще 0 к объему данных, у вас будет время, чтобы вздремнуть.

Идем глубже

Для справки:

  • Поиск в хорошей хеш-таблице находит элемент за O (1).
  • Поиск в хорошо сбалансированном дереве дает результат за O (log (n)).
  • Поиск в массиве дает результат за O (n).
  • Лучшие алгоритмы сортировки имеют сложность O (n * log (n)).
  • Плохой алгоритм сортировки имеет сложность O (n2).

Примечание: в следующих частях мы увидим эти алгоритмы и структуры данных.

Есть несколько типов временной сложности алгоритма:

  • сценарий среднего случая
  • лучший вариант развития событий
  • и худший сценарий

Временная сложность часто является наихудшим сценарием.

Я говорил только о временной сложности алгоритма, но сложность также применима для:

  • потребления памяти алгоритмом
  • потребления дискового ввода / вывода алгоритмом

Конечно, есть сложности хуже, чем n2, например:

  • n4: это ужасно! Некоторые из упомянутых алгоритмов имеют такую сложность.
  • 3n: это еще хуже! Один из алгоритмов, которые мы увидим в середине этой статьи, имеет эту сложность (и он действительно используется во многих базах данных).
  • факториал n: вы никогда не получите свои результаты даже с небольшим количеством данных.
  • nn: если вы столкнетесь с этой сложностью, вы должны спросить себя, действительно ли это ваша сфера деятельности …

Операция выборки

О том, как работает оператор языка SQL SELECT, можно узнать на уроке
SQL SELECT — запрос на выборку из базы данных.

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

Таким образом, операция выборки — унарная операция — и записывается следующим образом:

,

где — предикат (логическое условие).

Запрос SQL

SELECT * from R3 WHERE A3>’d0′

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

R3
A1 A2 A3 A4
3 hh yl ms
4 pp a1 sr
1 rr yl ms

Просматриваем столбец А3 и устанавливаем, что предикату A3>’d0′ удовлетворяют
записи в первой и третьей строках исходного отношения (так как номер буквы y в алфавите
больше номера буквы d). В результате получаем следующее новое отношение, в котором две строки:

R
A1 A2 A3 A4
3 hh yl ms
1 rr yl ms

Комбинировать всевозможные логические условия для выборок Вам поможет
материал «Булева алгебра (алгебра логики)».

А в материалах раздела «Программирование PHP/MySQL»
Вы найдёт немало примеров комбинаций различных логических условий для выборок из базы данных.

Хранилище пар «ключ — значение»Key/value data stores

Хранилище пар «ключ — значение» по сути представляет собой большую хэш-таблицу.A key/value store is essentially a large hash table. Каждое значение сопоставляется с уникальным ключом, и хранилище ключей использует этот ключ для хранения данных, применяя к нему некоторую функцию хэширования.You associate each data value with a unique key, and the key/value store uses this key to store the data by using an appropriate hashing function. Выбор функции хэширования должен обеспечить равномерное распределение хэшированных ключей по хранилищу данных.The hashing function is selected to provide an even distribution of hashed keys across the data storage.

Большинство хранилищ пар «ключ — значение» поддерживают только самые простые операции запроса, вставки и удаления.Most key/value stores only support simple query, insert, and delete operations. Чтобы частично или полностью изменить значение, приложение всегда перезаписывает существующее значение целиком.To modify a value (either partially or completely), an application must overwrite the existing data for the entire value. В большинстве реализаций атомарной операцией считается чтение или запись одного значения.In most implementations, reading or writing a single value is an atomic operation. Запись больших значений занимает относительно долгое время.If the value is large, writing may take some time.

Приложение может хранить в наборе значений произвольные данные, но некоторые хранилища пар «ключ — значение» накладывают ограничения на максимальный размер значений.An application can store arbitrary data as a set of values, although some key/value stores impose limits on the maximum size of values. Программное обеспечение хранилища ничего не знает о значениях, которые в нем хранятся.The stored values are opaque to the storage system software. Все сведения о схеме поддерживаются и применяются на уровне приложения.Any schema information must be provided and interpreted by the application. Эти значения по существу являются большими двоичными объектами, которые хранилище извлекает и сохраняет по соответствующему ключу.Essentially, values are blobs and the key/value store simply retrieves or stores the value by key.

Хранилища пар «ключ — значение» рассчитаны на приложения, выполняющие простые операции поиска на основе значения ключа или диапазона ключей, но не очень подходят для систем, которым нужно запрашивать данные из нескольких таблиц хранилищ пар «ключ — значение», например присоединенные данные в нескольких таблицах.Key/value stores are highly optimized for applications performing simple lookups using the value of the key, or by a range of keys, but are less suitable for systems that need to query data across different tables of keys/values, such as joining data across multiple tables.

Кроме того, хранилища пар «ключ — значение» неудобны в сценариях, где могут выполняться запросы или фильтрация по значению, а не только по ключам.Key/value stores are also not optimized for scenarios where querying or filtering by non-key values is important, rather than performing lookups based only on keys. Например, с помощью реляционной базы данных можно найти запись, используя предложение WHERE для фильтрации неключевых столбцов, но в хранилищах «ключ-значение» обычно отсутствует возможность поиска в значениях, или, если они есть, требуется медленный Просмотр всех значений.For example, with a relational database, you can find a record by using a WHERE clause to filter the non-key columns, but key/values stores usually do not have this type of lookup capability for values, or if they do, it requires a slow scan of all values.

Одно хранилище пар «ключ — значение» очень легко масштабируется, поскольку позволяет удобно распределить данные среди нескольких узлов на разных компьютерах.A single key/value store can be extremely scalable, as the data store can easily distribute data across multiple nodes on separate machines.

Соответствующие службы Azure:Relevant Azure services:

  • API таблиц Azure Cosmos DBAzure Cosmos DB Table API
  • Кэш Azure для RedisAzure Cache for Redis
  • хранилище таблиц AzureAzure Table Storage

Хранилище данных объектовObject data stores

Хранилища данных объектов оптимизированы для хранения и извлечения больших двоичных объектов, например изображений, текстовых файлов, видео- и аудиопотоков, объектов данных и документов приложений большого размера, образы дисков виртуальных машин.Object data stores are optimized for storing and retrieving large binary objects or blobs such as images, text files, video and audio streams, large application data objects and documents, and virtual machine disk images. Объект состоит из сохраненных данных, метаданных и уникального идентификатора доступа к объекту.An object consists of the stored data, some metadata, and a unique ID for accessing the object. Хранилища объектов поддерживают отдельные большие файлы, а также позволяют управлять всеми файлами за счет внушительного общего объема хранилища.Object stores are designed to support files that are individually very large, as well provide large amounts of total storage to manage all files.

Некоторые хранилища данных объектов реплицируют определенный большой двоичный объект между несколькими узлами кластера, что обеспечивает быстрое параллельное чтение.Some object data stores replicate a given blob across multiple server nodes, which enables fast parallel reads. Это, в свою очередь, позволяет реализовать масштабируемую архитектуру запроса данных, хранящихся в больших файлах, так как несколько процессов, обычно выполняющихся на разных серверах, могут одновременно запрашивать большие файлы данных.This in turn enables the scale-out querying of data contained in large files, because multiple processes, typically running on different servers, can each query the large data file simultaneously.

Часто хранилища данных объектов используют как сетевые общие папки.One special case of object data stores is the network file share. Доступ к файлам, хранящимся в этих папках, можно получить через компьютерную сеть с использованием стандартных сетевых протоколов, например SMB.Using file shares enables files to be accessed across a network using standard networking protocols like server message block (SMB). Учитывая соответствующие механизмы обеспечения безопасности и параллельного управления доступом, совместное использование данных позволяет распределенным службам обеспечить высокую масштабируемость доступа к данным для базовых операций низкого уровня, таких как простые запросы на чтение и запись.Given appropriate security and concurrent access control mechanisms, sharing data in this way can enable distributed services to provide highly scalable data access for basic, low-level operations such as simple read and write requests.

Соответствующие службы Azure:Relevant Azure services:

  • Хранилище BLOB-объектов AzureAzure Blob Storage
  • Azure Data Lake StorageAzure Data Lake Store
  • Хранилище файлов AzureAzure File Storage

Операция деления

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

Запрос SQL

SELECT DISTINCT A1, A4 from R5 WHERENOT EXIST (SELECT * from R6 WHERE NOT EXIST
R6.A2 = R5.A2 AND
R6.A3 = R5.A3)

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

R5 R6
A1 A2 A3 A4 A2 A3
2 S3 4 sun R4 8
3 X8 7 kab X8 7
3 R4 8 kab

Комбинации всех кортежей отношения R6 соответствуют вторая и третья строки
отношения R5. Но после исключения атрибутов (столбцов) А2 и А3 эти строки становятся идентичными.
Поэтому в новом отношении присутствует эта строка один раз. Новое отношение:

R
A1 A4
3 kab

Термины и типы

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

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

[править] Процедура нормализации

  1. Функциональные зависимости
  2. Нормализация отношений Нормализация — формальная процедура разбиения некоторой реляционной таблицы на две или более с целью получения такого проекта БД, в котором исключено избыточное дублирование информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных, возникающих в результате аномалий обновления, удаления и вставки, и создания структуры, в которой предусмотрена возможность ее будущих изменений и влияние этих изменений на приложения, использующие информацию этой БД, минимально.
  3. Многозначная зависимость В отношении R атpибут Y многозначно зависит от X, если каждому значению X соответствует несколько значений Y.

Что такое реляционная алгебра

Реляционная алгебра — это язык операций, выполняемых над отношениями — таблицами
реляционной базы данных. Операции реляционной алгебры позволяют на основе одного или
нескольких отношений создавать другое отношение без изменения самих исходных отношений.
Полученное другое отношение обычно не записывается в базу данных, а существует в результате
выполнения SQL-запроса — массиве, создаваемом функциями для работы с базами данных в
языках программирования. Для каждой операции реляционной алгебры будет дана её реализация
в виде запросов на языке SQL.

Рассмотрим операции реляционной алгебры. Чтобы Вам не отвлекаться на
содержание таблиц не Ваших баз данных, таких как «Продукты», «Водители», «сливы», «груши», «чай», «кофе», Владимиры, Сергеи и
т.п. будем выполнять операции над отношениями (таблицами) с абстрактными данными, такими как
R1, R2 (названия таблиц — отношений) и т.д. и А1, А2, А3 (названия атрибутов — столбцов) и
h15, w11 и т.п. (содержание записей таблиц базы данных).

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

Приоритеты выполнения операций реляционной алгебры (в порядке убывания
пунктов списка, а в одном пункте — операции с равными приоритетами):

  • селекция, проекция
  • декартово произведение, соединение, пересечение, деление
  • объединение, разность.

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

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

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

Решение.

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

.

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 3. Удаление повторений из строк

Теперь мы займёмся устранением других проблем, а именно, избавимся от дубликатов в строках таблицы “users”. Поскольку пользователи @AndyRyder5 и @Brett_Englebert разместили по несколько твиттов, то их имена в таблице “users” (Таблица 3) дублируются в колонке full_name. Данная проблема также решается разделением таблицы “users”.

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

Таблица 4. tweets

username text created_at
_DreamLead What do you think about #emailing #campaigns #traffic in #USA? Is it a good market nowadays? do you have #databases? Tue, 12 Feb 2013 08:43:09 +0000
GunnarSvalander Bill Gates Talks Databases, Free Software on Reddit http://t.co/ShX4hZlA #billgates #databases Tue, 12 Feb 2013 07:31:06 +0000
GEsoftware RT @KirkDBorne: Readings in #Databases: excellent reading list, many categories: http://t.co/S6RBUNxq via @rxin Fascinating. Tue, 12 Feb 2013 07:30:24 +0000
adrianburch RT @tisakovich: @NimbusData at the @Barclays Big Data conference in San Francisco today, talking #virtualization, #databases, and #flash memory. Tue, 12 Feb 2013 06:58:22 +0000
AndyRyder5 http://t.co/D3KOJIvF article about Madden 2013 using AI to prodict the super bowl #databases #bus311 Tue, 12 Feb 2013 05:29:41 +0000
AndyRyder5 http://t.co/rBhBXjma an article about privacy settings and facebook #databases #bus311 Tue, 12 Feb 2013 05:24:17 +0000
Brett_Englebert #BUS311 University of Minnesota’s NCFPD is creating #databases to prevent “food fraud.” http://t.co/0LsAbKqJ Tue, 12 Feb 2013 01:49:19 +0000
Brett_Englebert #BUS311 companies might be protecting their production #databases, but what about their backup files? http://t.co/okJjV3Bm Tue, 12 Feb 2013 01:31:52 +0000
NimbusData @NimbusData CEO @tisakovich @BarclaysOnline Big Data conference in San Francisco today, talking #virtualization, #databases,& #flash memory Mon, 11 Feb 2013 23:15:05 +0000
SSWUGorg Don’t forget to sign up for our FREE expo this Friday: #Databases, #BI, and #Sharepoint: What You Need to Know! http://t.co/Ijrqrz29 Mon, 11 Feb 2013 22:15:37 +0000

Таблица 5. users

full_name username
Boris Hadjur _DreamLead
Gunnar Svalander GunnarSvalander
GE Software GEsoftware
Adrian Burch adrianburch
Andy Ryder AndyRyder5
Brett Englebert Brett_Englebert
Nimbus Data Systems NimbusData
SSWUG.ORG SSWUGorg

После разделения в таблице users (Таблица 5) у нас присутствуют уникальные (не повторяющиеся) строки.

Данный процесс удаления дубликатов из строк называется приведением ко второй нормальной форме.

Основные характеристики полей реляционных БД

Названия полей должны быть уникальными в рамках одной сущности. Типы атрибутов или полей реляционных баз данных описывают, данные какой категории хранятся в полях сущностей. Поле реляционной базы данных должно иметь фиксированный размер, исчисляемый в символах. Параметры и формат значений атрибутов определяют манеру исправления в них данных. Еще есть такое понятие, как «маска», или «шаблон ввода». Оно предназначено для определения конфигурации ввода данных в значение атрибута. Непременно при записи неправильного типа данных в поле должно выдаваться извещение об ошибке. Также на элементы полей накладываются некоторые ограничения – условия проверки точности и безошибочности ввода данных. Существует некоторое обязательное значение атрибута, которое однозначно должно быть заполнено данными. Некоторые строки атрибутов могут быть заполнены NULL-значениями. Разрешается ввод пустых данных в атрибуты полей. Как и извещение об ошибке, есть значения, которые заполняются системой автоматически – это данные по умолчанию. Для ускорения поиска любых данных предназначено индексированное поле.

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

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

Переименование

Результатом применения операции переименования атрибутов является отношение с изменёнными именами атрибутов.

Синтаксис:

R RENAME Atr1, Atr2, … AS NewAtr1, NewAtr2,

где

R — отношение
Atr1, Atr2, … — исходные имена атрибутов
NewAtr1, NewAtr2, … — новые имена атрибутов.

Объединение

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

A UNION B

Пересечение

Отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B.
Синтаксис:

A INTERSECT B

Вычитание

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

A MINUS B

Декартово произведение

Отношение, заголовок (A1, A2, …, An, B1, B2, …, Bm) которого является сцеплением заголовков отношений A(A1, A2, …, An) и B(B1, B2, …, Bm), а тело состоит из кортежей, являющихся всеми вариантами сцеплений кортежей отношений A и B: (a1, a2, …, an, b1, b2, …,bm),

таких, что

(a1, a2, …, an) ∈ A,
(b1, b2, …, bm) ∈ B.

Синтаксис:

A TIMES B

Выборка (ограничение)

Отношение с тем же заголовком, что и у отношения A, и телом, состоящим из кортежей, значения атрибутов которых при подстановке в условие c дают значение ИСТИНА. c представляет собой логическое выражение, в которое могут входить атрибуты отношения A и/или скалярные выражения.
Синтаксис:

A WHERE c

Проекция

Основная статья: Проекция (реляционная алгебра)

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

A

или

PROJECT A {x, y, …, z}

Соединение

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

Синтаксис:

(A TIMES B) WHERE P

Деление

Отношение с заголовком (X1, X2, …, Xn) и телом, содержащим множество кортежей (x1, x2, …, xn), таких, что для всех кортежей (y1, y2, …, ym) ∈ B в отношении A(X1, X2, …, Xn, Y1, Y2, …, Ym) найдется кортеж (x1, x2, …, xn, y1, y2, …, ym).

Синтаксис:

A DIVIDEBY B
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector