Для чего нужна база данных для сайта
База данных сайта: что это такое?
Приветствую вас, читатели cccp-blog.com! 🙂
Сегодня мы на мгновение вернёмся к основам создания сайта и поговорим о таком важном компоненте как база данных сайта. Я намеренно не касался данного вопроса в предыдущих публикациях, т.к. он требует особого отношения и не может быть рассмотрен вскользь.
Без базы данных сайта, при переходе на ресурс Вы бы увидели множество картиночек (и то только те, которые прописаны в html и css), кучу рекламы и, наверное, всё… Даже надписей на кнопках не найдёте, поэтому и не поймёте, что на них нужно нажимать. Согласитесь, Вы приходите на сайт не за этим 🙂
То, что нужно пользователям от Интернет-ресурсов, — это информация. Вот она-то как раз и хранится в базе данных сайта. Вот поэтому-то и важно изучать данный вопрос…
Необходимость изучения базы данных сайта
С первого взгляда, может показаться, что вникать в тонкости устройства базы данных сайта есть смысл только разработчикам, решившим делать свой проект «с нуля».
Такая точка зрения вполне оправданна ввиду того, что пользователям, выбравшим из всех способов создания сайтов CMS и онлайн-конструкторы, нет смысла разбираться со структурой их БД ввиду её стандартности и готовности продуктов. Да и просто незачем туда соваться, если всё и так прекрасно работает, верно? 🙂
На самом же деле данные знания ни для кого не будут лишними. Нередко случаются ситуации, когда уже в готовой БД не представлены какие-либо сущности. Или владельцу ресурса необходимо поменять какой-либо тип или длину поля таблицы. Наконец, нужно по какой-то причине добавить, изменить или удалить запись напрямую в базе.
Вот тогда данное руководство Вам и пригодится. Поэтому мы продолжаем 🙂
База данных сайта — что это?
Для начала, как всегда, немного терминологии. Как я уже и говорил, понятие базы данных сайта относится к основам веб-строительства. Но, поскольку я не говорил о ней в одноимённой статье, посвятим ей пару строк здесь.
База данных (сокращённо БД) — это хранилище всей информации, расположенной на сайте. И совершенно неважно, к какому типу сайта принадлежит ресурс. Если он имеет больше одной страницы, БД у него гарантировано есть.
Ещё одной вещью, которую нужно запомнить, является то, что БД состоит из таблиц, у которых есть набор полей. В них-то вся информация и расположена в виде кортежей (записей). Например, «Красная Феррари» будет кортежем в таблице «Модели», у которой есть поля «Производитель» и «Цвет». Таблица, в свою очередь, будет частью БД «Машины».
К основным понятиям, связанным с базой данных сайта, относятся «сущность», «атрибут сущности» и «отношения». Пару слов о каждом из них, чтобы не возникало вопросов по ходу повествования.
Сущность — это объект предметной области.
Если Вы проектируете базу данных сайта книг, то сущностями у вас будут «книга», «автор», «издательство» и т.д. В структуре БД сущности представлены таблицами.
Атрибут сущности — это свойство объекта.
В нашем примере атрибутами книги будут являться «ФИО автора», «количество экземпляров», «год выхода», «переплёт». В структуре БД они представлены полями таблиц.
Отношения — это логические связи между таблицами.
Например, у книги есть автор. Данное отношение будет выражено одинаковыми полями в обоих таблицах.
Структура таблиц будет зависеть от типа отношений, которые бывают:
«один-к-одному» — одной записи из первой таблицы соответствует один объект другой таблицы.
Пример: издательство печатает произведения одного-единственного автора. Довольно часто такие таблицы объединяются;
«один-ко-многим» — записи из первой таблицы соответствует несколько записей из второй таблицы.
Пример: у автора может быть много книг, у книги может быть много авторов. как и в предыдущем случае, каждому участнику отношений соответствует отдельная таблица;
«многие-ко-многим» — множеству записей из первой таблицы может соответствовать множество записей из второй таблицы.
Пример: одну книгу может печатать много издательств в то же время, как одно издательство может печатать множество книг. При данном типе связи целесообразно создать промежуточную таблицу вроде «издательства-книги».
Для наглядности своих слов привожу изображение всех структурных элементов базы данных Интернет-магазина в программе phpMyAdmin, о которой я уже упоминал в статье «Программы для создания сайтов«:
По поводу таблиц хотелось бы отметить, что в каждой из них в обязательном порядке есть ключевое поле. Это поле или группа полей, которые служат идентификатором записи таблицы. Т.е. в каждой таблице базы данных сайта не может быть 2 или более записей с одинаковыми значениями ключевых полей.
По поводу полей таблиц следует отметить, что у каждого поля есть:
А вот по поводу отношений мы поговорим более подробно, т.к. это интересная тема не только в области психологии, но и в базах данных сайта она простотой не отличается 🙂
База данных сайта — нормализация отношений
Следующем темой, которую бы я хотел затронуть, является нормализация отношений. Речь тут пойдёт не о гармоничном развитии отношений с вашим партнёром, о чём привыкло думать большинство людей при встрече этого словосочетания 🙂 Мой блог посвящён немного другому…
Поговорим мы о нормализации отношений базы данных сайта, которая подразумевает приведение их к одной из 6 нормальных форм. Это делается для борьбы с избыточностью данных. Она заключается в содержании в БД повторяющейся информации.
Как раз для борьбы с этим и были введены нормальные формы, назначением которых как раз и является оптимизация структуры базы данных сайта таким образом, чтобы в ней не было избыточных данных.
Рассмотрим, какие же нормальные формы бывают:
1. Первая нормальная форма
Отношение находится в 1НФ, если все его атрибуты являются простыми и в таблицах нет повторяющихся кортежей. Взяв для примера приведённую ранее таблицу «Машины», отметим, что сейчас она является приведённой к 1НФ.
Если бы в ней были записи типа «Ferrari => Красный, Жёлтый, Малиновый» — это было бы нарушением ввиду того, что атрибуты не являются простыми. В таком случае её нормализация заключалась бы в разбиении этой записи на 3: «Ferrari => Красный», «Ferrari => Жёлтый», «Ferrari => Малиновый».
2. Вторая нормальная форма
Отношение находится во 2НФ, если оно находится в 1НФ и все его НЕ ключевые атрибуты неприводимо зависят от первичного ключа. И в составе первичного ключа не должно быть меньшего подмножества атрибутов. Проще говоря, не должно быть посторонних, чужих по смыслу полей.
Если бы в нашей таблице помимо полей «Фирма» и «Цвет» было бы поле «Скидка», она не была бы нормализованной, т.к. скидка зависит от цвета, но не зависит от фирмы машины. Нормализация заключалась бы в разбиении её на 2 таблицы: «Фирма» и «id цвета» были бы в одной. А «id цвета», «Цвет» и «Скидка» были бы в другой.
3. Третья нормальная форма
По смыслу она очень похожа на 2НФ. Обе они предусматривают зависимость НЕ ключевых атрибутов от первичного ключа. Отношение находится в 3НФ, если оно находится во 2НФ и его НЕ ключевые атрибуты зависят от ПФ.
Единственное отличие в том, что во 2НФ зависимость неприводимая, а в 3НФ она нетранзитивная. Страшное слово «нетранзитивная» на самом деле подразумевает вынесение всех НЕ ключевых полей, которые могут относиться к нескольким записям таблицы, в отдельную таблицу.
Если бы в нашей таблице помимо полей «Фирма» и «Цвет» было бы поле «Возраст фирмы», она не была бы нормализованной, т.к. возраст фирмы не зависит от модели машины. Нормализация заключалась бы в разбиении её на 2 таблицы: «Цвет» и «id фирмы» были бы в одной, а в другой были бы «id фирмы», «Название фирмы», «Возраст фирмы».
Частным случаем 3НФ является нормальная форма Бойса-Клодда, которая дополнительно учитывает наличие в таблице нескольких потенциальных ключевых полей, которые являются составными и пересекаются (имеют хотя бы один атрибут).
Я, честно говоря, с трудом ощущаю разницу между 2НФ и 3НФ, даже не знаю, зачем ввели две формы, если на практике они означают одно и тоже: в таблице не должно быть посторонних полей. При проектировке советую вам запомнить и применять этот тезис 🙂
Остальные формы я не буду рассматривать ввиду сложности их определения и достаточно тонких отличиях друг от друга. Да в этом и нет необходимости, т.к. на практике не всегда нужно доходить до 6НФ. В большинстве случаев достаточно приведение к 3НФ, чтобы в отношениях базы данных сайта отсутствовала избыточность и они считались нормализованными.
4НФ, 5НФ, 6НФ и их частные формы представляют скорее академический интерес, т.е. они могут быть интересны только узкому кругу учёных, которые защищают диссертации и проводят свои исследования, пытаясь открыть что-либо новое.
При реальном проектировании баз данных сайта эти заморочки могут только лишний раз запутать и отбить охоту, поэтому я в них и не углублялся 🙂 Если Вам будет интересно, Вы всегда можете прочитать об остальных нормальных формах на специализированных ресурсах. Мы же двигаемся дальше.
База данных сайта — денормализация отношений
Последним понятием, связанным с базами данных сайта, с которым я бы хотел вас познакомить, является денормализация отношений. Она является обратным явлением нормализации отношений. И заключается в преднамеренном приведении структуры БД в состояние, не соответствующее ни одной из нормальных форм.
Денормализацию есть смысл проводить, если в вашей БД:
1. Много соединений таблиц в запросах
Если Ваша база данных сайта нормализована, в ней будет масса таблиц, в большинстве которых будет всего 2 поля: ключевое и поле со значением, подтягивающимся по ключевому полю. Да, избыточности данных в таком случае не наблюдается, но и производительности тоже, т.к. операции объединения очень трудоёмкие 🙂
Поэтому в данной ситуации есть смысл объединить несколько таблиц в одну для ускорения запросов по выборке данных.
Если у Вас на сайте происходит много расчётов значений, которые хранятся в базе данных сайта, есть смысл подумать о денормализации. Особенно эта ситуация характерна для Интернет-магазинов, где постоянно рассчитывается стоимость заказов, цены товаров с учётом скидок и т.д.
В данном случае денормализация будет заключаться в хранении наиболее используемых рассчитываемых значений в базе данных сайта, чтобы при необходимости не производить выборку данных и их пересчёт, а взять уже готовое значение.
Если в вашей базе данных сайта есть длинные поля (фотографии, хранимые в blob-полях; огромные текстовые описания товаров), то запросы, подсчитывающие количество записей в таких таблицах будут выполняться оооочень медленно 🙂
Поэтому в данном случае есть смысл провести денормализацию путём создания отдельных таблиц, содержащих всего 2 поля: id записи и поле, содержащее «тяжёлое» значение. В основном таблице, в которой до этого это тяжёлое поле хранилось, вместо него будет идентификатор, и подсчёт количества записей будет производиться гораздо быстрее.
Подытожив всё вышесказанное, хочу сказать, что денормализация баз данных сайта проводится с целью повышения производительности веб-проекта, которая заключается в ускорении загрузки страниц и потребляемости ресурсов сервера, на котором он расположен.
На этом я заканчиваю своё повествование, в котором нами была рассмотрена база данных сайта — её основные понятия и определения, а также меры по оптимизации её структуры. В дальнейших публикациях я более подробно коснусь БД отдельных типов ресурсов (первый на очереди Интернет-магазин), в которых более подробно будут рассмотрены их сущности и атрибуты, а, следовательно, структура их таблиц и отношений между ними.
С нетерпением жду ваших отзывов и вопросов. Делитесь записью со своими друзьями в социальных сетях, привлекайте их к обсуждению. Чем больше людей — тем больше интересных мыслей!
И в завершение предлагаю вашему вниманию интересное экскурсное видео о том, что такое БД и зачем она нужна. Приятного просмотра 🙂
P.S.: если вам нужен сайт либо необходимо внести правки на существующий, но для этого нет времени и желания, могу предложить свои услуги.
Более 5 лет опыта профессиональной разработки сайтов. Работа с PHP, OpenCart, WordPress, Laravel, Yii, MySQL, PostgreSQL, JavaScript, React, Angular и другими технологиями web-разработки.
Опыт разработки проектов различного уровня: лендинги, корпоративные сайты, Интернет-магазины, CRM, порталы. В том числе поддержка и разработка HighLoad проектов. Присылайте ваши заявки на email cccpblogcom@gmail.com.
И с друзьями не забудьте поделиться 😉
Что такое база данных веб-сайта и зачем это нужно.
Любой человек, который занимается веб-разработкой рано или поздно сталкивается с таким понятием как база данных веб-сайта.
Давайте будем разбираться, что такое база данных и зачем это нужно.
Предположим, что мы решили создать какой-то свой веб-сайт. Мы создали одну страницу. Предположим, что это будет страница page.html. На этой странице находится какое-то содержимое.
С течением времени сайт начинает разрастаться. На нем начинают появляться все новые и новые материалы и страниц, на которых будут храниться эти материалы становиться все больше и больше.
Возникает вопрос, как хранить все данные, которые будут отображаться на этих веб-страницах. Какую структуру организации этих данных выбрать.
Как вариант, это будет работать. Но, при этом возникает ряд проблем.
Что если в этой структуре файлов, нам нужно будет добавить или изменить какой-то общий элемент? Например, нужно поменять изображение в шапке сайта.
Нужно будет открывать каждый из этих файлов и в каждом из них менять путь до картинки.
А что если у нас будет стоять задача получить какую-то статистику по этим страницам? Например, нам нужно узнать сколько всего у нас есть веб-страниц и вывести это в каком-то месте веб-сайта.
Если каждая страница у нас отдельный файл, сделать это может быть трудно.
Что если нам нужно будет организовать поиск по этим файлам?
С этим тоже могут быть трудности.
Наконец, как дать доступ на редактирование созданных html-страниц человеку, который в веб-разработке ничего не понимает. Для него это тоже будут некоторые трудности.
Из-за этих проблем, что трудно обслуживать такую структуру организации данных веб-сайта, есть другой подход как можно хранить информацию, которая будет отображаться на всех этих страницах.
В этом подходе мы исходим из того, что у нас есть только один файл. Предположим, это файл page.php.
Именно этот файл будет главным для всех страниц нашего сайта. А текст всех страниц, которые будут на этом сайте. Ссылки, даты и.т.д. мы выносим в отдельную сущность, которая называется база данных.
Т.е. мы разделяем структуру веб-страницы. Разметка документа отдельно и содержимое страницы тоже отдельно.
Каждая строка соответствует каждой странице.
При такой структуре мы можем настроить веб-сервер, чтобы при обращении по определенному url-адресу ему показывается каждый раз какая-то уникальная страница из базы данных.
Главное преимущество такой структуры в том, что нам теперь не нужно хранить на сервере огромное количество файлов.
Теперь у нас контент отдельно и разметка страницы тоже отдельно.
Какие мы теперь получаем преимущества:
1) Мы можем просто вносить изменения в содержимое страниц сайта за счет того, что контент размещается отдельно от структуры и логики.
2) Скорость и простота обработки информации в базе данных. Статистика, поиск и.т.д.
3) Возможность создания панели управления для людей, которые не знакомы с веб-разработкой.
Надеюсь, что стало понятнее что такое база данных и для чего они нужны.
Не во всех случаях оправдано их использование. Если вам приходится работать с большим объемом каких-то данных, тот первый вопрос, который вам нужно себе задать: не логичнее ли будет всю эту информацию хранить в базе данных.
На этом все, желаю вам удачно проектировать структуру своего веб-сайта и удачной работы.
База данных сайта
7 ноября 2017 Опубликовано в разделах: Азбука терминов. 32096
База данных по автомобилям состоит из множества таблиц. Это модели: ВАЗ, ГАЗ, FORD, VW, Ferrari и т.д. Каждая таблица имеет поля.
ВАЗ: 2101, 2104, 2105, 2107 и т.д.
В каждом поле внесены записи со значениям-характеристиками: цветовые гаммы, ЛС, мощность движка и т.д.
Таблицы связаны специальными отношениями, поэтому с записями можно работать: объединять, сортировать, делать выборку посредством указания одного запроса. Современные веб-ресурсы используют базы данных для своего функционирования.
Базы данных и организация веб-ресурса
Каждый сайт состоит из HTML-страниц. На них есть определенный каркас — то, что одинаково на любой странице. И есть контент — на каждой странице он разный.
Раньше интернет-сайты создавали на чистом HTML, и это было неудобно, так как все данные были представлены как отдельные HTML-файлы. Нельзя было осуществлять поиск, группировку, сортировку информации. К тому же, информация могла часто дублироваться. При появлении PHP у веб-мастеров появилась возможность разделения сайта на его каркас и данные в базе. Теперь структуру сайта можно хранить отдельно от контента, что позволяет быстрее и удобнее администрировать веб-ресурс, легко дорабатывать его дизайн и функционал.
Преимущества использования базы банных
Как работать с БД
Если вы в совершенстве владеете html и css, то все равно обращаетесь к Dreamweaver, чтобы снизить сложность работы с версткой сайта. Для работы с БД необходима также программа обработки SQL под названием MySQL. Она установлена на хостинге в оболочке phpMyAdmin.
По умолчанию сама БД сайта находится в каталоге data на веб-сервере интернет-проекта. К примеру, если БД имеет название bd, то все ее значения находятся в data/bd. Как правило, на хостинге доступ к файлам БД закрыт, их следует “вытягивать” посредством запросов SQL через консоль. Упрощает работу с запросами именно MySQL. Для того чтобы попасть в MySQL, необходимо зайти по ссылке, которую дает хостинг-провайдер, и ввести логин-пароль от базы.
Подключение базы к сайту происходит в конфигурационном файле при помощи указания названия, пользователя и пароля. Название файла и его и месторасположение зависит от вида вашей CMS. Для MODx это config.inc по пути /core/config/.
Необходимо периодически создавать бэкапы — резервные копии сайта и базы данных. Обычно хостинги предоставляют услуги по созданию копий сайта.
Восстановить предыдущую версию можно с той даты, за которую сохранены база и конфигурация сайта. Легче периодически делать копии, чем восстанавливать портал с нуля.
База данных. Реляционная база данных
Что такое базы данных (БД) и зачем они нужны
База данных (БД) — это программа, которая позволяет хранить и обрабатывать информацию в структурированном виде.
БД это отдельная независимая программа, которая не входит в состав языка программирования. В базе данных можно сохранять любую информацию, чтобы позже получать к ней доступ.
Пример использования
Базы данных нужны для хранения информации. Чтобы получить полное понимание необходимости использования БД в современном веб-программировании, необходимо ответить на три вопроса:
Предположим, вы решили сделать сайт, где каждый пользователь может вести личный дневник наблюдения за погодой в своем городе.
Такой сайт должен иметь как минимум одну форму ввода со следующими полями: город, дата, температура, облачность, погодное явление, и так далее.
Каждый день наблюдатель записывает показания погоды в эту форму, чтобы когда-нибудь в будущем вернуться на сайт и посмотреть, какая была погода месяц или даже год назад.
Из этого примера следует, что программист каким-то образом должен сохранять данные из формы для дальнейшего использования.
Кроме обычного просмотра дневника погоды за месяц в виде таблицы, можно сделать и более сложный проект.
Например, чтобы электронный дневник чем-то качественно отличался от своего бумажного аналога, будет неплохо добавить туда возможности для простого анализа: показать какой день был самым холодным в ноябре или какой продолжительности была самая длинная серия пасмурных дней.
Получается, что данные надо не просто как-то хранить, но и иметь возможность их обрабатывать и анализировать.
Именно для этих целей и существуют базы данных.
Как хранится информация в БД
В основе всей структуры хранения лежат три понятия:
База данных
База данных — это высокоуровневное понятие, которое означает объединение совокупности данных, хранимых для выполнения одной цели.
Если мы делаем современный сайт, то все его данные будут храниться внутри одной базы данных. Для сайта онлайн-дневника наблюдений за погодой тоже понадобится создать отдельную базу данных.
Таблица
По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.
Запись
Запись — это строка электронной таблицы.
Это неделимая сущность, которая хранится в таблице. Когда мы сохраняем данные веб-формы с сайта, то на самом деле добавляем новую запись в какую-то из таблиц базы данных. Запись состоит из полей (столбцов) и их значений. Но значения не могут быть какими угодно.
Определяя столбец, программист должен указать тип данных, который будет храниться в этом столбце: текстовый, числовой, логический, файловый и т.д. Это нужно для того, чтобы в будущем в базу не были записаны данные неверного типа.
Соберем всё вместе, чтобы понять, как будет выглядеть ведение дневника погоды при участии базы данных.
Теперь можно быть уверенными, что наблюдения наших пользователей не пропадут, и к ним всегда можно будет получить доступ.
Реляционная база данных
Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:
Так мы решим сразу две задачи:
Связи между таблицами в БД бывают разных видов.
В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот!
Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.