请问“阐述数据库的软件结构”这个题怎么回答

软件架构

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象 *** 作、逻辑和流程。

是一般而言，软件系统的架构（ArchitECture）有两个要素：

·它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

历史

早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和MiCROSoft内部的相关活动，软件架构这个概念开始越来越流行起来。

卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。 加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。

下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严谨，风格雄浑。难以想象这是石器时代的建筑物。

图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。（摄影：作者）

软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwaRDS our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（FORMs follows function）。

几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。

架构的目标是什么

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

·可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

·可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

·可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

·可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

·客户体验（Customer Experience）。软件系统必须易于使用。

·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

架构的种类

根据我们关注的角度不同，可以将架构分成三种：

·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图

图2、一个逻辑架构的例子

从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

·物理架构、软件元件是怎样放到硬件上的。

比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

图3、一个物理架构的例子

·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。

根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

构架描述

为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。

构架视图

我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

典型的构架视图集

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。

进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。

配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。

构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

构架重点

虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：

模型的结构，即组织模式，例如分层。

基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。

几个关键场景，它们表示了整个系统的主要控制流程。

记录模块度、可选特征、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：

系统演进，即进入下一个开发周期。

在产品线环境下复用构架或构架的一部分。

评估补充质量，例如性能、可用性、可移植性和安全性。

向团队或分包商分配开发工作。

决定是否包括市售构件。

插入范围更广的系统。

构架模式

构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。

构架模式示例

[BUS96] 根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

类别 模式

结构 层

管道和过滤器

黑板

分布式系统 代理

交互系统 模型-视图-控制器

表示-抽象-控制

自适应系统 反射

微核

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

为阐明其含义，下面将详述其中的两个；完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示：

模式名

环境

问题

影响，描述应考虑的不同问题方面

解决方案

基本原理

结果环境

示例

模式名

层

环境

需要进行结构分解的大系统。

问题

必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。

影响

系统的某些部分应当是可替换的

构件中的变化不应波动

相似的责任应归为一组

构件大小 -- 复杂构件可能要进行分解

解决办法

将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。

示例：

1 通用层

严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始 *** 作系统级调用，它包括更明显的机制。

2 业务系统层

上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。

有关该模式的深入讨论，请参见指南：分层。

模式名

黑板

环境

没有解决问题的确定方法（算法）或方法不可行的领域。例如 AI 系统、语音识别和监视系统。

问题

多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

影响

知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略

不同顾问的输入（结果或部分解决方案）可能有不同的表示方式

各顾问并不直接知道对方的存在，但可以评估对方发布的工作

解决办法

多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。

示例：

以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。

构架风格

软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。

构架设计图

构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：

逻辑视图：类图、状态机和对象图。

进程视图：类图与对象图（包括任务 - 进程与线程）。

实施视图：构件图。

部署视图：配置图。

用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。

构架设计流程

在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。

架构师

软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。

这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。

但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

传统数据库是关系型数据库，开发这种数据库的目的，是处理永久、稳定的数据。

关系数据库强调维护数据的完整性、一致性，但很难顾及有关数据及其处理的定时限制，不能满足工业生产管理实时应用的需要，因为实时事务要求系统能较准确地预报事务的运行时间。

整套的SQL Server 2012是由一系列的服务组件组成，各服务组件有其特有的功能，按照功能需要安装不同的服务组件，以达到最佳的性能和最少的费用；

其组件和功能如下：

(1)Database Engine Services:最核心的服务组件，负责数据库的数据存储，处理和数据安全，提供数据访问控制，快速的事务传输和数据库的高可用性；

（2）SQL Server Replication:支持不同的数据库之间数据的复制和分布；保证同步数据之间的一致性；

（3）Full-Text and Semantic Extractions For Search:支持全文搜索，支持基于关键字的全文模糊搜索；

（4）Data Quality Servies:在数据交互过程中管理数据质量和完整性更加容易；

（5）Analysis Services:支持在线分析处理和数据仓库；

（6）Reporting Services -Native:让通过WEB或者email形式来 *** 作和传输数据更加容易；

（7）Reporting Services-Sharepoint:通过Sharepoint集成报表视图和报表管理；

（8）Reproting Services Add-in For Sharepoint Products:在Sharepoint和SQL Server之间的数据集成提供管理和用户端接口；

（9）Data Quality Client:提供集成服务和数据源质量之间的交互；

（10）SQL Server Data Tools:是基于VS2010的商业智能开发环境，用于创建分析服务，集成服务和集成服务项目；

（11）Client Tools Connectivity:服务器和客户端之间通讯组件；

（12）Integration Services: 使得数据存储之间迁移，集成和传输数据更加容易；

（13）Client Tools Backward Compatibility:客户端工具向后兼容,用于不同服务之间数据的兼容；

(14)Client Tools Software Development Kit(sdk):数据库应用程序开发人员用到的资源；

(15)Documnentation Components:帮助文档；

(16)Managements Tools-Basic:企业管理器支持数据库引擎，SQLCMD，SQL Server Powershell,分布式重放管理工具；

(17)Managements Tools-Complete:企业管理器支持报表服务，分析服务，集成服务，事件跟踪器，数据库优化向导，SQL Server管理工具；

(18)Distributed Replay Controller:管理Distributed Replay Client

(19)Distributed Replay Client:在数据库实例上激活分布式重放功能；

(20)SQL Client Connectivity SDK:为开发数据库应用程序提供客户端链接软件套件；

(21)Master Data Serivces：为集成服务提供数据平台；

1 Session组件。它提供应用程序中数据库的有关信息，在单机数据库编程中不显式地使用它，这是因为每个数据库应用程序运行时，Delphi将自动创建一个缺省Session组件，用户可在程序中使用这个缺省的Session组件，而没有必要在设计时设置一个Session组件。Table、Query等组件的属性中有一个SessionName属性，缺省为“Default”，这就是缺省的Session组件。比较常用的是用它的GetTableNames方法，在一些查询有时需要用户选择数据库中的数据表名称列表。比如在列表框中列出我们的数据库别名lklb中所有的数据表名称，代码如下（窗体上要有激活的数据集组件并指明了数据库别名）：

procedure TForm1Button1Click(Sender: TObject);

var MyStringList :TStringList;

begin

MyStringList := TStringListCreate;

try

SessionGetTableNames('lklb', '',False, False, MyStringList);

ListBox1Items := MyStringList;

finally

MyStringListFree;

end;

end;

GetTableNames方法的语法如下，

语法:SessionGetTableNames(DataBaseName,Pattern,Extensions,SystemTables,List)。

参数说明：

DataBaseName——数据库名称。

Pattern——数据表类型，用来限制返回哪种类型的数据表，比如是DB还是DBF,如果为空则返回所有类型数据表，可以用通配符。

Extentions——布尔型变量，控制返回的数据表是否有扩展名。

SystemTables——对一些数据库来说有系统数据表，若设定为True则返回的数据表名称包括系统数据表。一般设定为False 。

List—保存数据表名称的字符串列表。

2 DBNavigator组件。DBNavigator组件主要用于为用户 *** 作数据集中的记录提供简捷的控制按钮。用户单击其中的按钮就可完成移动记录指针、插入、删除、修改、保存、刷新记录等功能。它的 VisibleButtons属性可指定哪些按钮显示，通过设置Hints属性可以为各控制按钮设置其他的动态提示信息，用户自己设置的动态提示信息会覆盖原来的提示信息，对我们来说提示信息写成中文比较好。

3 DBtext组件。相当于标签（Label）组件，只不过它用于显示数据库中的字段值，其显示内容随记录指针的变化而变化。它的DataField属性指定要显示内容的字段名称。

4 DBEdit组件。用于显示、修改数据表字段值。由于DBEdit一般用来修改或添加新记录使用，所以其ReadOnly属性一般设定为False，若设定为True则不可修改字段内容。

在Microsoft SQL Server 2005中,用于数据存储的实用工具是数据库。数据库的物理表现是 *** 作系统文件，即在物理上，一个数据库由一个或多个磁盘上的文件组成。这种物理表现只对数据库管理员是可见的，而对用户是透明的。逻辑上，一个数据库由若干个用户可视的组件构成，

如表、视图、角色等，这些组件称为数据库对象。用户利用这些逻辑数据库的数据库对象存储或读取数据库中的数据，也直接或间接地利用这些对象在不同应用程序中完成存储、 *** 作和检索等工作。逻辑数据库的数据库对象可以从企业管理器中查看 每个SQL Server 2005数据库(无论是系统数据库还是用户数据库)在物理上都由至少一个数据文件和至少一个日志文件组成。

出于分配和管理目的，可以将数据库文件分成不同的文件组。 数据文件：分为主要数据文件和次要数据文件两种形式。每个数据库都有且只有一个主要数据文件。主要数据文件的默认文件扩展名是．mdf。它将数据存储在表和索引中，包含数据库的启动信息，还包含一些系统表，这些表记载数据库对象及其他文件的位置信息。

次要数据文件包含除主要数据文件外的所有数据文件。有些数据库可能没有次要数据文件，而有些数据库则有多个次要数据文件。次要数据文件的默认文件扩展名是．ndf。 日志文件：SQL Server具有事务功能，以保证数据库 *** 作的一致性和完整性。所谓事务就是一个单元的工作，

该单元的工作要么全部完成，要么全部不完成。日志文件用来记录数据库中已发生的所有修改和执行每次修改的事务。SQL Server是遵守先写日志再执行数据库修改的数据库系统，因此如果出现数据库系统崩溃，

数据库管理员(DBA)可以通过日志文件完成数据库的修复与重建。每个数据库必须至少有一个日志文件，但可以 不止一个。日志文件的默认文件扩展名是．1df。建立数据库时，SQI。Server会自动建立数据库的日志文件。

文件组：一些系统可以通过控制在特定磁盘驱动器上放置的数据和索引来提高自身的性能。文件组可以对此进程提供帮助。系统管理员可以为每个磁盘驱动器创建文件组，然后将特定的表、索引、或表中的text、ntext或image数据指派给特定的文件组。

SQI．Server有两种类型的文件组：主文件组和用户定义文件组。主文件组包含主要数据文件和任何没有明确指派给其他文件组的文件，系统表的所有页均分配在主文件组中；用户定义文件组是在CR E_ATE DATA_BASE或AI,TER DATA．BASE语句中，

使用FII,EGROUP关键字指定的文件组。SQt．Server 2005在没有文件组时也能有效地工作，因此许多系统不需要指定用户定义文件组。在这种情况下，所有文件都包含在主文件组中，而且SQI。Server 2005可以在数据库内的任何位置分配数据。

每个数据库中都有一个文件组作为默认文件组运行。当SQI。Server给创建时没有为其指定文件组的表或索引分配页时，将从默认文件组中进行分配。一次只能有一个文件组作为默认文件组。如果没有指定默认的文件组，主文件组则成为默认的文件组。

分类: 电脑/网络 >> 软件 >> 其他软件

解析:

所谓B/S结构，就是只安装维护一个服务器（Server），而客户端采用浏览器（Browse）运行软件，即浏览器/服务器结构。

一、C/S与B/S结构模式

随着Inter获得愈来愈广泛的应用,原来基于LAN的企业网开始采用Inter技术

来构筑或改建自己的企业网,即Intra。于是,一种新的结构模式Browser/Server结构

应运而生,并且获得飞速发展, 成为众多厂家争相采用的一种技术。其实,B/S也是一种C

li/Server结构,它以浏览器为客户端软件,Web Server为服务器软件。但相对于C/S结

构,它又具有许多独特的优点:

(1) B/S是一种跨平台的、一点对多点及多点对多点的应用软件结构,减少了开发人

员在客户端的工作量,使他们可以把注意力集中到怎样合理地组织信息、提供客户服务上

来。

(2) B/S具有统一的浏览器客户端软件,不仅节省了开发、维护客户端软件的时间与

精力,而且方便了用户的使用。

(3) 在B/S结构中,客户端只需运行 *** 作系统和Web浏览器,数据的查询、处理和表示

都由服务器完成。和C/S结构的应用系统相比,客户端变得非常"瘦"。

(4) 可以透明地跨越异质网络、计算机平台,无缝地联合使用数据库、超文本、多媒

体等多种形式的信息。

(5) B/S系统运行的Inter易于设置、使用和管理。

目前,许多C/S体系结构的应用系统纷纷被重构为B/S结构,然后移植到Intra环境

下。我们在研究了UUHDB系统的体系结构和Web服务器下应用程序的运行机制后,尽可能对

UUHDB系统进行了最小修改,将其从一个C/S结构的系统改建为一个B/S结构的系统,使用户

能够通过浏览器对其进行访问。

二、B/S结构下的UUHDB系统

C/S结构的UUHDB系统从功能上可划分为两大部分:UUHDB数据处理系统和UUHDB输入/

输出系统,如图1所示。

@@0630000JPG;图1 UUHDB系统的功能分布图(B/S结构)@@

UUHDB数据处理系统是整个UUHDB系统的核心,首先事务管理器接收客户端传送的查询

命令(一般被称为用户请求,包括查询、更新,这里以查询为例说明),进行语法检查、查询

分解和优化处理;分解后的子查询被送往各局部数据库服务器,由它们具体实施;最后查询

子结果返回到事务管理器中汇总,完成一次全局查询的全过程。

UUHDB输入/输出系统提供了一个和数据库进行交互的用户界面,包括数据的输入、输

出以及对数据库的控制等功能。

把C/S的UUHDB系统改造为B/S结构模式的主要思想是: UUHDB数据处理系统基本保持

不变,去掉原来的客户端即输入/输出系统,代之以浏览器,通过Web服务器和CGI程序与 U

UHDB数据处理系统连接在一起,重新构成一个完整的、运行在Intra网络环境下的数据

库应用系统。改建后的UUHDB是典型的B/S结构模式,如图2所示。

@@0630001JPG;图2 B/S结构模型@@

三、B/S结构的UUHDB系统的运行环境

在原来的分布式局域网的基础上,安装了浏览器、Web服务器以及域名服务器,构成一

个Intra环境,其中,Web服务器与UUHDB系统的事务管理器在同一台机器上,各数据库服

务器不需重新安装,仍以分布式状态存在,如图3所示。

@@0630002JPG;图3 UUHDB的研究环境(Intra环境)@@

四、B/S结构的UUHDB系统的用户输入界面

改造后的UUHDB系统以浏览器作为客户端,为了方便用户的使用,我们提供了三种不同

级别的SQL命令的提交方式:嵌入式、输入式和交互式,以适应不同用户、不同场合的需求

。

1 嵌入式

这是最简单的一种方式。它是指在HTML文本的超联接中把SQL命令作为参数追加在C

GI程序之后,用户只能被动地访问数据库,不具有交互性。

2 输入式

在浏览器上提供一个文本编辑窗口,用户可以由此输入SQL命令。所有的数据库 *** 作

都可以通过这种方式完成,但要求用户必须懂得SQL语言。

3 交互式

制作一套查询命令的动态生成规则,以FORM表单为载体,使用户通过简单的选择、输

入即可完成对数据库的查询。界面友好亲切,使用简单,不需要用户了解SQL语言。如界面

上给出字段名,可为代号、姓名、年龄、性别、职称等,用户可选择所需字段,作为查询内

容,其值可作为查询条件。

目前,通过浏览器,用户可以对UUHDB进行全局数据查询和全局数据 *** 纵(包括插入、

修改、删除)等 *** 作。

五、B/S结构的UUHDB系统采用的通信方式

由于UUHDB是一个B/S结构的分布式数据库系统,用户通过浏览器对数据库进行访问,

因此存在多个用户同时访问Web服务器请求数据服务的现象,从而提出了并行性数据处理

的要求,即如何使多个用户能够同时访问全局库而不必相互等待和干扰,这也是UUHDB在W

eb网络环境下必须具备的基本特征之一。

在UUHDB前端的改造中,这一并行性问题是采用进程间通信的方式——DDE协议解决的

。

在UUHDB系统中,用户从浏览器上输入的查询命令通过网络传输到Web服务器端,由CG

I程序读取后,进行格式转换生成SQL语句,然后以DDE对话的形式传送给UUHDB的数据处理

系统,由其进行下一步的处理,具体的通信模型如图4所示。

@@0630003JPG;图4 CGI进程与全局事物管理器的并行通信模型@@

在图4中,每个CGI进程有三个部分组成:

(1) SQL生成:读取环境变量或标准输入,按照动态生成规则生成SQL语句。

(2) DDE客户:和DDE服务器进行通信,传送SQL语句并接收处理结果。

(3) 结果处理:把DDE客户接收的数据转换成HTML格式,通过标准输出交给Web服务器

,由其负责传送到浏览器。

图中与CGI进程相对应的数据处理系统可划分为两个功能部分:

(1) DDE服务器:接收DDE客户传来的SQL语句,并返回UUHDB数据处理系统的执行结果

。

(2) 数据处理:包括语法检查、查询分解、命令执行和结果汇总等。

以上就是关于请问“阐述数据库的软件结构”这个题怎么回答全部的内容，包括:请问“阐述数据库的软件结构”这个题怎么回答、传统数据库结构主要有什么、sql server有哪些组件组成等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！