数据库设计原理：数据建模的三个阶段

如果你在Google或者百度上搜索数据建模，相信可以搜索出很多关于数据建模的文章，但是你会发现其中绝大部分是理论、方法论、概念等，读起来很学院派，感觉很有道理，但是心里不由在想，我到底该怎么进行数据建模呢?
笔者自06年投身到IT行业中，主要活动在数据库层，数据建模，数据库设计以及数据库开发，尤其是在数据仓库领域，期间用到的数据库主要是SQL Sever和MySQL;目前正在给国内一家客户做内部IT系统的数据建模工作，主要负责数据库(MySQL)设计。自己也读过一些数据库设计方面的书 籍，在各大技术类网站上也拜读过很多神贴，大大小小的项目的数据库设计工作也参与过几十个，今天有幸和大家分享自己对数据建模的观点，任何不同观点或者反 对意见，欢迎大家发送到我的邮箱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 计划会议。