Tworzę schemat pojęciowy [tak, wiem, że zawarłem atrybuty i klucze - ale to tylko dla mnie, aby skonsolidować to, co robię podczas nauki] - więc proszę traktuj to jako koncepcyjne z naciskiem na relacje i relacje tabele, a nie jak rysować;)
Moją przeszkodą jest: staram się ustalić najlepszy sposób modelowania relacji Profil, Lokalizacja i Organizacja.
Przede wszystkim ZASADY:
- Jeden lub więcej profili może być członkiem / przyjacielem jednej lub więcej organizacji ; i wzajemnie.
- Jeden lub więcej profili może być członkiem / przyjacielem innych profili.
- Jedna lub więcej organizacji może być członkiem / przyjacielem innych organizacji.
Znajomi i członkowie różnią się tym, że przyjaciele są jak tylko do odczytu, a członkowie [w zależności od poziomu] mają pełny dostęp do wprowadzania zmian.
Aby jeszcze bardziej skomplikować sytuację, Lokalizacje mają własny zestaw „dalszych” możliwych do ulepszenia reguł, np. Organizacja posiada dwie Lokalizacje , ale w zależności od reguł Lokalizacji Członek [ Profil ] tej organizacji może mieć pełny dostęp w jednej Lokalizacji, ale ograniczony dostęp w inny. [Przepraszamy: najprawdopodobniej będziesz musiał otworzyć obraz w innym oknie, aby uzyskać większy rozmiar oglądania.]
Jak widać, koncepcja profili i organizacji jest w dużej mierze taka sama, a także ta, która ma być jeszcze modelowana koncepcja przyjaciół i członków [... które, jak sądzę, będzie obsługiwane podobnie jak obecne tabele pośrednie z ustawieniem Owner / Administrator / członek / przyjaciel itp. W rejestrze]. Dlatego myślę o następującej koncepcji:
Zobacz opcję 2 na powyższym obrazku: która usunie bieżące tabele organizacji i organizacji_lokalizacji i ich relacje, zastępując ją tabelą organizacji opcji 2 jako nieco rekurencyjną relacją z profilem .
Myślę, że sedno sprawy polega na tym, czy jestem zbyt programowo nastawiony na polimorfizm ze szkodą dla prostoty i elastyczności, całkowicie myląc się w tym procesie;)
Z góry dziękuję za przemyślenia, bardzo mile widziane - M :).
Zmieniony schemat:
W odpowiedzi na pytania MDCCL:
- Tak, Profil składa się z jednej Osoby i ma to samo znaczenie - chociaż tam, gdzie zmierza twoje uzasadnienie - uważam, że masz rację: Organizacja i Osoba mogą być podtypami Profilu ; dlatego Profil składa się albo z jednej Osoby, albo z jednej Organizacji.
- Jeden adres e-mail na profil.
- Tak. Jak wyżej, organizacja powinna mieć przynajmniej adres e-mail.
- Prawidłowo, jeden stały adres.
- Jest to możliwość, ale rzadkość - choć z tego, czego się uczę - należy zatem modelować taką dla przyszłej długowieczności itp., I tylko dla potwierdzenia, Lokalizacja może być własnością więcej niż jednej Osoby.
Lokalizacja jest zdecydowanie integralnym bytem między większością innych. Być może wyjaśnię tu pokrótce, co można zrobić zwięźle, a następnie pozwolę sobie przeczytać inne moje odpowiedzi, które, mam nadzieję, będą najpierw dotyczyły korzystnych dodatków do tego pytania [ następnie zobacz moją odpowiedź do nr 6 na końcu ];) Re: The Role Owner.
An **Organization** can be an Owner of zero or more **Locations**.
A Person can be an owner of zero of more Locations
[dlatego, jak wcześniej przypuszczałeś; najprościej mówiąc, profil może być właścicielem zerowej lub większej liczby lokalizacji / lokalizacji.Tak, profil , który jest Właściciel z Lokalizacja przyjmuje wszystkie ról Uprawnienia [SUPER USER]; Profil że jest Administrator może zmienić niektóre szczegóły dotyczące lokalizacji , ale przede wszystkim pomaga / edytuje Szczegóły / danych dostarczonych przez wszystkich pozostałych profil / s - to przede wszystkim być dostarczane przez „Użytkownik Basic / s” wspomnianej Lokalizacja / s; co pozostawia Basic Member , który może tylko do odczytu wszystkie powiązane szczegóły lokalizacji i dostarczyć dane, które muszą być zbadane przez administratora / właściciela . Poza tym dowolny profil[Organizacja / Osoba] przypomina Członka Podstawowego „tylko do odczytu” - nazwijmy go Gość - ale tylko wtedy, gdy Lokalizacja jest ustawiona jako Publiczna [a nie Prywatna ], chociaż nie mogą dostarczać danych wejściowych tak jak Członek Podstawowy może .
- Poprawny.
- Twoja intuicja jest niesamowita! Tak,
it is foreseen that a single Location could contain one to many LocationTypes
- aby jeszcze bardziej skomplikować - przewiduje się, że te poszczególne typy lokalizacji mogą mieć różne uprawnienia do profili powiązanych z lokalizacją „nadrzędną”; w tym uprawnienia odfiltrowałyby z lokalizacji do typu lokalizacji / s [podobnie jak uprawnienia do zabezpieczeń folderów systemu operacyjnego]. Za pomocą twojego schematu zauważam, że możesz opisywać więcej jako opis? - Tak.
- Zobacz 12.
- Poprawne, zdolność do Profil 1 [osoba lub organizacja] działa na Profile2 [osoba lub organizacja] posiadanych Lokalizacje [jeśli są Friend / Użytkownik z odpowiednimi uprawnieniami] jest najważniejsza.
- Bardzo rozsądne - a) zgadzam się. b) wyrazić zgodę. c) Tak, hmm? ... Może powinno być dokładnie tak samo, jak Profil [osoba] do Profilu [osoba] = Przyjaciele . Niezależnie od opisu, obracałby się on wokół Lokalizacji , ponieważ Organizacja będzie działać na podstawie innej Lokalizacji Organizacji ; chociaż semantycznie wątpię, by jakakolwiek organizacja chciała wyglądać na służącą jako „członek” organizacji tej lokalizacji, aby móc, „bez względu na to, jak dobra jest przyczyna”.
[6]. To wciąż jest dla mnie odrobinę szara, ale oto idzie ... Być może ze szkodą dla mnie, podobieństwo między relacjami między członkiem a przyjacielem jest tak bliskie, że postanowiłem je połączyć; z perspektywy czasu na diagramie i tłumaczeniu wydaje się, że możesz mieć rację, oddzielając je [ zamierzałem rozróżnić pojedynczy związek za pomocą właściwości enum: Właściciel / Administrator / Członek / Przyjaciel ]. Twoja koncepcja, na przykład: Lokalizacja należąca do organizacji będzie miała od zera do wielu Profil [Osoba lub Organizacja] działa na nią, chociaż powinna istnieć wyraźna różnica między sposobem, w jaki Profile działają na lokalizację poprzez jej relację [Członek lub Przyjaciel ] oznaczone przez Role.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.
źródło
Odpowiedzi:
To wspaniałe, że poświęcasz czas na zrozumienie, klasyfikację i modelowanie danych, z którymi masz do czynienia, ponieważ z mojego osobistego doświadczenia wszystko to sprawia, że cały proces rozwoju jest łatwiejszy i bardzo elastyczny na przyszłe zmiany. I jestem całkiem pewien, że już o tym wiecie.
Wstępny model danych i przyjęte reguły biznesowe
Zdefiniowałem listę reguł biznesowych, które przyjąłem po przeczytaniu twojego pytania i dokładnym zbadaniu twoich diagramów, aby opisać moje rozumienie twoich specyfikacji. Po zdefiniowaniu takiej listy wyprowadziłem model danych IDEF1X [1], który postanowiłem załadować jako dokument .PDF na platformę zewnętrzną (Dropbox), ponieważ ze względu na swój format ten model danych nie pasuje dobrze do osadzonego obrazu. Te dwa instrumenty będą przydatne jako odniesienia do niektórych ważnych punktów, które wymienię poniżej w części zatytułowanej Aspekty do rozwiązania w celu dalszego postępu .
Po pierwsze, oto…
Ponieważ jest to tylko to, wstępnie, rozważ to jako środek, który pomoże nam osiągnąć pożądany model danych końcowych.
Zakładane reguły biznesowe
Wspomniany wstępny model danych został wyprowadzony ze zbioru reguł biznesowych (wywnioskowanych z twojego pytania), które wymienię w następujący sposób:
Organizacje i profile
Zauważ, że
Profile
obecnie jest rozumiany jako synonimPerson
.Organization
przyjacielem jednego do wieluProfiles
.Organization
przyjacielem jednego do wieluOrganizations
.Organization
członkiem jeden do wieluOrganizations
.Profile
jest członkiem jeden do wieluOrganizations
.Profile
jest przyjacielem jednego do wieluProfiles
.Profile
jest członkiem jeden do wieluProfiles
.Lokalizacje i adresy
Organization
właścicielem jeden do wieluLocations
.Location
jest klasyfikowany według jednego do wieluLocationTypes
( tylko jeden w danym momencie).Location
Może mieć jeden-do-wieluAddresses
( jedenPhysical
, jeden zaShipping
, jeden zaBilling
, lub jeden , który służy wszystkim wspomnianych celów, lub jeden , który łączy w sobie dwa cele i kolejny, który służy tylko jeden z nich).Address
Mogą być przechowywane przez jeden-do-wieluProfiles
lub, innymi słowy, AProfile
utrzymuje jeden-do-wieluAddresses
.Konkretny
Address
mogą być wykorzystywane przez jeden-do-wieluProfiles
(będącyPhysical
w jednejProfile
i stosuje doBilling
przez inny jeden , etc.). WięcAddress
działa w podobny sposób dlaLocations
iProfiles
.Address
może być, w tym samym czasie , w rodzajuPhysical
,Shipping
iBilling
.Lokalizacje i role
Location
Otwiera jeden-do-wieluRoles
.Role
może być przeprowadzany w trybie jeden do wieluLocations
.Profile
(po ustawieniu jakoMember
anOrganization
) może przeprowadzać jeden do wieluRoles
, jeden do wieluLocations
(ale tylko jeden konkretnyRole
w każdymLocation
w danym momencie, tj. Nigdy dwa lub więcejRoles
w tym samym czasie ).Aspekty do rozwiązania, aby móc iść naprzód
Aby dalej rozwijać rozdzielczość Twojego modelu danych, oto lista istotnych punktów, które po ich opracowaniu pomogą nam osiągnąć ten cel:
Zakładam, że termin
Profile
w twoim kontekście ma podobne (lub takie samo) znaczenie jakPerson
, ale może być nieco inny. Czy w ten sposób powiedziałbyś, że w twoim scenariuszu podmiotyOrganization
iPerson
są podtypamiProfile
?Czy
Profile
(lubPerson
) może posiadać jeden do wieluEmailAddresses
, czy teżProfile
(lubPerson
) może być ustawiony na dokładnie jedenEmailAddress
?Czy chciałbyś, aby zapewnić możliwość za
Organization
którą należy się kontaktować za pośrednictwemTelephone
aEmail
, czy chcesz ograniczyć to być możliwe tylko dlaProfile
(lubPerson
)?Zakładam, że a
Location
jest ustawione na dokładnie jedenAddress
tego typuPhysical
, czy to jest poprawne?Czy możliwe
Location
jest współdzielenie jednego do wielu różnych,Organizations
czy w przeciwnym razieLocation
może być własnością tylko jednegoOrganization
?W komentarzach stwierdziłeś, że fakt bycia a
Member
i aFriend
jest taki sam. Jak widać w moim proponowanym wstępnym modelu danych, śledziłem oryginalne specyfikacje i przedstawiłem wszystkie możliwe kombinacje członkostwa i przyjaźni pomiędzyOrganization
iProfile
(lubPerson
) w różnych podmiotach, ponieważ uważam, że może to być pomocne w określeniu najlepszego możliwego struktura dla tej części twojego scenariusza. W tym sensie:an Organization is a Member of another Organization
ma inne skutki niż oświadczeniea Profile (or Person) is a Member of an Organization
dotyczy podmiotu wywoływanegoLocation
.Role
zOwner
jest ważna tylko dlaOrganization
i do mnie, ważneRoles
dlaProfile
(lubPerson
), WewnątrzLocation
sąAdmin
iMember
. Co o tym sądzisz? Ponieważ masz bezpośredni kontakt z regułami biznesowymi dotyczącymi Twojej sytuacji, musisz mi powiedzieć, czy moje założenia są prawidłowe.Czy
Profile
(lubPerson
) może grać inaczejRoles
w tym samymLocation
? tzn CzyPerson
będzie w tym samym czasie,Admin
a takżeMember
o tym samymLocation
? Jakie są zasady w tym zakresie?Myślę, że to samo
Profile
(lubPerson
) może grać inaczejRoles
w różnychLocations
. Na przykład: OkreślonyProfile
(lubPerson
) to „Administrator” wLocation
„1”, a ten samProfile
(lubPerson
) to „Member
” wLocation
„2” w tym samym czasie. Czy mam rację?Czy jest możliwe, aby konkretny
Location
miałLocationTypes
jednocześnie inne, czy też konkretna osobaLocation
może trzymać dokładnie jedenLocationType
?Czy atrybut
Organization.Website
reprezentuje adres strony internetowej konkretnej organizacji, takiej jak „dba.stackexchange.com”?Jeśli
Profile
„1” (rozumiane jakoPerson
) jestMember
(lubFriend
) zProfile
„2”, czy możliwe jest, abyProfile
„1” przeprowadził akcjęRole
wLocation
posiadaniuProfile
„2”? Uważam, że takie scenariusze są ważne tylko dla relacji międzyOrganization
aiMember
Person
tak, co sądzisz?W podobny sposób, jeśli
Organization
„1” jestMember
(lubFriend
) zOrganization
„2”, czy możliwe jest, abyOrganization
„1” przeprowadził akcjęRole
wLocation
posiadaniuOrganization
„2”? Ponownie myślę, że tego rodzaju scenariusze są ważne tylko dla relacji międzyOrganization
i aMember
Person
, czy to prawda?W związku z tym - pisząc te pytania - myślę, że rozsądnie byłoby powiedzieć, że istnieją tylko trzy różne rodzaje relacji obejmujące
Organizations
iPersons
, i możemy zdefiniować:Organization
a aPerson
jako „Membership
”.Person
a innym innymPerson
jak „Friendhip
”.Organization
a inną osobąOrganization
.Czy jest możliwe,
Organization
aby byćFriend
(lub aMember
) jednym do wielu różnychOrganizations
jednocześnie? Lub możliwe jest tylko,Organization
aby mieć związek tylko z jednym innymOrganization?
Kolejny model danych przedstawiający pierwszy postęp
W nawiązaniu do twoich odpowiedzi i rezolucji dotyczących oczekujących aspektów, które wymieniłem powyżej, stworzyłem następujące…
Chociaż nie czuję się jeszcze z tym komfortowo, ten nowy model danych wyraża następujące reguły biznesowe:
Profile
Jest alboOrganization
lubPerson
. [2]Profile
może być przyjacielem oferującym jeden do wieluFriendProfiles
, aProfile
może być przyjacielem przyjmującym jeden do wieluFriendProfiles
. [3]Location
Może składać się z jednego do wieluLocations
. [4]Odpowiedzi na twoje kolejne szczegółowe komentarze
Tak, to dobre porównanie, chociaż nie nazwałbym tego oddzieleniem problemów (co jest z pewnością podstawową zasadą programowania i projektowania aplikacji), ponieważ termin ten zwykle odnosi się do etapu tworzenia aplikacji i obecnie znajdujemy się w etap zrozumienia danych i zaprojektowania ich logicznej struktury.
Z mojego osobistego doświadczenia uważam, że ta faza ma związek z umieszczeniem istotnych rzeczy w ich całym kontekście, wiąże się z dostrzeżeniem powiązań między różnymi podmiotami, które są istotne w danym scenariuszu zainteresowania, a następnie przedstawiające te rzeczy w modelu danych. W konkretnym przypadku, o którym komentujesz,
Address
jednostka może mieć różne rodzaje powiązań z innymi jednostkami, jedną z drugą,Profile
a drugą z niąLocation
.I tak, gdy coś nie wydaje się właściwe lub naturalne , może to być znak, że należy włożyć więcej wysiłku, aby zrozumieć odpowiednie dane. W ten sposób,
Address
byt jest jedną z rzeczy, które uważam za wymagające większej uwagi, ponieważ uważam, że relacja międzyProfile
aiAddress
może być obsługiwana za pomocąLocation
bytu (ze względu na fakt, że każdyLocation
musi mieć co najmniej jedną fizycznąAddress
), dlatego mógł odwołaćProfileAddress
asocjacyjną podmiot przedstawiony w najnowszym modelu, ale należy kontynuować analizowanie tych punktów i daj mi znać swoje pomysły.Tak, to bardzo sprytna uwaga od ciebie, ponieważ IDEF1X zaleca stosowanie nazw ról do określania KLUCZÓW ZAGRANICZNYCH, aby uchwycić znaczenie takich atrybutów zgodnie z jednostką, w której są używane. Warto również zauważyć, że jest to również silnie związane z koncepcją migracji kluczy podstawowych . W rzeczywistości użycie nazw ról poprzedza IDEF1X, ponieważ zostało pierwotnie zaprezentowane przez dr EF Codda w jego zasadniczym tekście z 1970 roku. W ten sposób wyraźnie widać wierność, jaką standard IDEF1X utrzymuje wobec modelu relacyjnego .
Oprócz opisanych już powyżej szczegółów na temat
Address
podmiotu, nie jestem pewien, czyRoles
przeprowadzona przez danyProfile
w sposób szczególnyLocation
są równoważne dlaOrganization
lubPerson
. Z mojego punktu widzeniaPerson
najpierw trzeba skojarzyć zOrganization
, a następnieOrganization
mianować powiedziane,Person
aby wykonaćRole
konkretnyLocation
, ale znasz scenariusz lepiej, więc zasady te mogą być niepotrzebne. W związku z tym, mam zamiar domagać się o tym, że byłoby to bardzo pomocne dla mnie znać opis kontekstowe lub znaczenia , że użytkownicy przyszłości tej struktury danych daćOrganization
,Profile
iLocation
, ale rozumiem, że można to uznać za informacje poufne, więc byłoby to ograniczenie.Przy obecnej strukturze wydaje się, że każdy (
Organization
lubPerson
) może być powiązany z kimkolwiek (ponownieOrganization
lubPerson
) i może być / rób cokolwiek (Role
) w dowolnym miejscu (Location
), ale perharps, właśnie tego oczekują od ciebie i użytkownicy od tej bazy danych , dla których oczywiście zapewnisz dobrze określone ograniczenia. Jeśli tak, to prawie zapewniamy ostateczne rozwiązanie. Ponieważ oczywiście Twoja opinia jest decydująca w tej sytuacji, powinieneś również przeanalizować te pomysły, a następnie poinformować mnie o swoich wnioskach, abyśmy mogli podjąć ostatnie kroki.Realna druga zaliczka
Niestety, komunikacja zatrzymała się kilka tygodni temu, jak sądzę, z powodu zobowiązań do pracy, które musisz spełnić, co jest całkowicie uzasadnione. Byłbym o wiele bardziej zadowolony, gdybyśmy opracowali bardziej stabilny i solidny model, ale z powodu naszych wcześniejszych interakcji mogę założyć, że byłem w stanie wskazać ci właściwy kierunek.
Oprócz tego, co zostało już przedstawione w tym procesie pytań i odpowiedzi, uważam, że zapewnienie nowych postępów w stosunku do poprzednich modeli danych może być pomocne dla innych osób poszukujących z podobnym problemem. Stworzyłem…
Organizacje i profile Wstępny model danych - drugi postęp
Jak widać w takim modelu danych, usunąłem relację wiele do wielu , którą przedstawiłem w poprzednich modelach pomiędzy
Profile
iAddress
, ponieważ dane daneProfile
są już powiązane z relacjami jeden do wieluAddresses
za pośrednictwem ich własnościLocations
.Kolejną zmianą zilustrowaną w tym nowym postępie jest fakt, że obejmuje on teraz możliwość, że dana osoba
Location
może być własnością jednego do wieluProfiles
. W związku z tym zmieniłemLocation
KLUCZ PODSTAWOWY (odrzucającLocationOwnerProfileId
atrybut), a następnie dodałem jednostkę asocjacyjną ( wiele do wielu ), która sięProfile
z tym wiążeLocation
.Notatki
1. IDEF1X jest wysoce godną polecenia techniką modelowania danych, która została zdefiniowana jako standard w grudniu 1993 r. Przez amerykański Narodowy Instytut Norm i Technologii ( NIST ).
2. Jest to występowanie (super) klastra podtypu typu . Jeśli jesteś zainteresowany, oto odpowiedź, w której szczegółowo omawiam tego rodzaju relacje.
3. Przykład relacji hierarchicznej „wiele do wielu” i jest bardzo podobny do struktury, która dała ostateczne rozwiązanie „problemu eksplozji części” . Takie rozwiązanie zostało oczywiście wprowadzone przez dr Edgara Franka Codda w jego niezwykle wpływowym artykule z 1970 r. „Relacyjny model danych dla dużych wspólnych banków danych” .
4. Jako taki, jest to przykład relacji hierarchicznej jeden do wielu (lub wiele do jednego) .
źródło
Myślę, że próbujesz połączyć koncepcje z modelowania obiektowego i koncepcje z modelowania danych w sposób, który nie pomoże ci wyjaśnić twojego zrozumienia problemu. Mam nadzieję, że uda mi się trochę usunąć bałagan, bez zbytniego poruszania się.
Model relacyjny jako taki nie obsługuje dziedziczenia, nie wspominając o polimorfizmie. Oznacza to, że podczas modelowania rzeczywistej sytuacji życiowej należy zastosować raczej wyspecjalizowany wzorzec projektowy, który łatwo można rozwiązać za pomocą dziedziczenia i polimorfizmu w modelu obiektowym. Więcej o tym specjalnym wzorze później.
Kiedy model ER został opracowany po raz pierwszy, miał być agnostyczną alternatywą dla modelowania relacyjnego. Początkowo też nie miał on czegoś takiego jak dziedzictwo. Ale jakiś czas w latach 80. lub 90. XX wieku model został rozszerzony, aby zapewnić niektóre z tych samych możliwości ekspresyjnych, które można uzyskać dzięki dziedziczeniu. Było to znane jako „rozszerzony model ER”, ale dla wszystkich praktycznych celów dzisiejszy model ER zawiera funkcje EER.
Jedna funkcja EER nosi nazwę „generalizacja / specjalizacja”. Możesz wyszukać i przeczytać tę koncepcję w Internecie. Gen-spec zapewnia tę samą ekspresyjną zdolność, jaką zapewniają klasy i podklasy w modelu obiektowym. Jednak Gen-spec nie zajmuje się problemami związanymi z projektowaniem tabel relacyjnych dla sytuacji gen-spec. Więcej o tym później.
W modelowaniu ER relacja zawsze dotyczy tych samych podmiotów. Dlatego relacja znajomego między organizacją a profilem nie jest tym samym, co relacja znajomego między profilem a innym profilem. Te dwie relacje wymagają różnych nazw. Po prostu zwiąż się w węzły, jeśli nie będziesz przestrzegać tej zasady.
Albo to, albo musisz wymyślić uogólniony byt, którego specjalizacją są organizacje, profile i ewentualnie lokalizacje. Nie rozumiem twojej sprawy wystarczająco dobrze, aby ci w tym pomóc.
Idąc dalej, zauważam, że łączysz swój model relacyjny i model ER razem w jeden model. Robi to większość doświadczonych architektów baz danych. Ale radzę trzymać dwa modele osobno (chociaż godzą się ze sobą), dopóki nie osiągniesz biegłości.
Wreszcie, w jaki sposób zaprojektować tabele relacyjne, które reprezentują sytuację specyficzną dla genów? Spróbuj wyszukać te dwa wzorce projektowe „Dziedziczenie tabeli klas” i „Dziedziczenie tabeli pojedynczej”. Istnieją dwa tagi dla nich w Stackoverflow. Istnieje również kilka całkiem dobrych prezentacji wzorów w Internecie. Szczególnie podoba mi się leczenie Martina Fowlera. Wydaje się, że wie, jak myślą modelerzy obiektów. Mam nadzieję że to pomoże.
źródło