DB Design: когда вы должны сделать суперкласс общих атрибутов?

Question

Чтобы описать мою дилемму, позвольте мне сначала начать с примера проблемы (украденной у здесь ). Допустим, в вашей базе данных есть таблица GradStudent, которая выглядит следующим образом:

GradStudent:
firstName
lastName
birthDate
courseAssignment
researchGrant

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

GradStudent:
firstName
lastName
birthDate

TeachAsst:
courseAssignment

ResearchAsst:
researchGrant

Если у TeachAsst и ResearchAsst есть внешний ключ (вероятно, суррогат "studentID") из таблицы GradStudent.

Я также понимаю, почему было бы не лучше создать две совершенно разные таблицы, такие как:

TeachAsst:
firstName
lastName
birthDate
courseAssignment

ResearchAsst:
firstName
lastName
birthDate
researchGrant

Потому что вы повторяете много атрибутов, имеющих одинаковое значение.

Однако два различных класса будут иметь смысл (я думаю), если у них почти нет общих полей, например:

TeachAsst:
name
courseAssignment
payRate
numStudents

ResearchAsst:
name
researchGrant
facultyAdvisor
researchTopic

Здесь у них есть только общее имя, поэтому было бы глупо иметь суперкласс GradStudent только с одним атрибутом name? Где переломный момент? Как вы решаете, когда иметь суперкласс общей информации, или когда два класса должны быть полностью разделены? Наличие суперкласса делает большую часть CRUD немного сложнее, потому что для создания или обновления TeachAsst вам нужно изменить две таблицы вместо одной.

В качестве другого примера, скажем, база данных, над которой вы работаете, включает измерение информации на разных электронных устройствах. И хотя камера и мобильный телефон имеют общую длину / ширину / высоту, большинство других измерений не будут совпадать (например, камера не будет иметь никакой аудиоинформации, а мобильный телефон не будет иметь никаких измерений объектива или области просмотра ). Таким образом, кажется, что намного проще иметь таблицу cameraData и mobileData, которые являются полностью раздельными, чем помещать небольшое количество общей информации в таблицу суперкласса. Как вы думаете? Существует ли общее правило, которое гласит, что вы всегда должны объединять общие данные в суперклассе, даже если это небольшой процент описательных данных подкласса?

Редактировать: Предположим, что в примере аспиранта аспирант является либо помощником преподавателя, либо научным сотрудником, никогда не поменяется ролями, а также никогда не будет ни тем, ни другим.

Answer 1

Я считаю себя относительно новым для проектирования баз данных, так что примите это во что бы то ни стало. В первом примере моей первой мыслью было бы сохранить отдельную таблицу «GradStudent», которая включала бы имя и другую личную информацию. На мой взгляд, это оставляет вас гибкими для потенциальных изменений в будущем. Например, что, если будет создана другая роль GradStudent, которая может выполняться отдельным лицом в дополнение к TeachAsst или ResearchAsst? Вы могли бы создать таблицу «GradStudent_Relationship», которая могла бы разместить дополнительные роли в будущем, например:

GradStudent_Relationship:
GradStudent_ID (fk)
ResearchAsst_ID (fk)
TeachAsst_ID (fk)
NewGradStudentRole_ID (fk)

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

Что касается второго примера, почему у камеры не может быть звука? Разве некоторые цифровые камеры не записывают видео с аудио? Кроме того, почему у мобильного телефона не может быть объектива или измерения в области просмотра? Разве на многих мобильных телефонах нет камер?

Для чего бы это ни стоило, я иногда нахожу полезным абстрагировать «классы» как можно лучше, чтобы поддерживать максимальную гибкость в будущем. Как вы упомянули, вероятно, есть некоторый компромисс в отношении операций CRUD, но лично мне нравится знать, что схема базы данных может обрабатывать потенциальные изменения в будущем.

Надеюсь, это было хоть немного полезно.

Answer 2

В сценарии GradStudent у вас есть следующее свойство:

GradStudent может быть сначала TeachAsst, а позже стать ResearchAsst. Или она может быть обоими одновременно.

В этой ситуации денормализация может быть не очень хорошей идеей.

Тем не менее, в вашем случае вы измеряете камеры и мобильные телефоны. Они никогда не станут чем-то другим. Я думаю, вы могли бы рискнуть денормализацией ради меньшей сложности.

Или вы даже можете подумать об использовании документированной базы данных, например CouchDB , в которой вам не нужно следовать какой-либо схеме.