对象-关系数据库之间的映射1
面向对象数据库与关系数据库的优缺点对比
面向对象数据库与关系数据库的优缺点对比随着信息技术的不断发展，数据库成为了现代社会中不可或缺的一部分。
在数据库的发展过程中，面向对象数据库和关系数据库成为了两种主要的数据库模型。
面向对象数据库以对象为基本单位进行数据存储和管理，而关系数据库则以表格的形式组织数据。
本文将对这两种数据库模型的优缺点进行对比。
一、面向对象数据库的优点1. 数据模型的灵活性：面向对象数据库采用了面向对象的数据模型，可以更好地反映现实世界中的对象和关系。
它可以直接存储和处理复杂的对象结构，使数据的组织更加灵活。
2. 数据的封装性：面向对象数据库将数据和操作封装在一起，通过封装实现了数据的安全性和完整性。
对象的方法可以对数据进行操作和控制，保证了数据的一致性和可靠性。
3. 数据的继承性：面向对象数据库支持继承关系，可以通过继承来共享和复用数据和操作。
这样可以减少数据的冗余和重复，提高数据的利用率。
4. 复杂查询的能力：面向对象数据库支持复杂的查询操作，可以通过对象之间的关联和继承关系进行查询。
这样可以方便地进行数据分析和挖掘，提高了数据的处理效率。
二、面向对象数据库的缺点1. 学习成本高：面向对象数据库需要掌握面向对象的概念和技术，对于一些没有相关背景知识的用户来说，学习成本较高。
2. 标准化程度低：面向对象数据库的标准化程度相对较低，不同厂商的实现方式可能存在差异。
这样会导致数据的互操作性较差，不利于数据的共享和交换。
三、关系数据库的优点1. 数据的结构化：关系数据库采用了表格的形式组织数据，具有良好的结构化特性。
这样可以方便地进行数据的管理和维护，提高了数据的可靠性和稳定性。
2. 数据的一致性：关系数据库通过事务的机制来保证数据的一致性。
事务可以对一组操作进行原子性、一致性、隔离性和持久性的要求，保证了数据的完整性和一致性。
3. 标准化程度高：关系数据库采用了SQL作为标准的查询语言，具有较高的标准化程度。
这样可以方便地进行数据的共享和交换，提高了数据的互操作性。
持久层概述——精选推荐
持久层概述分层结构是软件设计中⼀种重要的思想。
持久层就是在软件的三层体系结构的基础上发展起来的，它以解决对象和关系这两⼤领域之间存在的问题为⽬标，为对象-关系数据库之间提供了⼀个成功的映射解决⽅案。
1.持久化对象我们已经知道，程序运⾏期间的数据都是保存在内存中的。
由于内存是易失性存储器，其中的数据掉电后就会丢失，但⼀些重要的数据需要长久保存以供使⽤，显然，仅依靠内存⽆法实现数据的长期保存。
为解决该问题，在计算机领域引⼊了持久化概念。
持久化（Persisent）指的是将内存中的数据保存到磁盘等存储设备中。
持久化对象是指已经存储到数据库或磁盘中的业务对象。
在java中对对象持久化的⽅式有3种：. 序列化对象，将对象存放到格式化的⽂本⽂件中。
.将对象持久化到XML⽂档中。
.将对象持久化到数据库中，⼀般为关系数据库。
关系数据库中遵循的⼀条重要原则就是“数据库独⽴性”，即数据库可以独⽴于应⽤程序⽽存在。
由此可知，数据可以⽐任何应⽤都存在得更持久。
同时，不同应⽤也可以共享数据库中的数据。
2.分层体系结构和持久层 随着计算机应⽤软件的不断发展，应⽤程序从最初的单层结构逐渐演变为双层结构。
分层也成为了软件设计中的⼀种重要思想。
双层结构分为应⽤层和数据库层，在双层结构中，⽤户界⾯和业务逻辑都由应⽤层负责实现，数据库层只负责存放持久化的数据。
这样，同⼀个程序⽂件中⽤户界⾯代码和业务逻辑代码会出现混合，显然会产⽣程序结构不清晰、维护困难等问题，⽽且不熟悉编程语⾔的美⼯⼈员也⽆法参与到软件开发过程中来。
这些问题促使了应⽤层的再次划分，将⽤户界⾯的设计从业务逻辑层中独⽴出来，形成单独的⼀层----表⽰层。
经过再次划分后的软件结构就从双层结构变成了经典的三层结构。
经典的软件应⽤体系结构有三层、表⽰层、业务逻辑层、和数据库层。
.表⽰层：提供了与⽤户交互的接⼝。
实现⽤户操作界⾯，展⽰⽤户需要的数据。
.业务逻辑层：完成业务流程，处理表⽰层提交的数据请求，并将要保存的数据提交给数据库。
对象关系数据库
对象关系数据库综述摘要：本文通过对对象关系数据库发展的历史背景、理论支持、体系结构、发展现状等了解、认识的基础上，对对象关系数据库进行全面剖析，并分析了它的产生、存在和发展现状，比较了在它发展过程中产生的优缺点，更好、更深入的帮助人们了解对象关系数据库的原理和体系结构。
关键字：对象关系数据库，数据库，体系结构一、对象关系数据库发展的历史背景从上世纪80年代初开始，数据库技术的应用在商业领域产生的巨大影响使人们认识到数据库技术的重要性。
随着科技的发展，各行各业为了满足自身的发展对数据库技术提出了更多的需求，单一的关系数据库已经不能胜任，以关系数据库为代表的传统数据库已经满足当前人们的需求。
这样就必须要有新的数据库技术才能满足现实的需求。
在软件开发领域，面向对象的方法在软件开发的分析、设计以及编码中作用越来越重要，它在适应系统需求变化、提高软件可重用性和开发效率方面有着其它开发方法无法比拟的优点。
面向对象思想将应用域中的概念描述成对象，应用系统由一系列对象构成，对象之间可以传递消息，系统的运作可说就是对象间的协同工作。
这些对象在面向对象方法中主要指实体对象。
目前，对象存储方式主要有两种：一种是存入文件，另一种是存入数据库。
将对象存入文件中，容易实现，操作简便，有很多类库已实现了此功能，但是文件存储方式不仅表示不清楚对象间的关系，对性能也有很大的制约。
将对象存入数据库，理想的选择是面向对象数据库，但面向对象数据库虽有所发展，仍不成熟，还不能满足需要[5]。
关系型数据库系统经过多年的发展，技术已经相当成熟，应用十分广泛，大部分信息系统都以其作为后台数据管理。
如今成熟的数据库产品有很多，为了降低在数据库编程方面的难度，各种数据库访问模型相继问世，如ADO、ODBC、BDE、和JDBC等。
基于以上所述, 利用现有的优势、改造关系数据库并融入面向对象技术, 即所谓的对象关系数据库, 成为业界的一个新的课题。
对象关系系统尝试结合两者的优点, 它以关系模型的SQL查询语言为基础, 但增加了数据模型的面向对象的特征。
orm的基本映射方式
orm的基本映射方式ORM的基本映射方式ORM（对象关系映射）是一种将对象模型与数据库模型进行映射的技术，它可以将数据库中的表映射成对象，从而简化了开发人员对数据库的操作。
在ORM中，有几种基本的映射方式，包括：表映射、列映射、关联映射和继承映射。
1. 表映射表映射是ORM中最基本的映射方式之一。
它将数据库中的表映射成对象，使开发人员可以直接通过操作对象来进行数据库的增删改查操作。
在表映射中，每个表对应一个对象，表的每个字段对应对象的一个属性。
通过表映射，开发人员可以方便地进行数据库操作，无需编写复杂的SQL语句。
2. 列映射列映射是指将数据库表中的列映射成对象的属性。
在列映射中，每个表的列对应对象的一个属性。
通过列映射，开发人员可以方便地将数据库中的数据存储到对象中，或者将对象中的数据保存到数据库中。
3. 关联映射关联映射是指将数据库表之间的关联关系映射成对象之间的关联关系。
在关联映射中，通过定义对象之间的关联属性，可以实现数据库表之间的关系。
例如，一个订单对象可以关联多个商品对象，通过关联映射，可以方便地进行订单与商品之间的操作。
4. 继承映射继承映射是指将数据库表之间的继承关系映射成对象之间的继承关系。
在继承映射中，通过定义对象之间的继承关系，可以实现数据库表之间的继承关系。
例如，一个员工对象可以继承自一个人员对象，通过继承映射，可以方便地进行员工与人员之间的操作。
以上是ORM中的基本映射方式，通过这些映射方式，开发人员可以方便地进行数据库操作，提高开发效率和代码质量。
同时，ORM还提供了一些高级的映射方式，如多对多关联映射、一对多关联映射等，可以更加灵活地处理复杂的数据库关系。
需要注意的是，在使用ORM进行开发时，开发人员需要根据具体的业务需求来选择合适的映射方式，并进行合理的设计和调优。
同时，由于ORM是一种抽象和封装的技术，它并不是适用于所有的场景，对于一些对性能要求较高的场景，可能需要使用原生的SQL语句来进行操作。
jpa convert原理 -回复
jpa convert原理-回复JPA(Convert)原理：简介与基本原理JPA（Java Persistence API）是Java领域的一种ORM（对象关系映射）标准，作为Java EE（企业版）规范的一部分，它提供了一种机制，用于将Java对象与关系型数据库之间进行映射。
在JPA中，将Java对象持久化到数据库中被称为"转换"（convert），它通过一系列的过程将Java对象转换成对应的数据库结构，或者将数据库中的数据转换成Java对象。
在本文中，我们将深入探讨JPA Convert原理，逐步解释整个转换过程。
1. 扫描实体类：首先，JPA需要扫描应用程序中的实体类。
实体类是指在数据库中有对应表结构的Java类。
JPA将使用反射机制扫描这些实体类，并获取类的元数据信息，包括字段、关联关系等。
2. 创建元模型类：在扫描实体类的过程中，JPA会生成对应的元模型类。
元模型类是对实体类的元数据信息进行抽象和封装后的类，用于在编译时进行静态类型检查。
元模型类是JPA Convert的基础，它通过将实体类的属性、关联关系等抽象成对应的类和属性，使得我们在后续的处理中可以更加方便和高效地操作和转换实体类。
3. 解析注解：JPA使用注解来描述实体类和表之间的映射关系，比如Entity、Table、Column等注解。
在这一步，JPA会解析这些注解，并根据注解的信息来设置实体类与数据库表之间的对应关系。
4. 创建数据库表：根据实体类的元数据信息和注解解析的结果，JPA将会在数据库中创建对应的表结构。
如果表结构已经存在，JPA则会进行更新和修改操作，以保持表结构与实体类的一致性。
5. 转换数据类型：在将Java对象转换为数据库中的数据时，JPA还需要处理数据类型的转换。
Java中的数据类型与数据库中的数据类型不尽相同，因此在转换过程中，JPA需要将Java对象中的数据转换为数据库中对应的数据类型。
数据模型映射关系
数据模型映射关系
数据模型映射关系是指在不同的数据模型或数据库之间建立的对应关系。
这种映射关系用于将一个数据模型中的数据和结构转换为另一个数据模型或数据库中的相应表示。
以下是一些常见的数据模型映射关系的示例：
1. 概念模型到逻辑模型的映射：在数据库设计过程中，概念模型（如实体关系图）被转换为逻辑模型（如关系型数据库的表结构）。
这种映射涉及将实体、属性和关系转换为相应的表、列和主键-外键关系。
2. 逻辑模型到物理模型的映射：逻辑模型表示数据的逻辑结构和关系，而物理模型则关注数据在实际存储介质中的组织和布局。
这种映射涉及将逻辑表和列转换为物理表和文件，以及确定存储策略、索引等。
3. 数据库到应用程序的数据映射：在应用程序开发中，数据库中的数据需要与应用程序中的对象或模型进行映射。
这种映射涉及将数据库表中的列与应用程序中的属性或字段相对应，以便在应用程序中操作和显示数据。
4. 不同数据库之间的映射：当需要将数据从一个数据库迁移或集成到另一个数据库时，需要建立数据库之间的映射关系。
这包括映射表结
构、列类型、数据约束等，以确保数据在不同数据库之间的一致性和可移植性。
5. 数据模型到数据仓库的映射：在数据仓库环境中，源系统的数据模型需要与数据仓库的模型进行映射。
这种映射涉及将源系统中的表、字段和关系转换为数据仓库的维度、事实和层次结构。
orm的映射原理
orm的映射原理ORM（对象关系映射）是一种将数据库表结构映射到对象的过程，它的主要目的是简化数据库操作，提高开发效率。
ORM框架通过将数据库表映射为对象，并提供对对象的CRUD（创建、读取、更新、删除）操作，使开发者可以直接操作对象来实现对数据库的操作，而不需要直接操作SQL语句。
ORM映射原理主要包括以下几个方面：1. 实体类与数据库表的映射：ORM框架通过注解、配置文件或者扫描实体类的方式，将实体类与数据库表进行映射。
映射可以指定实体类与数据库表的对应关系、表名、字段名、主键等。
2. 属性与字段的映射：实体类中的属性与数据库表中的字段进行映射。
ORM框架可以根据属性的命名规则或者通过注解、配置文件等方式，将属性与字段进行关联映射。
3. 关联关系的映射：ORM框架可以通过注解或者配置文件的方式，将实体类之间的关联关系映射到数据库的外键关系上。
可以通过一对一、一对多、多对一、多对多等关联关系进行映射。
4. CRUD操作的实现：ORM框架通常提供了一系列的API，用于实现实体类的增删改查操作。
通过框架提供的API，可以将操作转换为对数据库的SQL语句，并执行相关的数据库操作。
5. 对象与数据库的转换：ORM框架通过将对象转换为数据库表记录，或者将数据库表记录转换为对象的方式，实现对象与数据库之间的转换。
框架通常提供了对象与数据库之间的转换工具，可以将对象的属性值与数据库表的字段值进行相互转换。
总的来说，ORM框架的映射原理就是将实体类与数据库表进行映射，将属性与字段进行映射，将关联关系进行映射，并提供相应的CRUD操作和对象与数据库之间的转换。
这样可以使开发者更关注业务逻辑，而无需关心数据库操作的具体细节。
pdo 的映射参数
pdo 的映射参数PDO的映射参数指的是在PHP中使用PDO（PHP数据对象）扩展进行数据库操作时，可以使用的一些参数来进行数据库表和对象之间的映射。
这些映射参数可以帮助开发者更加便捷地进行数据库操作，提高开发效率。
本文将介绍几个常用的PDO映射参数及其使用方法。
1. 映射表名在使用PDO进行数据库操作时，可以通过设置映射参数来指定表名与类名之间的映射关系。
例如，可以通过设置PDO的映射参数将数据库表users映射为Users类。
这样，在进行数据库操作时，可以直接使用类名来操作数据库，而无需直接操作数据库表，提高了代码的可读性和可维护性。
2. 映射字段除了映射表名之外，还可以通过设置映射参数来指定字段名与属性名之间的映射关系。
例如，可以通过设置PDO的映射参数将数据库字段user_name映射为属性userName。
这样，在进行数据库查询时，可以直接使用属性名来获取字段值，简化了代码的书写。
3. 映射关系通过设置映射参数，还可以指定表之间的关联关系。
例如，可以通过设置PDO的映射参数将用户表users与订单表orders关联起来。
这样，在进行数据库查询时，可以通过用户对象直接获取关联的订单对象，实现了数据的关联查询，减少了数据库查询的次数，提高了查询效率。
4. 映射类型PDO的映射参数还可以指定字段的数据类型与属性的数据类型之间的映射关系。
例如，可以通过设置映射参数将数据库字段age的数据类型映射为属性age的数据类型为整型。
这样，在进行数据库插入和更新操作时，可以对数据类型进行校验，避免了数据类型不匹配的错误。
5. 映射规则除了直接指定映射关系外，还可以通过设置映射参数来指定一些映射规则。
例如，可以通过设置PDO的映射参数来指定属性名的命名规则，如驼峰命名法或下划线命名法。
这样，在进行数据库操作时，可以根据映射规则自动转换属性名和字段名，减少了手动转换的工作量。
6. 映射缓存为了提高性能，PDO还提供了映射缓存的功能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对象-关系数据库之间的映射 为什么对象-关系数据库的映射对于现代开发者是一件大事呢？一方面，对象技术（例如 Java 技术）是应用于新软件系统开发的最常见的环境。另外，关系数据库仍然是许多人都青睐的持久信息存储方法，并且在较长时间内这种情况不太会改变。请继续读下 去，了解如何使用这种技术。
为什么要写有关对象-关系数据库之间的映射的文章呢？因为在对象范例和关系范例之间“阻抗不匹配”。对象范例基于软件工程的一些原理，例如耦合、聚 合和封装，而关系范例则基于数学原理，特别是集合论的原理。两种不同的理论基础导致各自有不同的优缺点。而且，对象范例侧重于从包含数据和行为的对象中构 建应用程序，而关系范例则主要针对数据的存储。当为访问而寻找一种合适的方法时，“阻抗不匹配”就成了主要矛盾：使用对象范例，您是通过它们的关系来访问 对象，而使用关系范例，则通过复制数据来联接表中的行。这种基本的差异导致两种范例的结合并不理想，不过话说回来，本来就预料到会有一些问题。使对象-关 系数据库之间的映射成功的一个秘诀就是理解这两种范例和它们的差异，然后基于这些认识来进行明智的取舍。
本文应该能够消除现今开发周期中一些普遍共有的误解，对对象-关系数据库之间映射所涉及到的一些问题提供了切合实际的看法。这些策略基于我的开发经 验，项目范围从小到大，涉及金融、销售、军事、远程通信和外购等行业。我已对使用 C++、 Smalltalk、Visual Basic 和 Java 语言编写的应用程序应用了这些原则。
如何将对象映射成关系数据库 在这一节中，我会描述一些将对象成功映射成关系数据库所需的基本技术。
将属性映射成列 在关系数据库中实现继承 将类映射成表 映射关联、聚合和组合 实现关系
将属性映射成列 类属性将映射成关系数据库中的零或几列。要记住，并不是所有属性都是持久的。例如， Invoice 类会有 grandTotal 属性，这个属性由其实例在计算时使用，但它不保存到数据库
中。而且，某些对象属性本身就是对象，例如 Course 对象有一个作为属性的 TextBook 实例，它映射为数据库中的几列（实际上，很有可能 TextBook 类本身就将映射成一个或多个表）。重要的是，这是一个递归定义：有时属性将映射成零或者多列。也有可能将几个属性映射成表中的单一列。例如，代表美国邮递 区号代码的类可以有三个数字属性，每个都表示完整邮政编号代码中的每一部分，而邮政编号代码可以在地址表中作为单一的列存储。
在关系数据库中实现继承 在将对象保存到关系数据库中时，继承的概念中发生几个有趣的问题。（请参阅参考资料中 的 "Building Object Applications That Work"。）问题从根本上归结为解释如何在您的持久模型中组织继承的属性。解决这个难题所用的方法会对系统设计有很大影响。将继承映射到关系数据库中有 三种基本解决办法，为更好地理解它们，我将讨论在图 1 中显示的映射类图表的优缺点。为简化问题，我没有为类的所有属性都建模；也没有为其完整签名或任何类方法建模。
图 1. 简单类层次结构的 UML 类示意图
将类映射成表 类到表的映射通常不是直接的。除了非常简单的数据库以外，您不会有类到表的一对一映射。在以下章节中，我将讨论为关系数据库实现继承结构的三种策略：
整个类层次结构使用一个数据实体 每个具体类使用一个数据实体 每个类使用一个数据实体 整个类层次结构使用一个数据实体 使用这种方法，您可以将一个完整类层次结构映射成一个数据实体，而层次结构中所有类的所有属性都存储在这个实体中。图 2 描述了采取这个方法时图 1 的类层次结构的持久模型。请注意，为表的主键引入了一个 personOID 列 - 我在所有解决方案中都使用 OID （没有商业含义的标识，又称替代键），只是为了保持一致和使用我所知道的向数据实体分配键的最好办法。
图 2. 将类层次结构映射成单一数据实体
这种方法的优点是简单，因为所需的所有人员数据都可以在一张表中找到，所以在人们更改角色时支持多态性，并且使用这种方法，专门报告（为一小组用户 特定目的所执行的报告，这些用户通常自己写报告）也非常简单。缺点是每次在类层次结构的任何地方添加一个新属性时都必须将一个新属性添加到表中。这增加了 类层次结构中的耦合 - 如果在添加一个属性时有任何错误，除获得新属性的类的子类外，还可能影响到层次结构中的所有类。它还可能浪费数据库中的许多空间。我还必须添加 objectType 列来表明行代表的是学生、教授还是其它类型的人员。在人们具有单一角色时这种方法很有效，但如果他们有多个角色（例如，一个人既是学生又是教授），很快就会失效。
每个具体类使用一个数据实体 使用这种方法，每个数据实体就既包含属性又包含它所表示的类继承的属性。图 3 描述了采取这个方法时图 1 的类层次结构的持久模型。有与 Student 类对应的和与 Professor 类对应的数据实体，因为它们是具体类，但没有与 Person 类对应的数据实体，因为它是抽象类（它的名称以斜体字表示）。为每个数据实体都分别分配了自己的主键， studentOID 和 professorOID。 图 3. 将每个具体类映射成单个数据实体 这种方法最大的好处是，它仍然能相当容易地执行专门报告，只要您所需的有关单一类的所有数据都只存储在一张表中。但也有几个缺点。一个是当修改类时，必须修改它的表和它所有子类的表。例如，如果要向 Person 类添加高度和重量，就需要同时更新两个表，它会涉及很多工作。第二，无论何时，只要对象更改了它的角色 - 可能您聘用了您一个刚毕业的学生作为教授 - 则需要将数据复制到相应的表中，并为它指定一个新的 OID。这又涉及到很多工作。第三，很难在支持多个角色的同时仍维护数据完整性。（这种情况是可能的；只是比原先困难一点。）例如，您会在哪里存储既是学 生又是教授的人的姓名呢？
每个类使用一个数据实体 使用这种方法，为每个类创建一张表，它的属性是 OID 和特定于该类的属性。图 4 描述了采取这个方法时图 1 的类层次结构的持久模型。 请注意，将 personOID 用作了所有三个数据实体的主键。图 4 的一个有趣的特性是，为 Professor 和 Student 中的 personOID 列都分配了两个构造型，而这在标准建模语言 (UML) 中是不允许的。我的意见是，这是一个必须由 UML 持久性建模概要解决的问题，甚至可能在这个建模规则中也需要更改。（有关持久性模型的详细信息，请参阅参考资料中的 "Towards a UML Profile for a Relational Persistence Model"。）
图 4. 将每个类映射成它自己的数据实体 这种方法的最大好处就是它能够最好地适应面向对象的概念。它能够很好地支持多态性，对于对象可能有的每个角色，只需要在相应的表中保存记录。修改超 类和添加新的子类也非常容易，因为您只需要修改或添加一张表。这种方法也有几个缺点。第一，数据库中有大量的表 -- 实际上每类都有一个（加上维护关系的表）。第二，使用这种技术读取和写入数据的时间比较长，因为您必须访问多个表。如果通过将类层次结构中的每个表放入不 同物理磁盘驱动器盘片（假设每个磁盘驱动器磁头都单独操作）上来智能地组织数据库的话，就可以缓解这个问题。第三，有关数据库的专门报告很困难，除非添加 一些视图来模拟所需的表。
比较映射策略 现在，请注意，每个映射策略怎样产生不同的模型。要理解三种策略之间的设计优缺点，请考虑图 5 中显示的对我们的类层次结构做些简单的更改：添加了 TenuredProfessor，这是从 Professor 中继承的。
图 5. 扩展初始类层次结构
图 6 显示了一个更新过的持久性模型，用于将整个类层次结构映射成一个数据实体。尽管很明显，数据库中的空间浪费增加了，但请注意，按照这种策略操作，只需花非常小的代价就可以更新模型。 图 6. 将扩展的层次结构映射成单一数据实体 图 7 显示了将每个具体类映射成数据实体时的持久性模型。使用这个策略，虽然因为我们从教授提升到终身教授，这样对象和我们的关系就有了改变（学生变成教授），所以如何处理对象的这个问题更复杂了，但我只需要添加一个新表。
图 7. 将扩展的层次结构的具体类映射成数据实体
图 8 显示了第三种映射策略的解决方案 -- 将单个类映射成单个数据实体。这需要我添加一个只包括 TenuredProfessor 类的新属性的新表。这种方法的缺点是，要使用新类的实例，它需要好几个数据库访问。 图 8. 将扩展的层次结构的所有类映射成数据实体 要摒弃这样一种观点，即这些办法都不够好；每种办法都有其优缺点。在下面的表 1 中对它们进行比较。
表 1. 比较映射继承的各种办法 考虑因素 每个层次结构一张表 每个具体类一张表 每个类一张表
专门报告 容易 中等 中等/困难
实现的难易程度 容易 中等 困难
数据访问的难易程度 容易 容易 中等/容易
耦合 非常高 高 低
数据访问速度 快 快 中等/快
对多态性的支持 中等 低 高