Tài liệu Module 8: The Nontransactional Data Access Layer doc

Contents
Overview 1
Introduction to the Data Access Layer 2
Nontransactional DAL Technologies 5
Demonstration: ADSI 22
Logical Design of Nontransactional DAL 24
Physical Design of Nontransactional DAL 28
Market Purchasing 46
Best Practices 49
Lab 8: Nontransactional DAL 50
Review 54

Module 8: The
Nontransactional Data
Access Layer

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveX, BackOffice, BizTalk, FrontPage, Microsoft Press, MSDN,
MS-DOS, PowerPoint, Visio, Visual Basic, Visual C++, Visual InterDev, Visual J++, Visual
Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the U.S.A. and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Program Managers: Rhy Mednick, Susie Parrent
Instructional Designer: Susie Parrent
Subject Matter Experts: David Chesnut, Sam Gill (TechnoWiz), Michel Pahud
Media Management: David Mahlmann
Editing Manager: Lynette Skinner
Editor: Mick Alberts, Jennifer Linn
Production Manager: Miracle Davis
Print Coordinators: Linda Lu Cannon (Write Stuff), Marlene Lambert (Online Training
Solutions, Inc.)
Build Coordinator: Eric Wagoner
Graphic Artist: Scott Serna
Test Lead: Eric Myers
Manufacturing Manager: John Williams
Group Product Manager: Juan Fernando Rivera

Lead Product Manager, System Services and Infrastructure: Edward Dudenhoefer
Manufacturing Manager: Rick Terek
Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Group Manager, Courseware Infrastructure: David Bramble
General Manager: Robert Stewart
Module 8: The Nontransactional Data Access Layer iii


Instructor Notes
This module provides students with a presentation on the nontransactional data
access layer (DAL). Module 8 is the first of two modules that focus on the
DAL: Module 8, “The Nontransactional Data Access Layer” and Module 9,
“The Transactional Data Access Layer.” The DAL is an application’s means of
access to data services.
After completing this module, students will be able to:
!
Describe the differences between the two types of DALs: transactional and
nontransactional.
!
Describe the logical and physical designs of a nontransactional DAL and
how to apply behavioral design patterns.
!
Describe the data access technologies provided by Microsoft
®
Data Access
Connectivity (MDAC).
!
Describe the cursor engine and how to create the physical design for data

caching by using the cursor engine.
!
Implement the logical and physical designs for a nontransactional DAL
object.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1910A_08.ppt
!
Module 8: The Nontransactional Data Access Layer
!
Lab 8: The Nontransactional DAL

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.

Presentation:
75 Minutes

Lab:

30 Minutes
iv Module 8: The Nontransactional Data Access Layer


Demonstration
This section provides demonstration procedures that will not fit in the margin
notes or are not appropriate for the student notes.
ADSI
!
To prepare for the demonstration
• Review the instructions in the student notes.

Module 8: The Nontransactional Data Access Layer v


Module Strategy
Use the following strategy to present this module:
!
Introduction to the Data Access Layer
The purpose of this section is to introduce students to the DAL and its main
purpose, which is to buffer all other layers from the data services layer. The
section also emphasizes the need to split the DAL into nontransactional and
transactional layers to define the proper boundaries for COM+ applications
and their attributes.
In the topic “Splitting the DAL,” emphasize that the key functions for the
nontransactional DAL are to receive requests from the business or Web
services facade layer or business logic layer, to process the requests and
pass the requests to data services, to retrieve the results from data services,
and to pass the results of the processing back to the facade layer or business
logic layer.

!
Nontransactional DAL TechnologiesThe purpose of this section is to
introduce students to the technologies that can be used in the physical
design of the DAL. This is a long list of technologies that can be used by
both nontransactional and transactional DALs.
In the topic “Microsoft Data Access Components (MDAC)” emphasize the
history of MDAC and how the Microsoft Universal Data Access (UDA)
strategy has evolved over the past decade.
In the topic “ADO,” emphasize that ActiveX
®
Data Objects (ADO) have
replaced Data Access Objects (DAO) and Remote Data Objects (RDO) as
the standard for writing data-aware applications.
In the topic “Cursor Service,” emphasize that this is a service provided by
OLE DB and that the Cursor Service can be installed on each tier of a
multitier application to provide an effective solution for scalability.
In the topic “Active Directory Service Interfaces (ADSI),” emphasize that
this is recommended as the primary mechanism for creating and changing
objects and schemas within the Active Directory
™
services.
!
Logical Design of Nontransactional DALThe purpose of this section is to
identify the two design patterns that might be useful in the logical design of
nontransactional DAL: Iterator and Composite.
!
Physical Design of Nontransactional DALThe purpose of this section is to
show how DAL technologies can be applied to the nontransactional DAL.
!
Market Purchasing

The purpose of this section is to discuss the logical and physical designs of
nontransactional DAL in Market Purchasing and to explain the justification
for the choices made. The logical design incorporates an Iterator while the
physical design uses cursors and ADO for database access.
vi Module 8: The Nontransactional Data Access Layer


By using Component Services, you can present the Market Purchasing DAL
COM+ application. Explain that both the nontransactional and transactional
DAL components are registered in the same COM+ application because all
of the data is physically on one computer. You may also consider presenting
the source code of one of the nontransactional DAL components. Don’t
show the source code of the mpdalnt.Requestor class, since that will give
away the answers to the lab.
!
Best Practices
The best practices focus on using an Iterator as a design pattern for a class
rather than having a separate collection class for each business entity. The
physical design best practices focus on the efficient use of cursors: client vs.
server side.

Lab Strategy
!
Lab 8: The Nontransactional DAL
The purpose of Lab 8 is for students to learn how to design the
nontransactional DAL. Students probably will not derive answers that
correspond exactly to the Market Purchasing design. This is acceptable as
long as the student answers are justified and reflect the principles discussed
in the module. Discuss with students their answers to Lab 8.

Module 8: The Nontransactional Data Access Layer 1


#
##
#

Overview
!
Introduction to the Data Access Layer
!
Nontransactional DAL Technologies
!
Logical Design of Nontransactional DAL
!
Physical Design of Nontransactional DAL
!
Market Purchasing
!
Best Practices


Module 8 is the first of two modules that focus on the data access layer (DAL):
Module 8, “The Nontransactional Data Access Layer” and Module 9, “The
Transactional Data Access Layer.” The DAL is an application's access to data
services.
After completing this module, you will be able to:
!
Describe the differences between the two types of DALs: transactional and
nontransactional.

!
Describe the logical and physical designs of a nontransactional DAL and
how to use behavioral design patterns.
!
Describe the data access technologies provided by Microsoft
®
Data Access
Connectivity (MDAC).
!
Describe the cursor engine and how to create the physical design for data
caching using the cursor engine.
!
Implement the logical and physical designs for a nontransactional DAL
object.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the nontransactional
data access layer and how
to create a logical design
and a physical design for it.
2 Module 8: The Nontransactional Data Access Layer


#
##

#

Introduction to the Data Access Layer
!
The Business Problem
!
Splitting the DAL


The DAL buffers the entire system from the underlying data services. All
access to data services for creating, updating, or deleting is accomplished
through the DAL.
In this section, the DAL is introduced and discussed in the context of the
business problem for accessing data services. You will also learn about the
technologies necessary to implement the nontransactional DAL. Many of these
technologies are also used for the transactional DAL, which is discussed in
Module 9, “The Transactional Data Access Layer.”
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
about what makes up a
nontransactional DAL.
Module 8: The Nontransactional Data Access Layer 3


The Business Problem
Data Access Layer

Connected Business
Logic Layer
Disconnected Business
Logic Layer
Facade Layer
Web Services Facade Business Facade
Transactional DAL
Nontransactional DAL
User Services
Data
Services


The data services store and manage all of the data used by the system. Access to
the data services requires detailed knowledge of where and how the data is
stored. For example, an order entry system might store orders in several tables
in a Microsoft
®
SQL Server
™
database. To create a new order, a system must
know the name of the computer running SQL Server, the name of the database,
and the names of the tables in which the orders are stored.
If the business logic or facades were to access the data services directly, they
would have to be programmed and compiled with much of this information in
the components. Changes to the data services, such as changing the computer
name, database name, or table structures, would require changes in the business
logic and facades.
A DAL isolates the rest of the system from changes in the data services. Using
the DAL, the business logic or facades only pass or request the data they need,

without any dependency on where or how that data is stored. The DAL is
programmed with the information necessary to locate data servers and update
the data. Therefore changes to the data services will require only the DAL to be
recompiled, not any components in the business logic or facades.
A subtle but important detail in this architecture is that the business and Web
services facades can access the DAL directly. If the facades need to retrieve or
update data in a manner that does not require business logic to be involved,
there is no need to go through the business logic layer. The facades simply
access whatever components they need in the DAL to accomplish their goals.
Topic Objective
To provide background
about the business problem.
Lead-in
In this topic, you will learn
about the business problem
facing designers who need
to implement a DAL.
4 Module 8: The Nontransactional Data Access Layer


Splitting the DAL
!
Nontransactional only applies to retrieving data.
!
Transactional only applies to creating, updating, and
deleting data.
!
COM+ declares transactions at a class level.
!
Split entity classes into transactional and

nontransactional classes.


The DAL is split into two separate parts. One part, called the nontransactional
DAL, only exposes functionality to retrieve data. The other part, called the
transactional DAL, exposes functionality to create, update, and delete data. The
DAL is split into two parts because transactions take a lot of overhead. When a
COM+ class declares that it requires transactions, the Microsoft Distributed
Transaction Coordinator (MS DTC) must create and manage the transactions.
This overhead is not necessary when only retrieving data, so the methods
dealing with data retrieval are put in the nontransactional DAL.
This is an important distinction because most classes you derive in your logical
design will combine transactional and nontransactional methods. For example,
a customers table in the database should have a Customers class that exposes
methods such as GetCustomer, CreateCustomer, and UpdateCustomer.
GetCustomer is a nontransactional method because it does not change the
table. However, CreateCustomer and UpdateCustomer require a transaction
to update the database.
COM+ declares transactions at a class level. Either the entire class requires
transactions, or the entire class does not support transactions. Therefore the
GetCustomer method is split off into another class, which only has methods
that retrieve data.
In your logical design, you should already have this architecture in mind while
creating classes for the DAL.
The following are the key functions for the nontransactional DAL:
!
Receive requests from the business or Web services facade layer or business
logic.
!
Process the requests and pass them to data services.

!
Retrieve the results from data services.
!
Pass the results of the processing back to the facade layer or business logic.

Topic Objective
To discuss the advantage of
splitting off certain pieces of
the DAL into transactional
and nontransactional
components.
Lead-in
In this topic, you will learn
about the reasons for
splitting the DAL into two
separate parts.
Module 8: The Nontransactional Data Access Layer 5


#
##
#

Nontransactional DAL Technologies
!
Microsoft Data Access Components
!
OLE DB
!
ActiveX Data Objects

!
Record
!
Stream
!
Cursor Service
!
Data Shaping Service
!
Issues and Challenges of Data Exchange
!
XML Solution
!
Active Directory Service Interfaces


The design of components for the nontransactional DAL is based on data access
technologies for accessing hierarchical as well as non-hierarchical data. In this
section, the following data access technology topics will be covered in detail:
!
Microsoft Data Access Components (MDAC)
!
OLE DB
!
ActiveX
™
Data Objects (ADO)
!
Record
!

Stream
!
Cursor Service
!
Data Shaping Service
!
Extensible Markup Language (XML) solution
!
Active Directory
™
Service Interfaces (ADSI)

Topic Objective
To provide background
about the technologies for
implementing
nontransactional DAL.
Lead-in
In this topic, you will learn
about the technologies for
implementing
nontransactional DAL.
6 Module 8: The Nontransactional Data Access Layer


Microsoft Data Access Components
Other Data
Sources
Other Data
Sources

Relational
Databases
Relational
Databases
Data
Object
Interfaces
Data
Object
Interfaces
Application
Programming
Interfaces
Application
Programming
Interfaces
ADO RDO
ODBCOLE DB


Microsoft Data Access Components (MDAC) version 2.5, which is integrated
into Microsoft Windows
®
2000, provides the key technologies that enable
Universal Data Access (UDA). UDA is a definition of Microsoft's strategy for
providing access to information across the enterprise.
MDAC includes ADO, OLE DB, and Open Database Connectivity (ODBC).
The MDAC technology can be used in the physical design of nontransactional
DAL components to easily integrate information from a variety of sources, both
relational (SQL) and non-relational.

History of MDAC
The Microsoft Universal Data Access (UDA) strategy has evolved during the
past decade. It began with Data Access Objects (DAO), an object wrapper that
interacted with the Jet engine (a query service), and connected to data sources
through ODBC. DAO was designed to interact with Microsoft Access
databases. DAO, however, had serious shortcomings, particularly in
performance when it was used with large databases such as SQL Server. This is
because it used the Jet engine as its query engine. To overcome the shortcoming
of DAO, Microsoft introduced Remote Data Objects (RDO). RDO interacted
directly with ODBC drivers. RDO was an improvement over DAO, but it was
limited to relational database sources.
To facilitate performance and the ability to interact with different types of data
sources, Microsoft introduced OLE DB. OLE DB allows development of
provider applications and consumer applications that facilitate data transfer and
manipulation with different data sources.
To avoid needing to immediately create a large number of OLE DB providers
for different data sources, Microsoft introduced an OLE DB generic provider
that can communicate with ODBC drivers.
Topic Objective
To provide a review of
MDAC and the chronology
of its development.
Lead-in
In this topic, you will learn
about the MDAC
technology.
Module 8: The Nontransactional Data Access Layer 7


This brings us to MDAC. MDAC is a packaging of OLE DB, ADO, and

ODBC. MDAC provides universal access to many different data sources by
using a universal mechanism. Microsoft has introduced extensions to both OLE
DB and ADO for specific data sources, such as ActiveX Data Objects
Multidimensional (ADO MD), which provides access to multidimensional data
generated by Microsoft Analysis Services.
For more information on MDAC, see the Microsoft Universal Data Access Web
site at
8 Module 8: The Nontransactional Data Access Layer


OLE DB
!
Consumers
!
Providers
$
Data providers
$
Service providers
SQL
Server
SQL
Server
ADO
Consumer
SQL Server
OLE DB
Provider
Data Shaping
Service

Microsoft OLE DB defines a set of interfaces that can expose data from a
variety of relational and nonrelational sources by using the Component Object
Model (COM). OLE DB components consist of data providers, which contain
and expose data; data consumers, which use data; and service components,
which process and transport data (such as query processors and Cursor
Engines). In addition, OLE DB includes a bridge to ODBC to enable continued
support for the broad range of ODBC relational database drivers.
OLE DB makes it easy for applications to access data stored in relational and
nonrelational data sources. OLE DB applications can be classified broadly into
two categories: consumers and providers.
Consumers
A consumer is any application code that consumes an OLE DB interface. An
example of a consumer is a Visual Basic
®
application that accesses an Access
database. In our Enterprise Architecture, the consumer would be the DAL.
Providers
There are two types of OLE DB providers: data providers and service providers.
!
Data providers
A data provider is any component that owns data. It exposes its data in a
tabular format, regardless of the format in which it stores data. Examples of
data providers are relational database management systems (DBMS),
spreadsheets, Indexed Sequential Access Method (ISAM) files, and e-mail.
Topic Objective
To provide a review of OLE
DB.
Lead-in

In this topic, you will learn
about the architecture of
OLE DB.
Module 8: The Nontransactional Data Access Layer 9


!
Service providers
A service provider, in general, does not have its own data, but facilitates
data access between a data provider and a consumer. Examples of service
providers are query processors and Cursor Engines. Service providers act
both as consumers and providers. As a consumer, a service provider
retrieves data from the underlying data provider. As a provider, it creates a
rowset from the retrieved data and returns it to the consumer.
OLE DB functionality is exposed through more than 50 different interfaces.
Relatively few of these interfaces are mandatory. Since most interfaces are
optional, this allows a provider to implement only the functionality it needs.
Thus, OLE DB allows providers to better match and expose information
functionality.
Defining new interfaces can extend the OLE DB functionality. This allows
providers to expose custom functionality that cannot be exposed through
ODBC. For example, Microsoft Analysis Services for SQL Server has an
OLE DB MD provider.
10 Module 8: The Nontransactional Data Access Layer


ActiveX Data Objects
!
ADO Object Model
!

ADO Programming
!
Remote Data Service


ADO provides an object model and an associated programming model that
defines the sequence of activities necessary to gain access to and update a data
source. The programming model summarizes the entire functionality of ADO.
The objects in ADO expose methods, which perform some operation on data
and properties, which either represent some attribute of the data or control the
behavior of some object method.
ADO Object Model
ADO uses OLE DB to access and work with data. The object model is an
abstraction of OLE DB, which makes it easier to work through OLE DB. The
object model consists of three primary objects: Connection, Recordset, and
Command.
The Connection object represents a live connection to the data source. The
Connection object is used to execute commands and retrieve data from the data
source.
The Recordset object represents a collection of records retrieved from the data
source. The Recordset object is used to traverse the records and insert, update,
or delete those records. The Recordset object can be used in conjunction with a
Connection object, or it can be used separately, in which case it creates an
internal Connection object to access the data source.
The Command object is used to execute commands against the data source. It
can be used to specify parameters and the type of command, such as SQL text,
stored procedure name, or just a table name, to retrieve. The Command object
can be used in conjunction with a Connection object, or it can be used
separately, in which case it creates an internal Connection object to access the
data source.

Topic Objective
To provide an overview of
ADO.
Lead-in
In this topic, you will learn
about the architecture of
ADO.
Module 8: The Nontransactional Data Access Layer 11


ADO Programming
ADO provides the means for an application to perform the following sequence
of actions:
1. Connect to a data source.
2. Specify a command to gain access to the data source.
3. Execute the command.
4. If the command causes data to be returned in the form of rows in a table,
store the rows in a cache that you can easily examine, manipulate, or
change.
5. If appropriate, update the data source with changes from the cache of rows.
6. Provide a general means to detect errors (usually as a result of making a
connection or executing a command).

Remote Data Service
In addition, ADO provides an interface, Remote Data Services (RDS), which
allows you to gain access to a data source through an intermediary, such as
Internet Information Services (IIS).
RDS provides the means for a remote application to perform the following
sequence of actions:
1. Specify the program to be invoked on the server, and obtain a way to refer

to it from the client.
2. Invoke the server program. Pass parameters to the server program that
identify the data source and the command to issue.
3. The server program obtains a Recordset object from the data source.
4. The server program returns the final Recordset object to the client
application.
5. On the client, the Recordset object is processed.
6. Any modifications to the Recordset object on the client are sent back to the
server program, which uses them to update the data source.

12 Module 8: The Nontransactional Data Access Layer


Record
!
Represents an Individual Row of a Recordset, or a
Resource (Such As a File or Directory) in a File System
!
Used to Access Hierarchical Data in a Web Site


The Record object in ADO represents a row in a recordset, or a file or directory
in a file system. The Record object is ideal for working with hierarchical data.
The Record object can model tree-structured namespaces. Each node in the tree
is represented by a Record object with associated columns. The columns
represent the attributes of that node and other relevant information. The Record
object can represent both a leaf node and a nonleaf node in the tree structure.
Nonleaf nodes have other nodes as their contents while leaf nodes do not have
such contents. Leaf nodes typically contain binary streams of data while nonleaf
nodes might also have a default binary stream associated with them. Properties

on the Record object identify the type of node.
The Record object also represents an alternative way for navigating
hierarchically organized data. A Record object may be created to represent the
root of a specific sub-tree in a large tree structure, and new Record objects may
be opened to represent child nodes.
A file or directory (that is, a resource) is uniquely identified by an absolute
Uniform Resource Locator (URL). A Connection object is implicitly created
and set to the Record object when the record is opened with an absolute URL.
A Connection object may explicitly be set to the Record object by using the
ActiveConnection property. The files and directories accessible using the
Connection object define the context in which record operations can occur.
Data modification and navigation methods on the Record object also accept a
relative URL, which locates a resource using an absolute URL or the
Connection object context as a starting point.
Topic Objective
To provide an overview of
the Record object.
Lead-in
In this topic, you will learn
about one of the new
objects available in ADO:
Record.
Module 8: The Nontransactional Data Access Layer 13


Stream
!
Represents a Stream of Binary Data or Text
!
Used with the Record Object to Access the

Contents of a File


An ADO Stream object represents a stream of “bits,” binary data or text. In a
tree-structured hierarchy such as a file system or an e-mail system, an ADO
Record object may consist of a binary stream of bits that make up the contents
of the record. A Stream object can be used to manipulate fields or records
containing these streams of data.
A Stream object can be created in one of three ways:
!
From a URL pointing to an object (typically a file) containing binary or text
data. This object can be a simple document, a Record object representing a
structured document, or a folder.
!
By opening the default Stream object associated with a Record object. You
can obtain the default stream associated with a Record object when the
record is opened.
!
By explicitly creating an instance of a Stream object. These Stream objects
can be used to store data for the purposes of your application. Unlike a
stream associated with a URL, or the default stream of a record, an
instantiated stream has no association with an underlying source.

Topic Objective
To provide an overview of
the Stream object.
Lead-in
In this topic, you will learn
about another one of the
new objects available in

ADO: Stream.
14 Module 8: The Nontransactional Data Access Layer


Cursor Service
!
Provided by OLE DB
!
Supports Working with a Rowset
Independently of the Database
!
ADO Exposes a Cursor Service Through a
Disconnected Recordset


OLE DB includes a Cursor Service that provides a client-tier and middle-tier
cache for data sets and implements smart synchronization functions. Using the
Cursor Service can dramatically reduce network traffic while giving you full
control over data synchronization. The Cursor Service can be installed on each
tier of a multitier application, providing an effective solution for scalability.
ADO exposes the Cursor Service through the Recordset object as a client-side
cursor. This is the easiest way to program for the Cursor Service.

Topic Objective
To present features of the
OLE DB Cursor Service.
Lead-in
In this topic, you will learn
about the OLE DB Cursor
Service.

Module 8: The Nontransactional Data Access Layer 15


Data Shaping Service
!
Relation-based Hierarchical Rowsets
!
Group-based Hierarchies
!
Using Data Shaping
!
Sample Definition


OLE DB provides a Data Shaping Service that allows the creation of rowset
hierarchies. Data Shaping allows an application to create relationships that had
not previously existed between keys, fields, or rowsets. The Data Shaping
Service supports the Shape language, which allows you to define rowset
hierarchies built from rowset data obtained from a data provider.
Relation-based Hierarchical Rowsets
The OLE DB Data Shaping Service allows you to create a relationship between
two rowsets retrieved from parent and child tables that have at least one field in
common. In the illustration in the preceding slide, the Order table is related to
the Order Detail table through the cust_id field. To set up this type of
relationship, you can use the SHAPE command with a RELATE clause that
identifies the fields that match.
Group-based Hierarchies
The Data Shaping Service for OLE DB can also be used to create a group-based
hierarchy from a single rowset. The BY clause in the SHAPE command is used
to partition a rowset. A parent rowset is constructed in which there is one row

for each partition in the child rowset.
Topic Objective
To provide an overview of
the Data Shaping OLE DB
provider and the Shape
language.
Lead-in
In this topic, you will learn
about the architecture of
Data Shaping and the
Shape language syntax.
16 Module 8: The Nontransactional Data Access Layer


Using Data Shaping
Creating a hierarchy is a two-step process that requires connection to the Data
Shaping Provider and then uses the SHAPE command.
You can also use the Data Shaping provider from ADO. When you use Data
Shaping from ADO, you must setup an explicit connection to the OLE DB
provider, as shown in the following example:
Provider=MSDataShape; data provider=MSDASQL; Driver={SQL
Server};Server=xxx; Database=yyy; UID=zzz; PWD=;

You can also create an empty hierarchical rowset that can later be populated
with data or reshaped. In this case, it is not necessary to connect to a data
provider, as shown in the following example:
Provider=MSDataShape; data provider=NONE

Module 8: The Nontransactional Data Access Layer 17

Sample Definition
The Data Shaping Service for OLE DB can also be used to sum up a
hierarchical structure to produce totals at different levels. In the case of the
illustration in the slide, the following syntax would be used for the SHAPE
command:
SHAPE {select customer.*, orders.order_id, orders.order_amt
from customers, orders where customer.cust_id =
orders.cust_id}
AS rsDetail
COMPUTE rsDetail, SUM(rsDetail.order_amt)
AS order_amt
COUNT(rsDetail)
AS DetailCount
BY cust_id

18 Module 8: The Nontransactional Data Access Layer


Issues and Challenges of Data Exchange
!
Structural Representation of Data
!
Extensibility
!
Data Is Separated from Presentation and Process


Business applications rarely exist in a void or are completely self-contained.
Frequently, a business application needs to interact with other business

applications to complete a particular business scenario. For example, after a
requestor submits a requisition, the requisition must be forwarded to a vendor
for fulfillment. The transfer of data to other systems can be done on an
individual basis, and each time such a need arises a new data transfer protocol
can be defined.
Over time, it became apparent that a structural representation of data needed to
be defined so that the data, together with its schema, can be passed to another
application that would be able to retrieve and use data based on the schema
provided.
In addition, it is important that the standard for data exchange should be
extensible. Since application needs change, it is necessary to be able to extend
the schema for the data exchange to accommodate new requirements.
Finally, the actual data being exchanged should be separated from how it
should be represented and the process that will facilitate its use.
Topic Objective
To discuss issues related to
data exchange.
Lead-in
In this topic, you will learn
about issues related to data
exchange.
Module 8: The Nontransactional Data Access Layer 19


XML Solution
!
XML
!
DTD
!

DOM
!
Schema


XML is an ideal solution for the issues and challenges of data exchange. The
XML solution consists of several key components.
XML
XML is a meta-markup language that provides a format for describing
structured data. This facilitates more precise declarations of content and
exchange of data between applications. XML is extensible; it allows you to
define an unlimited set of tags. The power and beauty of XML is that it
maintains the separation of the user interface from the structured data.
Hypertext Markup Language (HTML) specifies how to display data in a
browser; XML defines the content. In HTML you use tags to tell the browser to
display data as bold or italic; with XML you only use tags to describe data, such
as city name, temperature, and barometric pressure. In XML, you use style
sheets such as Extensible Style Language (XSL) and Cascading Style Sheets
(CSS) to present the data in a browser. XML separates the data from the
presentation and the process, enabling you to display and process the data as
you wish by applying different style sheets and applications.
DTD
With XML, Document Type Definitions (DTDs) can accompany a document,
essentially defining the rules of the document, such as which elements are
present and the structural relationship between the elements. DTDs help to
validate the data when the receiving application does not have a built-in
description of the incoming data.
DOM
With the XML Document Object Model (DOM), you can load and parse XML
files, gather information about those files, and navigate and manipulate those

files.
Topic Objective
To discuss how XML can
provide a solution to data
exchange issues.
Lead-in
In this topic, you will learn
about XML as a solution for
the challenges of data
exchange.