CN103914512A - 用于管理数据服务的方法和系统 - Google Patents

Abstract

一种用于管理由数据服务提供实体向数据服务客户提供的数据服务的方法、系统和软件。所述方法包含：（i）从对应于由数据服务客户所做出的数据服务的错误使用的数据服务客户的预支付账户中减少相对价值单位（RVU）；（ii）从所述数据服务客户接收用于返回在减少步骤所减少的RVU的请求；以及（iii）如果请求已经被确定是适当的，则返回RVU。至少返回步骤是在由数据服务提供实体所提供的软件的控制下自动执行的，并且基本上没有由数据服务提供实体的任何人类代表进行的人工干预。

Description

用于管理数据服务的方法和系统

技术领域

本发明一般涉及计算机化的数据库服务领域（诸如，业务（business）数据库存档和业务数据库档案管理），并且更具体地涉及预支付的计算机化的数据库服务。

背景技术

计算机化的数据库服务，诸如业务数据库存档和业务数据库档案管理是已知的。例如，包括此类计算机化的数据库服务的商用系统目前由IBM公司以下列名称销售：IBM InfoSphere Optim企业版V9.1和工作组版V9.1，其提供具有基于容量定价的简化打包。已经将该软件和/或服务包描述如下：“InfoSphereOptim^TM企业版V9.1和工作组版V9.1提供具有基于容量定价的简化打包以用于Optim的档案、测试数据管理、和数据隐私能力”。至少某些数据库服务系统能够从需求到退役（retirement）对数据进行管理，以促进业务驱动的治理。优选地，数据库服务：（i）降低风险和成本，（ii）加速解决方案交付，（iii）提高性能，以及（iv）解决数据库、仓库以及大数据环境的合规性需求。数据生命周期管理是在业务信息的整个生命周期（从需求到退役）中管理业务信息的过程。数据生命周期管理跨域不同的应用系统、数据库以及存储介质，并且可以实现为整体信息整合和治理策略中的一部分。通过在数据的生命周期中对数据进行适当的管理、使用数据库服务，组织机构能够更好地以更少的风险来支持业务目标。

还已知，此类计算机化的数据库服务可以要求客户（一般是企业，常常是大企业）向数据库服务提供者对服务进行预付费。还已知，此类预付费可以基于预支付的“代币”（token，本文有时还称为RVU），其中每个代币代表用于数据库服务的某一类型服务或方面的预付费单位。例如，已知代币可以代表数据流的预支付的量，数据流是当数据从企业客户的计算机系统流到数据库服务提供者的计算机系统时所测量的。在本文中，此类预付费计划将被称为基于“量数据流”（volumetric data flow）的预付费计划。还已知，预付费计划可以是更具体地基于未压缩的量数据流。

发明内容

根据本发明的一个方面，一种用于管理由数据服务提供实体向数据服务客户提供的数据服务的方法。所述方法包括以下步骤（未必以如下顺序）：（i）为将由所述数据服务提供实体向所述数据服务客户提供的数据服务建立至少基本上的预支付账户，该预支付由相对价值单位（RVU）表示；（ii）响应于对所述数据库服务的使用，从所述预支付账户中减少至少一个递减RVU；（iii）从所述数据服务客户接收对于返回所述至少一个递减RVU的当前值的请求；以及（iv）返回所述至少一个递减RVU的当前值。至少所述接收步骤和所述返回步骤是在由所述数据服务提供实体提供的软件的控制下自动执行的，并且基本上没有人工干预。

附图说明

图1是根据本发明的计算机系统的第一实施例的示意图；

图2A是第一实施例的计算机系统的一部分的示意图；

图2B是第一实施例的计算机系统的一部分的示意图；

图3A是第一实施例的计算机系统的一部分的示意图；

图3B是第一实施例的计算机系统的一部分的示意图；

图4是示出根据本发明的过程的流程图；

图5A是由第一实施例的计算机系统生成的第一屏幕截图；

图5B是由第一实施例的计算机系统生成的第二屏幕截图；

图6A是由第二实施例的计算机系统生成的第三屏幕截图；

图6B是由第二实施例的计算机系统生成的第四屏幕截图；以及

图6C是由第二实施例的计算机系统生成的第五屏幕截图。

具体实施方式

所属技术领域的技术人员知道，本发明的各个方面可以实现为系统、方法或计算机程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式（包括固件、驻留软件、微代码等），或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。此外，在一些实施例中，本发明的各个方面还可以实现为在一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机可读的程序代码。

可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。此类传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java(注：术语“Java”可能在全球不同地区受限于商标权，并且在此使用仅仅指该商标权可能存在范围内的该标示所显示的产品或者服务)、Smalltalk、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。

下面将参照根据本发明实施例的方法、装置（系统）和计算机程序产品的流程图和/或框图描述本发明。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机程序指令实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些计算机程序指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。

也可以把这些计算机程序指令存储在计算机可读介质中，这些指令使得计算机、其它可编程数据处理装置、或其他设备以特定方式工作，从而，存储在计算机可读介质中的指令就产生出包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的指令的制造品（article ofmanufacture）。

也可以把计算机程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机或其它可编程装置上执行的指令提供实现流程图和/或框图中的一个或多个方框中所指定的功能/动作的过程。

现在，将参照附图详细地描述本发明。图1、2A、2B、3A和3B总体上是说明分布式数据处理系统100的各个部分的功能框图，所述分布式数据处理系统包括：数据服务提供者实体管理服务器子系统102；数据服务提供者实体数据库服务器子系统104；第一客户端（或客户）子系统108；第二客户端（或客户）子系统110；客户端（或客户）管理子系统112；通信网络114；数据服务提供者实体管理计算机200；数据服务提供者实体数据库服务器计算机250；通信单元202、252；处理器集204、254；输入/输出（I/O）接口206、256；存储设备208、258；持久存储设备210、260；显示设备212、262；外部设备集214、264；随机存取存储（RAM）设备230、270；缓存存储设备232、272；数据库服务模块（或mod）240、280；预付费子模块302；使用子模块304；限制子模块310；更正子模块312；测试数据管理桶304a；数据增长桶304b；应用退役桶304c；数据隐私（有时还称为数据屏蔽）桶304d；警告子子模块320；节流子子模块322；挂起子子模块324；事实确定子子模块330；策略子子模块332；相对价值单位返回子子模块334；数据库控制子模块352；资源使用子模块360；填充数据流子子模块370；删除子子模块380；特别费用子子模块382；访问数据流子子模块372；存储器使用子子模块374；以及处理时间子子模块376。

在以下段落中，将论述管理服务器计算机子系统的各组件。本领域的技术人员应当理解此论述中的大部分内容还将适用于数据库服务器子系统104；客户端数据子系统108、110；和/或客户端管理子系统112的对应组件。

服务器计算机子系统102可包括作为主要组件200的膝上型计算机、平板计算机、上网本计算机、个人计算机（PC）、台式计算机、个人数字助理（PDA）、智能电话、或任何能够经由网络114与客户端子系统通信的可编程电子设备。如图2A中所示，数据库服务模块240是用于（至少部分地）创建、管理和控制本发明中所处理的数据库服务的机器可读指令和数据的集合。

网络114（见图1）例如可以是局域网（LAN）、广域网（WAN）（诸如互联网）、或者这两者的组合，并且可包括有线、无线、或光纤连接。一般来说，网络114可以是将支持服务器和客户端子系统之间通信的连接和协议的任何组合。

应当了解，图1、2A、2B、3A和3B总体上只提供一种实现方式（即系统100）的说明，并不隐含对于可以在其中实现不同实施例的环境的任何限制。对所示出的环境可以进行许多修改，特别是关于在云计算、分布式计算、更小的计算设备、网络通信等中的当前和预期的未来改进。

再参照图2A，服务器计算机子系统102被示出为带有许多双向箭头的框图。这些双向箭头（没有单独标记）代表通信结构，其在如图2A中所示的子系统102的各组件之间提供通信。此通信结构可以用被设计用于在系统内的处理器（诸如微处理器、通信和网络处理器等）、系统存储器、外围设备、和任何其他硬件组件之间传递数据和/或控制信息的任何架构来实现。例如，通信结构可以至少部分地用一个或多个总线来实现。

存储器208和持久存储器210是计算机可读存储介质。一般来说，存储器208可以包括任何合适的易失性或非易失性计算机可读存储介质。还需注意的是，现在和/或在不久的将来：（i）外部设备（多个）214可能能够为子系统102供应一些或全部存储器；和/或（ii）子系统102的外部设备可能能够提供存储器子系统102。

数据库服务模块（或简称mod）240被存储在持久存储器210中，以供由各自的计算机处理器204中的一个或多个（通常通过存储器208中的一个或多个存储器）访问和/或执行。持久存储器210至少比传送中的信号更持久，但是，当然持久存储器可以基本上没有永久存储器持久。Mod 240可包括机器可读和可执行的指令和/或实质（substantive）数据（即，在数据库中所存储的数据类型）。在这个特定实施例中，持久存储器210包括磁性硬盘驱动器。举一些可能的变化，持久存储器210可包括固态硬盘存储器、半导体存储器设备、只读存储器（ROM）、可擦可编程只读存储器（EPROM）、闪存存储器、或能够存储程序指令或数字信息的任何其他计算机可读存储介质。

由持久存储器210使用的介质还可以是可移动的。例如，可移动硬盘驱动器可用于持久存储器210。其它示例包括插入到驱动器以用于传递到另一个计算机可读存储介质（也是持久存储器210的一部分）的光盘和磁盘、姆指驱动器、和智能卡。

在这些示例中，通信单元202提供与子系统102外部的其它数据处理系统或设备（例如，客户端子系统104、106、108、110、112）的通信。在这些示例中，通信单元202包括一个或多个网络接口卡。通信单元202可以通过使用物理通信链路和无线通信链路中的任何一个或两者来提供通信。本文所论述的任何软件模块可以通过通信单元（诸如通信单元202）下载到持久存储设备（诸如持久存储设备210）。

（一个或多个）I/O接口206允许在与服务器计算机250的数据通信中与可以本地连接的其它设备进行数据输入和输出。例如，I/O接口206提到到外部设备集214的连接。外部设备集214通常将包括诸如键盘、小型键盘、触摸屏、和/或一些其他合适的输入设备的设备。外部设备集214还可包括便携计算机可读存储介质，例如诸如姆指驱动器、便携光盘或磁盘、以及存储卡。用于实现本发明的实施例的软件和数据（例如，商业模块240）可以存储在此类便携计算机可读存储器介质上。在这些实施例中，相关软件可以（或可以不）经由I/O接口集206被全部或部分加载到持久存储设备210上。I/O接口集206还在数据通信中与显示设备212连接。

显示设备212提供向用户显示数据的机制，并且例如可以是计算机监示器或智能电话显示屏。

本文所描述的程序是基于应用来标识的，在本发明的特定实施例中它们针对该应用被实现。然而，应当了解，本文所使用的任何特定程序命名仅是为了方便，并且因此本发明不应当被限制于仅使用在由此命名所标识和/或隐含的任何特定应用中。

简略地参照图3A和图3B，图3A和图3B的各种模块、子模块和/或子子模块将融入到以下图4的流程图的论述中。

现在参照图4，图4是示出根据本发明的实施例的过程400的流程图。在这个示例中，数据库服务组合采用使用相对价值单位（RVU）的随用随付（pay-as-you-go）模型作为由客户为数据库服务付费的机制（不一定是排他的机制）。用于从（一个或多个）客户RVU账户的征收（assess）RVU的方案被用于有效地测量并监视客户对各种类型的数据库服务相关资源的消费，并且从而确保对那些数据库服务相关资源的使用已经做出了适当的预付费。借助于本发明的方法和系统：（i）消费可以通过报告和内部审计（这些可被实现为数据库服务系统的专有功能）来跟踪；以及（ii）容量使用可被跟踪并进行报告。现在将依次论述过程400a的各步骤。

处理在步骤S401开始，其中客户针对一个或多个“RVU桶”对数据库服务做出预付费。更具体地，管理服务器计算机子系统102的数据库服务模块240的预付费子模块302（见图2A和3A）控制接收来自服务客户的此预付费。可以使用金钱做出此支付，尽管其他种类的支付（例如，服务易货）是可能的。此支付例如可以通过互联网来做出。此支付可以由软件自动地处理，或者可以在预付费子模块302的帮助下由服务提供者的人类代理来接受。

处理前进到步骤S402，其中预付费子模块302将对应于预付费的RVU记在客户账户上。在一些实施例中，只有一种类型的RVU，其被应用于所有收费类型的资源使用，但是其它实施例可以有多种类型的RVU以用于不同的：（i）解决方案（例如，测试数据管理、数据增长、应用退役、数据隐私等）；（ii）可用资源类型；（iii）国家/地区/时区/等；（iv）相关的优先级或服务等级协议级别；（v）RVU失效日期（如有）；（vi）在服务客户的业务中的成本中心；（vii）用于具有更快/更慢的不同来源的数据库；和/或（viii）可以变化的其它RVU和/或客户和/或数据特点。对于给定客户账户，每个不同类型的RVU将具有其自己的“桶”（或子账户）。

一旦预付费子模块将RVU添加到客户账户的各桶，则使用子模块304（见图3A）将使用各种桶中的已经购买的RVU作为用于跟踪数据库服务相关资源的预支付使用的起点。如在图3A中的标记304a到304d处最佳示出的，在这个示例中，有四种不同类型的RVU，分别对应于四种不同解决方案：（i）测试数据管理（TDM），（ii）数据增长（DG），（iii）应用退役（AR），以及（iv）数据隐私（DP）。

在这个实施例中，通过RVU的使用，客户购买与所使用的数据库服务解决方案相关的一定量的容量。在这个实施例中，RVU以每个仓库（repository）为基础被应用于产品，但是，在其它实施例中，RVU可以被设计为可跨越多个仓库转移。简略地解释仓库的概念，在Optim产品和/或服务中，仓库被称为“Optim目录”。在本文中，将可互换地使用术语“仓库”和“目录”，但是应当记住，当特别处理Optim产品和/或服务时，准确名称是“Optim目录”。如以下将解释的，对于系统设计者已经选择测量并且收费的资源的每次使用（例如，每次数据库服务相关的执行）桶将被递减。如以下将解释的，基本上连续地对内部记录进行剪切并存储在数据库服务系统仓库中，以跟踪使用并更新剩余的容量。如以下将解释的，一旦已经购买的容量接近于耗尽、和/或完全耗尽时，系统将以由系统设计者选择的方式来响应这些情况。

在这个示例中，四个数据库服务解决方案中的每一个都将具有其自己的各自的消费跟踪和报告。也就是说，在这个示例中，四种不同RVU类型和相关联的桶分别专用于以下四种解决方案：测试数据管理（TDM）、数据增长（DG）、应用退役（AR）、和数据隐私（DP）。如图3A中所示，使用子模块304包括：TDM RVU桶304a、DG RVU桶304b、AR RVU桶304c、和DP RVU桶304d。在其他实施例中，可为所有这些不同解决方案分配一个公共RVU桶。在又一个实施例中，并且如上所述，RVU类型可以不同地定义，诸如用于不同类型的资源使用、用于不同客户成本中心等的不同RVU桶和类型。

现在，将简略地论述四种解决方案（TDM、DG、AR、DP）。

DG涉及出于数据增长目的而生成的所有有效档案文件（未压缩）的总数。

AR涉及出于应用退役目的而生成的所有有效档案文件（未压缩）的总数。

TDM涉及从数据源（排除DDL）拉出的未压缩原始数据的最大数量。该过程将优选地包括跟踪每个表的HWM（“高水位线”）以便避免重复收费，直到超过先前为给定表建立的HWM。详细报告将优选地跟踪摘录样式的使用、以及表样式的使用。

DP（有时还称为数据屏蔽，或DM）涉及经由调用数据库服务实体的相关联的“隐私提供者”屏蔽的数据的最大量。该过程将优选地包括跟踪每个表的HVM（“高水位线”）以便不重复收费，直到超过先前为给定表建立的HWM。详细报告将优选地跟踪以下各项：（i）插入使用；（ii）加载使用；（iii）转换使用；以及（iv）表使用。

返回参照图4，在步骤S403，客户使用由数据库服务系统提供的数据库服务，以及由数据库服务提供实体提供的本发明的方法。例如，客户可操作客户端管理计算机子系统112，以便在数据库服务模块280（见图3B）的数据库控制子模块352的直接控制下，客户端数据可以通过网络114从客户端数据子系统108、110移动到存储在数据库服务器计算机子系统104（参照图1和图2B）的外部数据库存储设备264中的数据档案中。

数据库服务系统的此使用将要求使用数种不同类型资源，包括：（i）一定量未压缩的客户端数据将流过数据库服务提供者的机器；（ii）数据库服务硬件的处理时间；以及（iii）数据存储空间（例如，在设备264中的空间）。在这个示例中，当这些使用在数据库服务器计算机子系统104中执行时，数据库服务模块280的资源使用子模块260跟踪这些使用。更具体地，（i）从数据源流到数据目的地的一定量未压缩的数据由数据库服务模块280的资源使用子模块260的填充数据流子子模块370来跟踪；（ii）与此使用相关联的处理时间由数据库服务模块280的资源使用子模块260的处理时间子子模块376来跟踪；以及（iii）所需要的存储空间由数据库服务模块280的资源使用子模块260的存储使用子子模块374来跟踪。虽然与此档案填充示例操作不相关，但是在这个实施例中可以跟踪的其它使用类型包括：（i）在客户进行数据访问操作期间的数据流（见图3B中的子子模块372）；（ii）数据删除（见子子模块380）；以及（iii）特别收费（例如，见子子模块382，由数据库服务提供者提供的专家辅助）。

返回参照图4，处理前进到步骤S404，其中基于使用对适当的（一个或多个）RVU桶征收RVU。在这个实施例中，系统设计者已经选择了只基于未压缩的量数据流（如由子子模块370跟踪的）对客户进行收费。即，在这个特定示例中，不对处理时间或所使用的存储设备容量进行收费。因此：（i）数据库服务器计算机子系统104的资源使用子模块360向管理计算机子系统102的使用子模块304通知关于在步骤S403的客户命令下已经发生数量流的量；以及（ii）使用子模块304对适当的RVU桶304a、b、c、d征收对应于客户端已经导致发生的量数据流的适当数目的RVU。在这个示例中，流动数据的量与从适当的RVU桶中递减的RVU的量之间存在简单的比例关系。在其他实施例中，在使用量（例如，未压缩的量数据流的量）与适当的（一个或多个）RVU桶的减少的量之间可能存在更复杂的关系。在一些实施例中，取决于不同RVU类型在由系统设计者使用的商业模型中是如何定义的，单个使用可以导致减少超过一个不同RVU桶。

在这个示例中以及如上所述，RVU桶分别对应于由数据库服务提供者提供的各解决方案。当在对应的解决方案中发生使用时，将减少用户账户中的给定RVU桶。例如，提取20千兆字节（GB）的档案将从数据增长RVU桶304b（见图3A）中减少20,000,000,000个RVU，从而使DG RVU桶304b从100,000,000,000个RVU下降到80,000,000,000个RVU。（在这个示例中，未压缩的量数据传送的每个字节被估价为1个RVU。）

如以下将更详细地解释，一旦给定RVU桶304a、304b、304c或304d耗尽，则客户将安排为耗尽的桶购买更多的RVU。这可例如通过数据库服务提供者实体的销售代表来实现。

返回参照图4，在步骤S405，客户做出了对数据库服务系统的（一个或多个）资源的某种不正确使用。在这个示例中，由于在企业客户端的员工之间的错误通信，客户通过数据库服务系统的数据增长（DG）解决方案，把将被存档的相同数据相当快速连续地发送了两次。此不正确的数据传送总计为1GB的未压缩数据，传送两次，总数为2GB的未压缩量数据传送。

处理前进到步骤S406，其中基于先前步骤S405的不正确使用减少了DG RVU桶304b。在这个示例中，这意味着对与企业客户已经执行两次（一次是正确的，以及另一次是重复的和错误的）的此DG解决方案操作相关联的未压缩数据流，从桶304b中减少了2,000,000,000个RVU。

处理前进到步骤S407，其中：（i）客户认识到在先前步骤S405处做出的错误；并且（ii）使用本发明的数据库服务系统以执行更正操作，这将在以下相当详细地论述。应当理解，此更正操作不需要来自数据库服务实体的任何人类服务人员介入。相反，将被描述的更正操作是通过软件在数据库服务提供者实体端自动处理的。这允许客户快速并可靠地进行更正，并且防止在由数据库服务人员而不是由软件自动地做出的更正的系统中可能需要的紧张和时间低效的通信。此外，由软件自动地处理更正调整允许做出更加统一的更正策略，而没有当需要人类服务代表介入更正过程时的偏见的可能性。

更具体地，在步骤S407，客户使用客户端管理计算机子系统112（见图1），调用管理服务器计算机子系统102的数据库服务模块240的更正子模块312（见图1、2A和3A），以便追回在步骤S405和S406错误花费和递减RVU。图5A示出了包括更正请求窗口502的截屏500a，该窗口是当请求本发明的软件对错误花费的RVU进行返回时，可由企业客户使用的用户界面类型的一个示例。在这个示例中，第二个并且多余的存档操作（1GB未压缩数据）是错误的交易，因此客户请求返回与这个多余交易相关联的所有的1,000,000,000个RVU。在这个示例中，客户被询问错误的原因。虽然此信息可能无需在本发明的所有实施例中都提供，但是它有助于确定：（i）本发明的软件是否将提供RVU的自动退还；和/或（ii）用于未来审计者（人类和/或基于人工智能的）在以后时间对此退还交易进行检查的信息。

处理前进到步骤S408，其中：（i）数据库服务模块240的更正子模块312的事实确定子子模块330和策略子子模块332（见图3A）确定是否将做出退还；（ii）数据库服务模块240的更正子模块312的RVU返回子子模块334（见图3A）做出向适当的RVU桶自动返回RVU；以及（iii）RVU返回子子模块334通知用户已经做出返回。这是本发明的自动的、基于软件的更正的一个示例。

事实确定子子模块330确定客户的返回请求是否是事实上正确的。例如：（i）交易号码是有效的吗？；（ii）指定交易真的花费了客户认为的RVU数量吗？；和/或（iii）退还请求的其它事实基础。如果客户的请求不是事实上正确的，则可以给予该客户进行（一个或多个）更正的机会。在一些情况下，可能退还请求仅仅是弄错了，且用户关心的RVU实际上根本没有从用户账户减少。优选地，软件可以有效地并自动地对这类意外事件与客户通信。

策略子子模块332确定数据库服务提供者的策略在该请求的情况下是否允许退还。例如，可以有这样的策略，该策略防止满足对返回RUV的请求，其中在做出该更正请求之前，所述RVU已被花费了超过一年的时间。用于自动的、基于软件的退还的许多其它策略可以由普通技术的系统设计者来实现。策略子子模块332还确定返回的RVU数量。例如，数据库服务提供者实体可以收取15%的“退还费”，其将从返回的RVU中扣除。在图3A和图4的当前示例中，数据库服务提供者具有全额满足所有基于事实的返回请求的策略，在这个示例中，这意味着企业客户得到其对应于未压缩量的、第二个多余的错误存档操作的全部1,000,000,000个RVU。即使在此情况下，该交易可以由人类审计员在某一以后时间点来审计，所述审计潜在地可以导致在未来的某一时刻进一步的RVU增加或进一步的RVU减少。

仍在步骤S408，向用户呈现图5B的截屏500b。截屏500b包括更正确认窗口525，其是可用于向用户通知错误花费的RVU的返回已经完成的用户界面类型的一个示例。

处理前进到步骤S409，其中（i）在步骤S403、S404、S405、S406、S407和S408中所示出的类型的使用根据客户数据库活动的起起伏伏而继续；以及（ii）如现在将在以下段落中解释的，（一个或多个）RVU桶的耗尽由限制子模块310（见图3A）以某种方式进行处理。

根据本发明，有各种方式来对RVU桶的耗尽进行处理。一种方式是为企业客户提供给定RVU桶处于或接近耗尽的“警告”。最后，企业客户将做出附加的支付，并且处理将循环回到步骤S401。“警告”可以采用各种形式，诸如电子邮件、弹出窗口、电话等。在图3A的示例中，给出的这些警告由限制子模块310的警告子子模块322来处理。在本发明的一些优选实施例中，这些“警告”是限制发生的数据库服务的仅有形式。在这些优选实施例中，在相关联的（一个或多个）RVU桶已经完全被耗尽后，当客户继续执行数据库服务操作（即收费的操作）时，客户实际上被延长了信用。在这些实施例中，信任客户能够做到及时付款，并且使其账户“恢复结余”（back in black）。

如在图3A中所示，限制子模块310还包括节流子子模块322，其可用于如果客户的RVU桶在步骤S409接近、处于或已经完全耗尽，则减慢数据库服务的执行，或以其他方式使数据库服务的执行不那么用户友好。此节流可以有助于刺激客户来做出另一个预付费以续费，使得处理返回到步骤S401。不是本发明的所有实施例都将包括任何类型的节流。

如图3A中所示，限制子模块310还包括挂起子子模块324，其可用于如果客户的RVU桶在步骤S409到达或已经完全耗尽，则挂起数据库服务的执行。此节流可以有助于刺激客户来做出另一个预付费以续费，使得处理返回到步骤S401。不是本发明的所有实施例都将包括任何类型的挂起。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

现在，在以下段落中将给出关于本发明的一些附加注释。这些段落涉及本发明的实施例，如被应用于被称为“Optim”的IBM数据库服务程序和/或包的实施例（注意：在全世界中的一些司法管辖区中，名称Optim具有商标权利和/或服务标记权利）。当然，在以下段落中所描述的特定特征不应当用于将限制本发明的范围，除非在这个特征由所发布的权利要求的明确语言所要求的程度上。在以下示例中，所使用的RVU是“代币”。

由于过程或服务有时运行错误（有误解或意外结果），因此向用户提供了向Optim跟踪机制返回消费的能力。消费容量的每个过程将返回可在随后过程中使用以返回意外消费的代币。这在本文的以下部分中更详细地描述。Optim不跟踪、报告、或指示任何容量类型消息传送，直到Optim容量代币记录（CTR）已经在Optim目录中创建。Optim将继续运行在经典的处理器价值单元（PVU）模型中，直到在运行期间已经检测到CTR。一旦创建了CTR，然后Optim将在CTR内跟踪消费。此方法将支持随着时间的推移从经典许可（PVU）迁移到容量许可（RVU）。RVU或消费模型在应用CTR的时刻生效。对于给定解决方案，没有CTR的仓库将继续基于PVU模型。

现在将论述将容量代币应用于Optim目录。容量代币是唯一的，并且可应用于一个且仅一个Optim目录。使用超过一个目录的站点将需要为使用中的每个目录购买容量。在应用容量代币的过程期间，Optim将在Optim目录中创建新的容量代币记录（CTR）。在Optim目录中的现有CTR不合并。每个容量代币在其生命周期期间具有管理该代币的单个CTR。对于单个解决方案，可同时存在两个或多个CTR。所有基于解决方案的CTR的总数将为那个特定解决方案产生站点容量总数。增加CTR仅是处理容量和消费的一个方面。还支持其它支持功能，如更新、删除以及返回容量的能力。

现在将论述更新Optim目录内的容量。可能存在更新给定Optim目录内的现有CTR以具有更少容量的需求。在正常的Optim处理之外，优选地允许减少原始的代币值。更新操作要求调用方来提供用于生成CTR的原始容量代币、代币应用于的Optim目录、以及应当减少可利用容量的数量。提供的用于减少的值将是以千兆字节为单位。

现在将论述将容量返回给Optim目录。有时，无意中运行或使用错误的属性运行请求。这运行虽然产生了有效的输出（档案文件、提取文件、隐私化数据），但不是预期的输出。然而，由于Optim认为处理是成功的，因此在CTR中记录消费。在这些情况下，用户应当能够将由错误过程使用的消费返回给CTR。每个过程将产生唯一的返回（RETURN）代币。这个代币被返回作为过程报告的一部分，但是也存留在与请求相关的CTR条目中。用于返回代币的编码将包括由操作消费的容量。因此当返回代币用于向CTR返回所消费的容量时，只需提供代币本身。用户必须提供与错误请求执行相关联的返回代币。用户还必须提供持有容量的CTR位于的Optim目录。拥有返回容量的能力为产品误用打开了一扇门。因此，返回消费的过程经由报告来审计和监视。

现在将论述从Optim目录删除容量代币记录。删除（DELETE）功能的目的是一旦已经确定出于报告的目的不再需要包括没有容量的CTR，则移除没有容量的CTR。虽然删除动作隐含从容量（CAPACITY）表中移除记录，但是它实际上是被更新，将与记录CTR相关联的记录类型从CTR类型“01”变更到“999”。（见以下所描述的CTR行类型）。主CTR条目的重编号将跟踪机制留在目录中用作历史目的，但是允许报告工具集中于最近的当前状态（如果这是希望的）。重编号主CTR的过程仅是删除过程的一部分。所有具有相同容量代币的从属记录类型将从容量表中物理删除。

现在将论述经由批处理的容量管理。如果用户希望经由命令行应用容量代币，则以下语法描述了什么是需要的。从用户界面的任何调用将在幕后调用这个API：

<executable name>/CAPacity/FUNCtion={ADD|DELETE|RETURN|{UPDATE SIZE=###}}

TOKEN={token|%}

DIRectory=repository name

在以下段落中将阐述命令行使用的示例连同一些示例性命令行语言。

将用于100GB数据增长的容量代币应用于OPYIM_PROD仓库。对此，命令行语言是：

<executable name>/CAP/FUNC=ADD TOKEN=0F0E0D0CDIR=OPTIM_PROD

将用于数据增长的10GB容量返回给OPTIM_PROD仓库。对此，命令行语言是：

<executable name>/CAP/FUNC=RETURN TOKEN=0F0E0D1CDIR=OPTIM_PROD

由于外部环境将数据增长容量代币OPTIM_PROD目录减少20GB。对此，命令行语言是：

<executable name>/CAP/FUNC=UPDATE TOKEN=0F0E0D0CSIZE=20DIR=OPTIM_PROD

出于应用退役目的而执行的存档请求成功地完成。然而，由于用户在存档请求编辑器中没有打开程序退役选项，因此错误地从数据增长容量代币中减去消费。为避免返回用于数据增长的容量以及重新运行打开应用退役选项的请求，用户可以简单地使用下面的UPDATE（更新）命令以执行这两个操作。（用户仍应修理编辑器以用于任何随后运行）。以下操作将与返回代币相关联的请求有关的CTR记录移动到应用退役CTR集（针对解决方案类型对返回代币进行调整）。它将消费添加回到数据增长容量CTR。最后，将相应地减少应用退役容量CTR。对于上述操作，命令行语言是：

<executable name>/CAP/FUNC=UPDATE TOKEN=0F0E0D0CRETURN_TOKEN=0F0E0D1C DIR=OPTIM_PROD

在OPTIM_PROD仓库中移除单个耗尽的容量代币，从而将其从所生成的消费报告中移除。对此，命令行语言是：

<executable name>/CAP/FUNC=DELETE TOKEN=0F0E0D0CDIR=OPTIM_PROD

在OPTIM_PROD仓库中移除所有耗尽的容量代币，从而将其从所生成的消费报告中移除。对此，命令行语言是：

<executable name>/CAP/FUNC=DELETE TOKEN=ALLDIR=OPTIM_PROD

现在将论述Optim中的消费跟踪。Optim为那些成功完成的请求跟踪消费。当成功完成时，将适当地减少CTR。以下描述对于每个消费类别的成功条件以及测量消费的方法。标准的通知消息将出现在所有的Optim过程报告中，其指示以下内容：（i）为执行消耗的容量；（ii）剩余容量（给定类型的所有CTR的总数）；以及（iii）用于在操作期间所消费的每种容量类型的（一个或多个）返回代币。对于在过程（数据增长、TDM、数据隐私等）中所涉及的每种CTR类型，应当出现类似于以下的消息：“这个请求已经消费了nn,nnn,nnn（M或G）。还剩余NNN,NNN,NNN（M或G）。返回代币：010d0303。”。如果消费导致CTR变为负值，例如站点已经消费了超过它被许可的，在任何时候Optim都不会停止操作。Optim将继续操作。如果剩余值是负值，则Optim将产生以下报警消息：“请联系xxxxx处的IBM XXXX以获取附加的容量代币来增加你针对<容量类型>使用Optim的权利。”

现在将论述数据增长跟踪和应用退役。用于数据增长以及应用退役的容量是以从数据源拉出的以千兆字节计的未压缩数据来测量的，并且在成功地执行了导致有效的档案文件的存档请求之后被减少。请求必须是无错的，然而在该过程中可以产生报警和通知消息。如果存档请求的删除部分失败，则仍减少容量，因为所产生的档案文件是有效的，并且在存档过程中消费应当已经被测量。在存档过程成功完成后，特定用于解决方案（数据增长、应用退役）的新CTR以及存档请求被创建并添加到容量目录表。该记录在该记录USED容量（已使用容量）栏中指示未压缩的档案文件大小。当请求CTR被添加时，将容量代币CTR的可用消费从解决方案容量代币（数据增长、应用退役）中减少，以反映总体使用。虽然有分别用于数据增长和应用退役的代币，但是跟踪的方法是相同的。因此，以下示例特别指出于解决数据增长问题的目的而运行的请求。

在这个示例中，预操作CTR具有用于100GB数据增长的已应用的容量代币。在此场景中，客户运行存档请求，其生成包含20GB未压缩数据（在测量了消费之后，文件当然可以被压缩）的档案文件。这个操作导致用于指示20GB使用容量的档案的请求级别CTR。作为这个操作的结果，容量代币CTR的可用容量被减少20GB，剩下80GB的剩余。

如果单个操作必须使用来自多个CTR的容量，则存档请求CTR将为从其消费容量的每个代币进行记录。在一些情况下，档案文件将需要使用来自多个代币的容量。例如，150GB档案文件可以使用来自先前购买的代币的100GB容量，另外来自尚未购买的代币的50GB。直到购买了新代币，否则用于用光的旧代币的“可用容量”将显示为-50GB。

现在将论述测试数据管理（TDM）跟踪。用于TDM的容量是以作为提取操作结果的从数据源提取的以千兆字节计的未压缩数据来测量的，并且在成功地执行了导致有效的提取文件的提取请求之后被减少。所述请求必须无错，然而在该过程期间可以生成报警和通知消息。在这个示例中，跟踪TDM消费需要Optim来维护以下信息：（i）每个提取请求的消费/收费；（ii）每个提取的表使用；（iii）每个表的HWM消费。TDM跟踪比数据增长的跟踪更复杂一点。对于TDM，促使数据子集的频繁创建或刷新，因此优选地是确保这样做成本是不高的。因此，所购买的最初容量代币应当反映用户希望随时间的推移从数据库中提取以满足测试需求的数据的量。Optim将为从其提取数据的每个表记录HWM。只有当随后的提取要求超过先前建立的HWM的附加数据量时，将对附加的消费收费，并且记录新表的HWM。

在提取过程成功地完成后，用于提取请求的请求CTR被创建并添加到容量目录表。所述记录指示包含提取文件的未压缩用户数据的大小。除了请求CTR外，用于参与提取的每个表的子请求CTR将与为该表所消费的容量一起被记录。此外，将添加一组非请求特定表CTR以跟踪用于给定表的HWM。每个容量令牌只需要一个表CTR，因此首先搜索条目以寻找现有的表CTR。如果找到现有表CTR，则只有当前值超过先前记录值时用新的高水位线更新该现有表CTR，以及当补偿消费时仅将减少增量大小。只有当它们超过先前建立的高水位线时，才对站点进行收费。

现在将在TDM上下文中论述消费容量。在提取过程成功完成后，特定于提取请求的新请求CTR被创建并且添加到容量目录表。所述记录在记录的已使用容量（USED_CAPACITY）字段中指示提取的数据的大小。在添加了请求CTR之后，为参与导致数据消费的提取的每个表添加子请求表CTR（如果从特定表中没有提取行，则不应当记录子请求CTR）。子请求表CTR将为特定表调出（call out）已使用容量。记录子请求表CTR的目的是处理与特定提取请求有关的容量的返回，其在以下的（一个或多个）返回容量段落中论述。对于每个子请求表CTR，在容量代币级别进行对于表CTR的查找。如果找到表CTR，则将其当前HWM与在子请求表CTR中所定义的当前使用的HWM相比较。如果子请求表CTR的已使用容量大于表CTR HWM，则用新值替换HWM。然后，新HWM和先前HWM之间的增量被用于计算从全部可用容量中所减去的值。在任何给定时间，所有表CTR HWM值的和必须等于全部使用的容量。

现在，将参照分别在图6A、6B和6C中所示出的截屏在TDM的上下文中论述返回容量。如果提取运行错误或意外运行，则可以调用返回API以返回容量。除了CTR记录中的记录外，生成审计记录，其指示请求了返回操作。当返回与提取请求相关联的容量时，返回请求针对的请求CTR300通过将大小添加到可用容量栏并更新修改日期栏来更新记录（见图6A和6C）。移除与所述请求CTR相关联的所有的子请求表CTR 302（见图6A和6C）。在返回过程中的下一个步骤是重新计算与子请求表CTR 302被移除的所有表CTR 301（见图6A和6C）相关联的HWM值。在调整了所有表CTR之后，调整容量代币CTR 300以增加“可用容量”（如果需要）。图6A至6C示出了数个返回场景的示例。更具体地，在图6A中示出了操作前的CTR。

在操作#1中，执行对EXTRACT3（其消费15GB）的返回，导致在图6B的截屏中所示出的一组CTR。在这个场景中，对于提取3的请求CTR300进行更新，以在可用容量栏（返回容量的指示器）中指示15GB。还更新修改用户和日期以反映用户返回容量。移除了与提取3相关的请求表CTR302。对于涉及EXTRACT3（客户和订单）的表的表CTR 301进行调整以具有新的HWM值。通过扫描所有剩余的请求表CTR 302，对于客户的新HWM值是1GB，以及对于订单的新HWM值是2GB。最后步骤是调整容量代币CTR 100可用容量值，以反映该组新的表HWM值。在此情况下，3GB的消费总量是由组合所有表CTR HWM值来指示的，因此可用容量（AVAIL CAPACITY）增加到197GB。增加的12GB由返回的EXTRACT3的消费来确认。

现在，将论述在图6C的截屏中所示出的示例性代币返回“操作#2”。执行对消费了2.5GB的EXTRACT2的返回，这导致以下一组CTR。在这个场景中，更新用于EXTRACT2的请求CTR（300）以在可用容量栏（返回容量的指示器）中指示2.5GB。还更新修改用户和日期以反映用户返回容量。移除与EXTRACT2相关的请求表CTR302。调整用于涉及EXTRACT2（客户和订单）的表的表CTR 301以具有新的HWM值。通过扫描所有剩余的请求表CTR 302，对于客户的新HWM值是0.5GB，并且对于订单的HWM值不变（2GB）。最后步骤是调整容量代币CTR（100）可用容量值，以反映该组新的表HWM值。在此情况下，2.5GB的消费总量是由组合所有表CTR HWM值来指示的，因此可用容量增加到197.5GB。增加的0.5GB由返回EXTRACT2的消费来确认。如果没有减少HWM值，则返回容量可导致没有增加是可能的。在此情况下，返回操作应当向用户返回消息。

现在，将论述数据屏蔽跟踪。用于数据屏蔽的容量是以在插入、加载和转换操作期间所屏蔽的以千兆字节计的数据来测量的。请求必须是无错的，然而在处理期间可以生成报警和通知消息。用于执行数据屏蔽功能的机制是经由Optim数据隐私提供者（ODPP）库。在这个示例中，跟踪数据屏蔽消费要求Optim维护以下信息：（i）每个插入、加载、转换请求的消费/收费；（ii）每个请求的表使用（只包括参与屏蔽操作的表）；以及（iii）每个表的HWM消费。

类似于TDM，数据屏蔽跟踪比数据增长或应用退役的跟踪更复杂一点。因为数据屏蔽通常是（但是非必须）作为TDM的一部分来执行的，这个过程将促使数据子集的频繁刷新，因此必须确保这样做的成本是不高的。因此，从数据服务提供实体（例如，IBM）购买的初始容量代币应当反映用户随着时间的推移希望屏蔽以满足隐私要求的数据的量。Optim将为数据被屏蔽的每个表记录HWM。只有当随后请求要求附加的数据屏蔽量超过先前建立的HWM时，才对附加的消费进行收费并且记录新表HWM。

在过程成功完成之后，用于插入、加载或转换（包括具有转换选项的提取）的请求CTR被创建并添加到容量目录表。该记录指示被屏蔽并推送到数据源（数据库、文件）的用户数据的大小。除了请求CTR外，对于参与屏蔽操作的每个表的子请求CTR将与为该表所消费的容量一起记录。此外，将添加一组非请求特定表CTR以跟踪用于给定表的HWM。每个容量代币仅需要一个表CTR，因此首先搜索条目以寻找现有的表CTR。如果找到现有表CTR，只有当前大小超过先前记录值，才用新的高水位线更新现有表CTR，以及当补偿消费时将只扣除增量大小。只有当它们超过先前建立的高水位线时，才对站点收费。数据屏蔽（类似于数据增长、应用退役以及TDM）将支持返回代币的概念，从而允许对那些运行错误的操作返回容量。

现在将在数据屏蔽的上下文中论述消费容量。在请求成功地完成后，特定于该请求的新请求CTR被创建并被添加到容量目录表。该记录在该记录的已使用容量栏中指示参与屏蔽操作的表中的数据的大小。在添加请求CTR后，为参与导致数据屏蔽消费的操作的每个表添加子请求表CTR（如果没有从特定表中屏蔽元素，则不应当记录子请求CTR）。子请求表CTR将为特定表调出已使用容量。记录子请求表CTR的目的是处理与特定请求有关的容量的返回。

对于每个子请求表CTR，在容量代币级别进行对于表CTR的查找。如果找到表CTR，则将其当前HWM与在子请求表CTR中所定义的当前使用的HWM相比较。如果子请求表CTR的使用容量大于表CTR HWM，则用新值替换HWM。然后，新HWM和先前HWM之间的增量被用于计算从全部可用容量中所减去的值。在任何给定时间，所有表CTR HWM值的和必须等于全部使用的容量。如果单个操作必须使用来自多个CTR的容量，则对于从其消费容量的每个代币将记录数据屏蔽请求CTR。用于记录的模式（pattern）是与在本文中的数据增长以及测试数据管理跟踪部分中所描述的模式是相同的。

现在，将在数据屏蔽的上下文中论述返回容量。如果请求出现运行错误（或意外运行），则可以调用返回API以返回容量。除了CTR记录中的记录外，还生成指示请求返回操作的审计记录。当返回与插入、加载或转换请求相关联的容量时，通过搜索目录以寻找匹配的返回代币来找到对其做出返回的请求CTR。一旦找到，则通过将原始消费值添加到该记录的可用容量栏，并且更新修改日期栏来更新请求CTR记录。移除与该请求CTR相关联的所有子请求表CTR。在返回过程中的下一个步骤是重新计算与子请求表CTR被分别移除的所有表CTR相关联的HWM值。在调整所有表CTR后，调整容量代币CTR以增加可用容量（如果需要）。

现在将论述容量使用概要报告。为支撑IBM和客户审计需求，Optim将支持对于容量消费的“审计”报告。为支持报告需求，Optim将捕获容量跟踪数据，而不管站点是否已经启用审计。客户将具有生成与容量消费有关的报告的选项。本文将专注于容量消费报告。提供两种形式的OOB报告：概要和详细。以下描述每一种的内容。

现在，将论述容量使用概要报告。概要报告将优选地包括在RVU模型下的每个Optim目录操作的下列信息：（i）用于所有解决方案的购买容量的总数；（ii）用于所有解决方案的剩余容量的总数；以及（iii）应用于目录的容量代币列表，其每个调出：（a）购买的容量，（b）剩余的容量，（c）代币类型（数据增长、应用退役、TDM、数据屏蔽），（d）应用代币的日期，以及（e）返回容量。

现在，将论述容量使用详细报告。详细报告将包括在RVU模型下的每个Optim目录操作的下列信息：（i）用于所有解决方案的购买容量的总数；（ii）用于所有解决方案的剩余容量的总数；（iii）应用于目录的容量代币列表，其每个调出：（a）购买的容量，（b）剩余的容量，（c）代币类型（数据增长、应用退役、TDM、数据屏蔽），（d）应用代币的日期，（e）返回容量，（iv）容量使用细节（每个代币），以及（v）容量解决方案细节（每个代币）。对于数据屏蔽和测试数据管理（表使用），详细使用信息是可获得的。

Claims (13)

1.一种用于管理由数据服务提供实体向数据服务客户提供的数据服务的方法，所述方法包含：

为将由所述数据服务提供实体向所述数据服务客户提供的数据服务建立至少基本上预支付账户，其中预付费由相对价值单位（RVU）表示；

响应于对所述数据库服务的使用，从所述预支付账户中减少至少一个递减RVU；

从所述数据服务客户接收用于返回所述至少一个递减RVU的当前值的请求；以及

返回所述至少一个递减RVU的当前值；

其中：

至少所述接收步骤和所述返回步骤是在由所述数据服务提供实体所提供的软件的控制下自动执行的，并且基本上没有人工干预。

2.根据权利要求1所述的方法，还包括以下步骤：

确定在所述接收步骤所做出的所述用于返回的请求是否是适当的请求；

其中：

只有在在所述确定步骤已经确定所述请求是适当的的条件下，才在所述返回步骤做出所述至少一个递减RVU的当前值的返回。

3.根据权利要求2所述的方法，其中：

所述预支付账户包括：数据屏蔽子账户、数据增长子账户、测试数据管理子账户以及应用退役子账户；以及

每个子账户具有其自身专用的、相关联的RVU储存。

4.根据权利要求2所述的方法，其中：

在所述减少步骤，被减少的（一个或多个）RVU的数量对应于由于错误使用所造成的未压缩数据流。

5.根据权利要求2所述的方法，其中：

在所述确定步骤，在所述至少一个递减RVU的减少已经在所述减少步骤发生的所有情况下，将请求确定为适当的请求。

6.根据权利要求1所述的方法，其中在所述返回步骤，所述至少一个递减RVU的所述当前值的返回是通过将所述至少一个递减RVU返回给所述预支付账户来实现的。

7.一种用于管理由数据服务提供实体向数据服务客户提供的数据服务的系统，所述系统包含客户账户管理计算机子系统，其包含：

处理器集；以及

软件存储设备；

其中：

所述处理器集被构造、编程和/或连接以运行存储在所述软件存储设备中的软件；

所述软件存储设备已经在其上存储了数据库服务模块；以及

所述数据库服务模块被编程为：

为将由所述数据服务提供实体向所述数据服务客户提供的数据服务建立至少基本上预支付账户，其中预付费由相对价值单位（RVU）表示；

响应于对所述数据库服务的使用，从所述预支付账户中减少至少一个递减RVU；

从所述数据服务客户接收用于返回所述至少一个递减RVU的当前值的请求；以及

返回所述至少一个递减RVU的当前值。

8.根据权利要求7所述的系统，其中所述数据库服务模块还被编程为：

确定在所述接收步骤所做出的所述用于返回的请求是否是适当的请求；

只有在已经确定所述请求是适当的条件下，才返回所述至少一个递减RVU的当前值。

9.根据权利要求8所述的系统，其中

所述预支付账户包括：数据屏蔽子账户、数据增长子账户、测试数据管理子账户以及应用退役子账户；以及

每个子账户具有其自身专用的、相关联的RVU储存。

10.根据权利要求8所述的系统，其中：

由所述数据服务模块减少的RVU的数量对应于由于错误使用所造成的未压缩数据流。

11.根据权利要求8所述的系统，其中在所述至少一个递减RVU的减少已经发生的所有情况下，所述数据服务模块将请求确定为适当的请求。

12.根据权利要求7所述的系统，其中所述数据服务模块通过将所述至少一个递减RVU返回给所述预支付账户来返回所述至少一个递减RVU的所述当前值。

13.一种用于管理由数据服务提供实体向数据服务客户提供的数据服务的系统，所述系统包含实现权利要求1至6的任何方法的任何步骤的装置。