To pytanie pokazuje, że nie w pełni rozumiesz relacje między podmiotami (bez nieuprzejmości). Z czego są cztery (technicznie tylko 3) typy poniżej:
One to One One to Many Many to One Many to Many
Jeden do jednego (1:1): W tym przypadku tabela została podzielona na dwie części w celu zapewnienia zgodności z normalizacją lub częściej zasadą otwartego zamkniętego.
Normalizacja zgodność:możesz mieć regułę biznesową, że każdy klient ma tylko jedno konto. Technicznie można by w tym przypadku powiedzieć, że klient i konto mogą znajdować się w tej samej tabeli, ale to łamie zasady normalizacji, więc dzielisz je i tworzysz 1:1.
Zasada otwórz-zamknij zgodność:tabela klientów, może zawierać identyfikator, imię i nazwisko oraz adres. Później ktoś postanawia dodać datę urodzenia, a wraz z nią możliwość obliczenia wieku wraz z kilkoma innymi bardzo potrzebnymi polami. Jest to zbyt uproszczony przykład jeden do jednego, ale głównym zastosowaniem jest rozszerzenie bazy danych bez łamania istniejącego kodu. Wiele napisanego kodu (niestety) jest ściśle powiązane z bazą danych, więc zmiany w strukturze tabeli spowodują uszkodzenie kodu. Dodanie takiej wartości 1:1 rozszerzy tabelę tak, aby spełniała nowe wymagania bez modyfikowania oryginału, umożliwiając w ten sposób normalne funkcjonowanie starego kodu, a nowego kodu korzystanie z nowych funkcji bazy danych.
Minusem normalizacji i rozszerzania tabel przy użyciu relacji 1:1 w ten sposób jest wydajność. Często na intensywnie używanych systemach pierwszym celem zwiększenia wydajności bazy danych jest denormalizacja i łączenie takich tabel w jedną tabelę oraz optymalizacja indeksów, co eliminuje potrzebę korzystania z łączeń i odczytywania z wielu tabel. Normalizacja/Denormalizacja nie jest ani dobrą ani złą rzeczą, ponieważ zależy od potrzeb systemu. Większość systemów zwykle zaczyna od znormalizowanej zmiany w razie potrzeby, ale ta zmiana musi być wykonana bardzo ostrożnie, jak wspomniano, jeśli kod jest ściśle powiązany ze strukturą bazy danych, prawie na pewno spowoduje awarię systemu. tj. Kiedy połączysz 2 tabele, jedna przestaje istnieć, cały kod, który zawiera nieistniejącą tabelę, kończy się niepowodzeniem, dopóki nie zostanie zmodyfikowana (w kategoriach bazy danych, wyobraź sobie łączenie relacji z którąkolwiek z tabel w 1:1, kiedy usuniesz te tabele , to zrywa relacje, więc struktura musi zostać znacznie zmodyfikowana, aby to zrekompensować. Niestety, takie złe projekty są w większości przypadków znacznie łatwiejsze do zauważenia w świecie DB niż w świecie oprogramowania i zwykle nie zauważasz, że coś poszło nie tak w kodzie, dopóki wszystko się nie rozpadnie), chyba że system jest prawidłowo zaprojektowany z oddzieleniem obaw na uwadze.
Jest to najbardziej zbliżona rzecz do dziedziczenia w programowaniu obiektowym. Ale to nie to samo.
Jeden do wielu (1:M) / Wiele do jednego (M:1): Te dwie relacje (dlatego 4 staje się 3), są najpopularniejszymi typami relacji. Obie są tym samym rodzajem relacji, jedyną rzeczą, która się zmienia, jest twój punkt widzenia. Przykład Klient ma wiele numerów telefonów lub alternatywnie wiele numerów telefonów może należeć do klienta.
W programowaniu obiektowym byłoby to uważane za kompozycję. To nie jest dziedzictwo, ale mówisz, że jeden element składa się z wielu części. Jest to zwykle reprezentowane przez tablice / listy / kolekcje itp. wewnątrz klas, w przeciwieństwie do struktury dziedziczenia.
Wiele do wielu (M:M): Taki związek z obecną technologią jest niemożliwy. Z tego powodu musimy podzielić ją na dwie relacje jeden do wielu z dołączającą do nich tabelą „powiązań”. Wiele stron relacji dwa do wielu znajduje się zawsze w tabeli asocjacji / linków.
Na przykład osoba, która powiedziała, że potrzebujesz „wiele za wiele”, ma rację. Ponieważ dwa do wielu to w rzeczywistości związek wiele (czyli więcej niż jeden) do wielu. To jedyny sposób, w jaki Twój system będzie działał. Chyba że zamierzasz badać dziedzinę rachunek relacyjny znaleźć nowy rodzaj relacji, który by na to pozwolił.
Również dla takich relacji (m2m) masz dwie możliwości:albo utwórz klucz złożony w tabeli linkera, aby kombinacja pól stała się unikalnym wpisem (jeśli jesteś zainteresowany optymalizacją bazy danych, jest to wolniejszy wybór, ale zajmuje mniej miejsca). Alternatywnie tworzysz trzecie pole z automatycznie wygenerowaną kolumną identyfikatora i czynisz z niego klucz podstawowy (dla optymalizacji bazy danych jest to szybszy wybór, ale zajmuje więcej miejsca).
W twoim przykładzie powyżej...
Byłaby to relacja wiele do wielu z tabelą numerów telefonów jako tabelą łączącą firmy i użytkowników. Jak wyjaśniono, aby mieć pewność, że żaden numer telefonu się nie powtórzy, wystarczy ustawić go jako klucz podstawowy lub użyć innego klucza podstawowego i ustawić pole numeru telefonu jako niepowtarzalne.
W przypadku tego rodzaju pytań tak naprawdę zależy to od tego, jak je sformułowasz. Co powoduje, że się mylisz i jak przezwyciężasz to zamieszanie, aby zobaczyć rozwiązanie, jest proste. Sformułuj problem w następujący sposób. Zacznij od pytania, czy jest to jeden do jednego, jeśli odpowiedź brzmi nie, przejdź dalej. Następnie zapytaj, czy to jeden do wielu, jeśli odpowiedź brzmi:nie iść dalej. Jedyną pozostałą opcją jest „wiele do wielu”. Bądź jednak ostrożny, upewnij się, że dobrze rozważyłeś pierwsze 2 pytania, zanim przejdziesz dalej. Wielu niedoświadczonych osób zajmujących się bazami danych często nadmiernie komplikuje problemy, definiując jeden do wielu, jak wiele do wielu. Po raz kolejny najpopularniejszym typem relacji jest zdecydowanie jeden do wielu (powiedziałbym, że 90%), gdzie wiele do wielu i jeden do jednego dzielą pozostałe 10% odpowiednio 7/3. Ale te liczby to tylko moja osobista perspektywa, więc nie przytaczaj ich jako standardowych statystyk branżowych. Chodzi mi o to, aby upewnić się, że zdecydowanie nie jest to jeden do wielu, zanim wybierzesz wiele do wielu. Jest to warte dodatkowego wysiłku.
Więc teraz, aby znaleźć tabelę łączącą między tymi dwoma, zdecyduj, które dwie są twoimi głównymi tabelami i jakie pola muszą być między nimi współdzielone. W takim przypadku zarówno firmowe, jak i użytkownika tabele muszą współdzielić telefon. W związku z tym musisz stworzyć nową tabelę telefonów jako linker.
Alarm ostrzegawczy o nieporozumieniu powinien pojawić się, gdy tylko zdecydujesz, że żaden z 3 nie działa dla Ciebie. To powinno wystarczyć, aby powiedzieć, że po prostu nie formułujesz poprawnie pytania dotyczącego związku. Z biegiem czasu będziesz w tym coraz lepszy, ale jest to niezbędna umiejętność i naprawdę należy ją opanować tak szybko, jak to możliwe, dla własnego zdrowia psychicznego.
Oczywiście możesz również przejść do bazy danych zorientowanej obiektowo, która pozwoli na szereg innych relacji zwanych relacjami „hierarchakalnymi”. To świetnie, jeśli myślisz o zostaniu programistą. Ale nie polecałbym tego, ponieważ spowoduje to ból głowy, gdy zaczniesz szukać sposobów na łączenie różnych rodzajów relacji. Zwłaszcza biorąc pod uwagę, że nie ma takiej potrzeby, ponieważ prawie wszystkie bazy danych na świecie składają się tylko z tych 3 rodzajów relacji, chyba że są one czymś super specjalnym.
Mam nadzieję, że to była rozsądna odpowiedź. Dziękujemy za poświęcenie czasu na jej przeczytanie.
