专利名称：程序设计方法与装置的制作方法
技术领域：
本发明系有关一种用以进行程序设计之计算机化方法与数据库。
发明之技术背景追踪商业程序传统上来说是一种数据导向的活动。这是具有意义的程序都是有关于操控数据，因此引导程序至数据如何被追踪的议题上将是一种可靠直觉得到的解决方法。例如，考虑一组织图表。如第1图所示，组织图表105典型地包括一位首席执行官110，以及其它未显示在第1图中的高级职员。最终地，在该层次系统下的某处将为部门。第1图显示三个部门部门A115、部门B120与部门C125。各个部门均包括一些雇员，如分别由雇员列表130、135与140所示。
现在请想想当一位雇员改变所属部门时将会发生什么事。例如，假设雇员5将从部门A115搬移至部门B120，如箭头145所示。传统地，雇员5将自雇员列表130中删除且将加入至雇员列表135。
但如果雇员5为进行分配给部门A115之一项目的唯一雇员的话，雇员5将仍属于部门A115吗？如果该项目将分配回给雇员5，它将与部门B120相关，但部门B却完全不熟悉该项目。因此，错误的部门(部门B120)将进行该项目。
数据的改变典型地将需要授权，例如雇员5将从部门A115搬移至部门B120。如果授权与数据变更程序是可以追踪的话，有关该项数据变更的数据将储存为数据目标的一部份。例如，该项雇员信息可以储存授权一位雇员的升职或额外训练的人是谁。但只有在有限的状况下，数据变更是可以追踪的，当每次需要储存该项信息时，将需要特殊用途的实行方法。此外，数据变更信息通常是不完整的。最后，数据变更授权的生命周期将典型地无法被追踪的。
本发明将阐述与现有技术相关的上述与其它问题。
发明之概要说明在上述说明中，由于雇员5移动至部门B120所产生之中断联结的发生原因是，用以进行程序管理的传统模型忽略了一项重要的特点即时间。随着时间的流逝，数据会改变。在传统上该变更并无法被追踪数据库仅能储存目前最新的信息。
为了完成历史数据，数据变更信息将为系统中所有的数据变更而保留。但数据变更信息并不与数据目的本身一同储存。反之，该等变更将分别地被储存。有关数据变更而储存的信息种类几乎是没有差异，即使是变化中的该种数据客体具有相当大差异性。例如，该数据客体是否为一雇员或为一项配备，变更有关该客体数据的程序将仍必须经过多个步骤，例如要求一项变更、同意该项变更，且进行该项变更。
本发明将包括一种装置，其用以管理计算机中的程序设计。包括内存的一计算机将储存一项基础数据与可在该基础数据上运作的控件。当该基础数据需要进行更新时，该控件将用来修正该基础数据。
本发明同时包括一种方法，其用以管理程序设计。将利用可在该基础数据上运作的一控件来产生基础数据的未来修正例。数据将输入在该控件中，且插入至未来修正例中。该未来修正例将随后变更为一目前修正例，以使一项稍早的目前修正例变成历史修正例。
本发明之上述与其它优点、目的与优点将在以下参照附录图式的说明中更为明显。
图标的简要说明第1图展示现有技术中数据组织的一范例。
第2图展示一计算机系统，其根据本发明之较佳实施例设计以管理程序设计。
第3图展示一计算机系统，其根据本发明之一替代实施例设计以管理程序设计。
第4图展示一项基础数据，其由根据本发明之较佳实施例的控件所控制，且可使用在第2图之计算机系统的数据库中。
第5图展示根据本发明之较佳实施例的一交叉点，其可使用在第2图之计算机系统的数据库中。
第6图展示一项观察，其由根据本发明之较佳实施例中的控件所控制，且可使用在第2图之计算机系统的数据库中。
第7图展示展示一项交易，其由根据本发明之较佳实施例中的控件所控制，且可使用在第2图之计算机系统的数据库中。
第8图展示一具有准则与样板的产生器，该准则与产生器将用以激活根据本发明之较佳实施例的一控件，且可使用在第2图之计算机系统的数据库中。
第9图展示一累积器，其根据本发明之较佳实施例，累加第4图中基础数据的交易。
第10图展示可使用在第2图之计算机系统的数据库中的原始类型、类型、实例与修正例层次系统。
第11图展示根据本发明之较佳实施例，具有多个修正例之第4图的基础数据。
第12图展示第11图中修正例之状态标记的状态图。
第13A图与第13B图展示根据本发明的较佳实施例，第4图中基础数据的多个可接受与不可接受″未来″修正例。
第14图展示根据本发明的较佳实施例，第4图中控件的步骤范例。
第15图展示根据本发明的较佳实施例，第14图中控件的修正例。
第16图展示一控件，其由根据本发明之较佳实施例的第二控件所控制，且其可在第2图之计算机系统中的数据库中使用。
第17图展示根据本发明的较佳实施例，第5图中二项基础数据之间相关数据的交叉点。
第18图展示根据本发明之较佳实施例，第17图中交叉点的修正例。
第19图展示第2图中计算机系统之数据库的数据概念组织。
第20A图至第20D图展示根据本发明之较佳实施例，利用一控件来修正一基础数据之程序的流程图。
第21A图与第21B图展示根据本发明之较佳实施例，当与该交叉点相关之基础数据被修正时，用以修正一交叉点之程序的流程表。
第22A图与第22B图展示根据本发明之较佳实施例，用以对基础数据进行一项观察之程序的流程表。
第23A图与第23B图展示根据本发明之较佳实施例，用以执行一项交易之程序的流程表。
第24图展示根据本发明之较佳实施例，利用一样板用以产生一控件之程序的流程表。
较佳实施例的详细说明第2图展示一计算机系统，其根据本发明之较佳实施例设计以管理程序设计。在第2图中，服务器205为连结至互联网210的一服务器。服务器205可由任何其它可存取互联网210的计算机，透过互联网210来存取，如以下所说明。未显示在第2图中的是服务器的正常组件，例如中央处理器、内存等等。
服务器205将从数据库212进行检索且将储存至数据库212。数据库212将储存有关管理程序设计的信息。例如，数据库212将储存已储存在原始类型之类型与实例中的数据(请参照以下第10图以了解有关类型与实例的更多信息；原始类型可被服务器了解但并未储存在数据库中)。
数据库212的分布式存取可致能多位使用者存取数据库212，而每位使用者并不必实行个别程序设计管理数据库。由于本发明的上述内容可以不需定制化便可由多位使用者运作，运作数据库212为分布式数据库将可避免使个别使用者必须维持数据库212的副本。因此，例如，计算机系统220上的使用者可以透过互联网210与公司网络215来存取数据库212。这将可利用应用服务供应者(Application Service Provider、ASP)模型来管理程序设计。对数据库212中之数据进行存取是可以被控制的，因此使用者无法观看他们未被允许观看的数据。
数据库212的分布式存取同时将致能控件与基础数据与企业相交。会发生的事是，一企业将具有利用第二企业的控件进行修正的基础数据。例如，企业的机器(第一企业的基础数据)可能可以由外来的服务公司(第二企业的控件)来进行修复。藉由致能数据库212的分布式存取，可以描绘跨企业关系性，该关系性很难在独立的格式中利用数据库212来描绘。
虽然第2图展示服务器205为一独立式、个别且储存数据库212的服务器，熟知技艺者将可了解的是可能有其它的配置。例如，服务器205可以为储存局域网络(Storage Area Network、SAN)的一部份，该局域网络将利用分散方式在网际网络210上储存数据库212。第3图同时展示一种用以储存数据库212的替代配置，当程序设计管理并不对网际网络210进行外部存取时，便可使用该项替代配置。
第3图展示一计算机系统，其根据本发明之一替代实施例设计以管理程序设计。在第3图的替代实施例中，计算机220仍为一公司所有的计算机。但在第3图中，数据库212将可直接从计算机系统220存取，而不必为透过网际网络存取的分布式数据库。习知地，计算机系统220将包括计算机310、监看器315、键盘320与鼠标325。并未展示在第3图中之选择性配备可包括打印机与其它输入/输出装置。同时未展示在第3图的是计算机系统220的习知内部组件，例如中央处理器、内存、档案系统等等。
第4图展示一项基础数据，其由根据本发明之较佳实施例的控件所控制，且可使用在第2图之计算机系统的数据库中。在第4图中，基础数据405将用来陈述有关程序设计之一客体的数据。基础数据405为一原始类型，其用以储存程序设计中任何客体类型的数据。将于第4图至第9图中说明的其它重要原始类型可包括控件415、交叉点515、观察615、交易715、准则805、产生器810、样板815与累积器915。原始类型并不直接储存数据，但可以作为样板，数据储存模型与客体将可从该样板产生(分别称为类型与实例)。原始类型、类型与实例的概念将参照以下第20图作进一步的讨论。除了参照第10图之外，本发明的其余部分将仅参照原始类型来说明。本文内容将协助读者来鉴别是否原始类型、类型或实例实际上是需要的。
控件415将控制基础数据405中数据的配置。虽然基础数据405是用来储存数据，储存在基础数据405中的数据并不是可以直接修改的。反之，控件415将负责根据数据输入来修改基础数据405(将参照以下第11图作更进一步的讨论)。相似地，控件415将控制对一交叉点、观察或交易的数据插入，如下所述。
如基础数据405的基础数据以及如控件415的控件将经过修正。换言之，它们将随时间改变。第4图将图标呈现出该种改变与控件420-1、420-2与420-3将分别地联系至基础数据410-1、410-2与410-3的分层过程。在第4图中，基础数据405为″目前″基础数据，而基础数据410-1、410-2与410-3并不是″目前″基础数据。基础数据410-1、410-2与410-3可以为″未来″修正例、″历史″修正例、″控件″修正例、或″失效″修正例的基础数据。相似地，控件415将为″目前″控件，而控件420-1、420-2与420-3并不是″目前″控件。″未来″、″历史″、″控件″与″失效″修正例的意义将参照第11图与第15图在以下作更详细的说明。
虽然并未展示于第4图中，单一控件可以负责同时地修改许多基础数据中的数据。例如，如果企业从一处搬移至另一处，所有部门的地址都会改变。单一控件可以致能各个部门基础数据之地址的变更，而不利用因着搬迁来影响各个部门的不同控件。熟知技艺者将可了解的是，此项应用的延伸将适用于由控件所管理的其它原始类型中。
第4图将展示控件415为负责修正基础数据405中之数据。控件可以同时负责修正其它的控件。如何进行修正将在以下参照第16图作进一步的说明。
第5图展示根据本发明之较佳实施例的一交叉点，其可使用在第2图之计算机系统的数据库中。在第5图中，交叉点515将与基础数据405与510发生相关联。这将致能跨越二种概念的信息在数据库中进行连结。例如，有关雇员的数据可以与有关部门的数据发生关系，以指明哪位雇员将为哪个部门工作。交叉点515将由控件415所控制。如基础数据与控件一般，交叉点可以经历修正过程交叉点修正例将参照以下第18图作进一步说明。
第6图展示一项观察，其由根据本发明之较佳实施例中的控件所控制，且可使用在第2图之计算机系统的数据库中。在第6图中，观察615将根据基础数据405的观点来观察基础数据510。例如，基础数据510可以说明具有油箱位准的汽车引擎，而基础数据405可以说明测量油箱位准的人。观察615将由控件415来控制。
与观察相关的是相同的额外因素。相关于观察的一项额外因素是用以进行测量的工具。例如，在测量汽车引擎中之油箱位准的过程中，加油站的加油人员可以利用一种工具来鉴别汽车引擎中的油量。各个工具便是一种观察基础数据。因此，可以有多种基础数据来观察已观察的基础数据510。
熟知技艺者将可了解的是，虽然用于上述汽车引擎范例中的工具是典型地一种机械装置(即油尺)，也可以使用其它种类的工具。工具可以比简单的油尺更复杂，也可以利用除了机械之外的操作方式(即电动操作)来操作。工具校准的正确性将是相关的，不论该工具的特性为何。
与观察相关之第二因素将适用于该项观察的任何外部状况。外部状况是观察的一部份且可影响该项观察的结论。例如，该汽车引擎是冷的或热的将可影响任何与测量相关的结论。如果车子的引擎是冷的，该项观察可指示出车中的油将多于实际上存在的油。或者，根据汽车的特定种类，已观察出的油量可能太多、太少或刚好。为了从一项观察得到正确的结论，将使用说明状况的参数。观察界定基础数据625将鉴别何种类型的基础数据将被使用以进行该项观察且储存所需参数来界定该等状况。观察界定基础数据625同时将鉴别需要何种基础数据来观察已观察基础数据510。熟知技艺者将可了解的是，观察界定基础数据625可以界定许多观察项目。
第7图展示展示一项交易，其由根据本发明之较佳实施例中的控件所控制，且可使用在第2图之计算机系统的数据库中。在第7图中，交易715将用来执行基础数据405与基础数据510之间的交易。为了执行交易715，信用基础数据405将供应一种资源(且对该资源付费)，且请款基础数据510将接收该资源(且为该资源付费)。报价基础数据720将用来鉴别请款基础数据510必须支付信用基础数据405该项资源的费用。例如，基础数据405可描述一位雇员的工作(即时间)，且基础数据510可描述部门将支付薪资。为了交换雇员为该部门所作的工作，该部门将支付雇员薪资，进而完成该项交易。其它种类的交易包括核发库存清单且接收支付一份帐单的金钱。交易715将由控件415所控制。
要注意的是，虽然在上述范例中，金钱将用来支付所转换的资源，该已转换资源可以使用除了金钱以外的计价单位来标价。此外，典型地该已转换资源与其价格是独立的。交易将遵从着合记式会计制度(dual entryaccounting)来进行。最终地，交易715并不修正任何信用基础数据415、请款基础数据510或报价基础数据720。
第8图展示一具有准则与样板的产生器，该准则与产生器将用以激活根据本发明之较佳实施例的一控件，且可使用在第2图之计算机系统的数据库中。产生器与样板可以用来自动地激活控件，以处理由人类所引起的不正常状况。例如，假设一台机器需要润滑油。虽然雇员将经常地检查该机器是否具有足够的润滑油，该项工作并不包括鉴别是否有问题发生。
但如果机器需要润滑油呢？一般来说，激活一项控件以在该机器中加入润滑油将需要人类的加入。但利用一产生器与一样板，控件可以自动地激活。准则805将典型地来自于一项观察或一项交易。但熟知技艺者将了解的是，其它原始类型可以用来满足准则805。产生器810将评估准则805以鉴别是否需要一控件。随后，如果该项评估将指示出需要一控件的话，产生器810将产生激活数据；将该数据加入至样板815的副本中，其将成为控件415。要注意的是，产生器810可以有任何数量的准则。此外，虽然第8图展示的样板815只有一个产生器，样板815可以有许多不同的产生器，且产生器810可以使用许多样板815来激活许多控件415。
再度假设上述范例中的机器需要润滑油。可以藉由测量该机器的润滑油来决定准则805。产生器810将评估该准则以鉴别该机器是否需要润滑油。若该机器需要润滑油的话，产生器810将产生激活数据，例如哪台机器需要润滑油且需要加进多少的润滑油，且传送该激活数据至样板815。相对地，样板815，将激活开始加入润滑油至该机器的程序的控件415。相对地，如果准则805指示出该机器已有充足的润滑油的话，便不需要控件。准则805随后并不需要传送任何数据至产生器810。
同时要注意的是，准则805可以是通称的，对基础数据实例而言并不是特定的。再次假设需要润滑油之机器的范例。如果在不同时间取得机器的话，机器所需要之润滑油的位准也将不同。准则805不应该使用固定量的润滑油来作为激活一控件的决定性因素，因为具有充足润滑油的机器可能不需要服务，或更糟的，需要润滑油的机器可能未被服务。准则805将存取各个基础数据实例的数据，以鉴别该基础数据实例是否需要一控件。这将使准则80能为所有基础数据实例进行一般的运作。
第9图展示一累积器，其根据本发明之较佳实施例，累加第4图中基础数据的交易。累积器915将负责根据基础数据来加总所有交易。例如，如第9图所显示，累积器915将加总交易715、905与910。虽然在第9图中显示出三项交易，熟知技艺者将了解的是，累积器915可以加总任何数量的交易。藉由累加基础数据405，将可以决定累积器915将使用何种交易。再者，交易可以由任何数量的累积器来累加。
既然已经讨论了不同的原始类型，可说明原始类型、类型与实例之间的差异。原始类型将用来分类位于程序设计中最高位准的数据客体。另一方面，类型将代表模型，其可以产生个别数据客体以储存数据。实例将代表个别类型的逻辑性事件。最终地，将为实例产生修正例，且实际上地储存该数据。这将有助于从下至上考量此层次系统修正例将储存数据、实例将鉴别数据客体、类型将以共同主题来界定实例的分类，且原始类型将界定类型的分类(百万类型)。
与原始类型、类型、实例与修正例之层次系统相似的为语言系统。语言学家已经鉴别出有多种语系，例如印欧语系、汉藏语系等。在各个语系中，有个别的语言，例如印欧语系中有英语和法语，而汉藏语系中有中文与日文。各种语言都有不同的方言，例如中文的方言有北京话和广东话。最终地，方言将随着时间演变，而新的词语将出现且旧的词语将从方言中消失。语系可相比于原始类型，而语言可相比于类型，而方言可相比于实例，而方言中的变更可相比于修正例。
第10图展示可使用在第2图之计算机系统的数据库中的原始类型、类型、实例与修正例层次系统。对各个原始类型来说，例如原始类型1005，可以有多种类型1010、1015与1020。对各个类型来说，可以有多种实例。因此，在第10图中，类型1010将具有四个实例1025，类型1015将具有三个实例1030，且类型1020将具有五个实例1035。例如，如果原始类型1005为基础数据，类型1010可为雇员数据的基础数据类型，类型1015可为部门数据的基础数据类型，且类型1020可为机构数据的基础数据类型。随后，对雇员数据之基础数据类型1010来说，四个实例1025将代表四位雇员的数据客体。在各个实例中，可以有多种修正例。所以，如果实例1025-1代表有关单一雇员的信息，修正例1040将说明加班工作的雇员。
熟知技艺者将可了解，从各个原始类型产生的类型数以及从各个基础数据类型产生的实例数，将仅被使用者的创造力与应用需求所限制。因此，虽然在第10图中展示了三种类型1010、1015与1020，可以有较多或较少的类型。相似地，虽然基础数据类型1010仅展示了四个实例1025，可以有较多或较少的实例。
第11图展示根据本发明之较佳实施例，具有多个修正例之第4图的基础数据。在第11图中，基础数据405包括四个修正例1105-1、1110-1、1115-1与1120-1。修正例1105-1为基础数据的第一修正例(即第一个插入至基础数据的数据)。虽然基础数据405包括雇员数据，熟知技艺者将可了解的是，基础数据405可以储存程序设计任何有关的客体。熟知技艺者将同时可了解的是，虽然展示了四个修正例，也可以展示多于或少于基础数据中的四个修正例。
除了基本雇员数据之外，修正例1105-1包括字段，例如修正例号码1105-2、修正例日期1105-3、修正控件1105-4与状态标志1105-5。修正例号码1105-2将储存基础数据中修正例的数量如所见的，修正例将较佳地依序地编上号码。修正例日期1105-3将储存修正例发生的日期。修正例日期1105-3实际上并不需要储存在修正例纪录1105-1中，因为修正例日期可以从修正控件1105-4中鉴别出来。修正控件1105-4将鉴别该控件要加入修正例1105至基础数据405中。确切地，修正控件1105-4将根据类型、实例与修正例号码来鉴别该修正控件。这将致能使用者快速地追踪在何种程序中的何种步骤产生了基础数据405的修正例。控件与控件中的修正例将参照以下第14图至第15图作进一步的说明。最终地，状态标志1105-5将标示出修正例的状态。
修正例可以在五种不同的状态中，且在第11图将展示出所有五种状态。″历史″修正例将以状态标志″H″代表，展示为修正例1105-1。″目前″修正例将以状态标志″C″代表，展示为修正例1115-1。″未来″修正例将以状态标志″F″来代表，展示为修正例1125-1。″控件″修正例将以状态标志″×″为代表，展示为修正例1110-1。且″失效″修正例将以状态标志″○″为代表，展示为修正例1120-1。
状态标志″H″与″C″的意义将相当具直觉性″历史″修正例为过去通用但现在已不再通用的修正例，而″目前″修正例将为储存目前正确数据的修正例。要注意的是，在任何时候应该只有一个″目前″修正例。即使当一项控件已经终止了(不论正常终止或不正常终止)，也只有一项控件的″目前″修正例。不会再有控件的″未来″修正例(因为控件已经完成)，这意味着代表完整状态之控件的″目前″修正例从未被改变。
但其它状态标志是较不具直觉性的。如果改变基础数据中之数据的程序是正常地完成的话，″未来″修正例将反映出可能变成通用的修正例。″未来″修正例可以于多种方式发生。方式之一是，″未来″修正例可以发生，当控件正在进行更新基础数据但尚未完成时。例如，假设晋升雇员的一控件。在该项晋升发生之前，不同管理者，例如部门监管者与部门管理者，必须核准该项晋升。典型地，晋升将不会被拒绝，因为不应该接收晋升的雇员典型地并不会被提拔。因此，″未来″修正例可以加至指明该项晋升的基础数据中，但在晋升完全核准前，才会变成″目前″修正例。
″控件″修正例为″未来″修正例，其已经由相同控件下的其它″未来″修正例接替。再度地，假设想要晋升一位雇员的部门监管者。晋升雇员的程序将由一项控件所管理，该控制向将产生该雇员之基础数据的″未来″修正例。当部门管理者核准该项晋升时，他可提出新的薪资。新的″未来″修正例将随后产生在雇员的基础数据中以反映出晋升被核准时的数据，包括新的薪资。较早的“未来″修正例，其仅反映出该部门监管者所提出之薪资，将被更新，因此″未来″修正例将不再被考量。稍早的″未来″修正例不应该成为″目前″修正例，因为晋升程序并未完成。它应该被删除，因为它是该雇员之历史数据的一部份。将稍早的″未来″修正例标示为″历史″将是令人困惑的，因为在修正例变更为″历史″修正例之前，它必须为″目前″修正例。解决的方法是变更稍早的″未来″修正例为一″控件″修正例。此将指示出修正例曾经是″未来″修正例，其已经由稍后的″未来″修正例所取代，且仅为了控制的目的而存在。
″失效″修正例为由控件所管理的″未来″修正例，而该控件不正常地终止。当控件到达了完成状态时，由该控件所管理之基础数据(或其它原始类型)将被检查以确定没有剩下之由该控件产生的″未来″修正例。如果该控件已经完成但在基础数据中留下″未来″修正例的话，该等″未来″修正例将不会被变更为″控件″或″目前″修正例。此时，该等″未来″修正例将变更为″失效″修正例。
再次假设想晋升一位雇员的部门监管者。但如果该部门管理者否决该项晋升的话，该项程序将不正常地终止。由控件所产生的″未来″修正例不应该被删除，因为它为该雇员之历史数据的一部份，但它也不应该标示为″未来″修正例，因为它随后将与其它″未来″修正例发生冲突(参照以下第13A图与第13B图)。藉由将该修正例变更为″失效″，很清楚的是该修正例并不为异常终止之程序的一部份，且并不会变成″目前″或″历史″。
第12图展示第11图中修正例之状态标志的状态图。在第12图中，修正例将首先被标示为″未来″修正例，如阶段1205所展示。″未来″修正例可以变更为″控件″修正例(阶段1210)，因为当正常进行时，修正控件将更新″未来″修正例，或者如果修正控件异常地结束时，将变成″失效″修正例(阶段1215)。当该修正控件指示出应该要使″未来″修正例变成目前修正例时，″未来″修正例将变更为”目前″修正例(阶段1220)，其当一稍后″未来″修正例变成″目前″时，将最终地成为″历史″修正例(阶段1225)。
现在请参照第11图，修正例1110-1、1115-1、1120-1与1125-1将更新基础数据405的最初修正例11051。在较佳实施例中，不为″目前″的修正例，例如修正例1110-1、1120-1与1125-1，将仅储存基础数据405中的字段，其已经相对于先前的修正例而变更。藉由仅储存已变更字段，基础数据405将在数据库中使用较少的空间。″目前″修正例，例如″目前″修正例1115-1，将在储存完整版本之基础数据的数据，如其目前存在一般，包括可能为从先前″历史″修正例变更的数据。藉由观看单一修正例，将致能存取目前数据。但熟知技艺者将可了解的是，目前数据的鉴别可以藉由激活基础数据之第一″历史″修正例且依序地施加该等变更来进行。要注意的是，各个修正例包括一序列修正例号码1105-2、1110-2、1115-2、1120-2与1125-2。
在修正例变更为”目前″之前，必须先测试以确保该数据是一致性的且有效的。例如，在公司中特定职位的人将享有事先界定范围间的薪资，如果该薪资已超除该职位所应有的范围的话，该项数据将不一致。相似地，一位雇员的薪资不能是负数该数值将是无效的。但这些限制将不适用于″未来″修正例。未来″修正例修正例可以是不一致的或为无效数据，只要该不一致性与无效数值问题能在“未来″修正例变更为″目前″修正例之前解决。假设″未来″修正例1125-1。公司可能指出S-2管理者的薪水将界于年薪美金$50,000与$60,000之间。如果″未来”修正例1125-1被变更为“目前″修正例的话，该项数据将是不一致的，因为雇员的薪水现在只有年薪美金$45,000。但在“未来″修正例1125-1变更为”目前″修正例之前，该不一致性并不需要被解决。
当管理在基础数据上运作之程序的控件指示出该是时候要更新基础数据时(典型地，当该控件终止时，基础数据更新将完成，但这并不是必须的)，″目前″修正例将变更为″历史″修正例，且一″未来″修正例将变更为″目前”修正例。当修正例即将变更为″目前″修正例时，修正例将被测试以确保数据是一致性的且有效的。任何不一致性或无效数据将随后被标示以进行校正。
第11图仅展示各个修正例的类型之一。例如，第11图仅展示单一″未来″修正例1125-1。熟知技艺者将了解的是，在相同的时间中，各个类型可以有多种修正例(除了″目前″修正例之外)。多种″历史″修正例将反映出发生在过去的变更为一基础数据，而多种”未来”修正例将反映可在未来进行的修正例将变更为一基础数据。例如，人力资源雇员将更新一位雇员的个人信息，而同时间管理者将处理该雇员的晋升。
当有多个”未来″修正例时，将可适用某些额外的规则。当多个″未来”修正例更新不同字段时，并不会有问题。但当多个“未来”修正例将更新相同的字段时，将出现冲突。假设一种状况，其中二个控件将同时进行更新，例如一位雇员的薪水。因为″未来″修正例并不是目前的修正例，没有人可以观看到其它人的更新。如果″未来″修正例最终地变成目前修正例的话，″未来″修正例可终止产生忽略了其它的″未来″修正例的一修正例。基于此原因，更新相同字段之所有″未来″修正例必须符合该字段的相同未来值。如果″未来″修正例并不符合该数值的话，在任一控件前进至下一状态之前(修正例)，冲突必须被解决。
第13A图与第13B图展示根据本发明的较佳实施例，第4图中基础数据的多个可接受与不可接受″未来″修正例。在第13A图中，修正例1115-1为基础数据之″目前″修正例。二个″未来″修正例1125-1与1305-1将被展示“未来″修正例1305-1将更新该雇员的电话号码，而″未来修正例1125-1将给予该雇员新的职位与新的薪资。因为在“未来″修正例1305-1与1125-1字段之间并没有冲突，将可处理二个″未来”修正例。
相对地，在第13B图中，″未来″修正例1310-1与″未来”修正例1125-1将修正该薪水字段，且修正为不同的数值。这将产生一项冲突，且直到该冲突被解决为止(由未修正薪水字段之″未来″修正例之一，或由符合该薪水字段中的共同数值之″未来”修正例1310-1与1125-1)，控件不会前进至下一状态。
第14图展示根据本发明的较佳实施例，第4图中控件的步骤范例。在第14图中，将展示雇用新雇员的样本程序之控件1402。在步骤1405中，监管者将建议雇用一位新的雇员。在步骤1415，将界定该新雇员的职位。在步骤1420，管理者将覆阅该项提议。步骤1425，假设管理者并未拒绝该项提议，在步骤1430，新的职位将被公告出来。在步骤1432，将搜集对该职位有兴趣之人员的履历表。在步骤1435，将检视履历表以找出适合该职位的候选人。在步骤1440，候选人将进行面试。在步骤1445，将选出一位候选人。在步骤1450，将与选出的候选人商谈工作条件，且在步骤1455，便不会再有职缺。
大部分的熟知技艺者将了解，虽然控件1402展示的程序是依序的，但实际上却是重复的程序。换言之，在控件1402的任何一点，程序可以依据任何原因传送回至稍早的步骤。例如，在步骤1420，检视职位界定的管理者可以将该职位界定送回至步骤1415以进行再次确定。相似地，如果在步骤1450中，该候选雇员所要求的工作条件是该公司不愿提供的，程序将返回步骤1445，且选出一位新的候选人，或甚至将程序传送回步骤1420中的管理者覆阅，其可以拒绝雇用新的雇员，在步骤1425。
要注意的是，在″步骤″1430，公告的步骤将被标示为二个圈圈。这代表着该项公告步骤是由分别的控件所处理，其负责找出公告的适当位置，且对该公告进行付款等。该公告控件实际上不是第14图之控件中的一个步骤(因此该将标示出该用语)，这是为什么虚线将用来包括控件1402中的公告″步骤″1430，这也是为什么从管理者检视步骤1420至履历表搜集步骤1432之间会有一条直线。但履历表搜集步骤1432并无法开始，直到公告步骤1432完成为止。这将展示出，一控件可以负责插入一数据至到另一控件。
第15图将根据本发明的较佳实施例，展示第14图中控件的修正例。在第15图中，控件415的修正例将展示出监管者/管理者等，其负责掌管各个步骤。控件修正例1505-1、1510-1、1515-1、1520-1与1525-1的结构将相似于第11图中之基础数据405的修正例，其中该控件修正例将储存数据、具有修正例号码且追踪步骤被掌管的日期，尽管有一些差异。首先，控件修正例1505-1、1510-1、1515-1、1520-1与1525-1的主要功能是储存掌管各个步骤的主管机构，虽然熟知技艺者将可了解控件修正例1505-1、1510-1、1515-1、1520-1与1525-1可以储存额外的数据。
再者，大致上来说，控件修正例并不包括修正控件的参考值。但当一控件修改另一控件时，如第16图所示，该修正控件将对照于已修正的控件，如控件修正例1525-1所示，其将相关于修正控件1525-4。在第16图中，一控件将由第二控件所控制。例如，可能发生的是，适用于一控件的时间表将需要被修正(例如日期需要被变更)。但因为该日期是敏感的，改变该日期将需要管理者的同意(即授权)。只有当管理者同意时，才可以修正日期。第16图将展示一控件，例如控件1605，将可以管理另一控件，例如控件415。
再回到第15图，同时要注意的是，控件修正例可以具有上述参照第11图所讨论的任何不同的状态标志。″历史″与″目前″修正例在修正基础数据的控件的方面来说是即刻有意义的。当一控件修改另一控件时，将发生″控件″、″未来″与“失效″修正例。
第17图根据本发明的较佳实施例展示第5图中二项基础数据之间相关数据的交叉点。本发明的基本概念是，不同的类型的数据将被分开保存。因此，雇员数据1705并不储存个别雇员工作的部门，且部门数据1715并不储存哪位雇员在哪个部门中工作。如第17图所示，雇员数据1705与部门数据1715可以视为本质上相异的数据类型。
如上参照第5图所述，交叉点将用来使来自二个基础数据的数据产生关系。因此，为了储存哪位雇员在哪个部门中工作，且反之亦然，将使用交叉点。第17图将展示多个交叉点，其用以使雇员数据705与部门数据1715相关联。基础数据1710将展示在雇员数据1705与单一雇员相关的修正例。基础数据1720将展示在部门数据1715与单一部门相关的修正例(虽然第17图仅展示雇员数据1705中的一项基础数据与部门数据1715中的一项基础数据，熟知技艺者将可了解，对各个数据类型来说，可以有许多基础数据，且各个数据类型之基础数据的数目并不需要相符合)。交叉点515包括鉴别基础数据1710的三个修正例(对雇员5)的雇员参考值1725-1，且包括鉴别基础数据1720的三个修正例(对部门B)的部门参考值1725-2。
参考值1725-1与1725-2将储存为三份。如基础数据修正例，该三份参考值将鉴别已鉴别出之基础数据的类型、实例与修正例(如基础数据修正例，只有一原始类型是期望的，且因此原始类型ID并不需要包括在内)。例如，因此参考值1725-1将对照基础数据类型2中雇员5之实例的第三基础数据修正例(基础数据类型2将表示雇员数据1705)。
如基础数据与控件，交叉点可以具有修正例。第18图将显示根据本发明较佳实施例中，第17图之交叉点的修正例(第18图将利用图表，而不是第11图与第15图所使用的″卡片目录″格式来展示，由于欲展示信息数量的关系)。在第18图中，交叉点515将展示为与部门相关的雇员。图表1805将展示在进行任何变更之前的交叉点515。如纪录1805-1、1805-2与1805-3分别所示，部门A将雇用雇员5、3与1。图表1805中第一行中的″C″将指示出纪录1805-1、1805-2与1805-3是”目前的”。
有二种方式可以更新交叉点。第一，可以更新因着交叉点相关的基础数据之一。当发生时，该交叉点将自动地更新以反映出已修改基础数据中的新修正例纪录。例如，假设雇员迁移至新的地址。在图表1810中，雇员5的基础数据已被更新。交叉点515的控件将产生交叉点纪录的″未来”修正例(在图表1810中并未显示)，其反映出雇员5之基础数据的新”目前″修正例。当该控件完成更新交叉点515时，该交叉点修正例将变更为″控件″修正例(输入项1810-1)。旧交叉点纪录1805-1将变更为″历史”，且新″目前”交叉点纪录1810-2将加入至图表1810。
但要注意的是，当一相关基础数据被修正时，交叉点并不应该自动更新。例如，假设一组态管理系统，其中一项配备将符合目前规格。具有该规格之配备的相关将用一交叉点代表。但如果该规格被更新了，该配备将未必需要更新来符合新的规格。该交叉点应继续使该配备与较旧的规格相关。
第二种可以更新交叉点的方式是，当基础数据之间的关系性变更时。当发生时，所有”目前″修正例将变更为″历史″，以使新的”目前″修正例反映出新的关系性。例如，假设雇员5将转换到部门B，且雇员10将加入部门A来置换离开的雇员5。在图表1815中，雇员10的基础数据已经产生了。交叉点515的控件将随后用来反映出雇员的新结合。″未来″修正例(未显示在图表1815中)将为雇员与部门之间的各个关系性产生。这些″未来″修正例将变更为″控件″修正例，一旦所有关系性均正确地建立了(输入项1815-1、1815-2、1815-3与1815-4)。最终地，新修正例将产生且变更为″目前″(输入项1815-5、1815-6、1815-7与1815-8)。
虽然第17图至第18图展示基础数据之间的相关信息的交叉点，熟知技艺者将可了解的是，交叉点可以相关其它原始类型之间的信息。例如，一交叉点可以相关二个控件之间的信息。
第19图展示第2图中计算机系统之数据库的数据概念组织。层次系统1905展示后续关系性数据库管理系统与上述原始类型之间的关系性，以及使用者接口。在位准0(1910)，关系性数据库管理系统将用来储存信息。位准1(1915)将包括原始类型基础数据、控件、交叉点等等。最终地，位准2(1920)将代表使用者接口，透过该接口将可存取数据库。
位准1(1915)将保留在位准2(1920)中产生的图表，以支持本发明的实施例。例如，基础数据的规则将指示出，一基础数据图表将具有某些属性，且将在该图表中进行些程序。但要展示如第19图中的架构是正确的但却是误导人的。在本发明的较佳实施例中，原始类型将在应用服务器中实行。但熟知技艺者将可了解的是，原始类型规则可以用不同方式实行。例如，原始类型可以实行为与数据库之图表相关的程序，因此，图表本身将执行原始类型的使用。原始类型规则将随后复制于使用者接口的每次出现时。
虽然上述之管理程序设计能大大地改进程序设计，但从使用者的观点来看，实际上并没有真正产生变更。例如，使用者可以利用熟悉的字段名称与布置来输入数据为格式。原始类型的施行规则将在幕后进行。这表示使用者不需要学习新的系统来利用本发明。
第20A图至第20D图展示根据本发明之较佳实施例，利用一控件来修正一基础数据之程序的流程图。在步骤2005(第20A图)，控件的”未来″修正例将产生。在步骤2010，控件及/或基础数据数据将被输入。在步骤2015，一项交换将根据接下来将进行的事件而发生。如果基础数据将被修正，随后在步骤2020，基础数据的″未来″修正例将产生。随后，在步骤2025，基础数据的″未来″修正例将连结至控件的修正例。该程序将返回至步骤2010。
或者，如果在步骤2015中控件的路径将被安排，随后在步骤2030中(第20B图)，数据将被验证以确定任何必要数据将被提供，且所有提供数据将是有效的。在步骤2035，数据将被检查以观看是否该验证步骤(步骤2030)是成功的。如果该项数据不是有效的，随后该程序将返回步骤2010(在第20A图)。否则，在步骤2040，控件的″目前″修正例将变更为″历史″修正例。在步骤2045，基础数据的″未来″将变更为″控件″修正例。在步骤2050，控件的″控件″修正例将复制为″目前″修正例。在步骤2055，基础数据的”控件″修正例将复制为″未来″修正例。在步骤2060(第20C图)，将检查基础数据以确定是否它将会被修正。如果该基础数据将被修正，那么在步骤2065中基础数据的″目前″修正例将合并至基础数据的″未来″修正例。在步骤2070，基础数据的″目前″修正例将变更为″历史″修正例，且在步骤2075，基础数据的”未来″修正例将变更为基础数据的″目前″修正例。
在步骤2080(第20D图)，是否该基础数据已在步骤2060被修正，该控件将被检查以确定是否将需要进一步的处理。如果需要的话，那么程序将返回至步骤2010(第20A图)。否则，在步骤2085，基础数据将被检查以确定是否已经被修正。如果该基础数据尚未被修正，随后在步骤2090，基础数据的未来″修正例将变更为″失效″修正例，在步骤2090之后，程序将完成。
第21A图与第21B图展示根据本发明之较佳实施例，当与该交叉点相关之基础数据被修正时，用以修正一交叉点之程序的流程表。在步骤2102，由交叉点相关的基础数据将被修正。在步骤2105(第21A图)，交叉点的″未来″修正例将产生。在步骤2110，基础数据的″未来″修正例将对照于交叉点的”未来″修正例。在步骤2115(第21B图)，基础数据的″未来修正例将被检查以确定将发生什么事(在步骤2110后可发生数天、数周或更久)。如果基础数据的″未来″修正例将变更为″控件″修正例(即基础数据的″未来″修正例被更新为新的″未来″修正例)，随后在步骤2120，交叉点的”未来″修正例将同样被变更为“控件″修正例，且流程将返回步骤2105(第21A图)，以处理基础数据的新“未来修正例。如果基础数据的″未来″修正例将变更为″失效″修正例，随后在步骤2125，交叉点的″未来″修正例将同样变更为“失效″。最终地，如果基础数据的″未来″修正例将变更为″目前″修正例，随后在步骤2130，交叉点的″目前”修正例将变更为″历史″，且在步骤2135，交叉点的″未来″修正例将变更为″目前″。
第22A图与第22B图展示根据本发明之较佳实施例，用以对基础数据进行一项观察之程序的流程表。在步骤2205(第22A图)，将产生一项观察。在步骤2210，观察数据将被输入。在步骤2215，该项观察将连结至控件。在步骤2220，该项观察将连结至欲观察的基础数据。在步骤2225，将发生一项转换，以确定是否任何观察基础数据将被连结至该项观察。如果有较多的基础数据将被使用来进行观察，随后在步骤2230，该观察基础数据将连结至该项观察。否则在步骤2235(第22B图)，将输入环绕着该项观察的状况。在步骤2240，将输入该项观察的容限。在步骤2245，该项观察将被储存为已观察基础数据的历史数据。最终地，在步骤2250，该项观察将被检查以确定是否已与累积器注册。如果该项观察已与累积器注册，随后在步骤2255，该项观察将被累加。
第23A图与第23B图展示根据本发明之较佳实施例，用以执行一项交易之程序的流程表。在步骤2305(第23A图)，将产生一项交易。在步骤2310，将输入该交易数据。在步骤2315，该项交易将连结至一控件。在步骤2320，该项交易将连结至信用与请款基础数据。在步骤2325(第23B图)，该项交易将连结至报价基础数据。在步骤2330，该项交易将储存为信用与请款基础数据的历史数据。最终地，在步骤2335，信用与请款基础数据将被检查以确定是否其中之一(或二者)已与累积器注册。如果信用或请款基础数据之一已经与累积器注册，随后该项交易将被累加。
第24图展示根据本发明之较佳实施例，利用一样板用以产生一控件之程序的流程表。在步骤2405中，准则将被评比，不论根据观察、交易或其它原始类型。在步骤2410中，评比将被考量以鉴别是否该准则符合产生器的限制。如果该准则并不符合该产生器的限制的话，那么该流程将返回以评比新的准则。否则，在步骤2415中，控件将利用一样板与激活数据产生。最终地，在步骤2420中，控件被行使。
以上所述与展示的为本发明之较佳实施例的原则。对熟知技艺者而言，应该了解的是，在不脱离本发明之精神及范围下，本发明的申请专利范围将包含各种的变动及改良。在以下的申请专利范围中，我们将请求所有包含在其范围与精神下的变动与改良。
权利要求
1.一种用以管理计算机中程序设计的装置，该装置包含一计算机，其包括一内存；储存在该内存中的一基础数据，该基础数据包括有关该程序设计中一客体的信息；以及储存在该内存中的一控件，该控件包括有关该程序设计中之一程序的信息，而该控件可在该基础数据上运作。
2.根据权利要求1所述的装置，其中该基础数据包括该基础数据的一修正例，而该修正例将指示出有关该基础数据中之该客体之信息中的一项变动。
3.根据权利要求1所述的装置，其中该控制包括该控件的一修正例，而该修正例将指示出有关该控件中之该程序之信息中的一项变动。
4.根据权利要求1所述的装置，还包含第二基础数据，其包括有关在该程序设计中第二客体的信息；储存在该内存中的一交叉点，其被设计以使该基础数据中的信息相关联于该第二基础数据中的信息；以及储存在该内存中的第二控件，其包括有关该程序设计中一程序的信息，而该控件将可在该交叉点上运作。
5.根据权利要求4所述的装置，其中该交叉点包括该交叉点的一修正例，该修正例将指示出该基础数据中之信息与该第二基础数据中之信息的相关联中的一项变动。
6.根据权利要求1所述的装置，还包含第二基础数据，其包括有关该程序设计中第二客体的信息；储存在该内存中的一项交易，其被设计以从该基础数据转换一项资源至该第二基础数据；以及储存在该内存中的第二控件，其包括有关该程序设计中之一程序的信息，而该控件可在该项交易上运作。
7.根据权利要求1所述的装置，还包含第二基础数据，其包括有关该程序设计中第二客体的信息；储存在该内存中的一项观察，其被设计以从该基础数据之第二实例的观点来观察该基础数据；以及储存在该内存中的第二控件，其包括有关该程序设计中之一程序的信息，而该控件可在该项观察上运作。
8.根据权利要求1所述的装置，其中该基础数据仅可利用该控件来修正。
9.根据权利要求1所述的装置，其中该控件中的信息将包括一数值的字段，而缺少该数值字段的活，该控件将无法运作；以及该装置还包含储存在该内存中的第二控件，该控件包括有关在该程序设计中之一程序的信息，而该第二控件可在该控件上运作以供应该字段的数值。
10.根据权利要求9所述的装置，其中该控件将被设计为使它无法提供该字段的数值。
11.根据权利要求1所述的装置，其中该基础数据包括该基础数据的一未来修正例，该未来修正例将指示出在该程序设计中有关该客体之信息中的一项未来变动。
12.根据权利要求11所述的装置，其中该基础数据将另包括该基础数据的第二未来修正例，该第二未来修正例将包括有关该程序设计中该客体之信息的第二未来变动。
13.根据权利要求12所述的装置，其中该基础数据的该未来修正例将包括有关该程序设计中之该客体之信息中的第三未来变动；该基础数据之该实例的第二未来修正例将包括有关该程序设计中该客体之信息中的第四未来变动；以及该未来修正例中的第三未来变动与该第二未来修正例中的第四未来变动将为相同的变动。
14.根据权利要求1所述的装置，其中该基础数据将包括该控件的-ID。
15.一种计算机执行方法，用于管理程序设计，该方法包含产生一基础数据的一未来修正例；输入数据至该未来修正例中；以及使该未来修正例成为目前修正例。
16.根据权利要求15所述的方法，其中使该未来修正例成为目前修正例将包括保留该基础数据之一先前修正例。
17.根据权利要求16所述的方法，其中保留该基础数据之一先前修正例将包括变更一目前修正例为一历史修正例。
18.根据权利要求15所述的方法，其中输入数据将包括输入有关该基础数据之一变化字段的数据至该未来修正例中。
19.根据权利要求15所述的方法，还包含验证该未来修正例。
20.根据权利要求19所述的方法，其中验证该未来修正例将包括检查一必需字段是否具有数据。
21.根据权利要求19所述的方法，其中验证该未来修正例将包括确认该未来修正例中的一字段将包括有效数据。
22.根据权利要求15所述的方法，还包含连结该未来修正例与一控件。
23.根据权利要求15所述的方法，还包含输入数据至该基础数据的一控件。
24.一种计算机实行方法，用于相关联第一基础数据与第二基础数据之间的信息，该方法包含产生一交叉点的一未来修正例；输入数据至该交叉点中，进而使第一基础数据与第二基础数据相关联；以及使该未来修正例成为目前修正例。
25.根据权利要求24所述的方法，还包含保留该交叉点的一先前修正例。
26.根据权利要求25所述的方法，其中保留该交叉点的一先前修正例将包括变更一目前修正例为一历史修正例。
27.根据权利要求24所述的方法，其另包含连接该未来修正例与一控件。
28.根据权利要求24所述的方法，还包含输入数据至该交叉点的一控件。
29.一种计算机实行方法，用于从第二基础数据观察有关第一基础数据的信息，该方法包含产生一项观察；从该第二基础数据中的信息，对该第一基础数据中的信息进行测量；以及储存该测量值于该项观察中。
30.根据权利要求29所述的方法，其中进行测量将包括鉴别该项观察的正确性。
31.根据权利要求29所述的方法，其中进行测量将包括分配一项容限至该项观察。
32.根据权利要求29所述的方法，其中进行测量将包括观察该测量值周围的一状况。
33.如申请专利范围第29项之方法，其中储存该测量值将包括保留一先前测量值于该观察中。
34.一种计算机实行方法，用于进行第一基础数据与第二基础数据之间的一项交易，该方法包含辨认该第一基础数据中的一项资源；将该资源从该第一基础数据移动至该第二基础数据；以及由该第二基础数据支付该第一基础数据该资源的费用。
35.一种计算机实行方法，用于产生一控件，该方法包含利用一产生器评估一准则；从该准则中产生激活数据；利用一样板与该激活数据来产生一控件；以及行使该控件。
36.根据权利要求35所述的方法，其中评估一准则将包括利用一产生器从一项观查评估一项准则。
37.根据权利要求35所述的方法，其中评估一准则将包括利用一产生器从一项交易评估一项准则。
38.一种计算机实行方法，用于相关联第一控件与第二控件之间的信息，该方法包含产生一交叉点；输入数据至该交叉点的一控件中；以及插入该数据中之至少某些数据至该交叉点中，进而使第一控件与第二控件相关联。
全文摘要
一程序是由产生一基础数据的一未来修正例来进行管理。数据将输入至该基础数据的该未来修正例中。将使该基础数据的该未来修正例成为目前修正例，进而修正该基础数据。一控件将追踪该基础数据修正例的授权，进而储存该基础数据之该未来修正例的授权。
文档编号G06Q10/00GK1441937SQ01811966
公开日2003年9月10日 申请日期2001年6月26日 优先权日2000年6月27日
发明者肯尼思·R·艾伦, 约翰·E·布劳蒂, 大卫·E·怀勒 申请人:变换能源有限公司