Mam parę pytań odnośnie logicznego (i nie tylko) modelu baz danych.
Na studiach mieliśmy na zadanie oddać projekt bazy danych dla Biura Nieruchomości, Coś tam zrobiliśmy, ale postanowiliśmy postarać się utrzymać 3 normalizację (czy jak się to nazywa)/ I problem pojawił się w przypadku, gdy zrobiliśmy 3 encje jako rodzaje nieruchomości na sprzedaż (dom, mieszkanie, działka). W celu podania adresu, zrobiliśmy dodatkową encję z Adresem, dla każdej encji (! Potem jeszcze doszli Pracownicy którzy mają już 4 taką samą). Jak zrobić, żeby użyć tylko jednej tabeli z Adresami dla 4 innych. Bo wg mnie, jeżeli będą połączone relacją opcjonalną to będą adresy "kierujące do niczego" (adres ani dzialki, ani domu, ani mieszkania), jeżeli wszystkie będą połączone relacją nieopcjonalną, to się okaże że dodanie do tabeli adresy jakiegoś pola wymusi utworzenie pól we wszystkich czterech encjach połączonych z tą tabelą, dobrze myślę?. Drugą sprawą jest to, że zrobiliśmy kolejną encję z Ofertami której atrybutem byłby klucz głowny TYLKO jednej z w/w encji, jak to zrobić? Zakładam, że może to być trochę cięższe, gdyż klucze podstawowe mogą mieć taką samą wartość (np w 2 encjach mamy już PK z wartością 1). Tutaj jest przedstawione graficznie jak to wygląda: https://zapodaj.net/86331a2eba481.jpg.html .
Co byście polecili jeszcze dodać/zmienić żeby ten (pseudo)Projekt przeszedł?
PS: Nie patrzcie na etykiety relacji, wiem że są tragiczne :D
Przede wszystkim miasta dałbym do innej tabeli. Wszystkie typy także. Mieszkanie, dom i działka to wg mnie "nieruchomość" z możliwymi trzema typami, każdy z nich ma powierzchnię oraz niepowtarzalny adres - tzn dom nie może istnieć w dwóch miastach. Czy działka (rozumiem że taka np na obrzeżach miasta) nie ma numeru ulicy? Tzn czy dwie działki umiejscowione na początku i końcu ulicy która ciągnie się przez pół miasta są tak samo traktowane?
Tak czy siak - wszystko co się powtarza w kilku tabelach umieszczamy w jednej, jeśli wartości w danej tabeli (np przy tysiacu ofert z setkami tysięcy mieszkań/domów itp) będą się powtarzaly i nie będą to identyfikatory - to robimy ekstrację - np typ mieszkania/miasto/ulica (ulica to może kwestia sporna).
Jak zrobisz tabelę "adresy" to potem połącz ją z "pracownicy_adresy" (tablę pracownicy też połącz relacją) i dajesz tam pary ID (pracownika i adresu)
axelbest napisał(a):
Mieszkanie, dom i działka to wg mnie "nieruchomość" z możliwymi trzema typami, każdy z nich ma powierzchnię oraz niepowtarzalny adres - tzn dom nie może istnieć w dwóch miastach.
Tutaj to zależy od logiki oprogramowania z jakiego miałaby korzystać baza. Taka struktura w modelu obiektowym byłaby reprezentowana przy wykorzystaniu dziedziczenia i generalnie odwzorowanie każdej klasy jako jednej relacji ma sporo zalet.
Nie rozumiem po co istnieje relacja zlecenie - to znaczy czym się różni w tym przypadku od oferty skoro ma tylko klucz główny i klucze obce do relacji Biura oraz Oferty.
Zlecenie chciałem dodać, po to żeby móc zastosować relację wiele-do-wielu.
Nadal nie rozumiem jak zrobić, z tymi nieruchomościami. Rozumiem, że mógłbym dodać np do Mieszkania (albo Nieruchomości), kolejną relację z działkami (opcjonalną), jeśli by była działka, to byłby traktowany jako dom - jeśli nie byłoby jej, do jako mieszkanie. Tylko nadal nie wiem, jak zrobić żeby była możliwość "sprzedaży" samej działki.
Sprzedajesz nieruchomość, nie ma znaczenia czy to dom, mieszkanie, działka czy garaż. Każdy z tych elementów posiada swoją lokalizację określaną przez adres. Każdy ten obiekt ma swój typ. Jeśli działki mają inne pola niż pozostałe typy (albo np dom ma atrybut "ilość pięter", a mieszkanie ma "klatka","piętro") to dorabiasz tabelę(jedną lub więcej) która jest połączona z nieruchomością. Podałeś zbyt mało danych na temat wytycznych - bo może w planie masz np zrobić sprzedaż "kilku mieszkań" lub "mieszkanie + działka" w jednej transakcji.
Najprościej jak się da. Jedno mieszkanie, lub jeden dom, w ostateczności sama działka.
Rozumiem o co chodzi z nieruchomościami, tylko czy jeżeli połączyłbym relacją (opcjonalną po stronie nieruchomości) z np. działką, encją z polami od domu/mieszkania to czy nie byłoby sytuacji gdzie mogłaby "istnieć sama nieruchomość"? Bez "działki", ilości "pięter" i "klatki"? O to mi głównie chodzi. Ew czy mogłyby istnieć Nieruchmości z "piętrami" (i innymi atrybutami charakterystycznymi tylko dla domów) wraz z "Klatka schodowa" (+ atrybuty Mieszkania)?
Aisekai napisał(a):
Jak zrobić, żeby użyć tylko jednej tabeli z Adresami dla 4 innych. Bo wg mnie, jeżeli będą połączone relacją opcjonalną to będą adresy "kierujące do niczego" (adres ani dzialki, ani domu, ani mieszkania)
No, jeśli pozwolisz aplikacji na wprowadzenie adresu niepowiązanego z niczym, to tak będzie. Ale to nie jest problem projektu bazy danych tylko jej używania.
Drugą sprawą jest to, że zrobiliśmy kolejną encję z Ofertami której atrybutem byłby klucz głowny TYLKO jednej z w/w encji, jak to zrobić? Zakładam, że może to być trochę cięższe, gdyż klucze podstawowe mogą mieć taką samą wartość
Możesz użyć guidów, aby mieć różne wartości. Ale równie dobrze możesz mieć trzy klucze obce i sprawdzaj w aplikacji, czy dokładnie jeden z nich jest ustawiony. Albo nie w aplikacji tylko w jakimś checku albo triggerze. Albo idź w stronę jednej relacji Nieruchomość i ewentualnie połączonych z nią relacji na dane specyficzne dla konkretnego typu nieruchomości.
axelbest napisał(a):
Sprzedajesz nieruchomość, nie ma znaczenia czy to dom, mieszkanie, działka czy garaż. Każdy z tych elementów posiada swoją lokalizację określaną przez adres. Każdy ten obiekt ma swój typ. Jeśli działki mają inne pola niż pozostałe typy (albo np dom ma atrybut "ilość pięter", a mieszkanie ma "klatka","piętro") to dorabiasz tabelę(jedną lub więcej) która jest połączona z nieruchomością.
Tylko to są dodatkowe złączenia podczas pobierania danych, no i nie rozwiązuje problemu trzech opcjonalnych kluczy obcych, jedynie przenosi go do innej tabeli.
Podałeś zbyt mało danych na temat wytycznych - bo może w planie masz np zrobić sprzedaż "kilku mieszkań" lub "mieszkanie + działka" w jednej transakcji.
To akurat chyba nie ma wpływu na strukturę przechowywania danych o nieruchomościach.
Aisekai napisał(a):
Rozumiem o co chodzi z nieruchomościami, tylko czy jeżeli połączyłbym relacją (opcjonalną po stronie nieruchomości) z np. działką, encją z polami od domu/mieszkania to czy nie byłoby sytuacji gdzie mogłaby "istnieć sama nieruchomość"? Bez "działki", ilości "pięter" i "klatki"?
Tak, mogłaby. To jest dokładnie taka sama sytuacja jak z Adresem z pierwszego Twojego posta.
BTW, jak dla mnie, to Twoim głównym problemem jest chyba to, że nazywasz klucze obce relacjami.
Bardzo wszystkim dziękuję. Przemyślałem wszystkie porady, oraz zmieniłem sam projekt Bazy Danych.
Ale czy w logicznym modelu, a bardziej relacyjnym (bo na takim robię ten projekt) to relacje "wymuszają" (chyba) pojawienie się kluczy obcych w encjach?
Chyba potrafię rozróżnić klucz obcy od relacji, tylko tutaj bardziej to były skróty myślowe.
Jeszcze raz dzięki wszystkim za porady.