如果你在Google或者百度上搜索数据建模，相信可以搜索出很多关于数据建模的文章，但是你会发现其中绝大部分是理论、方法论、概念等，读起来很学院派，感觉很有道理，但是心里不由在想，我到底该怎么进行数据建模呢？

　　笔者自06年投身到IT行业中，主要活动在数据库层，数据建模，数据库设计以及数据库开发，尤其是在数据仓库领域，期间用到的数据库主要是SQL Sever和MySQL；目前正在给国内一家客户做内部IT系统的数据建模工作，主要负责数据库（MySQL）设计。自己也读过一些数据库设计方面的书籍，在各大技术类网站上也拜读过很多神贴，大大小小的项目的数据库设计工作也参与过几十个，今天有幸在TechTarget数据库网站上和大家分享自己对数据建模的观点，任何不同观点或者反对意见，欢迎大家发送到我的邮箱max.lee.aihua23#gmail.com；就像数据库设计一样，不可能一步到位，都是一个迭代的过程，在讨论甚至是争论中成长！

　　数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。其中概念建模和逻辑建模阶段与数据库厂商毫无关系，换言之，与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上，我们可以这样写，用户都要通过填写个人基本信息以及一个邮箱来注册账户，之后使用这个邮箱作为登录帐号登录系统进行交易。

　　在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！！因为这些东西使我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。可能有的人在这个阶段担心会不会丢掉或者漏掉一些实体?也不用担心，现在好多公司都在采用Scrum的开发模式，只要你当前抽象出来的实体满足当前的User Story，或者当前的User Story里面的实体，你都抽象出来了，就可以了！如果你再说，我们User Story太大，实体太多，不容易抽象，那就真没办法了，建议你们的团队重新开Sprint 计划会议。

      点击继续阅读：详解数据建模的三个阶段：物理建模 、详解数据建模的三个阶段：逻辑建模