Преимущества трансформации-это отношения

Я хотел бы знать, каковы преимущества/влияние производительности при преобразовании иерархии IS_A в отношения. Лучше ли преобразовать, чтобы сохранить 3 таблицы (или), используя отдельные таблицы для преподавателей и студентов?А также если (X,Y) является ключом отношения.Может ли любой из них быть супер ключом к отношениям ?

Персона (Pid, имя, возраст)
Факультет (пид, ранг)
Студент (Pid, gpa)

1 ответ

  1. Много раз за эти годы мне приходило в голову, что лучшие проекты для преобладающей теории и лучшие проекты для практического применения все больше и больше расходятся. Конструкция, которую вы показываете, плохая в том, что она восприимчива к аномалиям данных. Например: ничто не мешает PID члена факультета быть введенным в таблицу студентов и наоборот.

    Должен быть способ указать, что 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 будет только полем 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. Это обеспечивает масштабируемость. Чтобы добавить другие типы сотрудников, секретарей или Хранителей (C) или техническое обслуживание (M) или что-то еще, просто добавьте определение(определения) в таблицу поиска и создайте необходимую таблицу(таблицы) и представление(представления).

    Короче говоря, не трансформируйте. Сохраняйте таблицы и добавляйте любые другие таблицы, которые могут потребоваться для поддержания строгой целостности данных. Целостность данных является вашим главным приоритетом в разработке баз данных.