难以管理完全基于数据库的应用软件所产生的产品数据

    基于数据库的应用软件一般不产生物理存储的电子文件，它的信息完全存储在数据库中，需要时再将数据调入模板中进行浏览、修改、打印等操作。这样传统PDM的信息管理模型就很难处理。

    目前国内基于数据库的CAPP系统方兴未艾，其中大部分基于数据库的CAPP都不产生物理存储的电子文件，每个工艺路线、工艺规程等的信息都存储在数据库中，而传统的四M只能够直接管理物理存储的计算机文件，因此显而易见，这种CAPP产生的信息PDM就很难集成和管理。

    目前也有少数信息化厂商为了解决这个问题，支持将基于数据库的CAPP产生的工艺路线和工艺规程等数据从数据库导出另存为物理文件，以便纳入PDM系统进行文件级的管理，但是这也存在问题：版本难以控制、信息一致性难以保证、操作复杂易出错。此外还有权限设置、流程控制等问题需要解决。

    除了基于数据库的应用软件产生的产品数据传统PDM难以管理之外，还有PDM内部产生的一些存储在数据库中的产品信息，传统PDM也难以处理。比如零部件的结构信息，它的数据在物理上可能是PDM数据库中某个产品结构关联表的一组记录(它在现实中的原型是设计图上的明细栏)，当传统的PDM将产品结构当作一种特殊的脱离于图纸和工艺等物理文件而单独存在的信息进行管理时，就难以处理产品结构的版本问题。

难以反映出不同类型的文档之间丰宫的关联方式和逻辑关系

    在企业的实际技术活动中，零部件图纸之间、零部件图纸与工艺文档之间、零部件图纸与技术文件之间、工艺文档与技术文件之间，存在着复杂而丰富的关联方式和逻辑关系，这些关联方式和逻辑关系是企业产品信息管理中不可或缺的组成部分，它包括了企业大量技术实践的结晶，是企业不可遗失的宝贵财富。

    比如：某纺机企业有一个工装清单文档FK6-700-030821(工装清单是一种工艺文档，上面罗列了某加工过程卡的某工序用到的工装列表)，那么在传统PDM模型下，  我们只能够将工装清单FK6—700—030821直接关联到零部件结构树节点上，如果这个工装清单与多个工艺规程有关，那么我们即使把它和这些工艺规程文档一起关联在零部件节点上，还是没有直观地表现出它与引用它的工艺文档——各种工艺规程中的过程卡和工艺卡的关联关系。其实，这种关联关系是蕴涵在不同的工艺规程的过程卡和工艺卡文档的内容之中的，工装清单与结构树节点并没有直接的关联关系。

难以反映出各个不同版本物理文件之间的版本对应关系

    在传统的PDM中，只能够记载关联到某个零部件节点上有哪些文档(包括这些文档的版本)，但是具体这些文档之间存在怎样的对应关系，它是难以表达的。因为在传统信息管理模型中，挂结在一个节点上的所有文档都是平等的，它们之间不存在包含关系，没有办法将某两个版本文档之间的对应关系采用打包处理，比如将第一版的图纸和第二版的计算说明书打包作为一种组合；再将第二版的图纸和第三版的计算说明书打包作为一种组合。

难以处理相互紧密关联的多个文档的复杂的演变过程

    在传统PDM中，零部件往往被作为两类信息实体进行管理，图纸(文档)信息实体和零部件信息实体，假设A为一张零部件的图纸(我们称为设计图纸文档)，B是代表该零部件本身(实际上是零部件的实体在PDM中映射的虚拟节点，类似于实体的人在档案管理系统中的档案代表人本身一样)，A是B零部件的设计图，这就意味着A图纸上的标题栏明细栏信息要与PDM中B部件的节点和子节点信息保持一致。不论是在A的还是B的演变流程中，都会产生与对方的一致性要求。因此，为了达到这种要求，用户将会很自然地要求在修改某一个信息实体时，由系统自动启动该信息实体对应的另外一个信息实体的相应演变流程。

    由PDM系统自动启动并控制两个信息实体的演变流程，在这两个信息实体的发展变化中，还要处理他们的版本关系、权限控制管理等等，这在传统的PDM信息管理模型下不会有既简单又严密的解决方案。

    为了实现这个操作，又不去处理复杂的演变流程，传统PDM产品数据信息模型目前只能够通过功能有限的“信息互动”来实现，目前大多数厂商提供的系统也只能够做到节点信息的互动，难以完成产品结构的互动，难以提出完整的方案，做到明细表的更改自动触发产品结构树的更改，其中还要牵涉到版本和权限控制，其机制可想而知有多复杂。

[page][/page]

难以实现零部件的多重分类体系

    传统PDM信息管理模型中的产品零部件节点，都是与结构树紧密相连的，没有了结构树，这些零部件也就消失了，没有纳入零部件仓库和分类管理的思想。

    这是由于在传统模型下，PDM对图纸本身的管理仅仅是一种图档管理，图档在PDM中并不代表零部件本身，代表零部件本身的是产品结构树上的一个个节点，而节点又是与结构密切相关的，结构一旦不存在，节点也就不存在了，但是图纸照样可以存在，也就是说零部件的图纸可以独立于零部件节点而存在。当我们修改了结构后，往往造成了零部件的变化，甚至是丢失。

    这种信息管理方式难以支撑零部件的多重分类体系，因为我们难以将图纸文件代替零部件来进行分类，图纸与零部件本身并非一对一的关系。

难以处理零部件结构属性信息的版本，难以描述零部件在生命周期中的演变过程

    从PDM角度来看，零部件的结构信息，它的数据在物理上是某个产品结构关联的一组记录，这组记录表达了零部件之间的装配关系(它在现实中的原型是设计图上的明细栏，它的信息存储在PDM数据库中)，当传统的PDM将产品结构当作一种特殊的脱离于图纸和工艺等物理文件而单独存在的信息进行管理时，就无可挽回地造成系统处理产品结构的版本的困难，没有产品结构信息的版本，那么实现所谓的产品生命周期的管理就无从谈起了。

    值得一提的是，曾经有些传统PDM厂商提出在PDM的产品结构树上通过并列堆积的方式表达同一产品多个不同阶段的产品结构树，实现所谓的产品结构属性信启、的版本和演变过程表达。但仔细考虑就会发现，产品结构的版本可能是多级不同版本结构的组合，那么某个底层零部件的结构版本的变迁就可能会影响到所有该零部件的上级部件的版本，采用并列堆积方式表达带来的将是无穷无尽的几何级数增长的结构信息，而且其中大部分组合可能是无效的；再者这种版本的演变过程和版本之间的关系难以记录，我们看到的只是毫不相干的几个精确的产品结构，根本无法表达产品结构在生命周期中的发展变化的全部过程。

难以记录产品结构复杂的替换代用、选用、数量变化关系

    由上面的分析可以看出，传统PDM信息管理模型，由于将产品结构当作一种特殊的脱离于图纸和工艺等物理文件而单独存在的信息进行管理，难以实现零部件自身的版本管理，也难以实现产品结构的版本管理，那么在一棵产品结构树上要想实现产品结构的替换代用、选用关系管理也是很艰难的，因为产品数据已经被割裂为图纸信息和产品结构信息两部分了，产品结构信息仅仅靠单一的产品结构树来表达，在产品结构树上靠节点与节点之间的父子关系联结，父子关系过于单调，难以在不同的节点或者节点类上定义可变属性，也难以进行装配变量约束规则的控制。比如一个最简单的规则：当父节点上某个变量的取值为A时，则子节点选择第一版本；当父节点上某个变量的取值为B时，则子节点选择第二版本；这在传统模型下就难以实现。

    难以实现产品结构复杂的替换代用、选用、数量变化关系，难以支撑零部件之间复杂的装配变量约束规则，也就难以根据企业产品的实际情况建立VPS(可变结构模型)；没有VPS，也就无从谈及EBoM(工程BoM，精确产品结构)了。

    在传统PDM信息管理模型下，很多制造业企业为了利用PDM实现产品的可选、替换关系，往往需要对同一个产品建立多个相对独立的结构树，通过删除某些零部件节点，添加某些零部件节点来完成可选、替换等关系，无形中增加了企业的工作量和数据的冗余，且应用效果并不是太好。

难以支持复杂的工作流管理和项目管理

    在企业级的项目管理和工作流管理的应用中，必然牵涉到产品生命周期中零部件演变的整个过程，在这个过程中，包括各种文档之间丰富的关联方式和逻辑关系处理、零部件结构和图纸的复杂的版本关系处理、零部件结构的复杂的演变、全结构与朋oM等等问题，传统PDM的信息管理模型难以处理，那么必然带来的结果就是：传统PDM信息管理模型不能够支持复杂的工作流管理和项目管理。

    为了解决传统四M信息管理模型中的固有问题和存在的种种弊端，一些专家人土和业界公司相继提出了新的产品数据管理模型，这些模型较基于产品结构树的管理有很多进步，能够涵盖更多的产品数据信息范围，概念上也都有所突破。在这些各具特色的数据管理模型中，最具代表性和生命力的就算是面向对象的产品数据管理模型，目前业界已经有多家公司推出了基于该模型的PDM系统。