Projekt bazy danych - sklep mp3 Opcje

[Ive]

Witam, chciałem prosić o pomoc przy projekcie bazy danych. Ma to być coś a'la baza sklepu mp3. Zaprojektowałem już kawałek w MySQL Workbenchu ale nie do końca jestem pewien czy to ma być tak odwzorowane jak sobie to wyobraziłem x]

Link do bazy: http://www.tomwet.pl/ive/bd.png
I teraz opis słowny:
Tabela `song` która trzyma w sobie nazwę, cenę i id.
Tabela `artist`: nazwa, kraj, biografia.
Tabela `category`: id, id_parent, title
Tabela `album`: id, title
Tabela `fav_list`: id_listy, id_usera
Tabela `user`: /wszelkie dane dla usera mail, login, haslo, adresy, etc./
Tabela `shopping_cart` która będzie trzymała tymczasowo dane o songach w koszyku czyli id_zamowienia, id_songu
Tabela `order` /wszelkie dane teleadresowe do konkretnego usera, sposób zapłaty, ew. uwagi, status zamówienia/

Tabele mixujące nazwy za pomocą łącznika '_has_' innych tabel to oczywiście powiązanie n:m, inne powiązania to 1:n x]

I teraz tak: każda piosenka musi mieć przypisanego artystę. Każda piosenka może być przypisana do albumu /tylko do jednego/. Każda piosenka może być przypisana do wielu kategorii. Każda piosenka może się znaleźć na liście ulubionych każdego usera. Każda piosenka może się znaleźć w koszyku i każda może zostać zamówiona. Do każdej piosenki można dopisać komentarze.
Każdy album może być przypisany do wielu kategorii. Kategorie mogą mieć podkategorie.
Przypisanie kategorii do piosenki czy albumu /chociażby jednej jest konieczne/.
Każdy user może mieć jedną listę ulubionych.

Chodzi mi o to czy mógłby ktoś mi wskazać, czy ten model graficzny jest poprawny i odpowiada temu co tutaj zapisałem. Jeśli ktoś widzi błędy w samym projekcie to też proszę o wskazanie takich x]

Ten post edytował Ive 8.05.2011, 16:56:55

[zbig]

Witam ! Na pierwszy rzut oka nie podoba mi sie podwojne polaczenie song->category. Powinienes moim zdaniem zastosowac tylko jedna relacje song->album->category. Unikniesz w ten sposob nieporozumien, ktore moga byc generowane w polaczenieu song->category poniewaz to polaczenie uzyskasz analizujac album->category. Druga sprawa to brak polaczenie order i shopping_cart z userem. Taka relacja musi byc zaimplementowana bezwzglednie. A trzecia sprawa to nie zawsze potrzebne tabele realizujace polaczenie 1 to M , M to 1 . Ma to jedynie uzasadnienie w polaczeniu M to M. Mam na mysli np. category->category_has_album->album (no chyba , ze przewidujesz tan sam album w wielu kategoriach i kategoria posiada rozne albumy - polaczenie M to M) . Prosciej byloby chyba category->album, gdzie album mialby klucz obcy category_id. To tak na pierwszy rzut oka.

Pozdrawiam.

[Ive]

Witam,
dzięki za odpowiedź. Dopiero teraz przypadkiem zauważyłem, że ktoś dodał odpowiedź x]
Po pierwsze to wywaliłem połączenie category do album - kategorie można po prostu przeczytać poprzez wyciągnięcie kategorii piosenek przypisanych do albumu.
Połączenie order i shopping_cart z userem rzeczywiście, musi być x]
Jeśli chodzi o połączenia n:m to to, które wytknąłeś usunąłem. Chodziło mi tam o to, że album może właśnie być przypisany do kilku kategorii, no a sama kategoria wiadomo że może być przypisana do wielu albumów.

No to z nowych dodanych do tego diagramów połączeń to 1:m pomiędzy user i order /user może złożyć wiele zamówień, zamówienie musi być przypisane do jednego usera/ i pomiędzy user a shopping_cart identycznie 1:n.

Pozdrawiam i dzięki

Ten post edytował Ive 4.06.2011, 19:00:29