Menurut interpretasi saya tentang spesifikasi Anda, Anda ingin menemukan metode untuk mengimplementasikan dua struktur subtipe-subtipe supertipe yang berbeda (namun terhubung ) .
Untuk mengekspos pendekatan untuk mencapai tugas yang disebutkan, saya akan menambah skenario yang dipermasalahkan dua tipe entitas hipotetis klasik yang disebut Foodan Bar, yang akan saya jelaskan di bawah.
Peraturan bisnis
Berikut adalah beberapa pernyataan yang akan membantu saya membuat model yang logis:
A Foo is either one Bar or one CA Foo is categorized by one FooTypeA Bar is either one A or one CA Bar is classified by one BarType
Model yang logis
Dan kemudian, model logis IDEF1X [1] yang dihasilkan ditunjukkan pada Gambar 1 (dan Anda juga dapat mengunduhnya dari Dropbox sebagai PDF ):
Tambahan Foo and Bar
Saya tidak menambah Foodan Barmembuat model terlihat lebih baik, tetapi untuk membuatnya lebih ekspresif. Saya menganggap mereka penting karena hal berikut:
Saat Adan Bmembagikan atribut yang dinamai E, fitur ini menunjukkan bahwa mereka adalah tipe subentitas dari konsep , peristiwa , orang , pengukuran , dll. Yang berbeda, yang saya wakili dengan menggunakan Bartipe superentity yang, pada gilirannya, adalah tipe subentity Foo, yang menyimpan Datribut di bagian atas hierarki.
Sejak Chanya saham satu atribut dengan sisa jenis entitas di bawah diskusi, yaitu, D, aspek ini menyindir bahwa itu adalah jenis subentity dari jenis lain dari konsep , acara , orang , pengukuran , dll, jadi saya digambarkan keadaan ini berdasarkan yang Foosuper entitas jenis.
Namun, ini hanya asumsi, dan karena database relasional dimaksudkan untuk mencerminkan semantik konteks bisnis tertentu secara akurat, Anda harus mengidentifikasi dan mengklasifikasikan semua hal yang menarik di domain spesifik Anda sehingga Anda dapat, tepatnya, menangkap lebih banyak makna .
Faktor penting pada fase desain
Sangat berguna untuk menyadari fakta bahwa, dengan mengesampingkan semua terminologi, klaster supertipe-subtipe eksklusif adalah hubungan biasa. Mari kita gambarkan situasi dengan cara berikut:
- Setiap kejadian jenis superentitas eksklusif terkait dengan hanya satu jenis pelengkap subentitas .
Dengan demikian, ada korespondensi (atau kardinalitas) dari satu-ke-satu (1: 1) dalam kasus ini.
Seperti yang Anda ketahui dari posting sebelumnya, atribut diskriminator (kolom, ketika diimplementasikan) memainkan peran penting ketika membuat asosiasi dari sifat ini, karena itu menunjukkan contoh subtipe yang benar dengan mana supertipe terhubung . The migrasi dari PRIMARY KEY dari (i) supertype untuk (ii) subtipe juga penting utama.
Struktur DDL beton
Dan kemudian saya menulis struktur DDL yang didasarkan pada model logis yang disajikan di atas:
CREATE TABLE FooType -- Look-up table.
(
FooTypeCode CHAR(2) NOT NULL,
Description CHAR(90) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_FooType PRIMARY KEY (FooTypeCode),
CONSTRAINT AK_FooType_Description UNIQUE (Description)
);
CREATE TABLE Foo -- Supertype
(
FooId INT NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
FooTypeCode CHAR(2) NOT NULL, -- Discriminator column.
D INT NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_Foo PRIMARY KEY (FooId),
CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
REFERENCES FooType (FooTypeCode)
);
CREATE TABLE BarType -- Look-up table.
(
BarTypeCode CHAR(1) NOT NULL,
Description CHAR(90) NOT NULL,
CONSTRAINT PK_BarType PRIMARY KEY (BarTypeCode),
CONSTRAINT AK_BarType_Description UNIQUE (Description)
);
CREATE TABLE Bar -- Subtype of ‘Foo’.
(
BarId INT NOT NULL, -- PK and FK.
BarTypeCode CHAR(1) NOT NULL, -- Discriminator column.
E INT NOT NULL, -- Column that applies to ‘A’ and ‘B’.
CONSTRAINT PK_Bar PRIMARY KEY (BarId),
CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
REFERENCES Foo (FooId),
CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
REFERENCES BarType (BarTypeCode)
);
CREATE TABLE A -- Subtype of ‘Bar’.
(
AId INT NOT NULL, -- PK and FK.
X INT NOT NULL, -- Particular column.
CONSTRAINT PK_A PRIMARY KEY (AId),
CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
REFERENCES Bar (BarId)
);
CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
BId INT NOT NULL, -- PK and FK.
Y INT NOT NULL, -- Particular column.
CONSTRAINT PK_B PRIMARY KEY (BId),
CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
REFERENCES Bar (BarId)
);
CREATE TABLE C -- Subtype of ‘Foo’.
(
CId INT NOT NULL, -- PK and FK.
Z INT NOT NULL, -- Particular column.
CONSTRAINT PK_C PRIMARY KEY (CId),
CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
REFERENCES Foo (FooId)
);
Dengan struktur ini, Anda menghindari penyimpanan tanda NULL di tabel dasar (atau relasi ) Anda, yang akan menimbulkan ambiguitas pada basis data Anda.
Integritas, konsistensi, dan pertimbangan lain
Setelah Anda menerapkan basis data Anda, Anda harus memastikan bahwa (a) setiap baris supertype eksklusif selalu dilengkapi oleh mitra subtipe yang sesuai dan, pada gilirannya, menjamin bahwa (b) baris subtipe tersebut kompatibel dengan nilai yang terkandung dalam kolom diskriminator supertype. . Oleh karena itu, cukup mudah untuk menggunakan ACID TRANSACTIONSuntuk memastikan bahwa kondisi ini terpenuhi dalam database Anda.
Anda tidak boleh menyerah pada kesehatan logis, ekspresi diri, dan akurasi database Anda, ini adalah aspek yang jelas membuat database Anda lebih solid.
Dua jawaban yang diposting sebelumnya sudah termasuk poin terkait yang tentu saja layak dipertimbangkan ketika merancang, membuat dan mengelola basis data Anda dan program aplikasinya.
Mengambil data dengan cara LIHAT definisi
Anda dapat mengatur beberapa tampilan yang menggabungkan kolom dari kelompok subtipe-supertipe yang berbeda , sehingga Anda dapat mengambil data secara langsung tanpa, misalnya, menulis klausa JOIN yang diperlukan setiap waktu. Dengan cara ini, Anda dapat PILIH langsung DARI VIEW ( relasi turunan atau tabel ) yang menarik dengan mudah.
Seperti yang Anda lihat, "Ted" Codd, tidak diragukan lagi, seorang jenius. Alat yang diwariskannya cukup kuat dan elegan, dan, tentu saja, terintegrasi dengan baik satu sama lain.
Sumber terkait
Jika Anda ingin menganalisis beberapa basis data yang luas yang melibatkan hubungan supertype-subtype, Anda akan menemukan nilai dari jawaban luar biasa yang diajukan oleh @PerformanceDBA untuk pertanyaan Stack Overflow berikut:
Catatan
1. Definisi Integrasi untuk Pemodelan Informasi ( IDEF1X ) adalah teknik pemodelan data yang sangat direkomendasikan yang ditetapkan sebagai standar pada bulan Desember 1993 oleh Institut Standar dan Teknologi Nasional ( NIST ) Amerika Serikat . Ini didasarkan pada (a) bahan teoretis awal yang ditulis oleh Dr. EF Codd; pada (b) yang Entity-Relationship tampilan data, yang dikembangkan oleh Dr. PP Chen ; dan juga pada (c) Teknik Desain Basis Data Logis, yang dibuat oleh Robert G. Brown. Perlu dicatat bahwa IDEF1X diformalkan dengan cara logika tingkat pertama.