基于vb的数据筛选系统设计终稿本科论文.docx
《基于vb的数据筛选系统设计终稿本科论文.docx》由会员分享，可在线阅读，更多相关《基于vb的数据筛选系统设计终稿本科论文.docx（31页珍藏版）》请在冰点文库上搜索。
基于vb的数据筛选系统设计终稿本科论文
基于JAVA的邮件收发系统的设计
摘要
《WISE系统》是一个功能强大的数据处理系统。
它应用于某公司，此公司由于行业的关系需要它去处理庞大的数据，这些数据每天都在以上百万条甚至上亿条的数量在增加。
因此它需要处理海量的数据，它的其中一个比较重要的功能是根据复杂并且灵活的条件筛选出适当的数据返回给客户。
本论文主要讲述了如何针对数据筛选条件比较复杂并且比较灵活这一需求，在做了详尽的需求分析之后，进行了一系列的设计，包括解决方案的设计，数据建模，PL/SQL程序设计，最终完成整个数据筛选接口的设计。
在整个数据筛选接口的设计中，在传统的关系性数据库的基础上，会尝试着应用一些面向对象的思想去设计。
尤其在数据建模阶段,通过传统的数据模型之间的关系,例如主外键关系,实现了一些重要的面向对象的思想。
关键字：
数据筛选；面向对象；数据建模；PL/SQL
ImplementtheObjectOrientedthinkingintheprojecttodatamodeling
——thedesignabouttheAPItofilterdata
Abstract
《TheWISEsystem》isapowerfulsystemfordataprocessing.Itisappliedinacompanywhichneedstousethissystemtoprocesshugeamountdata.Andthesedatawillbeincreasedbymillionsorhundredsmillions.Soitneedstoprocessthehugeamountdata.Oneofitsimportantfunctionisreturntherightdatatoclientfilteredbysomecomplexandflexibleconditions.Themostcontentofthepapertalksabouthowtofinishthetotaldesignfortherequirementwhichistheconditionstofilterdatacanbecomplexandflexible.Theentiredesignwillincludethedesignofprojecttosolveproblem,thedesignaboutdatamodeling,andthedesignaboutPL/SQLprogram.Finallythealldesignstoimplementtheinterfaceforfilteringthedataarefinished.Wewilltryimplementingtheobjectorientedthinkingtodesignonthebaseoftherelationaldatabaseintheprocesstofinishallthedesign.Especiallyintheprocesstoimplementdatamodeling,wewillimplementsomeimportantobjectorientedthinkingbysomerelationsamongtraditionaldatamodels,suchasPKorFKrelationship.
Keywords:
datafiltration；objectoriented；datamodeling；PL/SQL
目录
论文总页数：
24页
1引言1
2开发概述1
3需求分析1
3．1需求调研1
3．2开发运行环境3
4解决方案的设计3
5数据建模8
5.1数据模型的建立8
5.2数据库表结构的设计9
5.3数据库基础视图的设计11
6PL/SQL程序设计12
结论22
参考文献22
1引言
当今社会，某些行业的数据量越来越庞大，每天都在以上百万条甚至上亿条的数量在增加，因此对这些行业的数据处理系统的性能要求也越来越高。
这些要求不但包括处理速度尽可能快，系统可维护性尽可能高等传统需求，而且增加了对数据的处理尽可能的灵活等一些新的需求。
要满足这些新的需求，我们需要研究这些新需求的特性，挖掘一些解决办法。
面向对象的数据建模是我们研究的一个重要方向。
引用言论：
SteveHoberman所提出的“抽象组件”的概念和面向对象设计中的“设计模式”非常类似。
即数据库专家在多次的数据建模后，将各个项目中的类似部分抽象化，提取出特定的建模模型片段，以后只需在新的项目中对这些模型片段细化派生，即可快速构建出适合于该项目的数据库架构。
2开发概述
《WISE系统》是一个功能强大的数据处理系统。
由于业务的关系，它需要处理海量的数据，它的比较重要的一个功能是根据复杂并且灵活的条件筛选出适当的数据返回给客户。
针对这一数据筛选功能，开发的目标是设计一个合理的数据筛选接口。
接口能做到便于动态控制，便于动态修改，以及便于维护。
开发的过程包括需求分析，解决方案的设计，数据建模，PL/SQL程序设计，最终完成整个数据筛选接口的设计。
3需求分析
3．1需求调研
WISE系统是某公司的数据处理系统，它的一个主要功能是每天根据复杂并且灵活的条件筛选出适当的数据返回给客户。
所筛选的数据都来自于一张表，这张表的字段有260个，这些字段中有超过250个字段需要作为筛选字段，它们通常互为组合去筛选出客户需要的数据，根据客户的需要它们的组合又是多变的。
这张表的数据量通常在一千万到一亿条记录之间。
值得注意的是，筛选条件需要去匹配的值是具有特定意义的，尽管这些值数目众多，但它们的数量不是随意增长的。
而且这些值是根据客户的需求可以去定制的。
表1复杂表Complexity
字段名
数据类型
说明
C_ID
数字
主键
C_U1
文本
C_U2
文本
C_U13
文本
C_U4
货币
C_U5
数字
C_U6
货币
C_U7
文本
C_U8
货币
C_U9
文本
C_U10
货币
C_U11
文本
C_U12
文本
C_U13
日期/时间
C_U14
日期/时间
C_U15
数字
C_U16
数字
C_U17
文本
C_U18
文本
C_U19
文本
C_U20
货币
C_U21
数字
C_U22
货币
C_U23
文本
C_U24
货币
C_U25
文本
等等
一共260个字段
因此对数据筛选的需求特点主要有：
图1需求特点分析图
数据量庞大在这里不是本次设计的研究重点，后三个特点是本次设计要解决好的需求。
3．2开发运行环境
开发所需的基本软、硬件环境为：
●Windows2003或者WindowsXP。
●Oracle10gR2。
●CPU2.40GHz
●1G以上内存。
●2G以上可用硬盘空间。
在Windows2003操作系统下，以ToadforOracleXpertv9.0.1.8为开发工具，用Oracle10gR2为后台数据库。
4解决方案的设计
在这里来逐步分析需求应该通过怎样的方式来实现，进行一些解决方案的设计。
方案1：
直接写过程来实现。
根据不同的筛选条件，写不同的过程来实现数据筛选。
问题：
很显然，这种方案是行不通的。
由于筛选字段数量达两百多个，而且相互之间可以互为组合，所以是不应该写过程来实现的。
即便把目前需求要求的筛选条件通过写过程来实现了（暂不考虑开发人员的头疼），如果需要添加一些新的筛选，那将是非常麻烦的。
再则，如果所写过程中出现一些问题，也是难以维护的。
所以考虑到开发的质量与代码的可维护性，是不可能采用此方案的。
方案2：
结合数据建模与程序设计来实现。
由于筛选条件数量众多，但是条件之间的很多部分相互重合，从面向对象的角度出发，这些条件间存在继承的关系，如果能采用面向对象的方法，或许能做到重用条件。
假设一共有250个独立的筛选条件，也即表中的250个字段单独作为条件时的情况。
这些条件能相互组合，组合后的条件越发复杂，写程序时如果按照方案1要想做到很好的代码重用是不可能实现的。
所以根据方案1的失败，要想很好的做到代码重用，就很有必要引入面向对象的思想，采用继承的方法，做到条件组合，就好像类与类之间的继承。
作为表中列名出现的字段，是不可能相互组合的。
但是换个角度，大胆的设想，如果把这些字段不作为列名，能不能做到相互组合呢？
如果把这些字段转换成变量，对变量一一赋值，和作为字段相比并没有做到很大的改善。
如果把这些字段转换成表中的记录值呢？
试想一下，似乎看到一线光明，因为在PL/SQL里，可以用到动态SQL的方法，这样可以所需要的条件动态的组合了。
但是能不能真正达到便于动态控制，便于动态修改，以及便于维护呢？
我们需要一步一步去研究，以及测试。
根据目前得出的结论，我们现在需要一个表，表中的某一列的记录值为Complexity表中作为筛选条件的列名，如下表2所示：
表2FIELD
字段名
数据类型
说明
ID
数字
主键
NAME
文本
COLUMN_NAME
文本
列名
FIELD表中的COLUMN_NAME列存放Complexity表中作为筛选条件的列名。
这样就可以做到把条件一步一步‘拼起来’了。
接着往下分析。
需要选取出可能作为筛选条件的列名C_U1、C_U2、C_U3、C_U4四个字段，以后的分析将会以它们作为例子。
这里把每个单独的列名作为筛选条件的条件叫做简单条件，而多个简单条件组合而成的条件叫做复杂条件。
值得注意的是，筛选条件中有相当一部分是类似于‘C_U1IN（A,B,C,D）’的，它也是简单条件，但是比较特殊一点，这样的条件把它叫做简单序列条件。
假设现在客户Ted需要的数据是以C_U1>A和C_U2A和C_U2现在可以得到一个结论：
两个简单条件间的关系只有两种，AND和OR。
也就是说不论一个复杂条件是由多少个简单条件组合而成，这些简单条件间的关系只有两种。
这是一个有趣的结论。
现在就可以做到把一个个简单条件通过两种关系的一种‘拼装’起来，组合而成一个个复杂条件。
而对于多个组成部分有着重复简单条件的复杂条件，它们可以说是相互继承的，这样就从功能逻辑上做到了继承与组合。
图2条件间逻辑关系图
通过上图，很容易想到，这里只需要在数据库中创建五个表来来实现这一方式，也就是可以做到需求里的筛选条件间的自由组合这一功能了。
通过建立外键，可以很容易的做到把FIELD里的COLUMN_NAME字段一一映射到简单条件表和序列条件表中，而这两个表通过联接表可以组合成复杂条件存放到复杂条件表中。
图3条件功能组合图一
到此就可以实现需求里的筛选条件间的自由组合这一功能了。
还需要想办法去实现筛选条件需要去匹配的值是具有特定意义的，而且客户可以定制这一需求。
试想一下，如果现在不对这些值不做任何处理，那可以想象开发人员将会固定的把这些有着特定意义的数值写在PL/SQL程序中，这样做是不能做到客户灵活定制的，而且显而易见的是，从安全的角度出发，这样做也是不安全的。
为了能灵活控制，能按照客户的需求进行规范的定制，这些数值也必须是‘拼装’起来的。
所以必须要把这些数值存放到表中去。
对于简单条件，只需要把需要匹配的数值存放在简单条件表的VALUE字段中就可以了。
对于序列条件，则不能这样，因为它需要去匹配的是，是否存在于某一范围的数值当中，例如判断‘C_U1IN（A,B,C,D）’是否成立。
而这些数值（A或者B或者C等）是具有特定意义的。
所以为了能把这些数值‘拼装’起来，这些数值就需要独立的存放在一张表中。
那就需要再创建一张表LIST_CONDITION_MATCH_VALUE。
现在需要创建的表的框架如下：
图4条件功能组合图二
到此，对于复杂表中作为筛选条件的字段比较多（大约250个），且相互组合，而筛选条件需要去匹配的值是具有特定意义的，且可以根据客户的需要进行定制这一基本需求，我们也基本做到了动态控制，动态修改，并且便于维护。
现在要产生一个复杂的筛选条件，就可以通过写PL/SQL程序来从相关表中读取出来需要的值，再‘拼装’起来就可以了。
但是有一个问题，假设通过写程序来产生了非常多的筛选条件，某一天，客户需要再增加一系列数量众多的筛选条件，会发生什么呢？
那就会花大量的时间去写代码。
尽管目前的设计已经做到了条件的动态组合化，匹配的数值也可以做到动态组合化，但是开发人员需要写的代码有绝大数将是架构类似的。
换句话说，这样的设计会花了大量的时间在做类似的事情上。
很明显，做到的灵活控制，还不够灵活。
问题在哪儿呢？
分析一下，对于简单条件，比如‘C_U1>A’或者‘C_U2=B’，筛选列和匹配的数值我们都可以在相关表中取到，而筛选列和匹配的数值之间的关系，例如大于，小于，等于，时间从某时间开始，这些关系是我们在写代码的时候一直在重复的写的。
而正是因为这个原因，代码不能做到代码间的继承和重用，这是一个失败指出。
要是通过接口设计能把这些关系像处理筛选列与匹配的数值一样处理，这个问题也就解决了。
能做到么？
答案是肯定的。
因为这些关系也就只有数种，例如数字间的比较，时间数值之间的比较，诸如此类的关系是可以得到有效控制的。
对于序列条件，只有两种关系，即是否‘IN’，很显然也可以得到有效的控制。
通过以上的分析，现在只需要再加一个表就可以了，这张表用来存放简单条件的筛选列与匹配的数值之间的关系种类，而对于序列条件，就不用，在程序里很容易做到动态处理。
为了不占据篇幅，数据筛选接口的完整数据库架构会在后面的数据建模部分中一并出现。
5数据建模
5.1数据模型的建立
根据解决方案的设计，画出数据筛选接口的完整数据库架构，如后页图所示：
图5数据库架构图
5.2数据库表结构的设计
5.3数据库基础视图的设计
通过之前的分析，我发现数据库中的八个表之间关联比较多，应该把通常发生关联的表封装起来，视图正是实现这个‘封装’的最佳选择。
需要创建四个视图，分别为简单条件视图，序列条件视图，组合条件视图，以及条件视图。
通过这四个视图可以把简单条件，序列条件，以及组合条件和FIELD表很好的封装起来。
为了避免占据过多篇幅，这里只以序列条件视图和组合条件视图为例。
序列条件视图：
CREATEORREPLACEVIEWV_LIST_CONDITION
（FIELD_NAME,COLUMN_NAME,FIELD_TYPE_NAME,FIELD_TYPE_CODE,FIELD_TABLE_TYPE_NAME,
FIELD_TABLE_TYPE_CODE,NEGATED,ITEM_COUNT,ID,FIELD_ID,
FIELD_TYPE_ID,CONTAINER_ID）
AS
select
F.NameasField_Name,
F.Column_Name,
IC.Negated,
（selectcount（*）
fromList_Cond_Match_ValueLCMV
where（LCMV.List_Condition_ID=LC.ID））asI_Count,
LC.ID,
F.IDasField_ID,
F.Type_IDasField_Type_ID,
IC.Container_ID
fromList_ConditionLC
leftouterjoinConditionC
on（C.ID=LC.ID）
leftouterjoinFieldF
on（F.ID=LC.Field_ID）
/
组合条件视图：
CREATEORREPLACEVIEWV_COMPOUND_CONDITION
（NEGATED,CONJUNCTION_NAME,CONJUNCTION_CODE,CONDITION_COUNT,ID,
CONTAINER_ID,CONJUNCTION_ID）
AS
select
IC.Negated,
C.NameasConjunction_Name,
C.CodeasConjunction_Code,
（selectcount（*）
fromConditionChildCondition
where（ChildCondition.Container_ID=CIC.ID））asCondition_Count,
CC.ID,
IC.Container_ID,
CC.Conjunction_ID
fromCompound_ConditionCC
leftouterjoinConditionIC
on（IC.ID=CC.ID）
leftouterjoinConjunctionC
on（C.ID=CC.Conjunction_ID）
/
这样就通过创建视图，把简单条件，序列条件，以及组合条件和FIELD表很好的封装起来了。
到此，数据建模完成。
6PL/SQL程序设计
现在进行本接口设计的PL/SQL程序设计部分。
从客户出发，这里来整理一下思路。
当客户提出一系列筛选条件的要求时，开发人员首先需要把这些基本的简单条件和匹配的数值，以及相关的记录值，一一插入相关的表中。
开发人员可以用写一系列的过程来实现，通过传入必需的参数来调用相关的过程，插入一些数值。
从下到上，首先要对表直接进行操作，需要一系列最基本的用来实现把数值插入表的过程。
以简单条件为例：
procedureIns_Simple_Condition（
p_calling_user_idinteger,--Required
p_namevarchar2:
=null,
p_negatednumber:
=0,--Required
p_container_idinteger:
=null,
p_field_idinteger,--Required
p_valuevarchar2:
=null,
p_enum_value_idinteger:
=null,
p_comparison_field_idinteger:
=null,
p_operator_idinteger,--Required
p_new_row_idoutinteger）is
begin
--省略部分代码
Ins_Condition（
p_calling_user_id,
p_name,
p_negated,
p_container_id,
p_new_row_id）;
insertintoSimple_Condition（
ID,
Field_ID,
Value,
Enum_Value_ID,
Comparison_Field_ID,
Operator_ID）
values（
p_new_row_id,
p_field_id,
p_value,
p_enum_value_id,
p_comparison_field_id,
p_operator_id）;
--省略部分代码
end;
然后，需要在这些基础过程之上，写一些调用这些基础过程的过程，也以简单条件为例：
procedureAdd_Simple_Condition（
p_calling_user_idinteger,--Required
p_app_idinteger,
p_table_type_codevarchar2,--Required
p_namevarchar2:
=null,
p_negatednumber:
=0,
p_container_idinteger:
=null,
p_field_namevarchar2,--Required
p_valuevarchar2:
=null,
p_value_datedate:
=null,
p_comparison_field_namevarchar2:
=null,
p_operator_codevarchar2,--Required
p_new_row_idoutinteger）is
--
l_field_idinteger;
l_field_type_codevarchar2（100）;
l_comparison_field_idinteger;
l_comparison_field_type_codevarchar2（100）;
l_operator_codevarchar2（100）;
l_operator_idinteger;
l_valuevarchar2（1000）;
begin
--省略部分代码
selectID,Code
intol_operator_id,l_operator_code
fromCondition_Operator
where（lower（Code）=lower（p_operator_code））;
--省略部分代码
Ins_Simple_Condition（
p_calling_user_id=>p_calling_user_id,
p_name=>p_name,
p_negated=>p_negated,
p_container_id=>p_container_id,
p_field_id=>l_field_id,
p_value=>l_value,
p_comparison_field_id=>l_comparison_field_id,
p_operator_id=>l_operator_id,
p_new_row_id=>p_new_row_id）;
--省略部分代码
end;
现在就可以创建一些比较复杂的组合条件了。
为了不占据篇幅，这里只以一个简单的复合条件为例：
--Firstcompoundcondition
（NO_NOTICEIN（B,C,D）ANDMSG_DELINQ_DAYS>90ANDDO_NOT_PROCESS=9ANDCLIENT_ID=116）
declare
l_calling_user_idinteger;
l_dps_appl_id
升级会员 