上一次我摘了些第一章的内容,整理成了笔记,不知道对大家有没有点帮助啊,呵呵...第一章主要是讲了些概念上的东西，让大家对基本的概念有点理解，没有摘完全，只是选了我觉得有概括性的语句。现在，来写写第二章的笔记吧，Ready?？GO！
第二章 工作场所中的数据库建模
第一章描述了数据库模型设计的历史，不同类型的应用程序，以及这些应用程序如何影响数据库模型的基本结构。对于数据库模型设计者来说，人非常重要。这些人几乎总是终端用户。对于数据库模型创建者来说，重要的是查找需要什么人。人的技术是必要的。这一章，将让我们理解在数据库模型设计中，人是非常重要的因素，无数数据库是否已经存在。
业务规则与目标
业务规则定义：业务规则在本质上是公司日常工作中的一切过程和流程，即该业务的操作和执行公司的操作过程所进行的决策。
业务规则在本质上具有关于定义和重新定义的重要作用范围，甚至是在一个公司中，从本质上来说，业务规则包含公司的以下方面：
任何形式的，任何类型的公司策略及公司的任何层次
任何类型的计算或公式
任何类型的规章制度
结合人的因素
作为资源的人：请您构建数据库模型的人通常可以告诉您关于模型中应该包含的大部分内容，有时甚至会告诉您模型中的每个部分应该如何互相关联。然而，这个人通常不是技术人员，并且不了解数据库模型设计。数据库设计人员应该将用户的思想和语句用专门技能演绎。用户和设计人员在这个过程中具有同等重要性。
设计数据库模型是细节的抽象化。抽象化是逻辑的或算术的过程，设计抽象化用于更容易地处理特定的情况。抽象化尝试划分不同的活动，最终在划分的层次上进行处理，而不是在活动的层次上。经过适当的抽象化，业务环境中两种明显不同的事情可以变为相同的事情。
与适合的人交谈
具有最多业务知识的人通常是经理、小型公司的管理层以及较大型公司中的中层管理。对于大型公司，最佳的讨论人选是具有良好的整体业务描述的高级经理。相比于进一步缩小范围到很好地了解业务的人，或许是同时具有专门技能和业务操作技能的某个人，这些人有更多时间与数据库设计人员进行交流。
数据库模型需求越复杂，您就必须提出越多的问题。提出的问题越多，设计解决方案的结构中就有越多的细节和层次。
非常复杂的数据库模型不是最终的目标。应用程序开发者和终端用户需要简单性。如果没有适当的简单性，数据库模型设计就可能无法使用，特别是在终端用户和数据仓库的情况中。
数据库模型创建者的工作是通过抽象化实现简单性。
获得正确的信息
获得正确的信息实际上是与合适的人讨论的延伸，其中正确的细节来自于了解公司如何正常盍的人所说的话。查看正确信息的另一种方法是与更多的人进行讨论，这些人牌处于公司的不同部门和阶层中。
重要的不是您知道什么，而是您认识谁；也不是您说什么，而是如何说！
永远不要假设您比内部员工知道更多的内容，但也要认识到，您确实有一些经验。
重要的是倾听！倾听，学习，并且研究所得到的每部分信息。
处理不利和情况
相当常见的是，设计的最佳环境是完全非计算机化的环境。
将一沓纸计算机化
对于基于纸张的系统，问题通常是没有非常细心地设计它，并且已经或多或少地成为必要的情况。通过纸张系统的最容易方法是收集尽可能多的打印材料，然后开始对其进行分类。
转换传统的数据库
转换传统的数据库往往可能是最困难的工作。有时数据库是部分不可访问或者很难访问。有时数据库甚至可能使用网络或层次结构数据库建模技术。好的方法是首先找到公司中的专家。通过与其他人进行讨论和询问问题，获得更进一步的、更快的和更容易的解决方案。
异类数据库的同类集成
异类系统是由不同部分组成的系统。任何类型的数据库都可以使用其中任何一个数据库执行集成。思路是控制数据库中检索数据，该数据库建立异类的、无缝的、透明的接口，并且管理任何数量的底层数据库中的数据。
从电子表格转换
将电子表格等转换为数据库模型的优点是，电子表格可能在很多方面没有基于主机的传统网络数据库或基于纸张的系统那么复杂。
整理混乱的数据库
整理混乱的数据库暗示已经存在关系数据库，但该数据库模型是完全混乱的。在其中可以找到无效的数据、孤立的记录、以及其他类似的问题。在开始之前，首先建立所需的内容。在建立期望的记录后，您甚至可能发现只有很少的将要结构错误或关系错误，这些错误很容易修复。
这一章主要是谈到了在工作场所中的建模，主要强调了人的作用。在很多时候，我们总是会用专业的眼光，从技术的角度出发，做出我们认为是理所当然的模型。却忽略了一个很关键的因素：人。
在最近的电子辞典项目中，负责人也开始强调这一点：要从用户的角度出发，从人出发。。。
标签：入门,数据库,业务,抽象化,设计,第二章,模型,公司 From： https://blog.51cto.com/u_16129500/6349021