GoldenLine
Zaloguj się
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

Witam,
Uczę się właśnie tworzenia diagramów ER. Szukam w necie przykładów zaprojektowanych już diagramów i napotkałem na taki przykład zrobiony przez studenta (zrobiłem screen bo to pdf):


Obrazek


Zastanawiam się czy jest on dobrze zrobiony. Osobiście zrobiłbym to chyba trochę inaczej. Chciałbym uzyskać zdanie bardziej doświadczonych bazodanowców.
Link do wypowiedziLink
Grzegorz D.

Grzegorz D. PL/SQL Developer

Temat: Diagram ER - do sprawdzenia

Przeczytaj sobie chociażby wiki http://en.wikipedia.org/wiki/Entity-relationship_model i masz odpowiedź czy jest on dobrze zrobiony :)

Wg tego diagramu w magazynach trzymamy katalogi, i właśnie te katalogi sprzedajemy. Mamy nieopisane relacje, niepoprawną relację katalog-sprzedaż-faktury itd.
Link do wypowiedziLink
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

No z tymi katalogami trochę niefortunna nazwa (raczej chodziło o obuwie).
Natomiast odnośnie relacji katalog-sprzedaż-faktury to mam odczucie (zaznaczam odczucie), że powinno to być inaczej zrobione. Jednakże nie mam pomysłu jak to zrobić.

Mógłbym prosić o zaproponowanie swojej własnej inicjatywy?

EDIT:
No chyba, że tak to może wyglądać:
(taki mały pomysł mi wpadł - na szybko robione)


Obrazek
Michał Rodzynek edytował(a) ten post dnia 23.10.11 o godzinie 12:26
Link do wypowiedziLink

konto usunięte

Temat: Diagram ER - do sprawdzenia

Sprzedaż może dotyczyć wielu opakowań z butami, nie odwrotnie... Z opisu wynika, że tabela sprzedaż nie jest potrzebna. Tak samo jak tabla raty - wystarczy trzymać rejestr wpłat. Raty są wspomniane, żeby na jedną fakturę mogło być wiele wpłat.
Link do wypowiedziLink
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

@Michał - powiem szczerze, że myślałem tak od początku (tylko potem sugerowałem się zrobiony przykładem). Problem leży w tym, że nie mam za bardzo pomysłu na wygląd tego diagramu. Czytałem już różne rzeczy artykuły / wykłady na temat diagramów er i tam niby wszystko rozumiem, jednak przykłady jakie tam dają są banalnie prosto przedstawione.

Tutaj być może też jest to banalne, ale "nie widzę" tego jak połączyć ze sobą poszczególne relacje.

Powiem wprost - prosiłbym aby ktoś zaprezentował swój przykład diagramu dla tego zadania (przynajmniej ten kawałek z tą sprzedażą).
Link do wypowiedziLink
Leszek Rabek

Leszek Rabek IT Team Manager/IT
Designer/Analityk/Se
nior Developer

Temat: Diagram ER - do sprawdzenia

Michał Z.:
Sprzedaż może dotyczyć wielu opakowań z butami, nie odwrotnie... Z opisu wynika, że tabela sprzedaż nie jest potrzebna. Tak samo jak tabla raty - wystarczy trzymać rejestr wpłat. Raty są wspomniane, żeby na jedną fakturę mogło być wiele wpłat.


Według mnie tabela sprzedaż nie jest potrzebna, ale pozycje faktury należałoby użyć, zamiast sprzedaż - wtedy relacja OK. Dodatkowo relacja jedna faktura wiele pozycji faktury. Reszta jak powyżej Rejestr wpłat z relacją 1 faktura wiele wpłat. I tak najprościej będzie OK.
Link do wypowiedziLink

konto usunięte

Temat: Diagram ER - do sprawdzenia

Leszek Rabek:
Michał Z.:
Sprzedaż może dotyczyć wielu opakowań z butami, nie odwrotnie... Z opisu wynika, że tabela sprzedaż nie jest potrzebna. Tak samo jak tabla raty - wystarczy trzymać rejestr wpłat. Raty są wspomniane, żeby na jedną fakturę mogło być wiele wpłat.

Według mnie tabela sprzedaż nie jest potrzebna, ale pozycje faktury należałoby użyć, zamiast sprzedaż - wtedy relacja OK. Dodatkowo relacja jedna faktura wiele pozycji faktury. Reszta jak powyżej Rejestr wpłat z relacją 1 faktura wiele wpłat. I tak najprościej będzie OK.

W wymogach napisane było wyraźnie - faktura + historia wpłat. Jak coś by było np. o stanach magazynowych, albo o wystawianiu faktur - inna sprawa. No, albo jak byłby to system, który mam utrzymywać. :)
Tu sprawa jest prosta - jest zadanie i odpowiedź...
Link do wypowiedziLink
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

Michał Z.:
Sprzedaż może dotyczyć wielu opakowań z butami, nie odwrotnie... Z opisu wynika, że tabela sprzedaż nie jest potrzebna. Tak samo jak tabla raty - wystarczy trzymać rejestr wpłat. Raty są wspomniane, żeby na jedną fakturę mogło być wiele wpłat.


Ok, podjąłem się próby poprawienia. Nie wiem czy dobrze to zrozumiałem. Wyszło to tak:


Obrazek


A czy czasami między obuwie a faktura nie powinno być N:N. Bo w sumie wiele butów (nie koniecznie tych samych sztuk ale tego samego typu, rozmiaru, producenta itp) może być sprzedawane różnym klientom (chyba, że założymy że każde buty, mimo tych samych parametrów są traktowane osobno (mają inne id)).Michał Rodzynek edytował(a) ten post dnia 25.10.11 o godzinie 13:29
Link do wypowiedziLink
Leszek Rabek

Leszek Rabek IT Team Manager/IT
Designer/Analityk/Se
nior Developer

Temat: Diagram ER - do sprawdzenia

Michał Rodzynek:
Michał Z.:
Sprzedaż może dotyczyć wielu opakowań z butami, nie odwrotnie... Z opisu wynika, że tabela sprzedaż nie jest potrzebna. Tak samo jak tabla raty - wystarczy trzymać rejestr wpłat. Raty są wspomniane, żeby na jedną fakturę mogło być wiele wpłat.


Ok, podjąłem się próby poprawienia. Nie wiem czy dobrze to zrozumiałem. Wyszło to tak:


Obrazek


A czy czasami między obuwie a faktura nie powinno być N:N. Bo w sumie wiele butów (nie koniecznie tych samych sztuk ale tego samego typu, rozmiaru, producenta itp) może być sprzedawane różnym klientom (chyba, że założymy że każde buty, mimo tych samych parametrów są traktowane osobno (mają inne id)).

I właśnie dlatego powinna być encja z pozycjami faktury, gdyż dokładnie robi nam się relacja wiele do wielu. I tu będę w sprzeczności z Michałem niby nic nie było o stanach magazynowych itp., ale jeżeli tego nie zastosujemy to katalog obuwia i faktury mogą zostawać właśnie we wspomnianej relacji, i nie możemy podejść w ten sposób, że buty takie same mają mieć różne ID, gdyż co to za katalog by nam powstał - produkujemy 1000 po 1000 par z 10 rodzajów butów i już mamy 10000 różnych rekordów - bez sensu (a co jakbyśmy produkowali na rynek chiński ;) (a od strony technicznej jeszcze proszę mieć na uwadze postaci normalne ;). A i oczywiście ortograf na schemacie.
Link do wypowiedziLink
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

Rozumiem, czyli ten schemat mógłby tak zostać?

P.S. Z tym "obówiem" to tak z rozpędu ;p
Link do wypowiedziLink
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: Diagram ER - do sprawdzenia

Leszek Rabek:
...
I właśnie dlatego powinna być encja z pozycjami faktury, gdyż dokładnie robi nam się relacja wiele do wielu. I tu będę w sprzeczności z Michałem niby nic nie było o stanach magazynowych itp., ale jeżeli tego nie zastosujemy to katalog obuwia i faktury mogą zostawać właśnie we wspomnianej relacji, i nie możemy podejść w ten sposób, że buty takie same mają mieć różne ID, gdyż co to za katalog by nam powstał - produkujemy 1000 po 1000 par z 10 rodzajów butów i już mamy 10000 różnych rekordów - bez sensu (a co jakbyśmy produkowali na rynek chiński ;) (a od strony technicznej jeszcze proszę mieć na uwadze postaci normalne ;). A i oczywiście ortograf na schemacie.

Z tego co zauważyłem mówimy o modelu logicznym, tak więc nie ma problemu z zaznaczeniem relacji N:M pomiędzy obuwiem i fakturą. W modelu fizycznym relacja ta prawdopodobnie zostanie zrealizowana tabelą złączającą (łącznikowa). Natomiast encja magazyn powinna zawierać liczbę sztuk danego obuwia. Wtedy nie będzie problemu ze sprzedażą obuwia, którego nie ma w magazynie. Encja Rata moim zdaniem była w porządku.

Z grubsza diagram wygląda na ok, ale problem jest z tym, że sprzedajemy obuwie i umieszczamy go w Fakturze bez odwołania się do Magazynu. Dane o tym, z którego magazynu sprzedajemy powinny znaleźć się w encji Faktura (inna sprawa czy chcemy te dane umieszczać na "papierowej" fakturze). Inaczej nie unikniemy problemu sprzedaży obuwia, którego nie ma w magazynie.

Na koniec, w modelu logicznym nazwy encji powinny być w licznie pojedynczej, a w modelu fizycznym w liczbie mnogiej (tak jest w teorii, o praktykowaniu w polskich firmach rozwodzić się nie będę).
Link do wypowiedziLink
Leszek Rabek

Leszek Rabek IT Team Manager/IT
Designer/Analityk/Se
nior Developer

Temat: Diagram ER - do sprawdzenia

Aleksander Olszewski:
Leszek Rabek:
...
I właśnie dlatego powinna być encja z pozycjami faktury, gdyż dokładnie robi nam się relacja wiele do wielu. I tu będę w sprzeczności z Michałem niby nic nie było o stanach magazynowych itp., ale jeżeli tego nie zastosujemy to katalog obuwia i faktury mogą zostawać właśnie we wspomnianej relacji, i nie możemy podejść w ten sposób, że buty takie same mają mieć różne ID, gdyż co to za katalog by nam powstał - produkujemy 1000 po 1000 par z 10 rodzajów butów i już mamy 10000 różnych rekordów - bez sensu (a co jakbyśmy produkowali na rynek chiński ;) (a od strony technicznej jeszcze proszę mieć na uwadze postaci normalne ;). A i oczywiście ortograf na schemacie.

Z tego co zauważyłem mówimy o modelu logicznym

Fakt zapędziłem się nieco.
Link do wypowiedziLink
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

Witam,
Byłem dzisiaj u swojego profesora z takim diagramem:

http://oi39.tinypic.com/t7mt5y.jpg

Diagram przejrzał na szybko i skwitował tak: "Tutaj, w tym przypadku aż się prosi zastosować dodatkową encję POZYCJA_FAKTURY, która w dodatku będzie encją słabą" i przerobił mój diagram tak:

http://oi42.tinypic.com/2j3g07q.jpg

Dodatkowo dodał, że mógłby zostać zasotosowany rejestr wpłat (bo tutaj jest trochę okrężna droga).

Widzę w tym pewną logikę (bo zastępuje to tak jakby wcześniejszą tabelę sprzedaż. Ale nie rozumiem jaką funkcję ma spełniać pozycja faktury. O jaką pozycję chodzi?)

P.S. Aha, i czy w ogóle zgadzacie się z tą odpowiedzią (rozwiązaniem), którą dzisiaj otrzymałem?
Link do wypowiedziLink
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: Diagram ER - do sprawdzenia

Michał Rodzynek:
Witam,
Byłem dzisiaj u swojego profesora z takim diagramem:

http://oi39.tinypic.com/t7mt5y.jpg

Diagram przejrzał na szybko i skwitował tak: "Tutaj, w tym przypadku aż się prosi zastosować dodatkową encję POZYCJA_FAKTURY, która w dodatku będzie encją słabą" i przerobił mój diagram tak:

http://oi42.tinypic.com/2j3g07q.jpg

Dodatkowo dodał, że mógłby zostać zasotosowany rejestr wpłat (bo tutaj jest trochę okrężna droga).

Widzę w tym pewną logikę (bo zastępuje to tak jakby wcześniejszą tabelę sprzedaż. Ale nie rozumiem jaką funkcję ma spełniać pozycja faktury. O jaką pozycję chodzi?)

P.S. Aha, i czy w ogóle zgadzacie się z tą odpowiedzią (rozwiązaniem), którą dzisiaj otrzymałem?

W sumie poprawki słuszne :) Relacja nie może mieć atrybutów. Na marginesie, relację wiele do wiele oznacza się M:N (było N:N, co sugeruje tą samą liczebność). Pozycja faktury jak najbardziej ma sens, ale ona wynika z kontekstu, który nie został umieszczony w opisie słownym (może coś było na wykładach?). Taka pozycja może np. spinać wiele magazynów i butów na jednej fakturze lub ułatwiać ilościowe badanie sprzedarzy.

Jeśli chodzi o moje uwagi, to ja bym osobiście nie umieszczał liczby butów w encji obuwie, bo wtedy baza nie będzie w 3NF: liczba par obuwia zależy funkcyjnie od Magazynu a nie od Buta. Tak więc trochę diagram bym przebudował.
Link do wypowiedziLink
Michał Rodzynek

Michał Rodzynek Student, UAM

Temat: Diagram ER - do sprawdzenia

@Aleksander O. - dzięki za odpowiedzi. Z tymi atrybutami i relacjami to racja (nie doczytałem wcześniej tego dokładnie).

Ogólnie teraz lepiej to widzę, jeszcze raz dzięki.
Pozdrawiam (na tym chyba na razie zakończe)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Diagram E/R




Wyślij zaproszenie do
Anuluj