Saya membuat diagram konseptual [ya, saya tahu saya telah memasukkan atribut dan kunci - tetapi ini hanya bagi saya untuk mengkonsolidasikan apa yang saya lakukan saat belajar] - jadi tolong perlakukan itu sebagai Konseptual dengan fokus pada Hubungan dan tabel dan bukan cara diagram;)

Hambatan pikiran saya adalah: Saya mencoba memastikan cara terbaik untuk memodelkan hubungan Profil, Lokasi, dan Organisasi.

Pertama-tama, ATURAN:

• Satu atau lebih Profil dapat menjadi Anggota / Teman dari satu atau lebih Organisasi ; dan sebaliknya.
• Satu atau lebih Profil dapat menjadi Anggota / Teman dari Profil lain.
• Satu atau lebih Organisasi dapat menjadi Anggota / Teman dari Organisasi lain.

Teman dan Anggota berbeda, dalam hal itu, Teman seperti read-only dan Anggota [tergantung pada level] memiliki akses penuh untuk mengubah hal-hal.

Untuk memperumit hal-hal lebih lanjut, Lokasi memiliki seperangkat aturan yang lebih baik "lebih lanjut" misalnya Organisasi memiliki dua Lokasi , tetapi tergantung pada aturan Lokasi, Anggota [ Profil ] dari Organisasi tersebut mungkin memiliki akses penuh di satu Lokasi, tetapi membatasi akses di lain. [Maaf: Anda kemungkinan besar harus membuka gambar di jendela lain untuk ukuran tampilan yang lebih baik.]

Jadi seperti yang Anda lihat, konsep Profil dan Organisasi hampir sama, dan ini belum menjadi model konsep Teman dan Anggota [... yang saya bayangkan akan ditangani seperti tabel perantara saat ini dengan pengaturan Pemilik / Admin / Anggota / Teman dll dalam catatan]. Karenanya, mengapa saya memikirkan konsep berikut:

Lihat Opsi.2 pada gambar di atas: yang akan menghapus Tabel Organisasi dan Organisasi saat ini dan hubungannya, menggantinya dengan Tabel Organisasi Opsi.2 sebagai hubungan yang agak rekursif dengan Profil .

Saya kira inti masalahnya adalah apakah saya terlalu terprogram dengan Polimorfisme sehingga merugikan kesederhanaan dan fleksibilitas, membingungkan diri saya sepenuhnya dalam proses;)

Terima kasih atas pemikiran Anda sebelumnya, sangat dihargai - M :).

Diagram Revisi:

Menanggapi pertanyaan MDCCL:

1. Ya, Profil terdiri dari satu Orang dan memiliki makna yang sama - meskipun ke mana tujuan Anda mengarah - saya yakin Anda benar: Organisasi dan Orang dapat menjadi subtipe Profil ; oleh karena itu, suatu Profil terdiri dari satu Orang, atau satu Organisasi.
2. Satu Alamat Email per Profil.
3. Iya. Seperti di atas, Organisasi setidaknya harus memiliki Alamat Email.
4. Benar, satu alamat tetap.
5. Itu adalah kemungkinan, tetapi jarang - meskipun dari apa yang saya pelajari - karena itu seseorang harus membuat model seperti itu untuk masa depan yang panjang dll, dan hanya untuk mengonfirmasi, Lokasi karena itu dapat dimiliki oleh lebih dari satu Orang.

6. Lokasi jelas merupakan entitas yang tidak terpisahkan di antara sebagian besar lainnya. Mungkin saya akan mengklarifikasi apa yang dapat dilakukan secara ringkas di sini, kemudian membiarkan Anda membaca jawaban saya yang lain yang semoga akan menyinggung penambahan bermanfaat untuk pertanyaan ini terlebih dahulu [ kemudian lihat jawaban saya ke # 6 di bagian akhir ];) Re: Pemilik Peran. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[karena itu, seperti yang Anda duga sebelumnya; sederhananya, sebuah Profil dapat menjadi pemilik nol atau lebih Lokasi.

7. Ya, Profil yang merupakan pemilik dari Lokasi bertanggung Peran Perizinan [super user]; sebuah Profil yang merupakan Admin dapat mengubah rincian tertentu dari lokasi , tetapi terutama membantu / mengedit rincian / data yang diberikan melalui semua lainnya Profil / s - ini terutama akan dipasok oleh 'Basic Anggota / s' dari kata Lokasi / s; yang meninggalkan Anggota Dasar , yang hanya dapat membaca semua detail Lokasi terkait dan menyediakan data yang harus diperiksa oleh Admin / Pemilik . Di luar ini, Profil apa pun[Organisasi / Orang] sangat mirip dengan Anggota Dasar 'read-only' - sebut saja mereka Tamu - tetapi hanya jika Lokasi ditetapkan sebagai Publik [dan bukan Pribadi ], meskipun mereka tidak dapat memberikan input seperti Anggota Basic dapat .

8. Benar.
9. Intuisi Anda luar biasa! Ya, it is foreseen that a single Location could contain one to many LocationTypes- untuk memperumit masalah - diperkirakan bahwa masing-masing LocationTypes tersebut dapat memiliki berbagai izin untuk Profil yang terkait dengan Lokasi 'Induk'; di mana, izin akan disaring dari Lokasi ke LocationType / s [seperti izin keamanan folder OS]. Saya perhatikan melalui diagram Anda, Anda mungkin merujuk untuk mengetik lebih banyak sebagai deskripsi?
10. Iya.
11. Lihat 12.
12. Benar, kemampuan Profile1 [Orang atau Organisasi] untuk bertindak berdasarkan Profile2 [Orang atau Organisasi] yang dimiliki Lokasi [jika mereka Teman / Anggota dengan izin yang benar] adalah yang terpenting.
13. Sangat masuk akal - a) setuju. b) setuju. c) Ya, hmm? ... Mungkin itu harus sama dengan Profil [orang] ke Profil [orang] = Teman . Apa pun deskripsi, itu akan berputar di sekitar Lokasi , karena Organisasi akan bertindak atas Lokasi Organisasi lainnya ; meskipun secara semantik, saya ragu ada Organisasi yang ingin tampil patuh sebagai 'Anggota' dari Organisasi Lokasi itu untuk bisa melakukannya, 'tidak peduli seberapa bagus penyebabnya.'

[6]. Ini masih sedikit abu-abu bagi saya, tapi begini ... Mungkin merugikan saya, kesamaan antara hubungan Anggota / Teman sangat dekat sehingga saya berpikir untuk menggabungkan mereka; di belakang dengan diagram dan interpretasi Anda, tampaknya Anda mungkin benar untuk membuatnya terpisah [ saya akan membedakan hubungan tunggal melalui properti enum: Pemilik / Admin / Anggota / Teman ]. Konsep Anda sebagai misalnya: Lokasi yang Dimiliki oleh Organisasi akan memiliki nol hingga banyak Profil [Orang atau Organisasi] menindaklanjutinya, meskipun harus ada perbedaan yang jelas antara bagaimana Profil bertindak atas lokasi melalui hubungannya [Anggota atau Teman ] dilambangkan melalui Peran.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.

Sangat menyenangkan bahwa Anda meluangkan waktu untuk memahami, mengklasifikasikan dan memodelkan data yang Anda hadapi karena, dari pengalaman pribadi saya, semua ini membuat seluruh proses pengembangan lebih mudah dan sangat fleksibel untuk perubahan di masa depan. Dan saya cukup yakin bahwa Anda juga sudah mengetahui hal ini.

Model data awal dan asumsi aturan bisnis

Saya mendefinisikan daftar aturan bisnis yang telah saya asumsikan setelah membaca pertanyaan Anda dan memeriksa dengan cermat diagram Anda, untuk menjelaskan pemahaman saya tentang spesifikasi Anda. Setelah mendefinisikan daftar tersebut, saya mendapatkan model data IDEF1X ^[1] yang saya putuskan untuk unggah sebagai dokumen .PDF di platform eksternal (Dropbox), karena karena formatnya model data ini tidak cocok dengan gambar yang disematkan. Kedua instrumen ini akan berguna sebagai referensi untuk beberapa poin penting yang saya sebutkan di bawah ini di bagian berjudul Aspek untuk diselesaikan agar dapat terus bergerak maju .

Pertama, ini ...

• Model Data Awal Organisasi dan Profil .

Karena hanya itu, pendahuluan, menganggapnya sebagai sarana membantu kami untuk mencapai model data akhir yang diinginkan.

Aturan bisnis yang diasumsikan

Model data awal tersebut berasal dari kumpulan aturan bisnis (disimpulkan dari pertanyaan Anda) yang akan saya sebutkan sebagai berikut:

Organisasi dan profil

Catatan yang Profilesaat ini dipahami sebagai sinonim untuk Person.

• An Organizationadalah teman satu-ke-banyak Profiles .
• An Organizationadalah teman satu-ke-banyak Organizations .
• An Organizationadalah anggota satu-ke-banyak Organizations .
• A Profileadalah anggota satu-ke-banyakOrganizations .
• A Profileadalah teman satu-ke-banyak Profiles .
• A Profileadalah anggota satu-ke-banyak Profiles .

Lokasi dan alamat

• Sebuah Organizationmemiliki satu-ke-banyak Locations .
• A Locationdiklasifikasikan berdasarkan satu ke banyak LocationTypes ( hanya satu pada titik waktu tertentu).
• A Locationmungkin memiliki satu-ke-banyak Addresses ( satu Physical , satu untuk Shipping, satu untuk Billing, atau satu yang melayani semua tujuan tersebut, atau satu yang menggabungkan dua tujuan dan yang lain hanya melayani satu dari mereka).

• Sebuah Addressdapat disimpan oleh satu-ke-banyak Profiles atau, dengan kata lain, sebuah Profileterus satu-ke-banyak Addresses .

• Sebuah spesifik Addressdapat digunakan oleh satu-ke-banyak Profiles (melayani sebagai Physicaluntuk satu Profile , yang digunakan untuk Billingoleh satu yang berbeda , dll). Jadi, sebuah Addresskarya serupa untuk Locationsdan Profiles.

  • Jadi, seorang individu Addressdapat, pada saat yang sama , bertipe Physical, Shipping dan Billing .

Lokasi dan peran

• A Locationmembuka satu-ke-banyak Roles .
• A Roledapat dilakukan dalam satu-ke-banyak Locations .
• A Profile(setelah ditetapkan sebagai Membera Organization) dapat melakukan satu-ke-banyak Roles , dalam satu-ke-banyak Locations (tetapi hanya satu spesifik Roledi masing-masing Locationpada titik waktu tertentu, yaitu, tidak pernah dua atau lebih Roles pada waktu yang sama ).

Aspek yang harus diselesaikan agar terus bergerak maju

Untuk terus maju dalam resolusi model data Anda, berikut adalah daftar poin yang relevan, setelah kami mengatasinya, akan membantu kami untuk mencapai tujuan ini:

1. Saya berasumsi bahwa istilah Profiledalam konteks Anda memiliki makna yang serupa (atau sama) dengan Person, tetapi mungkin sedikit berbeda. Dengan cara ini, akankah Anda mengatakan bahwa, dalam skenario Anda, entitas Organizationdan Personmerupakan subtipe Profile?

2. Dapatkah Profile(atau Person) sendiri satu-ke-banyak EmailAddresses , atau merupakan Profile(atau Person) tetap untuk tepat satu EmailAddress ?

3. Apakah Anda ingin memberikan kemungkinan untuk Organizationdihubungi melalui Telephonedan Email, atau Anda ingin membatasi itu hanya mungkin untuk Profile(atau Person)?

4. Saya berasumsi bahwa a Locationdiperbaiki ke salah Address satu tipe Physical, apakah ini benar?

5. Apakah mungkin untuk Locationdibagikan oleh satu-ke-banyak berbeda Organizations atau , jika tidak, Locationdapat dimiliki hanya oleh satuOrganization ?

6. Anda telah menyatakan melalui komentar bahwa fakta menjadi Memberdan a Friendadalah sama. Seperti yang dapat Anda lihat dalam model data pendahuluan yang saya usulkan, saya mengikuti Anda spesifikasi asli dan menggambarkan semua kemungkinan kombinasi keanggotaan dan persahabatan antara Organizationdan Profile(atau Person) di entitas yang berbeda karena saya pikir itu dapat membantu dalam upaya menentukan yang terbaik yang mungkin. struktur untuk bagian skenario Anda. Dalam arti ini:

   • Saya berasumsi bahwa pernyataan tersebut an Organization is a Member of another Organizationmemiliki efek yang berbeda dari pernyataan yang a Profile (or Person) is a Member of an Organizationberkaitan dengan entitas yang dipanggil Location.
   • Seperti yang Anda lihat dalam model data, saya berpikir bahwa Roledari Ownerhanya berlaku untuk Organizationdan, bagi saya, berlaku Rolesuntuk Profile(atau Person), di dalam Locationadalah Admindan Member. Apa yang Anda pikirkan tentang semua ini? Karena Anda berhubungan langsung dengan aturan bisnis yang berlaku untuk situasi Anda, Anda perlu memberi tahu saya jika asumsi saya benar.

7. Bisakah Profile(atau Person) bermain berbeda Rolesdi dalam yang sama Location? yaitu, dapatkah Person, pada saat yang sama, Admindan juga Memberdari yang sama Location? Apa aturan dalam hal ini?

8. Saya pikir hal yang sama Profile(atau Person) dapat bermain berbeda Rolesdi berbeda Locations. Misalnya: Yang spesifik Profile(atau Person) adalah "Admin" di Location"1", dan yang sama ini Profile(atau Person) adalah " Member" di Location"2", pada saat yang sama. Apakah saya benar?

9. Apakah mungkin bagi orang tertentu Locationuntuk memiliki perbedaan LocationTypespada saat yang sama, atau apakah seseorang Locationditetapkan untuk memegang tepat satu LocationType?

10. Apakah atribut tersebut Organization.Websitemewakili alamat situs web organisasi tertentu, seperti "dba.stackexchange.com"?

11. Jika Profile"1" (dipahami sebagai Person) adalah Member(atau Friend) dari Profile"2", apakah mungkin bagi Profile"1" untuk melaksanakan suatu Roledalam yang Locationdimiliki oleh Profile"2"? Saya menganggap bahwa skenario seperti itu hanya berlaku untuk hubungan antara Organizationdan Member Person, jadi apa yang Anda pikirkan?

12. Dengan cara yang sama, jika Organization"1" adalah Member(atau Friend) dari Organization"2", apakah mungkin bagi Organization"1" untuk melakukan a Roledi Locationmilik Organization"2"? Sekali lagi, saya pikir skenario semacam ini hanya berlaku untuk hubungan antara a Organizationdan a Member Person, apakah ini benar?

13. Dalam hal ini - ketika saya menulis pertanyaan ini - saya pikir masuk akal untuk mengatakan bahwa hanya ada tiga jenis hubungan yang melibatkan Organizationsdan Persons, dan kita dapat mendefinisikan:

    • (a) Hubungan antara a Organizationdan a Personsebagai " Membership".
    • (B) Hubungan antara a Persondan yang lain berbeda Personsebagai " Friendhip".
    • (c) Kami belum menemukan nama yang bermakna untuk menggambarkan hubungan antara individu Organizationdan orang lain yang berbeda Organization.
    • Jadi, beri tahu saya pendapat Anda tentang (a), (b) dan (c).

14. Apakah mungkin untuk Organizationmenjadi Friend(atau Member) dari satu-ke-banyak yang berbeda Organizationspada saat yang sama? Atau hanya mungkin bagi seseorang Organizationuntuk hanya memiliki hubungan dengan orang yang berbeda secara eksklusifOrganization?

Model data berturut-turut menggambarkan kemajuan pertama

Memperhatikan tanggapan dan resolusi Anda terhadap aspek-aspek yang tertunda yang telah saya sebutkan di atas, saya telah membuat yang berikut ...

• Organisasi dan Profil Model Data Awal - Kemajuan Pertama .

Meskipun saya belum merasa cukup nyaman dengan itu, model data baru ini mengungkapkan aturan bisnis berikut:

• Sebuah Profileadalah salah seorang Organization atau sebuah Person. ^[2]
• A Profilemungkin merupakan teman persembahan satu-ke-banyak FriendProfiles , dan Profilemungkin merupakan teman satu-ke-banyak FriendProfiles . ^[3]
• A Locationdapat terdiri dari satu-ke-banyak Locations . ^[4]

Jawaban untuk komentar spesifik Anda selanjutnya

Sangat menarik bagi saya untuk mencatat / memperparah pemisahan kekhawatiran [mis. LocationAddress dan ProfileAddress] - karena saya jelas ingin bergegas dan menahan mereka semua tanpa hubungan yang benar [lucu, itu tidak terasa benar dengan ERD asli saya].

Ya, itu adalah perbandingan yang baik, meskipun saya tidak akan menyebutnya pemisahan perhatian (yang, tentu saja, prinsip dasar dalam pemrograman aplikasi dan desain), karena istilah ini umumnya berkaitan dengan tahap pengembangan aplikasi dan kami saat ini menemukan diri kami di tahap memahami data dan merancang struktur logisnya.

Dari pengalaman pribadi saya, saya menganggap bahwa fase ini berkaitan dengan menempatkan hal-hal penting ke dalam keseluruhan konteksnya, itu berkaitan dengan melihat asosiasi yang ada di antara entitas yang berbeda yang relevan dalam skenario minat tertentu, dan kemudian menggambarkan hal-hal ini dalam model data. Dalam kasus khusus yang Anda komentari, Addressentitas mungkin memiliki berbagai jenis koneksi dengan entitas lain, satu dengan Profiledan yang berbeda dengan Location.

Dan, ya, ketika sesuatu tidak terasa benar atau alami , itu mungkin merupakan pertanda bahwa seseorang perlu lebih berupaya untuk memahami data terkait. Dengan cara ini, Addressentitas adalah salah satu hal yang saya anggap perlu lebih diperhatikan, karena saya berpikir bahwa hubungan antara a Profiledan a Address dapat ditangani melalui Locationentitas (karena setiap orang Locationharus memiliki setidaknya satu fisik Address), oleh karena itu kami dapat memberhentikan ProfileAddressentitas asosiatif yang digambarkan dalam model terbaru, tetapi Anda harus terus menganalisa poin-poin ini dan memberi tahu saya ide-ide Anda.

Juga, apakah ini merupakan praktik umum dalam IDEF1X untuk mengubah denominasi PK / FK dalam entitas untuk keterbacaan yang lebih baik [misalnya ProfileId - LocationOwnerProfileId]?

Ya, itu adalah komentar yang sangat cerdik dari Anda, karena IDEF1X merekomendasikan penggunaan nama - nama peran untuk mendenominasi KUNCI LUAR NEGERI, untuk menangkap makna atribut tersebut sesuai dengan entitas di mana ia digunakan. Perlu juga dicatat bahwa ini juga sangat terkait dengan konsep migrasi kunci primer . Faktanya, penggunaan nama-nama peran mendahului IDEF1X, karena nama aslinya disajikan oleh Dr. EF Codd dalam teks seminalnya tahun 1970. Dengan cara ini, orang dapat dengan jelas melihat kesetiaan yang dipertahankan oleh standar IDEF1X terhadap model relasional .

Saya akan tertarik untuk mempelajari apa yang tidak terlalu Anda sukai / rasakan tidak sesuai dengan / dengan solusinya?

Selain detail yang sudah dijelaskan di atas tentang Addressentitas, saya tidak yakin apakah yang Rolesdilakukan oleh yang diberikan Profiledalam tertentu Locationsetara dengan Organizationatau Person. Dari sudut pandang saya, yang Personpertama harus dikaitkan dengan Organization, dan kemudian ini Organizationakan menunjuk mengatakan Personuntuk melakukan Rolekhususnya Location, tetapi Anda tahu skenario lebih baik, sehingga aturan ini mungkin tidak perlu. Dalam hal ini, saya akan bersikeras tentang fakta bahwa akan sangat membantu bagi saya untuk mengetahui gambaran kontekstual atau makna bahwa pengguna masa depan struktur data ini memberi untuk Organization, Profile, danLocation, tapi saya mengerti bahwa ini dapat dianggap informasi rahasia, jadi ini akan menjadi batasan.

Dengan struktur saat ini, sepertinya semua orang ( Organizationatau Person) dapat berhubungan dengan siapa saja (lagi, Organizationatau Person) dan dapat / melakukan apa saja ( Role) di mana saja ( Location) tetapi, perharps, ini adalah tepat apa yang Anda dan pengguna harapkan dari database ini , untuk itu Anda akan memberikan batasan yang jelas, tentu saja. Jika ini masalahnya, maka kami hampir memberikan solusi akhir. Karena, tentu saja, pendapat Anda menentukan dalam situasi ini, Anda juga harus menganalisa ide-ide ini dan kemudian biarkan saya tahu kesimpulan Anda sehingga kami dapat mengambil langkah-langkah terakhir.

Kemajuan kedua yang layak

Sayangnya, komunikasi berhenti beberapa minggu yang lalu, saya kira karena komitmen kerja yang harus Anda penuhi, yang benar-benar masuk akal. Saya akan jauh lebih puas jika kami telah mengembangkan model yang lebih stabil dan kuat tetapi, karena interaksi kami sebelumnya, saya dapat berasumsi bahwa saya dapat mengarahkan Anda ke arah yang benar.

Selain apa yang telah disajikan dalam proses tanya jawab ini, saya menganggap bahwa memberikan perkembangan baru dari model data sebelumnya dapat membantu bagi pencari lain dengan masalah yang sama. Jadi, saya telah membuat ...

Organisasi dan Profil Model Data Awal - Kemajuan Kedua

Seperti dapat dilihat dalam model data seperti itu, saya telah menghapus hubungan banyak-ke-banyak yang telah saya gambarkan dalam model sebelumnya antara Profiledan Address, karena yang diberikan Profilesudah terkait dengan satu-ke-banyak Addresses melalui yang dimilikinya Locations.

Perubahan lain yang diilustrasikan dalam kemajuan baru ini adalah kenyataan bahwa sekarang termasuk kemungkinan bahwa suatu pemberian Locationdapat dimiliki oleh satu-ke-banyak Profiles . Akibatnya, saya telah mengubah LocationKUNCI UTAMA (dengan mengabaikan LocationOwnerProfileIdatribut) dan kemudian menambahkan entitas asosiatif ( banyak-ke-banyak ) yang berhubungan Profiledengan Location.

Catatan

_{1. IDEF1X adalah teknik pemodelan data yang sangat direkomendasikan yang didefinisikan sebagai standar pada bulan Desember 1993 oleh Institut Nasional Standar dan Teknologi ( NIST ).}

_{2. Ini adalah kejadian dari kluster subtipe tipe (super) . Jika Anda tertarik, inilah jawaban di mana saya berurusan secara lebih rinci dengan hubungan semacam ini.}

_{3. Contoh hubungan hierarkis banyak-ke-banyak , dan sangat mirip dengan struktur yang memberikan solusi pasti untuk "Masalah Eksplorasi Bagian" . Solusi semacam itu, tentu saja, diperkenalkan oleh Dr. Edgar Frank Codd dalam makalahnya tahun 1970 yang sangat berpengaruh “Model Data Relasional untuk Bank Data Bersama Besar” .}

_{4. Dengan demikian, ini adalah contoh dari hubungan hierarkis satu-ke-banyak (atau banyak-ke-satu) .}

Saya pikir Anda mencoba untuk menggabungkan konsep-konsep dari pemodelan objek dan konsep-konsep dari pemodelan data dengan cara yang tidak membantu Anda untuk memperjelas pemahaman Anda sendiri tentang masalah tersebut. Saya harap saya bisa membersihkan sedikit kekacauan tanpa terlalu banyak bertele-tele.

Model relasional, dengan demikian, tidak mendukung pewarisan, apalagi polimorfisme. Ini berarti bahwa pola desain yang agak khusus harus digunakan ketika memodelkan situasi kehidupan nyata yang mudah ditangani oleh pewarisan dan polimorfisme dalam model objek. Lebih lanjut tentang pola desain khusus nanti.

Ketika model ER pertama kali dikembangkan, itu seharusnya menjadi alternatif implementasi agnostik untuk pemodelan relasional. Pada awalnya, itu tidak memiliki warisan seperti apa pun. Tetapi beberapa waktu di tahun 1980-an atau 1990-an, model ini diperluas untuk memberikan beberapa kemampuan ekspresif yang sama yang Anda dapatkan dengan warisan. Ini dikenal sebagai "model extended ER", tetapi untuk semua tujuan praktis, model ER saat ini mencakup fitur EER.

Satu fitur EER menggunakan nama "generalisasi / spesialisasi". Anda dapat mencari dan membaca konsep ini di web. Gen-spec menyediakan banyak kemampuan ekspresif yang sama yang disediakan oleh kelas dan subclass dalam model objek. Namun, Gen-spec tidak berurusan dengan masalah seputar desain tabel relasional untuk situasi gen-spec. Lebih lanjut tentang itu nanti.

Dalam pemodelan ER, hubungan selalu melibatkan entitas yang sama. Karenanya, hubungan pertemanan antara suatu organisasi dan suatu profil tidak sama dengan hubungan pertemanan antara suatu profil dan profil lainnya. Dua hubungan membutuhkan nama yang berbeda. Anda hanya akan mengikat diri sendiri dalam simpul jika Anda tidak mengikuti aturan ini.

Entah itu, atau Anda harus datang dengan entitas umum yang Organisasi, Profil, dan mungkin Lokasi semua spesialisasi. Saya tidak mengerti kasus Anda dengan cukup baik untuk membantu Anda.

Selanjutnya, saya perhatikan bahwa Anda menggabungkan model relasional dan model ER Anda menjadi satu model. Sebagian besar arsitek database berpengalaman melakukan ini. Tapi saya menyarankan Anda untuk menjaga dua model terpisah (meskipun berdamai satu sama lain) sampai Anda memperoleh kemahiran.

Akhirnya, bagaimana seseorang mendesain tabel relasional yang mewakili situasi gen-spec? Coba cari dua pola desain ini "Class-table-inheritance" dan "Single-Table-Inheritance". Ada dua tag untuk ini lebih dalam di Stackoverflow. Ada juga beberapa presentasi pola yang cukup bagus di web. Saya terutama menyukai perawatan Martin Fowler. Dia tampaknya tahu bagaimana pemodel objek berpikir. Semoga ini membantu.