网页设计相关的网站,wordpress外贸主题免费下载,化工营销型网站,苏州的建筑公司网站点击关注 异步图书#xff0c;置顶公众号每天与你分享 IT好书 技术干货 职场知识本文大概 10624 字读完共需 30 分钟Tips 参与文末话题讨论#xff0c;即有机会获得异步图书一本。数据建模是对现实世界各类数据进行抽象组织、界定数据库需管辖的范围、确定数据的组织形式等直…点击关注 异步图书置顶公众号每天与你分享 IT好书 技术干货 职场知识本文大概 10624 字读完共需 30 分钟Tips 参与文末话题讨论即有机会获得异步图书一本。数据建模是对现实世界各类数据进行抽象组织、界定数据库需管辖的范围、确定数据的组织形式等直至转化成现实数据库的过程。而数据模型是构建应用系统的核心是尽可能精准地表示业务运转的概念性框架。数据建模的过程是界定、分析、发现数据需求再用可视化的形式“模型”表示这种数据需求的过程。数据模型是用于精确表示信息领域沟通的一套符号和文字。任何景观的模型都会包含某些内容例如地图就是地理景观的模型同时为了方便理解又排除某些内容。“发现”是确定业务过程或应用中业务需要什么信息例如了解到客户和账号是个重要的概念。“分析”是明确需求的过程例如对客户和账户逐步有了清楚的定义理解了客户与他们的账户之间的关系。“界定范围”涉及与业务合作来决定什么对于特定的业务阶段是最重要的。例如第一阶段是否同时需要“保存”和“检查账号”还是只要“检查账号”就行了。“表示”是指要用清晰明确的语言展现出信息景观看上去是什么样的例如可以用以下数据模型表示一个客户可以有一个或多个账号。一个账号必须由一个或多个客户拥有。一旦我们将这些需求写成了数据模型文档就可以跟应用开发所涉及的业务和信息技术Information TechnologyIT人员进行沟通了如业务用户、业务分析师、数据建模人员、数据架构师、数据库管理员、开发者、测试人员以及管理人员。数据模型是用于从业务到ITIT内部从系统分析员、建模人员、架构师到数据库设计人员和开发人员之间沟通的主要媒介。无论要用的数据库技术是关系数据库管理系统Relational Database Management SystemRDBMS如ORACLE、Teradata还是像MongoDB或Hadoop这样的非关系型数据库Not Only SQLNoSQL都需要有种方式能用来沟通数据需求。因此我们需要数据模型。数据模型应该是高质量的要能支持目前的需求同时又要能满足未来的需要。数据模型记分卡是一个可以用来改进数据模型质量的工具。许多我正在为他们提供咨询服务的客户都决定将数据记分卡应用到客户的数据模型中他们也推荐用数据模型记分卡来改进设计。大数据就业挑战月薪30K,本文将简要介绍数据模型的组成并教你如何看懂数据模型。1.1 实体实体表示与业务有关的重要且有价值的事务的信息集合。每个实体由一个名词或名词词组来表示一般适用于以下6种问题之一谁、什么、何时、哪里、为什么、如何。表1-1是这些实体类的定义并举例说明。表1-1 实体类的定义分类定义举例谁Who能为企业带来好处的个人或组织。“谁对业务很重要”常常与角色有关例如客户或供应商员工、病人、演员、嫌疑人、客户、供应商、学生、旅客、参赛者、作者什么What对企业有利的产品或服务。常常指能使组织保持业务运转的产出物。“什么是对业务至关重要的”产品、服务、原材料、货物清单、课程、歌曲、照片、图书何时When企业所关心的日历或时间周期。“何时业务在运作”时间、日期、月份、季度、年、学期、会计期间、分钟哪里Where企业关心的位置。位置可以指实际的地理位置也可以指虚拟的位置。“业务在哪里开展”邮件地址、分布地点、网站的URL及IP地址为什么Why企业所关心的事件或事务。事件会让业务具有不确定性。“业务为什么可以运转”订单、盈利、投诉、取钱、存钱、褒扬、问询、交易、索赔如何How将企业关心的事件记录下来。可以用文档记录事件如采购订单用于记录一个订单事件。这就是”业务是如何跟踪事件的”发票、合同、协议、购买订单、收据、发票、装箱清单、交易确认单实体的实例是指特定实体的发生或实体的值。例如表单就是一个实体它的表头的每个字段表示每个实体要记录的信息。每个有实际值的表单行表示一个实体实例。“客户”实体可能会有多个有不同名字的客户实例如Bob、Joe、Jane等。“账号”实体有Bob的支票账户实例、Bob的存款账户实例、Joe的佣金账户实例等。实体可以从概念层、逻辑层、物理层进行描述。概念层是对一个业务过程或应用系统定义其范围和重要术语。逻辑层是对一个业务过程或应用系统的业务解决方案进行详细描述物理层则是对一个应用系统的技术解决方案进行详细描述。一个与概念层相关的实体一定是对业务基本且关键的。至于什么是“基本且关键的”主要因范围不同而不同。在通用层面某些概念是大多数公司都共有的例如客户、产品和员工。稍微收窄这个范围特定的行业可能会有某个特定的概念。例如广告役这在广告行业是有个有效的概念但在其他行业中却不适用。在出版行业作者Author、书Title和订单Order是概念实体如图1-1矩形框中的名字。图1-1 用矩形框中的名字表示概念实体逻辑层的实体比概念层更加详细地表示了业务。经常会用一个概念实体表示多个逻辑实体。逻辑实体包含一些特性我们叫作“属性”下一节会讨论。前面的概念实体可以由3个逻辑实体表示如图1-2所示。图1-2 逻辑实体在物理层实体与技术特定的对象有关例如关系数据库管理系统Relational Database Management SystemRDBMS中的数据库表或者非关系型数据库Not Only SQLNosglMongoDB中的集合。物理层与逻辑层相似但可以包括弥补技术缺陷所需要的折中方案一般是与性能或存储有关的。以下是前述逻辑实体的物理实体如图1-3所示。物理实体包含数据库特定的信息例如属性的格式和长度作者的姓氏即Author Last Name是50个字符长度该属性是否必须有值作者的税号标识即Author Tax Identifier不能为空因而必须有值作者的出生日期即Author Birth Date是可空的所以不要求一定有值。图1-3 物理实体在关系数据库管理系统Relational Database Management SystemRDBMS中这些物理实体是数据库表或视图。在非关系型数据库Not Only SQLNoSQL中这些物理实体根据所用的技术不同而不同。例如在MongoDB这样的文档数据库中这些实体是集合。常用的术语“结构”是指数据库组件无论这种数据库是RDBMS还是NoSQL类型。1.2 属性属性是用来识别、描述或度量实体实例的单个信息单元。货运单号Claim Number属性标识每个货运单。学生姓氏Student Last Name属性描述每个学生。订单金额Gross Sales Amount属性度量每笔交易的金额。像实体一样属性也可以在概念、逻辑和物理层描述。概念层的属性必须是对业务基本且关键的。通常我们并不从概念层描述属性当然根据业务需求的不同也可以作为概念层的属性。我在一家通讯公司工作时电话号码是对业务非常重要的属性所以多个概念模型中都有电话号码属性。逻辑模型的属性表示业务特性。每个属性显示出它对业务解决方案的贡献并且独立于任何软硬件技术。例如作者的姓氏Author Last Name就是一个属性因为它有重要的业务意义无论这些记录是保存在纸质文件里还是能快速检索的数据库里。物理模型的属性代表数据库的一列。作者的姓氏Author Last Name属性可能在关系数据库的AUTH表里用AUTH_LAST_NM列表示或者在MongoDB集合LibraryCardCatalog中用AuthorLastName表示。1.3 域一个属性所有可能赋值的全部集合叫作域。域包括一套可应用于不止一个属性的验证标准。例如日期Date域含有可给以下这些属性赋值的所有可能的有效日期。员工雇用日期下单日期交货日期课程开始日期一个属性一定不能包含其赋值域以外的值。域值由特定的实际列表值定义或者由一套规则定义。例如员工性别代码其值域限制为男和女员工雇用日期可能有默认的规则这个域值只能是有效的日期。因此可能会有以下值如2005-02-151910-01-25201504102050-03-10员工雇用日期必须是有效日期例如不能是2月30号。还可以用附加的规则来限制属性的域值。例如将员工雇用日期域限制为必须早于今天的日期这样就能排除类似2050年3月10日这样的日期。限制员工雇佣日期为YYYYMMDD格式年、月、日连接就能排除所有不符合日期格式的值例如20152410就会违规。另外一种限制域值的方式是规定员工雇用日期只能是周一、周二、周三、周四、周五的日期即只能是工作日。有3种基本的域类型。格式化域设定数据库中可用的标准数据类型。如Character(30)和date这些都是格式化域。列表域类似于下拉列表列出几个值可供选择。列表域是格式化域的改良。订单状态代码的格式化域可能是 Character(10)这个域可以从列表域可能的值打开已运送已关闭已退回中进行选择。范围域规定该域所允许的值在最小值和最大值之间。例如订单交付日期必须在今天和未来的几个月之间。与列表域类似范围域也是格式化域的改良。1.4 关系实体间的关系是指这些实体的实例可能以某种有意思的方式相关。每个关系都可以定义规则包括何时相关以及有多少实例相关。关系可以用两个实体间的一条线来描述。有些建模还可以有两个以上的关系它们会有不同的描述。如果这两个实体是员工和部门他们之间的关系可以描述为“每个员工必须为一个部门工作”“每个部门可以有一个或多个员工”。在两个实体关系中基数能记录有多少实例从一个实体参与到与另一个实体实例的关系中它由出现在关系线两端的符号表示。基数指定一种可强制的数据规则。如果没有基数我们最多可以说关系是两个实体以某种方式通过一个规则相互关联。例如员工和部门有某种关系但我们知道的仅限于这点。注意相同的两个实体可以有不止一种相关方式例如每个部门可以有一个或多个员工但是可能还会有一个单独的关系记录着某个员工管理某个部门。关于基数我们可以选择0、1或多m的组合。多m表示任何大于0的数。0或1可以记录一个实体实例在一个关系中是否是必需的。1或多m可以表示有多少个特定的实例参与这个关系。因为我们的图标仅有3种基数符号所以无法指定一个准确的数字[1]除非通过文档如“一辆车有4个轮胎”。我们只能说“一辆车可以有多个轮胎”以作者和书为例每种基数符号如图1-4所示。图1-4 基数的符号表示这个例子中的业务规则是每个作者Author可以写一本或多本书Title。每本书Title必须只能由一个作者Author写。短竖线表示1看上去像个1是吧圆圈表示0看上去也像个00表示可选但并不排除值1所以在上面的例子中一个作者Author只能写一本书Title。三角形中间有一根线意思是多个m。有人把m符号叫作鱼尾纹crow’s foot。关系线上通常有标签用来说明关系和关系所表示的规则。数据模型是一种通信工具如果你还记得实体是个名词关系标签就是一个现在时态动词。因此让我们读下面这句话。每个作者可以写一本或多本书。每个关系都有一个父实体和一个子实体。父实体出现在关系的1那边子实体出现在关系的多m那边。这个例子中父实体是作者Author子实体是书Title。当我读一个关系的时候我会从关系1那边的实体父实体开始。“每个作者可以写一本或多本书。”然后再从关系中多的那端读“每本书必须由一个作者写。”在读关系的时候我也总是使用“每个”从父实体那边开始。使用“每个”这个单词的原因是你想要指定一个实体平均有多少个实例与另一个实体的实例相关。有两种类型的关系依赖型identifying和不依赖型non-identifying。依赖型identifying关系用实线表示意思是m一侧的实体子总是1一侧的实体父的依赖型实体。虚线的意思是m一侧的实体子不依赖于1一侧的实体父。图1-5是这两种类型的关系。图1-5 两种类型的关系不依赖型实体以尖角矩形表示。依赖型实体以圆角矩形表示如“书”在依赖型关系中的例子。不依赖型的实体是实体的每个实例都只用它自己的属性。例如在不依赖型关系中“书”的例子可以由ISBN国际标准书号找到ISBN是属于“书”的一个属性。依赖型实体只能通过使用至少一个不同实体的属性找到如依赖型关系中的书和作者的税号。我们可以改变基数试试现在允许一本书可以由多个作者写如图1-6所示。图1-6 一本书可以由多个作者写与前面一对多的例子相比这是一个多对多关系的例子。这里的业务规则是每个作者可以写一本或多本书每本书必须由一个或多个作者写。“写”在这两个例子中都可以当成关系标签。有时候反向标签也会出现在关系线中例如由X写。我倾向于只显示一个关系标签以减少模型中的混乱同时也由于大多数情况我们能用相同的单词结构做反向标签写由X写。有 3 种层级的粒度概念、逻辑和物理可应用于实体和属性也可用于连接实体的关系。概念关系是高层规则或连接概念的检索路径。逻辑关系是详细的业务规则或逻辑实体间的强制规则的检索路径。物理关系则是详细的技术依赖规则或有关系连接的物理结构间的检索路径。这些物理关系可能最终会变成关系数据库管理系统中的数据库约束或文档数据库如MongoDB中的参照关系。1.5 键如果数据量很大如何才能快速找到你要找的数据呢这就是为什么需要键了。键可以用来创建强制规则还能高效地检索数据的一个或多个属性此外可以用来从一个实体检索另一个实体。这一节解释了候选键主键、替代键、代理键、外键和第二键。候选键主键、替代键候选键是一个或多个能唯一识别一个实体实例的属性。例如给每本书分配一个国际标准书号International Standard Book NumberISBN。ISBN唯一地识别每本书因此可以作为书的候选键。当把本书的ISBM编号“9781634620826”输入到多种搜索引擎或数据库系统时结果就返回了本书的实体实例《数据模型记分卡》你可以试试。税号可以是一些国家的组织机构候选键如美国。账号代码可以是账号实体的候选键。车辆标识号Vehicle Identification NumberVIN可以识别一辆车。有时候只用一个属性就能识别一个实体实例例如用ISBN识别书名。有时候却需要多个属性来唯一识别一个实体实例。例如必须通过促销类型代码和促销开始日期一起来唯一识别一个促销。当多个属性组成一个键时我们用术语“组合键”表示这种键。因此促销类型代码和促销开始日期一起构成促销的组合候选键。候选键有以下4个主要的特征。唯一的。一个候选键一定不能识别出多于一个实体实例一个真实世界的物品。强制的。候选键不能为空每个实体实例必须由一个候选键标识。所以候选键的所有不同值的数目总是等于全部不同实体的数目。例如用ISBN作为书的候选键如果有500个书的实例那么就有500个唯一的ISBN。不变的。实体实例上的候选键应该永远不变。最短的。候选键应该只包含那些可以唯一识别的实体实例的属性。如果有4个属性列出来作为一个实体的组合候选键但只有3个是标识唯一性所必需的那么就只需要由这3个属性组成候选键。例如每个学生可以学习一门或多门课程每门课程可以有一个或多个学生。表1-2表1-4是两个实体的一些简单实例。表1-2 学生表学生编号学生名学生姓氏出生日期SM385932SteveMartin1/25/1958EM584926EddieMurphy3/15/1971HW742615HenryWinkler2/14/1984MM481526MickeyMouse5/10/1982DD857111DonaldDuck5/10/1982MM573483MinnieMouse4/1/1986LR731511LoneRanger10/21/1949EM876253EddieMurphy7/1/1992表1-3 出勤表出勤日期5/10/20156/10/20157/10/2015表1-4 课程表课程全称课程简称课程描述数据建模基础数据建模101一门介绍性课程介绍数据建模的基本概念和原则数据建模进阶数据建模301一门技术类的进阶课程如高级范式和不规则层次结构网球基础网球教网球初学者学习这个游戏的关键方面杂技学习如何能同时保持让3个球在空中根据我们对候选键的定义候选键的特征是唯一的、稳定的和最小的应该选择什么字段作为这些实体的候选键呢对于学生实体学生编号看上去是个有效的候选键。有 8 个学生和 8个唯一的学生编号值。不像学生名和学生姓氏有重复值如名字 Eddie Murphy就有重复。而学生编号 Student Number 是唯一的。出生日期也有重复值如5/10/1982Mickey Mouse和Donald Duck的出生日期都有这个值。学生名、学生姓氏和出生日期这3个字段的组合也像一个有效的组合候选键但请注意我们不推荐使用这样的键因为这在某些系统中可能会有问题。出勤实体现在缺少了候选键。在这个简单的数据表中尽管出勤日期是唯一的我们可能需要知道在特定的日期里哪个学生上了哪门课程所以这个出勤实体的定义是不完全的。课程实体初看似乎任何属性都是唯一的都可以做候选键。然而杂技这门课程没有课程简称因此鉴于课程简称可以为空所以不能当做候选键。此外候选键的另一个特征是不变性。根据我的教学经验描述可能会变。因此课程描述也需要从候选键中排除只有课程全称才是候选键的最好选择。尽管一个实体可能有多个候选键但对于一个实体我们也只能选择一个候选键做主键。主键是从候选键中首选的能唯一标识实体的候选键。替代键是候选的尽管也有唯一性、稳定性和最小的特点却不能作为主键尽管替代键也可以用来查找特定的实体实例。在课程实体中只有一个候选键所以课程全称就变成主键。而学生实体需要做个选择因为它有两个候选键。应该用哪个候选键作主键呢选择哪个候选键作为主键需要考虑简洁和私密性。简洁意味着如果有几个候选键要选那个属性最少和长度最短的。而私密性有可能候选键中的一个或多个属性含有敏感数据查看这样的数据会受限。需要避免实体主键中含有敏感数据因为主键可能繁衍成外键因此会将这个敏感数据传播到整个数据库范围。在我们的例子中如果考虑简洁性和安全性我会选择学生编号而不是学生名、学生姓氏和出生日期。因为前者更简洁且含有更少的敏感信息。这是我们的主键和替代键的数据模型如图1-7所示。图1-7 主键和替代键的数据模型主键属性在矩形框中的横线之上。你会注意到有两个数字跟在键的缩写名“AK”之后第一个数是替代键的一组数字第二个数表示替代键中的属性顺序。所以学生实体属性的替代键有3个属性。学生名、学生姓氏和出生日期。这也是将要创建的替代键索引的顺序因为学生名在冒号之后有个“1”学生姓氏是“2”出生日期是“3”。出勤实体的主键是学生编号和课程全称这两个字段看上去可以组成一个有效的主键。注意出勤实体的两个主键属性跟着一个“FK”这是外键后面很快会讲到。所以简单地说一个候选键由一个或多个属性组成能唯一地识别一个实体实例。可以选择能最好地识别实体中每个记录的候选键作主键其他的候选键则作为替代键。由多个属性组成的键叫作组合键。在物理层候选键常常转换成唯一索引。1.6 代理键代理键是表的唯一标识符常用来计数通常具有固定长度一般由系统自动生成没有含义。所以代理键没有任何业务含义。换句话说不能看到一个月份标识符为1就认为它代表月份实体的实例值一月。代理键应该对业务是不可见的但应该保留在后台以允许更高效的检索也方便应用之间的集成。代理键也是高效的。你已经见过主键可能是多个实体属性的组合。相对于必须指定34个或56个属性来定位你要查找的一条记录使用单个代理键更高效。代理键有利于集成集成的目的是为了创建一个唯一一致的数据版本。像数据仓库这样的应用常常要保存不止一个应用或系统的数据。一个实体实例在每个源系统中都有不同的标识这些实体实例的相关性从公共的标识符看起来不太明显这时用代理键可以记录同一个实体实例的信息之间的相互关系。使用代理键时总是先确定自然键。自然键是能唯一识别实体的方式这是业务要考虑的然后将自然键定义为替代键。例如如表1-5所示假定一个代理键是比课程全称更高效的主键我们可以为课程实体创建课程编号代理键在自然键课程全称上定义一个替代键如图1-8所示课程的值。图1-8 在自然键课程全称上定义一个替代键表1-5 课程实体中的课程课程编号课程全称课程简称课程描述1数据建模基础数据建模101一门介绍性课程介绍数据建模的基本概念和原则2数据建模进阶数据建模301一门技术类的进阶课程如高级范式和不规则层次结构3网球基础网球教网球初学者学习这个游戏的关键4杂技学习如何能同时保持让3个球在空中1.7 外键在实体的“1”那侧的关系我们叫作父实体在“多m”那侧的关系叫作子实体。当我们创建一个从父实体到子实体的关系时父实体的主键就被复制为子实体的外键。外键是一个或多个属性提供到另外一个实体的链接也有种递归关系的情况同一个实体的两个实例是相关的一个链接连到同一个实体。在物理层面外键允许关系数据库管理系统从一个表到另外一个表进行检索。例如如果我们需要知道一个有账号的客户我们就想把客户编号放在账号实体中。账号实体中的客户编号就是客户实体的主键。使用外键返回到账号表可以让数据库管理系统从特定的账户检索或者从账号到客户进行检索再或者找到每个有账号的客户。类似地数据库可以从特定的客户到账号检索以找到某个客户的所有账号。当两个实体间的关系确定了之后数据库建模工具就自动地创建了外键。在学生/课程模型中出勤实体中有两个外键学生编号外键指向学生实体中特定的学生课程编号外键指向课程实体中特定的课程如表 1-6所示。表1-6 课程编号外键指向课程实体中特定的课程学生编号课程编号出勤日期SM38593215/10/2015EM58492615/10/2015EM58492626/10/2015MM48152626/10/2015MM57348326/10/2015LR73151137/10/2015通过查看这些值回忆起表1-6中的样例数据我们了解到Steve Martin和Eddie Murphy两人在2015年10月5号都听了数据建模基础这门课。Eddie Murphy还和Mickey Mouse、Minnie Mouse一起听了2015年10月6日的高级数据建模这门课。Lone Ranger在2015年10月7日上的是网球基础跟往常一样还是他一个人。另外注意出勤表Attendance当前的主键是假定一个学生只能参加一门课程一次。如果业务规则说明一个学生能参加一门课程一次或多次我们就需要修改出勤表的主键增加出勤日期Attendance Date字段。1.8 次键有时候需要从表中快速检索数据来回答业务的问题或满足响应时间的要求。次键是需要频繁访问和快速检索的一个或多个属性如果有多个属性就叫作组合次键。次键也就是众所周知的非唯一索引或反向条目inversion entryIE。次键不必唯一、稳定也不必非空。例如我们可以给学生表Student增加学生姓氏Student Last Name字段作为从键以允许无论何时需要查询学生姓氏Student Last Name都能快速检索如图1-9所示。图1-9 给学生表Student增加学生姓氏Student Last Name字段作为从键学生姓氏Student Last Name不唯一因为可能有两个人都叫Murphys它是不稳定的会随着时间变更尽管很少发生但也可能会有我们不知道某人名字的时候所以它可能为空。1.9 子类型子类型允许将公用属性、相似的关系或相关的实体分组。某些概念非常相似或者为了展示一些例子往往可以用子类型。在出版行业一个作者可能会写多部纸质版PrintVersion的书和多本电子版图书eBooks如图1-10所示。图1-10 一个作者可以写多部纸质版和多部电子版图书的模型每个作者Author可以写一本或多本纸质版PrintVersion的书。每个纸质版PrintVersion的书必须由一个作者Author写。每个作者Author可以写一本或多本电子书eBook。每本电子书eBooks必须由一个作者Author写。接下来让我们来介绍子类型如图1-11所示。图1-11 子类型每个作者Author可以写一本或多本书Title。每本书Title必须由一个作者Author写。每本书Title可以是纸质版PrintVersion或电子版eBook。每个纸质版PrintVersion的书都有一个书名Title。每个电子书eBook有一个书名Title。子类型关系隐含了一个规则即超类型的所有关系和属性也应用到每个子类型。因此从作者Author到电子书eBook有一种隐性的关系从作者Author到纸质版PrintVersion也是如此。titleName、subtitleName和titleRetailPrice属于纸质版PrintVersion也属于电子书eBook。注意每个子类型的主键是到超类型的外键所以它们有相同的属性。在这个例子中titleISBN是一本书的标识符。子类型不仅减少了数据模型上的冗余也能透过表面上唯一的和独立的概念从而更容易沟通它们的相似性。在某些情况下一个子类型可以有多个子类型集合例如一个人可能是一个孩子、青少年或成年人独立于这些分类一个人还可能是男性或女性。在某些情况下超类型可以没有任何子类型也能存在而在另一些情况下却不可以。每个超类型必须有一个子类型实例。例如一个人可能是一个司机或者不是无论哪种情况他仍然是一个人。但一个银行账号就必须总是某种特定子类型的账号。[1] 注意如果使用统一建模语言Unified Modeling LanguageUML中的类图就可以指定准确的基数。本文摘自《数据模型记分卡》《数据模型计分卡》【美】Steve Hoberman霍伯曼 点击封面购买纸书作为一本经典大师级著作本书非常适合对数据建模感兴趣的读者以及从事数据库等相关工作的专业人士参考阅读。通过阅读本书读者将对记分卡这一经典理论有更加全面、深入的理解。本书介绍了Steve Hoberman的经典理论——数据模型计分卡。全书分为3各部分共计16章内容。第一部分介绍了数据建模及验证包括数据建模、数据模型质量、数据模型计分卡概述等第二部分介绍了数据模型计分卡理论通过10个重要理论来介绍相关的知识要点第三部分介绍了如何使用计分卡验证数据模型。今日话题就业调查你的行业平均年薪大概是多少年龄年薪形式截止时间3月12日17时留言转发本活动到朋友圈小编将选出1名读者赠送异步新书一本。延伸推荐2018年2月新书 2018年1月重磅新书小学生开始学Python,最接近AI的编程语言安利一波Python书单政策升温大家都在学大数据一大波好书推荐一本基于Python语言的Selenium自动化测试书8本新书送出一本你喜欢的AI经典书单| 入门人工智能该读哪些书点击关键词新书Python|机器学习|Kotlin|Java|移动开发|机器人|有奖活动|Web前端|书单长按二维码可以关注我们哟每天与你分享IT好文。 在“异步图书”后台回复“关注”即可免费获得2000门在线视频课程推荐朋友关注根据提示获取赠书链接免费得异步图书一本。赶紧来参加哦 扫一扫上方二维码回复“关注”参与活动 点击下方阅读原文查看更多阅读原文
