CN100501734C - 实体属性数据处理装置及方法 - Google Patents
实体属性数据处理装置及方法 Download PDFInfo
- Publication number
- CN100501734C CN100501734C CNB2006100666910A CN200610066691A CN100501734C CN 100501734 C CN100501734 C CN 100501734C CN B2006100666910 A CNB2006100666910 A CN B2006100666910A CN 200610066691 A CN200610066691 A CN 200610066691A CN 100501734 C CN100501734 C CN 100501734C
- Authority
- CN
- China
- Prior art keywords
- entity
- entity attribute
- attribute
- database
- type
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
本发明公开了一种实体属性数据处理装置和方法,其中该装置包括:实体属性定义模块,用于保存并管理实体属性定义表,实体属性定义表用于保存实体属性的定义、类别及与类别对应的保存方式;第一实体属性保存模块,以数据库横表方式保存类别为第一类实体属性的实体属性数据;第二实体属性保存模块以数据库纵表方式保存类别为第二类实体属性的实体属性数据;及实体属性查找模块,根据实体属性定义表从实体属性保存模块中查找实体属性值,第一类实体属性是同类型所有实体个体共同拥有,第二类实体属性是仅被同类型部分实体个体拥有。本发明提高了实体数据的访问速度、减小了实体属性数据的数据量和存储空间,实现了灵活、方便的实体属性数据扩展。
Description
技术领域
本发明涉及一种实体属性数据的处理方法,尤其涉及一种根据实体属性数据的特征分别进行数据存储和查找的装置及方法。
背景技术
在计费系统的处理过程中,需要大量引用实体的各个属性,以实现各种“资费”、“套餐”。这里所说的实体包括但不限于:客户、帐户、用户、用户群组等,实体的属性包括(以用户实体具体说明):电话号码、年龄、性别、出生日期、职业、通话时间等。
在电信市场上,各个运营商为了应对日益激烈的市场竞争,不断推出新业务和与之配套的营销策略(如新产品组合和资费套餐),在资费上不是简单地实施降价,而是根据用户特点(也就是实体的属性)为用户提供优惠政策,这样就要求实体属性能不断增加以存储各种实体的属性,实体的数量也会经常发生变化的,所以要求能对计费系统中的实体属性进行动态增加。
为高效实现对实体属性的快速访问,计费系统将实体属性放置到系统的内存(包括共享内存)中实现,实现方式如图1所示,计费进程1和计费进程2分别从内存100中访问实体1属性和实体4属性,继而实现计费。
因此,为实现经济、高效的计费,就需要一套有效的内存分配、管理策略。
目前,在共享内容中,实体属性主要采用两种方式进行存放。
第一种方式是将实体属性采用数据库横表的矩阵方式存放在内存中,即将实体的各类属性放置到不同记录字段中,如表1所示。访问实体的属性时,直接按索引找到实体记录的位置,然后在对应字段的位置读取数据即可。
例如:查找用户名称为张三的用户所在群号的过程为:首先根据用户名称找到“张三”字段,查找到其实体ID记录为“1”,位于表中第1行,然后直接读取记录中的“用户所在群号”字段的值即可。
表1:实体属性的数据库横表存储表
实体ID | 电话号码 | 用户名称 | 性别 | 用户所在群号 | 拨打到广州长途时长 | 拨打到韩国长途时长 | 使用Sina音乐下载次数 |
1 | 13801001001 | 张三 | 男 | 1 | 10 | 2 | |
2 | 13801001002 | 李四 | 男 | 2 | |||
3 | 13801001003 | 李五 | 女 | 10 | |||
4 | 13801001004 | 李六 | 男 | 5 |
采用数据库横表方式存储实体属性,在计费过程中根据特定条件便可以非常快捷、方便的知道符合该条件的实体属性的值,但该方式具有如下问题:
大量浪费系统内存资源:因为并非所有实体都拥有表中所有属性,如表1所示,其中许多字段都是空值,例如“拨打到韩国长途时长”、“使用Sina音乐下载次数”等,只有拨打到韩国长途或下载时才有这些属性值。但是,这些空值仍占有相应的内存资源,从而会导致大量系统内存资源的浪费;
实体属性字段扩充困难:表结构定义好后增加表的字段,则要更改表结构,也需要相应修改访问数据的实现,而且在系统内存中的操作非常困难。
第二种方式是将实体属性采用数据库纵表的矩阵方式存放。这种方式是先利用实体属性定义表存放实体的属性含义(实体属性定义表的说明见表2),然后在实体纵表中存放实体的属性值,如用户纵表(用户纵表的说明参见表3)。
访问用户实体的属性时,直接根据实体ID和属性ID在纵表中找到对应的记录,取出属性值即可。
例如:查找用户张三的所在群号的过程为:首先根据实体属性定义表(表2)查找出“用户所在群号”的属性ID为4,然后根据实体的属性值存储表(表3)查找出“张三”的实体ID为1。根据该实体ID“4”和属性ID“1”的交点查找实体的属性值存储表(表3)找到对应的记录,得到张三的用户所在群号为1。
表2:实体属性定义表
属性ID | 属性含义 | 显示顺序 |
1 | 电话号码 | 1 |
2 | 用户名称 | 2 |
3 | 性别 | 3 |
4 | 用户所在群号 | 4 |
5 | 拨打到广州长途时长 | 5 |
6 | 拨打到韩国长途时长 | 6 |
7 | 使用sina音乐下载次数 | 7 |
表3:实体属性的数据库纵表存储表
实体ID | 属性ID | 属性值 | 索引号 |
1 | 1 | 13801001001 | 1 |
1 | 2 | 张三 | 2 |
1 | 3 | 男 | 3 |
1 | 4 | 1 | 4 |
1 | 5 | 10 | 5 |
1 | 6 | 2 | 6 |
2 | 1 | 13801001002 | 7 |
2 | 2 | 李四 | 8 |
2 | 3 | 男 | 9 |
3 | 1 | 13801001003 | 10 |
3 | 2 | 李五 | 11 |
3 | 3 | 女 | 12 |
3 | 7 | 10 | 13 |
4 | 1 | 13801001004 | 14 |
4 | 2 | 李六 | 15 |
4 | 3 | 男 | 16 |
4 | 5 | 5 | 17 |
采用此方式,当实体要增加某个属性值时,先在实体属性定义表中增加属性的定义,然后在实体的属性值存储表增加此属性的值即可;若其他实体不拥有此属性,则在实体的属性值存储表里不会拥有此记录。由此可见,此种方式解决了第一种方式的表结构扩展不灵活的缺点。但该存放方法又带来了新的问题:
访问速度慢:当系统要查找某个实体的所有属性的取值时,需要按每个属性依次去查找纵表,例:需要查找用户张三的所有记录时,在查找到一个属性值时,查找其他的属性值需根据下一个属性位置依次去查找,如果查找张三的所有属性时,查纵表的次数达6次,从而导致查找速度慢;
数据量大:所有实体的属性数据放在同一张表中,如表3所示,纵表的记录数达到17条;
比较浪费空间:由于实体属性的含义不相同,属性值的长度也不相同,为了提供查询效率,实体表的属性值字段都设置成相同的长度,如果有一个属性要求属性值长度较长时,则对于其他属性也要设置成该长度,会浪费空间。
发明内容
本发明的目的在于提供一种实体属性数据处理装置和方法,提高实体数据的访问速度、减小实体属性数据的数据量和存储空间,同时,实现灵活、方便的实体属性数据扩展。
为了实现上述目的,本发明提供了一种实体属性数据处理装置,包括:
实体属性定义模块,用于保存并管理实体属性定义表,所述实体属性定义表用于保存实体属性的定义、类别及与类别对应的保存方式,所述实体属性的类别包括第一类实体属性和第二类实体属性,分别对应于数据库横表保存和数据库纵表保存的保存方式;
第一实体属性保存模块,用于以数据库横表方式保存类别为所述第一类实体属性的实体属性数据;
第二实体属性保存模块,用于以数据库纵表方式保存类别为所述第二类实体属性的实体属性数据;及
实体属性查找模块,用于根据所述实体属性定义表从所述第一实体属性保存模块,或用于根据所述实体属性定义表从所述第一实体属性保存模块和第二实体属性保存模块中查找实体属性值。
所述第一类实体属性是被同类型所有实体个体共同拥有的实体属性,所述第二类实体属性是仅被同类型部分实体个体拥有的实体属性。
上述的装置,其中,还包括一实体类型定义模块,用于保存一实体类型ID定义表,所述实体类型ID定义表用于设置不同实体类型的实体类型ID;
所述实体属性查找模块还用于根据实体类型ID定义表判别需要查找的实体属性的实体类型,并根据实体类型ID选择对应的实体属性定义表。
上述的装置,其中,同类型实体的所述第二实体属性保存模块为多个,用于分别保存所述第二类实体属性中具有相同特征的实体属性。
上述的装置,其中,所述特征包括数据类型、数据长度和属性值中的至少一个。
为了更好的实现上述目的,本发明还提供了一种实体属性数据处理方法,包括:
步骤A,设置实体属性的定义、类别及与类别对应的保存方式,所述实体属性的类别包括第一类实体属性和第二类实体属性;
步骤B,将类别为所述第一类实体属性的实体属性数据保存在数据库横表中,将类别为所述第二类实体属性的实体属性数据保存在数据库纵表中;
步骤C,根据实体属性和所述实体属性定义表从所述数据库横表,或从所述数据库横表和数据库纵表中查找实体属性值。
上述的方法,其中,所述步骤C具体包括:
步骤C1,根据所述实体属性定义表确定要查找的实体属性的保存方式及属性ID,如果是数据库横表保存方式则进入步骤C2,如果是数据库纵表保存方式则进入步骤C3;
步骤C2,从所述数据库横表找到对应实体的数据库横表记录,读取要查找的实体属性的取值,并将所述取值返回给应用程序;
步骤C3,从所述数据库横表找到对应实体的实体ID,然后结合所述属性ID从所述数据库纵表中读取要查找的实体属性的取值,其中,所述第一类实体属性是同类型所有实体个体共同拥有的实体属性,所述第二类实体属性是仅被同类型部分实体个体拥有的实体属性。
上述的方法,其中,同类型实体的所述数据库纵表为多个,分别保存所述第二类实体属性中具有相同特征的实体属性。
上述的方法,其中,所述特征包括数据类型、数据长度和属性值中的至少一个。
上述的方法,其中,所述步骤C之前还包括:
步骤D,设置一实体类型ID定义表,定义不同实体类型的实体类型ID;
步骤E,根据实体类型ID定义表判别需要查找的实体属性的实体类型,并根据实体类型ID选择对应的实体属性定义表。
上述的方法,其中,所述步骤B和C之间还包括:
步骤F,分别为类别为所述第一类实体属性和所述第二类实体属性的实体属性数据创建索引,并分别保存在数据库横表和数据库纵表中;
所述步骤C中根据实体属性和所述实体属性定义表从所述数据库横表,或从所述数据库横表和数据库纵表中根据所述索引查找实体属性值。
上述的方法,其中,所述步骤F中创建索引的方式包括HASH索引、B+树索引、键树索引。
本发明的实体属性数据处理装置和方法利用数据库横表和数据库纵表结合的方式实现实体属性存储和查找,有效解决了单纯利用数据库横表的方式中的大量浪费内存资源的问题,同时通过两种方式的结合,实现了高效的实体属性数据查找方式,也有效的减少了数据量,降低了对内存资源的利用,同时,通过利用数据库纵表保存具有扩展和动态特性的实体属性数据,能够实现灵活方便的实体属性数据扩展。
附图说明
图1为实体属性访问的示意图;
图2为本发明的实体属性数据处理装置结构示意图。
具体实施方式
本发明的实体属性数据处理装置如图2所示,包括:
实体属性定义模块21,用于保存一实体属性定义表,该实体属性定义表用于对该类型实体的所有属性进行定义,并将被所有该类型实体(如客户实体、帐户实体、用户实体或用户群组实体)中所有实体个体(如表1中的张三、李四、李五和李六)共同拥有或不随业务改变的属性设置为该类型实体的第一类实体属性,将第一类实体属性以外的其它实体属性设置为该类型实体的第二类实体属性,该第二类实体属性不为该类型实体的所有实体个体所共有,同时具有扩展和动态的特征;同时该实体属性定义表还保存了与类别对应的保存方式,第一类实体属性和第二类实体属性分别对应于数据库横表保存方式和数据库纵表保存方式;同时,该实体属性定义模块21还用于管理实体属性定义表,如增加实体属性;
第一实体属性保存模块22,用于根据实体属性定义模块的实体属性定义表以数据库横表方式保存该类型实体的第一类实体属性的数据,一条实体数据库横表记录对应一个实体个体的实例(如一个具体的用户、客户、用户群组等),当存在不同的实体类型时,每一个实体类型会有对应的实体数据库横表;及
至少一个第二实体属性保存模块23,用于根据实体属性定义模块的实体属性定义表以数据库纵表方式保存该类型实体的第二类实体属性的数据,只有实体个体包括第二类实体属性时才在数据库纵表中记录属性值;
同时,上述的第一实体属性保存模块22和第二实体属性保存模块23还可用于对保存的实体属性数据进行管理,包括数据的增加、删除、修改等;
实体属性查找模块24,用于根据实体属性定义模块中的实体属性定义表判别需要查找的实体属性的归属表,并从第一实体属性保存模块,或第一实体属性保存模块和第二实体属性保存模块查找相应的实体属性值。
实体属性查找模块24在获取该实体属性值后,可将其返回给应用程序。
存在不同的实体类型时,本发明的实体属性数据处理装置还包括一实体类型定义模块,用于保存一实体类型ID定义表,该实体类型ID定义表中包括不同实体类型的实体类型ID,如将用户实体的实体类型ID设置为1,客户实体的实体类型ID设置为2,帐户实体的实体类型ID设置为3等。
不同类型的实体对应一实体属性定义表,其中包括有实体类型ID。
实体属性查找模块首先根据实体类型ID定义表判别需要查找的实体属性的实体类型,并根据实体类型ID选择对应的实体属性定义表,根据实体属性定义模块中的实体属性定义表判别需要查找的实体属性的归属表,并从第一实体属性保存模块,或第一实体属性保存模块和第二实体属性保存模块查找相应的实体属性值。
当某一类型实体的实体属性较多或有实际需要时,可将该第二类实体属性以数据库纵表方式保存在多个纵表中,例如,可以将同类型的实体个体中数据类型相同的实体属性保存在一个数据库纵表中,也可以将同类型的实体个体中长度相同的实体属性保存在一个数据库纵表中,当然也可根据属性值来进行划分,还可根据几个特征结合进行划分,具体的划分可以根据具体情况来定。
下面以表1中的客户实体为例进一步对本发明进行说明。
如表4所示,为本发明的实体属性定义表的一种具体实施例,其中该实体属性定义表包括5部分:属性ID(1、2、3、4、5、6、7,分别对应客户实体的7个实体属性)、实体类型ID(1,表明为用户实体)、属性含义(客户实体的7个实体属性的含义)、显示顺序及归属表(客户实体的7个实体属性的含义对应的存储表),该归属表选项表明该属性是存储在数据库横表还是数据库纵表中。
表4中用户实体的所有实体属性包括电话号码、用户名称、性别、用户所在群号、拨打到广州长途时长、拨打到韩国长途时长及使用sina音乐下载次数,其中电话号码、用户名称、性别这3个用户实体的实体属性为所有用户均共同拥有且不随业务改变,所以其在实体属性定义表的归属表选项中为数据库横表,其他4个用户实体的属性不是每一个用户都拥有,因此其在实体属性定义表的归属表选项中为数据库纵表。
表4:本发明的实体属性定义表
属性ID | 实体类型ID | 属性含义 | 显示顺序 | 归属表 |
1 | 1 | 电话号码 | 1 | 数据库横表 |
2 | 1 | 用户名称 | 2 | 数据库横表 |
3 | 1 | 性别 | 3 | 数据库横表 |
4 | 1 | 用户所在群号 | 4 | 数据库纵表 |
5 | 1 | 拨打到广州长途时长 | 5 | 数据库纵表 |
6 | 1 | 拨打到韩国长途时长 | 6 | 数据库纵表 |
7 | 1 | 使用sina音乐下载次数 | 7 | 数据库纵表 |
当第二类实体属性较多,分为多个纵表保存时,表4中的归属表选项可以为数据库纵表1、数据库纵表2、......、数据库纵表n。
表1所示的例子应用本发明后数据库横表如表5所示,其中用户实体的电话号码、用户名称、性别均在数据库横表中存储。
表5:本发明的数据库横表存储表
实体ID | 电话号码 | 用户名称 | 性别 |
1 | 13801001001 | 张三 | 男 |
2 | 13801001002 | 李四 | 男 |
3 | 13801001003 | 李五 | 女 |
4 | 13801001004 | 李六 | 男 |
表1所示的例子应用本发明后数据库纵表如表6所示,其中用户所在群号、拨打到广州长途时长、拨打到韩国长途时长及使用sina音乐下载次数这些不是所有用户均拥有的用户实体属性均在数据库纵表中存储。
表6:本发明的数据库纵表存储表
实体ID | 属性ID | 属性值 | 索引号 |
1 | 4 | 1 | 1 |
1 | 5 | 10 | 2 |
1 | 7 | 2 | 3 |
3 | 7 | 10 | 4 |
4 | 5 | 5 | 5 |
本发明的实体属性数据处理方法包括如下步骤:
步骤31,实体属性查找模块根据实体属性定义模块中的实体属性定义表判别需要查找的实体属性的归属表,,如果在实体数据库横表则进入步骤32,如果在实体纵表则进入步骤33;
步骤32,实体属性查找模块从第一实体属性保存模块的数据库横表找到对应用户的数据库横表记录,然后直接读取数据库横表记录中的实体属性的取值后返回属性数据给应用程序,如查找用户李五的性别的过程为:首先找到用户李五的数据库横表记录,找到其实体ID为3,然后直接从数据库横表记录中找到“性别”字段的值为“女”;
步骤33,实体属性查找模块根据实体ID和属性ID找到实体属性的取值后返回给应用程序,如查找用户李六拨打到广州长途时长的过程为:首先找到用户李六的数据库横表记录,找到实体ID为4,同时从实体属性定义模块中的实体属性定义表找到属性ID为5,然后根据实体ID和属性ID从数据库纵表查到属性值为50,即用户李六的拨打到广州长途时长为50分钟。
当存在多种类型的实体时,本发明的实体属性数据处理方法包括如下步骤:
步骤41,根据实体类型ID定义表判别需要查找的实体属性的实体类型;
步骤42,根据实体类型ID查找对应的实体属性定义表;
步骤43,实体属性查找模块根据实体属性定义模块中的实体属性定义表确定要查找的实体属性所在的表,如果在实体数据库横表则进入步骤44,如果在实体数据库纵表则进入步骤45;
步骤44,实体属性查找模块从第一实体属性保存模块的数据库横表找到对应用户的数据库横表记录,然后直接读取数据库横表记录中的实体属性的取值后返回属性数据给应用程序,如查找用户李五的性别的过程为:首先找到用户李五的数据库横表记录,找到其实体ID为3,然后直接从数据库横表记录中找到“性别”字段的值为“女”;
步骤45,实体属性查找模块根据实体ID和属性ID找到实体属性的取值后返回给应用程序,如查找用户李六拨打到广州长途时长的过程为:首先找到用户李六的数据库横表记录,找到实体ID为4,同时从实体属性定义模块中的实体属性定义表找到属性ID为5,然后根据实体ID和属性ID从数据库纵表查到属性值为50,即用户李六的拨打到广州长途时长为50分钟。
采用本发明的实体属性数据处理方法,大大提高了查找效率。
例如,需查询用户张三所有属性时,首先查询第一实体属性保存模块,得出电话号码、用户名称、性别(查询1次);再结合实体ID和属性ID查询数据库纵表得到用户所在群号、拨打到广州长途时长、使用sina音乐下载次数(查询3次)。由此可见,查询用户张三所有属性的总的查表次数为5次,和现有技术中利用纵表方式存储用户实体属性相比,查询次数少了2次。
采用本发明的方案,节省了空间存储效率。实体属性分为数据库纵表和数据库横表存放,如表5和表6所示,数据库横表记录数为4条,纵表记录数为5条,和现有技术中利用纵表方式存储用户实体属性相比,记录数要少了8条。
采用本发明的方案,系统有很好的扩充性。当某个实体个体需要扩充特定属性时,例如用户张三需要增加一个属性记录用户出生年月,则先在实体属性定义表中增加一个ID来表示此属性,属性ID为8,然后,在用户纵表中增加此属性及其值便可以了,增加的记录为用户纵表中的索引号为6的记录,由此类推,属性含义还可以包括证件编号、所在单位等。由此可见,要增加实体属性,不用更改表结构,只需要在相应纵表中增加记录即可。具体数据存储如表7、8、9所示:
表7:本发明的增加实体属性后的实体属性定义表
属性ID | 属性含义 | 显示顺序 | 归属表 |
1 | 电话号码 | 1 | 数据库横表 |
2 | 用户名称 | 2 | 数据库横表 |
3 | 性别 | 3 | 数据库横表 |
4 | 用户所在群号 | 4 | 数据库纵表 |
5 | 拨打到广州长途时长 | 5 | 数据库纵表 |
6 | 拨打到韩国长途时长 | 6 | 数据库纵表 |
7 | 使用sina音乐下载次数 | 7 | 数据库纵表 |
8 | 出生年月 | 8 | 数据库纵表 |
表8:本发明的增加实体属性后的数据库横表存储表
实体ID | 电话号码 | 用户名称 | 性别 |
1 | 13801001001 | 张三 | 男 |
2 | 13801001002 | 李四 | 男 |
3 | 13801001003 | 李五 | 女 |
4 | 13801001004 | 李六 | 男 |
表9:本发明的本发明的增加实体属性后的数据库纵表存储表
实体ID | 属性ID | 属性值 | 索引号 |
1 | 4 | 1 | 1 |
1 | 5 | 10 | 2 |
1 | 7 | 2 | 3 |
3 | 7 | 10 | 4 |
4 | 5 | 5 | 5 |
1 | 8 | 197912 | 6 |
如前所述,实体属性数据处理装置及实体属性数据处理方法综合了现有技术中两种方案的优点,并避免了方案1和方案2的缺点,解决了查找实体属性的快速经济的方式,可以快速的访问实体属性,有效的解决数据库横表稀疏矩阵浪费共享内存资源的情况,可以灵活的增加实体的属性,有效避免了纵表存储方式带来的纵表数据量大的缺点,有效的节省了实体属性存储空间。
同时,为了进一步提高查询的速度,本发明还对数据库横表和数据库纵表的数据创建索引,下面进行详细描述。
首先需要确定索引的定义信息,包括表索引ID、索引名、表ID、索引字段位置、索引字段长度、索引类型、索引方法及索引参数。
在数据库横表和数据库纵表创建索引,可以多种索引,如HASH索引、B+树索引、键树索引等,可以依据实体信息采用一种更高效的索引,本是实施例中采用HASH索引,索引信息也存储在第一实体属性保存模块和第二实体属性保存模块。
因此,第一实体属性保存模块和第二实体属性保存模块的数据库表均包括数据区和索引区。
同时,为了创建高效的索引,减少相同键值的数据数,可以将具有相同键值的数据形成一个链表。
在此,实体属性查找模块根据实体属性定义模块中的实体属性定义表确定要查找的实体属性所在的表,然后分别查询对应数据库表的索引,进而获取对应实体属性的数据。
在建立索引的情况下,实体属性数据的增加包括如下步骤:
步骤11,为增加的实体数据分配空间;
步骤12,将增加的实体属性数据复制到分配好的空间中;
步骤13,按增加的实体属性数据的索引关键信息生成索引键值;
步骤14,根据索引键值查询键值对应的位置,然后将步骤12中复制好的空间插入到键值对应的链表中。
在建立索引的情况下,实体属性数据的查找包括如下步骤:
步骤21,根据需要查找的实体属性数据的信息计算索引键值;
步骤22,根据索引键值查找到索引位置;
步骤23,获取索引位置相应的数据,对数据进行比较,当查找到相同的数据时,返回数据。
在建立索引的情况下,实体属性数据的更新只需在步骤21~22的基础上对数据进行替换即可。
在建立索引的情况下,实体属性数据的更新只需在步骤21~22的基础上从数据链表中删除即可。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以作出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (11)
1.一种实体属性数据处理装置,其特征在于,包括:
实体属性定义模块,用于保存并管理实体属性定义表,所述实体属性定义表用于保存实体属性的定义、类别及与类别对应的保存方式,所述实体属性的类别包括第一类实体属性和第二类实体属性,分别对应于数据库横表保存和数据库纵表保存的保存方式;
第一实体属性保存模块,用于以数据库横表方式保存类别为所述第一类实体属性的实体属性数据;
第二实体属性保存模块,用于以数据库纵表方式保存类别为所述第二类实体属性的实体属性数据;及
实体属性查找模块,用于根据所述实体属性定义表从所述第一实体属性保存模块,或用于根据所述实体属性定义表从所述第一实体属性保存模块和第二实体属性保存模块中查找实体属性值;
所述第一类实体属性是被同类型所有实体个体共同拥有或不随业务改变的实体属性,所述第二类实体属性是仅被同类型部分实体个体拥有的实体属性。
2.根据权利要求1所述的装置,其特征在于,还包括一实体类型定义模块,用于保存一实体类型ID定义表,所述实体类型ID定义表用于设置不同实体类型的实体类型ID;
所述实体属性查找模块还用于根据实体类型ID定义表判别需要查找的实体属性的实体类型,并根据实体类型ID选择对应的实体属性定义表。
3.根据权利要求1所述的装置,其特征在于,同类型实体的所述第二实体属性保存模块为多个,用于分别保存所述第二类实体属性中具有相同特征的实体属性。
4.根据权利要求3所述的装置,其特征在于,所述特征包括数据类型、数据长度和属性值中的至少一个。
5.一种实体属性数据处理方法,其特征在干,包括:
步骤A,设置实体属性的定义、类别及与类别对应的保存方式,所述实体属性的类别包括第一类实体属性和第二类实体属性;
步骤B,将类别为所述第一类实体属性的实体属性数据保存在数据库横表中,将类别为所述第二类实体属性的实体属性数据保存在数据库纵表中;
步骤C,根据实体属性和实体属性定义表从所述数据库横表,或从所述数据库横表和数据库纵表中查找实体属性值;所述实体属性定义表用于保存所述实体属性的定义、类别及与类别对应的保存方式;
所述第一类实体属性是同类型所有实体个体共同拥有或不随业务改变的实体属性,所述第二类实体属性是仅被同类型部分实体个体拥有的实体属性。
6.根据权利要求5所述的方法,其特征在于,所述步骤C具体包括:
步骤C1,根据所述实体属性定义表确定要查找的实体属性的保存方式及属性ID,如果是数据库横表保存方式则进入步骤C2,如果是数据库纵表保存方式则进入步骤C3;
步骤C2,从所述数据库横表找到对应实体的数据库横表记录,读取要查找的实体属性的取值,并将所述取值返回给应用程序;
步骤C3,从所述数据库横表找到对应实体的实体ID,然后结合所述属性ID从所述数据库纵表中读取要查找的实体属性的取值。
7.根据权利要求5或6所述的方法,其特征在于,同类型实体的所述数据库纵表为多个,分别保存所述第二类实体属性中具有相同特征的实体属性。
8.根据权利要求7所述的方法,其特征在于,所述特征包括数据类型、数据长度和属性值中的至少一个。
9.根据权利要求5所述的方法,其特征在于,所述步骤C之前还包括:
步骤D,设置一实体类型ID定义表,定义不同实体类型的实体类型ID;
步骤E,根据实体类型ID定义表判别需要查找的实体属性的实体类型,并根据实体类型ID选择对应的实体属性定义表。
10.根据权利要求5所述的方法,其特征在于,所述步骤B和C之间还包括:
步骤F,分别为类别为所述第一类实体属性和所述第二类实体属性的实体属性数据创建索引,并分别保存在数据库横表和数据库纵表中;
所述步骤C中根据实体属性和所述实体属性定义表从所述数据库横表,或从所述数据库横表和数据库纵表中根据所述索引查找实体属性值。
11.根据权利要求10所述的方法,其特征在于,所述步骤F中创建索引的方式包括HASH索引、B+树索引、键树索引。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100666910A CN100501734C (zh) | 2006-04-19 | 2006-04-19 | 实体属性数据处理装置及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100666910A CN100501734C (zh) | 2006-04-19 | 2006-04-19 | 实体属性数据处理装置及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101046805A CN101046805A (zh) | 2007-10-03 |
CN100501734C true CN100501734C (zh) | 2009-06-17 |
Family
ID=38771421
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100666910A Active CN100501734C (zh) | 2006-04-19 | 2006-04-19 | 实体属性数据处理装置及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100501734C (zh) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103164413B (zh) * | 2011-12-09 | 2016-03-09 | 金蝶软件(中国)有限公司 | 动态扩展业务对象的方法和系统 |
CN103501244A (zh) * | 2013-09-26 | 2014-01-08 | 汉柏科技有限公司 | 一种查看网络设备属性的方法和装置 |
CN103500225A (zh) * | 2013-10-21 | 2014-01-08 | 樊梦真 | 医学信息的结构化存贮方法 |
CN103870580A (zh) * | 2014-03-24 | 2014-06-18 | 深圳市众鸿科技股份有限公司 | 一种基于对象的动态属性云管理平台及系统 |
KR20170027036A (ko) * | 2015-09-01 | 2017-03-09 | 에스케이하이닉스 주식회사 | 데이터 처리 시스템 |
CN107145493B (zh) * | 2016-03-01 | 2020-11-24 | 创新先进技术有限公司 | 信息处理方法及装置 |
CN105955727A (zh) * | 2016-04-22 | 2016-09-21 | 广东凯通软件开发有限公司 | 一种通用内存实体的创建方法和访问方法 |
CN107544992A (zh) * | 2016-06-27 | 2018-01-05 | 阿里巴巴集团控股有限公司 | 数据分析的方法和装置 |
CN110019196A (zh) * | 2017-09-28 | 2019-07-16 | 北京国双科技有限公司 | 数据处理方法及装置 |
CN110019017B (zh) * | 2018-04-27 | 2021-04-27 | 中国科学院高能物理研究所 | 一种基于访问特征的高能物理文件存储方法 |
CN112862510A (zh) * | 2019-11-27 | 2021-05-28 | 北京沃东天骏信息技术有限公司 | 广告资源管理的方法和装置 |
CN111414361A (zh) * | 2020-02-20 | 2020-07-14 | 口碑(上海)信息技术有限公司 | 标签数据存储方法、装置、设备及可读存储介质 |
CN111988749B (zh) * | 2020-08-28 | 2022-01-28 | 北京思特奇信息技术股份有限公司 | 一种动态资费的生成方法及装置 |
-
2006
- 2006-04-19 CN CNB2006100666910A patent/CN100501734C/zh active Active
Non-Patent Citations (2)
Title |
---|
基于电信运营中大客户流失的数据挖掘模型. 冀振明,陶世群.计算机工程与应用,第23期. 2004 |
基于电信运营中大客户流失的数据挖掘模型. 冀振明,陶世群.计算机工程与应用,第23期. 2004 * |
Also Published As
Publication number | Publication date |
---|---|
CN101046805A (zh) | 2007-10-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100501734C (zh) | 实体属性数据处理装置及方法 | |
CN105930387A (zh) | 一种基于数据路由、分库分表的数据操作系统及方法 | |
CN107622091A (zh) | 一种数据库查询方法和装置 | |
CN101876983A (zh) | 数据库分区方法与系统 | |
CN102033882B (zh) | 一种性能数据的存储方法及系统 | |
CN105224560B (zh) | 缓存数据的查找方法和装置 | |
CN106155934B (zh) | 一种云环境下基于重复数据的缓存方法 | |
CN106959963A (zh) | 一种数据查询方法、装置及系统 | |
CN104281717B (zh) | 一种建立海量id映射关系的方法 | |
CN104462141A (zh) | 一种数据存储与查询的方法、系统及存储引擎装置 | |
CN109857760A (zh) | 快速响应检索方法及装置、计算机装置及存储介质 | |
CN103631933A (zh) | 一种面向分布式去重系统的数据路由方法 | |
CN110287160A (zh) | 一种缓存空间清理方法及装置 | |
CN101093482A (zh) | 一种大量信息存储和检索的方法 | |
CN104021088B (zh) | 日志存储方法和装置 | |
CN110096509A (zh) | 大数据环境下实现历史数据拉链表存储建模处理的系统及方法 | |
WO2021016050A1 (en) | Multi-record index structure for key-value stores | |
CN104574159A (zh) | 数据存储、查询方法和装置 | |
CN116756253B (zh) | 关系型数据库的数据存储、查询方法、装置、设备和介质 | |
CN104598652B (zh) | 一种数据库查询方法及装置 | |
CN102193988A (zh) | 一种图形数据库节点数据的检索方法及系统 | |
CN109165217A (zh) | 一种时序数据的高效存储方法 | |
CN106326295B (zh) | 语义数据的存储方法及装置 | |
CN107451229B (zh) | 一种数据库查询方法和装置 | |
Nie et al. | Effectively mining and using coverage and overlap statistics for data integration |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |