Spesifikasyonlarınız hakkındaki yorumuma göre, iki farklı (ancak bağlantılı ) süper tip-alt tip yapıyı uygulamak için bir yöntem bulmak istiyorsunuz .
Yukarıda bahsi geçen göreve ulaşmak için bir yaklaşım ortaya koymak için, söz konusu senaryoya, adı verilen ve aşağıda ayrıntıları vereceğim iki klasik varsayımsal varlık türü ekleyeceğim.FooBar
İş kuralları
Mantıksal bir model oluşturmama yardımcı olacak birkaç ifade:
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
Mantıksal model
Ve sonra, elde edilen IDEF1X [1] mantıksal modeli Şekil 1'de gösterilmektedir (ve bunu Dropbox'tan PDF olarak da indirebilirsiniz ):
Foo ve Bar ilavesi
Modeli eklemedim Foove Barmodeli daha iyi görünmesini sağladım, ancak daha etkileyici hale getirdim . Aşağıdakiler nedeniyle önemli olduklarını düşünüyorum:
As Ave Badlandırılmış özelliği paylaşan E, bu özellik göstermektedir onlar subentity türleri olduğu ayrı (ancak ilgili) tür kavramının , olay , kişi , ölçüm ben vasıtasıyla temsil, vb Barsuperentity tip sırayla,, yani özniteliği hiyerarşinin üstünde Footutan bir alt öğe türü D.
Yana Ctartışılmakta olan varlık tiplerinin, geri kalanı ile tek hisse fazla özellikte yani D, bu yönü ima bunun başka türlü bir subentity türü olduğunu konsepti , olay , kişi , ölçüm , vb sayesinde bu durumu tasvir Öyle Foosüper varlık türü.
Bununla birlikte, bunlar sadece varsayımlardır ve ilişkisel bir veritabanı belirli bir iş bağlamının anlambilimini doğru bir şekilde yansıtması gerektiği için , belirli bir alanınızdaki tüm ilgi alanlarını tanımlamanız ve sınıflandırmanız gerekir, böylece tam olarak daha fazla anlam yakalayabilirsiniz .
Tasarım aşamasında önemli faktörler
Tüm terminolojiyi bir kenara bırakarak, özel bir süper tip-alt tip kümenin sıradan bir ilişki olduğunun farkında olmak oldukça yararlıdır. Durumu şu şekilde tanımlayalım:
- Her bir ayrıcalıklı üstünlük tipi oluşumu yalnızca bir alt öğe türü tamamlayıcısı ile ilgilidir.
Bu nedenle, bu durumlarda bire bir (1: 1) bir uyum (veya kardinalite) vardır.
Önceki yazılarınızdan bildiğiniz gibi, ayırıcı özelliği (uygulandığında sütun), bu türden bir ilişkilendirme oluştururken çok önemli bir rol oynar , çünkü üst türün bağlandığı doğru alt tür örneğini gösterir . Göç , (i) süper tip birincil anahtar (ii) alt tipleri de belirgin bir etkiye sahip olduğu için.
Beton DDL yapısı
Ve sonra yukarıda sunulan mantıksal modele dayanan bir DDL yapısı yazdım:
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)
);
Bu yapı ile veri tablolarınıza belirsizlik getirecek NULL işaretlerinin temel tablolarınızda (veya ilişkilerinizde ) saklanmasını önlersiniz .
Dürüstlük, tutarlılık ve diğer hususlar
Veritabanınızı uyguladıktan sonra, (a) her bir özel süper tip satırın her zaman karşılık gelen alt tip karşılığı ile tamamlandığından ve (b) bu tür alt satırın üst tür ayırıcı sütununda bulunan değerle uyumlu olduğundan emin olmalısınız. . Bu nedenle, TRANSACTIONSveritabanınızda bu koşulların sağlandığından emin olmak için ACID kullanmak oldukça uygundur .
Veritabanınızın mantıksal sağlamlığını, kendini ifade etmeyi ve doğruluğunu bırakmamalısınız, bunlar kesinlikle veritabanınızı daha sağlam hale getiren unsurlardır.
Önceden gönderilen iki cevap zaten veritabanınızı ve uygulama programlarını tasarlarken, oluştururken ve yönetirken kesinlikle dikkate değer olan ilgili noktaları içerir.
VIEW tanımları yoluyla veri alma
Farklı supertype-subtype gruplarının sütunlarını birleştiren bazı görünümler oluşturabilir , böylece verileri her seferinde gerekli JOIN yan tümcelerini yazmadan elde edebilirsiniz. Bu şekilde, ilgilenilen GÖRÜNÜMDEN ( türetilmiş bir ilişki veya tablo ) doğrudan SEÇ seçebilirsiniz .
Gördüğünüz gibi, “Ted” Codd şüphesiz bir dahiydi. Sahip olduğu araçlar oldukça güçlü ve zariftir ve elbette birbirleriyle iyi entegre edilmiştir.
Alakalı kaynaklar
Süper tip-alt tip ilişkileri içeren bazı kapsamlı veritabanını analiz etmek isterseniz, @PerformanceDBA tarafından önerilen aşağıdaki Yığın Taşma sorularına verilen olağanüstü yanıtlara değer bulabilirsiniz :
Not
1. Bilgi Modellemesi için Entegrasyon Tanımı ( IDEF1X ), Aralık 1993'te Amerika Birleşik Devletleri Ulusal Standartlar ve Teknoloji Enstitüsü ( NIST ) tarafından standart olarak kurulan oldukça tavsiye edilen bir veri modelleme tekniğidir . Kesin olarak aşağıdakilere dayanmaktadır: (a) Dr. EF Codd tarafından yazılan erken teorik materyal; üzerinde (b) Varlık-İlişki tarafından geliştirilen veriler, görüş Dr. PP Chen ; ve ayrıca (c) Robert G. Brown tarafından oluşturulan Mantıksal Veritabanı Tasarım Tekniği. IDEF1X'in birinci dereceden mantık yoluyla resmileştirildiğini belirtmek gerekir.