一个主要涉及到一对多关系的数据库设计

Question

大家好，遇到一个数据库设计方面的问题，没想到太好的解决办法，希望大家给点建议。一个小模块，关于气象观测方面的。
一个气象台站对应着多种观测业务（如地面观测、酸雨观测等）；
一个观测业务可能会发多种报文（如酸雨观测可能会发酸雨日报、酸雨月报、年报等）；
一种报文可能对应着不同的发送时次（如天气预报，一天发4次，22点、02点、07点、08点）；关联为：台站  -  观测业务  -  报文  - 时次
各自关系：台站  -  观测业务       |      观测业务  -  报文     |    报文    -   时次
 1         n            |          1         n       |     1           n如果放一张表，最终的数据为：  台站号         观测业务         报文           时次
---------------------------------------------------------
  54511          地面观测         SI            00
  54511          地面观测         SI            06
  54511          地面观测         SI            12
  54511          地面观测         SI            18
  54511          地面观测         SX            00
  54511          地面观测         SX            08
  54511          地面观测         SX            16
  54511          地面观测         SM            00
  54511          地面观测         SM            02
  54511          地面观测         UP            00
  54511          地面观测         UP            12
  54511          地面观测         CS            00
我模拟了一下XML存储的形式：<台站-观测业务-报文-时次>
<台站 名称="北京气象站">
<观测业务 名称="地面观测">
<发送报文 名称="天气预报">
<时次 发送时间="22" />
<时次 发送时间="02" />
<时次 发送时间="07" />
<时次 发送时间="08" />
</发送报文>
<发送报文 名称="地面报（SI）">
<时次 发送时间="00" />
<时次 发送时间="06" />
<时次 发送时间="12" />
<时次 发送时间="18" />
</发送报文>
<发送报文 名称="地面报（SM）">
<时次 发送时间="00" />
<时次 发送时间="08" />
<时次 发送时间="16" />
</发送报文>
</观测业务>
<观测业务 名称="酸雨观测">
<发送报文 名称="酸雨日报">
<时次 发送时间="22" />
</发送报文>
</观测业务>
</台站>
</台站-观测业务-报文-时次>
像上面XML这样存储较直观，但在数据库中该如何设计呢？
我总觉得像上面那样一张表存储完不太好。

Answer 1

 DataSet myds = new DataSet();
 myds.ReadXml("test.xml");
得到的就是一个DATASET,这样就简单了，可以用LINQ得到你要插入的数据

Answer 2

你好，那个XML是我列举的形式，我现在需要把这些数据存放在数据库中，我还没想清楚该如何存储。我主要是想知道A-B-C-D这种关系该如何设计数据库的结构
其中：
A-B为一对多；
B-C为一对多；
C-D为一对多。

Answer 3

谢谢！假设现在有“地面观测”这样一个观测业务
“地面观测”这个观测业务下面包含SI、SX、SM、UP、CS、AB、CU等报文
假设现在有北京、成都两个气象站
其中北京站的地面观测发送SI、SX、SM三种报文，时次分别为SI(00,06,12,18)、SM(00,12),SX(12)
成都站的地面观测发送SI、SX、SM、CS、AB五种报文，时次分别为(00,08,16)、SM(00,12),SX(00，12)...不同的台站相同的观测业务（如上均为地面观测）发送的报文可能不同（如一个发送三种报文、一个发送五种报文），且相同的报文在不同的台站发送的时次也可能会不同（如上的SI报的发送时次不同）所以 “台站-观测业务-报文-时次”这应该有一条完整的记录才对

Answer 4

==============================================================================
台站表——定义所有台站
   台站id  --唯一
   台站名称
   .....
   
观测业务表--定义所有业务
   业务id  --唯一
   业务名称
   ....
   
业务报文表-- 定义业务报文
   业务id  --唯一
   报文id  --唯一
   上报时间
   报文格式 ....
   报文数据表   
   台站id
   业务id
   报文id
   报文数据....优点: 1、数据冗余少，不需太多的数据检查，节约存储
2、将台站、业务、报文分开存储，将来无论台站、业务、报文如何变化，都不影响基础结构，应用扩展性好
3、业务报文表\台站表\观测业务表三表是码表，只有报文数据表是需要上报的内容，冗余信息少，在有大量数据上报，或者上报频繁时，程序运行效率好保证。
缺点：
1、表结果是面向台站业务管理与业务数据收集设计的，如果要对收集的数据进行分析，这种架构不合适。主要是维表多（3个）大数据量统计分析效率不高。
2、虽然结果提高了应用的灵活性，扩展性，但是一般码表都需要维护界面。有一定的开发工作量==============================================================================
如果使用一张表存储所有数据，一方面上报数据量会大，另一方面数据一致性不好保证，同时如果台站或者业务发生变化，维护工作会比较多。当然，如果你做的是一个类似数据仓库的东东，那一张表也没有什么，毕竟数据很少变，倒是统计分析经常有

Answer 5

(补充: 如果你是做项目,考虑工期和需求,不要做多余的.) 
==============================================================================
台站表——定义所有台站
  台站id --唯一
  台站名称
  .....
    
观测业务表--定义所有业务
  业务id --唯一
  业务名称
  ....
    
业务报文表-- 定义业务报文
  业务id --唯一
  报文id --唯一
  上报时间
  报文格式 ....
    报文数据表   
  台站id
  业务id
  报文id
  报文数据....优点: 1、数据冗余少，不需太多的数据检查，节约存储
2、将台站、业务、报文分开存储，将来无论台站、业务、报文如何变化，都不影响基础结构，应用扩展性好
3、业务报文表\台站表\观测业务表三表是码表，只有报文数据表是需要上报的内容，冗余信息少，在有大量数据上报，或者上报频繁时，程序运行效率好保证。
缺点：
1、表结果是面向台站业务管理与业务数据收集设计的，如果要对收集的数据进行分析，这种架构不合适。主要是维表多（3个）大数据量统计分析效率不高。
2、虽然结果提高了应用的灵活性，扩展性，但是一般码表都需要维护界面。有一定的开发工作量==============================================================================
如果使用一张表存储所有数据，一方面上报数据量会大，另一方面数据一致性不好保证，同时如果台站或者业务发生变化，维护工作会比较多。当然，如果你做的是一个类似数据仓库的东东，那一张表也没有什么，毕竟数据很少变，倒是统计分析经常有