视角不同：日常数据管理是以业务应用流程（单表）为中心，关注数值合法性和关联的合规性，关注少量记录；而数据分析是是以业务逻辑概念（多个表格关联合并后的宽表）为中心，关注“跨领域全量”记录，同时考虑领域对象结构（多个表关联结构、记录间结构和业务场景）关联、全量的角度做数据分析。很多单条看起来正常的记录，在上下文角度看可能是不正常的。

概念模型与数据模型的差异：很多业务语义上约束关系，并没有在实际数据库或数据应用中严格检查与遵循。例如，数据表通常用代理主键而不是自然主键，很多概念上约束关系可能没有生效。时间间隔（time   interval）关系约束（例如，不同生产周期的起止时间间隔不能重叠）通常需要业务应用来保证，但当一条新的记录写入时候，很多业务应用没有将其与历史记录做约束性检查。

Data  Schema的设计是为了满足特定应用（例如MES）需求的，只要符合设计初衷，数据就不存在Data  Schema层面的质量问题；而数据分析的目的是解决一个物理世界中的问题，以物理语义看数据问题（不会完全迷信数据），并且通常要跨多个数据集，对数据集的要求与一个应用的需求可能不同，因而，数据分析项目中的“数据质量”问题除了Data  Schema层面，还要关心应用场景（Application Context）下的数据质量问题。Data  Schema层面的质量问题通常可以用数据模型（如关系数据表的3范式）、数据约束（如OCL，Object Constraint  Language）等形式化模型去描述，可以独立于具体的应用。而应用场景相关的数据质量问题，与研究问题的范畴和业务上下文有关，通常不容易发现，有一定规律但不存在通用的方法。各种数据系统、工具和企业级的数据治理大多集中在前者，而留给行业数据分析师的往往是后者，没有经验的数据分析师往往很难发现这些问题，造成了基于“问题数据”训练出的机器学习模型不可信。