Od historii użytkownika do schematu bazy danych: metoda wspierana przez AI

Co budujesz: schemat zgodny z rzeczywistą pracą

Schemat bazy danych to plan, jak twoja aplikacja będzie pamiętać rzeczy. W praktyce to:

• Tabele: „pojemniki” informacji (Customers, Orders, Tickets)
• Pola (kolumny): detale, które przechowujesz o każdym obiekcie (customer_name, order_date)
• Relacje: jak pojemniki się łączą (Order należy do jednego Customer; Customer może mieć wiele Orders)

Gdy schemat odzwierciedla rzeczywistą pracę, pokazuje to, co ludzie faktycznie robią — tworzą, przeglądają, zatwierdzają, planują, przypisują, anulują — zamiast tego, co ładnie wygląda na tablicy.

Dlaczego zaczynać od historii użytkownika?

Historie użytkownika i kryteria akceptacji opisują realne potrzeby prostym językiem: kto co robi i co oznacza „zrobione”. Jeśli użyjesz ich jako źródła, schemat rzadziej pominie kluczowe szczegóły (np. „musimy śledzić, kto zatwierdził zwrot” lub „rezerwację można wielokrotnie przeplanować”).

Zaczynanie od historii też pomaga kontrolować zakres. Jeśli czegoś nie ma w historiach (lub w workflow), traktuj to jako opcjonalne, zamiast budować skomplikowany model „na zapas”.

Co AI może, a czego nie może

AI może przyspieszyć pracę przez:

• Wyodrębnienie kandydackich encji (ważne „rzeczy” w historiach)
• Sugerowanie pól wynikających z kryteriów akceptacji (timestampy, statusy, referencje)
• Wykrywanie prawdopodobnych relacji i braków („wspominasz o zatwierdzeniach, ale nie zapisujesz approver`a”)

AI nie potrafi niezawodnie:

• Znać ukrytych reguł biznesowych lub przypadków brzegowych, których nie opisałeś
• Wybrać „odpowiedniego” poziomu szczegółowości bez kompromisów (proste vs elastyczne)
• Zagwarantować, że schemat spełni wymagania raportowania, bezpieczeństwa czy zgodności

Traktuj AI jako silnego asystenta, nie decydenta.

Jeśli chcesz zamienić tego asystenta w tempo pracy, platforma vibe-coding jak Koder.ai może pomóc przejść od decyzji schematu do działającej aplikacji React + Go + PostgreSQL szybciej — przy zachowaniu kontroli nad modelem, ograniczeniami i migracjami.

Ustal oczekiwania: iteracyjnie, nie jednorazowo

Projekt schematu to pętla: szkic → test przeciw historiom → znalezienie braków → poprawka. Celem nie jest idealny pierwszy rezultat, lecz model, do którego możesz odtworzyć każdą historię użytkownika i pewnie powiedzieć: „Tak, możemy zapisać wszystko, czego wymaga ten workflow — i potrafimy wyjaśnić, po co istnieje każda tabela.”

Wejścia: historie użytkownika, kryteria akceptacji i rzeczywiste przykłady

Zanim zamienisz wymagania na tabele, upewnij się, co modelujesz. Dobry schemat rzadko zaczyna się od pustej kartki — zaczyna się od konkretnej pracy, którą ludzie wykonują oraz dowodów, które będziesz potrzebować później (ekrany, outputy, przypadki brzegowe).

Typowe wejścia, które warto zebrać w jednym miejscu

Historie użytkownika to nagłówek, ale same w sobie nie wystarczą. Zbierz:

• Historie użytkownika + role (kto co robi i dlaczego)
• Kryteria akceptacji (reguły „musi być prawdą”)
• Formularze/ekrany (pola, które użytkownicy wpisują, wybierają lub widzą)
• Raporty/eksporty (co trzeba podsumować, grupować, filtrować)
• Rzeczywiste przykłady (przykładowe zamówienia, faktury, zgłoszenia, kalendarze — cokolwiek reprezentatywne)

Jeśli korzystasz z AI, te wejścia utrzymają model przy ziemi. AI szybko zaproponuje encje i pola, ale potrzebuje realistycznych artefaktów, by nie wymyślać struktury niepasującej do produktu.

Kryteria akceptacji: ukryte źródło ograniczeń

Kryteria akceptacji często zawierają najważniejsze reguły bazy danych, nawet jeśli nie mówią wprost o danych. Szukaj stwierdzeń jak:

• „Email musi być unikalny” (unikatowość)
• „Status może być Draft, Submitted, Approved” (dozwolone wartości)
• „Tylko menedżerowie mogą zatwierdzać” (uprawnienia, prawdopodobnie pola audytu)
• „Nie można usunąć faktury z płatnościami” (reguły referencyjne)

Typowe pułapki do naprawy wcześnie

Niejednoznaczne historie („Jako użytkownik mogę zarządzać projektami”) kryją w sobie wiele encji i przepływów. Częstym ubytkiem są też pominięte przypadki brzegowe: anulowania, ponowienia, częściowe zwroty, przypisania.

Szybka lista kontrolna jakości historii (przed modelowaniem)

• Aktor/rola jest wyraźnie określony.
• Obiekt jest konkretny (nie „dane” czy „rzeczy”).
• Istnieje przynajmniej jeden realny przykład.
• Kryteria akceptacji zawierają walidacje i granice.
• Przypadki błędów i „co jeśli” są wspomniane (albo wyraźnie odłożone).

Krok 1 — Wyodrębnij encje z historii (rzeczowniki)

Zanim pomyślisz o tabelach czy diagramach, przeczytaj historie użytkownika i podkreśl rzeczowniki. W pisaniu wymagań rzeczowniki zwykle wskazują na „rzeczy”, które system musi zapamiętać — to często stają się encjami w schemacie.

Krótki model mentalny: rzeczowniki → encje, czasowniki → akcje/ workflowy. Jeśli historia mówi „Menedżer przypisuje technika do zadania”, prawdopodobne encje to manager, technician i job — a „przypisuje” wskazuje relację do zamodelowania później.

Jak ocenić, czy rzeczownik to prawdziwa encja

Nie każdy rzeczownik zasługuje na osobną tabelę. Rzeczownik jest dobrym kandydatem na encję, gdy:

• Ma własną tożsamość: możesz wskazać konkretny egzemplarz (Job #1042, Customer A).
• Zmienia się w czasie: ma lifecycle (zadanie przechodzi z scheduled → completed).
• Jest używany w wielu miejscach: kilka historii się do niego odwołuje lub wiele workflowów go dotyka.

Jeśli rzeczownik pojawia się tylko raz lub opisuje coś innego („czerwony przycisk”, „piątek”), może nie być encją.

Atrybut czy osobna encja (test „Adres” i „Tag”)

Częsty błąd to zamienianie każdego szczegółu w tabelę. Reguła praktyczna:

• Jeśli to jedna wartość opisująca rzecz, zwykle to atrybut (np. Customer.phone_number).
• Jeśli to powtarzalne, wspólne lub złożone, to prawdopodobnie osobna encja.

Dwa klasyczne przykłady:

• Adres: jeśli przechowujesz adresy wysyłkowe i rozliczeniowe, trzymasz historię albo współdzielisz adresy między klientami/lokalizacjami, Address prawdopodobnie jest encją. Jeśli potrzebujesz tylko jednego adresu do korespondencji i nigdy go nie współdzielisz, może zostać jako atrybuty.
• Tag: tagi są niemal zawsze osobną encją, bo są powtarzalne i wiele-do-wielu (jedno Job ma wiele Tagów; jeden Tag dotyczy wielu Jobów).

Korzystanie z AI do sugerowania encji (ostrożnie)

AI może przyspieszyć wykrywanie encji, skanując historie i zwracając szkic listy rzeczowników pogrupowanych tematycznie (osoby, elementy pracy, dokumenty, lokalizacje). Przydatny prompt: „Wyodrębnij rzeczowniki, które reprezentują dane, które musimy przechować, i pogrupuj duplikaty/synonimy.”

Traktuj wynik jako punkt startu, nie odpowiedź. Zadaj pytania uzupełniające:

• „Które z nich mają lifecycle lub potrzebują własnego ID?”
• „Które to tak naprawdę statusy, kategorie lub atrybuty?”
• „Czy są synonimy (np. ‘client’ vs ‘customer’)?”

Celem Kroku 1 jest krótka, czysta lista encji, którą potrafisz obronić, odwołując się do realnych historii.

Krok 2 — Zamień szczegóły na pola (co musisz zapisać)

Gdy nazwiesz encje (np. Order, Customer, Ticket), kolejnym zadaniem jest uchwycenie szczegółów, które będą potrzebne później. W bazie te szczegóły to pola (zwane też atrybutami) — przypomnienia, których system nie może zapomnieć.

Jak wybierać pola (bez zgadywania)

Zacznij od historii użytkownika, potem czytaj kryteria akceptacji jak listę kontrolną tego, co musi być zapisane.

Jeśli wymóg mówi „Użytkownicy mogą filtrować zamówienia po dacie dostawy”, to delivery_date nie jest opcjonalne — musi istnieć jako pole (albo dać się wiarygodnie wyliczyć z innych zapisanych danych). Jeśli mówi „Pokaż kto zatwierdził żądanie i kiedy”, prawdopodobnie potrzebujesz approved_by i approved_at.

Praktyczny test: Czy ktoś będzie potrzebował tej wartości do wyświetlenia, wyszukania, posortowania, audytu lub obliczeń? Jeśli tak, prawdopodobnie to pole.

Proste reguły dla czystych pól

• Trzymaj wartości atomowymi: przechowuj „First name” i „Last name” osobno, jeśli będziesz po nich wyszukiwać lub sortować. Unikaj pakowania wielu wartości do jednego pola (np. „red, blue”).
• Używaj spójnych typów: daty jako daty, pieniądze jako decimal, boolean jako true/false — nie mieszaj formatów jak „$10”, „10 USD”, „10”.
• Unikaj duplikowania tekstów: nie kopiuj adresu klienta do każdego wiersza pozycji zamówienia. Przechowuj raz w odpowiednim miejscu i referencjęj.

Słownictwa kontrolowane: statusy, typy i kategorie

Wiele historii używa słów jak „status”, „type” czy „priority”. Traktuj je jako słowniki kontrolowane — ograniczony zestaw dozwolonych wartości.

Jeśli zestaw jest mały i stabilny, prosty enum wystarczy. Jeśli może rosnąć, wymaga etykiet lub uprawnień (np. admin zarządza kategoriami), użyj osobnej tabeli lookup (np. status_codes) i przechowuj referencję.

To sposób, w jaki historie zamieniają się w pola, którym można ufać — wyszukiwalne, poddane raportowaniu i trudne do błędnego wprowadzenia.

Krok 3 — Połącz encje relacjami

Gdy wymienisz encje (User, Order, Invoice, Comment itd.) i zrobisz szkic ich pól, kolejnym krokiem jest ich połączenie. Relacje to warstwa „jak te rzeczy się ze sobą komunikują” wynikająca z twoich historii.

Trzy kształty relacji (po ludzku)

Jeden-do-jednego (1:1) oznacza „jedna rzecz ma dokładnie jedną inną rzecz”.

• Fraza w historii: „Każdy użytkownik ma jeden profil.”
• Model: User ↔ Profile (często można je połączyć, chyba że jest dobry powód, by trzymać osobno).

Jeden-do-wielu (1:N) oznacza „jedna rzecz może mieć wiele innych”. To najczęstsze.

• Fraza: „Użytkownik może mieć wiele zamówień.”
• Model: User → Order (przechowaj user_id w Order).

Wiele-do-wielu (M:N) oznacza „wiele rzeczy może odnosić się do wielu rzeczy”. Wymaga dodatkowej tabeli.

• Fraza: „Zamówienie może zawierać wiele produktów, a produkt może być w wielu zamówieniach.”

M:N: trik z tabelą łączącą

Bazy danych źle radzą sobie z przechowywaniem „listy product ID” wewnątrz Order. Zamiast tego stwórz tabelę łączącą, która reprezentuje relację.

Przykład:

• Order
• Product
• OrderItem (tabela łącząca)

OrderItem zwykle zawiera:

• order_id
• product_id
• dodatkowe szczegóły z historii jak quantity, unit_price, discount

Zauważ, że szczegóły z historii („quantity”) często należą do relacji, nie do którejkolwiek encji.

Wymagane vs. opcjonalne (bez żargonu)

Historie mówią też, czy powiązanie jest konieczne, czy czasami brakujące.

• „Zamówienie musi należeć do użytkownika” → każde Order potrzebuje user_id (nie pozwól na puste).
• „Użytkownik może mieć numer telefonu” → phone może być pusty.
• „Zamówienie może mieć adres wysyłki (dla towarów fizycznych)” → shipping_address_id może być puste dla produktów cyfrowych.

Szybka zasada: jeśli historia sugeruje, że nie można stworzyć rekordu bez powiązania, traktuj je jako wymagane. Jeśli pojawiają się słowa „może”, „może być”, traktuj jako opcjonalne.

Przepisz zdania historii na zdania relacyjne

Gdy czytasz historię, przepisz ją jako proste sparowanie:

• „Użytkownik może zostawić wiele komentarzy” → User 1:N Comment
• „Komentarz należy do jednego użytkownika” → Comment N:1 User

Zrób to dla każdej interakcji w historiach. Na końcu będziesz mieć połączony model odpowiadający temu, jak praca faktycznie przebiega — zanim w ogóle otworzysz narzędzie do diagramów ER.

Krok 4 — Użyj workflowów, aby znaleźć stany, zdarzenia i luki

Historie mówią, co ludzie chcą. Workflowy pokazują, jak praca faktycznie przechodzi krok po kroku. Przetłumaczenie workflowu na dane to najszybszy sposób, by wykryć „zapomnieliśmy to zapisać” — zanim cokolwiek zbudujesz.

Zacznij od prostego workflowu

Zapisz workflow jako sekwencję akcji i zmian stanu. Na przykład:

• Create request → Draft
• Submit request → Submitted
• Manager reviews → Approved or Rejected
• If approved, work is scheduled → In progress
• Completed → Done

Te pogrubione słowa często stają się polem status (lub małą tabelą „state”) z jasnymi dozwolonymi wartościami.

Workflowy odsłaniają brakujące pola

Przechodząc przez każdy krok, zapytaj: „Co musielibyśmy wiedzieć później?” Workflowy zwykle ujawniają pola takie jak:

• znaczniki czasu: submitted_at, approved_at, completed_at
• własność: created_by, assigned_to, approved_by
• powód/kontekst: rejection_reason, approval_note
• kolejność: sequence dla wieloetapowych procesów

Jeśli workflow obejmuje oczekiwanie, eskalację lub przekazanie, zwykle potrzebujesz przynajmniej jednego znacznika czasu i pola „kto to teraz ma”.

Workflowy ujawniają brakujące tabele

Niektóre kroki workflowu to nie tylko pola — to oddzielne struktury danych:

• Audit log/history dla „kto zmienił status kiedy”
• Approvals przy wieloosobowych lub warunkowych regułach zatwierdzania
• Attachments gdy użytkownicy przesyłają pliki w kroku
• Comments gdy dyskusja jest częścią procesu

Używanie AI do sprawdzenia braków

Daj AI: (1) historie użytkownika i kryteria akceptacji oraz (2) kroki workflow. Poproś, by wypisało każdy krok i zidentyfikowało dane wymagane przy każdym (stan, aktor, znaczniki czasu, outputy), a następnie wyróżniło wymagania, których nie obsługuje obecny zestaw pól/tabel.

Na platformach takich jak Koder.ai taka „kontrola luk” jest praktyczna, bo możesz szybko iterować: dostosować założenia schematu, wygenerować scaffolding i ruszyć dalej bez ręcznego boilerplate.