Senaryonun kafası karışmış olan kısmı, supertype-subtype 1 yapısı adı verilen klasik bir yapı ile modellenebilir .
(1) ilgili bazı ön fikirleri tanıtacağım, (2) - kavramsal düzeyde - söz konusu iş bağlamını nasıl tanımlayacağımı detaylandıracağım ve (3) ek ilgili materyaller sunacağım - eg, SQL yoluyla ilgili mantıksal temsil -DDL bildirimleri - aşağıdaki gibi.
Giriş
Belirli bir iş ortamında, bir küme olduğunda, bu tür bir yapı meydana varlık türleri , içinde süpertip bir veya daha fazla özellik (veya öznitelikleri) sahiptir paylaşılan kümede varlık türlerinin geri kalanı tarafından, yani , alt türler . Her alt türün , sırayla, yalnızca kendisine uygulanabilen belirli bir özellik kümesi vardır.
Supertype-subtype kümeleri iki çeşit olabilir:
Özel . Üstünlük türünün bir örneğinin her zaman bir ve yalnızca bir alt tip karşılığı olması gerektiğinde ortaya çıkar; bu nedenle, söz konusu alt tip oluşumları birbirini dışlar . Senaryonuzla ilgili olan budur.
Özel süper tip alt tipi ile ilgili geldiği tipik bir vaka, bir ikisi bir iş alanıdır Organizasyon ve Kişi olarak kabul edilir Yasal Taraf durum görüşülmek olduğu gibi mesajların bu serinin .
Münhasır değil . Bir supertype örneği , her biri farklı bir kategoride olmaya zorlanan birden fazla alt tip oluşumuyla tamamlanabildiğinde kendini sunar .
Süper tip alt tipi bu tür bir örneği ele almaktadır bu mesajların .
Notlar : Bu değer kavramsal karakter-unsurlarını -being o süper tip alt tip yapılar yapmak söz olduğunu değil , belirli bir veri yönetimi teorik çerçeveye aittir o ilişkisel, ağ veya hiyerarşik -her teklifler belli yapılar kavramsal Parçaların temsil etmek üzere ol.
Ayrıca, süper tip alt tip kümelerin nesne yönelimli uygulama programlama (OOP) kalıtımına ve polimorfizmine belirli bir benzerlik göstermesine rağmen, aslında farklı amaçlara hizmet ettikleri için farklı cihazlar olduklarını belirtmek de önemlidir. Bir veritabanı kavramsal modelinde - ki bu gerçek dünya yönlerini temsil etmelidir - bilgi gerekliliklerini tanımlamak için yapısal özellikleri ele alırken, OOP polimorfizmi ve mirasında, diğer şeylerin yanı sıra, bir (a) skeçler ve (b) hesaplama ve davranışsal özellikleri uygular , kesinlikle uygulama programı tasarımı ve programlamasına ait olan yönler.
Bunun dışında, bir uygulama programı bileşeni olan bireysel bir OOP sınıfının , eldeki veritabanının kavramsal düzeyine ait olan bireysel bir varlık türünün yapısını “yansıtması” zorunlu değildir . Bu bağlamda, bir uygulama programcısı tipik olarak iki (veya daha fazla) farklı kavramsal düzey varlık tipinin tüm özelliklerini “birleştiren” tek bir sınıf oluşturabilir ve böyle bir sınıf da hesaplanmış özellikleri içerebilir.
Varlık-ilişki yapılarını, süper-tip-alt yapılarla kavramsal bir modeli temsil etmek için kullanma
Bir varlık-ilişki diyagramı (kısaca ERD) istediniz , ancak olağanüstü bir modelleme platformu olmasına rağmen, Dr. Peter Pin-Shan Chen 2 tarafından sunulan orijinal yöntem , bu tür senaryoları temsil edecek yeterli yapı sağlamamıştır. kavramsal bir modelin gerektirdiği hassasiyetle tartışıldı.
Sonuç olarak, ilk yönteme tekniğini doğal olarak yeni ifade özellikleriyle zenginleştiren gelişmiş varlık-ilişki diyagramlarının (EERD'ler) oluşturulmasına yardımcı olan bir yaklaşımın geliştirilmesiyle sonuçlanan durum, söz konusu yönteme, duruma bazı uzantılar yapmak gerekiyordu. . Bu özelliklerden biri, tam olarak, süper tip-alt tip yapıları tasvir etme olasılığıdır.
İlgi alanınızı modelleme
Şekil 1'de gösterilen çizim , EERD'dir (Ramez A. Elmasri ve Shamkant B. Navathe 3 tarafından önerilenlere benzeyen semboller kullanarak , üst sınıf / alt sınıf olarak bu yapılara atıfta bulunur ); özellikleri. Ayrıca, Dropbox'tan indirilebilen bir PDF olarak da mevcuttur .
Yukarıda belirtilen şemada görebileceğiniz gibi, her ikisi de Groupve superentity türünün özel alt türleri SoloPerformerolarak görüntülenir :Artist
Diyagram açıklaması
EERD'nin açıklamasına başlamak için, cümlenizin
- “Bir Sanatçı olmalıdır ya bir Grup veya (her ikisi de değil) bir SoloPerformer”
ile ilgilidir disjointness ve tamlık eldeki süper tip-alt tip küme yönleri.
Aykırılık
Tam burada, çünkü bahsettiği “veya parça” nedeniyle bir gerçeğine, devreye girer Aykırılık özelliği özellikle önemlidir Artistolmak zorunda ya bir alt tipi örneğini veya ben küçük yoluyla EERD belirtilen diğer, "d" harfini içeren daire, ayrık kuralın adını alan bir yapı .
Bir süper tip olası alt tiplerinden biri veya daha fazlası ile desteklenebiliyorsa, bu nokta örtüşme kuralı adı verilen bir sembol olan “o” harfli bir etiket tutan küçük bir daire ile ifade edilmelidir .
Ayırıcı özelliği
Ayrıca kapsamında Aykırılık bu süper tip alt tip dernek faktör, bu yakın dikkat değer Artist.Typebu düzenlemede bir çok alakalı bir görevi yürütmektedir beri, mülkiyet: alt tür olarak da işlev discriminator . Bu şekilde adlandırılır, belirli bir örneğinin ilişkili olduğu özel alt tür türüne dikkat çeken özelliktir Artist.
Durumlarında münhasır olmayan kümeleri, bir diskriminatör özelliğinin kullanılması (yukarıda yetişmiş gibi) belirli bir süper tıp tamamlayıcılar olarak birden fazla alt tipleri olabilir için, gerek yoktur.
Toplam uzmanlık kuralı ve bütünlüğü
Her Artistbirinin her zaman tamamlayıcı bir alt tür örneğinin olması gerektiğini şart koşan bu kümenin bütünlük özelliği ile ilgilidir. Bu, (a) supertype'i (b) ayrık kural yapısına bağlayan çift hat sembolü ile gösterilen toplam bir uzmanlaşma kuralı ile tanımlanır Artist.
Solo Oyuncularla İlişkili Gruplar
Cümlelerin değerlendirilmesi
- “Bir Grup bir veya daha fazla SoloPerformer'dan oluşur ”
ve
- “Bir SoloPerformer birçok üyesi olabilir Gruplarının hiçbir veya Grubu ”,
Bir iki alt tipleri dahil olduğunu tanıyabilir çok-sayıda I etiketli baklava biçimli kutu ile temsil birlikte (ya da ilişki), (K M) Group-SoloPerformer.
Bir de uygulanırsa ilişkisel bir şekilde veritabanı tabanı tablosundaki, bu bileşen için çok faydalı olacağını derived toplam (hesaplamasını yürütmek için, yani) Numberait SoloPerformersbir beton kadar o marka Group(eğer belirtilen gereksinimleri biri).
Solo Oyuncular ve Çalgılar arasındaki ilişki
Koşul
- “SoloPerformer […] bir veya daha fazla Enstrüman çalabilir”
aynı zamanda,
- “Bir Enstrüman sıfır, bir veya daha fazla SoloPerformer ile çalınır”.
Bu nedenle, bu bir M: N ilişkisinin başka bir örneğidir ve onu SoloPerformer-Instrumentortaya çıkarmak için belirlenmiş elmas şeklindeki figürü kullandım .
Ek malzeme
Süper tip alt tip yapıların kapsamını açıklamak için iki kaynak daha ekleyeceğim, yani,
Şekil 2'de sunulan bir IDEF1X 4 diyagramı ( ve bunu Dropbox'tan PDF olarak da indirebilirsiniz ), söz konusu iş alanıyla ilgili bu tür diyagramların etkileyici yeteneklerini gösteren; ve
SQL veritabanı yönetim sistemi sayesinde tartışma altındaki tüm senaryoyu nasıl yöneteceğinizi gösteren ilgili açıklayıcı DDL mantıksal yapısı.
1. IDEF1X temsili
IDEF1X bilgi modelleme tekniği, bir sınırlama olsa da, süper tip-alt tip yapıları tasvir etme kabiliyetini kesinlikle sunar: hassas bir kümenin özel veya özel olmayan bir tür olup olmadığını göstermek için görsel bir mekanizma sağlamaz (“doğal” sembolleri yalnızca iletişim kurabilir tam veya tamamlanmamış tüm kimlik öneminin olası subentity tipleri). Neyse ki, IDEF1X standardının tanımlayıcı gücünden yararlanırken, bu en önemli yönü daha doğru göstermek için Bilgi Mühendisliği (IE) gösterimi kullanılabilir.
Bu teknikte, sorunuzun ana özelliği, bir üst türün “genel varlık” olarak adlandırıldığı ve bir alt türün “kategori varlık” adını aldığı “sınıflandırma ilişkisi” olarak adlandırılır. Ancak, bu yazıda süper tip-alt tip terimini uygulamaya devam edeceğim çünkü (1) ilişkisel modelin yaratıcısı Dr. Edgar Frank Codd tarafından kullanıldı, (2) daha yaygın olarak biliniyor ve (3) IE notasyonu "yerli" yerine kullanılır.
Yabancı anahtarlar ve süpertip-alt kümeler
Gösterildiği gibi, IDEF1X başka bir avantaj sağlar: YABANCI ANAHTAR (FK) tanımlarını sergileme araçları, eğer bir uygulayıcı ilişkisel bir veritabanında bir süper tip-alt-tip ilişkisini temsil edecekse , en önemli unsurlardır .
Esas bir tür tasvir amacıyla, süper tiplerin birincil anahtar (PK) özelliği, yani Artist.ArtistNumber, zorundadır göç etmek Groupve SoloPerformeriki farklı atanmış edilmiş olmasına rağmen, rol adları 5, 6 , GroupNumberve SoloPerformerNumbervurgulamak amacıyla, sırasıyla anlamı , her subentity türü bağlamında özelliği taşıdığı.
PKs olarak nitelendirilmesinin yanı sıra, Group.GroupNumberve SoloPerformer.SoloPerformerNumberözellikleri, aynı zamanda, Artist.ArtistNumbersüper tip PK özelliğine gönderme yapan YABANCI TUŞLAR ( FK ) olarak tasvir edilir .
Dolayısıyla, her varlıkSoloPerformer ve Groupoluşum kesin bir örneğe bağlı olduğundanArtist , bu varlık türleri , önceki paragraflarda belirtilen PK mülk geçiş süreci yoluyla yürürlüğe giren bir tanımlayıcı ilişkilendirmeye dahil olur .
Yabancı anahtarlar ve ilişkilendirilebilir varlık türleri
IDEF1X diyagramı iki PKleri oluşturan FKS göstermek için de hizmet eder , birleştirici varlık tiplerinin alaka, yani GroupMemberve SoloPerformerInstrument; birincisi iki alt tipi birbirine bağlar ve ikincisi bir alt tipi bağımsız bir varlık tipine bağlar, yani Instrument.
2. Açıklayıcı SQL-DDL mantıksal bildirimleri
Daha önce açıklandığı gibi, bir süper tip-alt yapı, bilgi gereklilikleri ile ilgili belirli türdeki iş alanına özgü kavramsallaştırmaları ifade etmenin bir aracıdır, bu da bir veritabanında belirli kuramsal paradigma (ilişkisel, ağ veya hiyerarşik olsun) ardından tasarımcı tarafından kullanılan veritabanı yönetim sistemi izler.
İlişkisel paradigmanın birçok avantajından biri, bilginin doğal yapısında temsil edilmesine izin vermesidir ve ilişkisel teoride önerilen sistemlere en popüler yaklaşımlar çeşitli SQL veritabanı yönetim sistemleridir.
Son olarak, mantıksal soyutlama düzeyinde, yukarıda ele alınan kavramsal modelleme egzersizini temsil eden (a) temel tablo şemaları ile birlikte (b) ilgili kısıtlamaların bazıları - dahil olmak üzere bazı örnek DDL ifadeleri :
--
--
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)
);
--
--
Veri bütünlüğü ve tutarlılık hususları
Daha önce açıklanmış olanların hepsine uygun olarak, tasarımcı her bir “süper tip” sıranın her zaman beraberindeki “alt tip” karşılığı ile tamamlandığını ve söz konusu “alt tip” sıranın değerle uyumlu olduğundan emin olmalıdır. "tip ayırıcı" sütununda yer alır.
Bahsedilen koşulları deklaratif olarak uygulamak (ilişkisel çerçevenin önerdiği gibi) çok pratik ve zarif olacaktır , ancak, ne yazık ki, büyük SQL platformlarının hiçbiri (bildiğim kadarıyla) bunu yapmak için uygun mekanizmalar sağlamamıştır. Bu nedenle, bu koşulların her zaman bir veritabanında karşılanması için ASİT İŞLEMLERİ kullanmak son derece uygundur (diğer seçenek, TRIGGER'lardan yararlanmak olacaktır, ancak işleri düzensiz yapma eğilimindedir).
Veri türetme hususları
İlişkisel modelin ana yönlerinden biri, veri türetmeyi veri yönetiminde çok önemli bir faktör olarak görmesidir. Buna uygun olarak, (a) yukarıdaki DDL ifadelerinde gösterildiği gibi (a) temel ilişkiler - ya da SQL'de temel tablolar - ve (b) türetilmiş ilişkiler - SQL'de türetilmiş tablolar, yani, daha fazla kullanım için görünüm olarak düzeltildi.
Dolayısıyla, “tam” Grup veri noktalarını toplayan bir görünüm açıklanabilir :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
Ve "full" SoloPerformer bilgi parçalarını birleştiren diğer görünüm :
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;
Bu şekilde, tüm önemli verileri aynı mantıksal düzey aygıt, yani ilişki ya da tablo (temel ya da türetilmiş) aracılığıyla - zorunlu olarak - manipüle etmek çok kolaydır. Açıkçası, ilişkisel bir veritabanında temsil edilen kavramsal varlık türleri daha fazla ilgi alanına sahip olduğunda, görünümlerin kullanımı daha etkilidir, ancak mevcut senaryo ile açıklamaya değer bir olasılıktır.
Referanslar
1 Codd, EF (Aralık 1979). Veritabanı İlişkisel Model genişletme Daha Anlamı Capture , Veri Tabanı Sistemleri ACM İşlemleri , Cilt 4 Sayı 4 (s. 397-434). New York, NY, ABD.
2 Chen, PP (Mart 1976). Varlık-İlişki Modeli-doğru Veri Birleştirilmiş Görünüm , Veri Tabanı Sistemleri ACM İşlemler - Özel sorunu: Çok Büyük veri tabanı oluşturma Uluslararası Konferansı Bildiriler: 22-24 Eylül, 1975, Framingham, MA , Cilt 1 Sayı 1 (sf 9-36). New York, NY, ABD.
3 Elmasri, R & Navathe, SB (2003). Veritabanı Sistemlerinin Temelleri , Dördüncü Baskı. Addison-Wesley Longman Yayıncılık A.Ş., Boston, MA, ABD.
4 Ulusal Standartlar ve Teknoloji Enstitüsü (ABD) [NIST] (Aralık 1993). Bilgi Modellemesi için Entegrasyon Tanımı (IDEF1X), Federal Bilgi İşleme Standartları Yayını , Cilt 184. ABD.
5 Codd, EF (Haziran 1970). Büyük paylaşılan veri Bankaları için Veri ilişkisel model , ACM Communications , Cilt 13 Sayı 6 (s. 377-387). New York, NY, ABD.
6 Bakınız referans 4
