[SQL][MySQL] Normalizacja baz danych do 3NF |
[SQL][MySQL] Normalizacja baz danych do 3NF |
6.01.2024, 19:03:42
Post
#1
|
|
Grupa: Zarejestrowani Postów: 1 Pomógł: 0 Dołączył: 6.01.2024 Ostrzeżenie: (0%) |
Witam serdecznie,
Przyszlo mi na "starosc" zmierzyc sie ze studiami (w UK - dlatego tez brak polskich znakow w poscie). Jednym z modulow sa bazy danych i wlasnie przy pracy zaliczeniowej utknalem w miejscu, ktore jest dla mnie niezbedne aby przejsc dalej (relacje itp). Czy znalazlby sie tutaj ktos doswiadczony, ktory moze sprawdzic i powiedziec mi czy to co do tej pory zrobilem trzyma sie kupy? Nie chce brnac dalej, jesli juz na starcie mam spory problem. Teoretycznie jest to wypozyczalnia ksiazek, w ktorej ma byc tracking kiedy takowa zostala wypozyczona, kiedy miala byc zwrocona i kiedy faktycznie zostala zwrocona. Nazwy kolumn w formie UNF zostaly mi narzucone. Czuje ze tutaj cos nie gra. 3NF jest zrobiona wlasciwie jakby na sile. Zakladam ze popelnilem gdzies blad i dalej w nim draze dalej choc powininem zaczac od poczatku. Z gory serdecznie dziekuje za wszelkie sugestie i pomoc. Ja delej z tym samym walcze i nie daje mi to spokoju. Ilosc materialu jaki przerobilem na internetach zarowno poslkich jak i angielski chyba tylko jeszcze bardziej narobil mi metliku w glownie niz pomogl. Moze wyjasnienie swojego toku rozumowania jakos pomoze wykryc w nim bledy. **UNF** - wypisuje wszystkie mozliwe "kolumny". **1NF** - Tutaj mam pierwsze schody. Wiem ze dane odnosnie transakcji nie powielaja sie. Kazda tranzakcja jest unikalna - zawiera tylko jedna date wypozyczenia, jedna informacje kiedy ma byc zwrocona i kiedy zostala zwrocona. Reszta danych odnosnie ksiazek i "klientow" moze sie powielac. Ksiazki moga byc wypozyczane wiele razy i klient moze wypozyczyc wiele ksiazek. Mialem problem z kluczem w drugiej tabelce - na studiach nacisk klada na klucze zlozone. Postawilem na zlozenie klucza TransactionID i BookID. W teorii juz tutaj moglem popelnic blad. Jednak na wsystkich wykladach (2 wykladowcow) wlasnie taki sposob stosowali. Nie do konca chyba go rozumiem i mozliwe ze zle go stosuje. **2NF** - rozbilem ta nieszczesna tabele z poprzedniego przykladu na 2 osobne. Jednak dla memberow, druga dla books. **3NF** - nie widzialem tutaj zadnych wiecej mozliwych danych ktore moglem rozbic na inne tabele. Zakladajac ze nie mam imion i nazwisk klientow (bo nie mam) nie wiem czy jest sens to rozbijac ich na dwie osobne tabele - jedna z adresem i numerem, druga z zainteresowaniami? Tak samo z ksiazkami. Teoretycznie moglbym to rozbic na kilka ale wszystkie by wygladaly na zasadzie BookID + BookName, BookID + Author, BookID+PublicationDate, BookID+Keywords. Wszystkie te cztery wartosci sa zalezne jedynie od BookID, a nie od siebie wzajemnie. Dodalem rowniez do Tabeli z transakcjami Book i Membre ID. Aby mozna je bylo ze soba powiazac. Co mi umyka? Co robie zle? Patrze na to i wiem ze czegos ewidentnie nie zrozumialem. |
|
|
6.01.2024, 19:20:25
Post
#2
|
|
Grupa: Moderatorzy Postów: 36 519 Pomógł: 6308 Dołączył: 27.12.2004 |
ostatni 3NF wyglada tak jak powinna wygladac poprawnie zaprojektowana baza.
A jak powinny wygladac te wszystkie numerki 1, 2 3 to nie wiem bo nigdy nie przykladalem uwagi do tego. -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
21.01.2024, 14:27:25
Post
#3
|
|
Grupa: Zarejestrowani Postów: 377 Pomógł: 70 Dołączył: 15.07.2014 Ostrzeżenie: (0%) |
Osobiście jeszcze takie zmiany bym wprowadził:
- Address jako osobna encja z linkiem do Member; // jeden użytkownik wiele adresów - Author jako osobna encja z linkiem do Book; // wiele książek jeden autor I wyjdzie tutaj jeszcze jedna encja: ShippingAddress. Będziesz mieć połączenie pomiędzy użytkownikiem i konkretnym adresem użytkownika. I możesz dodać też pole "phoneNumber" do kontaktu. Ten post edytował Salvation 21.01.2024, 14:33:07 |
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 08:22 |