[SQL][MySQL] Normalizacja baz danych do 3NF Opcje

[Pampude]

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.

[nospor]

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.

[Salvation]

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