软件即服务(Sdtware-as-a-8ervioe，简称SaaS)作为一种新型的软件运营模式，具有使用简单、维护方便、价格适中等特点。然而，对于多租户模式下的人力资源管理系统、客户关系管理系统等企业级应用，SaaS系统应当可以针对企业的实际需求进行一定程度的定制。因此，推动SaaS模式广泛应用的要素之一是：可以通过租户的配置和二次开发来满足其个性化的业务需求。

在传统的企业应用中，软件开发者可以根据租户的特定数据需求采用不同的数据层架构方案，保证数据访问的高效性和安全性。在基于Sa,aS的企业应用中，则要面对来自不同租户的业务数据，需要在数据共享和数据隔离方面把握平衡，还需要满足租户的数据结构自定义等更为复杂的问题。

根据数据隔离和数据共享的程度不同，可以采取三种不同的数据层设计方案：独立数据库方案、共享数据库／独立架构方案、共享数据库供享架构方案。在实际的开发过程中，需要分析多种数据库设计方案的特点并选择适当方案以实现SaaS系统高效、安全的运行，并需要在此基础上进一步讨论可行的个性化数据扩展的解决方案。

1 基于关系的数据扩展模型

在传统的信息系统开发和应用过程中，可以根据用户的不同需求对系统进行二次开发和自定义配置。开发人员通过对数据结构的修改和扩展，满足用户在数据层的个性化需求。在多租户的SaaS应用系统中，特别是在采用共享数据库供享架构方案的数据模型中，租户使用的是相同的表、视图、存储过程以及关系等，对数据结构的直接修改或扩展会直接影响所有租户对系统的正常使用。因此，需要SaaS在提供对数据模型扩展的同时，不影响其他租户对数据的使用。

上述问题的常见解决办法是：通过对关系型数据库中已定义关系的修改来实现扩展数据的可配置性，即允许在系统运行时通过适当的操作完成对底层数据模型的扩展。一般通过定制字段、预分配字段、名称值对这三种方案来实现这种可配置性。下面将对这三种数据扩展方案进行分析与比较。

1.1 租户定制字段 定制字段方式根据租户的扩展需求

通过在数据表上增加相应的字段来保存数据，是传统应用中最常见的解决方案。例如在选课系统中，各个学校均要保存自己的课程信息，但是不同学校对于课程属性的定义是不相同的，如表1所示。

表1 定制字段方式扩展数据字段

 

其中TeantID用来标识租户，CourseType和Capadty字段分别是为满足1001和1002租户的数据扩展需求而添加的。1003和1020租户在两个字段的值均为null，即这两个字段对于1003和1020租户来说是没有任何意义的。

从实现的角度看，这是一种很简单的方案，这种方案不需要处理复杂的扩展数据的跟踪。如果SaaS应用采用共享数据库／共享架构方案，因每个租户的数据定义修改都是在共性表结构上进行的，允许用户增加自定义字段将会使得表中大多数字段对于其他用户是没有什么意义的，而且会严重破坏数据表的结构。因此这种方案用来解决SaaS应用中的数据扩展问题是不理想的。

1.2 预分配字段 预分配字段是指在用户有可能扩展字段的表中预设定一定数量的通用字段。当用户需要扩展数据时，使用这些通用字段来保存扩展数据。例如，在选课系统中每个学校对于学生数据有自己的定义，使用通用的预分配字段来描述不同的数据语义，如表2所示。

在表2中，同一表格中混有不同学校学生的记录，TenantID字段将每个记录与相应的学校相关联。表中除了标准的一组字段(StdID，StdName)外，还提供了三个预分配字段Ext1、Ext2、Ext3，每个租户可以决定如何使用这些定制字段，以及如何针对这些定制字段存储数据。与前面的租户定制字段方案相比。这两种方式都是通过在数据表中增加字段来存取扩展数据，但预分配字段方案中预分配的字段是没有固定含义的。对于不同的租户来说，这些字段保存的是不同含义的数据。例如表2中Ext1这个字段对于用户100l保存的是地址，对1002则保存的是电话。

由于不同租户对于扩展数据的数据类型要求是不一样的，这就需要所创建的预分配字段选择一般的数据类型(通常为一定长度的字符串型)，不过租户会觉得这种方法限制性过强。另外，为了在系统运行时更好地利用这些扩展数据，还需要对预分配字段的语义和实际类型单独定义一个配置元数据的数据表，如表3所示。

表2 预分配字段数据表示例

 

有了表3所保存的元数据，在使用租户的扩展数据时，就可以根据当前的租户TenantlD和所在的表Table查询到该租户所使用预分配字段的数据类型及含义。这样就可以将扩展数据转换成相应的数据类型来使用，实现数据的可扩展、可配置。

预分配字段的方案在一定程度上较好地实现了数据的可配置性，是实现用户扩展数据模型的一种简单方式。但是这种方案的局限性也相当明显：预分配字段的个数一般需要在系统设计时就确定，这对于拥有大量租户的SaaS应用来说很困难。设计时必须对表中需要预分配多少字段进行权衡，如果预分配字段设计的太多，就会造成数据表的膨胀，产生很多空闲的无意义字段，造成数据存取空间和性能的浪费；如果预分配字段过少，则无法为用户提供足够灵活的数据扩展，不能满足数据可配置的需求。

1.3 名称值对 名称值对方案将原数据表和扩展表分离，通过单独的扩展表来完成数据扩展。在这种方案中扩展数据表将数据表的横向列扩展转换成纵向的数据集，将原数据表中每一个扩展字段都保存成一条数据记录，并将数据表中的记录与配置元数据表中的配置记录关联，构成扩展数据记录。

 

图1 名称值对表关系图

构造如图1所示的三张数据表，其中etxstom为租户数据表，configtb为配置元数据表，exttb为扩展数据记录表。

当一个租户需要扩展自己的数据时，定义字段名称、字段类型、所扩展的表等重要信息作为记录存储在配置数据表configtb中。当用户需要保存数据记录时，在扩展表exttb中存放包含以下信息的记录：

a．所扩展数据表中的关联记录ID；b．与之关联的配置记录(用来保证存储正确的数据类型和扩展的数据表)；c．用户所保存数据的值。

名称值对这种模式，给扩展数据的实现带来了很大的灵活性，理论上可以提供无限数量的自定义扩展字段。租户可以根据自己的业务需要不断地增减自定义数据，以满足业务需求。当应用程序检索租户记录时，会在扩展表中进行查找，选择与记录ID相对应的所有行，并为所用的每个定制字段返回一个值。为了将这些值与正确的定制字段相关联并将其转换为正确的数据类型，应用会使用扩展表中与每个值关联的配置记录ID来查找该记录的详细配置信息。

名称值对模式在带来灵活性的同时增加了数据操作的复杂性。对数据进行增、删、改时，都需要进行复杂的处理才能实现用户定义的数据结构和实际数据库中所存储数据之间的映射。查询数据时，需要多次访问元数据才能获取完整的业务数据，这些问题都会影响数据访问的性能。

2 基于XML的数据扩展模型

通过将可扩展标记语言(eXtensible Markup Language，简称XML)与关系型数据库的有机结合，可以在满足租户对SoaS数据的扩展需求的同时不改变原有的关系结构。XML文档具有数据语义的自解释性，这就使得对数据的解析变得简单。另外，XML文档的层次性也便于对数据的扩展。

目前，许多关系型数据库产品都增加了XML数据类型，允许通过SQL来访问字段中的XML文档。XML数据类型可用于创建表、列或视图，还可用作参数和变量的数据类型。使用XML数据类型可以在应用程序和关系型数据模型之间提供一个隔离层，该层允许数据以非关系的模型进行操作，而不局限于CLOB或关系模型。

在基于关系的扩展模型中，对数据的扩展都需要增加多个表或在表中增加多个字段，而基于XML的扩展模型只需要对XML字段进行扩展就可以灵活的满足要求，如图2所示。由于基于XML类型的数据字段的存在，字段数量扩展没有限制，字段类型也没有限制，而且修改时无需停机处理。因此，基于XML的数据类型，可以灵活方便地应对不同租户的数据扩展需求。

 

图2 基于XML的数据字段扩展

以Oracle数据库环境为例，具体的实现可以通过关系表中的XML数据类型来实现数据扩展。可以看出，基于XML的数据扩展模型相比名称值对等基于关系的数据扩展模型而言拥有更大的灵活性。选择XML类型的字段来存储用户自定义数据，对扩展数据的数量和类型都没有限制。由于关系型数据库对XML和关系模式的映射和相应存取操作已有较好的支持，因此可以借助这种扩展模型来实现SaaS应用中通用数据表和自定义数据的集成。

3 小结

选择合理的数据库设计方案是构建SaaS应用的关键因素。通过对多种方案进行比较，本文认为采用共享数据库／共享架构的数据模型来处理租户数据的需求符合SaaS模式的设计初衷。在此基础上，定制字段、预分配字段、名称值对这三种基于关系的扩展模型都具有可行性，但都需要对数据库中的关系进行结构性的修改，进而增加了系统实现和维护的难度。基于XML的数据扩展模型在不牺牲通用关系操作的简便和高效的前提下，以非常灵活的方式实现租户数据的扩展性和可配置性，并能与成熟的数据定义、查询和更新操作进行集成，是实现SaaS数据扩展的较好的方法。