Проектирование БД
Немного моделировал в 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"
как лучше всего начать моделировать БД
один из примеров: https://www.ibm.com/docs/ru/tivoli-netcoolimpact/7.1?topic=wdm-setting-up-data-model
- Описать источники данных, где хранится все
- Описать типы данных: сущности
- Описать элементы данных: поля сущностей, и их содержание
- Описать связи данных
- Описать источники событий, события для изменения данных (можно через Dataflow Diagram, связав "действия/сценарий с агентами - тут основное внимание на сценарии получения данных/информации - кто что запрашивает, заносит куда и что получает https://prnt.sc/9HZS-AUtLbxO)
- Возможно категоризировать по отделам
- Возможно прикреплять ссылки на сценарии событий
Ключи это мета-мета-мета объекты описания.
- мы распределяем, для того, чтобы определить сущности мета-мета описаний - для связки таблиц, и логики взаимодействия, приоритезации данных.
Table - статическая табличка (плоская таблица)
Tables - реляционная табличка, со связями
Иерархическая таблица(сгруппированная, либо с ссылками - догадка моя)
Возможно, лучше не называть сущностями, а называть табличками: табличка клиентов, табличка заказов, таблица продуктов, таблица документов, таблица договора и тп.
Мы получим несколько уровней таблиц, минимум следующую:
и связи между ними мы просто мы строим ме жду этими таблицами.
А хранятся формы таблиц, и само содержание табличек(ящичков с данными) и таблиц мы храним уже в базах данных
Зачем делается реляционная база:
- для экономии места - одна база, делится на части, по сущностям, после связываются между собой каким-то знаком, по типу - ID клиента и тп.
Primary key - это такое значение, которое помогает нам определять, о какой записи мы говорим, где они находятся - то есть, оно уникальное, по которому нам легко пойти в другую базу, табличку и идентифицировать связанные записи
- задача: значит нужно у полей определять их назначение, тип "ключей" справа. Чтоб по ним понять, по "чему" мы определяем что.
ЕЕЕ, разобарсял что такое foregn key:
это обозначение строки-поля-ключа-содержания типом отношения - это основа для этого поля, чтоб его определяли, или нет. У каждой таблики,"ячщичка данных" есть определяющий этот ящичек идентификатор, по которому можно в данных найти этот "ящичек" и распознать этот ящичек.
И так как это связанные таблички, "ящички", в которых имеются элементы мета-описания других "ящичков", то для каждого ящичка это мета-описание будет по отношению разным.
К примеру, для таблички заказов id клиента будет не определяющим это мета-описание, оно будет указывать и ссылаться на другой ящичек, то это foregn key.
А то, что будет указывать, ссылаться, определять, размечать именно этот ящичек и будет для этой таблички заказов как primary. Так же и с табличкой клиентов. Отчасти, primary key, предполагаю, являются определяющей "шапкой" для тиблички "ящичка". Если это сущность клиента, то это Сущность и ее номер по порядке, т.к
А связи, взаимосвязи: "1 к 1", "1 к множеству" и "множество к множеству"
Это поможет выстроить связи и структуру между ними.
Как понять, какая связь между таблицами по множествам?
- логикой
- если одна сущность, может создать больше сущностей чем одну, то это 1 к множеству (взаимоисключающе, то есть в обратную сторону такого не происходит)
- если одна сущность может создать только 1 сущность, то это 1 к 1
- Если множество сущностей, может создать множество (тут предполагаю, что на одно поле может влиять несколько полей, и оно, поле, тоже может вариироваться - наверно более редкий случай, который нужно смотреть на примере). Это мостовые таблицы(называют как bridge tables) как понял.
- клиент может создать несколько заказов
- А несколько заказов не могут создать несколько клиентов, это будут разные клиенты
- а разные клиенты, не могут создать 1 заказ(хотя, если это б2б, или общий заказ, то это возможно), или даже несколько заказов.
https://www.youtube.com/watch?v=B5r8CcTUs5Y
Диаграмму движения потока данных можно делать по одному процессу за раз
- https://kwork.ru/personal-assistant/35329531/sozdanie-bazy-dannykh-dlya-internet-magazina
- https://kwork.ru/script-programming/29307520/razrabotayu-bazu-dannykh
- Отправил им https://www.websailors.pro/ru/healthcare-mobile-application
- Отправил им https://studiovsemoe.com/services9.html
- https://freelancehunt.com/showcase/work/dizayn-razrabotka-bd-yii2-migratsii/647153.html - вот это мужик может мб помочь
- https://kwork.ru/software/1065486/dorabotka-bazy-na-ms-access
- https://kwork.ru/software/10986214/dorabotka-ili-sozdanie-bazy-dannykh-na-ms-access
- https://kwork.ru/script-programming/29324415/telegram-razrabotka-bota-pod-klyuch
- https://www.youtube.com/watch?v=xsg9BDiwiJE&list=PLUoebdZqEHTxpGCwKrb82cIvHNoNaBb4R
- https://www.youtube.com/watch?v=96uKeHSQMkg&sttick=0
Database Schema (ERD). Entity Relationship Diagram
Как понять, как назвать табличку - по ее Primary Key - по столбцу. которая ее определяет, уникальность.
В чем оптимизация: мы чтобы один и тот же сет данных не дублировать, можем дать название сущности - к примеру как тут - табличку сделать customer ID - и эту табличку использовать как "ящичек" с данными об этом клиенте, а о клиенте делать маленькую заметку в этом табличке ссылкой - указателем, т.к. мы можем использовать только в ID и нам будет этого достаточно, остальные данные могут храниться отдельно и не нагружать базу.
- то же самое можно с продуктами, или с "набором" продуктов иметь дело. "Пакет услуг" нужен для того, чтобы объеденить таблички - по сути, мы имеем "Корзину услуг". И по идее, можем платить за "корзину". https://prnt.sc/Ta5QVD7ZUjip
- в итоге, у нас будет ID пакета, и возможно id продукта/договора, за который проводится платеж, чтобы "распознать" платеж при оплате
- то есть нужно подумать, куда дальше двигаться по отпимизации - как идентифицировать договора и оплаты, за какой primary key держаться
Каждую оптимизацию можно делать таким образом, шаг за шагом.
В итоге, получает такую мета-модель, чисто с ссылками(1 primary и foregn key), чтоб все то, что не используется, вынести в бок, оставить место только для того, что используется.
Это получается практика оптимизации базы данных, с помощью ее структуризации, декомпозиции и связки этих частей таблиц. Когда оптимизируем, у нас возможность растет работать с большим массивом данных, быстрее, в разы экономнее по ресурсам.
+ даже так можно сгруппировать еще, в итоге:
То есть в итоге, шапка состоит из мета-мета-мета-данных/описаний - ссылок, по которым можно детали узнать для себя уже найдя/перейдя по ссылке. Но эффективность базы, ее организация растет.
- можно посмотреть примеры требований: тут явно про то, чем мы тоже занимаемся - https://prnt.sc/rtoAbTwqL4vw
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
Как ручками сделать в 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
Придется ручками учится моделировать, уже к этому припер.
Тут прям, выше, гайд как делать. Буду записывать, брать в работу, еще и возвращаться пересматривать.
- Inputs - перечислить все операции с данными(близко к юзкейсам) - что круто. Их активность, периодичность запросов, workload смотреть.
- Запрос(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
- возможно получится несколько уровней модели даталфоу https://youtu.be/ab1DZ6o7QBs?t=938
- https://www.youtube.com/watch?v=p72mCYQBM8o