如何设计数据库
我们已经得到了类图。类图里面详细的记录着每个类的属性与方法以及类与类之间的关系。正因为有了这些才让我们接下来的工作得心应手。
但我们在设计数据库的时候必须面临几个问题：如何在设计数据库的时候体现类图中的继承关系，以及类图中的1:N,N:N这类多重度问题。
带着这些疑问，咋们来看看下面的图_数据库_1。这张图里面的关系很好的解决刚提出来的问题。图_数据库_1描述的是关于商品部分的类图的部分关系。在商品部分类图中，可选某些特征的商品类是继承于商品类，商品类与商品细节图片类是1:N, 可选某些特征的商品类与商品特征类是1:N,商品特征类与商品细节类是1:N。我们来看看这张数据库的关系图是怎么解决这些问题的。
继承问题:
表CustCommodity与表Commodity通过commodity表中的id字段建立外键关系，这样1条Commodity元组可以关联CustCommodity中的多条元组,并且CustCommodity也可以通过这个关联来获取Commodity中与它关联的元组。并且表CustCommodity中是以字段id为主键，也就避免一条CustCommodity元组关联多条commodity元组的情况。这样一来是不是有点像面向对象程序设计里的单重继承呢。
1:N问题：
这里所描述的1:N问题不是普通的1:N,普通的1:N问题可以通过设计外键来解决。查看商品部分类图（图_类图_1）我们能看到：商品类与商品细节图片类有1:N关系，商品特征与商品细节图片有1:N关系。商品类，商品特征类，商品细节图片类在数据库中分别设计成表Commodity,CustCommodityAttribute,CommodiityImage。我们并不希望粗暴的在CommodityImage中加上两个外键，来达到1:N的效果。这样设计会为数据库的扩展性带来负面影响。也许现在有2个类需要引用商品细节图片类,当过段时间随着需求的改变会有第3个第4类冒出来，如果不采取有效的措施这将会是无尽的噩梦！在这里我们采用N:N的原则来解决这个问题，毕竟N:N可以分解为1:N。这样如果有第3个或第4个类冒出来的话我们只需要增加一个关系表就能解决问题，而不用去修改以存储了海量数据的表！
图_数据库_1
解决了上面的几个难题后，接下来的问题将变的非常的简单。只是根据类图的描述来设计表与表之间的关系及g根据类图中包含的类的属性来设计表的字段。我们来做张Commodity表吧，这张表代表的是商品类。
根据图_类_商品中描述的商品类我们可以将Commodity表设计为:
图_数据库_Commodity
商品类中的属性：图片描述因为是集合形式的不能将它简单的设计为一个字段，这样将违反了数据库设计标准中的第一范式，会造成数据冗余。故将它分解为图_数据库_1中的关系表CommodityImageRelation.
按照这样的方法，我们能将设计好的类图转化为基于它的数据库。完成后的数据库关系图如下：
图_数据库_总体结构图