有2种方式可以将遗留系统集成进内容管理系统。一种可能性是将遗留系统中数据模型的相关部分映射到内容管理系统的内部数据模型上。这个数据模型可以是一个覆盖大部分甚至全部内容管理系统有关业务流程的企业范围的数据模型。在这个方案中，当处理有关请求时，数据管理器必须知道与之接驳的数据库中的哪部分数据模型在工作。有了数据管理器，遗留系统就可作为覆盖全部数据模型的特定子集的本地内容管理系统数据库之一，并且对内容管理系统的访问自动地联合到遗留系统。这个方法看起来相当精致，但在实施中可能会造成相当大的额外开销，将引起严重的延时。
第二个可能性是使标准的数据管理器适应遗留系统，以便支持一组预定义的查询和报告以及一组预定义的命令，其中每一个命令都有一个在系统范围内一致的语义。在这种情况中，虽然集成的范围被限定在该公司数据模型的一个相关的子域中，但是它仍然在内容管理系统的范围内有着一致的意义。遗留系统可作为一个标准信息系统被引导，并在这个范围内传送信息。这种方法使得内容管理系统可以指定特定的信息系统去传送特定的信息集（如专用权限数据库，针对视频、音频或静态画面的专用目录，或者印刷品数据库）。在这种情况下，唯一必需的是一个特定系统能提供一致的信息规范。
考虑到这一点，遗留系统可用于存储由内容管理系统管理的部分元数据，或可表示独立的信息源。在任何情况下，每个遗留系统都需要一个专门的数据管理器实例。因此，数据管理器经常需要专门定制。
内容管理系统数据库
表示一个公司数据模型的标准方法是开发一个实体关系图来描述数据模型，并用一个标准关系型数据库管理系统（Relational Database Management System， RDBMS）实现该模型。这种公司数据模型的一个很好的例子是BBC的标准媒体交换框架（Standard Media Exchange Framework， SMEF），它也被引入到EBU P/Meta中（见4.4.1）。
由于这些数据模型在各组织之间有极大差异，并且应用于这些数据模型上的工作流也非常不同，因此，内容管理系统是不可能用非常合适的标准定制数据模型进行工作的。因此，典型的内容管理系统项目包括对所需要的数据模型以及工作流程进行定制，这意味着，相应的数据管理器也需要被定制。
为了持久存储，用户可能使用单个数据库或多个联合的数据库。物理执行的情况是完全透明的。内容管理系统会通过数据管理器存取该数据库，因此它不依赖于数据库中有关元数据物理表示的特定知识。
全文检索
内容管理系统所用的数据模型中有一个用户可自行的配置的属性，这组属性可以用来为全文检索建立索引。全文检索能力既可通过一个单独的全文搜索引擎来提供，也可以通过数据库自身的全文检索能力加以提供。如果使用单独的全文搜索引擎，可由全文搜索引擎直接存取数据库并对属性加以索引，或者是通过数据库把选定的属性作为数据库报告写入结构性文件，这些文件被置于文件系统中的保护区域中。之后，全文搜索引擎对这些文件建立索引。
上述2种方法各有不足。如果全文搜索引擎直接存取数据库表，则必须建立和维护在数据模型映射和搜索引擎索引者之间的强耦合。在使用数据库报告的情况下，数据库就必须负责保持报告和数据库内容之间参照的完整性。
应该用哪个引擎，主要是由所请求的功能和语言来决定的。将一个全文引擎集成到一个内容管理系统中，应该很容易做到，这同样意味着需要一个清晰界定的接口。
应用中的某些需求可能会限制我们对这些全文搜索引擎的选择。搜索引擎应提供以下功能：
·一个可配置的词法分析程序。
·支持基于属性的检索和分类。
·支持将搜索限制在一定数量范围内。
·对于某些国家的内容管理系统应用，支持Unicode编码。
·一个合理的API，被授权访问检索功能和重要信息。
根据所选全文引擎的能力，内容管理系统可提供模糊搜索、评级以及其他高级检索特性。考虑到查询算法的不断更新，将全文检索与数据库分离可以提供更好的扩展性，从而发挥全文搜索引擎的卓越性能。
图像相似搜索
在一个内容管理系统中，视频对象一般是由一组关键帧来表示的，这些关键帧都是图像对象。除了关键帧，其他图像可存储在素材管理中。图像相似引擎为图像查询与检索提供了一个可选择的方案。图像对象不是通过查询基于文本的元数据来检索的，而是通过比较图像特征，从而找出与标本图像相似的图像。
需要注意的是，基于图像相似的搜索，经常会返回预期不到的结果。例如，一个用户要搜索关于某个人的图像。该用户提供此人的一个面部照片作为标本，要求得到相似的图像。大多数用户此时期望找到所有关于这个人的图像：近照和全身、正面和侧面、戴眼镜和不戴眼镜以及戴帽子和不戴帽子等。但他们得到的可能是许多与此人相似的其他人、动物或甚至与人相似的物体的图像。由于这不是他们所期待的，未经培训的用户往往会对搜索结果失望。
然而，这个技术在其他一些应用情境中是有用的。一个可能的应用是：不是寻求图像相似，而是寻求图像相同（或高度相似）。例如，一个用户在检索时发现了一个有趣的剪辑，但它太短了或者其中有插入物，使得它不适于在新的制作中重利用，因此，用户想要对系统进行查询，以便找到比这个剪辑更长一些的或没有插入物的版本。为实现这一点，该用户可以从剪辑中选取一个有特色的图像或关键帧，并对所有的关键帧进行查询，以得到非常相似的图像（通常是相同的）。通过查询得到的关键帧，用户可以找到由这些关键帧所代表的剪辑，从中得到他所需要的剪辑。在这种情况下，查询结果符合用户期望，技术有了用武之地。
以关键帧作为图像相似检索的主要来源，其主要问题是可扩展性。让我们考虑一个平均的含有100 000小时的视频资料的存档。平均而言，可选择大约1 000幅关键帧来代表1个小时的视频。这意味着，为了找出所有与所提供的样本图像相似的图像，我们必须把一张图像与100 000 000张图像做比较。如果我们假定最大响应时间应该低于10秒，很显然这个功能是相当费时的。
鉴于技术的快速进步，可能很快就会有这个问题的解决方案了。因此，一个可以使图像相似搜索引擎集成进内容管理系统框架的清晰的接口描述，在任何时候都是需要的。
音频相似搜索
另一类高级搜索功能是音频相似搜索。用户向搜索引擎呈现一段声音剪辑，搜索引擎返回包含有与所呈剪辑相似的声音元素的音频对象。由于音频对象可以是一个视频对象的音轨，因此这个搜索适用于视频和音频内容。
这类搜索引擎目前仍然在研究阶段。然而，如同图像相似搜索引擎需要对庞大数量的图像进行比较一样，音频相似搜索也有类似问题，随着技术的不断发展，相信会在不久的将来找到解决方案。与前面相同，一个可以使音频相似搜索引擎集成进内容管理系统框架的清晰的接口描述，在任何时候都是需要的。
6.4.3.2数据管理器
数据管理器被用于将信息系统集成进整个内容管理系统架构。对每一个必须包含的信息系统，必须提供一个专门的数据管理器。
一个数据管理器可分成2部分，系统专用部分和通用部分。系统专用部分是信息系统的外包装，而通用部分则提供内容管理系统的接口。数据管理器负责向任何请求信息的模块（如服务和应用）提供一个面向存储元数据（而非素材）的信息系统的统一接口。需要特别指出的一点是，数据管理器必须从特定的数据管理系统的查询语言和物理数据存储特征中完全抽象出来。数据管理器既接收查询，也请求创建、更新和删除数据对象。作为响应，它传送命中清单和细节报告等。
所有在数据管理器与客户端（可以是一个应用、一个服务或一个数据代理器）之间传送的消息，应该按XML等标准交换格式进行编码。为了对属性进行唯一的附注，可以使用SMPTE 335M（元数据字典结构）（电影与电视工程师学会：Society of Motion Picture and Television Engineers， SMPTE），以及SMPTE推荐规则RP210。属性可以根据SMPTE 336M加以编码（键-长度-值协议：Key-Length-Value Protocol， KLV）。为了将KLV映射到XML，消息的文档类型定义（Document Type Definition， DTD）应该遵循由高级制作格式（Advanced Authoring Format， AAF）协会指定的格式。
数据管理器将送来的查询请求转换成相应信息系统的本地查询语言，并将该信息系统（比如ANSI SQL关系型数据库）提供的响应映射成为标准响应消息。如有必要，数据管理器可在内容管理系统数据模型、数据管理器接口的信息系统的数据模型与数据存储表示之间，作为中介。
从本地数据模型中进行提取的一个可行的方法，是采用“被标记的查询”的概念。一个标记是在信息系统中对一个任意的属性集进行特定查询的标识符。标记需要有一个贯穿整个内容管理系统的一致的语义含义，但这取决于相应的数据管理器的配置，以及由标记引导的相应的信息系统主导数据模型的部分。这种标记的例子包括：“什么”、“何地”、“何时”等。
数据管理器接收一个带有许多属性参数的查询作为标记，从查询清单中选择由标记所标识的查询，并将这些属性映射到该查询中，从而产生由数据管理器连接的信息系统的本地查询语言所表示的一个完整的查询。查询达到一定复杂性后，该方法甚至可使得同一个被标记的查询与大量的数据管理器联合。这很重要，因为用户（尤其是不熟练和临时的用户）都期望得到一个单一的结果清单。由此，使用了标记的查询可允许对在大量信息系统中都有的一个共同概念进行特定搜索，并从具体系统的实现细节中抽象出来。
通过标记或高级结构（如用XML进行编码），数据管理器可引导内容管理系统的数据模型的一个子集，该子集一般是一个公司范围的数据模型（如BBC的SMEF）。该子集的大小由数据管理器所接口的数据库系统的容量来限定，它可以提供单个对象的特定属性及整个数据模型。
6.4.3.3数据管理器解析器
数据管理器与任意的信息系统集成，此信息系统授权存取用于内容对象或资产（若IPR受到管理）的某部分元数据。其他元数据可位于另一个信息系统，此信息系统与另一个数据管理器接口。最有可能的，每一个信息系统都采用其所拥有的唯一的ID在自己的域内标引资产。因此，可能需要将各自专有的ID映射到一个系统范围唯一的ID，该ID可在内容管理系统域内代表资产。这个工作可由一个数据管理器解析器来实现。
数据管理器解析器基本上是一个简单的映射表，包括：
·每个已知资产的所有已知ID构成一个数据行。
·一个存储每个资产在内容管理系统范围的ID数据列。
·一个为每个数据管理器存储其所接口的系统中的相应对象的ID数据列。
对该映射表的查询使得当用户知道数据管理器和相应本地ID时可以找到一个对象的内容管理系统ID，或当用户知道内容管理系统ID和相应数据管理器时，可以找到给定的信息系统中的一个对象的本地ID。
由于数据管理器向内容管理系统提供统一的接口，完全从相应的信息系统中的信息中抽象出来，因此由数据管理器存取数据管理器解析器。这个机制使得用户可以查询由内容管理系统ID所标识的内容管理系统内容对象，并发送这些内容对象作为查询结果。
6.4.3.4数据代理器
当一个查询需要与一个以上的数据管理器联合时，内容管理系统必须能在所涉及的数据管理器中间分发该查询的一个实体，并从这些数据管理器处接收响应。进一步讲，它必须将这些响应融合为一个统一的响应集，必要的话还可通过再次向特定的数据管理器就查询结果集中的每个对象请求附加信息，丰富结果属性等。
该组件称作数据代理器。它执行在元数据层之上引入代理管理器方案。数据代理器为内容管理系统提供唯一的查询、更新和删除接口，这样内容管理系统组件就不需要确切知道数据管理整体上是如何构造的。数据代理器向已在代理器上登记的数据管理器提交请求（查询和数据库维护指令）。因为数据代理器本身可以作为一个分布式的实体，它也会向已知且可连接的其他数据代理器传送请求。数据代理器在接收到它所调用的所有单元的结果后，收集响应，并将这些响应提交到请求的单元。这个过程取决于所选择的调用深度和选择的代理器。