SSO功能实现中的数据整合方案初探

摘要：SSO（Single Sign On）是并购整合后期的技术整合中必须要实现的一个功能，而通常不能直接将并购者的用户数据与被并购者的用户数据直接合并，本文着重分析了在实现SSO数据整合中可能存在的问题，并针对各个问题给出了初步的解决方案。

关键词：SSO；；去重

中图分类号：TP391.1 文献标识码：A文章编号：1007-9599 (2011) 10-0000-02

Data Integration Solutions Study in Function Implementation

Sun Chao

(Beijing Wo Wo Group Information Technology Co.,Ltd.,Beijing100080,China)

Abstract:SSO(Single Sign On)is a function which be must implemented in post-merger integration of technology integration process,but usually the bought users'data can not be merged directly with original users'data,so this article focuses on analysis of the problems which may exists in during data integration in achieving SSO and offer a elemental solution.

Keywords:SSO;Finding duplicate;Removing duplicate

一、前言

对于实施并购行为的互联网企业，如何将收购得来的用户相关的各项数据进行有效整合便成为并购后期的技术整合阶段的一个重要环节，也是后续各项整合的基础。如果在用户整合过程中要求收购网站（以下简称为分站）的用户必须重新在收购者的网站（以下简称为主站）上进行注册才可以使用主站的各项会员功能，将会大大降低用户的使用体验，并且在这一过程可能会导致用户的流失，这样并购的效果就会打折扣。因而用户整合的基本目标是：分站用户能够无需注册即可登录主站并能使用各项会员功能。这中情况在IT中被称之为SSO（Single sign on）问题。本文着重分析了实现SSO中的数据整合中可能存在的问题并给出了相应的解决方案。

二、SSO数据整合中可能会遇到的问题

要实现SSO登录，前提就是对分站的用户数据进行整合，以使得程序在登录验证时能够查到相应的数据，对于现在的企业而言，各种各样的数据都是用RDBMS进行存储，用户的数据也不会例外。在数据整合方面的可能存在的问题有下面几个：

（一）数据库系统不同，现在企业中常用的RDBMS中有My SQL，SQL Server，Oracle，DB2，由于数据库系统众多，主站和分站所使用的数据库系统可能会有所不同，即使是数据库相同也会存在版本不同的问题。

（二）即使当主站和分站使用的数据库相同，版本也相同，在主站和分站用户数据间可能会存在下述问题：

1.同一个信息用不同的类型进行存储。如注册时间、登录时间字段，在主站可能会用int类型进行存储，而在分站中可能会用datetime类型来表示，因而在进行整合时必须加以转化。再如手机号码，可以用int类型进行存储，也可以用字符串类型进行存储。

2.字段类型相同但长度或精度不同。比如对于地址字段，在分站相关表中长度可能是255个字符，而在主站的对应表则是100个字符。对于数字类型的字段则有可能存在精度要求的不同。

3.不同的字段名表示相同的含义。在软件开发中不同的企业有不同开发规范，在字段命名上也会有不同的规范和要求，这样就可能会导致主站和分站用不同的字段名表示同一个属性，增加了数据整合中的分析工作。

（三）登录名重复现在的网站在登录时通常会采用用户名邮箱作为登录名来进行登录，甚至有些网站（如支付宝）还采用手机号作为登录名。主站和分站的登录名（用户名、邮箱、手机号）有可能存在重复的问题，如果在实施SSO前没有解决重复问题，则在用户登录时程序可能无法进行正常的登录验证，导致用户无法登录或者登录后看到的却是其他用户的信息。

（四）无效数据和脏数据通常每一个网站都会有一定数量的“死”用户。这些用户在注册后就没有再登录过或者由于其他的原因这些用户已经遗忘了。另外在测试和运营过程中可能会引入一些脏数据。

三、问题分析

前两个问题说明无法直接将分站的用户数据直接导入到主站的用户表中，必须做一定的类型转换和调整才可以。

登录名重复的问题则要求在实施用户数据整合时必须对重复的登录名进行适当的调整，确保登录名的唯一，以保证登录验证机制的正常运行。

无效用户和脏数据的存在使得即使在前面两个问题解决后也不能直接将用户的数据导入到主站的数据库中，因为这样将会引入冗余数据进而可能会引起效率问题，也不利用之后的重构工作。

四、解决方案

在软件开发中加一层便可以解决很多问题，在这里我们也给数据加一个层：SSO数据层。即创建一个SSO库作为主站数据库和分站数据库的中间层。基本思路如下：

（一）在SSO数据库创建用户数据表，该表包括各分站用户表中所用到所有字段，也就是各分站用户表的字段是SSO库中用户表字段的子集，并且各个字段的长度和精度均设为最大。以my sql数据库为例，字符串设为255长度，数字类型设为bigint。将各分站的用户数据全部导入到SSO库中。

（二）对向SSO库中导入的分站用户数据进行操作，导入后对重复的登录名加前缀的方式进行修改，保证登录名唯一。

（三）调整主站的登录验证机制在登录验证时先查询主站数据库，若在主站数据库上验证不成功，再到SSO库中进行验证，验证成功后通过代码将SSO库中的用户数据转换成符合主站数据库要求的数据转存放到主站的用户表中，同时删除从SSO库将该用户的相关数据删除，这样确保不会引入脏数据到主站的数据库中。

五、登录名重复问题解决方案

在上述方案中第一步在确定SSO库用户表和分站用户表字段对应关系后只是简单的导入工作，而第三步主要是代码的实现，不属于数据整合的范畴，因而在这里着重描述如何解决登录名重复的问题。

一个网站的用户少则几千，多则数万，数十万，甚至更多。如果通过人工的方法去修重不仅效率非常低并且很容易留下纰漏。因而在去重时主要是利用数据库系统自身拥有的功能来进行和去重。

该方案有以下约定：

1.所使用的数据库为my sql。

2.通过添加前缀的方式进行去重操作，为方便修改登录名的用户进行输入前缀尽可能的短并且容易记忆，这里我们用“fz_”作为前缀，如果有多个分站则在后面加数字，如“fz2_”等。

3.为了区分主站及各分站我们在时给对应的数据加一个列：site-id（整形），用1表示主站，2表示分站，依次递增。

4.一次去重即可实现登录名的唯一。

5.假设主站和分站只用用户名作为登录名进行登录。

具体操作如下：

（1）创建数据库（chachong-for-user）并创建下列表

Cha-chong（表）主要用于存放主站及各个分站的登录用的用户名，在这个表中为了加快的速度我们在username字段上创建了索引。另外添加了字段notify-username-modify，用来表示用户名是否做了调整，这个字段的默认值均为0，表示不调整，如果做了调整就设为1.另外site-id用来表示区分主站和分站，如果有多个分站，其值可以递增。Orginal-id用来存放该用户在其原始数据表中的id。

Tem-username（重复用户名表），用于存放重复的用户名，为了加快的速度我们在username字段上创建了索引。

（2）操作流程

1）导入数据，将主站和分站的用户名及original_id导入到cha_chong表中，同时假设主站的site_id为1，分站的site_id为2。

2），利用数据库系统的group功能将分别对用户名和邮箱进行分组，并且将每个分组内条数大于1的用户名存放到对应的表中。对应的sql如下：

insert into tem_username（username） select username from`cha_chong`group by username having count（username）>1。

3）修重，修重采用在原有用户名前加前缀的方式实现，对应的sql如下：

update cha_chong cc inner join tem_username tu on cc.username=tu.username set cc.username=concat（"fz_"，cc.username），cc.notify_username_modify=1 where cc.site_id=2。

4）改重，为了加快改重速度，避免跨库查询，将修改了的用户名的数据放到SSO库中的一个临时表中。表结构和tem_username相同。

通过下面的sql将数据导入到SSO库中临时表中：

insert into tem_data（username，original_id）select username，original_id from chachong_for_user.cha_chong where site_id=2 and notify_username_modify=1；

然后进行替换

update SSO_users su inner join tem_data td on su.original_id=td.original_id set su.username=td.username，su.notify_username_modify=1 where site_id=2。

5）至此SSO库已建立完毕，而后可通过判断notify_username_modify是否为1来确定该用户的用户名是否做过调整，来给其发送邮件和短信告知用户用新的用户名进行登录。

六、结论

事实上，在真实环境中SSO的数据整合要比本文描述的要许多，有些问题并没有涉及到，例如：

（一）如果主站中字符型字段的长度没有分站中对应的字段长度长，或者精度不一致，则需要对主站的数据库相关表的结构进行调整。

（二）如果主站和分站所使用的数据库不同，那么在进行数据的导入导出时则要针对不同的情况做出相应的调整。

（三）密码加密问题通常在数据库中存储的用户密码都是进行加密过的，因而在实现SSO时必须了解各个分站的加密规则并对登录验证的相关代码做出调整，否则用户也不能成功登录。

因而这里给出的方案只是给出一个解决思路，提出一个简单的设计实现方案，在实际的环境需要做适当的调整。

参考文献：

[1]比利,张伟超,林青松.SQL学习指南(第2版)[M].人民邮电出版社,2010

[2]西尔伯沙茨,杨冬青.数据库系统概念(原书第5版)[M].2006