💡 Что такое база данных и зачем нужны таблицы?

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

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

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

• Реляционные БД (~ 70 %) 🏆

• Документные БД (~ 20%) 🥈

• Ключ-значение БД (~ 10-15%) 🥉

• Облачные БД (~ 10%) 🍫

• Графовые БД (~ 5-7%)

• Колоночные БД (~ 3-5%)

• Файловые БД (~ 2-3%)

• Объектно-ориентированные БД (< 1%)

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

Мы можем заметить, что наиболее распространенным видом БД являются реляционные и это не просто так !

🌟 Почему реляционные базы настолько популярны?

• Зрелость модели - реляционная модель, предложенная в 20-м веке ученым Эдгаром Коддом успела пройти проверку временем

• Универсальность и совместимость технологий - существует более 160 реляционных СУБД, поддерживающих общие стандарты и язык запросов SQL. Это в значительной степени облегчает миграцию данных и совместимость решений

• Поддержка транзакций - реляционные БД предлагают мощный функционал поддержки транзакций, обеспечивающий сохранение целостности данных (что является ключевым параметром многих решений)

• Поддержка большинства корпоративных систем (ERP, CRM, BI) - данные системы исторически проектировались под реляционную модель, поэтому в настоящее время большинство крупных и средний предприятий имеют готовые решения, построенные на базе реляционных моделей.

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

😱 Проблемы реляционных БД

• Масштабирование - реляционные БД обладают определенными трудностями при горизонтальном масштабировании (чаще всего по причине, что каждая отдельная БД размещена на физическом сервере с ограниченными ресурсами, что значительно усложняет задачу разделения нагрузки)

• Поддержка ACID-транзакций - не смотря на то, что поддержка транзакций является преимуществом реляционных БД, одновременно с этим она может быть и ее недостатком. Поддержание таких свойств, как: атомарность (Atomicity), согласованность (Consistency), изолированность (Isolation), надежность (Durability) может потребовать значительные ресурсы, что в свою очередь повлияет на скорость и производительность системы.

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

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

Рассмотрим пример таблицы на иллюстрации. Мы видим, что таблицы в реляционной БД имеют свою структуру, описание которой приведем ниже.

Структура таблицы

• Таблица (отношение) - основной элемент реляционной БД, представляет собой массив данных, состоящий из строк (записи) и столбцов (атрибуты)

• Атрибуты - свойства, определяющие характеристики каждой сущности. Каждому атрибуту соответствует определенный тип данных (числовой, формат даты, строковый).
  (Идентификатор, чаще всего, не приходит вместе с данными, а создается искусственно в момент создания записи в таблице)

• Записи (кортеж) - строка таблицы, которая содержит совокупность значений атрибутов.

• Мощность - количество записей в таблице (в нашей таблице мощность = 4)

• Размерность - количество атрибутов, описывающих характеристики сущности (в нашей таблице размерность = 4)

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

Давайте теперь рассмотрим то, как может выглядеть самая простая схема реляционной БД на примере нашей таблицы (Продукты) и двух новых таблиц. (Покупатели и Покупки).

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

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

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

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

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

🔗 Типы связей

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

• Один-ко-многим - одна запись первой таблицы, связана с множеством записей второй таблицы. Самый распространенный тип связи на практике.

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

Завершая рассказ об основах реляционных баз данных, особое внимание уделим важной теме — первичным (PK) и внешним (FK) ключам.

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

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

🔑 Рассмотрим виды ключей

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

При создании первичного ключа накладываются следующие ограничения:

• Уникальность (каждая запись имеет уникальное значение ключа)

• Обязательность заполнения (атрибут не может быть пустым)

• Постоянство (значение ключа должно быть постоянным)

Первичные ключи удобно классифицировать по двум критериям:

Способ формирования

• Естественный PK - атрибут, присутствующий в самих данных и обладающий уникальностью (например ИНН гражданина, серийный номер товара)

• Искусственный PK (суррогатный ) - специально созданный атрибут, формируемый системой автоматически. (самый простой способ - автоинкрементируемое целое число)

Количество элементов

• Простой PK - включает единственный атрибут.

• Составной PK - формируется из нескольких атрибутов, с целью достижения уникальности.

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

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

Особенности внешнего ключа

• Допускает пустые значения, если связь между таблицами необязательна

• Проверяет существование соответствующей записи в родительской таблице

• Гарантирует соблюдение целостности данных (любая запись ссылается на реально существующую запись в другой таблице)

• Определяет иерархические или ассоциативные связи между таблицами. (тут мы имеем ввиду ранее рассмотренные связи один-к-одному, один-ко-многим, многие-ко-многим)

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

❤️ Спасибо за Ваше внимание! Надеюсь, эта статья помогла разобраться с ключевыми принципами реляционных баз данных.

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

Хорошего дня, друзья!

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

Бизнес редко приходит с чётким запросом.
Не потому что он глупый или ленивый.
А потому что бизнес живёт ощущениями, а не формулами.

Продажи "просели".
Конверсия "стала хуже".
Клиенты "ведут себя странно".

Это язык боли, а не требований.

И тут аналитик хочет обезопасить себя со всех сторон:
- написать запрос
- вытащить все данные
- построить отчёт "на всякий случай"
- показать цифры и сказать: "Вот"

Но в реальности это почти всегда заканчивается одинаково:
- "А это не совсем то"
- "А можно по-другому?"
- "А мы вообще не это имели в виду"

Когда бизнес не знает, что ему нужно,
аналитик не исполнитель,
аналитик - переводчик.

Ты начинаешь переводить бизнесовые ощущения в конкретные показатели, и смотреть как эти показатели подтверждают/опровергают эти ощущения. Ты переводишь эмоции в конкретные метрики. Подсознательное ощущение "что-то не так", ты переводишь в конкретные вопросы к данным.

И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.

Очень часто проблема не в том, что запрос неправильный.
А в том, что вопроса не существовало.

Например:

• "Продажи упали" - относительно чего?

• "Конверсия плохая" - на каком этапе?

• "Клиенты уходят" - кто именно и когда?

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

И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы:
- стало понятно, что именно ищем
- появилось ощущение направления
- сузилось пространство неопределенности.

И да - бывает, что бизнес так и не может сформулировать запрос.

Тогда аналитик делает не отчёт, а гипотезу.

Я предполагаю, что проблема может быть здесь.
Давайте проверим это.

Это нормальная практика.
Гораздо честнее, чем молча строить отчёт "на всякий случай".

Самое важное:
если бизнес не знает, что ему нужно - это не ошибка бизнеса.

Это точка, где аналитика становится ценностью!

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

Рассмотрим задачу.

Есть таблица заказов. Нужно:

1. Взять только оплаченные заказы

2. Посчитать сумму заказов по пользователям

3. Оставить пользователей, у которых сумма больше 10 000

4. Отсортировать по убыванию суммы

Как это выглядит в SQL

SELECT

user_id,

SUM(amount) AS total_amount

FROM orders

WHERE status = 'paid'

GROUP BY user_id

HAVING SUM(amount) > 10000

ORDER BY total_amount DESC;

Что происходит на самом деле?

Хотя запрос написан сверху вниз, выполняется он иначе:

1. FROM — база берёт таблицу orders

2. WHERE — отфильтровывает только status = 'paid'

3. GROUP BY — группирует строки по user_id

4. SUM(amount) — считает сумму внутри каждой группы

5. HAVING — отбрасывает группы с суммой ≤ 10 000

6. SELECT — формирует финальные колонки

7. ORDER BY — сортирует результат

SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата

Ты не "живешь" внутри процесса, ты его декларируешь.

Теперь тот же самый запрос в Python (pandas)

Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла

1. Ты загружаешь данные. Ты их уже видишь. Они лежат в память, у них есть текущее состояние.

import pandas as pd

df = pd.read_csv('orders.csv')

2. Фильтрация

paid_orders = df[df['status'] == 'paid']

paid_orders.head()

Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.

3. Группировка и агрегация

grouped = (

paid_orders

.groupby('user_id')['amount']

.sum()

.reset_index(name='total_amount')

)

grouped.head()

Ты видишь промежуточный результат:

• пользователей

• их суммы

• можешь проверить аномалии

4. Фильтр по агрегату

filtered = grouped[grouped['total_amount'] > 10000]

filtered.head()

5. Сортировка

result = filtered.sort_values('total_amount', ascending=False)

result

Ключевая разница

SQL

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

Python

- данные живут в памяти
- каждый шаг меняет состояние
- на каждом шаге можно остановиться, посмотреть, вернуться, ветвить логику

На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями

Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.

Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам

SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.

В разбираемом примере мы говори:

Хочу видеть сумму заказов по пользователям,
только оплаченные,
только больше 10 000

Для SQL есть входные данные, правила отбора, финальный результат.
SQL не живет во времени, он живет в описании результата

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

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

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

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

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

И вряд ли будут.

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

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

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

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

Если интересно пообщаться на эту тему пиши - howtpi@disroot.org.

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