projektowanie bazy danych - Diagram Zwiazkow Encji

0

Chce narysowac Diagram Związków Encji (Entity Relationship Diagram), ktore potem moze zostac uzyty do stworzenia bazy danych.
Tutaj mozna troche o tym poczytac: http://pl.wikipedia.org/wiki/Diagram_zwi%C4%85zk%C3%B3w_encji
Korzystam z notacji Chen'a, czyli takiej jak na przykladowym rysunku z Wikipedii.

Czy ktos moze potwierdzic, czy zalaczony ponizej diagram ktory stworzylem jest poprawny, tj:

  1. Czy utworzone relacje sa poprawne?
  2. Czy wszystkie atrybuty sa dobrze oznaczone?
  3. Czy opcjonalne i obowiazkowe polaczenia sa dobrze oznaczone?
  4. Czy OCENA - jako slaba encja i PRZEDMIOT jako identyfikujaca ja encja sa poprawne?

Baza danych, ktora pozniej zostanie utworzona na podstawie tego diagramu musi miec mozliwosc wygenerowania raportu:
przedstawiajacego STUDENTA i jego wszystkie OCENY z PRZEMIOTOW ktore studiuje.
W jakis sposob musze zmienic swoj diagram, zeby wygenerowanie takiego raportu bylo mozliwe?
Czy moze nie trzeba nic zmieniac?

Z gory dzieki za pomoc.

W internecie znalazlem podobny diagram (zalaczam ponizej), z tym ze tutaj OCENA (GRADE) nie jest przedstawiona jako ENCJA, tylko jako atrybut relacji. Nie wiem czy to jest poprawne? Czy moze obie wersje sa prawidlowe?

0

nikt nie pomoze?

0

Zapomnialem dodac, ze raport ma przedstawiac STUDENTA i jego wszystkie OCENY z PRZEMIOTOW ktore studiuje oraz obliczyc SREDNIA z OCEN.

Wydaje mi sie, ze atrybut pochodny (derived attribute), jakim jest SREDNIA z OCEN powinien byc dodany jako dodatkowy atrybut encji STUDENT (obok imienia, adresu, PESELu etc... studenta).
Czy mam racje?

Ponizej zalaczylem diagram z dolaczonym atrybutem (na czerwono)

0

Pytania do przemyślenia:
Czy każdy student ma pesel? (a zagraniczny student?)
Czy data urodzenia nie wynika z peselu?
Czy pesel nie jest wystarczająco unikalny żeby dodawać studentID?
Czy do adresu nie warto użyć tabeli słownikowej (choćby dla miast)?
Czy "ocena słowna" nie powinna być w tabeli słownikowej? (bo jak nam się nagle 2.0 zmieni z "miernego" na "dopuszczający" to będziesz leciał przez całą tablicę)
Czy Departament nie powinien być ujęty w słowniku? (bo jak sie nazwa zmieni to znów lecisz przez całą tabelę?)

0
Shalom napisał(a)

Pytania do przemyślenia:

  1. Czy każdy student ma pesel? (a zagraniczny student?)
  2. Czy data urodzenia nie wynika z peselu?
  3. Czy pesel nie jest wystarczająco unikalny żeby dodawać studentID?
  4. Czy do adresu nie warto użyć tabeli słownikowej (choćby dla miast)?
  5. Czy "ocena słowna" nie powinna być w tabeli słownikowej? (bo jak nam się nagle 2.0 zmieni z "miernego" na "dopuszczający" to będziesz leciał przez całą tablicę)
  6. Czy Departament nie powinien być ujęty w słowniku? (bo jak sie nazwa zmieni to znów lecisz przez całą tabelę?)

Dzieki za odpowiedz.

  1. Tak, nawet zagraniczni studenci maja PESEL (PESEL = Social Security Number (SSN), patrz odpowiedz nr. 2)
  2. Tak, data urodzenia wynika z PESELU, ale jako ze to zadanie nie dotyczy polskich warunkow (i zostalo przetlumaczone z angielskiego SOCIAL SECURITY NUMER (SSN)), to w tym wypadku PESEL i DATA UR. nie maja ze soba nic wspolnego.
  3. Student ID jest sposobem na rozpoznawanie studentow przez uczelnie, PESEL na rozpoznawanie ludzi przez panstwo. Oba z nich sa w tym wypadku unikatowe, ale sluza innym celom. Specyfikacja mowi, ze zarowno PESEL i Student ID musza sie znalezc w bazie.
  4. To zadanie jest zwiazane z narysowanie i objasnieniem tylko i wylacznie diagramu (bez implementacji), takze na typ etapie i do tego zadania tabela slownikowa nie bedzie potrzebna.
  5. jak powyzej
  6. jak powyzej

Jeszcze raz dzieki za odpowiedz.
Bylbym wdzieczny gdybys mogl jeszcze skomentowac czy stworzone relacje sa poprawne i czy z obecnego ukladu da sie wygenerowac raport z ocenami kazdego studenta + srednia ocen. I czy atrybut "Srednia ocen" powinien nalezec do encji STUDENT.
Wydaje mi sie, ze wszystko jest ok, ale... potrzebuje potwierdzenia.
Diagram, ktory znalazlem w internecie wydaje mi sie niepoprawny bo nie ma tam encji OCENA, tylko od razu relacja pomiedzy STUDENTEM i PRZEDMIOTEM.

pozdrawiam i z gory dzieki

0
greep napisał(a)
  1. Student ID jest sposobem na rozpoznawanie studentow przez uczelnie

Czyli Student ID jest numerem indeksu czy kluczem sztucznym?

I czy atrybut "Srednia ocen" powinien nalezec do encji STUDENT.

A czy taki atrybut w ogóle powinien istnieć?

Co to jest adres "obecny" i "stały"?

Moim zdaniem brakuje encji Wykładowca.

Ponadto Ocena powinna mieć np. datę wystawienia. I w ogóle nie rozumiem powiązania między Przedmiotem, Ocena a Studentem. Ile ocen z jednego przedmiotu może mieć student?

0
somekind napisał(a)
greep napisał(a)
  1. Student ID jest sposobem na rozpoznawanie studentow przez uczelnie

Czyli Student ID jest numerem indeksu czy kluczem sztucznym?

I czy atrybut "Srednia ocen" powinien nalezec do encji STUDENT.

A czy taki atrybut w ogóle powinien istnieć?

Co to jest adres "obecny" i "stały"?

Moim zdaniem brakuje encji Wykładowca.

Ponadto Ocena powinna mieć np. datę wystawienia. I w ogóle nie rozumiem powiązania między Przedmiotem, Ocena a Studentem. Ile ocen z jednego przedmiotu może mieć student?

Dzieki za odpowiedz

Student ID jest numerem indeksu.
"Srednia Ocen" jest atrybutem pochodnym (derived attribute), i nie jest przechowywany w zadnej tabeli, tylko obliczany na podstawie innych wartosci z innych tabel. Taki atrubut oznacza sie zwykle przerywana liniia (ja u siebie go zaznaczylem na czerwono).
Tylko nie wiem czy ten atrybut powinien byc przypisany do encji STUDENT, czy moze gdzies indziej?

Adres obecny i staly to wymagania z opisu zadania. To akurat jest bardzo malo wazne wiec mozemy to pominac.

Encja Wykladowca nie byla w wymaganiach takze ja pomijamy (chociaz masz racje, ze cos takiego powinno zostac zdefiniowane).


OCENA, jest oceną koncowa za dany przedmiot (data wystawienia jest zbedna).
Relacja (1:N - jeden do wielu) pomiedzy OCENA a PRZEDMIOTEM:
Jedna OCENA moze byc przypisana do wielu PRZEDMIOTOW.
Za kazdy PRZEDMIOT jest tylko jedna OCENA.

Relacja (M:N - wiele do wielu) pomiedzy STUDENTem i OCENA:
Jeden STUDENT moze miec wiele OCEN (za wiele PRZEDMIOTOW, jednak tylko jedną za jeden przedmiot).
Jedna OCENA za jakis przedmiot moze byc przypisana do wielu STUDENTOW

Czy powyzsze relacje sa poprawne i czy na ich podstawie mozna wygenerowac raport przedstawiajacy STUDENTA i jego oceny z wszystkich przedmiotow, ktore studiuje, oraz srednia z wszystkich ocen.

pozdrawiam

0

To ja już zupełnie niczego nie rozumiem, chyba żyję w innym wymiarze. Albo ten diagram jest na jakimś dziwnym poziomie abstrakcji. Relacji M:N przecież fizycznie nie wykona się w bazie danych.

Jeden student może mieć wiele ocen, ale jedną za jeden przedmiot. (Pomijamy poprawki, itd.)
Z jednego przedmiotu wystawia się wiele ocen, ale jedną jednemu studentowi.
Nie rozumiem jak jedna ocena może być przypisana do wielu studentów? Przecież każdy ma swoją.

IMHO powinno być tak: Student -- 1:N -- Ocena -- N:1-- Przedmiot

0

To ja chyba cos zamotalem, ale nie wiem co bo ciezko sie mysli o tej porze.
A moze w ogole nie powinno byc relacji pomiedzy PRZEDMIOTEM a OCENA?

Zamiast tego powinna byc relacja:
STUDENT - M:N - PRZEDMIOT
Czyli ze student studiuje wiele przedmiotow.
Przedmiot jest studiowany przez wielu studentow.

Oraz druga relacja:
PRZEDMIOT 1 - N - OCENA
Za jeden przedmiot mozna dostac rozną ocene (2, 3, 4, 5).

Czy to ma wiekszy sens niz to co wczesniej napisalem?


Student -- 1:N -- Ocena -- N:1-- Przedmiot - czy przez ta relacje mam rozumiec, ze dwie relacje 1:N daja w efekcie relacje M:N, gdzie tabela OCENA jest tabela łącza?

0
greep napisał(a)

Czy to ma wiekszy sens niz to co wczesniej napisalem?

Nie, bo w ten sposób gubisz informację o tym, jaką ocenę otrzymał student z danego przedmiotu.

Student -- 1:N -- Ocena -- N:1-- Przedmiot - czy przez ta relacje mam rozumiec, ze dwie relacje 1:N daja w efekcie relacje M:N, gdzie tabela OCENA jest tabela łącza?

Ogólnie tak.

Wydaje mi się, że:

  1. Między Student a Przedmiot powinna być jedna relacja M:N, bo jeden student może uczęszczać na wiele przedmiotów, a jeden przedmiot ma wielu studentów. Ponieważ takie relacje są nierealizowalne, to potrzebna jest jeszcze encja pośrednia, która będzie przechowywać Id Studenta i Id Przedmiotu, żeby je ze sobą powiązać.
  2. Ocenę ma jakiś Student z jakiegoś Przedmiotu, Ocena ma także jakąś swoją wartość. Dlatego tabela ta też jest encją pośrednią, każdy rekord tej tabeli musi mieć Id Studenta i Id Przedmiotu.
  3. Można trzymać informacje o uczęszczaniu Studenta na Przedmiot w oddzielnej encji, a Ocenę w jeszcze innej, można to chyba połączyć i mieć tylko tabelę Ocena. Ale nie wiem, czy to dobre rozwiązanie, bo w sumie z uczestnictwa w wykładach nie wynika jeszcze fakt otrzymania oceny. To jest do przemyślenia.
  4. Nie wiem też, na jakim poziomie abstrakcji jest diagram, który rysujesz. Zamieszczasz na nim elementy (średnia ocen), których fizycznie nie będzie w bazie, więc to chyba nie jest diagram implementacyjny. Może dozwolone jest na nim przedstawianie M:N, jako zapisu dziedziny problemu, nie sposobu wykonania bazy. Tego nie wiem.
0
somekind napisał(a)
greep napisał(a)

Czy to ma wiekszy sens niz to co wczesniej napisalem?

Nie, bo w ten sposób gubisz informację o tym, jaką ocenę otrzymał student z danego przedmiotu.

Student -- 1:N -- Ocena -- N:1-- Przedmiot - czy przez ta relacje mam rozumiec, ze dwie relacje 1:N daja w efekcie relacje M:N, gdzie tabela OCENA jest tabela łącza?

Ogólnie tak.

Wydaje mi się, że:

  1. Między Student a Przedmiot powinna być jedna relacja M:N, bo jeden student może uczęszczać na wiele przedmiotów, a jeden przedmiot ma wielu studentów. Ponieważ takie relacje są nierealizowalne, to potrzebna jest jeszcze encja pośrednia, która będzie przechowywać Id Studenta i Id Przedmiotu, żeby je ze sobą powiązać.
  2. Ocenę ma jakiś Student z jakiegoś Przedmiotu, Ocena ma także jakąś swoją wartość. Dlatego tabela ta też jest encją pośrednią, każdy rekord tej tabeli musi mieć Id Studenta i Id Przedmiotu.
  3. Można trzymać informacje o uczęszczaniu Studenta na Przedmiot w oddzielnej encji, a Ocenę w jeszcze innej, można to chyba połączyć i mieć tylko tabelę Ocena. Ale nie wiem, czy to dobre rozwiązanie, bo w sumie z uczestnictwa w wykładach nie wynika jeszcze fakt otrzymania oceny. To jest do przemyślenia.
  4. Nie wiem też, na jakim poziomie abstrakcji jest diagram, który rysujesz. Zamieszczasz na nim elementy (średnia ocen), których fizycznie nie będzie w bazie, więc to chyba nie jest diagram implementacyjny. Może dozwolone jest na nim przedstawianie M:N, jako zapisu dziedziny problemu, nie sposobu wykonania bazy. Tego nie wiem.

Dzieki bardzo za odpowiedz.

Ad 1 & 2)foo Oczywiscie zgadzam sie. Tylko co bedzie kluczem takiej tabeli/encji posredniej?
Bo wydaje mi sie, ze klucz glowny bedzie zlozony i bedzie musial sie skladac z 3 atrybutow (Ocena, Student ID i Przedmiot) zeby odroznic kazdy rekord w tej tabeli. Czy mam racje?

Ad 4)foo Diagram jest na wysokim poziomie abstrakcji, niezalezny od zadnej implementacji. Dozwolone jest na nim przedstawianie relacji M:N.
Dla przykladu podam inny diagram, gdzie relacja pomiedzy PRACOWNIKIEM a PROJEKTEM jest wlasnie M:N.
PRACOWNIK pracuje nad PROJEKTEM (EMPLOYEE works on PROJECT).
1 pracownik moze pracowac nad wieloma projektami
Nad 1 projektem moze pracowac wielu pracownikow.
W tym diagramie nie ma tabeli posredniej.
Link do diagramu: http://www.google.ie/imgres?imgurl=http://www.cs.pitt.edu/~chang/156/images/fig3b.gif&imgrefurl=http://www.cs.pitt.edu/~chang/156/03ERmodel.html&usg=__XttgA-Njph_5V3N3zcd8VHjqxi8=&h=480&w=640&sz=9&hl=en&start=0&zoom=1&tbnid=94WyfAj9MgB-BM:&tbnh=156&tbnw=192&prev=/images%3Fq%3Dentity%2Brelationship%2Bdiagram%2BEMPLOYEE%26um%3D1%26hl%3Den%26sa%3DN%26biw%3D948%26bih%3D611%26tbs%3Disch:1&um=1&itbs=1&iact=rc&dur=453&ei=LrjzTKOhNYehOr_S6fEJ&oei=LrjzTKOhNYehOr_S6fEJ&esq=1&page=1&ndsp=12&ved=1t:429,r:3,s:0&tx=110&ty=72

Tylko jakbym chcial przedstawic relacje M:N pomiedzy STUDENT a PRZEDMIOT na moim diagramie (bez zadnej tabeli posredniej - z OCENA), jak wtedy podpialbym pod to OCENE i polaczyl ją z reszta? Jak wtedy zaprezentowac to na takim diagramie?
fooA moze w ogole nie tworzyc OCENY jako encji, a tylko jako atrybut relacji M:N pomiedzy STUDENTEM a PRZEDMIOTEM?
Czy taka reprezentacja pozwolilaby na wygenerowanie raportu Studenta i jego wszystkich ocen za wszystkie przedmioty, oraz sredniej z ocen?
Czy atrybut pochodny "srednia z ocen" jest prawidlowo podpiety pod encje STUDENT? Wydaje mi sie, ze tak.

0

Ok, narysowalem dwa diagramy (zalaczone ponizej):

  1. z OCENA (GRADE) jako ENCJĄ
  2. z OCENA (GRADE) jako atrybutem relacji.

Ktory diagram wedlug Was jest lepszy?
Komentarze i poprawki mile widziane :)

pozdrawiam

1 użytkowników online, w tym zalogowanych: 0, gości: 1