Bir veritabanında kalıtımı etkili bir şekilde nasıl modellersiniz?

Veritabanlarında kalıtımı modellemeye yönelik en iyi uygulamalar nelerdir?

Ödünleşimler nelerdir (örneğin sorgulanabilirlik)?

(En çok SQL Server ve .NET ile ilgileniyorum, ancak diğer platformların bu sorunu nasıl ele aldığını da anlamak istiyorum.)

Bir veritabanında kalıtımı modellemenin birkaç yolu vardır. Hangisini seçeceğiniz ihtiyaçlarınıza bağlıdır. İşte birkaç seçenek:

Tür Başına Tablo (TPT)

Her sınıfın kendi tablosu vardır. Temel sınıf, içinde tüm temel sınıf öğelerine sahiptir ve ondan türetilen her sınıfın, aynı zamanda temel sınıf tablosunun yabancı anahtarı olan bir birincil anahtara sahip kendi tablosu vardır; türetilmiş tablonun sınıfı yalnızca farklı öğeleri içerir.

Yani mesela:

class Person {
    public int ID;
    public string FirstName;
    public string LastName;
}

class Employee : Person {
    public DateTime StartDate;
}

Aşağıdaki gibi tablolarla sonuçlanır:

table Person
------------
int id (PK)
string firstname
string lastname

table Employee
--------------
int id (PK, FK)
datetime startdate

Hiyerarşi Başına Tablo (TPH)

Tüm kalıtım hiyerarşisini temsil eden tek bir tablo vardır, bu da birkaç sütunun muhtemelen seyrek olacağı anlamına gelir. Sisteme bunun ne tür bir satır olduğunu söyleyen bir ayırıcı sütun eklenir.

Yukarıdaki sınıflar göz önüne alındığında, bu tabloyla sonuçlanırsınız:

table Person
------------
int id (PK)
int rowtype (0 = "Person", 1 = "Employee")
string firstname
string lastname
datetime startdate

Satır türü 0 (Kişi) olan tüm satırlar için başlangıç ​​tarihi her zaman boş olacaktır.

Beton Başına Tablo (TPC)

Her sınıfın, diğer tablolara referans olmadan kendi tamamen oluşturulmuş tablosu vardır.

Yukarıdaki sınıflar göz önüne alındığında, şu tablolarla sonuçlanırsınız:

table Person
------------
int id (PK)
string firstname
string lastname

table Employee
--------------
int id (PK)
string firstname
string lastname
datetime startdate

Doğru veritabanı tasarımı, doğru nesne tasarımı gibi bir şey değildir.

Veritabanını basitçe nesnelerinizi serileştirmek dışında başka bir amaçla kullanmayı planlıyorsanız (raporlar, sorgulama, çoklu uygulama kullanımı, iş zekası vb.), O zaman nesnelerden tablolara herhangi bir basit eşleştirme önermem.

Pek çok insan bir veritabanı tablosundaki bir satırı bir varlık olarak düşünür (bu terimlerle uzun yıllar boyunca düşündüm), ancak bir satır bir varlık değildir. Bu bir öneridir. Bir veritabanı ilişkisi (yani tablo), dünya hakkında bazı gerçekleri ifade eder. Satırın varlığı gerçeğin doğru olduğunu gösterir (ve tersine, yokluğu gerçeğin yanlış olduğunu gösterir).

Bu anlayışla, nesne yönelimli bir programdaki tek bir türün bir düzine farklı ilişkide saklanabileceğini görebilirsiniz. Ve çeşitli türler (kalıtım, ilişkilendirme, birleştirme ile birleştirilmiş veya tamamen bağımsız) tek bir ilişkide kısmen depolanabilir.

Kendinize, hangi gerçekleri saklamak istediğinizi, hangi soruların yanıtlarını isteyeceğinizi, hangi raporları oluşturmak istediğinizi sormanız en iyisidir.

Uygun DB tasarımı oluşturulduktan sonra, nesnelerinizi bu ilişkilere göre serileştirmenize izin veren sorgular / görünümler oluşturmak basit bir konudur.

Misal:

Bir otel rezervasyon sisteminde, Jane Doe'nin Seaview Inn'de 10-12 Nisan tarihlerinde bir oda için rezervasyonu olduğu gerçeğini kaydetmeniz gerekebilir. Bu, müşteri varlığının bir özelliği mi? Otel varlığının bir niteliği mi? Müşteri ve oteli içeren mülklere sahip bir rezervasyon işletmesi mi? Nesne yönelimli bir sistemdeki bunlardan herhangi biri veya tümü olabilir. Bir veritabanında, bunların hiçbiri değildir. Bu sadece çıplak bir gerçektir.

Farkı görmek için aşağıdaki iki sorguyu düşünün. (1) Jane Doe'nin gelecek yıl için kaç otel rezervasyonu var? (2) Seaview Inn'de 10 Nisan için kaç oda rezerve edildi?

Nesneye yönelik bir sistemde, sorgu (1) müşteri varlığının bir niteliğidir ve sorgu (2), otel varlığının bir özniteliğidir. Bunlar, bu özellikleri API'lerinde açığa çıkaracak nesnelerdir. (Yine de, açıkça bu değerlerin elde edildiği iç mekanizmalar diğer nesnelere referansları içerebilir.)

İlişkisel bir veritabanı sisteminde, her iki sorgu da sayılarını almak için rezervasyon ilişkisini inceler ve kavramsal olarak başka herhangi bir "varlık" ile uğraşmaya gerek yoktur.

Bu nedenle, uygun bir ilişkisel veri tabanının yapılandırılması, varlıkları niteliklerle depolamaya çalışmak yerine, dünya hakkındaki gerçekleri saklamaya çalışmaktır. Düzgün bir şekilde tasarlandıktan sonra, tasarım aşamasında hayal bile edilemeyen faydalı sorgular kolayca oluşturulabilir, çünkü bu sorguları yerine getirmek için gereken tüm gerçekler uygun yerlerinde.

Kısa cevap: yapmıyorsun.

Nesnelerinizi serileştirmeniz gerekiyorsa, bir ORM kullanın veya daha iyisi aktif kayıt veya prevaylence gibi bir şey kullanın.

Verileri depolamanız gerekiyorsa, onu ilişkisel bir şekilde saklayın (ne sakladığınız konusunda dikkatli olun ve Jeffrey L Whitledge'ın az önce söylediklerine dikkat edin), nesne tasarımınızdan etkilenen biri değil.

Brad Wilson'ın da bahsettiği gibi TPT, TPH ve TPC kalıpları gittiğiniz yollardır. Ama birkaç not:

• Bir temel sınıftan miras alan alt sınıflar, veritabanındaki temel sınıf tanımına göre zayıf varlıklar olarak görülebilir, yani temel sınıflarına bağımlıdırlar ve onsuz var olamazlar. Her bir alt tablo için benzersiz kimliklerin depolandığını ve aynı zamanda FK'yi üst tabloda tuttuğunu birkaç kez gördüm. Bir FK yeterlidir ve alt ve temel tablolar arasındaki FK-ilişkisini silmek için kademeli olarak etkinleştirmek daha da iyidir.

• TPT'de, yalnızca temel tablo kayıtlarını görerek, kaydın hangi alt sınıfı temsil ettiğini bulamazsınız. Bu bazen, tüm kayıtların bir listesini yüklemek istediğinizde gereklidir ( select her alt tabloda yapmadan ). Bunu halletmenin bir yolu, alt sınıfın türünü temsil eden bir sütuna sahip olmaktır (TPH'deki rowType alanına benzer), böylece TPT ve TPH'yi bir şekilde karıştırın.

Aşağıdaki şekil sınıfı diyagramını içeren bir veritabanı tasarlamak istediğimizi varsayalım:

public class Shape {
int id;
Color color;
Thickness thickness;
//other fields
}

public class Rectangle : Shape {
Point topLeft;
Point bottomRight;
}

public class Circle : Shape {
Point center;
int radius;
}

Yukarıdaki sınıflar için veritabanı tasarımı şu şekilde olabilir:

table Shape
-----------
int id; (PK)
int color;
int thichkness;
int rowType; (0 = Rectangle, 1 = Circle, 2 = ...)

table Rectangle
----------
int ShapeID; (FK on delete cascade)
int topLeftX;
int topLeftY;
int bottomRightX;
int bottomRightY;

table Circle
----------
int ShapeID; (FK on delete cascade)  
int centerX;
int center;
int radius;

Bir DB'de kurabileceğiniz iki ana kalıtım türü vardır, her varlık için tablo ve Hiyerarşi başına tablo.

Varlık başına tablo, tüm alt sınıfların paylaşılan özelliklerine sahip bir temel varlık tablonuzun olduğu yerdir. Daha sonra, çocuk sınıfa göre her biri yalnızca o sınıfa uygulanabilir özelliklere sahip başka bir tablonuz olur. PK'leri ile 1: 1 bağlantılıdırlar

Hiyerarşi başına tablo, tüm sınıfların bir tablo paylaştığı ve isteğe bağlı özelliklerin null yapılabilir olduğu yerdir. Ayrıca, kaydın şu anda tuttuğu türü belirten bir sayı olan bir ayırt edici alandır.

SessionTypeID ayırıcıdır

Hiyerarşi başına hedefi sorgulamak daha hızlıdır, çünkü birleştirmelere ihtiyacınız yoktur (yalnızca ayırıcı değer), oysa varlık başına hedef, bir şeyin ne tür olduğunu saptamak ve tüm verilerini geri çekmek için karmaşık birleştirmeler yapmanız gerekir.

Düzenleme: Burada gösterdiğim görüntüler, üzerinde çalıştığım bir projenin ekran görüntüleridir. Varlık görüntüsü tam değildir, dolayısıyla boştur, ancak esas olarak tablolarınızın içine ne koyacağınızı değil, nasıl kurulduğunu göstermekti. Bu sana bağlı ;). Oturum tablosu, Sanal işbirliği oturumu bilgilerini içerir ve ne tür bir işbirliğinin dahil olduğuna bağlı olarak birkaç oturum türü olabilir.

Veritabanınızı normalleştirirsiniz ve bu aslında mirasınızı yansıtır. Performans düşüşü olabilir, ancak normalleşmede durum böyledir. Dengeyi bulmak için muhtemelen sağduyulu olmanız gerekecek.

benzer ileti dizisinin tekrarı

VEYA eşlemede, miras, üst ve alt tabloların aynı tanımlayıcıyı kullandığı bir üst tabloyla eşleşir

Örneğin

create table Object (
    Id int NOT NULL --primary key, auto-increment
    Name varchar(32)
)
create table SubObject (
    Id int NOT NULL  --primary key and also foreign key to Object
    Description varchar(32)
)

SubObject, Object ile yabancı anahtar ilişkisine sahiptir. Bir SubObject satırı oluşturduğunuzda, önce bir Object satırı oluşturmalı ve her iki satırda da Id'yi kullanmalısınız.

DÜZENLEME: Davranışı da modellemek istiyorsanız, tablolar arasındaki miras ilişkilerini listeleyen ve her tablonun davranışını uygulayan derleme ve sınıf adını belirten bir Tür tablosuna ihtiyacınız olacaktır.

aşırılık gibi görünüyor, ama bu onu ne için kullanmak istediğinize bağlı!

SQL Simyayı (Python ORM) kullanarak, iki tür kalıtım yapabilirsiniz.

Tecrübe ettiğim tek şey bir tekli masa kullanmak ve ayırt edici bir sütuna sahip olmak. Örnekler için, bir Koyun veritabanı (şaka değil!) Tüm Koyunları tek bir tabloda depoladı ve Koçlar ve Koyunlar bu tablodaki bir cinsiyet sütunu kullanılarak işlendi.

Böylece tüm Koyunları sorgulayabilir ve tüm Koyunları alabilirsiniz. Veya yalnızca Ram ile sorgulayabilirsiniz ve yalnızca Rams'ı alır. Sadece Koç olabilen bir ilişkiye sahip olmak gibi şeyler de yapabilirsiniz (yani, Koyun Efendisi) vb.

Bazı veritabanı motorlarının zaten Postgres gibi yerel olarak miras mekanizmaları sağladığını unutmayın . Bak belgelere .

Örnek olarak, yukarıdaki yanıtta açıklanan Kişi / Çalışan sistemini şu şekilde sorgulayabilirsiniz:

  / * Bu, tüm kişilerin veya çalışanların ilk adını gösterir * /
  Kişiden ad SEÇİN; 

  / * Bu, yalnızca tüm çalışanların başlangıç ​​tarihini gösterir * /
  Çalışandan başlangıç ​​tarihini seçin;

Veritabanınızın seçimi budur, özellikle akıllı olmanıza gerek yoktur!