Normalizacja baz danych - potrzebuje porady

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.

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. :(

Pierwsza postać eliminację powtarzalności danych. Dane w kolumnie muszą być atomowe. Tu ciężko powiedzieć jakie masz dane w kolumnach na podstawie samych nazw.
Zobacz sobie tutaj: https://www.sqlpedia.pl/projektowanie-i-normalizacja-bazy-danych/
Rozbito tu adres na kolumny ulica, województwo. Jakie masz dane w kolumnach? Musisz tam szukać co masz rozbić.
Np. podejrzana kolumna to Keywords.

Witam, dziękuję za odpowiedź ;)

Jedyne dane jakie mamy narzucone to 30 wierszy dla tabeli Transakcji - dlatego są w niej takie a nie inne kolumny (MemberID, BookID, itp.) Reszte bede musiał sam sobie wymyślić i podstawić. O wiele łatwiej na wyobraźnię działałoby posiadanie już gotowego zestawu danych.

Myślałem nad rozbiciem adresu. Jest to właściwie wystarczająco danych aby utworzyć nową tabele, i dodac coś na zasadzie AdresID do tabeli z Members. Ale czy taki zabieg ma sens? Nie wnosi chyba nic do jej funkcjonalnosci. Z drugiej strony tworzy się zależność Kod pocztowy -> miasto. Łeb mi już od tego pęka :(

Pampude napisał(a):

Myślałem nad rozbiciem adresu. Jest to właściwie wystarczająco danych aby utworzyć nową tabele, i dodac coś na zasadzie AdresID do tabeli z Members. Ale czy taki zabieg ma sens? Nie wnosi chyba nic do jej funkcjonalnosci.

Ma sens, to są właśnie dane atomowe. Masz kolumny osobne dla: kod pocztowy, miasto, ulica, nr domu.

Pampude napisał(a):

Z drugiej strony tworzy się zależność Kod pocztowy -> miasto. Łeb mi już od tego pęka :(

Gdzie niby masz tą zależność? Nie ma jej.

No i na podstawie tych 30 wierszy masz wszystko rozbić na początek na 1NF.
Rozbicie adresu z jednej kolmuny z postaci:
Gdańsk Stoczniowców 12 99-100
na kilka kolumn: miasto, ulica, kod pocztowy to właśnie prawidłowe działanie.
Dlatego dałem przykład u Ciebie z Keywords bo widać tu liczbę mnogą co sugeruje w obrębie tej kolumny więcej niż jedną daną. Jeśli dane się powtarzają i jest ich wiele w jednej kolumnie czyli masz np.
horror, strach, krew,
horror, krew,
thriller, krew
To widzisz że to są powtarzalne dane które można i trzeba rozbić.

A co w takim razie z keywords do books? Słowa kluczowe opisujące dana książkę. Teoretycznie mogę tam sam podstawić jedno słowo i będą to dane atomowe. Logiczne wydaje się że tych słów może być więcej (tak jak jurek1980 napisał), ale chyba będę musiał iść po linii najmniejszego oporu.

Bardzo Wam dziękuję. Jutro z rana zabieram się ponownie za robotę i będę walczył dalej ;)

No to pomyślmy. Masz kilka słów kluczowych. No to powiedzmy robijasz to na 3 kolmuny keyowrd1, keyword2, keyowrod3 I już widzisz, że ilość tych kolumn może być w sumie nieograniczona i coś jest nie tak.
No ale nic nie szkodzi by iść i wyodrębnić to do innej tabeli gdzie masz tylko kolumny id,keyword. Żeby potem połączyć taką książkę z tymi słowami kluczowymi potrzebujesz tabeli pośredniczącej która będzie trzymać book_id i keyword_id. I wtedy nie powielasz danych w przypadku słów kluczowych a jedna książka może mieć wiele słów kluczowych.

Poszedlem za Twoimi radami i przeksztalcilem to tak jak zrozumialem. Tworze obecnie diagram z relacjami i mam problem jak powiazac ta tabele posredniczaca za pomoca kluczy (PK i FK) oraz relacje jakie w niej wystepuja. Zalozylem ze trzy slowa keywords powinny wystarczyc - potem bede musial te slowa pouzupelniac jakimis danymi, dlatego tez boje sie ze w pewnym momencie rozbuduje sie to za bardzo i bede zmuszony spedzic grom czasu na uzupelnianiu tabeli.

Transaction (jedna do wielu) Members - jedna tranzakcja musi miec jednego uzytkownika, ale uzytkownik moze miec wiele transakcji
Members (jedna do wielu) Addresses - jeden uzytkownik moze miec jeden adres, ale moze byc wiele uzytkownikow pod jednym adresem
Transaction (jedna do wielu) Books - jeden tranzakcja odnosi sie jedynie do jednej ksiazki, ale ksiazki moga byc wiele razy wypozyczane i moga miec wiele tranzakcji

No i tutaj zaczely sie schody. Nie wiem czy nie dalem za wiele FK do tabeli posredniczacej, bo wlasciwie tutaj juz zglupialem. Ogolnie to bylaby to relacja wiele do wielu, ale z tego co wiem po to jest ta posredniczaca aby tego uniknac i wprowadzic relacje jedna do wielu i wiele do jednej.
Jedna ksiazka ma wiele slow kluczowych, slowa kluczowe moga opisywac wiele ksiazek.

Books (jedna do wielu) BooksKeywords - ale jak pomysle ze dojde do momentu kodowania kluczy PK i FK to mnie az ciarki biora.
BooksKeywords (wiele do jednej) Keywords - ale jak taka relacje zapisac skoro jedna Keyword_ID z tabeli jest pobierane az trzykrotnie w innej tabeli? Czy to co przedstawiam ponizej ma racje bytu? Czy cos nalezaloby zmienic?

Zabieram sie zaraz za fizyczny model ERD. Mam nadzieje ze powyzsze jest poprawne :D Nie chcialbym zaczynac od nowa ;(

Czuje ze brakuje mi wyobrazni albo tez wiedzy jak taka tabela laczaca powinna dzialac. Podejrzewam ze powinienem zastosowac tam nowe ID ktore bylo by PK, a w tej tabeli tylko dwie pozycje Book_ID i Keyword_ID jako FK. Ale nie jestem w stanie wyobrazic sobie jak fizycznie takie zastosowanie moze dzialac. ;(

Fizyczny model w takim razie wygladalby w ten sposob. Bardzo duzo pozycji zastrzeglem jako NOT NULL, co moze byc pozniej dla mnie strasznie problematyczne.

Chyba ze to tak powinno wygladac (czyzby nagle olsnienie?), Dwa FK, bo wlasciwie PK jest zbedny?:

Ostatni diagram wygląda dobrze. Co do tabeli z Keywords to dodaj PK pomimo iż nie do końca jest potrzebny.
Jeszcze wyodrębnił bym autora z książki. Jeden autor może mieć przecież wiele książek, czyli dane będą się powtarzać.