17xie > SQL Server 2005高级程序设计 > 1.2 数据库对象概览
背景:                 
[本书目录] [图书首页] [本书讨论区]  
链接地址:http://www.17xie.com/read-104906.html    注册17xie 一起来写书 实现您的出书梦想!

1.2  数据库对象概览

像SQL Server这样的RDBMS包含许多对象。对象纯化论者可能会纠缠于微软公司对对象的定义是否真正符合对象的标准定义,然而,对于SQL Server的用途而言,更重要的数据库对象包含如下的事物:

数据库本身                                                索引

事务日志                                                     CLR程序集

表                                                                  报表

文件组                                                         全文目录

关系图                                                         用户定义数据类型

视图                                                             角色

存储过程                                                     用户

用户定义函数                                           

1.2.1  数据库对象

数据库实际上是SQL Server中最高级别的对象。(技术上来说,服务器本身也可认为是一个对象,但是这不符合任何真正的“编程”观点,因此此处不这样看。)SQL Server中的大多数(但并非全部)对象都是数据库对象的子对象。

熟悉老版本SQL Server的人可能会问,“那么,登录名呢?远程服务器和SQL代理任务呢?”SQL Server中有其他一些支持数据库的对象(如前面列出的那些)。除了链接服务器(或许还有Integration Services包)外,这些对象主要属于数据库管理员的领域,在设计和编程的过程中通常不会对这些对象有太多的关注。[通过SQL管理对象(SMO)也可以对它们进行编程,但这是很特殊的情形,不必在此处考虑。第25章将对SMO作全面讲述。]

数据库通常至少包含一组表对象,并且多半还包含其他对象,如存储过程和视图(与存储于数据库的表中数据的特定分组有关)。

首次载入SQL Server时,将从4个系统数据库开始:

l    master;

l    model;

l    msdb;

l    tempdb。

要让服务器正确运行,需要安装所有这些数据库。(实际上,没有它们,服务器根本无法运行。)此后,根据你所做的安装选择,事情将有所不同。可能会看到下面这些示例数据库:

l    AdventureWorks(示例数据库);

l    AdventureWorksDW(Analysis Services用到的示例)。

1.master数据库

所有的SQL Server都有master数据库,无论什么版本或者如何定制修改。master数据库中保存着一类特殊的表(系统表),它们从整体上管理系统。例如,当你在服务器上创建新的数据库时,将向master数据库的sysdatabases表中加入一条新的记录。所有的扩展存储过程和系统存储过程,无论它们将用在哪一个数据库中,都存储在master数据库中。显然,由于几乎所有描述服务器的信息都存储在master数据库中,因此该数据库对于整个系统是至关重要的,并且不能删除。

系统表(包括master数据库中的系统表)只在必要时才可能非常重要。随着微软不断提供越来越多的其他方式来访问系统级别的信息,直接使用系统表的情形越来越少。

没有仔细阅读上面一段的读者可能想去看看用用系统表。千万别去!以任何形式使用系统表都是充满危险的。微软公司在至少最近3个版本的SQL Server里劝告不要使用系统表。他们绝对不保证版本间master数据库的兼容性——实际上,他们是会改变master数据库的。对master数据库中的对象进行升级是极大的错误。一定要记住,以任何方式对这些表进行改动都是想让SQL Server失去作用。庆幸的是,可以使用一些替代的方法(例如系统函数、系统存储过程和信息模式视图)来获取存储在这些系统表中的大量元数据。

2.model数据库

model数据库的命名十分恰当,这一名称说明它是建立副本所基于的模型。model数据库为创建新的数据库提供模板。这意味着,如果你愿意,当想要改变标准的、新建的数据库时,可以修改model数据库。例如,可以加入一组审计表,使得创建的所有数据库中都包含这些表。也可以放进一些用户组,这样在系统上新建的所有数据库中都将复制它们。注意,由于model数据库是所有其他数据库的模板,因此该数据库是必需的,且必须留在系统上,不可删除。

修改model数据库时,需要紧记一些事情。首先,新建的任何数据库,至少与model数据库一样大,即如果把model数据库的大小更改为100 MB,那么将无法创建小于100 MB的数据库。此外还有其他一些类似的隐患。因此,对于90%的安装,我都强烈建议不要修改该数据库。

3.msdb数据库

msdb是SQL代理过程存储系统任务的地方。如果计划在夜间对数据库进行备份,那么在msdb中将有一条记录。如果安排一个一次性执行的存储过程,那么同样在msdb中会有一条记录。

4.tempdb数据库

tempdb是服务器的一个关键的工作区域。在执行复杂的或大量的查询时,如果SQL Server需要创建中间表来完成,那么SQL Server将在tempdb中进行。在创建临时表时,尽管你认为是在当前数据库中创建的,但实际上是创建在tempdb中的。当需要临时存储数据时,数据很可能是存储在tempdb中的。

tempdb与其他数据库有很大的不同,这不仅因为tempdb中的对象是临时的,而且,tempdb自身也是临时的。每次启动SQL Server时,tempdb是系统中唯一完全重新创建的数据库。

从技术上说,实际上你可以自己在tempdb中创建对象——但我强烈建议不要这样做。可以从系统中任何你有权使用的数据库里创建临时对象——创建的临时对象将存储在tempdb中。直接在tempdb中创建对象,除了带来在数据库间引用的混乱外,没有任何好处。这是又一个“别去做”的事情。

5.AdventureWorks

微软公司在2005版本之前的SQL Server中就已经包含了不少示例。不过早期的示例有缺点。例如,示例中包含一些糟糕的设计实践。(对于AdventureWorks是否具有同样的问题,我先不做评判。但AdventureWorks试图改善这一问题。)此外,它们过于简单化,只注重说明某些数据库概念,而不是把重点放在作为一个产品的SQL Server上,或者放在作为一个整体的数据库上。

从Yukon(这是现在的SQL Server 2005的内部代号)开发的最初阶段,微软公司就明白需要一个更稳定、更强健的示例数据库,这个数据库要尽可能地像一个产品。AdventureWorks就是这种努力下的产物。对于AdventureWorks,你听到的多半是我抱怨它对于初级用户太过复杂,但它实在是太炫目了,简直是一个杰作。好吧,即便它实际上并非面面俱到,但也算得上是相当完备的示例了,它有更真实的数据量、更复杂的结构以及用以展示大多数产品功能的组成部分。从这种意义上说,它是非常了不起的。

本书将以它作为核心的示例数据库。

6.AdventureWorksDW

AdventureWorksDW是Analysis Services的示例。(DW代表数据仓库,它是作为大多数Analysis Services方案基础的一种数据库。)关于示例数据库最棒的是,微软公司很有远见地把事务数据库示例同分析示例结合在一起,给出展示二者一起工作的一套完整的示例。

决策支持数据库超出了本书的讲述范围,因而不会使用到该数据库,但是在你开始学习了解Analysis Services时请想到它。看看两个数据库间的区别。它们都是为同一个虚构的公司服务的数据库,不过它们的用途各不相同。

1.2.2  事务日志

信不信由你,数据库文件本身并不是大多数事情发生的地方。尽管数据的确是从数据库文件读入的,但你所做的任何修改不是一开始就发生在数据库上,而是连续地写入事务日志(transaction log)中。在随后的某个时间点,数据库发出一个检查点(checkpoint)——正是在那个时刻,日志中所有的修改才被传送到实际的数据库文件。

数据库是随机访问的,但日志本质上是连续的。数据库文件的随机访问特性能加快访问的速度,而日志文件的连续特性使得能够以正确的顺序追踪事情。日志中积累了被认为是已经提交的修改,服务器将在以后的某个时间把修改写到物理数据库文件。

第12章将更详细地讲述事情是如何记入日志的,眼下只需要了解,数据到达磁盘上的最初地方是日志,然后才被传送到实际的数据库中。性能良好的数据库既需要数据库文件,也需要日志文件。

1.2.3  最基本的数据库对象:表

数据库由许多事物构成,表是所有数据库的构成中最为重要的。可以把表想象成Excel电子表格。表由域(domain)数据(列)和实体(entity)数据(行)构成。数据库中的数据存储在表中。

每个表定义中也包含元数据(metadata)(数据的描述信息),以说明表中包含的数据的属性。每一列都有它自己的一组规则,以限定该列中能存储什么。违反任何一列的规则,都将导致系统拒绝行的插入或对已有行的更新,或者阻止行的删除。

1.索引

索引(index)是只存在于特定表或视图结构中的对象。索引的作用与百科全书后面的索引十分相似。索引中,以特定的方式存储了某类查找(即“键”)值,一旦有了它,就能得到另外一个键,通过该键可以找到实际要查找的信息。

索引提供了一种加快信息查找的方式。索引分为两类:

l    聚集索引(clustered index)——每个表只能有一个聚集索引。如果一个索引是聚集的,那么,该索引所基于的表,其物理存储顺序与该索引一致。如果是在对百科全书建立索引,那么聚集索引将是书的页码,百科全书中的信息按照页码的顺序进行存储。

l    非聚集索引(non-clustered index)——每个表可以有许多非聚集索引。非聚集索引或许更像是当你听到索引一词时所认为的那种索引。这类索引指向能引导你找到数据的一些其他值。对于百科全书来说,这将是位于书后面的关键字索引。

注意,具有索引的视图(或称索引视图)在拥有任何非聚集索引之前,必须至少要有一个聚集索引。

2.触发器

触发器(trigger)是只存在于表结构中的对象。触发器是当表中发生特定的事情(如插入、更新或删除)时,自动执行的一段逻辑代码。

触发器能够用在很多的事情上,但它主要用于在输入数据时复制数据,或者检查更新以确保满足某些条件。

3.约束

约束(constraint)是又一个仅存在于表范围内的对象。顾名思义,约束的作用就是限定表中的数据以满足某些条件。在某种程度上,约束与触发器作用类似,都是数据完整性问题上可能的解决方案。然而,它们不是同一种东西,每一种都有其自身独特的优点。

1.2.4  模式

模式(schema)可以用于在数据库和数据库所包含的其他对象之间设置命名空间。在所有数据库中,默认的命名空间都是“dbo”(代表数据库所有者)。每个用户都有一个默认的模式,SQL Server会自动在用户的默认模式里搜索对象。然而,如果对象所在的命名空间不是用户的默认模式,则必须以<schema name>.<object name>这种两部分的形式引用对象。

模式取代了以前版本SQL Server中“所有者”(owner)的概念。微软公司似乎要在当前的版本中突出其作用(目的是能够通过表所在的模式引用一组表,而不是全部一一列出),但我对此持怀疑态度。简言之,我认为这样做带来的问题远多于解决的问题,所以我通常建议避免使用它(也有例外,但都是在特定情形下)。

1.2.5  文件组

默认情况下,所有的表以及与数据库有关的所有其他事物(除日志外)都存储在一个文件中。该文件是主文件组(primary filegroup)的成员。然而,也不是非得坚持这样的安排。

SQL Server允许定义大约32 000个辅助文件(secondary file)。(如果你需要更多的辅助文件,或许这就不是SQL Server的问题了。)辅助文件可以加入到主文件组中,也可以创建为一个或多个辅助文件组(secondary filegroup)的成员。尽管只能有一个主文件组(该文件组实际上称为“Primary”),但是,可以有255个辅助文件组。通过CREATE DATABASE和ALTER DATABASE命令的选项创建辅助文件组。

1.2.6  关系图

数据库关系图将在讨论数据库设计时更详细地讲述,这里只需要了解数据库关系图是数据库设计(包括各种表、每个表中的各个列名以及表之间的关系)的可视化表示形式。在开发的过程中,你可能听说过实体—关系图(Entity-Relationship Diagram,ERD)。ERD把数据库分为两部分:实体(例如“供应者”和“产品”)和关系(类似于“供应”和“购买”)。

虽然SQL Server 2005做了重新设计,但是,包含的数据库设计工具还是比较少。实际上,工具所使用的关系图方法没有遵循任何ERD中公认的标准。

尽管如此,关系图工具还是提供了所有“必需”的东西,这至少算是个开始。

图1-1是一个关系图,展示了AdventureWorks数据库中的各种表。该关系图还描述了数据库的许多其他属性(尽管对刚接触它的人来说不是很明显)。注意钥匙形的小图标以及无穷大符号。它们描述了两个表之间关系的性质。

图  1-1

1.2.7  视图

视图是一种虚拟表。大多数情况下,使用视图与使用表类似,只是视图中不包含自己的数据。实际上,视图仅仅是存储在表中的数据的预先计划好的映射和表现。这个计划以查询的形式存储在数据库中。该查询从一个或多个表的一些(不一定要是全部)列中获取数据。要显示在视图中的数据并不一定(取决于视图的定义)必须满足特别的标准。

一直到SQL Server 2000,视图的主要用途是控制视图的用户所见到的内容。这样做有两个重要的意图:安全性和易用性。通过视图能控制用户看到的内容,因此,如果一个表中的部分内容(如工资详情)只应当被少数用户看到,那么可以创建一个视图,视图中只包含能够被所有人访问的那些列。此外,还可以裁剪视图,使得用户不必从不需要的信息中进行查找。

除了可以创建具有这些最基本用途的视图外,还可以创建索引视图(indexed view)。索引视图与任何其他视图一样,只是还可以在视图上创建索引。这在性能上会有一些影响(若干正面的,一个负面的):

l    通常,对于引用多个表的视图而言,执行索引视图会快很多,因为索引视图预先构造了表之间的联结。

l    预先计算了视图中要执行的聚集,并将其存储为索引的一部分。这意味着(在插入或更新行时)执行一次聚集,然后,就可以直接从索引信息中读取结果。

l    由于需要立即更新视图上的索引,这使得数据插入或删除的开销更高;同样,如果数据更新会影响到索引的键列,那么更新也将有更高的开销。

第9章将就这些性能问题进行更详细的讨论。

1.2.8  存储过程

在SQL Server中,存储过程(stored procedure,sproc)历来是主要的编程功能,到了.NET时代更是如此。通常,存储过程是组成一个逻辑单元的一系列有序的Transact-SQL(用来查询Microsoft SQL Server的语言)语句。它们可以有变量和参数,也允许有选择结构和循环结构。比起发送单独的语句到服务器,使用存储过程有以下优点:

l    调用存储过程只需要使用一个简短的名字,而不必发送一大串的文本字符串,这样,运行存储过程中的代码需要的网络流量更小。

l    存储过程是经过了预先优化和预编译的,故每次运行存储过程都能节省少量的时间。

l    通常,为了安全性的原因或者仅仅为了隐藏数据库的复杂性,需要封装一个过程。

l    可以从其他存储过程中调用,使得它们能在有限的意义上重用。

此外,能够利用任何.NET语言向存储过程中添加超越T-SQL本身之外的程序构造。

1.2.9  用户定义函数

用户定义函数(User-Defined Function,UDF)与存储过程极其相似,除了以下的不同:

l    能返回大多数SQL Server数据类型的值。不能返回text、ntext、image、cursor以及timestamp类型。

l    不能有“副作用”。基本上,它们不能在函数的范围之外做任何事情,例如修改表、发送电子邮件、改变系统或数据库的参数。

UDF与标准程序设计语言(如VB.NET或C++)中使用的函数类似。可以传入多个变量并返回一个值。SQL Server的UDF与许多过程语言中的函数不同,比较而言,这里所有的变量都是以值传入函数的。这里没有类似于VB中的By Ref传入变量,也不存在C++中的传入指针。然而,好消息是可以返回特殊的表数据类型。我们将在第11章中考查其影响。

1.2.10  用户和角色

用户和角色是密切相关的。用户(user)非常类似于登录名。简言之,该对象是登录到SQL Server上的用户的标识符。登录到SQL Server的任何人都必须(根据使用的安全模型直接或间接地)映射为一个用户。用户再转而属于一个或多个角色(role)。然后,就能够把在SQL Server中执行特定动作的权力直接授予用户或(一个或多个用户所属的)角色。

1.2.11  规则

规则和约束对于什么能放入表中进行限定。如果更新或插入的记录违反了规则,那么更新或插入将被拒绝。另外,规则能够用来在用户定义数据类型(user-defined data type)上加以限制。与规则不同,约束本身并非实际的对象,而只是描述特定表的元数据。

尽管没有说明将从哪一个版本开始,但微软公司警告说后续版本的SQL Server将删除规则。规则只应当在向后兼容性问题上考虑,在新的开发中要避免使用规则。并且,可能还应考虑逐步淘汰当前数据库中尚在使用的规则。

1.2.12  默认值

默认值有两种类型。一种默认值其自身是一个对象;另一种默认值不是实际的对象,只是描述表中特定列的元数据(这与约束和规则类似,规则是对象,约束是元数据而不是对象)。两种默认值的作用相同。在插入记录时,如果没有为一个列指定值,而该列上定义了默认值,那么将自动使用默认值进行插入。第5章将对这两种类型的默认值进行讨论。

与规则一样,是其自身对象的默认值应该被当作遗留对象,并避免在新的开发过程中使用。然而,默认值约束依然非常有效。更详细的信息请见第5章。

1.2.13  用户定义数据类型

用户定义数据类型是系统定义数据类型的扩展。从SQL Server 2005开始,其潜力几乎是无穷的。虽然SQL Server 2000及更早版本中有用户定义数据类型的概念,但它们其实仅限于已有数据类型的不同筛选。在SQL Server 2005中能够把.NET程序集与用户定义数据类型绑定在一起,这就意味着可以有一种数据类型,该类型中完全能存储所有可以存储到.NET对象中的事物。

使用用户定义数据类型一定要慎重!你所使用的数据类型对于数据和数据的存储非常重要。虽然能够自己定义一些事情是非常酷的,但是也要明白,这样做几乎必定会导致很大的性能开销。因此,使用时一定要经过深思熟虑,要确信那的确是你所需要的,然后,再不断地测试、测试、再测试。

1.2.14  全文目录

全文目录是数据的映射,以加速对启用了全文搜索的列中特定文本块的搜索。虽然,对于所映射的表和列来说,这些对象是不可分割的,但它们毕竟是单独的对象,因此,当数据库中发生了改变时,它们不会自动更新。

1-1- 1

从图中我们可以看出Photoshop 7.0的工作界面由以下几个部分组合而成,它们分别是:

1)标题栏

这里显示当前应用程序的名字(即Adobe Photoshop),当我们将图像窗口最大化显示时,这里会改为显示当前编辑图像的文件名及色彩模式和正在使用的显示比例。标题栏右边的三个按钮从左往右依次为最小化、最大化和关闭按钮,分别用于缩小、放大和关闭应用程序窗口。

2)菜单栏

使用菜单栏中的菜单可以执行Photoshop的许多命令,在该菜单栏中共排列有9个菜单,其中每个菜单都带有一组自己的命令。

3)工具选项栏

Photoshop6.0开始,工具选项栏取代了以往版本中的工具选项面板,从而使得我们对工具属性的调整变得更加直接和简单。

4)工具箱

工具箱包含了Photoshop中各种常用的工具,单击某一工具按钮就可以调出相应的工具使用。

5)图像窗口

图像窗口即图像显示的区域,在这里我们可以编辑和修改图像,对图像窗口我们也可以进行放大、缩小和移动等操作。

6)参数设置面板

窗口右侧的小窗口称为控制面板,我们可以使用它们配合图像编辑操作和Photoshop的各种功能设置。执行【窗口】菜单中的一些命令,可打开或者关闭各种参数设置面板。

7)状态栏

窗口底部的横条称为状态栏,它能够提供一些当前操作的帮助信息。

8Photoshop桌面

在这里我们可以随意摆放Photoshop的工具箱、控制面板和图像窗口,此外我们还可以双击桌面上的空白部分打开各种图像文件。


字数:11616    最后更新:7个月以前 [04-23 15:22]happyskynet 修改
本页编辑者:happyskynet  
[前一页]:第1章 回顾SQL Serve…  [后一页]:1.3 SQL Server数据类…
[在本页中加入书签] [收藏本书] [推荐本书]
  17xie论坛 > 本书讨论区 > 本页评论   (共0条)
发表评论

用户名称 匿名发表
评论内容
验证码

关于我们 | 版权声明 | 免责声明 | 诚聘英才 | 联系我们 | 合作伙伴 | 友情链接 | 广告合作 | 提交意见
Copyright © 2007 17xie.com 互联网协同写书平台 京ICP备08002671号