本科生毕业设计（论文）外文资料译文.doc

本科生毕业设计（论文）外文资料译文（ 2012 届）论文题目基于.net的心理健康网的设计学生姓名晏丽媛学号0804011002专业计算机科学与技术班级计081班指导教师王竹萍职称副教授杭州国际服务工程学院（信息科学与工程学院）教学部制外文资料译文规范说明一、译文文本要求1外文译文不少于2000汉字；2外文译文本文格式参照论文正文规范（标题、字体、字号、图表、原文信息等）；3外文原文资料信息列文末，对应于论文正文的参考文献部分，标题用“外文原文资料信息”，内容包括：1）外文原文作者；2）书名或论文题目；3）外文原文来源：出版社或刊物名称、出版时间或刊号、译文部分所在页码网页地址二、外文原文资料（电子文本或数字化后的图片）：1外文原文不少于10000印刷字符（图表等除外）；2外文原文若是纸质的请数字化（图片）后粘贴于译文后的原文资料处，但装订时请用纸质原文复印件附于译文后。指导教师意见：外文翻译材料的内容与所选课题有一定的相关性，对设计的完成具有较好的指导意义。所译文字基本反映原文的大意，翻译和文字表达流畅。指导教师签名： 2012 年 3 月 10 日一、外文资料译文：数据访问简介关键词： 介绍ado.net是在.net框架下的代码数据库访问技术。当你开发应用程序时使用ado.net，你将对于数据的处理会有不同的要求。在某些情况下，你可能只是想要数据显示到一个表格。在其他情况下，你可能需要创造出一种方法与另一家公司共享信息。不管你怎么处理数据，你应该了解关于在 ado.net 中处理数据时一些基本概念。你可能永远也不需要知道一些数据处理的细节，例如：你可能永远也不需要直接编辑一个包含数据的xml文件但对于了解在ado.net数据体系的主要数据部件以及如何链接这些部件是非常有用的。这个简介是对这些最重要概念的高度概括，所以故意忽略了很多的细节例如，除了这里提到过外，还有更多的数据集 对只向你介绍在 ado.net中的数据集成背后的思想是比较有利的。ado.net不依赖于持续的实时链接在传统的客户端/服务器应用程序中，组件建立到数据库的链接，并保持应用程序运行时打开。由于各种各样的原因，这种做法在许多应用程序中是不切实际的。打开的数据库链接占用宝贵的系统资源。在大多数情况下，数据库只是维持一些小的并发链接。为了保持这些链接必须以降低了应用系统的整体性能为代价。同样，需要一个开放数据库链接的应用程序很难再扩大规模。不能良好扩展的应用程序可能对于四个用户可并发地执行，但很可能有数百个用户不能执行。因为一个网站的流量可以在很短时间以数量级上升，特别是asp.net web 应用程序需要易于扩展。在 asp. net web 应用程序中， 组件本身就是互相断开链接的。浏览器向服务器请求一个页面并且当服务器已完成处理并发送这个页面之后，只有当它再一次获得请求，才会进一步与浏览器链接。在这些情况下，保持打开数据库的链接并不可行，因为没有办法知道是否与数据使用者 （客户端） 需要进一步数据访问。一个基于数据链接的模型很难使用一个互联的结构将应用程序和组织边界进行数据交换。如果两个组成部分需要共享相同的数据，都必须链接，或必须设计一个部件来回传送数据方式。基于这些理由，ado.net数据访问的设计围绕着一个使用链接很少的架构。链接到数据库的应用程序只需要足够长的时间获取或更新数据。因为数据库不支持空闲链接，它可以为更多的用户服务。使用数据命令执行数据库交互在数据库中执行的操作，可以执行sql语句或存储程序（其中包括 sql 语句）。可以使用 sql 语句或存储程序来读取和写入行以及执行聚合函数如添加或平均。也可以使用 sql 语句或存储程序来创建或修改表或列，执行交易，等等。在ado.net，可以通过使用数据命令来打包一个sql语句或者存储程序。例如，如果要从数据库中读取一组记录，可以创建一个能同步或异步的数据命令，并且配置时应使用 sql select 语句的文本或读取记录的存储过程的名称。当想要获取记录时，可以执行以下操作： 打开一个链接。 反过来调用 execute 方法的命令： 执行sql 语句或存储程序中引用的命令 然后关闭链接。 链接保持打开的时间要足以执行语句或存储程序。当调用命令的执行方法，它返回一个值。更新数据库的命令返回受影响的记录数，其他类型的命令返回一个错误代码。如果用命令select 语句查询中的数据库时，该命令可以返回一组记录。可以用数据读取器读取这些记录，它充当一个非常快的只读、 只前进的游标。有关详细信息，请参阅数据检索使用 datareader。安全说明： 当使用命令类型的数据命令的属性设置为文本时，请仔细检查从客户端传递到数据库之前发送的信息。恶意用户可能会试图发送 （插入） 修改或其他未经授权的访问或损坏数据库的 sql 语句。在传输到数据库的用户输入之前，应始终验证信息是否有效；它是始终使用参数化的查询或存储程序时可能的最佳做法。有关详细信息，请参见脚本研究。如果需要执行多个操作 例如，读取某些记录，然后更新它们对于每个操作都要使用多个数据命令。每个操作分别执行。例如，若要读取的记录，要打开该链接， 读取记录，然后关闭链接。当要更新数据，再次打开该链接、 执行更新，然后再一次关闭重新的链接。数据命令可以包含允许你可以创建参数化查询的参数 （具体而言，参数对象的集合）如下所示：select * from customers where (customer_id = customerid）从所有客户中选择客户id为一定值的客户然后可以在运行时设置参数和执行时要返回或更新数据的命令。数据可以存储在数据集中从数据库中检索数据，进行数据处理，最常见的数据任务是： 显示它、 处理它，或将其发送到另一个组件。应用程序需要多次处理的不仅仅是一条记录，而是多条记录：客户或今天的命令，例如列表。通常应用程序需要的记录集都来自多个列表：我的客户及其所有命令；所有名为史密斯的作者和他们所写的书；其他与之类似的相关记录集。一旦获取了这些记录，应用程序通常与他们一起作为一个整体。例如，应用程序可能允许用户浏览所有作者名为史密斯和检索有一个史密斯写的的书，然后找到关于史密斯的下一条记录等等。在许多情况下，应用程序要处理的下一个记录需要每次都回到数据库是不切实际的。（这样做会让打开的链接数变多。）因此，另一种解决方案是暂时将从数据库检索的记录存储并设置该临时集。这就是数据集。数据集是从数据源中检索的记录缓存。它的工作方式类似虚拟数据存储区：数据集包括基于实际的数据库中的表的一个或多个，并且它可以包括关于什么样的数据表可以包含这些表和约束之间的关系的信息。数据集中的数据通常是在数据库中大幅减少的版本。但是，可以用大部分相似的方式来使用你的真实数据。虽然你这样做，你仍然从可以释放它执行其他任务的数据库断开链接。当然，经常需要更新数据库中的数据 （虽然不像你从中检索数据那样频繁）。可以对数据集执行更新操作，以及这些写入到基础数据库。重要的一点是：数据集是数据的被动容器。其实从数据库读取数据和 （选择性） 写回，你可以使用数据适配器。数据适配器包含用于填充数据集中的单个表和更新数据库中的相应表的一个或多个数据命令。(数据适配器通常包含四个命令，选择、 插入、 更新和删除数据库中的行。） 因此，数据适配器的 fill 方法可能会执行 sql 语句，如当调用该方法时，就从作者表中选择 id、lname、fname。由于数据集是一个有效的数据库中数据的私有副本，它并不一定反映数据库的当前状态。如果你想看到其他用户所做的最新变化，你可以通过调用适当的填充方法刷新数据集。使用数据集的优点之一是组件可以交换他们所需。例如，在中间层业务对象可能会创建并填充数据集，然后将其发送到另一个组件，用于处理应用程序中的其他地方。这一设施是指组件没有单独查询数据库。请参阅数据集在 ado.net 2.0和the .net framework 2.0中的新功能。数据集是独立的数据源尽管数据集作为来自数据库的数据缓存，该数据集与数据库没有任何实际的关系。数据集是一个容器 ；它包含了sql 命令或存储的过程从一个数据适配器执行程序。因为数据集不直接绑定到数据源，它是来自多个源的数据很好的结合点。例如，某些数据集中的数据可能来自数据库，而其他部分可能来自不同的数据库或非数据库源的电子表格。数据集中的一些数据可能会到达另一个组件发送的流。一旦数据放在数据集中，不管的其最初的来源是什么，都可以使用一致的对象模型来处理。数据作为 xml 保存数据需要从数据存储移动到数据集，再从数据集移动到各个组件。在ado.net中，传输数据的格式是 xml。同样地，如果数据需要被保留 （例如，到一个文件），它以xml方式。如果你有一个 xml 文件，你可以使用任何数据源一样使用它并创建它的数据集。实际上，在ado.net 中，xml 是一种基本数据格式。ado.net数据应用程序自动在数据集中创建 xml 文件或信息流，并将它们发送到另一个组件。第二个组件可以调用类似应用程序读回数据集的 xml。(数据不是以xml方式存储在数据集中 例如，使用 xml 解析器是无法解析数据集中的数据的 而是要用一种更有效的格式。)围绕xml基于数据协议提供了一系列优点 xml 是一种行业标准格式。这意味着，应用程序的数据组件可以与任何其他应用程序中的任何其他组件的数据进行交换，只要该组件了解 xml。许多应用程序证逐步”xml”化，这达到了不同的应用程序之间数据交换的前所未有的水平。 xml 是基于文本的。数据的xml表示形式不使用任何二进制信息，这样它就可以通过任何的协议如http传送。大多数防火墙阻止二进制信息，但通过在 xml 中格式设置信息，组件可以仍然很容易交换信息。 对于大多数情况，不需要为了使用ado.net中的数据来了解xml。ado.net可以根据需要自动将数据和xml进行转换；可以和用普通编程方法的数据进行交互。简单定义数据结构虽然你不需要知道关于 xml 读取和写入数据库和使用数据集，但是之后有些情况下使用 xml 是最明确的目标。这些情况下，都不能访问数据，但相反，可以使用数据的设计。换而言之，在 ado.net中，当你正在使用元数据，你可以直接使用 xml。数据集用xml表示。数据集的结构 在数据集中表、列、数据类型、约束和等等的定义 是使用基于 xml 架构定义语言 (xsd) 的 xml 架构定义。就像一个数据集所包含的数据可以从加载和作为 xml序列化，该数据集的结构可以被加载和作为 xml 架构序列化。对于处理大多数的使用 ado.net 中的数据，你不必深入架构。通常情况下，基于你在可视化设计器，visual studio 工具将生成和更新架构需要。例如，当你使用工具来创建一个数据集，表示数据库表中的，visual studio 会生成 xml 架构描述的数据集的结构。然后，xml 架构用于生成类型化的数据集，在哪些数据元素 （如表、 列，等等） 可作为一流的成员。有关类型化的数据集的详细信息，请参见数据集介绍。然而，当要多次创建或编辑自己的架构。一个典型的例子发展结合的合作伙伴或客户端中的架构。在这种情况下，模式可以作为你与合作伙伴对于你将交换的基于 xml 的数据的形状之间的合同。在这种情况下，你经常要将架构元素映射到你自己的数据库的结构中。有关设计架构的详细信息，请参阅 ado.net2.0 中的架构。ado.net与 sql server 2005之间的关系？虽然 ado.net可以通过数据提供程序模型访问许多不同类型的数据源，sql server 2005 和.net框架是高度集成在一起的，支持使用最喜爱的网络编程语言来创建存储的过程、 函数、 用户定义的类型和用户定义的聚合函数。所有的这些构造可以利用.net 框架的大部分基础设施、 基类库和第三方托管的库。集成的 ado.net和 sql 服务器的详细信息，请参阅管理 sql server 数据内的ado.net 和sqlclr。 基于ado.net 2.0使用sql server 2005，还为开发人员提供 sqlclient 的数据提供程序和数据库调用查询通知中内置的信号解决方案。查询通知创建了一个简单的解决方案，即点对点数据刷新和缓存。如何了解更多有关 ado.net?数据是大多数应用程序的核心。msdn 提供了大量的资源，以帮助这一关键任务和了解更多有关 ado.net。数据访问开发人员中心会集中研究所有类型的数据访问方法。sql 服务器开发人员中心将为你提供的所有对 sql server 2000 和 2005的最新信息。也可以从sql server 2005学习中心获取 sql server 2005的简介或更多的学习选择。关于特定主题详细和深入的信息，请访问其他主题的完整列表中数据参考一节。外文原文资料信息1 外文原文作者：microsoft2 外文原文所在书名或论文题目：visual studio 20053 外文原文来源：出版社或刊物名称、出版时间或刊号、译文部分所在页码：team edition for software developers with msdn pretinum subscriptions， p1-7网页地址：二、外文原文资料：introduction to data accessintroductionthe code data access technology in the .net framework is ado.net. as you develop applications using ado.net， you will have different requirements for working with data. in some cases， you might simply want to display data on a form. in other cases， you might need to devise a way to share information with another company.no matter what you do with data， there are certain fundamental concepts that you should understand about the data approach in ado.net. you might never need to know some of the details of data handling for example， you might never need to directly edit an xml file containing data but it is very useful to understand the data architecture in ado.net， what the major data components are， and how the pieces fit together.this introduction presents a high-level overview of these most important concepts. the topic deliberately skips over many details for example， there is much more to datasets than what is mentioned here in favor of simply introducing you to ideas behind data integration in ado.net.ado.net does not depend on continuously live connectionsin traditional client/server applications， components establish a connection to a database and keep it open while the application is running. for a variety of reasons， this approach is impractical in many applications.open database connections take up valuable system resources. in most cases， databases can maintain only a small number of concurrent connections. the overhead of maintaining these connections detracts from overall application performance.similarly， applications that require an open database connection are extremely difficult to scale up. an application that does not scale up well might perform acceptably with four users but will likely not do so with hundreds. asp.net web applications in particular need to be easily scalable， because traffic to a web site can go up by orders of magnitude in a very short period.in asp.net web applications， the components are inherently disconnected from each other. the browser requests a page from the server; when the server has finished processing and sending the page， it has no further connection with the browser until the next request. under these circumstances， maintaining open connections to a database is not viable， because there is no way to know whether the data consumer (the client) requires further data access.a model based on always-connected data can make it difficult and impractical to exchange data across application and organizational boundaries using a connected architecture. if two components need to share the same data， both have to be connected， or a way must be devised for the components to pass data back and forth.for all these reasons， data access with ado.net is designed around an architecture that uses connections sparingly. applications are connected to the database only long enough to fetch or update the data. because the database is not holding on to connections that are largely idle， it can service many more users.database interactions are performed using data commandsto perform operations in a database， you execute sql statements or stored procedures (which include sql statements). you use sql statements or stored procedures to read and write rows and perform aggregate functions， such as adding or averaging. you also use sql statements or stored procedures to create or modify tables or columns， to perform transactions， and so on.in ado.net， you use data commands to package a sql statement or stored procedure. for example， if you want to read a set of rows from the database， you create a data command， which can be either synchronous or asynchronous， and configure it with the text of a sql select statement or the name of a stored procedure that fetches records.when you want to get the rows， you do the following: open a connection. call an execute method of the command， which in turn: executes the sql statement or stored procedure referenced by the command. then closes the connection. the connection stays open only long enough to execute the statement or stored procedure. when you call a commands execute method， it returns a value. commands that update the database return the number of rows affected; other types of commands return an error code. if the command queries the database with a select statement， the command can return a set of rows. you can fetch these rows using a data reader， which acts as a very fast read-only， forward-only cursor. for more information， see retrieving data using the datareader.security note: when using data commands with a commandtype property set to text， carefully check information that is sent from a client before passing it to your database. malicious users might try to send (inject) modified or additional sql statements in an effort to gain unauthorized access or damage the database. before you transfer user input to a database， you should always verify that the information is valid; it is a best practice to always use parameterized queries or stored procedures when possible. for more information， see scripting exploits.if you need to perform more than one operation for example， read some rows and then update them you use multiple data commands， one for each operation. each operation is performed separately. for example， to read the rows， you open the connection， read the rows， and then close the connection. when you want to update data， you again open the connection， perform the update， and then close the connection again.data commands can include parameters (specifically， a collection of parameter objects) that allow you to create parameterized queries such as the following:select * from customers where (customer_id = customerid)you can then set the parameters at run time and execute the command to return or update the data you want.data can be cached in datasetsthe most common data task is to retrieve data from the database and do something with it: display it， process it， or send it to another component. very frequently， the application needs to process not just one record， but a set of them: a list of customers or todays orders， for example. often the set of records that the application requires comes from more than one table: my customers and all their orders; all authors named smith and the books they have written; and other， similar， sets of related records.once these records are fetched， the application typically works with them as a group. for example， the application might allow the user to browse through all the authors named smith and examine the books for one smith， then move to the next smith， and so on.in many cases， it is impractical to go back to the database each time the application needs to process the next record. (doing so can undo much of the advantage of minimizing the need for open connections.) a solution， therefore， is to temporarily store the records retrieved from the database and work with this temporary set.this is what a dataset is. a dataset is a cache of records retrieved from a data source. it works like a virtual data store: a dataset includes one or more tables based on the tables in the actual database， and it can include information about the relationships between those tables and constraints on what data the tables can contain.the data in the dataset is usually a much-reduced version of what is in the database. however， you can work with it in much the same way you do the real data. while you are doing so， you remain disconnected from the database， which frees it to perform other tasks.of course， you often need to update data in the database (although not nearly as often as you retrieve data from it). you can perform update operations on the dataset， and these can be written through to the underlying database. an important point is that the dataset is a passive container for the data. to actually fetch data from the database and (optionally) write it back， you use data adapters. a data adapter contains one or more data commands used to populate a single table in the dataset and update the corresponding table in the database. (a data adapter typically contains four commands， one each to select， insert， update， and delete rows in the database.) therefore， a data adapters fill method might execute a sql statement such as select au_id， au_lname， au_fname from authors whenever the method is called.because a dataset is effectively a private copy of the database data， it does not necessarily reflect the current state of the database. if you want to see the latest changes made by other users， you can refresh the dataset by calling the appropriate fill method.one of the advantages of using datasets is that components can exchange them as required. for example， a business object in the middle tier might create and populate a dataset， then send it to another component elsewhere in the application for processing. this facility means that components do not have to individually query the database.see whats new in datasets in ado.net 2.0 and the .net framework 2.0.datasets are independent of data sourcesalthough a dataset acts as a cache for data drawn from a database， the dataset has no actual relationship with the database. the dataset is a container; it is filled by sql commands or stored procedures executed from a data adapter.because a dataset is not directly tied to a data source， it is a good integration point for data coming from multiple sources. for example， some of the data in a dataset might come from your database， whereas other parts of it might come from a different database or a non-database source such as a spreadsheet. some of the data in a dataset might arrive in a stream sent by another component. once the data is in a dataset， you can work with it using a consistent object model， regardless of its original source.data is persisted as xmldata needs to be moved from the data store to the dataset， and from there to various components. in ado.net the format for transferring data is xml. similarly， if data needs to be persisted (for example， into a file)， it is stored as xml. if you have an xml file， you can use it like any data source and create a dataset out of it.in fact， in ado.net， xml is a fundamental format for data. the ado.net data apis automatically create xml files or streams out of information in the dataset and send them to another component. the second component can invoke similar apis to read the xml back into a dataset. (the data is not stored in the dataset as xml for example， you cannot parse data in a dataset using an xml parser but instead in a more efficient format.)basing data protocols around xml offers a number of advantages: xml is an industry-standard format. this means that your applications data components can exchange data with any other component in any other application， as long as that component understands xml. many applications are being written to understand xml， which provides an unprecedented level of exchange between disparate applications. xml is text-based. the xml representation of data uses no binary information， which allows it to be sent via any protocol， such as http. most firewalls block binary information， but by formatting information in xml， components can still easily exchange the information. for most scenarios， you do not need to know xml in order to use data in ado.net. ado.net automatically converts data into and out of xml as needed; you interact with the data using ordinary programming methods.schemas define data structuresalthough you do not need to know anything about xml to read and write to the database and work with datasets， there are situations in which working with xml is precisely the goal you are after. these are situations in which you are not accessing data， but instead， working with the design of data. to put it another way， in ado.net you use xml directly when you are working with metadata. datasets are represented as xml. the structure of the dataset the