Як я документував цілу базу даних з нуля (без схеми бази даних)

Конфіденційність

З огляду на політику конфіденційності я НЕ буду розголошувати ЖОДНОГО реального імені, бази даних, таблиць та/або вмісту. Весь вміст в цьому повідомленні був змінений для збереження конфіденційності.

Сценарій

Коли мене прийняли на роботу 12 квітня 2022 року, я прийняв цю роботу через поставлений мені виклик, оскільки в той час шукав роботу за межами Бразилії. Але… це був величезний виклик, і я прийняв його.

На той час компанія налічувала приблизно 80 співробітників, і коли мене прийняли, в компанії не було структурованого відділу ІТ, тільки декілька хлопців перед комп’ютерами, які підтримували компанію.

У мій перший день мені було задано багато завдань, і до кожного завдання, що мені давали, я запитував:

Де знаходяться дані?

Ну… джерел було багато… Жодне з цих джерел не було базою даних, це були таблиці в Google Drive, локальні таблиці Excel і звіти, експортовані з програми, назвемо це “ABC” від компанії “X”.

Ця програма була розміщена на локальному ПК, яке знаходилося всередині нашої компанії, і всі наші комп’ютери були підключені до неї. І найважливіша інформація для компанії була в програмі “ABC”. Таким чином, мені довелося вручну експортувати всі дані з “ABC” і створювати інформаційні панелі та/або аналіз.

Крім того, на нас (відділ ІТ) покладали обов’язок автоматизувати все. Тож ми звернулися до “X Company” із проханням перенести базу даних “ABC” в хмару.

Коли вона нарешті була перенесена в хмару, ми повинні були підключити VPN до хмари і завантажити все з хмари нашого хмарового сховища (Google Big Query). Ну, нарешті, на той час ми почали з приблизно 450 таблиць і 5000 стовпців.

Таким чином, щоб почати працювати в цьому хаосі, я попросив мого керівника запросити у “X Company” схему бази даних.

Документування всієї бази даних

Їхня відповідь була: Ми цього не зробимо, оскільки це є нашою основною діяльністю.

Ну, ось звідки все почалося. Мій керівник попросив мене задокументувати базу даних, оскільки без цього найважливіші проекти в нашій компанії зупиняться. (жодного тиску, звісно)

З чого я почну?

У мене є понад 400 таблиць, всередині них є понад 5000 стовпців зі своїми зовнішніми ключами (FK).

У мене була ідея: Power BI може визначити стовпці з однаковою назвою, якщо я встановлю опцію “Автоматичне виявлення нових зв’язків після завантаження даних”.

З цією опцією включеною, Power BI може це робити:

Отже, я уявив… це все. Проблема вирішена.

Ну… виявляється, це не так.

Номенклатура бази даних не є стандартизованою, але ця ідея дала мені добрий старт. Коли я завантажив всю базу даних в Power BI, я зміг визначити, що деякі таблиці були пов’язані з більшою кількістю таблиць, ніж інші.

Знаючи це, я вирішив розпочати документацію, розділяючи Fact Tables від Dimension Tables Загалом, згідно з ChatGPT: «Факт-таблиця зазвичай містить зовнішні ключі, які з’єднують її з таблицями-розмірами, які надають додаткову описову інформацію про факти».

Перш ніж йти далі, мені треба пояснити, чому я прийняв це рішення: зіркова схема.

В схемі «Зірка/Сніжинка» Факт-таблиця з’єднана з Таблицями-вимірами(Dimension), тобто таблиці, які мають найбільшу кількість зв’язків в Power BI, повинні бути Факт-таблицями, а ті, які мають найменше, повинні бути Таблицями-вимірами.

Тепер я пам’ятаю, як я відреагував, коли зрозумів розмір зусиль, які потрібні були, і це стосувалося не лише мене, а й багатьох людей в компанії.

“Завдання, надане, завдання виконане”

По-перше, інструменти:

1. Google Big Query (SQL) (сотні тисяч запитів)
2. Power BI
3. Google Docs
4. Diagrams.net (який можна пов’язати з Google Docs)

На той момент ми знали (ІТ-сектор, керівництво на всіх рівнях), що всякий проект залежить від моєї “місії”. Щастям було те, що їхнє усвідомлення було надзвичайно корисним для мене, оскільки “ми”, як організація, були цілком спрямовані на досягнення єдиної мети, і це було досить унікальним моментом у моєму житті.

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

В самий час, коли все було готово для початку процесу документування.

По-перше, я почав шукати всі таблиці фактів, які я міг ідентифікувати. Спочатку я не зміг правильно ідентифікувати всі з них, але мені вдалося розпізнати 4 основні таблиці, які я позначив як table_a, table_b, table_c і table_d.

Ці таблиці представляють основний бізнес нашої компанії і містять всю інформацію, яка була необхідна для безлічі проектів, що були зупинені.

Після “підтвердження ID” я міг продовжити і пов’язати їх із відповідними таблицями вимірювань.

Але з’явилася ще одна проблема. До цих 4 таблиць було пов’язано понад 100 таблиць-вимірами, і, щоб було ще важче, номенклатура більшості таблиць була абсолютно нестандартизованою. Для прикладу: table_b.random_variable не відповідає таблиці вимірювань, яка називається “random_variable”, лише декілька таблиць мають стандартизовану номенклатуру, як table_b.variable_abc відповідно до таблиці variable_abc.

Спочатку, щоб перевірити, чи правильно зв’язані таблиці, я спробував визначити, чи всі значення в таблиці вимірювань є в таблиці фактів, але багато значень були покинуті або видалені з таблиці вимірювань, що призвело мене до багатьох помилок, і тоді я спробував інший підхід. Я почав запитувати звіти з програми “ABC” і почав їх підтверджувати.

Було багато інших таблиць, для яких потрібні були відеоконференції з різними людьми з різними знаннями з різних секторів у компанії.

Документування 4 основних таблиць бази даних дозволило нам (компанії) рухати деякі проекти вперед, але база даних далеко не була належним чином задокументованою.

Весь цей процес зайняв практично 2 місяці роботи з повним відданням (9 годин на день, 5 днів на тиждень).

Таблиці фінансів

З операційною областю документованою (не на 100%, як я вже сказав), мені було призначено нове завдання, і найважче: документувати фінансові таблиці. Спочатку це, здається, було легко, але з часом це перетворилося на кошмар складності.

Коли мені було доручено це завдання, я вже знав, які таблиці відносяться до фінансів.

Потім я повторив той самий процес, який я робив раніше: звіти, відеодзвінки, перевірка та так далі і так далі…

Чудово, але фінанси і так – складна галузь, так от, після року можна підсумувати: є 2 основні таблиці, які я назву fin_1 та fin_2. Таблиці fin_1 і fin_2 – це практично одне й те саме, майже однакові стовпці, ті самі таблиці-вимірники… майже все однакове, і обидві активні. Ви можете запитувати: чому? … Ну, я не знаю. Але це, як воно працює. Ми змогли розібратися і сьогодні це працює ідеально.

Підсумовуючи

Для документування основ мало фінансів і операцій мені знадобилося 3 місяці роботи, але лише у грудні 2022 року я нарешті надав те, що було обіцяно в березні/травні 2022 року через інші термінові вимоги, які врешті-решт виникли для мене.

Сьогодні сам документ слідує тій самій структурі, яку я створив тоді. Я вважаю, що приблизно 95% бази даних належним чином задокументовано в документі Google Docs на 50 сторінках, з десятками діаграм, які посилаються на сотні таблиць-розмірів до таблиць фактів, пояснюючи у тексті, які це колонки, іноземні ключі, яку інформацію вони несуть і багато іншої “структурної” інформації про базу даних.

База даних змінюється майже щомісяця, і оновлення вносяться до документації як тільки будь-які дані, таблиця і/або інформація додаються до нашої бази даних.

Особлива подяка

Я хотів би подякувати кожній людині (я вважаю, що їх було аж до 50), яка допомагала мені у цьому проекті, який ще триває. Цей проект є значущим етапом у моїй професійній кар’єрі.

ОРИГІНАЛ СТАТТІ:How I Documented an Entire Database From Scratch (Without DB Diagram)

АВТОР СТАТІ:Igor Comune

Долучайтесь до нашої спільноти Telegram
* Data Life UA
* Data Analysis UA
* DATA ENGINEERING UA
Долучайтесь до нашої спільноти FaceBook
* Data-Life-UA