UML类图-关系数据库之间的映射
基于UML模型的关系数据库设计
UML类图到关系表的映射策略及其应用
这 二 者描 述 的是 部 分 与 整 体 的 关 系 。 聚 集 关 系 如 果 是 紧 密 的 。 以考虑映射成一张表 ， 果是 松散的 ． 可 如 可参 考 １ 多 的 关 对
联， 映射 为 ２张 表 ， ” ” （ 分 类 ） 置 外 键 ． 用 ｎ ” （ 在 多 方 部 设 引 １方 整 Ｕ ＭＬ 中 的类 图主 要 由类 及 其 关 系组 成 ． 而类 之 间 的关 系 又 体类 ） 键 。 主 可 以细 分 为 关 联 、 化 、 集 、 成 、 赖 、 现 等 多 种 。 中 前 四 泛 聚 组 依 实 其 组 成 的映 射 与 聚集 相 似 ．但 部 分 类 对 应 的 子 表 中 的外 键 必 种 关 系 的定 义 如 下 ： 须 是 强制 非 空 的 。 （ 关 联 ： 示 类 的实 例之 问存 在 的某 种 关 系 。 它 通 常 可 以 ３ 应 用 实 例 １ ） 表 ． 有 １对 １、１ 多和 多对 多 等 情 形 。 对 下 面 尝 试 将 上 述策 略 运 用 到 一 个 小 区 业 主 论 坛 系统 中 （ 泛 化 ：在 Ｕ ２ ） ＭＬ类 图 中 ，如 果 类 型 Ｂ 的接 口包 括 类 型 Ａ １ ．业 务 需求 简述
维普资讯
２０ ０ ７年第 ８ 期 福建 电脑
１５ ０
Ｕ ＭＬ类图到关 系表 的映射 策略及其应用
徐 婉 珍
ｆ 海 东软 信 息 技 术 职 业 学 院 广 东 佛 山 ５ ８ ０ ） 南 ２２０
【 摘
要 】 随着面 向对 象技 术的发展及应 用的 １益 复杂化 ， Ｍ ： ３ Ｕ Ｌ已成为应用 开发 的流行 建模工具 ， 并将取代 关 系数据 表 映射
的 接 口中 的 每 个 元 素 ， 类 Ａ 与 类 Ｂ之 问构 成 泛 化 关 系 。且 称 则 某 小 区业 主 论 坛 ： 一 个 功 能 较 简单 的论 坛 ． 要 满 足 小 区 是 主 类 型 Ｂ为 子 类 型 ， 型 Ａ 为超 类 型 。泛 化 是 继 承 的 逆运 算 ， 以 业 主 之 问 的交 流 ， 类 所 分设 有几 个 版 块 ， 版 块 版 主 由论 坛 管 理 员 从 各 泛 化关 系通 常 可 以用 继 承 关 系实 现 。 注 册 用 户 中选 取任 命 。 册 用 户 可 自由 发贴 、 改 、 注 修 回贴 ， 不 能 但 （ 聚 集 ： 个 类 由几 个 部 分类 组 成 ， 种 关 系 被 称 为 聚 集 ， 删 除 帖子 ， 贴 可 累 积 积 分 ； 主 除 具 有 普 通 用 户 的 功 能 外 ． ３ ） 一 这 发 版 还 它 体现 部 分 与 整 体 的 关 系 有 删 贴 ， 移 帖 子 去 其 它版 块 的功 能 。 转 （） 成 ： 成 是 强 类 型 的 聚 集 ， 表 示 聚 集 中 的 每 个 部 分 ４组 组 它 分 析 其 中 的主 要 关 系后 ， 到 如 图 １ 示 的 Ｕ 得 所 ＭＬ类 图 。为
UML类图及类与类之间的关系
UML类图及类与类之间的关系原⽂地址：类图⽤于描述系统中所包含的类以及它们之间的相互关系，帮助⼈们简化对系统的理解，它是系统分析和设计阶段的重要产物，也是系统编码和测试的重要模型依据。
1. 类类(Class)封装了数据和⾏为，是⾯向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。
在系统中，每个类都具有⼀定的职责，职责指的是类要完成什么样的功能，要承担什么样的义务。
⼀个类可以有多种职责，设计得好的类⼀般只有⼀种职责。
在定义类的时候，将类的职责分解成为类的属性和操作（即⽅法）。
类的属性即类的数据职责，类的操作即类的⾏为职责。
设计类是⾯向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。
在软件系统运⾏时，类将被实例化成对象(Object)，对象对应于某个具体的事物，是类的实例(Instance)。
类图(Class Diagram)使⽤出现在系统中的不同类来描述系统的静态结构，它⽤来描述不同的类以及它们之间的关系。
在系统分析与设计阶段，类通常可以分为三种，分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class)，下⾯对这三种类加以简要说明：(1) 实体类：实体类对应系统需求中的每个实体，它们通常需要保存在永久存储体中，⼀般使⽤数据库表或⽂件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。
实体类来源于需求说明中的名词，如学⽣、商品等。
(2) 控制类：控制类⽤于体现应⽤程序的执⾏逻辑，提供相应的业务操作，将控制类抽象出来可以降低界⾯和数据库之间的耦合度。
控制类⼀般是由动宾结构的短语（动词+名词）转化来的名词，如增加商品对应有⼀个商品增加类，注册对应有⼀个⽤户注册类等(3) 边界类：边界类⽤于对外部⽤户与系统之间的交互对象进⾏抽象，主要包括界⾯类，如对话框、窗⼝、菜单等。
在⾯向对象分析和设计的初级阶段，通常⾸先识别出实体类，绘制初始类图，此时的类图也可称为领域模型，包括实体类及其它们之间的相互关系。
软件工程之系统建模篇【设计数据模型】
软件⼯程之系统建模篇【设计数据模型】数据模型描述系统持久性数据库层的逻辑内容与结构，数据模型⽤UML的类图描述。
⾸先简要介绍数据模型的设计⽅法及关系数据库的⼏个术语，然后依次介绍如何将类映射到表、将关联映射到关系数据库及将泛化映射到数据库。
数据库模型从层次上可以分为3类：概念数据模型、逻辑数据模型和物理数据模型。
概念数据模型是⾯向⽤户、⾯向现实世界的数据模型，与数据库管理系统⽆关，逻辑数据模型反映了DBMS的存储结构，是⽤户从数据库看到的数据模型，物理数据模型是特定的DBMS，定义实际中的数据如何存储在持久存储设备上。
本章要设计的数据模型是逻辑数据模型，⽤⾯向对象⽅法设计数据模型于⽤传统⽅法设计数据模型差别不⼤。
设计步骤为： 1、设计UML中的实体与ER图中的实体 2、设计UML实体类图与E-R图 3、建模依据 4、选择数据库系统 持久性数据库层可以是关系型的数据库，也可以是对象关系型的数据库或者对象数据库。
从关系型数据库技术到对象数据库技术是⼀个演化过程，对象数据库技术是这个演化过程的中间阶段，尽管未来将属于对象数据库，但关系型数据库在⽬前的数据库软件市场中仍占主流，本章为系统实例选择关系型数据库作为持久性数据库层的数据库管理系统。
对于关系数据库来说，可以⽤类图描述数据库模式，⽤类描述数据表，⽤类的操作描述触发器和存储过程。
1、将类映射到表 将实体类映射为关系数据表，必须遵循表的第⼀范式，列必须是不可再分的数据项，从类到表的映射可以是⼀对⼀，即⼀个类映射为⼀个表，但是，⼀对⼀映射可能会导致⼀些问题，如表太多，表丢失，以及对泛化关系处理不合理等，在设计中要灵活调整。
2、将关系映射到关系数据库 类之间的多重性可以分为⼀对⼀，⼀对多和多对多3种情况，对3种多重性的处理已经有⼀些⼀般的转换规则，数据模型的设计⽤UML符号构造型和其他扩展机制类模拟，关系表的UML符号⽤构造型为《relational table》的类符号表⽰，关系表的列⽤类中的属性表⽰，带有构造型《pk》的属性代表主键，带有构造型《fk》的属性代表外键，不能接受空值的列⽤约束“｛not null｝”类表⽰。
UML中的类图和数据库设计的关联性探究
UML中的类图和数据库设计的关联性探究在软件开发过程中，UML（Unified Modeling Language）是一种常用的建模语言，用于描述软件系统的结构和行为。
其中，类图是UML中最常用的图表之一，用于表示系统中的类、属性和方法之间的关系。
而数据库设计则是软件开发过程中的另一个重要环节，涉及到数据的存储和管理。
本文将探讨UML中的类图与数据库设计之间的关联性。
首先，UML中的类图可以直接映射到数据库设计中的表结构。
在类图中，每个类代表了一个实体，而每个属性则代表了实体的属性。
同样地，在数据库设计中，每个表代表了一个实体，而每个字段则代表了实体的属性。
因此，可以通过对类图的分析和设计，直接生成数据库的表结构，从而实现类与表之间的一一对应关系。
其次，UML中的类图可以帮助设计数据库的关系模式。
在类图中，类与类之间的关系可以通过关联、聚合、组合等方式进行表示。
这些关系在数据库设计中可以转化为表与表之间的关系。
例如，一个类图中的关联关系可以转化为数据库中的外键关系，用于表示两个表之间的关联。
而聚合和组合关系则可以转化为数据库中的表之间的关系，用于表示表之间的层次结构。
通过类图的设计，可以更好地理清系统中各个实体之间的关系，从而指导数据库的关系模式设计。
此外，UML中的类图还可以指导数据库的索引设计。
在类图中，类的属性可以分为主属性和外部属性。
主属性通常用于唯一标识一个实体，而外部属性则用于描述实体的特征。
同样地，在数据库设计中，主键可以用于唯一标识一个表中的记录，而外键则用于建立表与表之间的关系。
通过对类图的分析，可以确定哪些属性应该成为主键，哪些属性应该成为外键，从而指导数据库的索引设计，提高数据库的查询效率。
最后，UML中的类图还可以与数据库设计工具进行集成。
目前市面上有许多专业的数据库设计工具，如ERwin、PowerDesigner等。
这些工具可以根据UML中的类图自动生成数据库的表结构，简化了数据库设计的过程。
数据库设计中的数据模型与UML图解方法(十)
数据库设计中的数据模型与UML图解方法引言在今天的信息化社会中，数据成为了企业运作的重要资产。
为了有效管理和利用数据，数据库设计成为了关键环节。
而数据模型和UML 图解方法则是数据库设计中常用的工具。
本文将探讨数据模型和UML 图解方法在数据库设计中的应用。
数据模型介绍数据模型是数据库设计的重要组成部分，它描述了数据之间的关系和约束。
常用的数据模型有层次模型、网状模型和关系模型等。
层次模型是最早的数据库模型之一，它将数据组织成树状结构。
树的每个节点代表一个实体，节点之间通过父子关系连接。
网状模型是层次模型的扩展，它允许一个节点拥有多个父节点。
节点之间的关系使用连接线表示。
关系模型是最为常用的数据库模型，它将数据组织成二维表格。
表格的每一行代表一个记录，每一列代表一个属性。
记录之间通过键值来建立关系。
UML图解方法介绍UML（Unified Modeling Language）是一种用于软件开发的通用标准。
它提供了一套丰富的图形符号和规则，用于描述系统的结构、行为和交互。
在数据库设计中，UML图解方法可用于建立数据库的逻辑模型和物理模型。
逻辑模型使用类图来描述实体（表）之间的关系。
类图由实体类、属性和关系等组成。
每个实体类表示数据库中的一个表，属性表示表的字段，关系表示表与表之间的关联。
物理模型使用部署图和组件图描述数据库的部署和组件关系。
部署图展示了数据库和服务器之间的物理连接，而组件图则展示了数据库中各个组件之间的依赖关系。
数据模型与UML图解方法在数据库设计中的应用数据模型和UML图解方法在数据库设计中起到了关键的作用。
它们可以帮助开发人员理解需求、分析问题和设计方案。
首先，数据模型可以帮助开发人员准确地理解系统的业务逻辑。
通过数据模型，开发人员可以清晰地了解各个实体之间的联系和属性，从而更好地设计数据库结构。
其次，UML图解方法可以提供更加直观的展示和交流方式。
通过使用图形符号，开发人员可以将复杂的数据库结构转化为易于理解和沟通的图形模型。
UML类图详解_关联关系_多对多
UML类图详解_关联关系_多对多在关联关系中，很多情况下我们的多重性并不是多对⼀或者⼀对多的，⽽是多对多的。
不过因为我们要考虑⾥⾯的导航性，如果直接搞的话就是需要去维护两群对象之间多对多的互指链接，这就⼗分繁杂且易错。
那么我们怎么办呢？可以将多对多的多重性尝试拆解为两组⼀对多的设计。
我们可以改为上图的这种拆解⽅法。
就是说在账户与基⾦之间多搞⼀个申购交易，这样就可以化解多对多的复杂度。
⼀个账户底下可以记录多笔申购交易，⽽每⼀个申购交易将指定某⼀档基⾦。
虽然可以重复申购同⼀档基⾦，不过每⼀个申购交易只能设定⼀档基⾦。
⼀个账户对象可以链接多个申购交易对象，⽽每个申购交易对象只能链接到⼀个基⾦对象。
下⾯我们来看⼀个“多对多”的例⼦Account.h1 #include <cstdlib>2 #include <vector>3 #include "Bid.h"4using namespace std;56class Account7 {8public:9void setBid(Bid*);10int calcAsset();11private:12 vector<Bid*> bidObj;13 };Account.cpp1 #include "Account.h"23void Account::setBid(Bid *theBid)4 {5 bidObj.push_back(theBid);6 }78int Account::calcAsset()9 {10int size,theAsset=0;11 size=bidObj.size();12for(int i=0;i<size;i++)13 theAsset=theAsset+bidObj[i]->calcAsset();14return theAsset;15 }Bid.h1 #include "Fund.h"23class Bid4 {5public:6 Bid(float);7void setFund(Fund*);8int calcAsset();9float getUnit();10private:11float unit;12 Fund *fundObj;13 };Bid.cpp1 #include "Bid.h"23 Bid::Bid(float theUnit)4 {5 unit=theUnit;6 }78void Bid::setFund(Fund *theFund)9 {10 fundObj=theFund;11 }1213int Bid::calcAsset()14 {15return unit*fundObj->getPrice();16 }1718float Bid::getUnit()19 {20return unit;21 }Fund.h1class Fund2 {3public:4 Fund(float);5float getPrice();6private:7float price;8 };Fund.cpp1 #include "Fund.h"23 Fund::Fund(float thePrice)4 {5 price=thePrice;6 }78float Fund::getPrice()9 {10return price;11 }main.cpp1 #include <cstdlib>2 #include <iostream>3 #include "Bid.h"4 #include "Account.h"5 #include "Fund.h"6using namespace std;78int main(int argc, char *argv[])9 {10 Fund *myFund;11 Bid *myBid;12 Account myAccount;1314 myFund=new Fund(19.84);15 myBid=new Bid(100);16 myBid->setFund(myFund);17 myAccount.setBid(myBid);18 cout << "⼤华⼤华基⾦单位及净值： "19 << "(" << myBid->getUnit() << ")"20 << "(" << myFund->getPrice() << ")" << endl;2122 myFund=new Fund(37.83);23 myBid=new Bid(200);24 myBid->setFund(myFund);25 myAccount.setBid(myBid);26 cout << "⽇盛上选基⾦单位及净值： "27 << "(" << myBid->getUnit() << ")"28 << "(" << myFund->getPrice() << ")" << endl;2930 myBid=new Bid(300);31 myBid->setFund(myFund);32 myAccount.setBid(myBid);33 cout << "⽇盛上选基⾦单位及净值： "34 << "(" << myBid->getUnit() << ")"35 << "(" << myFund->getPrice() << ")" << endl << endl;3637 cout << "总资产为： "38 << myAccount.calcAsset() << endl << endl;3940 system("PAUSE");41return EXIT_SUCCESS;42 }下⾯我们来画⼀下UML图，并且⽤UML⾃动⽣成C++代码来做⼀个⽐较⽣成代码对⽐Account.h达到预期Bid.h达到预期Fund.h达到预期。
(完整版)面向对象分析与设计练习题含答案
面向对象分析与设计试题B卷一、单项选择题( 在每小题的四个备选答案中，选出一个正确答案，并将正确答案的序号填在题干的括号内。
每小题2 分，共20 分)/* 上个世纪80年代开始至今还盛行的以Smalltalk,C++等为代表的面向对象软件开发方法(00)*/1.到20世纪末，面向对象软件工程已经逐渐发展成熟，特别是（D）的形成和广泛使用，采用面向对象分析与编程的软件开发方法已成为软件开发的主流方法。
A. Simula67语言（20世纪70年代的Simula-67是第一个面向对象的语言）B. Smalltalk语言（80年代初的Smalltalk语言）C. Java语言(对流行的语言进行面向对象的扩充得到的语言或C++)D. 统一建模语言(UML)的标准2. 面向对象的运动产生了多种面向对象的语言, 其中（C）是一种混合性面向对象语言, 既支持面向过程的程序设计方法，又支持面向对象的程序设计方法，有广泛应用的基础和丰富开发环境的支持，因而使面向对象的程序设计能得到很快普及。
A. SmalltalkB. EiffelC. C++D. Java3．下列不属于面向对象技术的基本特征的是（B）。
A. 封装性B. 模块性C. 多态性D. 继承性4. 面向对象程序设计将描述事物的数据与( C ) 封装在一起,作为一个相互依存、不可分割的整体来处理。
A. 信息B. 数据隐藏C. 对数据的操作D. 数据抽象5. 关于面向对象方法的优点，下列不正确的叙述是（C）。
A. 与人类习惯的思维方法比较一致B. 可重用性好C. 以数据操作为中心D.可维护性好6.（D）是从用户使用系统的角度描述系统功能的图形表达方法。
A. 类图B. 对象图C. 序列图D. 用例图7. (C ) 是表达系统类及其相互联系的图示,它是面向对象设计的核心，建立状态图、协作图和其他图的基础。
A．对象图 B. 组件图 C. 类图 D. 配置图**8.（D）描述了一组交互对象间的动态协作关系，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UML类图与关系数据库之间的映射策略摘要：UML是目前面向对象程序设计中的一种标准的建模技术。
在关系数据库系统的设计过程中，我们可先利用UML建立商业模型，然后将其映射成表。
本文主要讨论如何将UML 类图中的类映射成表的策略。
关键词：UML 类表关系建模映射一．概论在关系数据库设计中，用来创建数据库逻辑模型的标准方法是使用实体关系模型（ER 模型）。
ER模型的中心思想是：可以仅通过实体和它们之间的关系合理地体现一个组织的数据模型。
但这样做似乎对描述一个组织的信息过于简单化，并且词汇量也远远不足。
所以，迫切需要使用更加灵活、健壮的模型来代替ER模型。
标准建模语言UML是由世界著名的面向对象技术专家发起的，在综合了著名的Booch 方法、OMT方法和OOSE方法的基础上而形成的一种建模技术，它通过用例图、类图、交互图、活动图等模型来描述复杂系统的全貌及其相关部件之间的联系。
UML可以完成ER 模型的所有建模工作，而且可以描述ER模型所不能表示的关系。
在UML中，类图主要用于描述系统中各种类及其对象之间的静态结构。
在关系数据库领域中，类与表相对应。
本文主要讨论将UML类图中的类及其对象映射成关系型数据库中的表的策略。
二．UML类图中的类映射成表的策略UML中的类图主要由类及其关系组成，而类之间的关系又可以细分为：（1）泛化：在UML类图中，如果子类型的接口包括超类型的接口中的每个元素。
则超类与子类之间构成泛化关系。
泛化通常可以用继承或授权的方式实现。
（2）关联：在UML类图中，关联表示类的实例之间存在的某种关系。
它通常可以有1对1、1对多和多对多等情形。
（3）聚集：在UML类图中，聚集描述了部分与整体之间的关系。
（4）组成：在UML类图中，组成由聚集演变而成，它表示一个部分对象仅属于一个整体，并且部分对象通常与整体对象共存亡。
下面结合例子，分别讨论在将类映射成表的过程中这些关系的实现技术。
假设，有一个电脑公司专门从事软件开发，其项目主要由项目开发部门承担，它们之间构成多对多的关联（即一个项目可由多个部门承担，而一个部门又可以承担多个项目的开发工作）；项目开发部门由经理及一般职员组成，项目开发部门和组成人员之间构成聚集关系，而人（抽象类）又可以进一步和一般职员及经理两个子类之间构成继承关系；每个项目具有一定的属性，它们之间构成组成关系。
综上所述，其主要关系的UML类图如图1所示。
1．将类图中的属性类型映射成表的域域的使用提高了设计的一致性，且优化了应用的移植性。
简单的域是非常容易实现的，在映射时仅需替换相对应的数据类型和数据尺寸。
但要注意：有时可能要求在域的约束中加入SQL的Check串（如限定域的取值范围等）。
2．将类的属性映射成表的字段一般地，可将类的属性直接映射成表的一个字段，但要注意以下两种特殊情况：（1）并不是类中的所有属性均是永久的。
例如，发票中的“合计”属性可由计算所得而不需保存在数据库中，此时，该类属性（称为派生属性）映射成个0个字段。
（2）一般地，类中的属性是单值的，但如果在类中存在多值属性，则该属性映射成多个字段。
3．将类直接或间接地映射成表。
将UML类图中的类映射成表时，可针对类间的不同关系，采用下面介绍的各种策略。
首先，在关系数据库中，一个关键问题是表主键的唯一性策略的选取。
适当的方案能优化继承、组成等类之间的关系的实现。
为此，可以在处理数据库关系时嵌入对象标识符（OID）的概念，即采用对象标识符OID（对象唯一的标识符）作为相应的数据库中所有表的主键，从而简化了关系数据库的主键方案，使数据库发生更新时，不会出现完整性问题，并且还可以避免在数据库操作时的诸多限制。
但要注意的是，OID不应包含有商业内涵（这一点可能和传统的关系理论相悖），因为任何具有商业意义的字段不在控制范围之内，从而设计者面临值和规划改变的危险。
（1）继承的实现策略一：将整个类层次映射为单个数据库表。
类层次中的所有类映射为单个的数据库表，表中保存所有类（基类、子类）的属性。
例如，图1中人、职员及经理之间的关系的实现如图2所示。
该策略实现简单，支持多态，报表操作实现简单。
但增加了类层次中的耦合，类层次中任何类的属性的增加会导致表的变更；某个子类属性的修改错误会影响到整个层次结构，而不仅仅是该子类。
并且该策略还浪费了大量的数据库空间。
策略二：每个具体子类映射成单个数据库表。
数据库表包括自身的属性和继承的属性，每个具体的子类包含各自的OID。
抽象基类不参与映射，它的所有属性都复制到子类对应的表中。
例如，图1中的人、职员及经理之间的关系可映射成两个表，其中“职员”表包含“职员OID”（主键）、“姓名”和“工作类别”字段；“经理”表包含“经理OID（主键）”、“姓名”和“职位补贴”字段。
该策略由于在表中包含了具体子类的所有信息，所以报表操作实现简单。
但类的修改会导致相对应的表及其子类所对应表的更改；角色的更改会造成ID的重新赋值（因为不同子类的ID可能重复）。
并且该策略还难以在支持多重角色时，保持数据的完整性。
策略三：每个类均映射为数据库表。
为每一个类创建数据库表，表中包含特定于该类的属性和OID。
例如，图1中的人、职员及经理之间的关系可映射成三个表，其中“人”表包含“人OID”（主键）和“姓名”字段；“职员”表包含“人OID”（主键及外键）和“工作类别”字段；“经理”表包含“人OID”（主键及外键）和“职位补贴”字段。
值得注意的是：“人OID”作为所有表的主键。
该策略与面向对象的概念相一致，对多态的支持最好，并且对于对象可能充当的角色仅需要在相应的表中保存记录，易于修改基类和增加新的类。
但由于数据库中存在大量的表，所以访问数据的时间较长，对报表的支持较差（除非定义视图）。
（2）关联的实现在关系数据库中，可通过外键实现类的关联。
外键允许表中的某一行与其它表中的行相关联。
为了下面论述方便，现假定M表示强制（Mandatory），O表示可选（Optional）。
情况一：1对1的关联如果关联是O－M，则可将外键放置在可选的一端，该外键不能为空值；其它1对1的情况外键可放置在任意一边，具体情况依赖于性能等因素。
但要注意的是：对于1对1的情况，不要在两个表中均放置对方的主键。
这样，增加了冗余，并且不会提高性能。
对于关联的强制性，一般在商业规则的对应层实现，而不在物理层中实现。
情况二：1对多的关联将外键放置在“多”的一方。
如果“1”方是可选的，则外键可有空值，以表明“多”方的记录可以独立于“1”方存在；如果1方是强制性的，则外键一定要非空。
情况三：多对多的关联实现多对多关系，通常需要建立一个关联表，并把它与关系两端的表建立联系。
在传统实现中，关联表的属性包含关系中两个表的主键，并且关联表的主键往往是它们的组合。
该实现方法意味两个表的联系是静态的，不能跟踪一方退出某个项目然后又在某个时候加入的情况。
另一种实现方法是将关联表视为普通表，使用自身的主键OID，然后加入实现关系所必需的外键。
例如，“项目”与“项目开发部门”之间的多对多关联可用图3的方式实现。
使用该方法，可保证在物理层中，所有的表具有相同的形式，从而简化了实现，提高了运行时效率。
但要注意的是：一些数据库在连接具有复合外键的表时，性能较差；并且，存在着向关联表中增添字段的可能。
（3）聚集的实现例如，在图1中项目开发部门及人之间的聚集关系的实现如图4所示：图4（4）组成的实现组成的映射和聚集类似，但要注意的是：子表中的外键必须是强制非空的。
三．引用完整性及关系约束检查的策略在UML中，类之间的关系反映了具体的商业规则，因此将类映射到关系数据库时，必须保证类之间关系的正确定义，并确保在数据库中实施对数据的约束。
以下就1对多的情形为例加以说明（1对1关系可以视为特殊的1对多关系；多对多关系则可以分解为两个1对多关系）。
1．父表操作的约束。
将类的关系映射为到关系数据库后，父表在操作上的约束规定如表1。
2．子表操作的约束将类的关系映射为到关系数据库后，子表在操作上的约束规定如表2。
表2施加子表的约束主要是为了防止碎片的产生。
在一些情况下（如在O-M、M-M约束中），一个子女（子表中的记录）只有在当其兄弟存在时才能被删除或修改。
即最后一个存在的子女是不能被删除或修改的。
此时，可以对父记录进行即时的更新。
或者禁止该操作。
而子表约束可以通过在数据库中加入触发器来实现，一个更合理、可行的方法是将对子表方的限制放在业务层中实现。
应用程序执行数据约束有很重要的作用。
在四类约束M-M、M-O、O-M、O-O中，键值的修改可能会改变表之间的关系，而且可能违反一些约束。
违反约束的操作是不允许的。
而前面的规则仅为具体实现提供了可能性。
具体的应用必须根据实际的要求和商业规则进行适当的选择。
但在设计和开发时，必须考虑以上所分析的约束。
目前，面向对象已成为软件开发的主流技术，在一个良好的项目设计中，我们可以先使用面向对象的UML技术建立商业模型，接着引入映射层，对将类设计映射至关系数据库的逻辑进行封装。
通过物理层封装对数据库的访问细节，并为开发者提供简单而又完备的接口，从而使开发者可以运用面向对象的技术解决关系数据库领域中的问题。
参考文献：[1] 《可视化面向对象建模技术》刘超、张莉编著北京航空天大学出版社1999年7月[2] 《Oralce 8 UML 对象建模设计》Paul Dorsey 编著机械工业出版社2000年4月。