sql - 使用 UML 或其他建模语言解释 SQL 查询？

Question

是否有任何推荐/既定的方法来解释 SQL 查询的工作？

我们的项目中有很多复杂的查询，我们需要使用 UML 或任何其他建模语言来记录它。

请注意，我不是在问数据建模。它更多地是关于记录 SQL 逻辑，即表如何连接、条件如何影响结果、连接等。

所以，最后:

推荐的方式有哪些？

有什么例子吗？

Answer 1

好问题。

我没有一个答案，这取决于上下文 - 实际查询的复杂程度，受众是谁(他们对不同符号的熟练程度)，如果我能够面对面提出这个问题，或者是它用于离线文档等。一些建议是:

对于不同的受众，以电子表格表格的形式使用源到目标的映射:

来源专栏 |目标列 |转换逻辑(规则+SQL)

请注意，这也涵盖了数据模型的一部分，不必非常正式(但可以)，您可以决定适当的详细程度(仅捕获整个数据处理的输入和输出或记录每个步骤即每个子查询)。

对于其他开发人员(精通 SQL) - 编写格式良好且文档化的 SQL 代码，并广泛使用缩进来指示子子子查询的不同嵌套级别。

对于其他开发人员或 DBA - 许多成熟的 RDBMS 具有生成解释计划(甚至可视化解释计划)的功能 - 这样的输出通常非常有用并带有附加信息(带有每个步骤估计成本的实际执行计划)。

对于学者 ;-) - 使用关系代数符号并绘制一棵树来描绘查询逻辑(例如: https://people.ok.ubc.ca/rlawrenc/teaching/304/Labs/Lab1/ ，请查看维基百科以获取用于表示特定操作的符号)。

有时使用特定工具来构建/定义数据处理(例如，Informatica 或 MS SSIS 用于构建部分 ETL 逻辑或 SAS Enterprise Guide，它具有表示执行代码的图形界面)，并且此类流程在工具本身中可视化，但是我不相信它像 SQL 一样具有表现力并且可以很好地显示一些非常复杂的查询。

QBE - 由 Moshé M. Zloof 发明的 Query-By-Example(例如在 MS Access 中可用)，是一种用于定义查询的图形工具/语言。但它也有其局限性(并非每个查询都可以这样表示)。