Data Modelling Vocabulary: ER Diagrams, Normalisation, and Schema Design (англійською)
Англійський словник моделювання основних даних: сутності, відносини, нормалізація, іноземні ключі, індекси, типи моделей dbt, включно з шарами стаджінгу, mart і знімок.
Інженери даних, аналітики даних і розробники, які працюють з базами даних, потребують точного словника для обговорення дизайну схеми, структури моделі і відносин даних. Незалежно від того, чи малюєте ви діаграму взаємозв’ язків між об’ єктами, переглядаєте проект dbt або обговорюєте з колегою компроміси щодо нормалізації, правильний словник зробить розмову швидшою і точнішою.
Диаграма відносин об’єктів (ER) Vocabulary
** Сутність ** — об’ єкт або концепція реального світу, представлена як таблиця у реляційній базі даних. Сутності, зазвичай, є іменниками: Замовник, Замовлення, Продукт, Фактура. « Схема має три основні сутності: Замовник, Замовлення і РядокЗамовлення. »
** Атрибут ** — властивість або характеристика сутності, що відповідає стовпчику у таблиці. « Сутність Customer має атрибути: customer_ id, email, created_ at і country_ code. »
** Відношення ** — зв’ язок між двома об’ єктами. Відношення описуються за їх кардинальністю. « Відношення між Замовником і Замовленням є відношенням один- до- багатьох: один клієнт може зробити багато замовлень, але кожне замовлення належить лише одному клієнту. »
** Кардинальність ** — описує числову природу зв’ язку:
- ** Один до одного (1: 1) ** — кожен запис у таблиці A відповідає точно одному запису у таблиці B.
- ** Один до багатьох (1: N) ** — кожен запис у таблиці A може відповідати багатьом записам у таблиці B.
- ** Багато- до- багатьох (M: N) ** — записи в обох таблицях можуть відповідати декільком записам у іншій, що вимагає створення таблиці з’ єднання.
** Таблиця з’ єднання / асоціативна таблиця ** — таблиця, яку використовують для реалізації зв’ язку « багато- до- багатьох ». « У таблиці з’ єднання OrderProduct зберігаються зв’ язки між замовленнями і продуктами, а також кількість кожного з продуктів у заданому замовленні. »
** Основний ключ ** — стовпчик або комбінація стовпчиків, які унікальним чином ідентифікують кожен рядок у таблиці. « Ми використовуємо UUID як основний ключ для таблиці User, щоб уникнути показу послідовних ідентифікаторів у адресах URL. »
** Інший ключ ** — стовпчик у одній таблиці, який посилається на первинний ключ у іншій таблиці, забезпечуючи цілісність посилань. « Стовпчик order_ id у таблиці OrderLine є зовнішнім ключем, що посилається на стовпчик id у таблиці Order. »
** Цілісність посилань ** — гарантія того, що значення зовнішнього ключа завжди відповідає існуючому значення первинного ключа. « Відкидання цього запису без каскадного правила порушує цілісність посилань. »
Нормалізація мовлення
Нормалізація - це процес структурування бази даних для зменшення надлишку і поліпшення цілісності даних.
** Перша нормальна форма (1NF) ** — кожна колонка містить атомарні (неподільні) значення, і кожен рядок є унікальним. « Таблицю не було у 1NF, оскільки у стовпчику tags зберігалися значення, розділені комами; ми розділили її на окрему таблицю Теги. »
** Друга нормальна форма (2NF) ** — таблиця у 1NF, і кожен атрибут, який не є ключем, повністю залежить від всього первинного ключа (це стосується складних ключів). « Пересування назви продукту з таблиці OrderLine до таблиці Product призвело до того, що схема отримала значення 2NF. »
** Третя нормальна форма (3NF) ** — таблиця у 2NF і жоден атрибут, що не є ключем, не залежить транзитивно від первинного ключа. « Розділення відповідності країни і валюти на власну таблицю посилання виключає транзитивну залежність. »
** Денормалізація ** — навмисне введення надлишковості у схему для поліпшення швидкодії читання. Поширена у аналітичних базах даних і сховищах даних. « Ми денормалізували область клієнта у таблицю подій, щоб уникнути дорогих з’ єднань під час запиту. »
Схема дизайну словника
** Індекс ** — структура бази даних, яка покращує швидкість отримання даних за рахунок додаткової пам’ яті і витрат на запис. « Ми додали складний індекс (user_ id, created_ at) для підтримки найпоширеніших шаблонів запиту на таблицю подій. »
** Складений індекс ** — індекс, який охоплює більше ніж один стовпчик. Порядок стовпчиків у складеному індексі має значення. « Складений індекс на (tenant_ id, status, created_ at) обслуговує найчастіші запити у нашій архітектурі з декількома користувачами »
** Обмеження ** — правило, яке застосовується на рівні бази даних: первинний ключ, зовнішній ключ, унікальний, не нульовий, перевірка. « Додавання перевірочного обмеження до стовпчика amount забезпечує, що ми ніколи не зберігаємо від’ ємне значення транзакції. »
** Розділення на розділи ** — розділення великої таблиці на менші частини, з якими буде легше працювати, на основі значення стовпчика (діапазон, список або геш). « Ми розділимо таблицю подій за місяцями за створено_ в; запиту на останні події буде виконано лише на найновіший розділ. »
** Міграція схеми ** — скрипт, який змінює структуру схеми бази даних у контролюваний, версійний спосіб. « Кожна зміна схеми відбувається за допомогою файла міграції; ми ніколи не змінюємо схему бази даних вручну. »
Типи моделей dbt
dbt (засіб побудови даних) широко використовується у інженерії даних. Його шаровий підхід моделювання має свій власний словник.
** Модель стадії ** — тонкий шар перетворення, який очищає, перейменовує і перетворює необроблені дані джерела. Одна модель стажування на таблицю джерела, мінімальна бізнес- логіка. « Модель stg_orders перетворює поле order_total з рядка на десятковий і перейменовує стовпці, щоб вони відповідали нашій конвенції іменування »
** Проміжна модель ** — модель, яка поєднує або далі перетворює моделі стабілізації, але ще не є вихідним продуктом, який можна використовувати у бізнесі. « Проміжна модель об’ єднує замовлення з поверненнями для обчислення чистої вартості замовлення, яку потім посилаються декілька моделей ринку »
** Модель Mart ** — широка, орієнтована на бізнес таблиця, призначена для звітування і аналізу. Марти часто денормалізовані для швидкості запиту. “Модель fct_orders mart містить один рядок на замовлення з усіма розмірами, які аналітик потребує для звітів про прибуток.”
** Модель знімків ** — модель dbt, яка захоплює стан повільно змінюваної вимірності у певний момент часу, що дозволяє провести історичний аналіз. « Ми створили знімок таблиці users, щоб відстежити зміни рівнів підписки клієнтів з плином часу. »
** Сімеїз ** — файл CSV, завантажений до dbt як статична таблиця посилань. « Коди країн і їхні назви ISO обробляються як сімеїз dbt. »
Приклади слів у контексті
-
«Взаємозв’язок між Campaign і ConversionEvent є один-до-багатьох; кампанія може генерувати тисячі подій конверсії, але кожна подія приписується саме одній кампанії»
-
«Ми навмисно денормуємо рівень ціноутворення в таблицю рахунків-фактур, тому що приєднання до конфігурації ціноутворення в час запиту додавало 200 мс до кожного запиту звіту»
-
«Складений індекс на (customer_id, order_date DESC) був обраний спеціально для підтримки найпоширенішого шаблону доступу: отримання останніх замовлень клієнта»
-
«Всі зміни схеми версуються як файли міграції в сховищі; жоден DBA не має прямого доступу до запису до виробничої схеми поза переглянутою і схваленою міграцією»
-
«Наш проект dbt дотримується строгої тришарової архітектури: моделі стадіювання містять тільки перетворення, що відповідають джерелу, проміжні моделі містять логіку з’єднання, а моделі mart є єдиним шаром, який аналітики запитують безпосередньо»
На практиці: Навігація нюансів зворотного зв’язку
Будьмо чесними - коли ви створюєте схему бази даних, особливо в командному середовищі, комунікація іноді може здатися… складною. Термінологія не завжди інтуїтивно зрозуміла, особливо якщо ваша перша мова не є англійською. Легко зануритися в технічний жаргон і пропустити головне повідомлення. Ось тут розуміння того, як професіонали використовують ці терміни, стає таким же важливим, як і знання того, що вони означають.
Розглянемо такий сценарій: Ви надіслали запит на збирання (Pull Request, PR), у якому описано зміни у схемі бази даних замовлень клієнтів. Ваш старший розробник, Сара, залишає коментар до опису PR: « Це хороша робота, але я хвилююся щодо рівня нормалізації. Зокрема, чи можете ви пояснити, чому ми маємо денормовану таблицю перетину для orders і «добутків»? Здається, що це може призвести до оновлення аномалій в майбутньому.” Фраза не агресивна; це конструктивна. Сара не просто каже “неправильно!” Вона використовує точний словник - “рівень нормалізації”, “денормалізована таблиця з’єднань” і, що найважливіше, “оновлення аномалій” - кожна з яких має певні технічні наслідки. Зрозуміти, що «аномалії оновлення» відносяться до потенціалу невідповідності даних, якщо оновлення не обробляються обережно, є ключовим. Це про визнання того, що вона піднімає потенційну проблему, а не видає негайну критику. Аналогічно, у розмовах Slack, де обговорюється дизайн схеми, ви можете почути, як хтось каже: «Сфокусуємося на тому, щоб у нас були належні іноземні ключі для підтримки посилальної цілісності». Наголос тут робиться на принципі підтримки відносин даних — щось, що часто втрачається при перекладі безпосередньо з концепцій рідної мови.
Інша поширена ситуація виникає під час перегляду коду. Рецензент може вказати: « Цей індекс на customer_id у таблиці orders здається зайвим, враховуючи обмеження первинного ключа. » Термін « зайвий » не має на меті зменшити ваші зусилля; він підкреслює потенційну неефективність — індекс, який не пропонує значних прибутків продуктивності і може, з часом, ускладнити обслуговування. Це стосується оцінки компромісів, що беруть участь у проектуванні схеми. Навчання інтерпретувати ці нюанси дозволяє вам ефективно відповісти, можливо, сказати: « Ви маєте рацію; я не враховував вплив обмеження первинного ключа під час додавання цього індексу. Я оціню його необхідність і, можливо, видалю його»
Ціль не в тому, щоб просто повторювати англійські визначення. Це розуміння * чому * певні терміни використовуються в професійному контексті, розпізнавання основних проблем, які вони представляють, і відповідь з відповідною точністю. Це про те, щоб продемонструвати, що ви розумієте не тільки * що * запитується, але * чому * це має значення для загальної стабільності і продуктивності системи.
Ось приклад того, як ви можете використовувати dbt для створення моделі перевірки:
-- dbt Staging Model - Orders
source orders_table {
sql = """
SELECT
order_id,
customer_id,
product_id,
order_date,
total_amount
FROM {{ source('raw_orders') }}
"""
}Цей простий приклад демонструє використання source і SQL для перетворення сирих даних — ключова концепція при обговоренні стадіонарних шарів в dbt. Мова тут не тільки про технічні кроки; це про опис * як * ви готуєте дані для подальшого аналізу, підкреслюючи навмисний і контролюваний процес.