Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Таблицы - необходимый компонент баз данных. Чтобы построить аналитику, мы часто агрегируем данные из таблиц и строим графики. Но иногда анализ самой таблицы без графиков оказывается удобнее.

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

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

4 <h2>Таблица</h2>

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

6 Таблица содержит информация о разных пиццериях. В ней есть следующие столбцы:

7 <ul><li>Название - это название пиццерии</li>

8 <li>Доставка - есть у пиццерии доставка или нет</li>

9 <li>Начало работы - с какого времени открыта пиццерия</li>

10 </ul>Вся информация в таблице - это параметры разных пиццерий, то есть смысл этой таблицы. Смысл называетсясущностью- это то, о чем хранится информация в таблице.

11 Для таблиц как сущностей есть такое правило: одна таблица - одна сущность. Например, в таблице Users хранится только информация о пользователях, в таблице Payments - о платежах, а в таблице выше - о пиццериях.

12 Таблицы в базах данных могут быть связаны друг с другом. Такие базы называютсяреляционными.

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

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

15 Таблицы Users и Payments связаны. Такие связи называютсяотношениямимежду сущностями. Язык SQL - это основной инструмент работы с реляционными базами данных.

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

17 <h3>Компоненты таблицы</h3>

18 Обязательные компоненты таблиц такие:

19 <ul><li>Столбец</li>

20 <li>Строка</li>

21 <li>Домен</li>

22 <li>Ключ</li>

23 </ul>Столбец в таблицах еще называютколонкой*,полемилиатрибутом. Атрибут таблицы выражает какой-то один тип информации о сущности. Например, в таблице Users может храниться поле Full name, и оно содержит информацию о ФИО пользователя. Поле User address будет хранить адрес пользователя. В колонке Название в таблице пиццерий мы видим название конкретной пиццерии.

24 Строки мы еще зовемзаписьюиликортежем. Одна строка - это одна единица сущности. В таблице Users одна запись - это один пользователь, в Payments - это один платеж, в Пиццерии - одна пиццерия.

25 При создании таблицы в базе данных мы обязательно указываемтип данныхинформации в поле.Доменполя - это и есть тип данных столбца. К примеру, поле Full name в таблице Users может содержать строку и ничего кроме строки.

26 Вот примеры доменов полей:

27 <ul><li>Строка</li>

28 <li>Целое число</li>

29 <li>Число с плавающей точкой и прочее</li>

30 </ul>Мы уже упомянули, что таблицы в реляционных базах данных связаны. Чтобы связать две таблицы, мы используем специальное поле, которое называетсяключ. В таблице Users и Payments такой ключ - это колонка UserID. Мы связываем эти две таблицы с помощью оператора join.

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

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

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

34 <h2>Отношения таблиц</h2>

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

36 <ul><li>Один к одному</li>

37 <li>Один ко многим</li>

38 <li>Многие ко многим</li>

39 </ul>Рассмотрим каждый из этих типов.

40 <h3>Один к одному</h3>

41 Представим, что у нас есть база данных пользователей интернет-магазина. Посмотрим на таблицу Users, в которой есть информация о пользователях:

42 users

43 В этой таблице мы видим три поля:

44 <ul><li>UserID - ID покупателя</li>

45 <li>Full name - имя и фамилия покупателя</li>

46 <li>Email - адрес электронной почты</li>

47 </ul>Теперь топ-менеджер магазина сообщил нам, что мы должны внести новое поле: есть ли у покупателя скидочная карта или нет. В нашей таблице уже хранится 10 000 строк, поэтому вписывать в каждую наличие скидочной карты будет долго. При этом один покупатель мог быть вписан в таблицу несколько раз, если он менял адрес электронной почты.

48 Чтобы решить эту задачу просто, мы создадим новую таблицу Users discount card, в которой будет всего два поля:

49 <ul><li>ID покупателя</li>

50 <li>Наличие у покупателя скидочной карты</li>

51 </ul>При этом, чтобы не вписывать наличие карты у одного и того же покупателя несколько раз, мы сделаем поле UserID уникальным.

52 Посмотрим на такую таблицу:

53 users_discount_card

54 Таблица содержит только UserID и Discount card - есть у пользователя скидочная карта или нет. Теперь эту таблицу легко связать с таблицей Users по UserID с помощью SQL-функции join и получить для каждого пользователя наличие у него скидочной карты. При этом нам не нужно вносить в Users новое поле.

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

56 <h3>Один ко многим</h3>

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

58 Для этого мы создадим новую таблицу Phones:

59 users

60 В этой таблице есть три поля:

61 <ul><li>PhoneID - ID номера телефона</li>

62 <li>UserID - ID покупателя, которому принадлежит телефон</li>

63 <li>Phone - номер телефона</li>

64 </ul>При этом PhoneID должен быть в таблице уникален, но, как мы видим, UserID повторяется. Это значит, что у одного покупателя есть несколько номеров.

65 <h3>Многие ко многим</h3>

66 Чтобы понять отношениемногие ко многим, рассмотрим еще одну таблицу Products:

67 products

68 В таблице содержится список товаров магазина - ID товара и наименование. Мы хотим связать, какие товары какой покупатель приобрел. При этом один покупатель может купить много разных товаров, но и один и тот же товар могут купить разные люди. Таблица-отношение между таблицами Users и Products будет выглядеть так:

69 users_products

70 В этой таблице мы видим, что пользователь с ID = 1 купил товары с ID 10 и 5, но товар 10 купили два пользователя: с ID = 1 и ID = 6. Такие отношения и есть "многие ко многим".

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

72 <h2>Проектирование таблиц</h2>

73 Есть такие виды проектирования баз данных:

74 <ul><li>Концептуальное моделирование</li>

75 <li>Логическое моделирование</li>

76 <li>Физическое моделирование</li>

77 </ul>Концептуальное проектирование заключается в том, что мы описываем, какие у нас будут сущности в базе данных и отношения. Сущности, как мы говорили выше - это отдельные таблицы. Отношения - какие сущности и как будут связаны друг с другом: "один к одному", "один ко многим" или "многие ко многим". То, о чем мы говорили выше, - это концептуальное проектирование.

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

79 Физическое моделирование уже учитывает проектирование на уровне особенностей каждой отдельной базы данных: PostgreSQL, MySQL. При физическом моделировании мы выбираем, какие запросы нам важны больше всего: чтение из таблицы или запись в таблицу, и производим тестирование на пропускную способность.

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

81 <ol><li>Концептуально описываем схему базы данных и сущности, которые там содержатся</li>

82 <li>Выбираем модель данных в логическом моделировании</li>

83 <li>Рассматриваем более детально реализацию базы данных в конкретном хранилище с учетом конкретной базы, которую мы выбрали</li>

84 </ol>Таким образом, проектирование одной базы данных обычно проходит через все три этапа. Каждый следующий этап дополняет и уточняет предыдущий.

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

86 <h2>Агрегация таблицы продаж</h2>

87 Рассмотрим базу данных<a>table</a>. В ней есть одна таблица sales, которая содержит информацию о покупках в магазине. Посмотрим на эту таблицу:

88 sales

89 В этой таблице мы видим информацию о покупателях и купленных товарах.

90 Мы хотим определить из таблицы топ-5 самых прибыльных товаров. Наименование товара указано в поле product_name, а прибыль - в sales. Напишем SQL-запрос:

91 <a>Ссылка на таблицу</a>

92 В этом запросе мы произвели агрегацию по товарам и посчитали суммарную прибыль по всем товарам. Мы использовали ORDER BY SUM(sales) DESC, чтобы отсортировать товары по убыванию прибыли. LIMIT 5 позволяет отобрать только пять верхних строк таблицы.

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

94 <h2>Выводы</h2>

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

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