转换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）等，只需将定义添加到查找表中并创建所需的表格和视图。

总之，做不是改造。保留表格并添加可能需要的其他表格以保持严格的数据完整性。 数据完整性是您在数据库设计中的首要任务。