业务人员必须了解的数据库设计知识
What business folks have to understand about database design
我有一个业务团队要我安排一次会议来向他们解释数据库设计注意事项。由于他们对 RDMS 了解不多，我想在下面解释一下
- 什么是 RDBMS
- 什么是 table 以及什么是约束/我们为什么需要它们
- 什么是事务，什么是 ACID 属性
需要考虑的事项 before/while 开发 dbms
一个。确定您需要多少细节以及将来可能需要多少
b.识别具有唯一值的字段
C。 Select 适合您字段的数据类型
d.归一化和索引设计
而且大多数时候，这个团队的数据来自平面文件，我们需要将这些文件加载到数据库中并以他们需要的格式表示。任何人请建议我可以解释更多或更好的解释方式。他们的数据无处不在。我只是想更多地强调仔细考虑，因为我们无法设置 stable 进程来执行导入。也欢迎给我任何建议 :)
感谢您的帮助！
如何从CRUD操作的基础开始，然后转向规范化，给出规范化需求的场景和RDBMS中Keys的概念，然后你可以谈谈ER建模
考虑到您要向商务人士展示，我认为有 2 种方法最适合您的需求。
a) 当你没有时间时:
- 只涵盖需要最少或不需要先验知识的主题。涵盖 RDMS 和需要考虑的事项。
- 保持简单易懂。告诉他们您的解决方案是如何工作的以及为什么它是有效的。
- 仅涵盖相关的主题，使其对外行友好。向他们提供您的数据库设计的优缺点。将其与业务需求联系起来。
- 在所有情况下，请提供他们可能轻松关联的上下文示例。
b) 当你有更多时间时
- 您可以按照之前评论中的建议详细介绍主题。 (@SQL_Underworld & @Ramya)
您还没有说出您的听众希望从您的演讲中学到什么。所以我不得不根据我过去与商界人士的往来进行猜测。您的里程可能会有所不同。
业务人员通常不关心您为做好数据库设计工作而投入的技能和知识，即使他们说他们关心。他们想从成本和收益的角度理解数据库设计。商人就是这么想的。
因此，如果您必须涵盖一些技术主题（如索引），请从成本效益的角度考虑。向 table 添加索引是有成本的，而向 table 添加索引是有好处的。提前弄清楚收益是否值得付出代价才是真正棘手的部分，他们会对此感兴趣。
在更大范围内，数据是一种商业资产。管理好资产是有成本的，管理好资产是有好处的。如果你能把你的演讲与这两个概念联系起来，他们就会感兴趣。
如果他们真的是优秀的业务人员，他们将对数据库涵盖的主题有很好的理解，前提是它是影响他们业务的企业数据的一部分。如果您有一个良好的数据库数据 ER 模型，该模型会将每个 table 中的每个值连接到一个属性，并且每个属性都将描述主题的某些方面。这是对 ER 模型的一种非常不同的使用，而不是仅仅将它用作创建关系模型的准备。
技术人员倾向于将 ER 建模视为 "relational modeling light"。它真的比那更深。这是问题 "what does the data really mean?" 的分析句柄，这是 "what is the data really worth?" 的句柄。这就是技术世界与商业世界相遇的地方。
我有一个业务团队要我安排一次会议来向他们解释数据库设计注意事项。由于他们对 RDMS 了解不多，我想在下面解释一下
- 什么是 RDBMS
- 什么是 table 以及什么是约束/我们为什么需要它们
- 什么是事务，什么是 ACID 属性
需要考虑的事项 before/while 开发 dbms
一个。确定您需要多少细节以及将来可能需要多少 b.识别具有唯一值的字段 C。 Select 适合您字段的数据类型 d.归一化和索引设计
而且大多数时候，这个团队的数据来自平面文件，我们需要将这些文件加载到数据库中并以他们需要的格式表示。任何人请建议我可以解释更多或更好的解释方式。他们的数据无处不在。我只是想更多地强调仔细考虑，因为我们无法设置 stable 进程来执行导入。也欢迎给我任何建议 :)
感谢您的帮助！
如何从CRUD操作的基础开始，然后转向规范化，给出规范化需求的场景和RDBMS中Keys的概念，然后你可以谈谈ER建模
考虑到您要向商务人士展示，我认为有 2 种方法最适合您的需求。
a) 当你没有时间时:
- 只涵盖需要最少或不需要先验知识的主题。涵盖 RDMS 和需要考虑的事项。
- 保持简单易懂。告诉他们您的解决方案是如何工作的以及为什么它是有效的。
- 仅涵盖相关的主题，使其对外行友好。向他们提供您的数据库设计的优缺点。将其与业务需求联系起来。
- 在所有情况下，请提供他们可能轻松关联的上下文示例。
b) 当你有更多时间时
- 您可以按照之前评论中的建议详细介绍主题。 (@SQL_Underworld & @Ramya)
您还没有说出您的听众希望从您的演讲中学到什么。所以我不得不根据我过去与商界人士的往来进行猜测。您的里程可能会有所不同。
业务人员通常不关心您为做好数据库设计工作而投入的技能和知识，即使他们说他们关心。他们想从成本和收益的角度理解数据库设计。商人就是这么想的。
因此，如果您必须涵盖一些技术主题（如索引），请从成本效益的角度考虑。向 table 添加索引是有成本的，而向 table 添加索引是有好处的。提前弄清楚收益是否值得付出代价才是真正棘手的部分，他们会对此感兴趣。
在更大范围内，数据是一种商业资产。管理好资产是有成本的，管理好资产是有好处的。如果你能把你的演讲与这两个概念联系起来，他们就会感兴趣。
如果他们真的是优秀的业务人员，他们将对数据库涵盖的主题有很好的理解，前提是它是影响他们业务的企业数据的一部分。如果您有一个良好的数据库数据 ER 模型，该模型会将每个 table 中的每个值连接到一个属性，并且每个属性都将描述主题的某些方面。这是对 ER 模型的一种非常不同的使用，而不是仅仅将它用作创建关系模型的准备。
技术人员倾向于将 ER 建模视为 "relational modeling light"。它真的比那更深。这是问题 "what does the data really mean?" 的分析句柄，这是 "what is the data really worth?" 的句柄。这就是技术世界与商业世界相遇的地方。