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:

1. 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.
2. Jeden adres e-mail na profil.
3. Tak. Jak wyżej, organizacja powinna mieć przynajmniej adres e-mail.
4. Prawidłowo, jeden stały adres.
5. 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.

6. 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.

7. 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 .

8. Poprawny.
9. 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?
10. Tak.
11. Zobacz 12.
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.
13. 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.

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…

• Organizacje i profile Wstępny model danych .

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 Profileobecnie jest rozumiany jako synonim Person.

• Jest Organizationprzyjacielem jednego do wielu Profiles .
• Jest Organizationprzyjacielem jednego do wielu Organizations .
• Jest Organizationczłonkiem jeden do wielu Organizations .
• A Profilejest członkiem jeden do wieluOrganizations .
• A Profilejest przyjacielem jednego do wielu Profiles .
• A Profilejest członkiem jeden do wielu Profiles .

Lokalizacje i adresy

• Jest Organizationwłaścicielem jeden do wielu Locations .
• A Locationjest klasyfikowany według jednego do wielu LocationTypes ( tylko jeden w danym momencie).
• LocationMoże mieć jeden-do-wielu Addresses ( jeden Physical , jeden za Shipping, jeden za Billing, 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).

• AddressMogą być przechowywane przez jeden-do-wielu Profiles lub, innymi słowy, A Profileutrzymuje jeden-do-wielu Addresses .

• Konkretny Addressmogą być wykorzystywane przez jeden-do-wielu Profiles (będący Physicalw jednej Profile i stosuje do Billingprzez inny jeden , etc.). Więc Addressdziała w podobny sposób dla Locationsi Profiles.

  • W ten sposób, jednostka Addressmoże być, w tym samym czasie , w rodzaju Physical, Shipping i Billing .

Lokalizacje i role

• LocationOtwiera jeden-do-wielu Roles .
• A Rolemoże być przeprowadzany w trybie jeden do wielu Locations .
• A Profile(po ustawieniu jako Memberan Organization) może przeprowadzać jeden do wielu Roles , jeden do wielu Locations (ale tylko jeden konkretny Rolew każdym Locationw danym momencie, tj. Nigdy dwa lub więcej Roles 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:

1. Zakładam, że termin Profilew twoim kontekście ma podobne (lub takie samo) znaczenie jak Person, ale może być nieco inny. Czy w ten sposób powiedziałbyś, że w twoim scenariuszu podmioty Organizationi Personsą podtypami Profile?

2. Czy Profile(lub Person) może posiadać jeden do wielu EmailAddresses , czy też Profile(lub Person) może być ustawiony na dokładnie jeden EmailAddress ?

3. Czy chciałbyś, aby zapewnić możliwość za Organizationktórą należy się kontaktować za pośrednictwem Telephonea Email, czy chcesz ograniczyć to być możliwe tylko dla Profile(lub Person)?

4. Zakładam, że a Locationjest ustawione na dokładnie jeden Address tego typu Physical, czy to jest poprawne?

5. Czy możliwe Locationjest współdzielenie jednego do wielu różnych, Organizations czy w przeciwnym razie Locationmoże być własnością tylko jednego Organization ?

6. W komentarzach stwierdziłeś, że fakt bycia a Memberi a Friendjest 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ędzy Organizationi Profile(lub Person) 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:

   • Zakładam, że oświadczenie an Organization is a Member of another Organizationma inne skutki niż oświadczenie a Profile (or Person) is a Member of an Organizationdotyczy podmiotu wywoływanego Location.
   • Jak widać w modelu danych, myślę, że Rolez Ownerjest ważna tylko dla Organizationi do mnie, ważne Rolesdla Profile(lub Person), Wewnątrz Locationsą Admini Member. 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.

7. Czy Profile(lub Person) może grać inaczej Rolesw tym samym Location? tzn Czy Personbędzie w tym samym czasie, Admina także Membero tym samym Location? Jakie są zasady w tym zakresie?

8. Myślę, że to samo Profile(lub Person) może grać inaczej Rolesw różnych Locations. Na przykład: Określony Profile(lub Person) to „Administrator” w Location„1”, a ten sam Profile(lub Person) to „ Member” w Location„2” w tym samym czasie. Czy mam rację?

9. Czy jest możliwe, aby konkretny Locationmiał LocationTypesjednocześnie inne, czy też konkretna osoba Locationmoże trzymać dokładnie jeden LocationType?

10. Czy atrybut Organization.Websitereprezentuje adres strony internetowej konkretnej organizacji, takiej jak „dba.stackexchange.com”?

11. Jeśli Profile„1” (rozumiane jako Person) jest Member(lub Friend) z Profile„2”, czy możliwe jest, aby Profile„1” przeprowadził akcję Rolew Locationposiadaniu Profile„2”? Uważam, że takie scenariusze są ważne tylko dla relacji między Organizationai Member Persontak, co sądzisz?

12. W podobny sposób, jeśli Organization„1” jest Member(lub Friend) z Organization„2”, czy możliwe jest, aby Organization„1” przeprowadził akcję Rolew Locationposiadaniu Organization„2”? Ponownie myślę, że tego rodzaju scenariusze są ważne tylko dla relacji między Organizationi a Member Person, czy to prawda?

13. 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 Organizationsi Persons, i możemy zdefiniować:

    • (a) Relacja między Organizationa a Personjako „ Membership”.
    • (b) Związek między a Persona innym innym Personjak „ Friendhip”.
    • (c) Musimy jeszcze znaleźć sensowne imię, aby opisać relację między jednostką Organizationa inną osobą Organization.
    • Więc daj mi znać, co myślisz o (a), (b) i (c).

14. Czy jest możliwe, Organizationaby być Friend(lub a Member) jednym do wielu różnych Organizationsjednocześnie? Lub możliwe jest tylko, Organizationaby 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…

• Organizacje i profile Wstępny model danych - First Advance .

Chociaż nie czuję się jeszcze z tym komfortowo, ten nowy model danych wyraża następujące reguły biznesowe:

• ProfileJest albo Organization lubPerson . ^[2]
• A Profilemoże być przyjacielem oferującym jeden do wielu FriendProfiles , a Profilemoże być przyjacielem przyjmującym jeden do wielu FriendProfiles . ^[3]
• LocationMoże składać się z jednego do wielu Locations . ^[4]

Odpowiedzi na twoje kolejne szczegółowe komentarze

Bardzo interesujące jest dla mnie odnotowanie / złożenie separacji problemów [np. LocationAddress i ProfileAddress] - ponieważ oczywiście chciałem się w pośpiechu i utrzymać je wszystkie bez właściwych relacji [zabawnie, nie było dobrze z moim oryginalnym ERD].

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, Addressjednostka może mieć różne rodzaje powiązań z innymi jednostkami, jedną z drugą, Profilea 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, Addressbyt jest jedną z rzeczy, które uważam za wymagające większej uwagi, ponieważ uważam, że relacja między Profileai Address może być obsługiwana za pomocą Locationbytu (ze względu na fakt, że każdy Locationmusi mieć co najmniej jedną fizyczną Address), dlatego mógł odwołać ProfileAddressasocjacyjną podmiot przedstawiony w najnowszym modelu, ale należy kontynuować analizowanie tych punktów i daj mi znać swoje pomysły.

Ponadto, czy powszechną praktyką w IDEF1X jest zmiana oznaczeń PK / FK w jednostkach dla lepszej czytelności [np. ProfileId - LocationOwnerProfileId]?

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 .

Byłbym zaintrygowany, aby dowiedzieć się, czego nie lubisz / czujesz, że nie modeluje, z / w rozwiązaniu?

Oprócz opisanych już powyżej szczegółów na temat Addresspodmiotu, nie jestem pewien, czy Rolesprzeprowadzona przez dany Profilew sposób szczególny Locationsą równoważne dla Organizationlub Person. Z mojego punktu widzenia Personnajpierw trzeba skojarzyć z Organization, a następnie Organizationmianować powiedziane, Personaby wykonać Rolekonkretny Location, 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, ProfileiLocation, ale rozumiem, że można to uznać za informacje poufne, więc byłoby to ograniczenie.

Przy obecnej strukturze wydaje się, że każdy ( Organizationlub Person) może być powiązany z kimkolwiek (ponownie Organizationlub Person) 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 Profilei Address, ponieważ dane dane Profilesą już powiązane z relacjami jeden do wielu Addresses za pośrednictwem ich własności Locations.

Kolejną zmianą zilustrowaną w tym nowym postępie jest fakt, że obejmuje on teraz możliwość, że dana osoba Locationmoże być własnością jednego do wielu Profiles . W związku z tym zmieniłem LocationKLUCZ PODSTAWOWY (odrzucając LocationOwnerProfileIdatrybut), a następnie dodałem jednostkę asocjacyjną ( wiele do wielu ), która się Profilez tym wiąże Location.

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) .}

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.