鸡啄米

　　1 引言

　　SaaS(Software-as-a-Service，软件即服务)作为一种新型软件服务模式，它通过Internet进行软件交付，具有软件部署为托管服务，通过因特网存取，付费即用、多租户等特点。随着互联网技术的发展和应用软件的成熟，SaaS正在全球兴起，特别是受国际金融危机影响，尤其是实力弱小的中小企业受到极为严峻的考验。如何提升中小企业的竞争力，帮助中小企业规避全球金融危机的影响，获得可持续的健康发展，是中小企业要考虑的问题。而在我国医药连锁行业绝大部分中小型企业，在信息化进程中表现较慢，原因很多，诸如企业规模小、资金缺乏、IT人才匾乏等等。面对这样的现状，SaaS的出现彻底改变了人们对软件的观念，使用软件的人从产品消费者转换为服务消费者，而开发软件的人从产品提供者转换为服务提供者。在国外，有关SaaS的概念正在渗透到软件应用的各个方面，甚至开始成为主流。

　　一套传统模式的医药GSP管理平台，较好地实现了客户的要求，但是随着不同客户需求逐渐个性化，需要不断地维护代码，所以，如何设计出更好的系统，来解决软件开发出现这样的问题，SaaS模式是个不错的选择。通过医药GSP的业务为切入点，探究SaaS式在数据扩展性方面是如何设计和具体实现的。

　　2 系统架构分析与设计

　　2.1 GSP医药管理系统的模块划分

　　GSP医药管理平台业务流程图简单表述如图1，而如何设计出可以扩展的数据实体，从而实现不同用户对图1业务的个性化需求，是研究的重点。

图1 GSP医药管理平台模块划分图

　　2.2 SaaS应用程序架构模型

　　一个基本的SaaS模式的应用程序架构模型如图2，在GSP医药管理平台中，在应用底层是一个单实例、多用户的数据模型，采用Name Pair-Value的方式进行基于元数据概念的数据存储。在应用层，采用了多种微软的新技术来进行设计，采用Windows Communication Foundation进行基于通讯和数据安全的处理；在界面设计方面利用了ASP.NET 2.0中的Web Parts和Themes等技术提供了灵活的设置和相对丰富的用户体验。

图2 SaaS应用程序架构模型

　　在图2中，对于用户数据扩展性方面的解决方案是采用集中式元数据库和共享数据库两个物理数据库来存储数据。元数据库存储的是元数据最基本的属性，包括表名、字段名称、字段类型、字段长度，字段标题等属性；共享数据库存储的是用户共享的数据实体，也包括了用户自定义的数据实体的值。

　　2.3 数据存储模型选择

　　对应数据的隔离和共享程度的不同，有如下3种方案可供选择：

　　1)每个租户独立一个数据库

　　这个方案的优点是不同租户的数据物理分离，安全性比较好。它的缺点是数据库连接的利用效率不高，性能问题会很大。将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。

　　系统将借由元数据(Metadata)来记录哪一个数据库属于哪一个特定客户，与此同时也可以部署一定的数据库访问策略来确保即使系统处于异常状况下，客户数据也不会被其它客户意外访问到。但是，这种数据模型的最大问题是对应的部署和维护成本非常高，硬件资源的消耗将明显高于其它两种方案，一台服务器将只能支持有限数量的客户。

　　2)所有租户使用同一数据库，使用不同模式

　　这种客户独立模式的方式相对比较容易实现，而且从数据扩展性而言，这种解决方案和独立数据库一样，客户可以相对自由地对其中的数据结构进行新增和修改。这种客户独立模式的方式比较适合应用在每个客户拥有比较少的表数量的情况下，比如每个客户只有100张表或更少。这种方式毫无疑问可以在每台服务器上支持比独立数据库方式更多的客户数量，减低了服务供应商的运营成本。

　　3)所有租户使用同一数据库，共享模式

　　第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录，由一个客户ID字段来确认哪条记录是属于哪个客户的。这种共享模式的方式具有最低的硬件成本和维护成本，而且每台服务器可以支持最大数量的客户。但是由于所有客户使用同一套数据表，因此可能需要在保证数据安全性上花费更多额外的开发成本，以确保一个客户永远不会因系统异常而访问到其它客户的数据。

表1 三种存储模式的比较

　　在所有这三种数据模型中，综合比较见表1，从业务的角度，因为GSP医药管理平台要求要比较容易推广，要有价格优势，权衡比较，采用了第三种方案，即同一数据库、共享数据架构。

　　3 数据模型详细分析与设计

　　3.1 数据库设计

　　数据实体的定义见图3，对于元数据的构造，主要有上面三个表来完成，数据模型由实体预定义元数据，实体实例数据，和租户扩展元数据组成。元数据由DataNodes和DataProperties表组成，而对于租户扩展元数据。则存储在ExtentionValues表里面。DataNodes和DataProperties构成了数据字典，DataNodes通过ParentId连接成一棵树，DataProperties用来描述DataNodes的属性，实体和字段的定义都对应到DataNodes。NodeType用来区分DataNodes是用来描述实体还是实体的字段。每个DataNodes的行都有TenantId，TenantId为NULL代表系统预定义的元数据。Tenantld不为NULL代表是用户扩展的元数据。同样，在DataProperties表格中，TenantId为NULL，代表系统预定义的节点属性，TenantId不为NULL代表某个Tenant扩展的结点属性。

图3 元数据驱动的表设计

　　在系统中，我们用到了两种NodeType：Entity和Entity Field。NodeType为0表示是表，NodeType为1代表表字段，2代表存储过程，3代表视图。

表2 DataNodes(元数据结点表)

表3 DataProperties(元数据结点属性表)

表4 ExtensionValues(扩展字段值表)

　　3.2 自定义数据的动态查询

　　在GSP医药管理平台中，表是通过元数据的描述信息生成动态的SQL脚本而获取的。表字段元数据中包含了字段的名称和数据库表格中的列名。假设Purchaseorder表有一个用户自定义扩展字段Summary，则编写脚本及其查询结果如图4所示。

图4 自定义数据的动态查询

　　4 结语

　　详细阐述了实现SaaS模式的数据实体扩展性，以GSP医药管理平台为实例，以SaaS应用架构模型为基础，结合GSP医药管理平台的行业特点，对几种数据存储方式进行了比较分析，给出了详细的数据库设计，最后针对该设计进行详细的编码，并给出了最终的实现结果，这对于如何具体实现基于SaaS模式的软件下数据实体的扩展性，做了有意义的探讨，有较强的商业价值。