Modelowanie bazy danych

Mam za zadanie zamodelować bazę danych, dostałem informacje zwrotną o treści: do identyfikatora Encji kontrakt powinien wejść również związek od Zawodnika. Niestety nie wiem do końca jak to zrobić, proszę o pomoc.

Nie znam się na diagramach, ale wnioskuję, ze hasze oznaczają kolumny na które ma się składać klucz główny i jednoznacznie identyfikują wiersz. W przypadku Kontraktu data_zawarcia nie ma takiej własności, ma ją za to trójka data_zawarcia, zawodnik.imie, zawodnik.nazwisko.

Czyli, wystarczyłoby do encji kontrakty dodać dwa atrybuty: imie oraz nazwisko i dodać je do klucza głównego?

A profesor do encji Klub i Zawodnik się nie czepiał? Bo przecież ten związek masz na strzałkach posiada i jest przypisany do.

Nie, nie dostałem żadnej uwagi odnośnie tego.

Czy mógłby ktoś potwierdzić moją wiadomość odnoście dodania atrybutow do encji Konrakt?

Tak bym powiedział, ale nie wiem jaka jest konwencja, bo te atrybuty to de facto ten związek opisany strzałką jest przypisany do, a nie widzę na schemacie jawnie wskazanych kolumn klucza obcego w pozostałych miejscach.

Możesz z tego SQL wygenerować?
Np. ja tych obrazków nie rozumiem i do mnie bardziej przemawia CREATE TABLE i ALTER TABLE

To może chodzi o to że ustawił ten klucz na data_zawarcia, jak będą 3 kontrakty jednego dnia to jak je rozpozna? Dodaj tam pole np nr_kontraktu

Tak, dokładnie o to chodzi, tylko że mam jasno określone, że do indentyfikatora ma wejsc zwiazek od zawodnika.

Przemas1402 napisał(a):

Czyli, wystarczyłoby do encji kontrakty dodać dwa atrybuty: imie oraz nazwisko i dodać je do klucza głównego?

To będzie bardzo kiepski klucz główny dla kontraktu. Będziesz go identyfikował sporym kluczem złożonym, w dodatku będzie mieć w składzie dwa klucze obce do jednej tabeli. Poza tym ogólnie identyfikując ludzi po imieniu i nazwisku zakładasz, że nie ma dwóch ludzi z tym samym imieniem i nazwiskiem - a jeśli są, to trzeba zmienić klucz również tam. Nie mówiąc o tym, o czym ktoś już wspomniał - identyfikowanie po dacie jest słabe, bo skąd możesz wiedzieć, że dwóch ludzi nie zawrze kontraktu w jednym dniu albo nawet minucie?

Najprościej byłoby wprowadzić klucze proste (jakieś id_kontraktu dla kontraktu, pesel lub id_zawodnika dla zawodnika etc...) i po nich identyfikować, wtedy wystarczyłoby że kontrakt zawiera informację o id_zawodnika / jego peselu jako klucz obcy i jakieś własne unikalne id jako klucz główny. No chyba, że prowadzący jest jakimś fanem sklejania kluczy złożonych z 3-6 kolumn. Wtedy to hulaj dusza, możesz jeszcze dorzucić fazy księżyca do identyfikatora :D