在关系数据库中，数据存储在使用特定模型和关系网络创建的表中。特别是在尚未完全成熟的系统中，数据模型中的更改频繁发生，它们使得难以控制数据和数据模型的完整性、一致性和粒度。这就需要控制机制，这些机制将基于对数据模型和目录机制所做的更改而工作。
上述控制机制不应阻碍开发过程，但也应防止数据模型变成“垃圾”。在这方面，在进行规划时应考虑数据模型（表名、相关表的存在及其相互兼容性、相关表在列方面的一致性等）。
在本文中，除了在关系数据库中构建数据模型目录（这里使用的是Oracle DB）之外，还将讨论一种机制，用于监视和报告与此数据模型和目录内容相关的更改。
先决条件
当涉及到标准规则及其控制时，在开发相关环境时，也应遵循某些规则。这些规则应该写下来，整个开发团队在进行任何数据模型更改时都应该仔细遵守。以下是一些在本文描述的结构中有效的规则。可以添加这些规则以涵盖其他数据库对象类型。
规则
本文将以以下控制和规则为例进行讨论：
1.数据模型更改与约定规则的符合性
2.是否有描述为元数据的表
3.是否有描述为元数据的列
4.是否有包含未添加到相关审核日志表的列的表
5.是否有包含未添加到审核日志触发器的列的表
如前所述，应将此列表作为参考点，根据架构角度和数据和数据模型的结构进行改进。
工作流程和方法
在继续讨论实现细节之前，简要介绍一下本文中解释的技术过程将很有帮助。
该过程从Oracle Scheduler触发作业开始。下一节还将介绍更多详细信息，但这里只执行以下代码：
BEGIN
schema_name.p_data_model_reporter();
END;
首先，上述作业获取与表创建、删除或更改相关的数据模型更改。例如，这里捕获了向表中添加列的开发，供数据模型架构师对照上一节中提到的数据模型结构的预定义开发标准进行审查。
然后，对整个数据模型进行编程控制，以获取主要用于保护数据模型目录的一致性和可靠性的规则。
最后，在整个过程中收集的数据被格式化为报告，并发送给开发团队进行重构、进一步检查等。
以下是流程图：
另一方面，这个过程不是日常开发周期中的额外工作，而是应该被视为该周期的一部分。在这方面，可以讨论从开发周期开始到结束的流程，如下所示：
在这里，“开发”和“检查”阶段可以归类为标准的“开发工作”，应该毫无疑问地进行。但是，由于讨论、头脑风暴、人类互动等都发生在“分析”和“讨论”阶段；在这些阶段中，所需的值也会添加到工作区中。
实施细节
上述规则通过数据库过程进行控制。GitHub上也提供了过程内容。在这里，将强调上述规则的操作逻辑和一般流程，而不是逐行遍历整个数据库过程内容。作为每个规则的输出，与规则结果相适应的内容将作为电子邮件发送给数据模型架构师以供审查。
数据模型更改与约定规则的符合性
admin.ddl_history_log表用于此控件。”前一天在相关模式的表上执行的ALTER、DROP和CREATE操作被拉入差分逻辑。它通过下面这样的查询工作。
SELECT TO_CHAR (action_date, 'dd.mm.yyyy') action_date,
action_osuser,
action_username,
object_name,
ddl_sql
FROM admin.ddl_history_log
WHERE object_type = 'TABLE'
AND object_owner = :schema_name
AND ddl IN ('ALTER', 'DROP', 'CREATE')
AND action_date BETWEEN TRUNC (SYSDATE - 1) AND TRUNC (SYSDATE)
ORDER BY action_osuser;
是否有描述为元数据的表
sys.user_tab_comments视图用于此控件。这里应用累积逻辑。通过以下查询检索需要更正的记录列表：
SELECT utcom.table_name
FROM sys.user_tab_comments utcom
INNER JOIN sys.user_objects uobj ON utcom.table_name = uobj.object_name
WHERE uobj.object_type = 'TABLE' AND utcom.comments IS NULL;
是否有描述为元数据的列
sys.user_tab_comments视图用于此控件。这里应用累积逻辑。通过以下查询检索需要更正的记录列表：
SELECT ucc.table_name || '.' || ucc.column_name column_name
FROM sys.user_col_comments ucc
INNER JOIN sys.user_objects uobj ON ucc.table_name = uobj.object_name
WHERE uobj.object_type = 'TABLE' AND ucc.comments IS NULL;
是否有列未添加到相关审核日志表的表
sys.user_objects视图用于此控件。这里应用累积逻辑。首先，对于每个表，检查是否有另一个表具有后缀“_log”（请参阅“先决条件”部分中的规则）。对于满足此标准的每个表，检查表和相关审核日志表之间的列奇偶性。报告不符合要求的表格。
是否有包含未添加到审核日志触发器的列的表
sys.user_objects视图用于此控件。这里应用累积逻辑。首先，对于每个表，检查是否有前缀为“trg_u”的数据库触发器（请参阅先决条件部分中的规则）。对于满足此标准的每个表，检查是否对共轭触发器代码内的表中的所有列进行了审计日志编码。报告不符合要求的表格。
进度表
通过此处详述的过程，通过每天在特定时间触发的预定Oracle数据库作业进行控制。这些Oracle作业定义是通过Oracle的内置DBMS_作业包进行的。示例定义脚本如下：
DECLARE
l_job_id BINARY_INTEGER;
BEGIN
DBMS_JOB.submit (job => l_job_id,
what => 'BEGIN
schema_name.p_data_model_reporter();
END;',
next_date => SYSDATE,
interval => 'SYSDATE+(4/(24))');
DBMS_OUTPUT.put_line (l_job_id);
END;
可以通过以下查询访问创建的作业。
select * from sys.dba_jobs where job = :l_job_id;
总结和进一步工作
在本文中，除了在关系数据库中构建和保证数据模型目录外，还讨论了监视和报告与此数据模型和目录内容相关的更改的机制。在这种情况下要评估的控制不应局限于提供对数据模型的控制，还应考虑存储在数据模型中的数据与数据模型本身之间的一致性（匹配数据类型有效性等）以及数据本身、数据模型的使用。
原文标题：Data Model Tracing and Reporting on a Relational Database
原文作者：Taner Inal
原文链接：https://dzone.com/articles/data-model-tracing-and-reporting
