Diagram bazy danych, co zrobić, aby relacje między tabelami same się "wyrysowały"?

Witam.

W pracy czasem mam za zadanie zrobić zestawienie SQL, pobierające dane z bazy programu użytkowego (sam program nie zapewnia wszystkich funkcjonalności). Najczęściej jest to wyciąganie danych z kilku tabel. Używam polecenia JOIN i dlatego muszę ustalać nazwy pól w tabelach, które są kluczami głównymi i obcymi.

Po raz n-ty stwierdzam, że bardzo pomocny byłby graficzny schemat bazy danych. Po to, by mieć w jednym miejscu klucze główne i obce wszystkich tabel, jak również widzieć relacje między tabelami.

W SQL Server Management Studio 2008R2 poprzez Database Diagrams -> New Database Diagram bez problemu nanosi się tabele na diagram. Ale jak równie bezproblemowo odtworzyć relacje między tabelami?

Pozdrawiam i proszę o podpowiedź.

Ale przecież SQL Server maluje diagram razem z zaznaczonymi powiązaniami między tabelami. Jeśli ich tam nie ma znaczy ze ktoś mega sprytnie tą baze zrobił i wcale nie powiązał tabel kluczami.

Shalom napisał(a):

Ale przecież SQL Server maluje diagram razem z zaznaczonymi powiązaniami między tabelami. Jeśli ich tam nie ma znaczy ze ktoś mega sprytnie tą baze zrobił i wcale nie powiązał tabel kluczami.

No właśnie tego nie rozumiem. Prywatny, kiedyś na uczelni robiony programik, wyrysował mi się razem z relacjami między tabelami. Natomiast gdy w pracy tworzę "New Diagram" dla programu, na którym pracujemy, to widać jedynie tabele z kluczami, ale nie ma tych "wiązań" pomiędzy tabelami. A może to jakieś zabezpieczenia producenta??

Ja jestem prawie pewien że ktoś po prostu źle tą bazę zrobił i tyle. Zobacz sobie co ci wypisze skrypt tworzący tą bazę i czy będą tam faktycznie podane contrainty dla foreign key czy nie. Ja zgaduje że nie.

Shalom napisał(a):

Jeśli ich tam nie ma znaczy ze ktoś mega sprytnie tą baze zrobił i wcale nie powiązał tabel kluczami.

Czy dobrze Cię rozumiem - czy jest możliwe, że program wykonuje obliczenia "w kodzie" (tu: w Delphi), a w tabelach są jedynie przechowywane wyniki tychże obliczeń? I dlatego nie ma ustanowionych relacji pomiędzy tymi tabelami?

Shalom napisał(a):

Ja jestem prawie pewien że ktoś po prostu źle tą bazę zrobił i tyle. Zobacz sobie co ci wypisze skrypt tworzący tą bazę i czy będą tam faktycznie podane contrainty dla foreign key czy nie. Ja zgaduje że nie.

Dziękuję, że w międzyczasie odpisałeś na tamto pytanie.
Program na pewno działa, bo to program użytkowy, od lat na rynku, ma oczywiście swoje błędy, ale jakoś tam działa :)
Spróbuję wyskryptować bazę jak radzisz i potem ją odtworzyć ze skryptu, a na końcu zrobić do niej diagram, zobaczę, czy "łyknie" constrainty ze skryptu :)

No zasadniczo jest możliwe że masz bazę gdzie na poziomie bazy danych nie ma powiązań między tabelami (czyli tych constraintów na kluczach) i to moze działać o ile aplikacja sobie tego pilnuje. Jest to dziwny pomysł, ale nie jest to niemożliwe ;)

baza danych zrobiona z niepowiązanych tabel będzie działała, będą działały na niej złozone zapytania pobierające dane z różnych tabel, taka baza (zbiór niepowioązanych tabel) po prostu nie zapewnia spójności danych.

Shalom napisał(a):

No zasadniczo jest możliwe że masz bazę gdzie na poziomie bazy danych nie ma powiązań między tabelami (czyli tych constraintów na kluczach) i to moze działać o ile aplikacja sobie tego pilnuje. Jest to dziwny pomysł, ale nie jest to niemożliwe ;)

Coś mi się obiło o uszy, jak koledzy mówili o tabelach w warstwie aplikacji oraz o tabelach w bazie. To by się zgadzało z tym, co piszesz, że aplikacja sobie pilnuje obliczeń, a wyniki pewnie są wyprowadzane do tabel w SQL, bo gdzieś muszą być przechowywane.

To może dlatego klienci się skarżą, że program tak wolno działa, bo obliczenia nie są przeprowadzane na poziomie bazy SQL w T-SQL'u, tylko aplikacja (Delphi) najpierw musi za każdym razem wyciągnąć sobie te dane, dokonać obliczeń i zwrócić wyniki z powrotem.

Po wyskryptowaniu bazy są constrainty, ale jakieś dziwnie brzmiące, np.: " CONSTRAINT [PK__RATYUM__02084FDA] PRIMARY KEY CLUSTERED"

Varran napisał(a):

baza danych zrobiona z niepowiązanych tabel będzie działała, będą działały na niej złozone zapytania pobierające dane z różnych tabel, taka baza (zbiór niepowioązanych tabel) po prostu nie zapewnia spójności danych.

Mam nadzieję, że tak jak Shalom pisał, aplikacja jednak "pilnuje" sobie tych danych w bazie SQL.
To są dane typu rozliczenia rat potrąceń itp., więc pewnie dawno byłaby niezła afera, gdyby nie zapewniono spójności danych.
Choć przyznam szczerze, że rzadko, ale zdarzały się dziwne zachowania programu typu "osierocone" raty, więc pewnie masz rację, że coś jest na rzeczy ze spójnością danych.

@Reniffer constraint który pokazałeś to jest contraint na PK który baza wymusza ;) Powinny tam też być takie z prefixem FK.

Shalom napisał(a):

@Reniffer constraint który pokazałeś to jest contraint na PK który baza wymusza ;) Powinny tam też być takie z prefixem FK.

No właśnie ciekawa sprawa, że przeczesanie skryptu od góry do dołu Ctrl+F ze słowem kluczowym "Constraint" wyłapuje tylko PK, żadnych Foreign Key nie widać, dziwne. Ale dobra tam, nie zawracam już głowy. Bardzo dziękuję za rozmowę i chęć pomocy, miłego wieczoru :)

Shalom napisał(a):

Ale przecież SQL Server maluje diagram razem z zaznaczonymi powiązaniami między tabelami. Jeśli ich tam nie ma znaczy ze ktoś mega sprytnie tą baze zrobił i wcale nie powiązał tabel kluczami.

Mam jeszcze jedno podejrzenie. Kiedyś program pracował na bazie plikowej (Paradoxowej), w niej były gromadzone wyniki obliczone przez aplikację napisaną w Delphi. Potem w ramach "unowocześnienia" program przeniesiono na bazę SQL.

Może brak możliwości wyrysowania relacji między tabelami SQL, to pozostałość po tamtej architekturze?