@ dportas очень хорошо охватил основные моменты.
Вот пример того, как эти таблицы могут быть определены.
create table dbo.Employee
(
EmployeeId int not null primary key,
FirstName nvarchar(100) not null,
LastName nvarchar(100) not null,
Email nvarchar(255) not null,
)
create table dbo.Salary
(
EmployeeId int not null
foreign key references dbo.Employee (EmployeeId),
BeginDate datetime not null,
primary key (EmployeeId, BeginDate),
EmploymentClassificationId int not null
foreign key references dbo.EmploymentClassification (EmploymentClassificationId),
PerWeekAmount money not null,
)
Есть ли что-то еще, что я должен рассмотреть, чтоотносится к дизайну базы данных, который не относится к ООП?
Является ли это приглашение разглагольствовать о дизайне базы данных?Ну ... ОК.
Дизайн базы данных сильно отличается от ООП.БД - это точное представление о состоянии мира, в то время как цель ООП - это сделать что-то.Объект представляет собой сущность, в то время как строка в таблице содержит (надеюсь, истинное) предложение.
Мой совет для проектирования БД заключается в буквальном построении предложения для каждой таблицы, которое точно указывает, что представляет строка в этой таблице.,Затем спроектируйте систему так, чтобы эти предложения всегда были истинными (и любые пропущенные строки в таблице представляют ложные утверждения ).А поскольку таблицы принципиально отличаются от объектов, не бойтесь представлять одну сущность в нескольких таблицах, если это помогает точно представить моделируемые факты.
Часто лучше сосредоточиться на том, какие отчетыследует генерировать на основе данных, а не того, как приложение собирается создавать или использовать данные.
И в базовом отношении NULL означает «неизвестно».Это не значит «не применимо».Если есть место для неприменимых данных, значит что-то не так с дизайном.