Автор статьи: Артем Михайлов


Привет, дорогие читатели! Я сегодня хочу поговорить о важной теме для всех, кто работает с базами данных. Это проектирование реляционных баз данных. Кажется, что звучит ужасно скучно, да? Но на самом деле это важнейший инструмент для успешной разработки и поддержки баз данных.

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

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

Реляционная база данных (или, как ее еще называют, "РБД") - это основа для многих приложений и систем хранения данных. Это просто громадные таблицы с множеством строчек и колонок. В этих таблицах данные хранятся в отдельных "ячейках" и могут быть легко изменены или получены. 

Пример реляционной базы данных
Пример реляционной базы данных

Но что на самом деле делает РБД особенной? Дело в том, что она структурирована таким образом, что данные хранятся в отдельных таблицах и поэтому являются связанными (отсюда и название реляционных баз данных). Эти таблицы связываются друг с другом с помощью ключей, которые действуют как мосты между связанными таблицами. 

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

РБД является лучшим решением для хранения структурированных данных и позволяет обрабатывать большое количество информации.

Итак, какие показатели характерны для характерны для хорошо спроектированной базы данных?

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

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

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

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

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

Основные этапы проектирования РБД

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

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

Принципы правильной структуры РБД:

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

Второй принцип - это определение уникальных ключей (primary key) в каждой таблице. Ключ должен быть уникальным в пределах таблицы и использоваться для идентификации конкретной записи в этой таблице. Это позволяет устранить дублирование данных и обеспечить целостность базы данных.

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

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

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

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

Существуют много форм нормализации, но мы рассмотрим только первые три:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Также хочу порекомендовать бесплатный мастер-класс от Otus по проектированию БД для несложного Enterprise-приложения.

Комментарии (6)


  1. dyadyaSerezha
    23.04.2023 14:44
    +2

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

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

    Кстати, в одном крутом и большом западном банке была большая база референсных данных (то есть, только одни запросы на чтение от множества клиентов) с почти тысячью таблиц и с миллионами записей а некоторых. И во всей этой махине не было ни одного ключа вообще! Ни primary, ни foreign. А за ней присматривала целая команда "крутых" DB-админов, которые отвечали на любые запросы/вопросы через неделю, а часто их вообще игнорировали, нотому что ну очень крутые. Документации по базе ноль, конечно же.

    Есть ещё место чудесам в нашем мире! ????


    1. VVitaly
      23.04.2023 14:44
      -1

      :-) И даже "не так" как вы описали...
      На первом этапе проектирования (если хотите получить в результате масштабирование) нужно:
      - Узнать/понимать какие данные, объем и возможность "расширения" их исходного набора полей/свойств добавляются, обновляются и удаляются в БД (и в каком % соотношении).
      - Узнать/понимать какие данные, в каком объеме и с какой частотой выбираются/получаются из БД
      В противном случае получите "правильную" БД , но с проблемами масштабирования производительности... В которой запросы и структуры нужно будет в последствии оптимизировать. Любая оптимизация запросов в БД - следствие "недоработки" на этапе проектирования этой самой БД (ну и прикладного ПО использующего данную БД).


      1. dyadyaSerezha
        23.04.2023 14:44

        Мой комментарий был очень конкретный, по этапу оптимизации.


  1. GooG2e
    23.04.2023 14:44
    +1

    Некоторые моменты спорные - в угоду масштабируемости сейчас можно принести многое. В частности внешние ключи. Иногда и нормализацию.

    Проектирование хорошей БД как раз обычно учёт текущих запросов и некоторое прогнозирование будущих. То что хорошо для базы с 100 rps может быть катастрофически для базы с 100k rps. И это даже не учитывая профиль нагрузки.

    В итоге - правила хорошо проектирования это взвешивание плюсов и минусов каждого решения.


  1. klimkinMD
    23.04.2023 14:44
    +2

    Статья -- рекламный спам. Целевая аудитория непонятна. Учитывая количество годного материала по теме, появлений материала можно объяснить только рекламой.


  1. KhodeN
    23.04.2023 14:44

    Боюсь писать статьи на Хабр. Что-то интересное мне, после освоения кажется таким простым и очевидным, что странно об этом писать. А если то, что интересно - то обычно это то, что сейчас изучаю, но кому интересны мысли недоучки, тут же профи разномастные.

    А потом читаешь вот такие капитанские статьи и удивляешься. Чего боялся, пипл хавает?

    Ожидал чего-то интересного, глубокого. А тут введение в БД на уровне технарского урока...