【发布时间】：2013-06-28 12:55:16
【问题描述】：
是否有任何推荐/既定的方式来解释 SQL 查询的工作？
我们的项目中有很多复杂的查询，我们需要使用 UML 或任何其他建模语言对其进行记录。
请注意，我不是在询问数据建模。它更多地是关于记录 SQL 逻辑，即表是如何连接的、条件如何影响结果、连接等。
所以，最后：
- 推荐的方法是什么？
- 有什么例子吗？
【问题讨论】：
标签： sql uml data-modeling
【发布时间】：2013-06-28 12:55:16
【问题描述】：
好问题。
我没有一个答案，这取决于上下文 - 实际查询的复杂程度，听众是谁（他们对不同符号的熟练程度），如果我能够面对面地展示这个 -面对还是离线文档等。一些建议是：
-
对于不同的受众，以电子表格的形式使用源到目标的映射：
来源专栏 |目标栏 |转换逻辑（规则+SQL）
请注意，这也涵盖了数据模型的一部分，不必非常正式（但可以），并且您可以决定适当的详细程度（仅捕获整个数据处理的输入和输出或记录每个步骤，即每个子查询）。
-
对于其他开发人员（精通 SQL）- 编写格式良好并记录在案的 SQL 代码，并广泛使用缩进来指示子子查询的不同嵌套级别。
李> 对于其他开发人员或 DBA - 许多成熟的 RDBMS 具有生成解释计划（甚至是可视化解释计划）的功能 - 这样的输出通常非常有用并带有额外的信息（实际执行计划以及每个步骤）。
对于学者 ;-) - 使用关系代数符号并绘制一棵树来描绘查询逻辑（例如：https://people.ok.ubc.ca/rlawrenc/teaching/304/Labs/Lab1/，查看 Wikipedia 中用于表示特定操作的符号）。
有时使用特定工具来构建/定义数据处理（例如，用于构建 ETL 逻辑的部分 Informatica 或 MS SSIS 或具有图形界面来表示执行代码的 SAS Enterprise Guide）和此类流程在工具本身中是可视化的，但我不相信它像 SQL 那样具有表现力并且可以很好地显示一些非常复杂的查询。
QBE - 由 Moshé M. Zloof 发明的 Query-By-Example（例如在 MS Access 中可用）是一种用于定义查询的图形工具/语言。但它也有其局限性（不是每个查询都可以用这种方式表示）。
【讨论】：