数据库关系是由数据库模型决定的，而数据模型抓住了数据的基础和参照完整性规则。要理解这是如何实现的，就要理解构建数据模型需要的基础步骤，这些步骤将生成数据定义语言的语句，用这些语句才能真正创建存放数据的物理结构，也就是数据库表和列。虽然数据建模流程中有很多变体，但对于关系模型来说，第一步通常是定义实体。
在中，实体可以是独立存在的任何东西，如物理对象，事件或概念。实体之间可以存在关系，实体和关系都可以具有描述它们的属性。打个比方，实体就是名词，关系就是动词，修饰实体的属性就是形容词，修饰关系的属性就是副词。
实体可以是某个事物的实例，例如客户订单，可以具有订单ID和价格这样的属性。把同种类型的实体集合起来就形成了实体集合。在网站建设项目的数据库中，实体相当于表中的一行，而实体集合相当于表。描述实体特有的属性是表的主键。主键通过唯一标识实体的实例实现了实体完整性。外键描述实体间关系的特有属性。外键把不同实体集中的两个实体关联在一起，从而实现了引用完整性。最常用的实体，关系和属性的图解表示法是实体关系图 – ERD。ERD展示了实体集间的基本关系，是一对一，一对多还是多对多。
一旦我们为项目中的数据建模，定义和映射了实体，关系和属性，设计数据模型就剩下最后一步了：规范化。规范化网站建设项目中的数据模型的主要目的是，确保存储数据的方式允许在保证数据完整性的前提下对数据进行CRUD操作。不规范的数据模型具有高度的数据冗余，这意味着数据完整性的风险更大。规范是逐级构建的，这意味着满足第二范式的数据库也必须满足第一范式。如果一个数据库至少满足第三范式，就可以认为它是规范的。
你可能已经想到，实体间的关系会对数据存储，提取和更新的有效性产生巨大影响。由于这些关系定义了如何分割和共享数据库，所以它们在扩展中也扮演着重要的角色。假设我们想在网站制作中实现根据订单确认服务对数据库进行纵向分割，那么如果订单实体与其它实体关系紧密，那么这种分割几乎是不可能的。在分割之后再试图理清这种关系就更加困难了。在网站设计阶段多花费点时间，那么在之后的数据库分割时就只需要花费原来的1/10甚至1/100的精力。
对于网站建设项目的扩展性来说，数据关系的最后一个关键点是在查询中如何连接表。当然，这不仅是由数据模型决定的，也是由在网站中创建报表和新页面的网站制作人员定义的。而且新的查询都应该由有经验的DBA审查，在把它们投入到生产环境之前，必须对数据查询性能，查询语句及语法做严格地审查，确保没有性能方面的问题。
在通过规范化提高数据完整性的愿望和在数据库中使用关系的程度之间是有密切联系的。采用的范式越高，在创建表时的关系就越多。而在网站设计数据库方面，几年前被当作原则使用的东西，现在在一些大型网站建设项目中进行设计时，都要进行权衡了。这种权衡与风险和成本，成本和质量，时间和成本等之间的权衡是相似的，也就是一方的下降通常会导致另一方的上升，是一个此消彼长的过程。通常，要提高网站的可扩展性，我们会适当牺牲数据库设计时采用的范式等级。
因为要连接表，所以SQL查询会耗时，可以采用下面几种方式解决。
- 首先对查询进行调优；
- 创建视图，物化视图，摘要表等，可以对连接进行预处理；
- 不要在查询中进行连接，而是把数据集读到应用层，在应用层内存进行连接，现在asp.net 2.0以后的版本已经加入了Linq语法，可以很好的支持内存中的join操作。虽然这种方法比较复杂，但在数据库中进行连接通常是最难扩展的，而在应用层进行连接的方法将连接移出了数据库，放在应用层服务器上，那么用更多的商业硬件进行负载均衡扩展会更容易实现；
- 最后一种方法要追溯到业务需求上，通常我们的业务合作伙伴会提出不同的解决方案，在解释时会说，现有的查询方法需要增加10%的硬件成本，而删除一行会减少查询的复杂度，而得到的业务价值基本是相同的。
最近了解了几家较大型的公司，发现大多数网站建设公司在网站制作时并没有太过于注重数据库的查询分析，至少在前期没有，也许是因为开发成本的考虑。但是最后了解到的事实是，当网站访问量上去后，这些深圳网站建设公司最后还是要花很高的成本去对数据模型做大修改以满足对网站进行负载扩展的需求，所以如何在当初多花点时间在数据库模型设计上，也许总的成本算下来可能还是“磨刀不误砍柴工”来得更划算一些。