建模零或一到零或一个关系？那是一件事吗？

Question

我试图为我正在使用的关系数据库找到合适的设计。

定义：

• 客户：进入商店获取服务的人。
• 用户：执行客户要求的服务的人员。
• 预约：客户与用户之间在特定时刻在商店所在地的协议。
• 商店：提供的一组用户 一个地方的服务。
• 服务：技术流程

我尝试支持的用例

• 客户致电商店并设置约会以获取服务 用户。
• 客户走进商店的位置，需要一个 来自用户的服务。

问题： 服务与客户和用户有关系，但约会也是如此（当一个实际存在时）也与服务有关。

因此，如果创建了一个约会，那么创建一个空服务是不对的，因为约会可能会或者可能不会实际通过，我认为该服务将创建大量空行支持约会。服务也不是服务，只要它有用户，客户和约会，它需要一些其他属性才能成为有效的服务。

我还认为在Appoitment和Service中重复用户和客户端是不对的，因为我将来可能会遇到一些完整性问题。

解决这个问题的正确方法是什么？

Answer 1

我从以下开始，随着新业务规则的出现而适应。

首先，客户，Shopes，用户和服务的“基础”表（可以完成的工作）

CLIENT
 ClientId
 Name
 ContactInformation

SHOP
 ShopId
 Name
 OtherAttribues

USER
 UserId
 ShopId  
 Name
 Etc

 (Note: Assumes a user works in only one shop, otherwise you need a many-to-many
  table joining SHOP and USER. See further reminders below.)

SERVICE
 ServiceId
 Name
 FurtherAttributes

 (This is the “master list” of all available services that can be done. “ServiceEvent”
  is used to record actual work being done.)

接下来，复杂的表格：

SERVICEEVENT
 ServiceEventId
 ClientId  (who the work was done for)
 UserId  (who did the work work. Add ShopId if a User can work in multiple shops)
 ServiceId  (what work was done)
 FurtherAttributes  (time, cost, etc.)

(This is used to record actual work that was done--or perhaps, is being done?)

APPOINTMENT
 AppointmentId
 ClientId   (who the work will be done for)
 UserId     (who will be doing the work. Add ShopId if a User can work in multiple shops.)
 ServiceId  (What work will be done)
 ServiceEventId  NULLABLE  (the ServiceEvent, if any, produced by this Appointment)
 Status     (indicate pending, cancelled, completed, etc.)
 FurtherAppointmentAttributes   (when the appointment was made, etc.)
 FurtherServiceEventAttributes  (optional? data used to populate ServiceEvent, when it comes time to do so)

(Should consider creating a lookup table for "Status".)

“约会”和“ServiceEvent”确实是两个截然不同的事情。它们看起来很相似，但每个都可以存在而没有其他（取消约会，步入式服务事件），因此两者都需要所有的密钥。通过Appointments生成的ServiceEvents应该由一个例程创建，该例程从Appointment和INSERTs中读取数据到ServiceEvent。

它们之间的链接（外键）可以在任一表中;我把它放在约会中，因为理想情况下每个约会都会生成一个ServiceEvent，但反之则不然。