实际数据中也证实了我们的猜想。
表TestTask中存在重复记录（按照bed_id, unit_idy与task唯一的语义），并且重复记录的内容不完全相同，应该是业务应用对于录入的测试任务没有做重复性检查。
表TestTask中存在时间字段异常的情形，例如，竟然有task_start_time为2035年的记录。
表TestConditionMonitoring中与TestTask的起止时间(task_start_time和task_end_time规约到10分钟间隔)，用bed_id, unit_id和时间字段做左joint之后，做填补(具体做法可以参阅《工业大数据分析算法实战》的2.2.2节)，发现竟然有很多记录缺乏task值。包括3类原因，
1) TestConditionMonitoring在2017年前unit_id用的是大类，而TestTask一直用的是细类；
2) TestTask中存在测试周期缺失；
3) TestTask有些记录的起止时间不对。
上面问题的发现都是从data schema的薄弱点切入。包括：
1）代理主键；
2）层次性字段；
3）关键字段的值域。
2、结构约束条件的检查对象建模中也有OCL (Object Constraint Language)等约束描述，但实际应用开发中应用较少。很多概念上的约束并没有在数据库或业务应用层面实现。
可以从领域模型或从业务逻辑的角度，把当前理解的约束逻辑明确列出来，通过分析代码的自动化手段，快速发现大量历史数据中的零星数据质量问题。
以TestTask为例，它蕴含着时序结构。在选择同一个bed_id的记录后，按照task_start_time从小到大排列，第i个测试周期的起止时间记为task_start_time(i)、end_date(i)，curtime为当前查询时间，task_end_time=NA表示当前任务还未结束。可以简要列出如下6条约束条件,第6条是个软约束：
1) task_start_time(i)< task_end_time(i)
2) task_start_time(i) is not NA & task_start_time(i)<= cur_time
3) task_end_time(i) is NA | task_end_time(i)<=cur_time
4) task_start_time(i+1)= task_end_time(i)
