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

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

«Данные» - информация. Данные могут быть разными — от простых чисел до изображений.

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

Для сайта базой данных будет информация, с которой придется работать. Например, базой данных управленца по кадрам - список сотрудников компании. Зоопарка — список животных, возможно, с фото и описаниями. Журнала — ряд статей определенной тематики. Магазина — каталог товаров. И тому подобное. В общем и целом — любые сайты будут иметь в базе данных тексты и изображения. 

То, как Вы разложите материалы по полочкам называется «структура реляционной базы данных». Можно просто выложить все подряд. Получится блог. То есть Дневник. Можно разбить материалы по каким-либо признакам. Получится что-то вроде книги. Разложить по полочкам — значит структурировать или организовать —разбить по темам, разделам, направлениям, выполняемым задачам.

Потому нужно разобраться немного с терминами «модель данных» и «модель базы данных» или «схема БД».

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

Википедия предлагает различные виды классификации баз данных.

Честно говоря, нам эти проблемы ни к чему. Но для полноты картины отмечу: по модели данных базы делятся на:

• Иерархическая
• Объектная и объектно-ориентированная
• Объектно-реляционная
• Реляционная
• Сетевая
• Функциональная.

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

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

Сущности и атрибуты

В книге Райордан Р. Основы реляционных баз данных/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2001, сущность определяется следующим образом:

«...Сущность — это нечто такое, о чем нужно хранить информацию в разрабатываемой системе...

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

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

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

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

Применительно к рассматриваемому примеру, это:

• Статьи

Причем, при дальнейшем рассмотрении состав сущностей может измениться.

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

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

Разбиение текста на разделы можно выполнить в пределах одной таблицы или разных таблиц.

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

Таким образом, получаем список сущностей:

• Разделы
• Пользователи
• Статьи
• Главы
• Комментарии

Можно было бы сказать — это и есть таблицы. Не все так просто. Это пока набросок, эскиз.

Атрибуты сущностей:

Из той же книги:

«В разрабатываемой системе будут храниться записи об определенных параметрах каждой из сущностей. Эти параметры называются атрибутами сущностей. Например, если в вашей системе присутствует такая сущность, как Customer (Покупатель), вам, скорее всего, потребуется хранить имена и фамилии, и возможно, род деятельности клиентов.

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

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

Применительно к рассматриваемому примеру, определим атрибуты сущностей:

Сущность «Статья»

Атрибутами сущности могут быть и будут непременно:

• заголовок,
• содержание

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

Общий список атрибутов сущности «Статья» (рис. 1):

• заголовок
• содержание
• дата публикации
• автор
• глава
• раздел

Несмотря на то, что Раздел и Глава уже объявлены сущностями, в пределах сущности «Статья» они будут выступать и как атрибуты. 

Сущность «Пользователи»

Рассматривая сущность Пользователи, определяем атрибуты, например

• Логин
• Пароль

Сущность «Глава»

Главы определяются именем главы и не более. Хотя могут быть и другие варианты. Можно добавить к ним номер сортировки, например. Или еще какие-то нужные Вам пункты.

Комментарии:

• Текст
• Автор
• Комментируемая статья

Разделы будут иметь те же атрибуты, что и главы.

Атрибуты сущностей соответствуют именам столбцов наших таблиц.

Связи между сущностями

В книге Райордан Р. Основы реляционных баз данных/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2001, говорится:

Кроме атрибутов каждой сущности модель данных должна определять связи между сущностями. На концептуальном уровне связи представляют собой простые ассоциации между сущностями. Например, утверждение «Покупатели покупают продукты* указывает, что между сущностями Customers (Покупатели) и Products (Продукты) существует связь, и такие сущности называются участниками этой связи. Число участников определяет размерность связи. Определение размерности связи похоже на определение размерности отношения, но они между собой не эквивалентны.

Большинство связей — двойные, в них два участника. Пример такой связи — связь между сущностями Customers (Покупатели) и Products (Продукты). Однако существуют и другие виды связей, например, на существование неявной тройной связи указывает утверждение «Сотрудники фирмы продают товары покупателям». Определение двух двойных связей не позволяет определить, кто именно из сотрудников продал товары покупателям, и какие именно товары каким именно покупателям он продал. Для этого нужно определять тройные связи.

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

Существует несколько типов связей между двумя сущностями: это связи «один к одному», «один ко многим» и «многие ко многим».

Связи «один к одному» встречаются достаточно редко….

Связи «один ко многим» более часты. «В счете перечислено множество товаров», «Торговый агент выписывает много счетов» — вот примеры таких связей...

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

Теперь, когда мы знаем о сущностях, атрибутах и связях, определим связи между нашими сущностями. Задача — свести связи к единичным, то есть к типу «один ко многим», в необходимых случаях - «один к одному». Нельзя в реляционной модели выполнить связи «многие ко многим».

Сущность «Раздел» и сущность «Глава» будет иметь связь «один ко многим». Это значит — один раздел имеет множество глав(рис. 2). 

В свою очередь, сущность «Глава» имеет связь «один ко многим» с сущностью «Статья», одна глава имеет много статей (рис.3).

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

Сущность «Статья» и «Комментарии» будет иметь связь «один ко многим». Одна статья может иметь множество комментариев. Но каждый из них будет относится к указанной статье(рис. 2).

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

Задача более или менее решена — все связи сведены к виду «один ко многим».

Теперь можно создавать базу.

Итоги

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

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