轉換IS的優勢關係

Question

我想知道當我們將IS_A層次轉換爲關係時，對優勢/性能的影響是什麼。如果（X，Y）是一個關係的關鍵字，是否更好地轉換爲使用單獨的表格來爲教師和學生保留3個表格？或者如果（X，Y）是關係的關鍵點，它們中的任何一個都可能成爲關係的超級關鍵？

人（PID，姓名，年齡） 學院（PID，秩） 學生（PID，GPA）

Answer 1

通過它發生在我這些年來很多次，對主流理論最好的設計而實際應用的最佳設計則越來越遠。您所展示的設計很差，因爲它容易受到數據異常的影響。例如：沒有什麼能夠阻止教師的PID進入學生表，反之亦然。

必須有一種方法來指定PID是教師或學生（或兩者都允許）。學院和學生的表格必須遵循該規範。

幸運的是，這並不困難。將其稱爲主實體和派生實體之間的混合交集或交叉表。這不僅將派生實體連接到主實體，還定義派生類型。這裏有一個最小的定義：

create table FacultyOrStudent(
    PID  int not null references Person(PID), 
    PersonType char(1) check(PersonType in ('F', 'S')), 
    constraint PK_FacultyOrStudent primary key(PID, PersontType) 
); 

有可能是其他領域，如人員加入教職員工或學生團體的日期。

PK允許同一個人既是教師又是學生。如果不允許這樣做，那麼PK就是PID字段。但是，在這種情況下，（PID，PersonType）將被定義爲唯一的。我會在下面詳細說明。

與標準交集表不同，唯一的外鍵是將PID返回給Person表或主實體。它不能像派生實體那樣在不同的表格中定義爲FK。但是，沒有任何東西阻止我們將它作爲來自其他表格的FK參考目標。因此將（PID，PersonType）定義爲PK或唯一。

在這裏，那麼，是所導出的實體：

create table FacultyPerson(
    PID   int not null primary key, 
    FacultyType char(1) check(FacultyType = 'F'), 
    Rank   ranktype, 
    constraint FK_FacultyToDefinition foreign key(PID, FacultyType) 
    references FacultyOrStudent(PID, PersonType) 
); 

create table StudentPerson(
    PID   int not null primary key, 
    StudentType char(1) check(StudentType = 'S'), 
    GPA   gpatype, 
    constraint FK_StudentToDefinition foreign key(PID, StudentType) 
    references FacultyOrStudent(PID, PersonType) 
); 

相同的PID不能使用一次以上，可以是教員或學生。最重要的是，無法將PID添加到FacultyPerson或StudentPerson表中，該表中先前沒有定義爲FacultyOrStudent表中的教員或學生。

爲了使應用程序開發人員的工作更加容易（並且因爲我的個人規則並非所有應用程序都直接訪問表），請創建兩個視圖，它提供所有教師數據和學生數據。

create view Faculty as 
    select f.PID, p.name, p.age, fp.Rank 
    from FacultyPerson fp 
    join FacultyOrStudent fos 
     on fos.PID = fp.PID 
     and fos.PersonType = fp.FacultyType 
    join Person p 
     on p.PID = fos.PID; 

create view Students as 
    select sp.PID, p.name, p.age, sp.GPA 
    from StudentPerson sp 
    join FacultyOrStudent fos 
     on fos.PID = sp.PID 
     and fos.PersonType = sp.StudentType 
    join Person p 
     on p.PID = fos.PID; 

這允許應用以他們最需要的形式訪問數據。視圖上的觸發器還允許以相同形式的所有DML操作。這些應用程序不需要知道底層數據的實際形式。這爲數據庫開發人員提供了額外的便利，可以自由更改底層數據，而無需擔心對應用程序的影響。只要適當地改變觀點。

我使用的對象的名稱僅用於說明。命名是根據個人喜好和/或公司規則。

我還硬編碼了'F'和'S'值。再次，爲了說明。這些最好放在他們自己的查找表中，將FacultyOrStudent中的字段作爲FK。這允許可擴展性。要添加其他類型的工作人員，祕書（S）或保管（C）或維護（M）等，只需將定義添加到查找表中並創建所需的表格和視圖。

總之，做不是改造。保留表格並添加可能需要的其他表格以保持嚴格的數據完整性。 數據完整性是您在數據庫設計中的首要任務。