Отображение родительско-дочерних отношений в составной таблице первичных ключей - PullRequest
0 голосов
/ 13 сентября 2011

У меня есть составная таблица первичных ключей (элементы обслуживания).Я хотел бы создать другую таблицу, которая отображает родительские дочерние отношения между элементами в этой таблице.

Я не уверен, как создать таблицу родительских и дочерних отношений, см. Ниже либо вариант 1, либо вариант 2.

ПРИМЕЧАНИЕ: Наши бизнес-правила предусматривают, что родительские дочерние отношенияможет выходить только между пунктами обслуживания, которые используют одну и ту же программу обслуживания.Это никогда не изменится!

Программы обслуживания таблиц
ProgramCode (первичный ключ)
ProgramDescription
Другие столбцы ...

ТаблицаЭлементы обслуживания (таблица составного первичного ключа)
ProgramCode (составной первичный ключ)
MaintenanceCode (составной первичный ключ)
MaintenanceDescription
Другие столбцы ...

Таблица родительских / дочерних элементов обслуживания (вариант 1)
ProgramCode
ParentMaintenanceCode
ChildMaintenanceCode

Таблица родительских / дочерних элементов обслуживания (вариант 2)
ParentProgramCode (то же значение, что и ChildProgramCode)
ParentMaintenanceCode
ChildProgramCode (то же значение, что и ParentProgramCode)
ChildMaintenanceCode

В таблицах Parent / Child других столбцов не будет, это только таблица сопоставления отношений,

Какой вариант лучше?Вариант 2, кажется, подходит для лучших практик, но, учитывая наше правило бизнеса, мы имеем два столбца с одинаковыми данными (ProgramCode).

Ответы [ 3 ]

2 голосов
/ 13 сентября 2011

Единственная причина для использования ассоциативной сущности, которую вы предлагаете, заключается в том, что вы хотите, чтобы отношения между объектами обслуживания были множественными.Если это то, что вам нужно, то вариант 1 - это то, что вы делаете.Схема будет выглядеть примерно так:

create table MaintenanceProgram
(
  ProgramCode int not null ,

  ... -- other non-key attributes here

  primary key ( ProgramCode ) ,

)
create table MaintenanceItem
(
  ProgramCode     int not null ,
  MaintenanceCode int not null ,

  ... -- other non-key attributes here

  primary key ( ProgramCode , MaintenanceCode ) ,

  foreign key                     ( ProgramCode )
    references MaintenanceProgram ( ProgramCode ) ,

)
create table MaintenanceItemMap
(
  ProgramCode           int not null , 
  ParentMaintenanceCode int not null ,
  ChildMaintenanceCode  int not null ,

  primary key ( ProgramCode , ParentMaintenanceCode , ChildMaintenanceCode ) ,

  foreign key                  ( ProgramCode , ParentMaintenanceCode )
    references MaintenanceItem ( ProgramCode , MaintenanceCode       ) ,
  foreign key                  ( ProgramCode , ChildMaintenanceCode  )
    references MaintenanceItem ( ProgramCode , MaintenanceCode       ) ,

  check ( ParentMaintenanceCode != ChildMaintenanceCode ) ,

)

Это гарантирует, что все связанные элементы обслуживания совместно используют один и тот же программный код и что элемент обслуживания не может быть сопоставлен самому себе (ограничение проверки).

ОднакоВаша постановка проблемы относится к родительским / дочерним отношениям, которые больше похожи на иерархию / дерево.В этом случае схема, которую вы захотите, будет выглядеть примерно так:

create table MaintenanceProgram
(
  ProgramCode int not null ,

  ... -- other non-key attributes here

  primary key ( ProgramCode ) ,

)
create table MaintenanceItem
(
  ProgramCode           int not null ,
  MaintenanceCode       int not null ,
  ParentMaintenanceCode int     null ,

  ... -- other non-key attributes here

  primary key ( ProgramCode , MaintenanceCode ) ,

  foreign key                     ( ProgramCode  )
    references MaintenanceProgram (  ProgramCode ) ,
  foreign key                     ( ProgramCode , ParentMaintenanceCode )
    references MaintenanceItem    ( ProgramCode , MaintenanceCode       ) ,

  check ( MaintenanceCode != ParentMaintenanceCode or ParentMaintenanceCode is null ) ,

)

Выше сказано, что каждый элемент обслуживания связан с одной программой обслуживания;наоборот, что каждая программа обслуживания имеет ноль или более элементов обслуживания.

Кроме того, что каждый элемент обслуживания имеет ноль или 1 родительский элемент обслуживания, что должно относиться к одной и той же программе обслуживания.

Проверочное ограничение говорит, что данный элемент обслуживания не может быть его собственным родителем.

1 голос
/ 13 сентября 2011

Вариант 1 - лучший ответ, вы можете сослаться на ребенка к родителю (и обеспечить ссылочную целостность).Кроме того, если вы используете SQL Server 2005 или более позднюю версию, вы можете использовать рекурсивный CTE для построения иерархии parent / children, если это необходимо для меню, раскрывающихся списков и т. Д.

1 голос
/ 13 сентября 2011

Почему, по вашему мнению, вариант 2 является наилучшей практикой? Если они должны быть одинаковыми, нет смысла помещать их в разные столбцы. Вариант 1 - лучший из 2.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...