引言：前文（数据库设计 Step by Step (8)——视图集成）讨论了如何把局部ER图集成为全局ER图。有了全局ER图后，我们就可以把ER图转化为关系数据库中的SQL表了。俯瞰整个数据库生命周期（如下图所示），找到我们的“坐标”。 把ER图转化为关系数据库中的表结构是一个非常自然的过程。许多ER建模工具除了辅助绘制ER图外，还能自动地把ER图转化为SQL表。   从E

一、数据库设计的必要性          在实际的软件项目中，如果系统中需要存储的数据量比较大，需要设计的表比较多，表与表之间的关系比较复杂，那我们就需要进行规范的数据库设置。如果不经过数据库的设计，我们构建的数据库不合理、不恰当，那么数据库的维护、运行效率会有很大的问题。这将直接影响到项目的运行性和可靠性。 二、什么

Sql Server数据库的主键设计有多种，比如经典的自增长，欢乐的guid，按照时间生成id（有通过程序生成的方式，还有一种也是通过数据库时间和随机数生成），按照业务模型组合生成有意义的id等等。最近项目中接触到一种模拟自增长自动编号主键的方式，即“Max加一”。 Max加一的原理看上去和自增长是相似的，表的唯一主键也设计成数字型(如bigint)的，只是把自动增长去掉了

引言：在前文（数据库设计Step by Step (7)——概念数据建模）最后的案例中，我们通过集成多个局部的实体关系（ER）模型最终得到了全局ER图。在现实项目中视图集成可能并不会那么容易。 俯瞰整个数据库生命周期（如下图所示）。在前面的内容中，我们已完成了“确定需求”和“数据模型”（图中以灰色标出），本小节我们将详细讨论“视图集成”（图中以红色标出） 把基于不同用户视角的局部ER图集成

引言：在前两篇博文（数据库设计 Step by Step (5)和数据库设计 Step by Step (6) —— 提取业务规则）中，我们进行了数据库需求分析，着重讨论了两个主题：1.理解用户需求；2.提取业务规则。当需求分析完成后，我们就要进入到概念数据建模环节。本篇文章将使用之前介绍过的“基本实体关系模型构件”和“高级实体关系模型构件”作为建模的基本元素，大家可以回顾数据库设计 Step b

1. 原始单据与实体之间的关系 　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对 应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实 体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计 录入界面大有好处。　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员

引言：数据库设计 Step by Step (4)中我们讨论了泛化关系、聚合关系、三元关系等高级实体关系模型构件及其语义。从本次讲座开始我将引领大家开始数据库设计之旅，我们将从需求分析开始，途中将经过概念数据建模、多视图集成、ER模型转化为SQL、范式化等过程，最终得到完整、可用的SQL表。 需求分析在数据库生命周期中至关重要，通常也是涉及人员最多的步骤。数据库设计师在这个阶段必须走访最终用户，

设计表和字段 1. 检查各种变化 我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，我倾向于在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。 — Shropshire Lad 2. 采用有意义的字段名 有一回我参加开发过一个项

一直以为实现一个类型Windows的任务计划的数据库设计（计划调度部分不考虑具体的任务步骤执行），最近认真的看了下每个配置才发现其实也不难，关键是搞清楚不管任务计划怎么个配置（按天，按周，按月），对任务调度进程来说只要知道当前时间点应该执行那些任务就好了，即任务调度进程发现某一任务的“下次执行时间”小于等于当前时间时，则执行之，并且将任务的上次执行时间更新为当前时间，并且根

引言：数据库设计 Step by Step (3)中我们讨论了基本实体关系模型构件及其语义。这些概念非常重要，是今天这一讲的基础，在开始本文内容之前建议大家可以再回顾一下上一篇的内容。今天我们将讨论高级实体关系模型构件，与上一篇一起涵盖了ER模型构图的大部分内容。三元关系是今天这一讲的难点，大家可以重点关注。   泛化（Generalization）：超类型与子类型 原始的ER

引言：数据库设计 Step by Step (2)在园子里发表之后，收到了一些邮件，还有朋友直接电话我询问为什么不包含数据库物理设计方面的内容。我在这里解释一下，数据库物理设计与数据库产品是密切相关的，本系列的专注点是较为通用的数据库设计理念与方法，这也是国内软件项目中容易被忽视的一块。今天我们将学习实体关系（ER）模型构件及其语义，这是数据库逻辑设计的基础。内容可能有些枯燥，但却非常重要和有用。

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 在实际开发中最为常见的设计范式有三个： 1．第一范式 第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 第一范式的合理遵循需要根据系统的实际需求来定。

经过两天对于实现应用程序接触结构跨数据库系统的修改，在设计数据库过程中，建议重视两个字段类型，一个是GUID类型，一个是DATETIME（TIMESTAMP）类型。 1.在需要数据库分发和数据库复制的架构中，为了保证数据的一致性，我们经常使用GUID字段类型，但GUID类型只存在于SQL Server数据库对象中，在Oracle中没有此数据类型，需要向RAW或CHAR进行转换。 2.对于需要保证数

引言：一直在从事数据库开发和设计工作，也看了一些书籍，算是略有心得。很久之前就想针对关系数据库设计进行整理、总结，但因为种种原因迟迟没有动手，主要还是惰性使然。今天也算是痛下决心开始这项卓绝又令我兴奋的工作。这将是一个系列的文章，我将以讲座式的口吻展开讨论（个人偷懒，这里的总结直接拿去公司培训新人用）。   系列的第一讲我们先来回答下面几个问题 数据库是大楼的根基 大多数程序

要开发用户管理系统,我们首先要了解需求,现在就举一个简单需求,用户表,假设有两种角色用一个字段departID来判断,管理员和员工, 我们要先建一个用户表custom和一个部门表department: CREATE TABLE [dbo].[custom]( [id] [int] IDENTITY(1,1) NOT NULL, [cname] [nvarchar](50) COLLATE

前篇回顾 从租车信息系统数据库设计（1）至租车信息系统数据库设计（4）我们完成了一个简单的租车信息系统的数据库设计。 从功能上来讲还有很多可以扩展的方面，如权限管理、发票管理等等，本文不将展开。大家可以对这些需求进行设想，设计相应的表、字段和关联，并融合到整体设计中。 本篇是本系列的最后一篇，我们将利用先前设计的数据库结构来写一些查询，完成一些业务需求，同时也反过来审视先前的设计。 获取需要催促还车的订单 我们的业务人员每天都要获取超出预订期限未还车的订单。对于这些订单，业务人员需要一一电话客户。 那就让我们来帮助业务人员写这个查询吧！ select RentalOrder.Order_ID from Table_Order RentalOrder where RentalOrder.Order_BookEndDate < GETDATE() and Orde