Bagian dari skenario yang Anda bingung dapat dimodelkan dengan konstruksi klasik yang disebut struktur supertype-subtype 1 .
Saya akan (1) memperkenalkan beberapa ide awal yang relevan, (2) menjelaskan bagaimana saya akan menggambarkan — pada tingkat konseptual — konteks bisnis yang sedang dipertimbangkan, dan (3) memberikan materi terkait terkait — misalnya, representasi tingkat logis yang sesuai melalui SQL Deklarasi -DDL— sebagai berikut.
pengantar
Struktur sifat ini terjadi ketika, dalam lingkungan bisnis tertentu, ada sekelompok jenis entitas di mana supertype memiliki satu atau lebih properti (atau atribut) yang dibagi oleh sisa jenis entitas dalam cluster, yaitu , subtipe . Setiap subtipe memiliki, pada gilirannya, seperangkat properti tertentu yang hanya berlaku untuk dirinya sendiri.
Cluster Supertype-subtype dapat terdiri dari dua jenis:
Eksklusif . Terjadi ketika sebuah instance dari tipe superentity harus selalu memiliki satu dan hanya satu subtipe; oleh karena itu, kejadian subtipe potensial yang dipertanyakan adalah saling eksklusif . Ini adalah jenis yang berkaitan dengan skenario Anda.
Kasus khas di mana subtipe supertype eksklusif muncul adalah domain bisnis di mana baik Organisasi dan Seseorang dianggap sebagai Pihak Hukum , seperti dalam situasi yang dibahas dalam serangkaian posting ini .
Tidak ada yang eksklusif . Hadir dengan sendirinya ketika instance supertype dapat dilengkapi dengan beberapa kejadian subtipe , yang masing-masing dipaksa dari kategori yang berbeda .
Contoh jenis subtipe supertipe ini dibahas dalam posting ini .
Catatan : Perlu disebutkan bahwa struktur subtipe supertipe — menjadi elemen karakter konseptual — tidak termasuk dalam kerangka kerja teoritis manajemen data tertentu, baik itu relasional, jaringan, atau hierarkis — masing-masing menawarkan struktur tertentu untuk mewakili elemen konseptual—.
Ini juga tepat untuk menunjukkan bahwa meskipun kluster supertipe-subtipe memiliki kemiripan tertentu dengan pewarisan dan aplikasi polimorfisme pemrograman berorientasi objek (OOP) , mereka sebenarnya adalah perangkat yang berbeda karena mereka melayani tujuan yang berbeda. Dalam model konseptual database - yang harus mewakili aspek dunia nyata - seseorang berurusan dengan fitur struktural untuk menggambarkan persyaratan informasi , sedangkan dalam OOP polimorfisme dan pewarisan, antara lain, satu (a) sketsa dan (b) menerapkan karakteristik komputasi dan perilaku , aspek yang jelas milik desain dan pemrograman program aplikasi.
Selain itu, sebuah OOP individu kelas -Menjadi program component- aplikasi, tidak tidak perlu harus “cermin” struktur jenis entitas individu yang dimiliki tingkat konseptual database di tangan. Dalam hal ini, seorang pemrogram aplikasi biasanya dapat membuat, misalnya, satu kelas tunggal yang "menggabungkan" semua properti dari dua (atau lebih) tipe entitas tingkat konseptual yang berbeda, dan kelas semacam itu juga dapat mencakup properti yang dikomputasi.
Menggunakan konstruksi hubungan entitas untuk mewakili model konseptual dengan struktur subtipe-supertipe
Anda meminta diagram hubungan entitas (ERD for brevity) tetapi, meskipun menjadi platform pemodelan yang luar biasa, metode asli - seperti yang diperkenalkan oleh Dr. Peter Pin-Shan Chen 2 - tidak menyediakan konstruksi yang cukup untuk mewakili skenario dari jenis yang sedang dibuat. dibahas dengan presisi yang dibutuhkan oleh model konseptual database.
Akibatnya, perlu untuk membuat beberapa ekstensi untuk metode tersebut, situasi yang menghasilkan hasil dalam pengembangan pendekatan yang membantu dalam pembuatan diagram hubungan entitas yang ditingkatkan (EERDs) yang, secara alami, memperkaya teknik diagram awal dengan karakteristik ekspresif baru . Salah satu karakteristik itu, tepatnya, kemungkinan menggambarkan struktur subtipe-supertipe.
Membuat model konteks minat Anda
Ilustrasi yang ditunjukkan pada Gambar 1 adalah EERD (menggunakan simbol yang mirip dengan yang diusulkan oleh Ramez A. Elmasri dan Shamkant B. Navathe 3 , yang merujuk pada struktur seperti superclass / subclass ) di mana saya memodelkan domain bisnis yang Anda gambarkan dengan mempertimbangkan semua spesifikasi. Ini juga tersedia dalam bentuk PDF yang dapat diunduh dari Dropbox .
Seperti yang Anda lihat pada diagram di atas, keduanya Groupdan SoloPerformerditampilkan sebagai subtipe eksklusif dari Artisttipe superentitas:
Deskripsi diagram
Untuk memulai deskripsi EERD, penting untuk menunjukkan bahwa kalimat Anda
- “Artis harus berupa Grup atau SoloPerformer (tetapi tidak keduanya)”
terkait dengan disjointness dan aspek kelengkapan dari supertype-subtype cluster yang ada.
Ketidakcocokan
Fitur disjointness sangat penting karena di sinilah "atau bagian" yang Anda sebutkan berperan, karena fakta bahwa Artistharus salah satu contoh subtipe atau yang lain, yang saya tentukan dalam EERD melalui kecil lingkaran yang berisi huruf "d", sebuah konstruk yang menerima nama aturan disjoint .
Ketika supertipe dapat dilengkapi dengan satu atau lebih subtipe yang mungkin, titik ini harus dinyatakan oleh lingkaran kecil yang memegang label dengan huruf "o", simbol yang disebut aturan tumpang tindih .
Properti diskriminator
Juga dalam lingkup faktor disjointness dari asosiasi supertipe-subtipe ini, ada baiknya memperhatikan Artist.Typeproperti, karena melakukan tugas yang sangat relevan dalam pengaturan ini: berfungsi sebagai pembeda subtipe . Ini dinamai dengan cara ini karena itu adalah properti yang menunjukkan jenis subtipe eksklusif yang terkait dengan contoh spesifik Artist.
Dalam kasus cluster noneksklusif , penggunaan properti diskriminator tidak perlu, karena supertype tertentu dapat memiliki beberapa subtipe sebagai pelengkap (seperti yang dijelaskan di atas).
Aturan dan kelengkapan spesialisasi total
Persyaratan yang menetapkan bahwa setiap orang Artistharus selalu memiliki turunan subtipe pelengkap berkaitan dengan karakteristik kelengkapan gugus ini. Ini digambarkan dengan menggunakan aturan spesialisasi total , ditunjukkan melalui simbol garis ganda yang menghubungkan (a) Artistsupertype dengan (b) konstruk aturan disjoint.
Menghubungkan Grup dengan Pemain Solo
Mengevaluasi kalimat
- “ Grup terdiri dari satu atau lebih SoloPerformers ”
dan
- “ Pelaku Solo dapat menjadi anggota dari banyak Grup atau tanpa Grup ”,
kita dapat mengenali bahwa kedua subtipe terlibat dalam asosiasi (atau hubungan) banyak-ke-banyak (M: N), yang saya wakili dengan kotak berbentuk berlian yang berlabel Group-SoloPerformer.
Jika diimplementasikan dalam relasional database sebagai sebuah basis tabel, komponen ini akan sangat berguna untuk Turunkan (yaitu, untuk melaksanakan perhitungan) total Numberdari SoloPerformersmake up yang beton Group(salah satu persyaratan yang Anda tentukan).
Hubungan antara Pelaku dan Instrumen Solo
Ketentuannya
- “Seorang SoloPerformer [...] dapat memainkan satu atau lebih Instrumen”
memungkinkan kita menyimpulkan bahwa, pada saat yang sama,
- "Instrumen dimainkan oleh nol, satu atau lebih SoloPerformers".
Jadi, ini adalah contoh lain dari asosiasi M: N, dan saya menggunakan sosok berbentuk berlian yang ditunjuk SoloPerformer-Instrumentuntuk mengeksposnya.
Material tambahan
Untuk menjelaskan ruang lingkup struktur subtipe-supertipe saya akan menyertakan dua sumber daya lagi, yaitu,
diagram IDEF1X 4 yang disajikan dalam Gambar 2 ( dan Anda juga dapat mengunduhnya dari Dropbox sebagai PDF ) yang mengilustrasikan kemampuan ekspresif diagram semacam ini terkait dengan domain bisnis yang dipermasalahkan; dan
struktur logis DDL ekspositoris masing-masing yang mencontohkan bagaimana mengelola skenario penuh dalam diskusi berdasarkan sistem manajemen database SQL.
1. Representasi IDEF1X
Teknik pemodelan informasi IDEF1X tentu saja menawarkan kemampuan untuk menggambarkan struktur subtipe-supertipe, walaupun dengan batasan: teknik peminjaman tidak menunjukkan mekanisme visual untuk menunjukkan apakah kluster yang tepat adalah jenis yang eksklusif atau tidak eksklusif (simbol "asli" -nya hanya dapat berkomunikasi yang lengkap atau tidak lengkap identifikasi semua kemungkinan jenis subentity signifikansi). Untungnya, orang dapat menggunakan notasi Information Engineering (IE) untuk menunjukkan aspek terpenting ini lebih akurat sambil mengambil keuntungan dari kekuatan deskriptif standar IDEF1X.
Dalam teknik ini, fitur utama dari pertanyaan Anda adalah "hubungan kategorisasi" dalam denominasi, di mana supertype disebut sebagai "entitas generik" dan subtipe menerima nama "entitas kategori". Namun, saya akan terus menerapkan istilah supertipe-subtipe dalam posting ini karena (1) digunakan oleh Dr. Edgar Frank Codd, pencetus model relasional, (2) lebih dikenal luas dan (3) notasi IE adalah digunakan bukan yang "asli".
Kunci asing dan klaster supertipe-subtipe
Seperti yang ditunjukkan, IDEF1X memberikan keuntungan lebih lanjut: sarana untuk menunjukkan FOREIGN KEY (FK) definisi, elemen terpenting jika seorang praktisi akan mewakili asosiasi supertype-subtipe dalam relasional database yang.
Untuk menggambarkan asosiasi semacam itu, properti PRIMARY KEY (PK) dari supertype, yaitu Artist.ArtistNumber, harus bermigrasi ke Groupdan SoloPerformer, meskipun telah ditetapkan dua nama peran yang berbeda 5, 6 , GroupNumberdan SoloPerformerNumbermasing - masing, dengan tujuan untuk menekankan yang artinya disampaikan oleh properti dalam konteks masing-masing jenis subentity.
Selain dicirikan sebagai PK, properti Group.GroupNumberdan SoloPerformer.SoloPerformerNumber, pada saat yang sama, digambarkan sebagai KUNCI LUAR NEGERI (FK) yang membuat referensi ke Artist.ArtistNumber, properti PK supertipe.
Jadi, karena setiap SoloPerformerdan Groupkejadian tergantung pada keberadaan pada Artistcontoh yang tepat , tipe entitas ini terlibat dalam asosiasi pengidentifikasi yang berlaku melalui proses migrasi properti PK yang dijelaskan dalam paragraf sebelumnya.
Kunci asing dan jenis entitas asosiatif
Diagram IDEF1X berfungsi juga untuk menggambarkan FK yang menyusun PK dari dua jenis entitas asosiasi yang relevan, yaitu, GroupMemberdan SoloPerformerInstrument; yang pertama menghubungkan dua subtipe, dan yang kedua menghubungkan subtipe dengan tipe entitas independen, yaitu Instrument,.
2. Deklarasi logis Expository SQL-DDL
Seperti dijelaskan sebelumnya, struktur subtipe-supertipe adalah sarana untuk mengekspresikan jenis tertentu konseptualisasi bisnis-domain-spesifik mengenai persyaratan informasi, yang pada gilirannya dapat direpresentasikan dalam basis data dengan menggunakan konstruksi berbeda yang harus sesuai dengan yang ditawarkan oleh pihak tertentu paradigma teoretis (baik relasional, jaringan atau hierarkis) diikuti oleh sistem manajemen basis data yang digunakan oleh perancang.
Salah satu keuntungan berganda dari paradigma relasional adalah bahwa ia memungkinkan merepresentasikan informasi dalam struktur alaminya, dan perkiraan paling populer untuk sistem yang diusulkan dalam teori relasional adalah berbagai sistem manajemen basis data SQL.
Jadi, akhirnya, berikut adalah beberapa contoh pernyataan DDL — termasuk (a) skema tabel dasar bersama dengan (b) beberapa kendala terkait — yang mewakili, pada tingkat abstraksi logis, latihan pemodelan konseptual yang diperlakukan di atas:
--
--
CREATE TABLE Artist ( -- Stands for the supertype.
ArtistNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
Type CHAR(1) NOT NULL, -- Holds the discriminator values.
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Artist_PK PRIMARY KEY (ArtistNumber),
CONSTRAINT Artist_AK UNIQUE (Name), -- ALTERNATE KEY.
CONSTRAINT Artist_Type_CK CHECK (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);
CREATE TABLE MyGroup ( -- Represents one subtype.
GroupNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
FormationDate DATE NOT NULL,
--
CONSTRAINT MyGroup_PK PRIMARY KEY (GroupNumber),
CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
SoloPerformerNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
BirthDate DATE NOT NULL,
--
CONSTRAINT SoloPerformer_PK PRIMARY KEY (SoloPerformerNumber),
CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
MemberNumber INT NOT NULL,
GroupNumber INT NOT NULL,
JoinedDate DATE NOT NULL,
--
CONSTRAINT GroupMember_PK PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT GroupMemberToMyGroup_FK FOREIGN KEY (GroupNumber)
REFERENCES MyGroup (GroupNumber)
);
CREATE TABLE Instrument ( -- Represents an independent entity type.
InstrumentNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
--
CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
CONSTRAINT Instrument_AK UNIQUE (Name) -- ALTERNATE KEY.
);
CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
SoloPerformerNumber INT NOT NULL,
InstrumentNumber INT NOT NULL,
CreatedDate DATE NOT NULL,
--
CONSTRAINT SoloPerformerInstrument_PK PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT SoloPerformerInstrumentToInstrument_FK FOREIGN KEY (InstrumentNumber)
REFERENCES Instrument (InstrumentNumber)
);
--
--
Integritas data dan pertimbangan konsistensi
Dalam perjanjian dengan semua yang telah dijelaskan sebelumnya, perancang harus menjamin bahwa setiap baris “supertype” setiap saat dilengkapi dengan rekanan “subtype” yang menyertainya dan, pada gilirannya, memastikan bahwa baris “subtype” tersebut sesuai dengan nilai. terkandung dalam kolom "diskriminator" supertipe.
Akan sangat praktis dan elegan untuk menegakkan keadaan tersebut secara deklaratif (sebagaimana kerangka kerja mengusulkan) tetapi, sayangnya, tidak ada platform SQL utama yang menyediakan mekanisme yang sesuai untuk melakukannya (sejauh yang saya tahu). Oleh karena itu, sangat nyaman untuk menggunakan TRANSAKSI ASAM sehingga kondisi ini selalu dipenuhi dalam basis data (opsi lain adalah menggunakan PEMICU, tetapi mereka cenderung membuat hal-hal tidak rapi).
Pertimbangan derivasi data
Salah satu aspek utama dari model relasional adalah mempertimbangkan derivasi data sebagai faktor terpenting dalam manajemen data. Sesuai, ia memfasilitasi menciptakan (a) dasar hubungan -atau dasar tabel di SQL, seperti yang ditunjukkan dalam DDL pernyataan di atas dan di (b) berasal hubungan - berasal tabel di SQL, yaitu, mereka menyatakan dengan berkat operasi SELECT yang mungkin ditetapkan sebagai pandangan untuk eksploitasi lebih lanjut—.
Jadi, seseorang dapat mendeklarasikan tampilan yang mengumpulkan poin data Grup "penuh" :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
Dan tampilan lain yang menggabungkan informasi SoloPerformer "penuh" :
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;
Dengan cara ini, sangat mudah untuk memanipulasi —declaratif — semua data signifikan melalui perangkat level logis yang sama, yaitu relasi atau tabel (baik basis atau turunannya). Jelas, penggunaan pandangan lebih efektif ketika jenis entitas konseptual yang diwakili dalam database relasional memiliki lebih banyak sifat yang menarik, tetapi kemungkinan layak diilustrasikan dengan skenario saat ini.
Referensi
1 Codd, EF (Desember 1979). Memperluas Model Relasional Basis Data untuk Mengabadikan Lebih Berarti , Transaksi ACM pada Sistem Basis Data , Volume 4 Edisi 4 (hal. 397-434). New York, NY, AS.
2 Chen, PP (Maret 1976). Model Entity-Relationship — Menuju Pandangan Terpadu Data , Transaksi ACM tentang Sistem Basis Data - Masalah khusus: Makalah dari Konferensi Internasional tentang Pangkalan Data Sangat Besar: 22-24 September 1975, Framingham, MA , Volume 1 Edisi 1 (hal. . 9-36). New York, NY, AS.
3 Elmasri, R & Navathe, SB (2003). Dasar-dasar Sistem Basis Data , Edisi Keempat. Addison-Wesley Longman Publishing Co, Inc. Boston, MA, AS.
4 Institut Standar dan Teknologi Nasional (AS) [NIST] (Desember 1993). Definisi Integrasi untuk Pemodelan Informasi (IDEF1X), Publikasi Standar Pemrosesan Informasi Federal , Volume 184. AS.
5 Codd, EF (Juni 1970). Model Relasional Data untuk Bank Data Besar Bersama , Komunikasi ACM , Volume 13 Edisi 6 (hal. 377-387). New York, NY, AS.
6 Lihat referensi 4
Jawaban dari MDCCL adalah ringkasan luar biasa dari konsep-konsep di balik superclass / subclass atau generalisasi / spesialisasi seperti yang digambarkan pada tingkat EERD.
Jawaban ini dimaksudkan untuk menunjukkan tiga pola desain atau teknik yang perlu diketahui ketika saatnya tiba untuk mengubah EERD menjadi desain relasional, berdasarkan tabel yang ditentukan dengan kolom yang ditentukan.
Inilah ketiganya:
Dua yang pertama adalah alternatif, satu baik untuk kasus-kasus sederhana di mana hampir semua data berkaitan dengan superclass. Yang kedua lebih rumit, tetapi dapat bekerja lebih baik ketika banyak data berkaitan dengan beberapa subkelas. Kata "Warisan" digunakan untuk menunjukkan bahwa desain menyediakan beberapa kekuatan ekspresif yang sama yang akan diberikan warisan dalam model objek.
Kunci utama bersama adalah teknik di mana entri dalam tabel subkelas dapat memperoleh identitas dengan "mewarisi" identitas entri yang sesuai dalam tabel superclass.
Di SO, ada tiga tag dengan nama-nama ini. Tab Info di bawah setiap tag memberikan deskripsi, dan ada banyak pertanyaan yang dikelompokkan di bawah tag.
Ada juga banyak situs web yang menyajikan teknik ini. Saya merekomendasikan yang dari Martin Fowler. Saya suka cara dia menyajikannya. Berikut adalah beberapa halaman web:
Tabel Tunggal Warisan Kelas
sumber