Руководство по разработке структуры и проектированию базы данных

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

• База данных;
• Таблица;
• Запись.

База данных

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

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

Запись — это строка электронной таблицы.
Это неделимая сущность, которая хранится в таблице. Когда мы сохраняем данные веб-формы с сайта, то на самом деле добавляем новую запись в какую-то из таблиц базы данных. Запись состоит из полей (столбцов) и их значений. Но значения не могут быть какими угодно.
Определяя столбец, программист должен указать тип данных, который будет храниться в этом столбце: текстовый, числовой, логический, файловый и т.д. Это нужно для того, чтобы в будущем в базу не были записаны данные неверного типа.

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

1. Создадим для сайта новую БД и дадим ей название «weather_diary».
2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
   • Город (тип: текст);
   • День (тип: дата);
   • Температура (тип: число);
   • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
   • Были ли осадки (тип: истина или ложь);
   • Комментарий (тип: текст).
3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

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

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

1. Создать новую таблицу с именем „cities“.
2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

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

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

Требования к проектированию БД

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

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

Возможны и другие требования, причём нередко они противоречат друг другу

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

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

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

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

Где их используют

Базы данных сейчас используются почти везде:

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

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

Системы Управления Базами Данных

Теперь, когда у нас есть реляционная БД, каким образом мы можем её имплементировать? Для этого мы можем воспользоваться системами управления базами данных (СУБД). Существует целый набор подобных программ, как платных, так и бесплатных. Среди платных можно выделить Oracle Database, IBM DB2 и Microsoft SQL Server. Бесплатные: MySQL, SQLite и PostgreSQL.

Чаще всего различные компании используют MySQL. Twitter в этом смысле — не исключение.

SQLite чаще используется при разработке приложений для iOS и Android, где хранится различного рода конфиденциальная информация. Браузер Google Chrome использует SQLite для хранения истории просмотров, кукисов, изображений…

PostgreSQL используется реже. Для неё существует полезное расширение PostGIS, которое делает данную СУБД удобной для хранения геолокационных данных. К примеру сервис OpenStreetMap исользует PostgreSQL.

Создание правила брандмауэра для IP-адресов на уровне сервера

Служба «База данных SQL Azure» создает брандмауэр IP-адресов на уровне сервера. Он не позволяет внешним приложениям и средствам подключаться к серверу и к любой базе данных на сервере, если не создано правило брандмауэра, позволяющее пропускать их IP-адреса через брандмауэр. Чтобы разрешить внешние подключения к базе данных, необходимо сначала добавить правило брандмауэра IP-адресов, указав в нем свой IP-адрес (или диапазон IP-адресов). Выполните следующие действия, чтобы создать правило брандмауэра IP-адресов на уровне сервера.

Важно!

База данных SQL обменивается данными через порт 1433. Если вы пытаетесь подключиться к этой службе из корпоративной сети, исходящий трафик через порт 1433 может быть запрещен сетевым брандмауэром. В таком случае вы не сможете подключиться к базе данных, пока ваш администратор не откроет порт 1433.

1. После завершения развертывания выберите Базы данных SQL в меню портала Azure или выполните поиск по запросу Базы данных SQL на любой странице и выберите этот пункт.

2. Выберите yourDatabase на странице Базы данных SQL. После этого откроется страница обзора базы данных, где будет указано полное имя сервера (например, ) и будут предоставлены параметры для дальнейшей настройки.

3. Скопируйте полное имя сервера. Оно понадобится вам для подключения к серверу и связанным базам данных из SQL Server Management Studio.

4. Щелкните Настройка брандмауэра для сервера на панели инструментов. Откроется страница Параметры брандмауэра сервера.

5. На панели инструментов щелкните Добавить IP-адрес клиента, чтобы добавить текущий IP-адрес в новое правило брандмауэра IP-адресов. С использованием правила брандмауэра IP-адресов можно открыть порт 1433 для одного IP-адреса или диапазона IP-адресов.

6. Выберите команду Сохранить. Для текущего IP-адреса будет создано правило брандмауэра для IP-адресов на уровне сервера, с помощью которого можно открыть порт 1433 сервера.

7. Нажмите кнопку ОК, а затем закройте страницу Параметры брандмауэра.

Теперь IP-адрес может проходить через брандмауэр IP-адресов. Теперь можно подключиться к базе данных с помощью SQL Server Management Studio или другого средства по своему усмотрению. Обязательно используйте созданную ранее учетную запись администратора сервера.

Важно!

По умолчанию доступ через брандмауэр IP-адресов Базы данных SQL включен для всех служб Azure. На этой странице щелкните Откл. , чтобы отключить доступ для всех служб Azure.

С чего начать создание базы знаний?

Начните с малого

В качестве минимального функционала вы можете создать небольшой раздел FAQ, в котором разместите ответы на часто задаваемые вопросы

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

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

Подберите инструмент

В самом начале вы можете обойтись простой статической страницей с FAQ. Но совсем скоро вам понадобится инструмент, через который можно будет быстро добавлять новые статьи и редактировать старые. Если вы располагаете ресурсами разработки, идеальным решением будет создание собственной админки, через которую вы будете работать с базой знаний. Если ваш сайт на WordPress, можно подключить один из бесплатных плагинов для базы знаний. Например, KnowledgeBase или EchoKnowledgeBase. Возможно, вы используете стороннюю helpdesk-систему — как правило, в них есть готовые модули для создания базы знаний.

Выделите команду для поддержки базы знаний

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

Привлекайте сотрудников к написанию статей

Кто лучше разбирается в особенностях сервисов, которые вы предоставляете, как не сотрудники компании? Мы в REG.RU подключаем продакт-менеджеров для уточнения концептуальных вопросов по нашим услугам. А также нам часто помогают сотрудники техподдержки. Они всегда на связи с клиентами и точно знают, какие вопросы у них возникают и как на них лучше ответить. У вас может быть договорённость с определённым кругом экспертов, которые охотно согласятся помочь с написанием инструкций.

Создание таблиц и ключей с помощью конструктор таблиц

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

Создание таблицы Customers

1. В Обозреватель сервера разверните узел подключения к данным , а затем узел сампледатабасе. mdf .

   если не удается развернуть узел подключения к данным или отсутствует подключение сампледатабасе. mdf, нажмите кнопку Подключение к базе данных на панели инструментов обозреватель сервера. в диалоговом окне добавление соединения убедитесь, что в поле источник данных выбран Microsoft SQL Server файл базы данных , а затем найдите и выберите файл сампледатабасе. mdf. Завершите добавление подключения, нажав кнопку ОК.

2. Щелкните правой кнопкой мыши таблицы и выберите команду Добавить новую таблицу.

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

3. В сетке добавьте строку для каждой из следующих записей.

   Имя столбца	Тип данных	Разрешить значения null
   		False (не установлен)
   		False (не установлен)
   		True (установлен)
   		True (установлен)

4. Щелкните строку правой кнопкой мыши и выберите пункт Задать первичный ключ.

5. Щелкните строку по умолчанию () правой кнопкой мыши и выберите пункт Удалить.

6. Назовите таблицу «Клиенты» путем обновления первой строки в области скриптов, как показано в следующем примере:

   Отобразятся примерно следующие сведения:

7. В левом верхнем углу Конструктор таблиц выберите Обновить.

8. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Таблица Customers создается в файле локальной базы данных.

Создание таблицы Orders

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

   Имя столбца	Тип данных	Разрешить значения null
   		False (не установлен)
   		False (не установлен)
   		True (установлен)
   		True (установлен)

2. Задайте OrderID в качестве первичного ключа, а затем удалите строку по умолчанию.

3. Назовите таблицу «Заказы» путем обновления первой строки в области скриптов, как показано в следующем примере:

4. В левом верхнем углу Конструктор таблиц выберите Обновить.

5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Таблица Orders создается в файле локальной базы данных. Если развернуть узел таблицы в обозреватель сервера, отобразятся две таблицы:

Создание внешнего ключа

1. В контекстной области в правой части сетки конструктор таблиц для таблицы Orders щелкните правой кнопкой мыши внешние ключи и выберите Добавить новый внешний ключ.

2. В появившемся текстовом поле замените текст ToTable на Customers.

3. в области T-SQL обновите последнюю строку, чтобы она соответствовала следующему примеру:

4. В левом верхнем углу Конструктор таблиц выберите Обновить.

5. В диалоговом окне Предварительный просмотр обновлений базы данных выберите обновить базу данных.

   Создается внешний ключ.

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

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

Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному» (часто обозначается 1:1). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

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

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

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим» (1:M) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M, добавьте первичный ключ из «одной» таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1» представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим» (M:N). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи «один-ко-многим».

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N, можно назвать этот новый объект «sold_products», так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products. Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

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

Два объекта могут быть взаимозависимыми (один не может существовать без другого).

Рекурсивные связи

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

Лишние связи

Лишние связи — это те, которые выражены более одного раза

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

Так как единственный способ, которым ученикам назначают учителей — это предметы.

Для чего нужны

Вот основные задачи БД на примере гардеробной:

• Сохранить наши данные по запросу — чтобы вы могли открыть дверь, повесить куртку, закрыть дверь и больше не думать ни о куртке, ни о гардеробной.
• Изменить наши данные по запросу — чтобы можно было легко извлечь из гардеробной все дырявые носки и положить на их место целые.
• Найти эти данные по запросу — чтобы быстро найти приличный пиджак или парный носок.
• Не дать прочитать эти данные тем, кому не следует, а кому надо — дать. Например, младший брат может смотреть на ваши кроссовки, но не может их брать. А девушка (или парень) может положить свои вещи, но только на определённую полку.
• Поддерживать порядок и не дать захламиться — если вам было лень и вы просто кинули толстовку куда попало, чтобы гардеробная либо сама нашла, куда эту толстовку правильно положить, либо сказала: «Э БРАТ ЗАЧЕМ ЗАХЛАМЛЯЕШЬ ПОЛОЖИ НОРМАЛЬНО ДАВАЙ»
• Масштабироваться — чтобы вы могли просто вешать в гардеробную вещи и не думать об объёме полок.
• Не потерять данные — если квартира будет гореть, приличная гардеробная не должна даже нагреться. Или, если она всё-таки горит, чтобы где-то в защищённом подземном гараже была точная копия этой гардеробной со всеми актуальными вещами.

Нормализация базы данных

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP), должны быть нормализованы.

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

Первая форма нормализации

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

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

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

Вторая форма нормализации

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

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

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара» зависит от идентификатора продукта, но не от номера заказа:

• Номер заказа (первичный ключ);
• ID товара (первичный ключ);
• Название товара.

Третья форма нормализации

Третья форма нормализации (3NF): каждый не ключевой столбец должен быть независим от любого другого столбца. Если при проектировании реляционной базы данных изменение значения в одном не ключевом столбце вызывает изменение другого значения, эта таблица не соответствует третьей форме нормализации.

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

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

Многомерные данные

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

Как сделать базу знаний полезной?

Пишите просто!

Старайтесь не усложнять текст. Представьте, что вашу инструкцию читает человек, который впервые столкнулся с тем, о чём вы пишете. Поймёт ли он вас? Можно даже провести эксперимент: дать прочитать черновик статьи непосвящённому человеку (пусть это будет мама, жена или ваш друг) и попросить дать обратную связь. Всегда ориентируйтесь на пользователя-новичка, поскольку продвинутый пользователь в любом случае вас поймёт.

Не скупитесь на картинки и видео

На одной картинке или схеме порой можно наглядно показать то, что вы будете описывать в нескольких абзацах текста. Если есть возможность записать видеоинструкцию — замечательно! В REG.RU у нас есть целая серия видеороликов по самым популярным вопросам. Вот пример одного из них:

Сделайте очевидным переход в базу знаний

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

Продумайте навигацию

Простая и интуитивно понятная навигация по базе знаний поможет сэкономить пользователям время на поиск нужной информации. Лучше всего разделить все статьи по тематическим категориям:

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

Добавьте поиск по статьям

Поиск — незаменимая вещь, если в вашей базе знаний много статей. В разделе «Помощь» на сайте REG.RU более 700 статей на различные темы, поэтому без качественного поиска никак не обойтись. Наши алгоритмы ищут релевантные страницы по поисковым запросам с учётом синонимов и опечаток.

Разместите ссылки на актуальные статьи на других страницах сайта

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

Разместите в конце каждой статьи форму для сбора обратной связи от пользователей. Это могут быть комментарии, лайки, звёзды или простой вопрос: «Помогла ли вам статья?».

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

Держите базу знаний в актуальном состоянии

Этот пункт последний в списке, но не последний по значимости. Бизнес постоянно развивается и растёт. Появляются новые услуги и сервисы. Меняется интерфейс и путь пользователя

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

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

⌘⌘⌘

Итак, хорошая база знаний может стать альтернативным каналом поддержки ваших клиентов. По нашему опыту, только 20% пользователей, посетивших раздел «Помощь» на сайте REG.RU, нуждаются в дополнительной консультации и идут писать заявку в поддержку. Поэтому мы рекомендуем создавать и развивать свою базу знаний. Поверьте, это выгодно.

А если у вас пока нет своего онлайн-бизнеса или проекта, это легко исправить с сервисом REG.Site, где не требуются навыки разработки или программирования.

5 последних уроков рубрики «Разное»

• Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

• Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

  Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

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

• Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Что такое база знаний?

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

База знаний может быть внутренней (только для сотрудников компании) и внешней (для клиентов). Мы поговорим именно о такой базе знаний, которую пользователи видят на вашем сайте. Она может называться по-разному: FAQ (часто задаваемые вопросы), справочный центр, центр поддержки, справка, помощь, справка и поддержка — но суть одна и та же. Это раздел на сайте, который содержит информационные статьи для ваших пользователей.

SQLite

Провозгласившая себя самой распространенной СУБД в мире, SQLite зародилась в 2000 году и используется Apple, , Microsoft и . Каждый релиз тщательно тестируется. Разработчики SQLite предоставляют пользователям списки ошибок, а также хронологию изменений кода каждой версии.

Достоинства

• Нет отдельного серверного процесса;
• Формат файла – кросс-платформенный;
• Транзакции соответствуют требованиям ACID;
• Доступна профессиональная поддержка.

Недостатки

Не рекомендуется для:

• клиент-серверных приложений;
• крупномасштабных сайтов;
• больших наборов данных;
• программ с высокой степенью многопоточности.

Подключение к СУБД

Если мы планируем работать в командной строке, заходим в среду управления MySQL.

а) В Linux вводим команду:

mysql -uroot -p

* где root — пользователь, под которым мы будем подключаться к оболочке; ключ -p потребует ввода пароля.

б) В Windows запускаем командную строку — в меню пуск или найдя ее в поиске. Переходим в каталог, с установленной СУБД и запускаем одноименную команду mysql, например:

cd «%ProgramFiles%\MySQL\MySQL Server 5.5\bin\»

* в данном примере предполагается, что у нас установлена MySQL версии 5.5. 

mysql -u root -p

* здесь, как и в Linux, идет подключение к mysql/mariadb под учетной записью root с запросом пароля.