Lesson Category: Базы данных

Последний вид связи – это Один-к-одному.

Этот вид связи самый простой.

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

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

Например, есть наша основная таблица Продукты.

И пусть в ней будет новый аттрибут – Бракованный товар. То есть например, все лампы из тех, что есть на складе оказались бракованными или все стулья, которые есть на складе оказались бракованными. То есть представим, что эти все стулья и лампы это какая-то конкретная их модель и эта модель выпускалась с браком, такое бывает. Тогда у них в этом столбце будет стоять true, то есть бракованные, если всё в порядке то false.

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

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

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

Третий случай – это когда у нас, например, есть таблица с продуктами и у продуктов появляется какой-то новый ВРЕМЕННЫЙ аттрибут. То есть мы точно знаем, что этот столбец мы со временем удалим из таблицы. И создавать новый столбец в основной таблице не всегда бывает удобно, легче создать отдельную таблицу чтобы потом с легкостью ее удалить.

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

Далее рассмотрим тип связи Многие-ко-Многим.

Ясное дело должно быть две таблицы – Продукты и Покупатели продуктов. И как-то нужно их связать.

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

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

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

Например, Ricardo купил стол, лампу и утюг, но стол также купили Billy и Van. То есть повторение идет и покупателей и продуктов.

Почему она многие-ко-многим думаю уже понятно – каждый покупатель может купить МНОГО разных продуктов и каждый продукт может быть куплен МНОГИМИ разными покупателями.

Итак разобьем же таблицу на две

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

Но подождите! Если мы посмотрим на исходную таблицу (ту которая была в самом начале урока), то стол же купил не только Billy, его купил и Van и Ricardo. Утюг также купил Billy и Ricardo.

Давайте попробуем наоборот.

Очевидно та же самая ситуация. Только размноживать теперь придется покупателей.      

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

Продемонстрируем это:

Как видим, в первом столбике ключи из таблицы продукты, во втором же ключи из таблицы покупатели.

Получается мы сопоставляем строку таблицы с продуктами где идентификатор 1 к строке покупателя с идентификатором 1, к строке покупателя с идентификатором 2 и к строке покупателя с идентификатором 3. То есть стол связан с Billy, Van и Ricardo.

То есть мы сопоставляем строку таблицы с покупателями где идентификатор 3 к строке продукта с идентификатором 1, к строке продукта с идентификатором 2 и к строке продукта с идентификатором 3. Ricardo связан со столом, лампой и утюгом.

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

Например, стол и стул относятся к категории мебель, а лампа, утюг и вентилятор к категории электроприборы.

Давайте же добавим в таблицу из прошлого урока аттрибут "Категория продукта".

Как видим, слово Электроприбор повторяется три раза, слово мебель два раза.

А что если у нас в таблице будет больше электроприборов и больше мебели, то значит у нас в таблице будут повторяться эти два слова еще больше раз?

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

То есть мы сейчас подошли к двум новым концепциям – идентификаторам (чаще называют ключами) и связям.

Разбиваем таблицу. Вторая таблица будет иметь имя Категория продукта.

Как видим теперь информация не повторяется.

Для этого используется идентификатор(ключ).

Например, в таблице Продукт можно увидеть аттрибут Идентификатор продукта.

Идентификатор в этой таблице идентифицирует продукт, по нему можно отличить один продукт от другого.

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

Идентификатор чаще всего это простое числовое значение.

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

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

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

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

Например:

Если бы мы не разделяли таблицы, то дублировалось бы уже два аттрибута:

Теперь профит от разделения таблиц должен быть очевиден.

Рассмотренный тип связи называется 'Один-ко-многим'.

Всего типов связей три и мы всех их разберем.

То есть у нас категории мебель (она одна) соответствует два продукта (их много), а категории электроприборы (она одна) соответствует три продукта (их много).

Думаю можно догадаться, что это хранилище, в котором хранятся данные.

Конкретная таблица БД хранит в себе данные какой-либо конкретной сущности.

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

То есть, например, одна строка таблицы хранит данные о лампе, другая о стуле и т.д.

В каждой ячейке строки храниться конкретная какая-либо характеристика конкретного продукта (например стула).

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

Столбцы таблицы принято называть аттрибутами, а строки кортежами.

Сейчас на примере таблицы Продукт будет понятнее.

Видим аттрибуты продуктов таблицы (Идентификатор продукта, Наименование продукта, Цена продукта, Количество на складе).

Также видим пять кортежей (значит пять продуктов).

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