Что такое БД
Делая первые шаги, я то и дело сталкивалась с аббревиатурой БД. Загадка загадок. Она почему-то нужна была всем... Что такое БД? Зачем оно? Однажды добрый человек расшифровал аббревиатуру. Она означала - «База данных». Понятно, «база» - место хранения каких-то однотипных предметов. Например, на автобазе хранились автомобили. «Данные» - информация. Данные могут быть разными — от простых чисел до изображений.
Базу можно уподобить картонной коробке с бумагами. В бумагах написано все, что нужно. Пока информация в коробке — она не база. Чтобы иметь гордое название База данных, все, что написано, должно иметь электронный вид.
Для сайта базой данных будет информация, с которой придется работать. Например, базой данных управленца по кадрам - список сотрудников компании. Зоопарка — список животных, возможно с фото и описаниями. Журнала — ряд статей определенной тематики. Магазина — каталог товаров. И тому подобное. В общем и целом — любые сайты будут иметь в базе данных тексты и изображения.
То, как Вы разложите материалы по полочкам, и будет вашей базой данных. Программисты говорят об этом «структура БД». Можно просто выложить все подряд. Получится блог. То есть Дневник. Можно разбить материалы по каким-либо признакам. Может получиться что-то вроде книги. Разложить по полочкам — значит структурировать или организовать —разбить по темам, разделам, направлениям, выполняемым задачам. Потому нужно разобраться немного с терминами «модель данных» и «модель базы данных» или «схема БД». Понятие «модель данных» определяет общую идею отображения данных в какой-то заданной ситуации. И относится к теории баз данных. Названная модель определяет теоретическое обоснование базы.
Википедия предлагает различные виды классификации баз данных. Для полноты картины отмечу: по модели данных базы делятся на:
Иерархическая
Объектная и объектно-ориентированная
Объектно-реляционная
Реляционная
Сетевая
Функциональная.
Практически, при использовании реляционной СУБД, используется реляционная БД, точнее - реляционная модель со всеми ее условиями. Далее я буду описывать действия именно с реляционной базой данных. И, говоря о базе данных или о СУБД, мною будет подразумеваться реляционная база данных.
Прежде, чем создать свою базу, понадобится определиться с так называемыми сущностями, их атрибутами и связями между сущностями.
Сущность в БД
В книге Райордан Р. Основы реляционных баз данных/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2001, сущность определяется следующим образом:
...сущность — это нечто такое, о чем нужно хранить информацию в разрабатываемой системе...
...Большинство сущностей моделируют объекты или события реального мира, примерами могут служить клиенты, товары, или звонки в службу продаж. Это конкретные сущности.
...Сущности также могут моделировать и абстрактные понятия. Здесь наиболее яркий пример — сущность, моделирующая отношения между сущностями: скажем, тот факт, что некий торговый агент отвечает за определенного клиента, или что некий студент записан на определенный курс лекций...
...Иногда необходимо моделировать только сам факт наличия отношения, иногда — хранить дополнительную информацию об этом отношении (дата возникновения данного отношения, а также его дополнительные характеристики).
Применительно к рассматриваемому мной примеру, сущностями будут:
Статьи,
Разделы,
Главы.
Причем, при дальнейшем рассмотрении состав сущностей может измениться. Например, нужно подумать — понадобятся или нет комментарии посетителей. Хотя в Интернете они обычно важны. Учитывая сказанное, добавим сущность Комментарии. Комментарии, в свою очередь, потребуют регистрации пользователя. Нам же не нужен бесконтрольный спам? Значит, добавится сущность Посетители или Пользователи.
Разбиение текста на разделы можно выполнить в пределах одной таблицы или разных таблиц. В пределах одной таблицы мы получим довольно сложный процесс выбора за счет того, что применяться к одной статье будут как минимум 2 переменные.
Список сущностей:
Разделы
Пользователи
Статьи
Главы
Комментарии
Можно было бы сказать — это и есть таблицы. Не все так просто. Это пока набросок, эскиз.
Атрибуты сущностей
Из той же книги:
В разрабатываемой системе будут храниться записи об определенных параметрах каждой из сущностей. Эти параметры называются атрибутами сущностей. Например, если в вашей системе присутствует такая сущность, как Customer (Покупатель), вам, скорее всего, потребуется хранить имена и фамилии, и возможно, род деятельности клиентов.
При моделировании такого события, как звонок в службу технической поддержки потребуется знать, кто звонил, время звонка, и удалось ли успешно разрешить проблему, с которой обратился клиент.
Определение атрибутов, которые нужно включить в разрабатываемую модель — это семантический процесс. Решая эту задачу, нужно основываться на том, что реально означают хранимые данные и как они будут использоваться
В нашем случае атрибутами статьи могут быть и будут непременно:
заголовок,
содержание
дата публикации.
Это очевидно и не требует дополнительных объяснений. Вовсе не обязательно, что будут иметь значение такие атрибуты как автор, раздел или глава. Так как я рассматриваю случай достаточно объемного содержания, поэтому включим и эти атрибуты в список.
Общий список атрибутов сущности Статьи:
заголовок
содержание
дата публикации
автор
глава
раздел
Рассматривая сущность Пользователи определяем атрибуты, например
Логин
Пароль
Главы определяются именем главы и не более. Хотя могут быть и другие варианты. Можно добавить к ним номер сортировки, например. Или еще какие-то нужные Вам пункты.
Комментарии:
Текст
Автор
Комментируемая статья
И Разделы. Они будут иметь те же атрибуты, что и главы.
Атрибуты сущностей будут соответствовать именам столбцов наших таблиц.
Связи между сущностями
В книге Райордан Р. Основы реляционных баз данных/Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2001, говорится:
Кроме атрибутов каждой сущности модель данных должна определять связи между сущностями. На концептуальном уровне связи представляют собой простые ассоциации между сущностями. Например, утверждение «Покупатели покупают продукты* указывает, что между сущностями Customers (Покупатели) и Products (Продукты) существует связь, и такие сущности называются участниками этой связи. Число участников определяет размерность связи. Определение размерности связи похоже на определение размерности отношения, но они между собой не эквивалентны.
Большинство связей — двойные, в них два участника. Пример такой связи — связь между сущностями Customers (Покупатели) и Products (Продукты). Однако существуют и другие виды связей, например, на существование неявной тройной связи указывает утверждение «Сотрудники фирмы продают товары покупателям». Определение двух двойных связей не позволяет определить, кто именно из сотрудников продал товары покупателям, и какие именно товары каким именно покупателям он продал. Для этого нужно определять тройные связи.
Весьма интересен особый случай — это связь, в которой сущность является участником связи с самой собой. Такую связь часто называют связью типа «спецификация товаров» и используют для представления иерархических структур. Наглядный пример — связь между сотрудником и менеджером: любой сотрудник может одновременно сам являться менеджером и подчиняться другому менеджеру.
Существует несколько типов связей между двумя сущностями: это связи «один к одному», «один ко многим» и «многие ко многим».
Связи «один к одному» встречаются достаточно редко….
Связи «один ко многим» более часты. «В счете перечислено множество товаров», «Торговый агент выписывает много счетов» — вот примеры таких связей...
Связи «многие ко многим», хотя и не столь широко распространены, как «один ко многим», также не редкость. Например, каждый покупатель покупает разные товары, и определенные виды товаров также приобретаются разными покупателями. Преподаватели в университете читают лекции многим студентам, и каждый конкретный студент посещает лекции нескольких преподавателей. Связи «многие ко многим» невозможно непосредственно реализовать в реляционной модели, однако их косвенная реализация вполне проста и однозначна.
Теперь, когда мы знаем о сущностях, атрибутах и связях, определим связи между нашими сущностями. Задача — свести связи к единичным, то есть к типу «один ко многим», в необходимых случаях - «один к одному». Нельзя в реляционной модели выполнить связи «многие ко многим».
Сущность Раздел и сущность Глава будет иметь связь «один ко многим». В свою очередь, сущность Глава имеет связь «один ко многим» с сущностью Статьи. Если посмотреть в обратную сторону, увидим: одна статья отвечает одной главе и одному разделу. Могут быть и другие случаи. Например, одна статья может относиться к нескольким разделам. Это бывает в некоторых документооборотах. Тогда рассмотренная схема не будет работать, а потребуется изобретать другую.
Сущность Статья и Комментарии будет иметь связь «один ко многим». Одна статья может иметь множество комментариев. Но каждый из них будет относится к указанной статье.
Сущность Пользователи и Комментарии будут связаны как «один ко многим». Понятно, один пользователь на одной странице может оставить несколько комментариев, но каждый из комментариев будет относиться только к указанному пользователю.
Итак, задача более или менее решена — все связи сведены к виду «один ко многим». Теперь можно создавать базу.
Напоследок
Помните: база данных хранится в компьютере? Следовательно, нам требуется как-то сохранить материалы на компьютере. К любому документу, хранимому компьютером можно получить доступ только через компьютер. По крайней мере на сегодняшний день. Значит, для отображения электронных материалов нужно как-то получить эти материалы. Чем и как сохранять данные, чем и как отображать?
Для небольших объемов лучше всего подходит файловая система, на мой взгляд. Для хранения больших объемов информации иногда также используют файлы различных форматов. Но чаще СУБД. Пора разобраться с тем, Что такое СУБД.
Родионова Галина2019-02-07