一、引述
在数据表设计过程中一个表的表单字段项的常用设计为：主键+属性信息（若干）+外键。
关于主键和外键的关系可以做这样的联想：主键作为实现子对象（记录）的标识 ID，而外键作为作为父对象（记录）的标识ID.
这样外键代表的记录对象可主键标识的记录对象和可以看作对象实例层面的父子继承关系，两个表单作为更高抽象一层类层面的继承关系。
于是我们可以用面向对象的类设计思想来结构化数据关系， 不同的层次记录对象有隶属于其自身的属性信息 而其子对象实例可以继承其父实例信息。
二、设计思路与目标
在分析某健身中心旧数据库表结构的过程中结合新的的数据库表，分析各自的优缺点过程中，
在数据库结构的设计上我似乎找到了一种思路或者说是方法：
1. 能够有助于软件系统的可扩展性设计
2. 在结合面象对象的程序设计思路，和数据库关系表设计之间找到了一个结合点，就是如何把面向对象的类层次设计(继承和包含)映射到数据库关系表
当中，即利用表之间的关联完全可以实现对象实体之间的隶属（is-a）、继承(has-a)、使用(use)等关系。
3. 这样一来数据存储结构层次划分就很清楚了，整个系统当然构架和数据结构也就很明了了。 接下来更具体的 我还得继续研究 ，有时间和你说说 :-)
三、设计实例
数据库设计感悟(概念结构和逻辑结构设计)：（某健身中心会员卡以及收费管理系统）
1. 数据库保存的数据类型总体上分为两类：1) 系统初始配置数据 （例如健身中心系统中的卡类型，运动项目等数据信息）
2) 系统运行生成的业务数据（例如健 身中心系统中的会员信息，销售记录等数据信息）
2. 其中配置数据的结构设计直接决定了整个信息系统的框架是否合理、科学。系统的构架清晰性、可维护性、可扩展性、运行正确性、和数据一致性保证
都直接受其影响。(在做用户分析时要落实一些程序计算中要用到的配置参数是否存在变的可能，并在系统分析与设计是做好相关的可配置性设计) 原则
上系统的配置参数是不允许随意改动的。
3. 面向对象程序设计和关系数据库设计之间的映射和交互实现
关于数据抽象的几个重要的概念：
面向对象程序设计几个概念：
(1) 抽象分类
(2) 组合包含<has--a>
(3) 继承隶属<is--a>
(4) 关联<relation>
关系数据库概念结构设计：
(1) 分类<Classification>
a 定义某一类概念作为现实世界中的一组对象的类型。这些对象具有“某些”共同的特性和行为。它抽象了“对象值”和型之间的“is member of”的语义。
b 在数据库设计的E_R图中，“实体型”就是这种抽象。
c 数据库设计中的实体型和实体的概念相当于程序设计中的类和对象；
d举例：
===================================================================
数据库实体型：
会员卡〈[ ID ],会员卡名,面值，面次，折扣，有效期限，检票时限〉
实体(转化为二维表关系数据模型)：
[0，金卡，1980, … ]
[3，游泳次卡，360，… ]
[5，健身年卡，480，… ]
…
=====================================================================
程序实现：
类定义：
Class/Struct 会员卡：{
[ ID ] // ID 对应this(self)
CardTypeName; // 名称
CardValue; // 面值
CardTimes; // ...
Discount; // ...
DateLimit; // ...
CheckTime; // ...
}
================================================================================
实例(对象)：
ObjGold( 对象名ObjectName) // 金卡
{
[this=0]； //对象标识，隐指自己
金卡；
1980；
…
}
ObjSwim // 游泳卡
{
[this=3];
游泳次卡；
360
…
}
ObjSport // 健身卡
{
[this=5];
健身年卡；
480；
…
}
... …
======================================================================
说明：
数据库实体型会员卡转换为关系模型二维数据表后的一条记录相当于程序类会员卡的的一个实例(对象)。为了区分一个个不同的实例(对象)，应在二维
数据表中设值一“主键”以唯一表识此实例(实体/对象)，在此，在数据库表中设置了一“ ID”字段来标识每一个实体，根据语义和用户约束的需要可再设
其他字段的属性约束，比如：“会员卡名”应为唯一不能重命。
E_R图向关系模型的转换：
一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
此外在关系数据库当中对于实体间的一个联系也可转换为一个独立的关系模式。这个在面向对象的程序设计中没有显式的出现类似的类对象实例？？(待
查)。
e **自注**：抽象具有层次性，即在一次抽象的基础上可以进行第二次抽象归类。
(2)聚集<Aggregation>
a 定义某一类型的组成成分。它抽象了对象内部类型
和成分之间“is part of”的语义；
b 在数据库设计的 E_R图中若干属性的聚集组成了
实体型，就是这种抽象。
c 数据库设计中的实体型和属性的概念相当于与程
序设计中类和数据成员(或对象成员)；
(我的观点：在合并联系的关系模式时 便产生了这样的聚集)
d举例：
.......
e**自注** 聚集具有嵌套性，即属性或数据成员可能
仍是某中类型的类对象或聚集实体；
(3)概括<Generalization>
a定义类型之间的一种子集联系。它抽象了类型之间的“is subset
of”的语义。
b扩充的的E_R模型允许定义超类实体型和子类实型
c数据库设计中的超类实体型和子类实型的概念相当于程序设计
中父类和子类(基类/超类和子类)
d举例：
基类实体型：储值卡
实体：通用卡，年卡，次卡
子类实体型：通用卡，年卡，次卡
实体：通用卡实体：[金卡]，[银卡]，[会员卡]
年卡实体：[游泳年卡]，[健身年卡]，[游泳健身年]…
次卡实体：[游泳次卡]，[健身次卡]，[乒乓球次卡]…
讨论：
储值卡<类型ID，类型名称，面值，押金，有效期,>
通用卡<>
e **自注**概括有一个很重要的性质“继承性”。子类继承超类上定
义的所有抽象。(当然子类可以增加自己的某些属性)
(4)关联
实体间静态关系和动态关系的说明(我的观点)：
实体间的关系有聚集，概括等静态关联也有由实体间的某种相互作用而产生的动态关联，而这种动态的关系一般转换为一个独立的关系模式而不与某
一端合并。此即为刚开始提到的：系统运行生成的业务数据
对象间静态关系和动态关系的说明：
包含关系，继承关系均为静态的关联，而由消息触发的对象之间的接口调用和服务为动态关联
(5)相关的说明
a 有关数据库设计的一些知识
数据库设计是信息系统开发和建设中的核心技术，具体的说，数据库设计是指对于一个给定的应用环境，构造最优的数据库模型，建立数据库以及其应用系统，使之能够有效的存储数据，满足各种用户的需求(信息要求和处理要求)。
大型数据库的设计和开发上一一项庞大的工程，是涉及多学科的综合性技术。主要有：
·数据库的基本知识和数据库设计技术；
·计算机上科学的基础知识和程序设计的方法和技巧；
·软件工程的原理和方法；
·应用领域的知识；
数据库设计的特点：
1“三分技术，七分管理，十二分基础数据”是数据库建设的基本规律。
2．数据库设计应该和应用系统设计相结合，即，整个数据库过程中要把结构(数据)设计和行为设计密切结合起来。
数据模型概述：
模型是现实世界特征的模拟和抽象，数据模型是现实世界数据特征的抽象。现有的数据库系统均是基于某种数据模型的。
数据模型的层次分类：
第一类：是概念模型，也称信息模型，是按用户观点来对数据和信息建模，主要用于数据库设计。
第二类：数据模型，主要包括网状模型，层次模型和关系模型，是按计算机系统的观点对数据建模，主要用于DBMS的实现。
数据操作／数据的约束条件
概念模型：用于信息世界的建立模，是现实世界到信息世界的第一层抽象，是数据库设计人员进行数据库设计的有力工具，也是数据库设计人员和用户之间进行交流的语言，所以概念模型一方面应该具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识，另一方面它还应该简单、清晰、易于用户理解。
信息世界的基本概念：
１) 实体(Entity)
客观存在并相互区别的事物成为实体。可以是具体的人、事、物，也可以是抽象的概念或联系。
２) 属性(Attribute)
实体所具有的某一特性。一个实体可由若干个属性来刻画。
３) 码(Key)
唯一标识实体的属性称为码。
数据库设计方法简述：
由于信息结构复杂，应用环境多样，在相当长的一段时
间内数据库设计主要采用手工试凑法。
规范设计中比较著名的有新奥尔良(New Orleans)方法.j将数据库设计分为四个阶段：需求分析(分析用户要求)、概念设计(信息分析和定义)、逻辑设计(设计实现)和物理设计(物理数据库设计)。 其他的一些辅助设计手段：基于E_R模型的数据库设计方法；基于3NF(第三范式)的设计方法；基于抽象语法规范的设计方法等。
规范设计方法从本质上看仍然是手工设计方法，其基本的 是过程迭代和逐步求精。
数据库设计基本步骤：
系统分析和数据库设计人员是数据库设计的核心人员。
1) 需求分析阶段
进行数据库设计首先必须准确了解与分析用户需求(包括数据与处理)。需求分析是整个设计过程的基础，是最困难、最耗时间的一步。作为地基的需求分析是否做的充分与准确，决定了在其上构建数据库大厦的速度与质量。需求分析做的不，甚至会导致整个数据库设计返工重做。
2) 概念结构设计阶段
概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
3) 逻辑结构设计阶段
逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。
4) 数据库物理设计阶段
数据库物理设计是为逻辑设计模型选取一个最合适应用环境的物理结构(包括存储结构和存取方法)
5) 数据库实施阶段
设计人员运用DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行
6) 数据库运行和维护阶段
最后，设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述六个过程中必须不断地对其进行评价、调整与修改。这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。在设计中应该把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两方面的需求分析，抽象，设计，实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。
数据库的各级模式图：
E_R图向关系模型的转换：
E_R图向关系模型的转换要解决的问题是如何将实体和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码
关系模型的逻辑结构一组关系模式的集合。E_R图是由实体，属性，和实体之间的联系三个要素组成的。所以将E_R图转换关系模型实际上就是要将实、实体的属性和实体之间的联系转换为关系模式，这种转换一般遵循如下原则：
(1) 一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
对于实体间的联系有以下不同的情况：
(2) 一个1:1的联系可以转换为一个独立的关系模式，也可以与任意一端的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的侯选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一关系模式的码和联系本身的属性。(可以理解。选择以具体需求而定)
(3) 一个1:n 的联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各个实体的码以及联系本身的属性均转换为关系的属性，而关系的吗为n端实体的码。(可以理解。选择以具体需求而定)
(4) 一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各个实体码的组合。( 可以理解)
(5) 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
(6) 具有相同码的关系模式可合并。
数据模型的优化：数据库逻辑设计的结果不是唯一的。需要对其进行优化调整，关系数据模型的优化通常以规范化理论为指导，方法为：
1) 确定数据依赖。
2) 对于各个关系模式的之间的数据依赖进行极小化处理，消除冗余的联系。
// 需求计划 ///////////////////////////////////////////////////////////////////////
一， 用户需求分析
假设前提：已经掌握用户的需求要求，应用需求和设计已经明了。下一步直接进入数据库系统分析和设计阶段。(针对系统最核心的系统配置，项目销售，卡业务和统计报表部分)
1． 用户业务需求分析
2． 数据的存取和处理要求分析
二， 概念结构设计
1. 用例分析
a 现场实际考察；(***考察：场地、项目设置等)
b 与业务人员，系统操作人员，和相关管理人员交流。(****，前台操作员) (特殊的需要跟班作业)
c 目的：熟悉业务流程和相关的行业用语，了解实际的业务需求，要解决什么问题，实际业务中有那些约束条件。()
d 对掌握的材料和信息做整理。得出不清楚和不明白的疑问。
e 写出一份有计划和有目的的需求调研表，做二次考察。并澄清相关疑问。
f 再总结材料。对整体业务流程有把握。同时对整个项目应有整体的目标和认识
g 可电话咨询分析过程中的一些疑问。
h 写出一份较详尽和完整的用户需求说明书，程交用户方审阅
i 得到反馈，再与用户方相关人员交流修改需求说明书
g 审阅通过 做下一步的分析与设计 否则迭代返回。
2. 应用需求
用例分析的基础上得到具体的应用需求
针对于数据库的各个应用要求：
运动项目信息的：添加、删除、修改
项目场地的：添加、删除、修改
会员卡类型信息的：添加、删除、修改
会员卡的：注册、充值、挂失、过户、注销
系统用户：添加、删除、修改及权限控制
统计查询：
场地预定：
3．概念设计&逻辑设计
提取实体，画E_R关系图
实体型：运动项目 可扩充(修改)
项目场地 可扩充(修改)
储值卡类型 可扩充(修改)
会员卡 可扩充(修改)
会员 可扩充(修改)
会员卡状态 可扩充(修改)
系统用户 可扩充(修改)
附件 可扩充(修改)
价格策略 可扩充(修改)
项目时间场地限制方式 可扩充(修改)
消费方式 可扩充(修改)
/*(我的观点)当某个属性具有可扩充性需要时要做到程序可配置就应作为一实体。在分析阶段为了更清楚全面的实现系统目标应尽可能采用更多的实体，以及实体间联系，最后在设计时可以合并化减*/(在业务应用模式分析时确定是否做可配置性设计);根据需要决定某些属性是放在超类中还是子类中，或者外键实体的某些属性是否也作为本实体一部分。(适当的数据冗余是非常必要的也是必需的)
诸如：会员卡状态、项目时间场地限制方式等这些有应用需求得来的相对比较固定的一些属性参数也做为一实体对应一配置表有利于改善系统的可扩充性和可维护性，一般其作为其他实体属性项，不设置独立的关系模式，而是合并掉。
另外在应用程序当中用到的一些常量参数也可用数据库管理作为可配置的 (当然也可采用文件保存配置方式);
用代数结构表达式A<a,b,c…>来替代E_R图表示：
实体型：
运动项目<项目编号，项目名称，状态标志，备注>
项目场地<场地编号，场地名称，状态，备注>
项目时间场地限制方式<方式编号，方式名称，备注>
价格策略<价格编号，定价名目，价格数目，备注>
储值卡类型<卡类型编号，类型名称，备注>
会员卡<会员卡编号，会员卡名称，有效期，面值，面次，检票时间，折扣，(消费项目)，状态标志，备注>
会员卡状态<卡状态编号，状态名目，备注>
会员<会员卡号，会员姓名，性别，身份证号，联系电话，(卡类型编号)，(卡状态编号),备注>
实体间联系
a [运动项目] 1----------n [价格策略]；
b [运动项目] 1----------1 [项目时间场地限制方式]
c [运动项目] 1----------n [项目场地]
d [储值卡类型] m----------n [会员卡]
联系也作为一个实体型出现，可以有其自己的属性。
各个实体转换为关系模式：
用代数结构表达式A[a,b,c…]来替代关系模式：
运动项目[项目编号，项目名称]
项目场地[场地编号，场地名称]
项目时间场地限制方式[方式编号，方式名称]
价格策略[价格编号，定价名目，价格数目]
实体间的联系转换为关系模式：
a：联系a[ ID，项目编号，价格编号，[联系a的属性] ] (n端的“价格编号”为该关系的码)
b：联系b[ ID，项目编号，方式编号，[联系b的属性] ] (“项目编号”,”方式编号”均为该关系的码)
c：联系c[ID,项目编号，场地编号，[联系c的属性] ] (n端的“场地编号”为该关系的码)
分析是否合并、如何合并联系的关系模式。(合并的方法和策略见上文)
==========/ 写于 2007.3 / ======================================================