基于面向对象数据库模式设计研究.docVIP

基于面向对象数据库模式设计研究 　　摘 要：面向对象数据库系统是为了满足新的数据库应用而产生的新一代数据库系统，通过设计面向对象数据库的理论概念和含义来构建一个面向对象的数据库系统的理论体系，而面向对象数据库的模式设计方法又显得尤为重要，它是在E-R模型的基础上加入面向对象程序设计思想的继承、构成、消息传递、方法等成分后进行的改进，产生了较为规范的根据需求生成扩展的E-R模型和数据结构方法，在设计过程中包括概念提取，概念分析，确定概念模型等，还包括消息传递和联系的实现方法，以及拥有实例的确定法则，实例对方法的可行性检验方法等。 　　关键词：面向对象；数据库；模式设计 　　中图分类号：TP311.52 　　1 映射关系 　　在应用领域中数据库设计将面对的是更多更复杂的业务关系，面向对象数据库的模式设计是以实体对象进行建模，它和具体的应用领域中业务对象又是对应的关系，所以对象关系模型也适应于业务对象。对象基本关系模型根据业务对象之间的关系，将实体对象模型分成元实体对象模型和关联实体对象模型。这些模型构成了业务对象关系的基本框架。 　　在关系数据库为基础加入对象―关系映射引擎，将实体对象和关系表做一个映射，上层应用操作实体对象，映射引擎操作具体的关系表，在整个过程中对象关系数据库是自底向上的行为，由数据库厂商实现。而对象关系映射是自上而下的行为，由应用层来完成，核心技术就是OR映射，（1）将类映射成表。类到表的映射通常不是直接的。除非常简单的数据库以外，不会有类到表的一对一映射。（2）将属性映射成列。类属性将映射成关系数据库中相应的列，且这些属性都不是持久的。（3）在面向对象中将联系转换成类/对象，表示联系的类用来记录对象之间的对应关系，在程序运行过程中起到对象之间的映射作用，联系类应该具备如下基本特性：用来存储对应关系的数据结构，有这个数据结构的维护机制，有足够的查询机制。 　　在面向对象数据库的逻辑设计阶段，采用面向对象的数据模型来表述逻辑设计的结果，在概念设计阶段采用对应扩展ER模型，而扩展ER模型主要用来分析有关应用信息需求和构造高级数据模型，也就是对传统ER模型进行的扩展。其中扩展ER模型有静态元素、动态元素的扩展和构成的加入，静态元素的加入相当于继承，而继承又是用来联系2个或者2个以上实体型（一对多关系），通过比较规范的设计得到扩展ER模型中实体型与属性和方法的拓扑结构就是深度为2的树，如下图1： 　　图1 实体继承 　　据继承的传递性，一个实体型实际继承了层次结构中在其上面的所有实体型的全部性质。扩展ER模型动态元素的扩展包括方法和消息传递的加入，面向对象中的方法相当于函数，用来描述实体行为特性和某种操作的程序，例如：教师实体型中职称和学历相当于方法，其属性也可以进行new。而消息传递的加入是用来一对一的有向联系两个实体型，也可以用来处理实体执行某一处理的请求或回答某些信息的要求，例如：教师实体向学生实体发送问题消息，要求学生解答。 　　构成的加入是用来联系2个或者2个以上实体型，其形式是实体型之间的一对多的联系，区别于继承的是不具有层次结构上面的性质，在特性方面是叠加的，因为有这样一概念，才能实现面向对象的复杂结构、较高的数据抽象能力和结构上较高的灵活性。当一个实体型包含有其他实体型时，称这个实体型由其他实体型构成，如下图2： 　　图2 实体构成图 　　扩展的ER模型主要包括7个成分：实体型、对象标识、属性、方法、联系、封装、继承、多态、构成、消息传递，其中最重要的是封装性、继承性、多态，，封装性是将数据与操作封装起来，提供类层次结构，建立不同层次的数据抽象，使用户可以采用统一的模式去处理数据对象。这样的模型也能更好的应用到面向对象数据库的设计当中。除了上述基本定义之外，为适应非常规应用领域，还需引入其他一些扩展的特征，如长事务和协作等，它们充分体现了面向对象的特征。 　　概念图型方法 概念图型方法 　　实体型 　　属性 　　方法 　　联系 继承 　　构成 　　消息传递 　　图3 扩展ER模型图形元素 　　在确定具体类和实例过程中引出新的问题： 　　将实体转化成类以后，需要确定哪些类将有实例/对象存在，如果一个类成为超类后，其子类将继承所有特性，但不再拥有实例/对象，所以子类完全有能力表达超类能够表达的信息，同时也证明超类已经不能满足信息表达的需求，另外，指向没有实例的类的联系和向没有实例的类发送消息是没有意义的。 　　如果有消息发往没有实例的类，则该消息应改为发往原接收类的所有非超类的子类，如果有联系指向没有实例的类C1，设该类有n个非超类的子类C11，C12，…C1n，则该联系用n个联系代替，在n个联系中原来指向C1的指针分别指向C11，C12，…C1n，其余不变。向没有实例的类发送消息通过调用响应消息的方法来