注意：在SAP社区博客平台上，代码示例可能看起来有些混乱。这不是我能帮助的-它在预览中看起来不错，但在发布时就不行了。本文的可读性更好的版本可在以下位置获得：
对于BI的一个客户，我们目前正在努力生产一个定制的概念验证SAP/HANA应用程序。
这个特殊的应用程序在我们如何使用SAP/HANA功能和技术方面非常典型：它是一个用于桌面和平板电脑设备的web应用程序，我们通过SAP/HANA的XS引擎提供服务。对于数据库通信，我们主要使用OData（使用XS OData服务），以及奇怪的xsjs请求（在本例中，大数据包括，使用ODXL提供MS Excel导出）
我们应用程序使用的OData服务主要由SAP/HANA计算视图支持。这些，反过来，是建立在一个混合的对象袋之上：
其中一些是只属于我们的应用程序的自定义基表；有些是基表，用于收集在外部R服务器中运行的高级分析建议算法的输出有些是信息视图（分析视图、属性视图和计算视图），它们在从各种SAP ERP源系统复制到我们的SAP/HANA数据库的基表之上形成一个虚拟数据集市（排序）。
使当前解决方案产品化的先决条件之一是重新设计后端。重新设计是必需的，因为新的目标系统将从比我们的概念验证环境更多的ERP源系统中获得，并且新的后端将需要调整所有这些不同ERP实施的数据。此外，R算法也将得到优化：在概念验证环境中，为了方便起见，高级分析算法通过许多字段，这些字段需要从生产环境中的其他地方获取。
为了便于重新设计，我们需要准确了解哪些基列最终用于实现我们的应用程序的数据服务。事实证明，使用标准工具很难做到这一点。所以，我们自己开发了一些东西。我们认为这可能对其他人也有用，这就是为什么我们想通过这个博客与您分享它。
标准工具集提供了一些支持来获取信息视图（分析视图、属性视图和计算视图）的依赖关系：
如果您是HANA Studio用户，您可以使用"Where used list"和/或"Column lineage"功能。看看克里希那摩·克里希纳关于这个话题的精彩博客。您可以查询对象依赖关系系统视图
事实证明，这些标准工具没有提供我们需要的详细信息。hanastudio特性主要在设计和修改信息视图时有用，但不能让我们获得所有依赖项的概述，返利是什么，而且不能在hanastudio之外轻松使用。查询OBJECT\u DEPENDENCIES系统视图的有用性受到以下事实的限制：它只报告对象（即基表或信息视图），而不报告其中包含的列。
看起来我们并不是唯一一个在解决这个问题的人。
要获得我们需要的信息，智能物联网，我们只需要打开信息视图的定义，看看里面是什么。事实证明，HANA将其作为XML存储在\u SYS的CDATA列中_REPO.ACTIVE\u对象系统表，我们可以通过包名、对象名和对象后缀（基本上是存储库中包含定义的文件的扩展名）进行查询：
稍加努力，_系统_REPO.ACTIVE\u对象可以连接到对象依赖项以发现信息视图所依赖的对象：
（注意：对象依赖项报告所有依赖项，而不仅仅是直接依赖项）
或者我们可以反过来查询，并为在对象依赖项中找到的依赖项找到相应的模型：
注意：它会打开指出查询对象依赖关系在报告分析视图和它们使用的属性视图之间的依赖关系时失败。要捕获这些依赖项，您需要查询_REPO.ACTIVE\u OBJECTCROSSREF对象交叉引用.
一旦我们获得了定义信息视图的XML，我们仍然需要将它分离开来，这样我们就可以弄清楚它是如何与我们的基表列相关联的。为此，我们首先应用一个通用的XML解析器，将XML文本转换成一个（临时）表或表变量，这样每一行表示XML文档中一个不同的原子元素。为此，我开发了一个名为p\u parse\u xml的HANA存储过程。这里是它的签名：
注意，您可以从github下载整个过程的源dode。p\u parse\u xml过程依赖于p\u decode\u xml\u实体，因此，如果您想自己运行它，一定要先安装它。
要了解如何使用它，请考虑以下简单的示例：
这给了我们以下结果：
结果是XML解析树的表格表示。每一行本质上代表一个DOM节点，列值代表节点的属性：
Node\u TYPE列告诉我们正在处理什么类型的节点。此列中的值符合节点类型值的w3c标准文档对象模型（DOM）枚举。最重要的是1个元素节点（"标记"）；2个属性，3个文本。整个解析树包含在节点类型为9的文档节点中。NODE\u ID是节点的唯一标识符，而PARENT\u NODE\u ID指向被认为是当前节点的父节点的任何节点。父节点基本上是节点的容器。如您所见，节点为3的元素将节点为1的元素节点作为父元素。这些元素对应于文档中的第一个和元素。属性节点也被标记为它们所属元素的子级。DOM标准不考虑其各自元素节点的属性子级，但p\u parse\u xml考虑，主要是为了使结果表尽可能简单。NODE\u NAME列进一步描述了我们所使用的节点类型。对于大多数节点类型，什么是大数据技术，节点名称是一个常量值，本质上是节点的友好名称类型。用于例如，文档节点（NODE#TYPE=9）总是将#document作为节点名称，而文本节点（NODE#TYPE=3）总是将#text作为节点名称。对于元素节点和属性节点（节点类型分别为1和2），节点名称不是常量。相反，它们的节点名传递有关节点及其内容的含义的信息。换句话说，元素和属性名是元数据。节点值列包含实际数据。对于元素和文档节点，它总是空的。对于属性，节点值列包含属性值，对于文本节点，它是文本内容。POS列出了找到当前元素的位置；LEN列跟踪显示在doucment中的当前项的长度。通常您不需要这些列，除非是出于调试目的。这里的TOKEN\u TEXT列也主要用于调试目的。
如果您检查分析视图和/或属性视图的XML定义，您会注意到表基列是使用元素引用的，例如：
