CN1877573A

CN1877573A - 多层次数据库***结构

Info

Publication number: CN1877573A
Application number: CN200510076357.9A
Authority: CN
Inventors: 高裕翔; 苏汉良; 叶志强; 叶金宽
Original assignee: Huaxia Science & Technology Co Ltd
Current assignee: Caxa Technology Co Ltd
Priority date: 2005-06-10
Filing date: 2005-06-10
Publication date: 2006-12-13
Anticipated expiration: 2025-06-10
Also published as: CN100590616C

Abstract

本发明提供一种可解决数据库升级风险的数据库***及其建立方法，利用混合多种不同层次的数据库结构设计，以在升级数据库时能维持原始程序的数据及保持***的完整性。在不需更动实体数据结构的条件下，通过应用程序于索引数据层针对实体数据建立索引数据表以进行数据及字段的搜寻、建立、删除及修改。

Description

多层次数据库***结构

技术领域

本发明涉及一种数据库***结构，特别是涉及一种适用于数据库升级的多层次数据库***结构。

背景技术

近年来，随着多媒体技术、空间数据库技术和计算机网络的快速发展，数据库***的发展十分迅速，应用领域愈来愈广，企业单位、政府部门的行政管理、办公自动化、企业生产计划管理、银行财务管理、医院病房病历管理、图书馆管理、气象预报、地理信息***(GIS)、电子商务等等都离不开数据库***。一方面，一些较成熟的技术，如各种大、中、小和微型计算机数据库管理***和一些传统的数据库设计方法已付诸应用层面；另一方面，尚有许多理论及实际问题极待开发和探索，如空间数据库、多媒体数据库、网络数据库、智能数据库等。特别是网络数据库的理论和技术问题正成为数据库研究的一个热门研究领域，相较之下，传统的数据库技术和***便显得力不从心，这也对传统的技术和研究开发工作提出了挑战。

从1970年代末期以来，几乎所有的数据库***的发展都以关系型数据库***(relational database system)为主轴。事实上，关系型的作法是今日的主流，而关系型模型成为数据库领域中最重要的发展也是无庸置疑的。简单的说，关系型数据库***就是：

1.使用者所看到的数据都是表格。

2.使用者可使用的运算(例如数据的撷取)都是从旧的表格中产生新的表格。例如，有些运算子(operator)用来撷取表格中的某些横列成为一个子集合，另有些运算子则用来选取表格中的直行成为子集合，当然，表格中横列的子集合及直行的子集合可以合起来构成一个新的表格。

关系型数据库的所以如此受欢迎，主要原因是其建立在严格的数学概念基础上(以「关系运算」为基础)，无论数据库内的实体(entity)或实体之间都用关系来表示，对数据的检索结果也是一种关系(即表格)，因此关系型数据库的概念单一，其数据结构也显得相当简单、清晰。此外关系型数据库中关系表格的存取路径对使用者而言是公开的，其具备了更高的数据独立性、更加的安全保密性，亦简化了数据库开发建立的工作。总结来说，关系型数据表的优点在于对结构化数据关连的定义和控制十分详细。

然而关系型数据库的缺点则是缺乏弹性，一旦数据的关联发生异动，则牵一发而动全身，对应程序的修改是相当费时费力。通常关系型数据库在两个独立的数据表格(data table)之外还需要建立一个关系表格(relationaltable)，以在数据库表格中间设定主键(primary key)与其它附属键(foreignkey)的关联性。请参阅图1。图1为一现有的关系型数据库B1示意图。关系型数据库B1包含二数据表格10及表格20，其中表格10中含有数据K1，表格20中含有数据K2。此外，根据数据K1及数据K2的关系另建立一表格30来表示。

建立关系表格的好处在于搜寻上如果有关系式的建立，所有相关的附属数据可以非常快地找出来；但是相对而言，使用关系表格的一个非常大的缺点就是：当需要新增、删除、修改数据，甚至需要新增、删除、修改数据库时，数据之间的关联性会使得执行这些任务变得非常复杂、耗时且容易出错。举例而言，当需要删除数据时，必须先将相关联的附属关系数据一一删除后才可以删除原本要删除的数据。如图1所示，如果我们要删除表格20中的数据K2，必须先将表格30中所有有关数据K2的数据删除才可以将表格20中的数据K2删除。

从程序设计师的观点来看，前后数据的变动关系会使得程序设计变得异常困难；也往往在数据更新的过程中，因为修正程序的错误，而使***产生错误的讯息，甚至造成整个***的瘫痪。此外，因为各数据彼此之间的关联性很重要，即使是数据库的硬件有些微的差错，也可能遗失各数据之间的关联或破坏了该关联性数据库，造成整个***停摆。如此一来，虽然关联性数据库增加了数据搜寻上的便利性，却因此牺牲了数据新增、删除、修改的效率，并且增加了程序本身不必要的复杂度；更严重的是，复杂的关系型数据库结构的修改成了一近乎不可能的工程。

请继续参考图1。一个具有三个数据表格的关系型数据库在针对数据本身作处理的过程中，若处理的数据涉及键值数据(key)时，不管是新增、删除或修改数据，皆需要三个步骤。例如：

(一)新增数据的步骤：

步骤一：于表格10新增数据K1

步骤二：于表格20新增数据K2

步骤三：于表格30新增数据K1与数据K2的关联数据

(二)删除数据的步骤：

步骤一：删除表格30中数据K1与数据K2的关联数据

步骤二：删除表格10中数据K1

步骤三：删除表格20中数据K2

(三)修改数据(键值数据)的步骤：

步骤一：修改表格30中数据K1与数据K2的关联数据

步骤二：修改表格10中的数据K1

步骤三：修改表格20中的数据K2

上述关于新增、删除与修改数据的步骤只有涉及表格30与表格10、表格20之间的关系，尚未包含表格30与其它表格的关系。如果关系型数据库的具有n个数据表格，则我们可以预期如表格30的关系表格最多将有C₂ ⁿ种情形。在表格数量持续增加时，单单进行简单的数据或表格的新增、删除或修改的运算量就十分惊人。

另一方面，由于C++等面向对象(object oriented)的程序相继问世，几乎所有程序设计都以面向对象为设计标准。面向对象设计的概念在于将所有最基本程序分析的组件转换成对象与对象的相互行为。也因为程序设计的基本组件变成可分析的概念，UML(unified modeling language)语言一类的语言便相继被发明与强化来支持面向对象程序的简化。然而很不幸的，目前在程序语言被强化成面向对象观念同时，数据库的运用虽有所谓面向对象的数据库来配合，但是仍为了在搜寻上与稳定度的考虑而采用关系型数据库。

正因为如此，无论是面向对象的数据库或关系型数据库，当遭遇***升级的需求时，数据库的升级都会遭到无比的风险。总括而言，这些风险来自：

(1)数据库表格的字段往往会因为升级的需求而增加，而在关系型数据库的结构下，「增加字段」会更动到数据库基本结构。

(2)关系型数据库的数据表格会因为主表格的变更而跟着被更动，同样也会更动到数据库的基本结构。

(3)当数据库版本变更时，数据库的数据格式可能无法兼容。

由于这些数据库设计的风险，大部分信息人员往往视移动关系型数据库的数据为畏途，即使数据库效能已经不敷使用，也只利用调教效能(performance tuning)的方式试图解决。

发明内容

因此，本发明的主要目的是提供一种可解决数据库升级风险的多层次数据库***。

本发明提供一种多层次的数据库***，其包含有一实体数据层以及一索引数据层。该实体数据层包含一数据表，该数据表记录有该数据库***的多笔对象数据，该数据库***的数据表的每一笔对象数据包含多个数据项，该对象数据的该多个数据项的每一数据项具有一属性名称，一对象识别码，一项目内容及一索引代码。该索引数据层记录有索引数据，用来据以搜寻该多个数据项的索引代码以取得该数据库***中符合应用程序所要求的对象数据。

本发明还提供一种建立多层次数据库***的方法，其包含下列步骤：产生一实体数据层，其包含一数据表，该数据表记录有该数据库***的多笔对象数据，该数据库***的数据表的每一笔对象数据包含多个数据项，该对象数据的该多个数据项的每一数据项具有一属性名称，一对象识别码，一项目内容及一索引代码；以及依据一索引数据层的索引数据，搜寻该多个数据项的索引代码以取得该数据库***中符合应用程序所要求的对象数据。

附图说明

图1为现有关系型数据库中关系表格的示意图。

图2为本发明多层次数据库***一实施例的示意图。

图3为本发明多层次数据库***的数据表结构示意图。

图4为本发明多层次数据库***中建立一数据表的示意图。

图5为本发明多层次数据库***中一索引数据表的示意图。

图6为本发明多层次数据库***中于数据表中建立索引的示意图。

图7为本发明多层次数据库***中删除一对象数据的示意图。

图8为本发明多层次数据库***另一实施例中实体数据层丛集实际操作方法的示意图。

附图符号说明

K1、K2 表格数据 B1 关系型数据库

10、20、30 表格 40 关联数据表

42 数据记录 44 字段名称

50 应用程序 100 多层次数据库***

200 索引数据层 210 索引数据表

220 对照表 300 动态数据层

400 实体数据层 410 丛集

422 对象数据 424 数据项

430 数据表 432 属性名称

434 对象识别码 436 项目内容

440，440A，440B索引代码

具体实施方式

请参考图2。图2为本发明的多层次数据库***100的示意图。多层次数据库***100包含有一索引数据层200、多个动态数据层300及一实体数据层400。其中，多层次数据库***100通过索引数据层200与应用程序连结，而索引数据层200与多个动态数据层300还与实体数据层400相连结。实体数据层400中包含多个丛集410，而记录实体数据的数据表430则包含于丛集410中。索引数据层200及多个动态数据层300中包含多个索引数据表210，用来记录索引数据。索引数据表210及其所记录的索引数据依据应用程序的搜寻条件由应用程序产生。索引数据层200及多个动态数据层300亦依据应用程序的设计需求而产生，若应用程序需求较为简单，多层次数据库***100甚至可以不具备动态数据层300，只由索引数据层200及实体数据层400构成。

当计算机***的应用程序依据搜寻条件及所需求的数据库类型产生索引数据层200的索引数据表210(及多个动态数据层300的索引数据表210)后，应用程序即依据索引数据层200及动态数据层300中的索引数据表210的索引数据来搜寻数据表430。

请参考图3。图3为本发明的多层次数据库***100中，实体数据层400的一丛集410的示意图。数据表430由面向对象程序构成，数据表430数据表430记录有数据库***100的多笔对象数据422，其中每一笔对象数据422包含多个数据项424，对象数据422的多个数据项424的每一数据项424具有一属性名称432、一对象识别码434、一项目内容436及一索引代码440A。此一实施例的数据表430中，属性名称432、对象识别码434及项目内容436为多层次数据库***100中的静态数据，该静态数据的模式(Schema)于实体数据层400建立的初即规划好，当数据库***100运作或进行任何数据处理的操作时，该模式皆不受影响，亦即多层次数据库***100中实体数据层400的实体数据具有一不需更动的基本结构，可确保实体数据的稳定性及安全性。如先前所述，实体数据层400中设置了多个丛集410，而为了适应数据库各种实体数据性质不同，每一丛集410可允许拥有一种部署纲要，属于该丛集410的所有数据表430则以同一种部署纲要来设计。

另外，此一实施例的数据表430中，索引代码440A为多层次数据库***100中的动态数据，其依据索引数据层200及多个动态数据层300中索引数据表210的索引数据而建立，而当索引数据表210有所更动时，索引代码440A亦会同步随着更动(通常是重新建立)，当索引数据表210被删除时，其所建立的索引代码440A亦随之删除。也适应应用程序的设计及数据搜寻的复杂度，数据表430中可包含一个以上的索引代码440A。而应用程序便是依据索引索引数据表210的索引数据，以搜寻数据表430中数据项424的索引代码440A，以取得多层次数据库***100中符合应用程序所要求的对象数据422或对象数据422中的数据项424。

请继续参考图4。图4为现有关系型数据库的一关联数据表转换为本发明的多层次数据库***100一实施例的数据表的示意图，其中关联数据表40的首列显示字段名称44，于关联数据表40中共有「记录识别码」、「姓名」、「性别」、「年龄」及「血型」五个字段。而关联数据表40的其余各列则依据字段名称44显示各笔数据记录42。当欲建立本发明的一实施例的数据表430时，则将关联数据表40的数据表名称(此处命名为「人员」数据表)及数据域位44合并为数据表430的属性名称432一栏的内容；由于关联数据表40中每笔数据记录42皆具有一唯一的记录识别码，以与其它数据记录作区别(主要以该记录识别码作为关联数据表的索引)，于实际操作本发明的一实施例时，则将该记录识别码记录于数据表430的第二栏，做为对象识别码434一栏的内容；数据表430的项目内容436则记录数据记录42中相对应于数据域位44的数据内容，以作为项目内容436一栏的内容。

以关联数据表40(「人员」数据表)中第一笔数据记录42举例来说，第一笔数据记录42记录有「姓名」字段内容：「陈建宏」、「性别」字段内容：「男」、「年龄」字段内容：「30」、「血型」字段内容：「A」，另外第一笔数据记录42的记录识别码为「1」，则本发明的一实施例的实际操作方式会据此建立一笔对象数据422，其包含四笔数据项424，其中第一笔数据项424的属性名称432一栏的数据内容为「人员□姓名」(如前所述，该栏内容为关联数据表40中数据表名称与数据域位名称的合并)，对象识别码434一栏的内容为「1」，项目内容436一栏的内容为「陈建宏」；同理，第二笔数据项424的属性名称432一栏的数据内容为「人员□性别」，对象识别码434一栏的内容为「1」(皆属同一对象数据，因此对象识别码相同)，项目内容436一栏的内容则为「男」…余此类推。如此一来，关联数据表40中的一笔数据记录42会建立成本发明的一实施例的数据表430的四笔项目数据424，此四笔项目数据424构成一笔对象数据422，因此四笔项目数据424的对象识别码434一栏的内容皆相同。

请参考图5、图6。如前所述，应用程序依据搜寻条件及应用程序所需求的数据库类型而产生索引数据层200的索引数据表210(及多个动态数据层300的索引数据表210后)，并据以进行数据表430的数据搜寻。图5、图6说明于索引数据层200建立有一索引数据表210，其中包含索引数据用来将项目数据424的项目内容436中具有数据内容为「男」的项目数据424，于该项目数据424的索引代码440A字段中标示为″0″，并用来将项目数据424的项目内容436中具有数据内容为「女」的项目数据424，于该项目数据424的索引代码440A字段中标示为″1″。当索引数据表210建立完成后，会于实体数据层400中已建立好的数据表430动态增加一索引代码440A字段，并依据前述条件将″0″与″1″填入适当项目数据424的字段中，其余不符合条件的项目数据424的索引代码440A一栏则不作用。

当欲依据索引数据表210所标示的索引数据来搜寻数据表430中符合的对象数据422时，例如欲搜寻数据库中所有男性员工的数据，则只需要于索引代码440A中提取出代码内容为″0″的数据项424，并依据数据项424中对象识别码434取得所需的对象数据422。如此完成了数据的搜寻操作。

同理，如欲找出数据表430中，年龄小于30岁的男性员工，则根据事先于索引数据层200建立的索引数据表210(或于动态数据层300中建立的索引数据表210)另于数据表430建立的一索引代码440B，再与原先已建立的索引代码440A交叉搜寻，即可提取出两个条件皆符合的数据。

此外，配合应用程序需求而欲实现「于现有的关联数据表40中新增一字段」的目的时，于本发明的一实施例的数据表430的作法则是直接于数据表430中新增一笔数据项424，其各字段内容则依前述建立方式建立。例如要新增一「婚姻状态」的字段，而第一笔数据记录42的相对于「婚姻状态」字段的字段内容为「已婚」时，则于数据表430中新增一笔数据项424，其属性名称432一栏的数据内容为「人员□婚姻状态」，对象识别码434一栏的内容为「1」(属同一对象数据，因此对象识别码相同)，项目内容436一栏的内容则为「已婚」。

请参考图7。图7为本发明的多层次数据库***100欲删除一对象数据的作法示意图。若配合应用程序需求而欲实现「于现有的关联数据表40中删除一笔数据记录42」甚或「于现有的关联数据表40中删除一字段」的目的时，于本发明的一实施例的数据表430的作法则是直接于索引数据层200的索引数据表210中，将记录有实体数据层400中可用数据表430、对象数据422或数据项424的索引数据表210标示出有效或常用的索引数据。

应用程序可动态于索引数据层200中建立一全域索引数据表210，其中可依需求将处理数据的单位规划为以数据项424为单位，或以对象数据422、甚至以数据表430为单位。当然亦可以建立二层至多层以上的索引数据表210，以实现同时针对丛集410、数据表430、对象数据422及数据项424等实体数据范围作全域索引的目标。当应用程序欲删除数据表430中第三笔对象数据422时，于全域索引数据表210中将「可用性」字段标示为「否」，则「全域索引」字段对应数据表430的「有效索引」的索引内容亦将被解读为无效的数据。换句话说，多层次数据库***100即可藉由于索引数据层200中建立索引数据表以标示出实体数据层400中有效或常用的数据表430、丛集410、对象数据422或数据项424。

特别注意的是，其中数据表430的「有效索引」亦为索引数据层200根据应用程序设计而建立的动态索引栏，其与对象识别码434不相同，无论是对象识别码434或有效索引(甚至是其它动态建立的索引代码)皆可依程序设计需求设计成全域索引或局部索引。

图8为本发明多层次数据库***100另一实施例中实体数据层丛集实际操作方法的示意图。当数据类型因为成年累月的发展与改变而不断增加时，实体数据层400的数据表430并不需要无限制的扩张。本发明的多层次数据库***100于实体数据层400另建立丛集410以放置多个数据表430。丛集410本身被***设定有固定的容量限制，以避免任一丛集410的大小无限制扩大。当一类的对象数据数量增长至某一程度时，整个数据库会重新开启一个丛集410，以放置新增的数据表430及其中的对象数据。在一个大型的数据库***中，若是能对搜寻的数据再作进一步的分类与筛选，则有助于搜寻效率的提升，因此，于建立丛集410时，本发明即对丛集410进行建立索引的操作，并于索引数据层200中建立一搜寻丛集索引的对照表220以将搜寻对象作进一步的范围限制。而实体数据层400中多个丛集410亦不需被限定储存在单一计算机主机中。多个丛集410分别储存于多个经由网络***相连的计算机主机中，以分散主机***的处理负载。

为配合使用者仍较习惯以表格方式建立数据库的数据内容，应用程序的接口仍旧可以设计成以表格(或类似表格)的形式供使用者输入数据，无论是数据的新增、删除、修改，或是数据域位的新增、删除、修改，以致于一个以上表格之间的数据关系的建立、移除，皆可通过上述索引数据层200或动态数据层300于实体数据层400的数据表430中建立相关的索引代码440字段(一个或一个以上)以完成对象数据422的建立。以前述实施例而言，当使用者欲建立一笔具有廿个字段的数据时，现有作法就是于数据库中写入一笔具有廿个字段的数据，而本发明的多层次数据库***100的一实施例则是于数据表430中建立廿笔具有三个字段(于尚未建立索引代码440的情况下)的数据项424。为避免于数据项424建立时占用***资源以致于影响多层次数据库***100的效能，于应用程序端与多层次数据库***100的索引数据层200之间可另外建立一队列缓冲区，使多层次数据库***100可利用所有***闲置的时间来进行数据的建立工作。

另一方面，经过搜寻之后的数据也可以通过程序设计以转换成使用者较习惯的表格方式呈现，对于应用程序而言，多层次数据库***100提供一安全的数据储存结构，而使用者端可以沿用原有的数据处理方式以避免使用习惯的改变。也由于多层次数据库***100种储存对象数据的方式几乎是不变的，针对数据库的结构改变、***升级等需求，多层次数据库***100可以完成这些对关系型数据库***而言相当具风险的变更。

以上所述仅为本发明的较佳实施例，凡依本发明的权利要求所做的均等变化与修饰，皆应属本发明的涵盖范围。

Claims

1.一种多层次的数据库***，其包含有：

一实体数据层，其包含一数据表，该数据表记录有该数据库***的多笔对象数据，该数据库***的数据表的每一笔对象数据包含多个数据项，该对象数据的该多个数据项的每一数据项具有一属性名称，一对象识别码，一项目内容及一索引代码；以及

一索引数据层，其记录有索引数据，用来据以搜寻该多个数据项的索引代码以取得该数据库***中符合应用程序所要求的对象数据。

2.如权利要求1所述的数据库***，其还包含多个动态数据层，位于该索引数据层与该实体数据层之间。

3.如权利要求1所述的数据库***，其中该实体数据层包含多个丛集，每一丛集包含多个数据表。

4.如权利要求3所述的数据库***，其中该多个丛集储存于多个经由一网络***相连的计算机主机中。

5.如权利要求3所述的数据库***，其中该多个丛集的每一丛集还具有索引数据。

6.如权利要求1所述的数据库***，其中该索引数据层包含多个索引数据表，每一索引数据表包含多笔索引数据。

7.一种建立多层次数据库***的方法，其包含下列步骤：

(a)产生一实体数据层，其包含一数据表，该数据表记录有该数据库***的多笔对象数据，该数据库***的数据表的每一笔对象数据包含多个数据项，该对象数据的该多个数据项的每一数据项具有一属性名称，一对象识别码，一项目内容及一索引代码；以及

(b)依据一索引数据层的索引数据，搜寻该多个数据项的索引代码以取得该数据库***中符合应用程序所要求的对象数据。

8.如权利要求7所述的方法，其还包含依据该应用程序的搜寻条件产生该索引数据层的索引数据。

9.如权利要求7所述的方法，其还包含依据该应用程序的搜寻条件，于该索引数据层与该实体数据层之间建立多个动态数据层。

10.如权利要求9所述的方法，其中步骤(b)依据该索引数据层的索引数据及该多个动态数据层的索引数据，搜寻该多个数据项的索引代码以取得该数据库***中符合该应用程序所要求的对象数据。

11.如权利要求7所述的方法，其还包含根据该应用程序的搜寻条件于该索引数据层中标记常用或有效的索引数据。

12.如权利要求7所述的方法，其还包含由一面向对象程序构成该数据表。

13.如权利要求7所述的方法，其还包含将一关系型数据库的一笔记录转换成一笔对象数据，每一笔对象数据包含多个数据项。

14.如权利要求7所述的方法，其还包含于该实体数据层建立多个丛集，每一丛集包含多个数据表。

15.如权利要求14所述的方法，其中当对象数据的数目超过该数据库设定的丛集大小时，该数据库***于该实体数据层还建立一新丛集以放置新增的对象数据。

16.如权利要求14所述的方法，其还包含以一数据库模式规划一丛集。

17.如权利要求14所述的方法，其还包含对每一丛集建立索引数据。