Model logiczny bazy danych - biblioteka

Witam, potrzebuje wykonac projekt bazy danych dowolnego elementu rzeczywistosci. Wybralem model biblioteki.W zalozeniach projektowych musialobyc co najmniej 10 tabel. Utworzylem nastepujace relacje i tabele:

Czy ten model logiczny sie sprawdzi? Czy relacje zostaly dobrze zdefiniowane? Prosze o wskazanie ewentualnych bledow i porady, poniewaz chcialbym isc dalej z projektem ale nie jestem pewny tego modelu ( glownie chodzi o relacje ).

Eeee.... co to za tabelka dane_logowania? Czym to jest połączone z innymi tabelkami?

Zrób sobie nadrzędną tabelkę user, która będzie posiadać wspólne dane dla wszystkich rodzajów użytkowników. A tabelki czytelnik, pracownik i admin będą z niej korzystać.

To tabela zawierajace dane do logowania online przez strone. Polaczona relacja 1:1 z tabelami PRACOWNIK oraz CZYTELNIK.

sc4mp napisał(a):

To tabela zawierajace dane do logowania online przez strone. Polaczona relacja 1:1 z tabelami PRACOWNIK oraz CZYTELNIK.

Ale czym połączona? Do czego odnosi się kolumna login? Jak dla mnie bez sensu. Ja bym to wrzucił do tabelki user.

serek napisał(a):

Eeee.... co to za tabelka dane_logowania? Czym to jest połączone z innymi tabelkami?

Zrób sobie nadrzędną tabelkę user, która będzie posiadać wspólne dane dla wszystkich rodzajów użytkowników. A tabelki czytelnik, pracownik i admin będą z niej korzystać.

I do kazdej z tych tabelek dodac ID_user ?

sc4mp napisał(a):

I do kazdej z tych tabelek dodac ID_user ?

No raczej^^

Możesz też pozbyć się tabelki administrator, bo póki co nic ciekawego w niej nie ma. A zamiast tego w tabelce user możesz dodać kolumnę role, w której będziesz zaznaczał, czy user jest administratorem, klientem, czy pracownikiem.

W przypadku książki zrezygnowałbym z pola czy_dostępna, a dodał liczbę wszystkich egzemplarzy (wliczając wypożyczone). Wtedy wiesz dodatkowo ile jest maksymalnie książek, a ile zostało (gdy odejmiesz liczbę wypożyczonych).

Model wyglada aktualnie tak:
Dodalem tabele uzytkownik zamiast dane_logowania i przerzucilem tam dodatkowo pola takie jak telefon czy e-mail. Dostawca zostal rowniez podpiety pod tabele uzytkownik. Administrator zostal usuniety a do uzytkownika dodalem role. Czy ktos chcialby sie jeszcze podzielic uwagami? ;)

Czy relacje pomiedzy CZYTELNIK FILIA PRACOWNIK DOSTAWCA a ADRES oraz CZYTELNIK PRACOWNIK DOSTAWCA a UZYTKOWNIK powinna byc relacja 1:1 czy moze M:N?

Jeśli chodzi o userów, to 1:1. W przypadku reszty, to nie wiem, ale dałbym też 1:1.

Masz teraz duplikację pól w userze, pracowniku i czytelniku.

O jakich duplikacjach pol mowisz? Chodzi o LOGIN ? Pelni on role klucza obcego w pozostalych tabelach zamiast ID_USER, poniewaz i tak musi byc unikatowy dla kazdego uzytkownika.

Ilość i termin_dostawy nie powinien być u dostawcy.
Trzymanie informacji o samochodzie dostawcy to chyba za dużo jak na DB biblioteki.
Zamiast dostawcy to zamówienie może się łączyć z filią.
Z zamówienia można oddzielić pozycje na zamówieniu (nie mam pomysłu jak to nazwać).

Delor napisał(a):

Ilość i termin_dostawy nie powinien być u dostawcy.
Trzymanie informacji o samochodzie dostawcy to chyba za dużo jak na DB biblioteki.
Zamiast dostawcy to zamówienie może się łączyć z filią.
Z zamówienia można oddzielić pozycje na zamówieniu (nie mam pomysłu jak to nazwać).

FILIA do ZAMOWIENIE ale DOSTAWCA nadal do ZAMOWIENIE, zgadza sie ?

Tak.
Termin dostawy do zamówienia a ilość i id książki do nowej tabelki (połączonej z zamówieniem).

Delor napisał(a):

Tak.
Termin dostawy do zamówienia a ilość i id książki do nowej tabelki (połączonej z zamówieniem).

I wtedy polaczyc KSIAZKA z ta tabela, ktora jest polaczana z zamowieniem, powiedzmy: POZYCJA_ZAMOWIENIA ?
Miedzy ZAMOWIENIE a POZYCJA_ZAMOWIENIA relacja 1:N ?

Mysle ze juz ostatnie pytanie: relacja miedzy KSIAZKA a POZYCJA_ZAMOWIENIA rowniez bedzie 1:N ?