CN101404013A - 数据库大数据量表存储和查询方法 - Google Patents
数据库大数据量表存储和查询方法 Download PDFInfo
- Publication number
- CN101404013A CN101404013A CNA2008101597866A CN200810159786A CN101404013A CN 101404013 A CN101404013 A CN 101404013A CN A2008101597866 A CNA2008101597866 A CN A2008101597866A CN 200810159786 A CN200810159786 A CN 200810159786A CN 101404013 A CN101404013 A CN 101404013A
- Authority
- CN
- China
- Prior art keywords
- database
- item
- subregion
- storage
- cust
- 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.)
- Pending
Links
- 238000003860 storage Methods 0.000 title claims abstract description 23
- 238000000034 method Methods 0.000 title claims abstract description 14
- 238000005192 partition Methods 0.000 claims abstract description 11
- 238000005516 engineering process Methods 0.000 claims abstract description 5
- 238000013316 zoning Methods 0.000 claims description 13
- 238000013500 data storage Methods 0.000 claims description 4
- 238000012423 maintenance Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000002354 daily effect Effects 0.000 description 2
- 230000003203 everyday effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000009825 accumulation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种数据库大数据量表存储和查询方法，该方法通过数据库物理设计和逻辑设计来实现海量数据表的存储“分区”，而不依赖于数据库本身是否具备分区技术；该方法根据日结帐表所特有的一些特性设计合理的规则，根据规则来对表定义进行“分区”设计，使记录在向数据库插入过程中自动“分发”到不同存储“分区”中；“分区”之后的日结帐表根据规则设计来创建联合视图，通过联合视图提供查询功能，这样实现的日结帐表在数据查询上会有明显的优势，而对于表空间存在大小限制的数据库，也不会因为日结帐表数据量庞大而导致数据库表空间达到上限而无法解决。
Description
技术领域
本发明涉及计算机应用技术领域，具体地说是一种数据库大数据量表存储和查询的实现方法。
背景技术
在很多企业的业务系统中都存在“日清日结”或者“日清月结”的功能，这样会方便企业对当天或者整个月商品的库存以及销售情况进行盘点；在这一过程中，一般会生成大量的数据记录来存储到数据库相应的日结帐表中，随着时间的累积，这样的表会越来越庞大，在一些相对集中的企业数据库中数量级会达到亿级以上。
在数据库中如果存在记录数上亿的表，会给数据的查询带来比较大的麻烦，除了查询SQL本身的响应时间会越来越慢，主机系统在CPU、内存资源的使用上也会越来越高，更严重的是会使跟这些表相关的业务功能无法进行，在并发要求比较高的数据库系统中，可能会给系统带来大量的数据库锁，并影响整个数据库系统，导致数据库的崩溃；而对于表空间存在大小限制的数据库，庞大数据量的表也是一个比较棘手的问题。
在解决大数据量表存储问题方面，比较常用的方式是在经过一段时间之后，对表中的数据进行转移，也就是从最初的表中将数据迁移到另一个或多个存储历史过渡数据的表中，也有直接将历史数据清除的做法；这两种做法都存在一定问题，将数据隔一段时间转移到历史过渡表中，一方面需要考虑历史过渡表怎么维护的问题，在转移数据上也需要花费很多精力，另外就是对于历史过渡数据的查询比较麻烦，查询性能也不会很好；如果将数据直接清空也将面临历史数据查询的问题。上面的方式多数时候都不具备自动维护的特点，都是在维护人员人工操作的情况下进行的。
发明内容
本发明的数据库大数据量表存储和查询方法，是根据企业中大数据量的表特性进行分区规则设计，通过设计好的分区规则，实现数据库表的逻辑设计和物理设计，从而实现大数据量表的分区存储以及分区查询的目的，具体实现步骤如下：
1)企业中日结帐表按照月份分区规则设计，日结帐表都存在日期列，而且对于日结帐表的查询方式是一个完整的月份，分区规则按照月份来制定；
2)在定义好分区规则之后，对于表定义按照分区规则划分成多份，按月份的划分定义成12个表，每个表都定义有特定的表空间，数据存储在不同特定的表空间中；
3)在定义好的表的基础上，增加表检查约束定义，约束条件为月份，通过检查约束实现记录增加的时候自动存储到不同表空间中；
4)分区表的定义完成之后，定义联合视图，通过联合视图联合所有分区表实现大数据量日结帐表的分区存储；
5)通过修改联合视图的定义，让每个分区表都增加相应的查询条件，这样就实现了分区查询的目的。
利用通用数据库定义以及设计规则来实现数据库表分区存储以及分区查询的目的，不依赖于任何数据库深层次的技术。
本发明的有益效果是：
1、通过企业中大数据量表的一些特性，来实现表的逻辑分区设计，从而实现大数据量表物理上的分区实现。
2、采用一些通用的数据库定义方法来解决大数据量表的分区实现问题，而不依赖数据库是否具备分区技术，大多数数据库产品都能够实现。
3、不需要花太多精力考虑数据存储维护的问题，表空间的限制相当于扩大到原来的12倍，避免了数据库表空间维护给系统运维人员带来的麻烦。
4、解决数据库大数据量表的查询SQL的响应时间随时间增长变得越来越慢的问题，在这种实现效果下，12年之后才会相当于原方式1年之后的查询响应时间。
5、整个实现方式对于客户端工具和程序来说，相当于一个“黑盒子”，不需要开发人员做什么调整，在以后的维护当中也不需要系统维护人员做人工的干预。
附图说明
附图1是数据库大数据量表存储和查询的方法流程结构示意图。
具体实施方式
本发明的方法是是通过合理的分区规则来解决大数据量表的问题；不需要维护人员做过多的维护工作，更不需要定期进行历史数据的迁移工作。
企业中的日结帐表一般都是根据特定算法，来记录当天商品的销售、库存等财务报表数据的情况；汇总的目的一方面企业需要知道当天销售过程中的成本以及获得的利润情况，另一方面一些具体的人员，例如客户经理需要及时了解每个客户的当天的订货情况；这种日结帐表除了能够提供某一天或者某一段时间的报表查询数据之外，还将作为月结算的原始数据，那么这样来看日结帐表对系统来说真正有意义的都是不超过一个完整月份的数据。这样我们就可以根据这个规则对日结账表进行按月分区实现，实现分区之后日结帐表对应12个表。
具体实现的技术方案如下，假设某企业中存在一个客户商品日账表(SD_ITEM_CUST_DAY)，该表是用来存储每天该企业的所有客户定购商品情况的，我们现在想象一下在一个拥有庞大客户群的企业，比如拥有20万个客户，而每个客户每天至少定购10种商品，这样算下来这个表一天增加的记录是200万条，如果在一年当中把一些假期去掉，按剩下200天算，那一年下来这个表中存储的记录为4亿条记录，这是相当庞大的一个数字。现在我们看这个表原来的定义：
CREATE TABLE″SD_ITEM_CUST_DAY″(
″COM_ID″VARCHAR(30)NOT NULL，
″SALEORG_ID″VARCHAR(30)NOT NULL，
″DATE1″CHAR(8)NOT NULL，
″CUST_ID″VARCHAR(30)NOT NULL，
″SLSMAN_ID″VARCHAR(30)NOT NULL WITH DEFAULT’0’，
″ITEM_ID″VARCHAR(30)NOT NULL，
″QTY_SOLD″DECIMAL(18，2)WITH DEFAULT 0，
″AMT_SOLD_WITH_TAX″DECIMAL(18，2)WITH DEFAULT 0)
IN″DATA_QUERY″；
首先将该表逻辑定义上按月份划分成12个表，例如：
SD_ITEM_CUST_DAY01、SD_ITEM_CUST_DAY02...
CREATE TABLE″SD_ITEM_CUST_DAY01″(
″COM_ID″VARCHAR(30)NOT NULL，
″SALEORG_ID″VARCHAR(30)NOT NULL，
″DATE1″CHAR(8)NOT NULL，
″CUST_ID″VARCHAR(30)NOT NULL，
″SLSMAN_ID″VARCHAR(30)NOT NULL WITH DEFAULT’0’，
″ITEM_ID″VARCHAR(30)NOT NULL，
″QTY_SOLD″DECIMAL(18，2)WITH DEFAULT 0，
″AMT_SOLD_WITH_TAX″DECIMAL(18，2)WITH DEFAULT 0)
IN″DATA_QUERY″；
……
在定义划分好之后需要解决两方面问题，分别是分区存储和分区查询如何实现的问题。针对分区存储实现的问题，可以进一步细分为两个问题，一是如何将物理存储按照月份实现自动存储，二是如何对客户端或者程序员来说操作这12个表仍然跟“分区”之前没有区别，这样客户端的工具及程序就不用去做任何的调整。
为了解决分区存储的第一个问题，我们在定义这12个表的时候每个表都指定了一个特定的表空间，另外特别增加一个特定的检查约束，检查约束的目的是保证表存储的时候按照我们所设想的每个月的数据存储在特定月份的表中。实现如下：
CREATE TABLE″SD_ITEM_CUST_DAY01″(
″COM_ID″VARCHAR(30)NOT NULL，
″SALEORG_ID″VARCHAR(30)NOT NULL，
″DATE1″CHAR(8)NOT NULL，
″CUST_ID″VARCHAR(30)NOT NULL，
″SLSMAN_ID″VARCHAR(30)NOT NULL WITH DEFAULT’0’，
″ITEM_ID″VARCHAR(30)NOT NULL，
″QTY_SOLD″DECIMAL(18，2)WITH DEFAULT 0，
″AMT_SOLD_WITH_TAX″DECIMAL(18，2)WITH DEFAULT 0)
IN″DATA_QUERY01″；
ALTER TABLE″SD_ITEM_CUST_DAY01″
ADD CONSTRAINT″ITEMCUSTDAYCHECK01″CHECK
(SUBSTR(DATE1，5，2)＝’01’)；
……
为了解决分区存储的第二个问题我们需要将这12个表创建成一个视图，通过联合定义使12个表对客户端及程序员表现为一个表，实现如下：
CREATE VIEW SD_ITEM_CUST_DAY AS
(
SELECT*FROM SD_ITEM_CUST_DAY01 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY02 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY03 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY04 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY05 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY06 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY07 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY08 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY09 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY10 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY11 UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY12)；
在分区存储的问题解决之后，我们面临的是查询性能问题，因为我们不仅需要解决存储表空间数据量大的问题，还要解决在查询上分区之后的性能明显比分区之前好的问题。假使我们现在有一个查询SQL：select CUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAYwhere DATE1＝’20080908’，如果按照上面的联合视图的方式去查询，最终的结果会是下面12条SQL的查询结果的一个联合结果集，
select CUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY01 where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY02where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY03where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY04where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY05where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY06where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY07where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY08where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY09where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY10where DATE1＝’20080908’；
selectCUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY11where DATE1＝’20080908’；
select CUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY12whereDATE1＝’20080908’；
这并不是我们想要的结果，这样的查询效率肯定很差，而且会比“分区”之前更差。我们实现的目的是想让这个SQL只会去查询SD_ITEM_CUST_DAY09一个表，即执行下面SQL：
select CUST_ID，ITEM_ID，SUM(QTY_SOLD)from SD_ITEM_CUST_DAY09 whereDATE1＝’20080908’；
为了实现这样的效果我们将原来SD_ITEM_CUST_DAY这个联合视图的定义重新调整一下，实现方式如下：
CREATE VIEW SD_ITEM_CUST_DAY AS(
SELECT*FROM SD_ITEM_CUST_DAY01WHERE DATE1＞＝’20080101’AND DATE1＜＝’20080131’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY02WHERE DATE1＞＝’20080201’AND DATE1＜＝’20080231’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY03WHERE DATE1＞＝’20080301’AND DATE1＜＝’20080331’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY04WHERE DATE1＞＝’20080401’AND DATE1＜＝’20080431’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY05WHERE DATE1＞＝’20080501’AND DATE1＜＝’20080531’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY06WHERE DATE1＞＝’20080601’AND DATE1＜＝’20080631’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY07WHERE DATE1＞＝’20080701’AND DATE1＜＝’20080731’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY08WHERE DATE1＞＝’20080801’AND DATE1＜＝’20080831’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY09WHERE DATE1＞＝’20080901’AND DATE1＜＝’20080931’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY10WHERE DATE1＞＝’20081001’AND DATE1＜＝’20081031’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY11WHERE DATE1＞＝’20081101’AND DATE1＜＝’20081131’UNION ALL
SELECT*FROM SD_ITEM_CUST_DAY12WHERE DATE1＞＝’20081201’AND DATE1＜＝’20081231’)；
做上面修改之后，我们就实现了分区查询的效果。
Claims (2)
1.数据库大数据量表存储和查询的方法，其特征在于，根据企业中大数据量的表特性进行分区规则设计，通过设计好的分区规则，实现数据库表的逻辑设计和物理设计，从而实现大数据量表的分区存储以及分区查询的目的，具体实现步骤如下：
1)企业中日结帐表按照月份分区规则设计，日结帐表都存在日期列，而且对于日结帐表的查询方式是一个完整的月份，分区规则按照月份来制定；
2)在定义好分区规则之后，对于表定义按照分区规则划分成多份，按月份的划分定义成12个表，每个表都定义有特定的表空间，数据存储在不同特定的表空间中；
3)在定义好的表的基础上，增加表检查约束定义，约束条件为月份，通过检查约束实现记录增加的时候自动存储到不同表空间中；
4)分区表的定义完成之后，定义联合视图，通过联合视图联合所有分区表实现大数据量日结帐表的分区存储；
5)通过修改联合视图的定义，让每个分区表都增加相应的查询条件，这样就实现了分区查询的目的。
2、根据权利要求1所述的方法，其特征在于利用通用数据库定义以及设计规则来实现数据库表分区存储以及分区查询的目的，不依赖于任何数据库深层次的技术。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008101597866A CN101404013A (zh) | 2008-11-13 | 2008-11-13 | 数据库大数据量表存储和查询方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2008101597866A CN101404013A (zh) | 2008-11-13 | 2008-11-13 | 数据库大数据量表存储和查询方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101404013A true CN101404013A (zh) | 2009-04-08 |
Family
ID=40538033
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2008101597866A Pending CN101404013A (zh) | 2008-11-13 | 2008-11-13 | 数据库大数据量表存储和查询方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101404013A (zh) |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102053975A (zh) * | 2009-10-30 | 2011-05-11 | 国际商业机器公司 | 数据库系统和跨数据库查询优化方法 |
| CN102081651A (zh) * | 2010-12-29 | 2011-06-01 | 北京像素软件科技股份有限公司 | 一种网络游戏数据库分表的方法 |
| CN103226610A (zh) * | 2013-05-07 | 2013-07-31 | 华为技术有限公司 | 数据库表查询方法和装置 |
| CN103262074A (zh) * | 2010-11-16 | 2013-08-21 | 赛贝斯股份有限公司 | 并行再分区索引扫描 |
| CN104360997A (zh) * | 2014-04-01 | 2015-02-18 | 芜湖齐创自动化系统有限公司 | 一种基于结构化数据库的大数据漂移技术 |
| CN105718539A (zh) * | 2016-01-18 | 2016-06-29 | 浪潮通用软件有限公司 | 一种数据库应用方法及装置 |
| CN105868197A (zh) * | 2015-01-20 | 2016-08-17 | 中国移动（深圳）有限公司 | 一种话单数据的统计方法及统计装置 |
| CN106411987A (zh) * | 2016-01-06 | 2017-02-15 | 平安科技（深圳）有限公司 | 文件上传监控方法和装置 |
| CN107153683A (zh) * | 2017-04-24 | 2017-09-12 | 泰康保险集团股份有限公司 | 实现数据查询的方法和装置 |
| CN107861989A (zh) * | 2017-10-17 | 2018-03-30 | 平安科技（深圳）有限公司 | 数据的分区存储方法、装置、计算机设备及存储介质 |
| CN109558758A (zh) * | 2018-11-14 | 2019-04-02 | 中国航空综合技术研究所 | 基于rfid标签的计量器具监控系统及其监控方法 |
| CN110019215A (zh) * | 2017-10-26 | 2019-07-16 | Sap欧洲公司 | 多重租赁数据库系统中的键模式管理 |
| CN110716948A (zh) * | 2019-12-12 | 2020-01-21 | 四川新网银行股份有限公司 | 一种基于数据定期处理的双锁控制方法及介质 |
-
2008
- 2008-11-13 CN CNA2008101597866A patent/CN101404013A/zh active Pending
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8768915B2 (en) | 2009-10-30 | 2014-07-01 | International Business Machines Corporation | Database system and method of optimizing cross database query |
| CN102053975A (zh) * | 2009-10-30 | 2011-05-11 | 国际商业机器公司 | 数据库系统和跨数据库查询优化方法 |
| CN103262074B (zh) * | 2010-11-16 | 2016-11-02 | 赛贝斯股份有限公司 | 并行再分区索引扫描 |
| CN103262074A (zh) * | 2010-11-16 | 2013-08-21 | 赛贝斯股份有限公司 | 并行再分区索引扫描 |
| CN102081651B (zh) * | 2010-12-29 | 2013-01-30 | 北京像素软件科技股份有限公司 | 一种网络游戏数据库分表的方法 |
| CN102081651A (zh) * | 2010-12-29 | 2011-06-01 | 北京像素软件科技股份有限公司 | 一种网络游戏数据库分表的方法 |
| CN103226610B (zh) * | 2013-05-07 | 2016-06-29 | 华为技术有限公司 | 数据库表查询方法和装置 |
| CN103226610A (zh) * | 2013-05-07 | 2013-07-31 | 华为技术有限公司 | 数据库表查询方法和装置 |
| CN104360997B (zh) * | 2014-04-01 | 2017-11-14 | 芜湖齐创自动化系统有限公司 | 一种基于结构化数据库的大数据漂移方法 |
| CN104360997A (zh) * | 2014-04-01 | 2015-02-18 | 芜湖齐创自动化系统有限公司 | 一种基于结构化数据库的大数据漂移技术 |
| CN105868197A (zh) * | 2015-01-20 | 2016-08-17 | 中国移动（深圳）有限公司 | 一种话单数据的统计方法及统计装置 |
| CN106411987A (zh) * | 2016-01-06 | 2017-02-15 | 平安科技（深圳）有限公司 | 文件上传监控方法和装置 |
| CN106411987B (zh) * | 2016-01-06 | 2019-05-31 | 平安科技（深圳）有限公司 | 文件上传监控方法和装置 |
| CN105718539A (zh) * | 2016-01-18 | 2016-06-29 | 浪潮通用软件有限公司 | 一种数据库应用方法及装置 |
| CN105718539B (zh) * | 2016-01-18 | 2019-02-19 | 浪潮通用软件有限公司 | 一种数据库应用方法及装置 |
| CN107153683A (zh) * | 2017-04-24 | 2017-09-12 | 泰康保险集团股份有限公司 | 实现数据查询的方法和装置 |
| CN107153683B (zh) * | 2017-04-24 | 2020-04-07 | 泰康保险集团股份有限公司 | 实现数据查询的方法和装置 |
| CN107861989A (zh) * | 2017-10-17 | 2018-03-30 | 平安科技（深圳）有限公司 | 数据的分区存储方法、装置、计算机设备及存储介质 |
| CN110019215A (zh) * | 2017-10-26 | 2019-07-16 | Sap欧洲公司 | 多重租赁数据库系统中的键模式管理 |
| CN110019215B (zh) * | 2017-10-26 | 2023-10-20 | Sap欧洲公司 | 多重租赁数据库系统中的键模式管理 |
| CN109558758A (zh) * | 2018-11-14 | 2019-04-02 | 中国航空综合技术研究所 | 基于rfid标签的计量器具监控系统及其监控方法 |
| CN110716948A (zh) * | 2019-12-12 | 2020-01-21 | 四川新网银行股份有限公司 | 一种基于数据定期处理的双锁控制方法及介质 |
| CN110716948B (zh) * | 2019-12-12 | 2020-04-14 | 四川新网银行股份有限公司 | 一种基于数据定期处理的双锁控制方法及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101404013A (zh) | 数据库大数据量表存储和查询方法 | |
| EP1897000B1 (en) | Methods and apparatus for maintaining consistency during analysis of large data sets | |
| US9092467B2 (en) | Systems and methods for displaying data in split dimension levels | |
| US7720804B2 (en) | Method of generating and maintaining a data warehouse | |
| CN101263492B (zh) | 用于透明地存档的方法和设备 | |
| US7870016B2 (en) | Report management system | |
| US20140244573A1 (en) | Data warehouse with cloud fact table | |
| US20140214753A1 (en) | Systems and methods for multi-source data-warehousing | |
| WO2014106046A2 (en) | Systems and methods for multi-source data-warehousing | |
| CN112835917A (zh) | 一种基于血缘关系分布的数据缓存方法、系统 | |
| Albano | Decision support databases essentials | |
| Ahmed et al. | Querying multiversion data warehouses | |
| Sethi | Data Warehousing and OLAP Technology | |
| Rizzi | Open problems in data warehousing: 8 years later | |
| Khan | Data warehousing 101: Concepts and implementation | |
| BOGZA | DATA MARTS ARCHITECTURE AND DESIGN | |
| DuMoulin | Architecting Data Warehouses for Flexibility, Maintainability, and Performance | |
| Rizzi et al. | Date Warehouse Design. | |
| Bog et al. | Enterprise Data Management for Transaction and Analytical Processing | |
| Shah | A Novel Framework for Data Acquisition and Retrieval Using Hierarchical Schema Over Structured Big Data | |
| Chang et al. | Database Design on Classification Detailed Account for Educational Materials | |
| Levine et al. | What the accountant must know about data warehousing | |
| Hira et al. | Designing multidimensional model using relational schema | |
| Sunna et al. | Enabling agile BI with a compressed flat files architecture | |
| Mastroianni | 5-Data warehousing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20090408 |