About Teletype
Join
Личный Журнал
@ultralearning
October 6

Проектирование БД

Немного моделировал в 2019-20 схему реляционных БД, при прохождении https://productuniversity.ru/marketing-i

https://www.youtube.com/watch?v=B5r8CcTUs5Y&list=PL4etfiszkYJydvQ3wqa7BcPXkX69TyUSo

Но теперь, нужно реально составить для задач, иначе сложно двигатсья дальше.

Далее, мета-описания, записываю мысли по прохождению.

Мои основные задачи:

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

Список вещей которые я незнаю:

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

"Database Keys Made Easy - Primary, Foreign, Candidate, Surrogate, & Many More"

Что такое keys

как лучше всего начать моделировать БД

один из примеров: https://www.ibm.com/docs/ru/tivoli-netcoolimpact/7.1?topic=wdm-setting-up-data-model

Хороший план(на мой взгляд)

  1. Описать источники данных, где хранится все
  2. Описать типы данных: сущности
  3. Описать элементы данных: поля сущностей, и их содержание
  4. Описать связи данных
  5. Описать источники событий, события для изменения данных (можно через Dataflow Diagram, связав "действия/сценарий с агентами - тут основное внимание на сценарии получения данных/информации - кто что запрашивает, заносит куда и что получает https://prnt.sc/9HZS-AUtLbxO)
    1. Возможно категоризировать по отделам
    2. Возможно прикреплять ссылки на сценарии событий

Ключи это мета-мета-мета объекты описания.

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

Table - статическая табличка (плоская таблица)

Tables - реляционная табличка, со связями

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

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

Мы получим несколько уровней таблиц, минимум следующую:

  1. Таблица всех зареганных документов
  2. Таблица типов документов
    1. Документы, как таблицы (то есть "сущность", и является таблицей так же)

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

А хранятся формы таблиц, и само содержание табличек(ящичков с данными) и таблиц мы храним уже в базах данных

Зачем делается реляционная база:

  1. для экономии места - одна база, делится на части, по сущностям, после связываются между собой каким-то знаком, по типу - ID клиента и тп.

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

  • задача: значит нужно у полей определять их назначение, тип "ключей" справа. Чтоб по ним понять, по "чему" мы определяем что.

ЕЕЕ, разобарсял что такое foregn key:

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

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

К примеру, для таблички заказов id клиента будет не определяющим это мета-описание, оно будет указывать и ссылаться на другой ящичек, то это foregn key.

А то, что будет указывать, ссылаться, определять, размечать именно этот ящичек и будет для этой таблички заказов как primary. Так же и с табличкой клиентов. Отчасти, primary key, предполагаю, являются определяющей "шапкой" для тиблички "ящичка". Если это сущность клиента, то это Сущность и ее номер по порядке, т.к

А связи, взаимосвязи: "1 к 1", "1 к множеству" и "множество к множеству"

  • 1 to 1
  • 1 to many
  • many to many

Это поможет выстроить связи и структуру между ними.

Как понять, какая связь между таблицами по множествам?

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

Пример тут:

  • клиент может создать несколько заказов
  • А несколько заказов не могут создать несколько клиентов, это будут разные клиенты
  • а разные клиенты, не могут создать 1 заказ(хотя, если это б2б, или общий заказ, то это возможно), или даже несколько заказов.
Тут показан пример PK
Как раз, нашел и пример, вроде правильно догадывался - множества к множеству

https://prnt.sc/9HZS-AUtLbxO

https://www.youtube.com/watch?v=B5r8CcTUs5Y

Диаграмму движения потока данных можно делать по одному процессу за раз

Список пот. исполнителей:

Еще источники:

Database Schema (ERD). Entity Relationship Diagram

  • Tables → Fields
    • Student table
    • Class table
  • Relation, relation key

  • Nature of relationship: 1 to 1, 1 to many, many to many

Как понять, как назвать табличку - по ее Primary Key - по столбцу. которая ее определяет, уникальность.

  • оптимизация табличек, "ящичков", делать их компактнее, как раз такими разбиениями

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

  • то же самое можно с продуктами, или с "набором" продуктов иметь дело. "Пакет услуг" нужен для того, чтобы объеденить таблички - по сути, мы имеем "Корзину услуг". И по идее, можем платить за "корзину". https://prnt.sc/Ta5QVD7ZUjip
    • в итоге, у нас будет ID пакета, и возможно id продукта/договора, за который проводится платеж, чтобы "распознать" платеж при оплате
      • интересно, насколько мы можем сделать личный кабинет для платежа? и стоит ли?
  • то есть нужно подумать, куда дальше двигаться по отпимизации - как идентифицировать договора и оплаты, за какой primary key держаться

Каждую оптимизацию можно делать таким образом, шаг за шагом.

В итоге, получает такую мета-модель, чисто с ссылками(1 primary и foregn key), чтоб все то, что не используется, вынести в бок, оставить место только для того, что используется.

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

+ даже так можно сгруппировать еще, в итоге:

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

  • можно посмотреть примеры требований: тут явно про то, чем мы тоже занимаемся - https://prnt.sc/rtoAbTwqL4vw

Про ETL процессы:

https://blog.skillfactory.ru/glossary/etl/#:~:text=ETL%20%E2%80%94%20%D1%8D%D1%82%D0%BE%20%D0%BE%D0%B1%D1%89%D0%B8%D0%B9%20%D1%82%D0%B5%D1%80%D0%BC%D0%B8%D0%BD%20%D0%B4%D0%BB%D1%8F,%D1%81%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0%D0%BC%D0%B8%20%D0%B2%20%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%B5%20%D0%BF%D0%B5%D1%80%D0%B5%D0%BD%D0%BE%D1%81%D0%B0.

Когда мы размечаем что-то как Primary - мы сразу обозначаем это как мета-объект, "шапку", данных

Как Foregn key мы размечаем ссылки на другие таблицы, обозначем "мета-объект" как ссылку, чтоб по ней было понятно, что это шапка, которая ссылает меня на другую табличку/ящичек данных.

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

https://t.me/malik_valikhodjaev1/105

Основные задачи, внутри данных, которые будут производится в рамках практик:
1. поправка критической вещи: правильного порядка взаимосвязей данных меж собой. Понимание взаимосвязей объектов - критично. (https://youtu.be/aWP2MLAYQfk?t=879)

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

Композитные ключи - Composite Key

  • https://youtu.be/hktyW5Lp0Vo?t=541
  • это когда соединяют значения, для создания уникального комбо значения - типо - что-то с документами, когда из твоей даты рождения и пр данных + id паспорта создают уник номер, который по сути является Composite Key

Bridge Table

  • соединительные "ящички"

Как ручками сделать в lucid с типовым кодом базу:

  • int (integers) - интеграл - целые числа - нечто целое = 1,2,3 и тд.
  • words - string - строка, текстовый формат данных - вики - кобминация(нить) любых символов(знаков) и чисел, без разницы
  • floats = числа, с дроблением = 1.02, 38.287 и тд.
  • date - датовое значение, для временных форматов
  • Char (___) - в SQL - Char и (кол-во символов в этой строке) - занимает 1 кол-во строк, в зависимости от указанного кол-во символов - если указали 7, то будет 7 знаков всегда занимать.
  • Varchar - varying - изменяемое - varchar(__) - в скобках можно указать максимальное значение строки.
  • boolean - Истина/Ложь(для программистов)- да/нет(для пользователей), True/False. Тип данных, тип переменных. В знаках указывается как - ложь=0, истина=1.
  • в char - могут быть и негативные значения, в uchar - только положительные.
  • money - фин значение
  • https://vertabelo.com/blog/er-diagram/
  • enum - enumiration - списковое значение, которое задают, чтоб потом можно было это значение выбрать. Но, это только в случае, если значения не меняются. Если меняются, то лучше составить отдельную таблицу и сделать через ссылкочную строку - foreign key, с этими значениями, даже с тем, что они будут пополнятся, и генерить ID этих новых значений, потом связав через foreign key - https://prnt.sc/pgV3E-bf1OJE

https://docs.mql4.com/ru/basis/types/integer/integertypes#char

https://vertabelo.com/blog/er-diagram/

https://vertabelo.com/blog/logical-physical-data-model/

https://docs.mql4.com/ru/basis/types/integer

Part 2

Придется ручками учится моделировать, уже к этому припер.

Тут прям, выше, гайд как делать. Буду записывать, брать в работу, еще и возвращаться пересматривать.

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

Примеры:

  • Запрос(query): какие данные запрашивают
    • Задача: Берем самые важные query вперед!
  • Операция: что делают с данными, или какое действие происходит со стороны приложения/базы данных
  • Description: по сути краткое описание сценария, сути того, что смотрят, какие данные

Задача 2: разложить все сущности на модели изначально

Пока самый гибкий инструмент - draw.io

будем продолжать там - https://docs.google.com/spreadsheets/d/1NjOS3_sI71FCoJ9fm2mtI402LwuG9KT9EzKA09cNXSo/edit?gid=1345648953#gid=1345648953

апдейт: лучше этот - https://app.quickdatabasediagrams.com/#/d/xjTWti

апдейт: еще лучше https://dbdiagram.io/e/6713aea297a66db9a38c6ae7/6715aafc97a66db9a3a44f78 гуд!

Практика DFD - Data Flow Diagram

Нотация проста

https://app.diagrams.net/#G1u2KO8cbXyKB-WvFu3MDCjzcsH1QCsMpC#%7B%22pageId%22%3A%22dgrNQc7oY4N92YgCMkvI%22%7D

Личный Журнал
October 6, 17:21
0 reactions
0 views