关系型数据库范文1
关键词：关系型数据库；办公系统；企业；服务器
中图分类号：TP393 文献标识码：A文章编号：1007-9599 (2011) 11-0000-01
Relational Database Network Office System Study
Chen Jinping
(Dalian Fishe Ries University Vocational&Technical College,Dalian116300,China)
Abstract:The database is the data of scientific management,advanced technology,is an important part of computer science,relational database applications are becoming increasingly widespread.This paper describes the enterprise network in the office of information technology systems relational database design and application,the application method has a certain universality and representation.
Keywords:Relational databases;Office system;Enterprises;Server
一、企业网络办公系统信息化建设中关系型数据库的设计
（一）系统结构的选择
在整个系统开发过程中系统结构的设计是最重要的一环。对于网络办公系统来说，尤其是一些结构关系较为复杂的系统，如果没有一个科学合理的系统结构而要有一个完善的办公系统是不可能的。不同类型的应用系统需要定制不同的系统结构，系统的设计在很大程度上取决于系统结构的规划。按照系统业务情况的不同，可把企业网络办公系统的开发结构分为B／S（browser／service）和C／S（client／service）两种结构模式。它们特色鲜明，是当前常见的系统开发模式。
B／S结构的系统以服务器环节为核心，除了部分脚本，大部分程序解析和数据处理都在服务器端完成的，用户不需要安装特殊的客户端程序，只要能够连接服务器，使用浏览器就可以访问系统。C／S结构的系统以服务器作为数据处理和存储平台，在终端要求安装有专门的软件来处理事务，数据被传递到服务器端，用户必须使用客户端应用软件才能访问系统。
（二）关系型数据库的设计
1.设计规则。综合考虑到企业办公系统基础数据量大，访问频繁，设计时尤其要注意系统的处理效率。同时从全局的层面出发，数据构成关系型数据库系统，保证全局数据的完整性和一致性。
2.系统结构。该企业办公系统是由数据库服务器和web程序服务器构成。数据库存放所有的管理数据，发展整个系统正常运行所需的数据，程序服务器存放应用程序，并且处理用户的访问请求。采用这种有冗余的相对集中的关系型结构可以对系统中的主要数据进行集中式管理。当WEB程序服务器收到用户的请求后，服务器应用程序和WEB服务器将请求转换为数据库访问命令，并发送到数据库服务器，数据库服务器执行命令并返回结果。
二、PHP语言在办公系统中的应用
该系统采用PHP（Hypertext Preprocessor）语言编写，它是服务器端的编译执行环境，我们可用它来创建动态Web页或生成功能强大的网络应用程序。对关系型数据表中的记录进行增加、编辑、删除可以用命令insert、update、delete来实现。现在以增加通知信息为例来说明PHP语言在办公系统中的应用：
$ddd=time（）；
if（empty（$timu））
echo"题目不能为空"；
elseif（empty（$_POST['neirong']））
echo"内容不能为空"；
elseif（empty（$lanmu））
echo"你没有选择栏目"；
$sortid=（float）$usec+（float）$sec；
$quer=mysql_query（"insert into$tongzhi set timu='$ timu'，neirong='$neirong'，lanmu='$lanmu'，ReleaseTime='$ddd'，AmendTime='$ddd'"）；
if（$quer）
echo"通知记录添加成功"；
else
echo"调整记录添加失败"；
?>
对记录的修改和删除方法与此类似。
三、关系型数据库在办公自动化管理系统中的实际应用
办公自动化管理系统安装在企业的服务器上，形成一个可供企业上至管理层、下至普通员工，根据不同的权限而使用相应功能的公共系统。
（一）系统实现的主要功能
（1）企业内通知的接收与发送。（2）企业公文的接收与发送。（3）企业业务部门电子公告。（4）内部员工电子邮件。（5）相应辅助功能：如日程安排，通讯录等。
（二）数据库设计
该办公自动化管理系统的数据库由HFYH（合法用户表），TZ（通知表），GW（公文表），NBYJ（内部邮件表）几个主表组成。
（三）系统特点
本系统与传统的办公管理系统相比，具有如下的优点：
1.占用主机空间小。对于传统的办公管理软件，用户如果希望实现数据管理，则必须在每台计算机上安装办公管理软件，占用主机空间。而本系统属于B/S系统，只要安装在服务器上，同时用户拥有使用权限，便可使用本系统。
2.安装简便。只需一次安装便可服务于多个用户。
四、结束语
网络技术日新月异，但是如果没有关系型数据库结合其中，办公系统将无法工作。本文介绍的关系型数据库网络办公系统中的应用方法，具有一定的普遍性和代表性。
参考文献：
关系型数据库范文2
关系模型就是指二维表格模型，因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。
当前主流的关系型数据库有Oracle、DB2、MicrosoftSQLServer、MicrosoftAccess、MySQL等。
（来源：文章屋网 ）
关系型数据库范文3
关键词：ACCESS,PC项目物资管理，缺口量，库存量，材料成本
1．PC项目物资管理问题
我公司近两年内先后承接了140×104立方原油商业储备库项目以及300×104立方国家石油储备基地这两个总承包项目（以下简称PC项目）。根据施工工艺以及进度的安排各专业在不同的时期对物资都有不同的需求，造成物资采购以及管理数量多，工期紧，涉及施工单位多的局面。在项目建设中物资缺口查询，库存平衡这样的动态数据不能很好的把握的问题尤为突出。拨付进度款或者结算时材料成本不能及时准确回馈施工单位，需要大量人力汇加料单，暴露出物资管理方面水平低下的弊端。
基于这样的状况，通过对大量物资管理软件的了解与学习使用，我们认为这类问题在关系型数据库ACCESS下可迎刃而解。作为PC总包方，我们可以通过对ACCESS数据库的设计来运用到项目管理当中，全面准确的了解各施工分包方的物资运作情况，真正做到：“手中有粮，心中不慌”。所谓关系型数据库在实际中的应用我们可以认为是类似于ERP（企业资源计划 Enterprise Resources Planning，是基于企业管理理念上高度集成化的信息系统，是一套将制造、财务、分销及其他业务功能合理集成的应用软件系统。）中的一个物料管理模块的简单化。根据工程分包特点签订完毕施工分包合同，根据物资采购程序签订采购合同，为此分包范围内的物资建立起来了一个流通的网络。一个施工分包合同内的物资可能有几份采购合同，而总包商一份大的采购合同中的物资也有可能是多个施工分包合同中的。而在这些合同间起到桥梁作用的就是物资本身。
2．解决方案
分包单位通过施工合同确定施工范围，材料计划纳入ACCESS管理中，通过申报物资计划，流转到采购部门，签订采购计划，催缴，到货检验，发放。ACCESS数据库自动赋予每个材料（计划数量依据蓝图）一个唯一编号，此编号下的材料则是该某一施工分包合同范围内的、项目WBS分解下某一或多个工作包内的专属材料，绝无重复性。实际操作中这个材料的计划数量确认，多次到货（正值，实际到货量），多次出库（负值，实际出库量）都是调用它的唯一编号来运算的。基于每种材料的到货与发放的手续，通过利用ACCESS建立选择查询来整合这个唯一编号下的实际数量，不难得到此编号下材料设备的各种动态数据。
2.1.物资缺口生成
物资当前缺口量=计划数量（蓝图已知）―实际到货量（一次或多次累积值）
SQL语句:SELECT [4WBS下分解到零件].需求数量, 累计入库.累计入库, [需求数量]-[累计入库] AS 缺口数量, [累计入库]/[需求数量] AS 到货比率
FROM 5分包方上报计划 INNER JOIN (4WBS下分解到零件 INNER JOIN 累计入库 ON [4WBS下分解到零件].序号 = 累计入库.序号) ON [5分包方上报计划].分包方器材计划ID = [4WBS下分解到零件].分包方器材计划ID;
缺口信息表达：可查询某施工单位某种材料的缺口量、累积到货量、每次到货量、每次到货时间，为生产部门提供信息。
2.2. 物资库存生成
物资当前库存量=实际到货量（一次或多次累积值）―实际出库量（一次或多次累积值）
SQL语句: SELECT Sum([4WBS下分解到零件].需求数量) AS 需求数量之总计, Sum(累计入库.累计入库) AS 累计入库之总计, Sum(累计出库.累计出库) AS 累计出库之总计, Sum([累计入库]-[累计出库]) AS 库存
FROM 5分包方上报计划 INNER JOIN ((4WBS下分解到零件 INNER JOIN 累计入库 ON [4WBS下分解到零件].序号 = 累计入库.序号) INNER JOIN 累计出库 ON [4WBS下分解到零件].序号 = 累计出库.序号) ON [5分包方上报计划].分包方器材计划ID = [4WBS下分解到零件].分包方器材计划ID
HAVING (((Sum([累计入库]-[累计出库]))>0));
库存信息表达：及时掌握某施工单位某种材料的库存量、累积出库量、每次出库量、每次出库时间等，便于问题及时发现，与生产部门联手管理。
2.3. 材料成本生成
出库材料成本=实际出库量（一次或多次累积值）×采购单价+附加费用
SQL语句：SELECT [5分包方上报计划].分包单位, Sum([实发数量]*[采购单价(元)]) AS 合计成本
FROM (5分包方上报计划 INNER JOIN 4WBS下分解到零件 ON [5分包方上报计划].分包方器材计划ID = [4WBS下分解到零件].分包方器材计划ID) INNER JOIN 9出库登记表 ON [4WBS下分解到零件].序号 = [9出库登记表].零件序号
GROUP BY [5分包方上报计划].分包单位
HAVING (((Sum([实发数量]*[采购单价(元)]))>0));
出库材料成本信息表达：便于统计某施工单位任意时间段任意区域的出库材料成本，便于协助经营部门检查成本，控制拨付费用等等。
3．应用实例
2009年在独山子国家石油储备基地项目中，对30台十万方罐基础多家分包施工单位的物资管理采用了ACCESS数据库技术，一些基本表设计、数据录入、查询和报表摘录如下，
3.1.物资计划查询
将施工分包单位的材料申请计划准确导入ACCESS系统后：在材料计划查询设计状态下挑选字段【器材计划名称】输入：“罐基础”，点击运行后显示四家分包单位承建的罐基础所需建筑钢材需求量等信息。（如下表）
我们不妨随机挑选被ACCESS命名为零件序号11的需求量为1224t的φ25 HRB335螺纹钢来演示。
3.2.入库详细登记
随着保管员根据采购合同、到货清单等将到货记录完成后（每次只输入零件序号即可，其他内容系统自动引入，出库记录下同），可在入库登记查询设计状态下挑选字段【零件序号】输入“11”（零件序号，相当于本系统中唯一的，不重复的器材编码），点击运行后显示本材料的单次到货数量日期等情况，点击后缀还有其他到货情况。特别需要注意的是区分零件序号与入库、出库登记流水号。
3.3. 物资缺口查询
缺口查询设计状态下挑选字段【零件序号】输入“11”，点击运行后显示本材料目前的累积到货量，缺口数量，到货比率等信息。
3.4. 出库详细登记
随着保管员根据领料单、调拨单等将出库记录完成后，可在出库库登记查询设计状态下挑选字段【零件序号】输入“11”，点击运行后显示本材料的每次出库数量日期、每次出库材料成本等情况，点击后缀还有其他到货情况。
3.5.库存数量查询
随着材料的出库发放，我们可在库存数量查询设计状态下挑选字段【零件序号】输入“11”，点击运行后显示本材料的库存数量，还可衍生出库存成本，及时了解动态等等。
3.6.项目管理应用展望
关系型数据库范文4
十几年之后，时任IBM研究员的E.F.Codd博士首次提出了关系型数据库的数据模型和理论，后经IBM实验室对该模型的数据库体系结构、SQL查询语言、事务处理、分布式数据库理论等进行商务开发和论证，最终以今天大家熟知的DB2系统推向市场，并因此引发了数据库的一次革命。从此，这种带有易于理解的二维数据模型的关系型数据库，以强大的生命力在上个世纪80年代后成为数据库领域的绝对主角。
随着网络应用的丰富和深入，数据对象从简单的数字、字符等文本类型向诸如图形、图像、音视频、Web网页等各种类型和事件拓展，传统关系型数据库的二维模型已经无法完成对上述复杂对象的描述和存储。于是，关系型数据库的主角身份开始受到置疑和动摇。此时，后关系型数据库如一匹黑马，脱颖而出，并随即成为其中最强势的挑战者。
事实上，在近几年的市场争夺战中，后关系型数据库已经显现出了作为未来数据库领袖的气质和内涵。
后关系型数据库抢戏
严格算来，在上个世纪70年代后期，一位名为P.Chen的人提出的实体――关系数据模型被普遍认为是今天后关系型数据库的雏形。当然，直到Internet的出现和繁荣，后关系型数据库才在网络市场需求的刺激下得以完善的产品和应用参与角逐。
随着网络化应用的推进，即使是一个简单的事务处理性应用系统也能触及到关系型数据库技术的极限。其中二维数据模型、低效的事务处理性能、高昂的开发和维护费用、有限的扩展机制等都成为这些传统关系型数据库的软肋。可以说，它在适应复杂化、快速升级、简单开发、海量数据存储和处理等新应用需求方面似乎越来越力不从心。它无法完成对复杂数据类型的简单、合理描述，随之而来的，是现有的查询语言、数据处理技术、存储系统也日显“老态”。总之，当面向对象甚至面向服务的技术架构开始风行的时候，关系型数据库却成为这种对象技术的掣肘，因为所有的对象和服务都不得不被拆解为二维关系数据模型。
此时，后关系型数据库信步走上前台。
后关系型数据库的主要特征是将多维处理技术和面向对象技术集成在一起，从而能够提供事务处理应用开发所需的高性能和灵活性，同时支持应用和数据的复杂性，并拥有比关系型技术更强的扩展性、更快的编程能力以及更便捷的使用特性。
InterSystems公司被业界公认是这种后关系型数据库的技术领袖和在医疗卫生行业数据库的主导者。他们的Caché数据库技术结合了高性能、快速查询SQL、先进的快速存储和面向对象技术，在全球400多万用户的关键应用环境中得到可靠验证。其中，美国前十大医院、三大医疗实验机构都在使用Caché数据库，波士顿地区医生工作站更是成为Caché数据库在全球医疗卫生行业较成功较经典的应用。
也正是InterSystems的成功示范，使后关系型数据库有了引领未来医疗卫生行业数据库市场的底气和资格。
“后”起之秀的特质
从全球应用市场看，医疗、政府、金融、交通、制造业是后关系型数据库的推崇者和先行者，其中，尤以医疗卫生行业应用为最早、较成功。
医疗环境本身的繁杂导致了海量数据关系和事物处理上的日益复杂，而这个行业对于数据库容量与安全要求显然高于其它行业――每日产生大量的医疗信息、面对排队等候的病人，只有全天全年一刻不停机、快速响应的数据库，才能担此大任。而基于传统关系型数据库开发的管理系统则普遍存在着响应速度慢、怠机频繁、存储超出冗余等弊端。如影随形并时常加剧的头疼困扰着信息管理员们。幸运的是，他们发现了减轻并彻底治愈这种症状的良剂――后关系型数据库，并开始从中受益。
这里不妨仍以InterSystems公司的Caché为例。据他们在400万个终端用户的应用反馈看，相比传统的关系型数据库，后关系型数据库的处理速度快了20倍；应用系统的稳定性提高了3倍；存储空间节约了一半；开发、使用和维护成本也降低许多。这样的成效来自于Caché或者说后关系型数据库本身的技术特质。这种整合了对象数据库访问、高性能SQL访问和强大的多维数据访问的后关系型数据库技术，为有大量用户使用的Web复杂事物处理提供了优化和集成功能；其在统一数据架构下自动定义的对象和表两种数据模型，因为无需进行代码转换，而使应用系统的开发效率得到极大提高；同时因其简单易行而大大降低了系统的维护成本。
值得关注的是，虽然一些厂商正试图扩展他们的数据模型来支持各种对象，但产品成熟度和市场反应方面仍需判断。Caché中拥有专利的高级对象技术――方法生成器，使开发者能够用简单、现实的方法思考并使用对象，甚至是那种极其复杂的对象都可自动定义并归类。这种面向对象的技术既是后关系型数据库的核心品质，也代表着未来数据库技术的发展方向。纵观后关系型数据库的市场反响，我们或许应该确认并坚持这种判断。
关系型数据库范文5
关键词：数据库:软件开发
中图分类号：S611文献标识码：A 文章编号：
引言
计算机技术中数据库是最重要的研究方向之一，随着日趋应用复杂化，传统的数据库不足已逐渐被显露出来，而面向对象技术的数据库将成为新一代数据库的发展方向。
1、关系数据库中的优势
面向对象是一种认识方法学，也是一种新的程序设计方法学。把面向对象的方法和数据库技术结合起来可以使数据库系统的分析、设计最大程度地与人们对客观世界的认识相一致。
面向对象技术利用对象、类等技术手段可以满足对一些领域数据库的特殊需求，与关系型数据库相比，面向对象技术的优势主要体现在以下几个方面。
1.1 支持复杂的数据模型。传统的关系型数据库不能支持复杂的数据模型，例如：文本、图像、声音、动画、图像等数据，其缺乏对这些数据信息的描述、操纵和检索能力。而面向对象技术具有这些方面的优势，面向对象技术应用到数据库领域后，对象的使用就可以满足对这些类型数据的相关操作。
1.2 支持复杂的数据结构。传统的关系型数据库不能满足数据库设计的层次性和设计对象多样性的需求，关系型数据库中的二维表不能描述复杂的数据关系和数据类型，而面向对象技术中的对象可以描述复杂的数据关系和数据类型。
1.3 支持分布式计算和大型对象存储。面向对象技术中对象、封装、继承等方法的应用可以支持分布式计算，并且支持独立于平台的大型对象存储。
1.4 更好地实现数据的完整性。面向对象数据库支持复杂的数据结构和操作的约束、触发机制，从而可以更好地实现数据的完整性。
2、面向对象技术应用在关系数据库中的实现方法
由于计算机网络、多媒体技术、CAD/CASE等新型数据库应用的需要，数据库领域开始借助面向对象技术来满足这些需要。面向对象技术借助对象、封装和继承机制可以实现对复杂对象和复杂数据模型的支持，将面向对象技术应用于数据库是解决当今许多新型数据库应用中遇到的问题的好办法，虽然面向对象技术和数据库的结合沿着三个方向发展，当前多数数据库生产商都在研发如何将面向对象技术应用到关系数据库中。将面向对象技术应用到关系数据库中可以有两种方式。
2.1 把面向对象技术中的对象作为关系数据库系统中的一种新的数据模型。关系表中的属性值包含对象指针，对象数据的操作在关系数据库之外进行。把面向对象数据模型(ODM)和关系数据模型(RDM)结合起来，对荚系数据库管理系统进行扩充，但对象查询功能受到一定的限制。
2.2 把面向对象接口添加在关系数据库中。在关系数据库系统中增加一个对象到关系转换器，将上层的面向对象模式转化为关系存储模式，存放到关系数据库中。这样，在面向对象的数据库中关系存储模型位于底层。数据库用户可以利用标准的面向对象数据库语言进行查询处理，用户输入的面向对象数据库语言被转换成关系数据库语青，从而对底层的关系存储模式进行查询等处理，同时将操作结果按照对象方式返回给用户。这种实现方式使得数据库管理系统存实现关系模型和面向对象模型之间的模型转换时需要一定的开销，执行效率比直接面向对象数据库要低一些，但这种扩充方式实现比较简单。
面向对象技术通过映射接口和关系数据库相结合，面向对象数据库强调的是对象的属性、方法和对象间的关系。设计这种类型的数据库需要理解对象到关系数据库表的映射方法。这种映射方法通过将对象类生成为 SQL 语言中的数据定义语言(DDL)来将对象转换成一个好的概念层的数据模型(DDL)。
3、面向对象关系数据库系统的应用实例
3.1 系统构想。设想这个是物流信息 MIS 系统。该 MIS 系统有几种验证方法：（1）通过使用的和选择的物流公司。如果其在其业务的IP段的话，就认为是在物流公司上网，可认为是管理人员，将自动通过注册请求，系统发激活邮件；（2）不符合第一种情况的话，看选择的注册方式如果是使用 IP 电话的话去根据选择的物流公司看填写的 IP 电话是否符合所在区域的 IP 段，如果符合的话，系统发激活邮件；（3）选择物流公司邮箱注册，根据选择的物流公司和他填写的邮箱，如果域名符合就认为注册人为合法客户，系统发激活邮件；（4）选择其他方式，通过人工方法去确认注册者的合法性。以上是用户注册的过程，注册成功后，用户通过激活账户的链接，激活自己的账户，然后登陆，登陆成功后就可以使用注册用户可以使用的所有功能。管理员除可以拥有所有注册用户可以使用的功能外，还可添加物流公司及运单信息；编辑公司所在的 IP 段，查看所有用户的状态，进行活动管理，即添加、编辑活动，设定活动规则。应用系统需要响应用户的操作；另应用系统还需要给出各种各样的排行；需要按照规则确定活动的获奖者等：需要记录用户的操作，以确定用户的积分。
3.2 数据库部署。整个系统分为三层，客户层、业务逻辑层及数据访问层，选择 sqlserver2000 作为数据库。项目使用 asp．net 作为开发平台，用 c#作为开发语言，相应的使用 IIS6.0 作为Web 服务器。本系统的两种角色注册用户和管理员用户的问题，在上面的类结构设计时，让管理员继承的注册用户类，这样管理员就自然的拥有注册用户可以使用的所有权限，而它本身还可以拥有自己的权限，对物流公司的管理，对运单、货物及注册用户的管理。在页面类设计时采用这样的设计来确保使用页面的权限问题。设计三个类 BasePage、BasePageFor1.0gin、BasePage-ForAdmin，这三个类都继承自 System.Web.UI．Page 重载了 Ren-der 方法，这样就可以为同一级别的页面绘制相同的导航条，使页面的风格统一化；BasePage 类来作为未注册用户可以浏览的页面的基类，BasePageForLogin 类作为只有注册用户才可以浏览页面的基类，BasePageF0rAdmin 类作为只有管理员才可以浏览页面的基类。然后就可以在这些类的 render 方法中进行统一的权限设置及出错管理。
4、总结
关系型数据库范文6
关键词：多媒体数据库；研究；实现
中图分类号：TP311.13
1 多媒体数据库的概述
多媒体数据库将各式各样的多媒体对象按照一定的规律组合起来，构造一个集合，它可以供其他应用分享。多媒体数据库的表现方式既有格式化的，又有非格式化的。格式化的包括字符、数字等方式。非格式化的包括许许多多的多媒体方式。多媒体数据库管理系统以多媒体数据库为基础，可以对之进行操作和控制，例如，对多媒体数据库的创造、搜索、删除等等。
2 多媒体数据库系统的结构
2.1 层次结构。在多媒体数据库中，物理层是指描述各种各样的多媒体数据如何在计算机的物理储存设施中进行放置的，它是物理储存的代表。同时，绝大多数多媒体数具有规律的放置在数据库中。例如，个人的档案管理放置在信息管理数据库中，声音数据放置在声音数据库中，图像数据放置在图像数据库中等等。
在完成对各式各样的多媒体数据库的集中管理时，多媒体数据库应用程序的研发人员采用了概念层所提供的数据库描述语言。概念层是由许多多媒体数据库的概念对象组成的，它的数据形式与其他多媒体数据库的概念形式相符。概念层是为了描述抽象对象而产生的，它是对现实世界对象的一种虚构。
表现层由两部分组成，第一部分是视图层，第二部分是用户层。用户经常会面对图像、画面以及播放的声音等数据形式，这些数据形式是多媒体数据库用户层的外在形式。用户层利用专业的多媒体语言来为用户提供相关的使用接口。由于非格式数据有着各式各样的数据形式，并且千差万别的非格式数据联系紧密，因此，相较于传统的数据库，表现层在多媒体数据库中的地位更加稳固。
2.2 体系结构。集中型的多媒体数据库系统是由一个独立的多媒体数据库系统来创建不同媒体的数据库，并且由该系统管理对象领域和目标数据的集合。
图1 集中型多媒体数据库系统的体系结构图
从数据库系统是指自身的系统管理自身的数据库，这些从数据库系统再由主数据库系统控制。用户在采用多媒体数据库中的数据时，如果是从主数据库系统中获得数据，则要通过主数据库系统提供的功能来完成。目标数据的集合也是由主数据库系统来管理的，它们之间的关联如下图2：
图2 主从型多媒体数据库管理系统
协作型的多媒体数据库系统同样是由多个数据库系统构成的，各个数据路系统的地位必须相当，并且运作时必须协调。由于每一个多媒体数据库系统是有差异的，因此，在通信中应该首先解决差异性这一难题。为此，我们在每一个多媒体数据库系统之外添加一个外部处理软件模块，由它来供给沟通、搜索和维修的界面。在协作型的多媒体数据库系统中，用户的位置可以是任意的。协作性多媒体数据库系统体系结构如下图3所示：
图3 协作型MDBMS的体系结构
3 多媒体数据库实现的技术
3.1 基本技术：（1）硬件技术。多媒体数据库的对象主要是纷繁的多媒体储存数据，因此，多媒体数据库的压缩技术至关重要。多媒体储存数据占了很大空间，例如，几十秒的mp3可能要占几百KB的储存空间，一幅JPG格式的图片可能要占几MB的储存空间。因此，我们应当用压缩技术来压缩数据，以便于储存，当再次需要数据时，我们再将数据还原。数据的储存经常会采用硬盘、软盘和U盘等储存器。（2）软件技术。建模是多媒体数据库的中心内容。目前，多媒体数据库的模型有四种：第一种是面向对象的多媒体数据库模型；第二种是面向关系的多媒体数据库模型；第三种是研发创新的多媒体数据库模型；第四种是利用超媒体或超文本方法的多媒体数据库模型。
随着多媒体数据库程序语言、开放式研发平台和虚拟现实技术的产生并聚集，多媒体数据库的应用界面得到改善，这样一来，用户与多媒体数据库的图像和视频接流更加便捷。传统的数据库已不能满足多媒体数据库管理的要求，因此，我们要解决数据的表现形式和压缩技术，对于数据储存空间较大的对象，多媒体数据库采用分页存放方式来管理。多媒体数据库的图像处理要从静态到动态，对于图像和视频等多种数据形式，要分析并总结它们复杂的数据形式，并编制科学高效的管理程序。
3.2 构造方法。多媒体数据库的建立以关系数据库为基础。对于多种多媒体数据形式，传统的关系数据库抽象能力比较弱，不能支持非格式化的数据结构，不能进行推理操作，抑制了关系数据库的表达能力，因此，在对复杂的多媒体对象进行描述时，关系数据库模型并不适用。但是，关系数据库理论比较完善，应用比较广泛，在关系数据库的基础上构造多媒体数据库也是合理的。我们扩展了传统的关系数据库模型，战胜了它结构简单的缺陷，将完善之后的关系数据库应用于多媒体数据库中，使之既可以支持格式化数据，又可以处理非格式化数据，
多媒体数据库的建立以面向对象的数据库为基础。多媒体数据库从多媒体数据的构造方式出发，用崭新的管理机制来管理用户数据类型，并且构造和善的交互接口。由于面向对象的数据库系统比较罕见，因此，与之相关的研究还有待充实和完善。
由于多媒体数据所处的环境千差万别，而且它表达生动并相互联系，因此，它的建模十分复杂。为了解决该问题，人们探索并得到了分布式超媒体数据库。分布式超媒体数据库是以超媒体信息处理方法为基础的数据系统，它用超媒体结点来描述对象实体之间的关联，并提供了一种基于内容的查询方法，使用户人机交互模式更加和谐。同时，它不仅可供查询，而且可供欣赏挑选，使数据库可以自动获取用户喜欢的东西，并用宏文献的结构来支持各种大型的数据库。
4 结束语
本文从多媒体数据库的概述、系统结构和实现技术等方面来阐述多媒体数据库。我们知道，多媒体数据库的技术还缺乏成熟的理论指导，甚至在实现时会面临很大的困难，但是，多媒体数据库的技术还在探索完善中，相信随着科学技术的日益进步，多媒体数据库会有一个光面的前景。
参考文献：
[1]钟玉琢.多媒体计算机技术基础及应用[M].北京：高等教育出版社，2005.
[2]张海莲，邢海峰.一种多媒体数据库管理系统的设计与实现[J].计算机工程与应用，2003（26）.
[3]周立柱，赵洪彪.数据库研究的发展与方向[J].微电脑世界，1997（03）.
