Naucz się praktycznej metody zamiany historii użytkownika, encji i workflowów w przejrzysty schemat bazy danych oraz jak rozumowanie AI pomaga wykryć luki i reguły.
Schemat bazy danych to plan, jak twoja aplikacja będzie pamiętać rzeczy. W praktyce to:
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.
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”.
AI może przyspieszyć pracę przez:
AI nie potrafi niezawodnie:
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.
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.”
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).
Historie użytkownika to nagłówek, ale same w sobie nie wystarczą. Zbierz:
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 często zawierają najważniejsze reguły bazy danych, nawet jeśli nie mówią wprost o danych. Szukaj stwierdzeń jak:
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.
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.
Nie każdy rzeczownik zasługuje na osobną tabelę. Rzeczownik jest dobrym kandydatem na encję, gdy:
Jeśli rzeczownik pojawia się tylko raz lub opisuje coś innego („czerwony przycisk”, „piątek”), może nie być encją.
Częsty błąd to zamienianie każdego szczegółu w tabelę. Reguła praktyczna:
Customer.phone_number).Dwa klasyczne przykłady:
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:
Celem Kroku 1 jest krótka, czysta lista encji, którą potrafisz obronić, odwołując się do realnych historii.
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ć.
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.
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.
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.
Jeden-do-jednego (1:1) oznacza „jedna rzecz ma dokładnie jedną inną rzecz”.
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.
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.
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:
OrderProductOrderItem (tabela łącząca)OrderItem zwykle zawiera:
order_idproduct_idquantity, unit_price, discountZauważ, że szczegóły z historii („quantity”) często należą do relacji, nie do którejkolwiek encji.
Historie mówią też, czy powiązanie jest konieczne, czy czasami brakujące.
Order potrzebuje user_id (nie pozwól na puste).phone może być pusty.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.
Gdy czytasz historię, przepisz ją jako proste sparowanie:
User 1:N CommentComment N:1 UserZró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.
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.
Zapisz workflow jako sekwencję akcji i zmian stanu. Na przykład:
Te pogrubione słowa często stają się polem status (lub małą tabelą „state”) z jasnymi dozwolonymi wartościami.
Przechodząc przez każdy krok, zapytaj: „Co musielibyśmy wiedzieć później?” Workflowy zwykle ujawniają pola takie jak:
submitted_at, approved_at, completed_atcreated_by, assigned_to, approved_byrejection_reason, approval_notesequence dla wieloetapowych procesówJeśli workflow obejmuje oczekiwanie, eskalację lub przekazanie, zwykle potrzebujesz przynajmniej jednego znacznika czasu i pola „kto to teraz ma”.
Niektóre kroki workflowu to nie tylko pola — to oddzielne struktury danych:
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.
Zacznij od historii i podkreśl rzeczowniki, które reprezentują rzeczy, które system musi zapamiętać (np. Ticket, User, Category).
Promuj rzeczownik do encji, gdy:
Trzymaj krótką listę, którą potrafisz uzasadnić, wskazując konkretne zdania z historii.
Użyj testu „atrybut vs. encja":
customer.phone_number).Szybła wskazówka: jeśli kiedykolwiek będziesz potrzebować „wiele z tego”, prawdopodobnie potrzebujesz osobnej tabeli.
Traktuj kryteria akceptacji jak listę kontrolną przechowywania. Jeśli wymóg mówi, że musisz filtrować/pokazywać/kontrolować coś, musisz to zapisać (albo dać się to wiarygodnie wyliczyć).
Przykłady:
approved_by, approved_atdelivery_datePrzepisz zdania z historii na zdania opisujące relacje:
customer_id w orders)order_items)Jeśli sama relacja ma dane (ilość, cena, rola), te dane należą do tabeli łączącej.
Modeluj M:N za pomocą tabeli łączącej, która przechowuje oba klucze obce plus pola specyficzne dla relacji.
Typowy wzorzec:
ordersproductsPrzejdź przez workflow krok po kroku i zapytaj: „Co musielibyśmy później udowodnić?”.
Typowe dodatki:
submitted_at, closed_atZacznij od:
id)orders.customer_id → customers.id)Następnie dodaj indeksy do najczęstszych zapytań (np. , , ). Odłóż spekulacyjne indeksowanie do czasu, aż zobaczysz realne wzorce zapytań.
Szybkie sprawdzenie spójności:
Phone1/Phone2, podziel na tabelę potomną.Denormalizuj później tylko z jasnym powodem (wydajność, raportowanie, snapshoty audytu) i zadokumentuj, co jest źródłem prawdy.
Przechowuj fakty, których nie da się wiarygodnie odtworzyć później; oblicz resztę.
Dobrze przechowywać:
Dobrze obliczać:
Jeśli przechowujesz wartości pochodne (np. ), zaplanuj jak będą synchronizowane i przetestuj przypadki brzegowe (zwroty, poprawki, częściowe wysyłki).
Używaj AI do szkiców, potem weryfikuj na podstawie swoich artefaktów.
Praktyczne zapytania:
Zasady bezpieczeństwa:
emailorder_items z order_id, product_id, quantity, unit_priceUnikaj przechowywania „listy ID” w jednej kolumnie — zapytania, aktualizacje i zapewnienie integralności stają się kłopotliwe.
created_by, assigned_to, closed_byrejection_reasonJeśli potrzebujesz „kto zmienił co i kiedy”, dodaj tabelę zdarzeń/audytu zamiast nadpisywać pojedyncze pole.
emailcustomer_idstatus + created_atorder_total