潘老师，有空帮忙点评一下，谢谢
参数类型 更多的是表示分组，而参数规格是用于参数校验的。。 数据上报的时候，可能与mi不是同一个时刻的，在可能在设备端收集后统一发上来，所以不能合并
UMLChina潘加宇:再思考一下，分组是对规格分组还是对参数分组
彡工鸟:参数名和参数值一开始是没有属性的，感觉怪怪我就加上去了。参数名和状态名都想表示不同时刻，可能拥有不同的值 对参数分组 状态是设备的状态，模组也可以理解为参数那边的分组，就是逻辑上划分
UMLChina潘加宇:我的意思是我的意见很可能是对的，你再好好思考一下 类比：商品-商品规格-商品类型 特别是，设备直接连到事件类型，这个不会的。 规则是规则，游戏是游戏
就算有规则似乎是针对个体，其实也不是，仍然是针对群体。例如有一些特殊的规则适用于Xi总，那不是针对他个人，而是因为他的职位。只不过这个职位目前只有一个人。 你再仔细体会一下。
彡工鸟:这个确实，我连的时候，也想了好久。。。
UMLChina潘加宇:实在不行，你就当成是数据库建模 ，把你认为合适的数据库模型发上来
彡工鸟:这种可以合并么？最开始通过用例分析的时候，分别是存在参数上报，状态上报，事件上报三个mi的，然后对应自己的mi明细。现在合并成一个数据上报，再添加上报类型的描述
如实描述。合并成一个，上报，关联到上报类型
彡工鸟:谢谢，我再仔细体会一下，到时候同数据库建模一起发上来
彡工鸟:潘老师，我重新再整理了一下，觉得这样应该更合理。同时附上了数据库模型，您再帮忙点评一下，谢谢！
1. 我是偷懒，所以直接用领域属性的做主键的，实际上会单独用ID 2. 适用那个，可以理解成同一型号的设备，都有这些参数和状态，之前是关联到具体设备，后来觉得应该是关联到设备型号 3. 右下角的事件，同样是设备上报的，事件差不多等同参数/状态
彡工鸟:潘老师，这个还是需要设备ID吧，不然不知道是哪个设备
已经关联到上报了，又关联一次不是重复了吗
彡工鸟:哦，那事件和状态也是一样处理才行 我想着这样便利一点呢
UMLChina潘加宇:这几个类就够了
彡工鸟:，我好好消化一下
彡工鸟:不过数据项不需要跟设备，设备型号关联么？因为还有反过来，修改设备的数据项一说
换成这样？
