数据库建模工具是什么东西？什么是数据建模

本文目录

• 数据库建模工具是什么东西
• 什么是数据建模
• 如何进行数据建模
• 数据仓库数据建模的几种思路
• 数据建模的如何进行
• 关于数据库建模，概念模型，逻辑模型，物理模型的区别和转化

数据库建模工具是什么东西

你说的使用过程和建模工具还真差不多。所谓建模就是把现实世界的东西模型化到软件中的过程。数据库建模指的是把现实中没有使用计算机的情况下需要存储、处理的数据模型化到数据库中。关系数据库一般是以表（table）来存储数据的，对应现实中来说一个表的信息就是一类事物的信息。比如现实中的学生信息、课程信息，模型化到数据库中就是一个职工信息表、一个课程信息表。所谓建模工具就是帮助我们把现实中的事物模型化成数据库对象的工具。比如powerdesigner就是一个数据库建模工具，rational rose也可以进行数据库建模。在这些工具中我们一般先以汉字的形式定义现实中的各个事物及其属性（比如学生），然后定义各个对象之间的关系，比如一个学生可以学习多门课程，一门课程可以被多个学生学，那么他们之间就是多对多的关系，然后我们再将汉字信息转换成英文，最后工具根据我们定义的事物（数据库对象）及其关系生成相应的数据库脚本（不同数据库脚本语法可能不同），并执行脚本，这样就通过工具完成现实事物到数据库对象的建模了。我是做信息系统的，跟数据库打交道很多年了。记得选我的答案做推荐答案哦！

什么是数据建模

数据建模是一个用于定义和分析在组织的信息系统范围内支持商业流程所需的数据要求的过程。简单来说，数据建模是基于对业务数据的理解和数据分析的需要，将各类数据进行整合和关联，使得数据可以最终以可视化的方式呈现，让使用者能够快速地、高效地获取到数据中有价值的信息，从而做出准确有效的决策。

之所以数据建模会变得复杂且难度大，是因为在建模过程中会引入数学公式或模型，用于确定数据实体之间的关联关系。不同的业务逻辑和商业需求需要选择不同的数学公式或模型，而且，一个好的数据模型需要通过多次的测试和优化迭代来完成，这就使得数据建模的难度变得很高。但是，数据分析中的建模并没有想象中的那么高深莫测，人人都可以做出适合自己的模型。

数据建模总归是为了分析数据从而解决商业问题。如下图数据建模的流程图，数据建模核心部分是变量处理和模型搭建。

• 变量处理

在建模之前，首先要决定选择哪些变量进行建模，主要从业务逻辑和数据逻辑两方面来考虑。业务逻辑需要了解数据来源的背景，通过了解业务知识来判断哪些变量在业务上很有价值的，哪些变量是可以选择的。数据逻辑则是从数据的完整性，集中度，是否与其他变量强相关等角度来考虑。

除了选择变量，对于一些变量的重构也是需要在建模前进行。例如客户的满意度有“满意”“不满意”，可以将其重构成数字“0”和“1”，便于后续建模使用。除此以外，还有将变量单独计算（取平均值）和组合计算（如A*B）也是常用的重构方法，例如，缺失值以数据取平均值的方式替换。

• 模型搭建

在模型搭建时，会经历选择算法、设定参数、加载算法、测试结果四个过程。在这个过程中，测试结果会引导调整之前设定的参数，加载算法会对应调整之前选择的算法，而选择算法时会考虑到已定的变量，如果变量不满足算法要求，还需回到选择/重构变量，直至得到最合适的模型。

在优化模型的过程中，模型的解释能力和实用性会不断地提升。在结果输出之后，还需接收业务人员的反馈，看看模型是否解决了他们的问题，如果没有，还需进一步修改和调整。

MicroStrategy在数据领域深挖企业需求，经过多年的研究和沉淀，结合众多复杂的应用场景，不断更新体验，深入开发各种数据辅助功能，使客户可以一站式链接各类型数据资源，完成数据导入和数据建模。在MicroStrategy 平台中，既支持传统方式数据建模，即通过Project Schema 来进行建模，又支持自助式数据导入的建模方式。

如何进行数据建模

如何进行数据建模正确完成建模在过去的几十年里，数据建模的努力通常集中在关系数据建模或可扩展标记语言(XML)的建模上。只要数据存储在关系数据库中，关系数据建模就会很好，但除此之外，它很少会有其他的用途。而且XML也不能被可靠地称为建模语言。XML是序列化数据的规范--即定义了如何将数据写入文件。XML为构造数据的序列化提供了一种格式，但它不是一个真正的模型。我所说的“模型”指的是以数学为基础的形式规范。实际上，这意味着是可以使用形式化方法进行验证的东西。通俗地说，这意味着我们可以用数学运算来证明它是正确的，并且我们可以使验证过程自动化。而在XML模式中捕获数据不符合此定义下的模型。但可以肯定的是，我们可以使用软件来验证该XML格式是否良好，是否符合一些XML模式的文档。但这还不足以真正地对数据进行建模。无论是计算机还是人，如果不同时理解数据的语法(结构)和语义(含义)，就无法理解数据。XML可以捕获语法，但它不能天生捕获语义。语义可以用XML格式编写，但是这些语义必须首先在一些更正式的建模方案中被捕获。换句话说，企业需要一个正式的本体。这种建模方案大多基于形式逻辑，通常是公共逻辑或描述逻辑。迄今为止，最常用的语义建模语言是基于描述逻辑的网络本体语言(OWL)。这意味着我们不仅可以正式验证模型及其包含的数据，还可以通过对数据的推理来推断新的事实，并且我们可以证明这些推断的正确性。因为OWL是本体建模的事实上的标准，所以我将把剩下的内容限制在OWL上。但是等等!所有这些都不意味着你需要将你的数据存储为OWL。在你过于担心如何将存储格式强加给不情愿的开发人员之前，先听我说完。

数据仓库数据建模的几种思路

数据仓库数据建模的几种思路主要分为一下几种

1. 星型模式

星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；

2. 雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用

雪花模式

3．星座模式

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

星座模型

数据建模的如何进行

概念建模数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。其中概念建模和逻辑建模阶段与数据库厂商毫无关系，换言之，与MySQL，SQL Server，Oracle没有关系。物理建模阶段和数据库厂商存在很大的联系，因为不同厂商对同一功能的支持方式不同，如高可用性，读写分离，甚至是索引，分区等。概念建模阶段实际工作中，在概念建模阶段，主要做三件事：1. 客户交流2. 理解需求3. 形成实体这也是一个迭代，如果先有需求，尽量去理解需求，明白当前项目或者软件需要完成什么，不明白或者不确定的地方和客户及时交流，和客户double confirm过的需求，落实到实体（Package）；但是好多时候我们需要通过先和客户交流，进而将交流结果落实到需求，之后进一步具体到实体；本文可能会涉及到一些来自于EA（Enterprise Architect 7.1）建模术语，（EA中将每个实体视为一个Package）。这里并不对各种建模工具进行比较，如Visio，EA，PowerDesigner， ERWin等；其实作为员工的我们选择性很少，公司有哪个产品的Licence，我们就用哪个吧。举例说明：在一个B2C电子商务网站中，这样的需求再普通不过了：客户可以在该网站上自由进行购物！我们就以这个简单例子，对其进行细分，来讲解整个数据建模的过程，通过上面这句话，我们可以得出三个实体：客户，网站，商品；就像Scrum（敏捷开发框架的一种）中倡导的一样每个Sprint，都要产出确确实实的东西，OK，概念建模阶段，我们就要产出实体。客户和商品（我们将网站这个实体扔掉，不需要它。）在创建这两个实体（Package）的时候，我们记得要讲对需求的理解，以及业务规则，作为Notes添加到Package中，这些信息将来会成为数据字典中非常重要的一部分，也就是所谓的元数据。BTW，EA或者其他建模工具应该都可以自动生成数据字典，只不过最终生成的格式可能不太一样。如在Customer这个Package的Notes上，我们可以这样写，用户都要通过填写个人基本信息以及一个邮箱来注册账户，之后使用这个邮箱作为登录帐号登录系统进行交易。在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！！因为这些东西使我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。可能有的人在这个阶段担心会不会丢掉或者漏掉一些实体?也不用担心，2013年好多公司都在采用Scrum的开发模式，只要你当前抽象出来的实体满足当前的User Story，或者当前的User Story里面的实体，你都抽象出来了，就可以了！如果你再说，我们User Story太大，实体太多，不容易抽象，那就真没办法了，建议你们的团队重新开Sprint 计划会议。逻辑建模逻辑建模阶段对实体进行细化，细化成具体的表，同时丰富表结构。这个阶段的产物是，可以在数据库中生成的具体表及其他数据库对象（包括，主键，外键，属性列，索引，约束甚至是视图以及存储过程）。我在实际项目中，除了主外键之外，其他的数据库对象我都实在物理建模阶段建立，因为其他数据库对象更贴近于开发，需要结合开发一起进行。如约束，我们可以在web page上做JavaScript约束，也可以在业务逻辑层做，也可以在数据库中做，在哪里做，要结合实际需求，性能以及安全性而定。针对Customer这个实体以及我们对需求的理解，我们可以得出以下几个表的结构，用户基本信息表（User），登录账户表（Account），评论表（Commnets,用户可能会对产品进行评价），当然这个案例中我们还会有更多的表，如用户需要自己上传头像（图片），我们要有Picture表。针对产品实体，我们需要构建产品基本信息表（Product），通常情况下，我们产品会有自己的产品大类（ProductCategory）甚至产品小类（ProductSubCategory），某些产品会因为节假日等原因进行打折，因为为了得到更好的Performance我们会创建相应ProductDiscount表，一个产品会有多张图片，因此产品图片表（ProductPicture）以及产品图片关系表（ProductPictureRelationship），（当然我们也可以只设计一张Picture表，用来存放所有图片，用户，产品以及其他）有人说产品和图片是一对多的关系，不需要创建一个关系表啊?是的，我认为只要不是一对一的关系，我都希望创建一个关系表来关联两个实体。这样带来的好处，一是可读性更好，实现了实体和表一一对应的关系，二是易于维护，我们只需要维护一个关系表即可，只有两列（ProductID和PictureID），而不是去维护一个Picture表。客户进行交易，即要和商品发生关系，我们需要Transaction表，一个客户会买一个或者多个商品，因为一笔Transaction会涉及一个或多个Products，因此一个Transaction和ProductDiscount之间的关系（ProductDiscount和Product是一一对应的关系）需要创建，我们称其为Item表，里面保存TransactionID以及这笔涉及到的ProductDiscountID（s），这里插一句，好多系统都需要有审计功能，如某个产品历年来的打折情况以及与之对应的销售情况，我们这里暂不考虑审计方面的东西。就这样，我们根据需求我们确定下来具体需要哪些表，进一步丰富每一个表属性（Column），当然这里面会涉及主键的选取，或者是使用代理键（Surrogate Key），外键的关联，约束的设置等细节，这里笔者认为只要能把每个实体属性（Column）落实下来就是很不错了，因为随着项目的开展，很多表的Column都会有相应的改动。至于其他细节，不同数据库厂商，具体实现细节不尽相同。关于主键的选取多说一句，有的人喜欢所有的表都用自增长ID作为主键，而有的人希望找到唯一能标识当前记录的一个属性或者多个属性作为主键；自增长ID作为代理主键，对于将来以多个类似当前Transaction System作为数据源，构建数据仓库的时候，这些自增长ID主键会是一个麻烦（多个系统中，相同表存在大量主键重复）；使用一个属性或多个属性作为作为主键，不管主键是可的，读写效率是我们必须考虑得。所以并没有一个放之四海而皆准的原则，笔者只是给大家推荐一些考虑的因素。物理建模物理建模阶段EA可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码，运行来创建相应具体数据库对象（大多数建模工具都可以自动生成DDL SQL代码）。但是这个阶段我们不仅仅创建数据库对象，针对业务需求，我们也可能做如数据拆分（水平或垂直拆分），如B2B网站，我们可以将商家和一般用户放在同一张表中，但是针对PERFORMANCE考虑，我们可以将其分为两张表；随业务量的上升，Transaction表越来越大，整个系统越来越慢，这个时候我们可以考虑数据拆分，甚至是读写分离（即实现MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，当然不同存储引擎采用不同的方案），这个阶段也会涉及到集群的事情，如果你是架构师或者数据建模师，这个时候你可以跟DBA说，Alright,I am done with it,now is your show time.相信大家都知道范式，更有好多人把3NF奉为经典，3NF确实很好，但是3NF是几十年前提出来的，那个时候的数据量以及访问频率和2012年完全不是一个数量级的；因此我们绝对不能一味地遵守3NF；在整个数据建模过程中，在保证数据结构清晰的前提下，尽量提高性能才是我们关注的要点，因此笔者大力倡导数据适当冗余!上面笔者是结合一些实际例子表达自己对数据建模的观点，希望对读着有用。在数据建模过程中，不要希望一步到位将数据库设计完整，笔者不管是针对data warehouse还是Transactional Database设计，从来没有过一次成功的经历。随着项目的进行，客户和开发团队对业务知识与日增长，因此原来的设计也在不断完善中。毕竟，数据建模或者设计数据库不是我们的最终目的，我们需要的是一个健壮，性能优越，易扩展，易使用的软件!

关于数据库建模，概念模型，逻辑模型，物理模型的区别和转化

最近在进行UML学习过程中，突然忘记了大学时关于数据库理论中概念模型、逻辑模型、物理模型之间的区别。随机复习上网并复习，并在此记录一下，数据库建模是对现实世界进行分析、抽象、并从中找出内在联系，进而确定数据库的结构。 1、概念模型：就是从现实世界到信息世界的第一层抽象，确定领域实体属性关系等，使用E-R图表示，E-R图主要是由实体、属性和联系三个要素构成的。 2、逻辑模型：是将概念模型转化为具体的数据模型的过程，即按照概念结构设计阶段建立的基本E-R图，按选定的管理系统软件支持的数据模型（层次、网状、关系、面向对象），转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。目前最流行就是关系模型（也就是对应的关系数据库） E-R图向关系模型的转换是要解决如何将实体和实体间的联系转换为关系，并确定这些关系的属性和码。这种转换一般按下面的原则进行： （1）一个实体转换为一个关系，实体的属性就是关系的属性，实体的码就是关系的码。 （2）一个联系也转换为一个关系，联系的属性及联系所连接的实体的码都转换为关系的属性，但是关系的码会根据联系的类型变化，如果是： 1：1联系，两端实体的码都成为关系的候选码。 1：n联系，n端实体的码成为关系的码。 m：n联系，两端实体码的组合成为关系的码。 3、物理模型就是根据逻辑模型对应到具体的数据模型的机器实现。物理模型是对真实数据库的描述。如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。