MySQL klucze glowne i klucze obce - relacje w Workbench

0

Mam pytanie. Bawił się ktoś z Was Mysql Workbench ewentualnie innym programem do tworzenia graficznej struktury baz danych?

Zrobiłem sobie bazę w phpMyAdmin wszystkie tabele są powiązane ze sobą poprzez klucze główne i klucze obce, mechanizm, składowania InnoDB. Tylko 4 tabele powiązałem w taki sposób, że usuwając konto użytkownika automatycznie zostaną usunięte z nim dane z innej tabeli, aby nie pozostawiać niepotrzebnych danych bez powiązań I tak samo z dwoma innymi. Reszta tabel gromadzi jakieś dane podawane przez użytkowników, ale głównie są w nich przechowywane stałe rzeczy, które zostały już wpisane na stałe do wyświetlania na stronie w formularzu.

Nie potrzebuję tu żadnych innych relacji, itd. ale potrzebuję przedstawić graficzną reprezentację bazy. Wczytałem sobie strukturę do MySQL Workbench celem zobrazowania tabel. I tak jak wspominałem 4 z nich automatycznie zostały pokazane powiązaniami, tak jak to ma odzwierciedlenie w rzeczywistości. Jednak jak mam powiązać resztę tabel, one wszystkie kluczami głównymi odnoszą się do jednej, w której spływają zebrane informacje i na ich podstawie są gromadzone informacje o użytkowniku. Tylko chciałbym jednak przedstawić powiązania tych tabel w sposób graficzny. Jak je próbuję powiązać relacjami to jednak potem serwis nie działa mi tak jak trzeba coś robię źle.

Wytłumaczcie mi, co oznaczają relacje 1 do wielu przerywaną linią, a relacje 1 do wielu rozrysowane ciągłą linią.

Rozumiem, ze relacja 1 do wielu przerywaną linia oznacza, ze usuwając rekord w głównej tabeli automatycznie wykasuje informacje powiązane z danym rekordem w drugiej tabeli.
W ogóle, kiedy mam zastosowane klucze w bazie to powinienem jednak jakoś jeszcze zastosować odpowiednie relacje w bazie czy jeśli chce tylko pokazać graficzny model bazy to wystarczy, że rozrysuje to tylko celem zademonstrowania bez potrzeby implementowania tego w bazę?

A i jeszcze jedno, kiedy w Workbench rysuję relację (jest tam taki ołówek na samym dole po lewej stronie) w ten sposób:, że zaznaczam najpierw w tabeli głównej klucz główny ID a potem w tabeli gdzie jest klucz obcy odwołujący się do klucza głównego zaznaczam klucz obcy to program rysuje mi relację ciągła linią w przy kluczu głównym mam wiele a przy kluczu obcym 1.

Kiedy robię to na odwrót najpierw zaznaczam klucz obcy a potem klikam na klucz główny to mam linię przerywaną, ale przy kluczu obcym wiele a przy kluczu głównym 1.

Czegoś tu trochę nie rozumiem. Możecie mi wyjaśnić jak to jest?

0

Nie wiem czy w MySQL Workbench jest tak samo, ale linia ciągła przy relacji 1:n oznacza, że kolumna z kluczem obcym należy równocześnie do klucza podstawowego tabeli. (A w przypadku linii przerywanej nie należy)

Nie ma to związku z zachowaniem się danych w tabelach powiązanych przypadku aktualizacji/usunięcia danych z tabeli "głównej". Robi się to przy pomocy ON DELETE i ON UPDATE w kodzie SQL tworzenia klucza obcego, szukaj w programie opcji z podobnymi słowami.

Nie ma przymusu stosowania relacji. Możesz sobie je tylko "rozrysować", ale nie zapisywać zmian w swojej bazie danych, skoro ci się psuje. Minusem jest oczywiście to, że musisz sam dbać o spójność swojej bazy danych z poziomu aplikacji.

No i oczywiście ma znaczenie z której tabeli do której "przeciągasz" relację.

0

Mam coś takiego zrobione:
Tabela BAZA_UZYTKOWNICY jest połączona z tabelą BAZA_PROFIL kiedy zajdzie potrzeba usunięcia użytkownika z tabeli BAZA_UZYTKOWNICY to automatycznie usuwane są informacje związane z danym użytkownikiem z tabeli BAZA_PROFIL tak, że nie pozostaną tam niepotrzebne rzeczy z niczym i z nikim niepowiązane. Czyli działa O.K.
user image

Tabela SZKOLY to tabela, w której użytkownicy dodają z formularza swoje szkoły. Raz dodana jest już w bazie więc inna osoba chcąca wybrać daną uczelnię ma ją już w bazie więc się pokazuje na liście wyboru, nie trzeba jej już dodawać. To samo z wydziałem, który jest powiązany ze szkołami. Jeśli ktoś doda nie istniejącą szkołę/dziwną etc. to usunięcie jej wykasuje też jej wydziały, aby się nie pojawiały na liście i nie pozostawały w bazie. Tabela kierunki to tabela z analogicznym podejściem, raz dodany kierunek będzie potem już w formularzy, wiec użytkownik go tylko wybiera. Wypełniając formularz wszystkie dane o danej osobie są składowane w BAZA_PROFIL poprzez powiązania kluczy głównych i kluczy obcych.
Wszystko niby działa jak trzeba, ale pytanie jak mam powiązać te relacje i aby fizycznie je odzwierciedlić ewentualnie, aby tylko graficznie przedstawić powiązania? Czy to ma byc tak?
user image

Czy może to powinno być tak, ale ten ostatni przykład chyba jest źle.
user image
Kolega z tymi liniami co podpowiedział wyżej to chyba to jednak powinno nyc na odwrót.

W ogóle już nie wiem jak z tymi relacjami. Rozumiem BAZA_UZYTKOWNICY to relacja 1 do wielu bo jeden użytkownik może mieć wiele profilów/ wiele ukończonych szkół.
Relacja szkoły – wydziały to też 1 do n bo jedna szkoła może mieć wiele wydziałów, ale jak z tymi dalszymi relacjami?
Szkoły-baza_profil?
Wydzialy-baza_profil?
Kierunki-baza_profil?
Czy kierunek może mieć wiele profilów wystąpień, jak to sobie tłumaczyć?
A może gdzieś powinna być relacja 1 do 1 albo jeszcze jakoś inaczej?

Podpowiedzcie mi, który schemat jest prawidłowo zrobiony (2-3) wydaje mi się, że drugi chyba, zę to jeszcze inaczej powinno być?

0
  1. Nie pomyliłem się z liniami. Przerywana - relacja nieidentyfikująca (klucz obcy nie jest jednocześnie kluczem podstawowym), ciągła - relacja identyfikująca

  2. Popracuj nad nazewnictwem tabel i kolumn. Żeby w miarę jednolite było.

  3. Zainstalowałem tego Workbencha i przygotowałem ci relacje, które najbardziej odpowiadają rzeczywistości. Problem w tym, że będziesz miał sporo złączeń w zapytaniach. Dodatkowo jeśli w tabeli kierunki będziesz przechowywał jedynie ID i nazwę kierunku, to sporo się będzie powtarzało. W takim wypadku powinieneś użyć relacji wiele do wielu między kierunkami a wydziałami. Analogicznie między szkołami a wydziałami, jeśli też będą powtórzenia.
    Ewentualnie możesz bazę trochę zdenormalizować i zrobić relacje:
    kierunki - profile
    szkoły - wydziały - profile
    user image

  4. Zachowanie w przypadku usunięcia/edycji danych w powiązanej tabeli ustawia się w zakładce Foreign Keys okienka edycji tabeli. Jeśli dla wszystkich relacji
    szkoła - wydział - kierunek - profil
    ustawisz ON DELETE: CASCADE, to po usunięciu szkoły automatycznie usuną się jej wydziały, kierunki oraz profile. Zostaną tylko dane o użytkownikach w tabeli baza_uzytkownicy

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