数据库设计

一,概述

驱动网站的数据库中,相对于对象-关系型、面向对象型数据库来说,关系数据库以其高可用性、高性能和易用性等优势而最为流行。对于大多数稍具规模的网站来说,数据库表是运作的生命中枢。用户帐户、新闻动态、内容、统计数据都保存到关系数据库管理系统(Relational Database Management System,RDBMS)。

建立数据信息模型(Data Model,建模,运用一般业务知识的可视化图形设计来表现业务需求)可提供企业整体信息共享,以图形提供专业化业务规则与需求,作为技术人员与企业人员的桥梁,建立一致性,建立一种静态数据模型。

最优秀的关系数据库的设计方法被称为IDEF1X(I cam DEFinition method 1 eXtended),它采用用实体关系图(Entity Relationship Diagram,ERD),建立实体-关系模型(ER模型)能预先精确定义数据需求,为维护与改动进行持续发展的有效规划。其中,IDEF1X建模语言获得广泛应用。

高端数据建模工具的有 Sybase PowerDesigner/ERWin;高端UML工具加上恰如其分的数据库建模支持有:Rational Rose Enterprise;中低端的数据建模工具有MS Visio/Dezign/Case Studio等。

二,建模

1,逻辑模型(Logical Model)一种结构性呈现且独立于DBMS的表示业务信息及业务行为规范的语言

物理数据模型(Physical Data Model)依赖于DBMS并利用SQL下的DDL方法来设计与实施的描述数据结构,设计及实施的一种规格。

2,实体(ENTITY):人,地点,物,事件以及任何包含业务活动数据的概念。每个实体由一组相似却有别(必须能单独标识)的实例(INSTANCES)组成。命名要有业务意义(用实体描述和业务例子有助理解业务意义)

分为独立实体和非独立实体(依赖实体)

3,属性(ATTRIBUTE):用来分辨或说明实体的性质与特征。一般采用描述和注释来定义属性,还可采用业务实例(可助于理解域,Domain,可以被看作是允许属性接受的一组抽象/有企业意义的值)

分为键属性和非键属性

候选键(Candidate Keys)任何一个属性或一组属性其可用来唯一认定实体中的每个实例)

主键(主关键字,Primary Key,PK)所有候选键中被指定为最优先或最常用来唯一标识每个实例的某个属性或一组属性

替代键(Alternate Key)除PK外的所有候选键,以(AKn)表示。假如换用键本身包含好几个属性,每个属性后面均需加(AKn)

(Inversion Entries)利用其余属性来查找其所需的实体实例但其结果并不具唯一性,以 (IEn)表示。假如换用键本身包含好几个属性,每个属性后面均需加(IEn)

4,关系:

可通过三重判断来判断关系类型。

1,一对多/多对多

2,特定/非特定

3,继承/非继承

外键(FOREIGN KEY,FK)父实体的PK通过“关系”加入到子实体中作为PK。

标识关系Identifying Relationship实体主键迁移给子实体作为部分主键(PK),子实体须由父实体决定,其存在亦需依附父实体。

强制关系Non-Identifying Mandatory Relationship实体主键迁移给子实体作为非键属性(非PK),其表示不由父实体来决定。子实体为何子实体不须由父实体决定,但其存在仍需依附父实体 (mandatory)

非标识关系Non-Identifying Non-Mandatory Relationship实体 PK 迁移到子实体当作非主键且与子实体为非标识行( Non-Identifying )实体与父实体间的标识为独立存在性,实体信息本身不需完全依赖父实体

Many-to-Many Relationship一种不确定关系,主键并不迁移给它实体做为外来键,必须有两种动词(片语),两种关系:父对子/子对父关系

5,模型读法:保证读模型给出有效的语句,把模型读回到业务,虽然不能精确地描述规则,却能给人初步直观的了解,是验证所获取的业务规则正确性的主要方法之一。

使用正确的动词短语从父实体到子实体来读关系

A PLANE-FLIGHT <transports> many PASSENGERs

一个[飞机航班]<运输>多名[乘客]

A CUSTOMER <borrows under> many MOVIE-RENTAL-RECORDs

一个[用户]<通过>众多的[影碟租借记录]<进行租借>

A PERSON <may have> many HOBBYs.

一个[人]<也许有>许多[嗜好]

也可以从子实体读起,用”被动动词”短语表达

A MOVIE-RENTAL-AGREEMENT <records borrowing by> a CUSTOMER.

一个[影碟租借记录]记载了<被>一个用户<租借影碟>的情况

A HOBBY <may be had by> a PERSON.

一个[嗜好]可能<被>一个[人]<拥有>。

多对多的关系比较难读。

A PERSON <has the use of an ADDRESS recorded as> one or more ADDRESS-USAGEs.

An ADDRESS <has its use by a PERSON recorded as> one or more ADDRESS-USAGEs.

有人采用比较易读的模糊读法:

An ADDRESS <is used by> one or more PERSONs

A PERSON <may use> one or more ADDRESSs

参考资料

简洁、明晰!数据库设计三大范式应用实例剖析|

SQL Server数据库设计表和字段的经验|

数据库设计和数据库重构--小小心得|

ORM漫谈

数据建模工具/ER图工具列表

中小型项目的权限管理的数据关系图

数据库表设计模板

利用ERD规范化生成数据库表结构

用实体关系图进行数据库建模

数据库设计方法、规范与技巧

数据库设计中的敏捷方法

数据建模工具与BPM日趋融合