Tài liệu Module 10: Data Services ppt

Contents
Overview 1
Introduction to Data Services 2
SQL Server 5
Active Directory 12
Demonstration: Active Directory 16
Logical Design of Data Services 22
Physical Design of Data Services 23
Market Purchasing 27
Best Practices 30
Lab 10: Data Services 31
Review 35

Module 10: Data
Services

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 10: Data Services iii


Instructor Notes
This module provides students with an introduction to data services. Every
enterprise application needs to save data in a data store. In this module, two
types of data stores are considered: relational and hierarchical.
After completing this module, students will be able to:
!
Identify the important features of a data service, and in particular those of
Microsoft
®
SQL Server
™
and Active Directory
™
.
!
Describe storage and retrieval for data services.
!
Describe how a data service works with data.
!
Describe how a data service maintains data integrity.

!
Describe how a data service handles distribution.
!
Describe the physical design of a data services layer and how to apply
technologies to implement it.

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_10.ppt
!
Module 10: Data Services
!
Lab 10: Data Services

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 10: Data Services


Module Strategy
Use the following strategy to present this module:
!
Introduction to Data Services
The purpose of this section is to introduce students to the data services
layer. The purpose of the data services layer is to facilitate the storage of
data on different types of data storage providers. In this module, you will
introduce students to two types of storage capabilities: relational and
hierarchical.
Emphasize to students that these are not the only two types of data service
providers. Examples of other data service providers are online analytical
processing (OLAP) server for data warehousing and Microsoft Exchange for
workflow application storage.
!
SQL ServerThe purpose of this section is to review with students the salient
features of SQL Server.
In the topic “SQL Server Storage and Retrieval,” emphasize that
denormalizing is one of the key physical design activities associated with
relational database design. To improve retrieval performance, you would
denormalize your table structure.
!
Active DirectoryThe purpose of this section is to review with students the
salient features of Active Directory.
The first two topics in this section explain the requirements of hierarchical
data storage and how the Active Directory design meets those requirements.

This section contains a demonstration of two utility applications that allow
Active Directory browsing. The first utility, ADSVW, allows browsing of
the Active Directory schema, while the second utility, ADSIEdit, allows
browsing and modification of Active Directory objects.
!
Logical Design of Data ServicesThe purpose of this topic is to point out to
students that while there are not currently design patterns that apply to the
logical design of data services, there are other models that can facilitate the
logical design of data services.
!
Physical Design of Data servicesThe purpose of this section is to describe
the key considerations in the physical design of SQL Server and Active
Directory. The first topic in this section provides some general guidelines
about when one type of data store is preferred over the other (relational vs.
hierarchical).
!
Market Purchasing
The purpose of this section is to discuss the logical and physical designs of
the data services layer of Market Purchasing and to explain the choices
made. The logical design of the relational data services is reflected in an
entity relationship diagram (ERD). The logical design of the hierarchical
data services is presented as a schema.
You can use the SQL Server Enterprise Manager to open the Market
Purchasing database and show students the actual implementation for the
physical design. Using the Enterprise Manager, you can show how the
tables are designed and how the constraints and indexes are configured.
Module 10: Data Services v


!

Best Practices
There are four important best practices associated with data services:
• The logical design should specify SQL Server as the preferred data
service for relational, volatile data. All volatile entities, such as
requisitions, vendors, and so on, are stored on a database data service
provider.
• The logical design should specify Active Directory as the preferred data
service for hierarchical, non-volatile data. Non-volatile, highly
redundant data sets such as requestor are stored in Active Directory.
• The physical design of the SQL Server data service should use stored
procedures for data set retrieval and data modification. The physical
design should also use triggers to maintain data integrity.
• The design of an Active Directory schema should include both a class
design and an object design. While defining a class design is a
requirement, defining an object design allows the Active Directory
services to better index the directory to enable faster searches.

Lab Strategy
!
Lab 10: Data Services
The purpose of Lab 10 is for students to experiment with designing a
specialized query. The query is a hierarchical query that will require the
Data Shape Provider to implement the query in the physical design.
The physical design is the hardest part of the lab because students must
derive the query to pass to the Data Shape Provider. Microsoft MSDN
®

Library provides documentation for creating Data Shape Provider queries.
However, it is also acceptable for students to use a pseudocode solution.
Discuss with students their answers to Lab 10.

Module 10: Data Services 1


#
##
#

Overview
!
Introduction to Data Services
!
SQL Server
!
Active Directory
!
Logical Design of Data Services
!
Physical Design of Data Services
!
Market Purchasing
!
Best Practices


In this module, you will learn about the data services layer. This module
focuses primarily on Microsoft
®
SQL Server

™
and Active Directory
™
as two
key technologies of a data services layer. After completing this module, you
will be able to:
!
Identify the important features of a data service, and in particular those of
SQL Server and Active Directory.
!
Describe storage and retrieval for data services.
!
Describe how a data service works with data.
!
Describe how a data service maintains data integrity.
!
Describe how a data service handles distribution.
!
Describe the physical design of a data services layer and how to apply
technologies to implement it.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about the data services
layer and how to create a
physical design for it.

2 Module 10: Data Services


#
##
#

Introduction to Data Services
!
The Business Problem
!
Business Requirements


The data services layer objects and business logic objects allow the data access
layers to retrieve and modify data from the underlying data storage systems.
In this section, the data services layer will be placed in the proper context of the
business problem. This discussion will be followed by a presentation on the
business requirements of a data services layer.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will learn
what makes up a data
service.
Module 10: Data Services 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 layer is accessed by the transactional or nontransactional data
access layer (DAL). The data services layer consists of data service providers
that provide many services, including data definition, data manipulation and
retrieval, logging, archiving, transactions, and so forth.
The data services components are the requests for services that are initiated by
the DAL components and passed to the data service providers. A data service
provider processes the request and returns a result to the DAL.
In this module, you will learn about the characteristics of these requests as they
pertain to different types of data service providers.
Topic Objective
To provide background
about the business problem.
Lead-in
In this topic, you will learn
about the business problem

presented to designers who
need to implement a data
services layer.
4 Module 10: Data Services


Business Requirements
!
Relational
!
Hierarchical

The data services layer satisfies the requirements of business applications for
data storage and retrieval. Specifically, the requirement is that data services
provide a service beyond simple file I/O to be considered a data service. In
general, two types of services can been identified as data service providers:
back-end relational database servers, such as SQL Server, and hierarchical
directory services that can manage application information, such as Active
Directory. The next two sections of this module will explore these technologies
in more detail.
There are, however, other data service providers that can be used in an
application, including data warehouses such as OLAP (online analytical
processing) Server and electronic mail data stores such as Microsoft Exchange
Server. These types of data stores might not be applicable to a general type of
business application and therefore are not discussed in detail in this course.

In SQL Server 2000, the name OLAP Server has been changed to
Analysis Services.

For more information about using data warehouses, see Course 1502B,

Designing and Implementing a Data Warehouse Using Microsoft SQL Server
7.0. For more information about using workflow, see Course 1593A, Building
Collaborative Solutions by Using Microsoft Outlook 2000 and Course 2017A,
Creating Digital Dashboards.

Mail data stores are applicable to general business applications when
used for sending messages. For example, the Market Purchasing application is
designed to send e-mail messages to managers to let them know that there are
requisitions awaiting approval. However, for simplicity, the Market Purchasing
sample does not currently implement e-mail delivery.

Topic Objective
To provide information
about the business
requirements of data
services.
Lead-in
In this topic, you will learn
about the two types of
business requirements:
relational and hierarchical.
Note
Note
Module 10: Data Services 5


#
##
# SQL Server
!

SQL Server Storage and Retrieval
!
Using SQL Server to Work with Data
!
Data Integrity
!
SQL Server Distribution


The design of physical components for a data services layer can be based on
using a database data service provider such as SQL Server. In this section, the
salient SQL Server features will be covered in detail:
!
SQL Server Storage and Retrieval
!
Using SQL Server to Work with Data
!
Data Integrity
!
SQL Server Distribution

For more information about SQL Server, see Course 832B, System
Administration for Microsoft SQL Server 7.0; Course 833B, Implementing a
Database on Microsoft SQL Server 7.0; and Course 2013A, Optimizing
Microsoft SQL Server 7.0.
Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in

In this section, you will
review the important
physical design features of a
database data service
provider such as SQL
Server.
6 Module 10: Data Services


SQL Server Storage and Retrieval
!
Relational
!
Denormalization
!
Indexing
!
Hot Spots
!
Archives


Relational
SQL Server is a relational database. This means that information in the database
is represented in tables and that the relationship between the tables is through
common columns in tables. The physical design of a database for an application
is based on the entity relationship diagram (ERD) derived during the logical
design phase of the data services layer.
Based on the logical design, a first version of the table design of a database is
derived. In this design, a table or a column represents each entity and

relationship. While the logical design of a database is concerned with correctly
representing the entities of the enterprise and is a normalized view of the
relationships between the entities, the physical design is concerned with
performance.
Denormalization
The result of the representation of entities and relationships as tables is a highly
normalized table structure. This representation results in excessive joins in
order to retrieve information needed by the DAL. To avoid excessive joins, the
physical design of a database is denormalized: additional columns and rows are
added to tables to avoid the need for joins. Although denormalization increases
the speed of data retrieval, it results in duplicated columns across tables.
Constraints must be imposed to ensure consistency in these columns when
updates are made to any of the tables.
Indexing
To improve the performance of database retrievals and modifications, define
indexes. For optimal performance, base the definition of the indexes on the type
of operations performed on the database and their frequency.
Topic Objective
To provide an overview of
storage and retrieval.
Lead-in
In this topic, you will learn
about design considerations
for the storage and retrieval
of data.
Module 10: Data Services 7


Hot Spots
Hot spots are a key concern in physical database design. Hot spots are pages in

a table that receive an excessive number of access requests as compared to other
pages in the same table. Hot spots are usually a symptom of poor physical
database design. You can avoid hot spots by defining appropriate indexes on
tables.
Archives
Finally, there is a rule that says that 20 percent of the data is accessed 80
percent of the time. Specifically, the 20 percent of the data that is frequently
accessed is the current data. Separating older data, by archiving it, from current
data can enhance the performance of a physical design.
8 Module 10: Data Services


Using SQL Server to Work with Data
!
SQL Statements
$
SELECT
$
INSERT
$
UPDATE
!
Stored Procedures
$
Result set
$
Parameters
$
Return value
!

Triggers
$
INSERT
$
UPDATE
$
DELETE


The DAL presents data retrieval requests and data modification requests to a
data service provider as either SQL statements or stored procedures. While
using SQL statements is more universal and can be applied to different data
service providers, stored procedures offer a performance advantage.
SQL Statements
The SQL statements make up the syntax for retrieval and modification:
SELECT, INSERT, and UPDATE. There is also a DELETE statement, but its
use is highly discouraged. Deleting records can misrepresent the sequence of
events that occurred when a compensating transaction should have been used. It
is appropriate to use the DELETE statement when the business logic demands a
delete, such as when the administrator wants to delete a requestor’s information
from the database.
Stored Procedures
Stored procedures include both SQL Statements and control-of-flow statements
that encapsulate access control logic on the data service provider. Stored
procedures can return two types of results from the data service provider: a row
set (a table-like structure representing the result of a query) or an output
parameter. In general, row sets are more generic and easier to handle. In
addition, stored procedures can return a value indicating if the operation was
successful.
Topic Objective

To provide a review of
working with data.
Lead-in
In this topic, you will learn
the details of the physical
design of working with data.
Module 10: Data Services 9


Triggers
Triggers are used to maintain data integrity in the database. Triggers are very
much like stored procedures in that they consist of SQL statements and control-
of-flow statements that encapsulate logic for maintaining data integrity.
You can define triggers to run automatically in response to an insert, update, or
delete on a table. The trigger runs before the insert, update, or delete occurs,
allowing the trigger to control what happens during the change. If a change will
violate data integrity, the trigger can prevent the change or allow the change by
updating other tables to maintain data integrity. Once defined, triggers cannot
be turned off; they must be deleted.

In general, issuing DELETE statements against the database is not
recommended. It is recommended that you mark records as not being used, or
move them to archives, instead of permanently deleting the data.

Note
10 Module 10: Data Services


Data Integrity
!

Constraints
!
Triggers


In the physical design of a database, include data integrity: the rules that govern
the consistency and accuracy of the data. In general, there are four types of data
integrity:
!
Entity integrity
A row representing a specific entity cannot be duplicated.
!
Domain integrity
Values for attributes can only be selected from a domain.
!
Referential integrity
The relationships between tables are consistent. This means that a foreign
key field must have a corresponding primary key field.
!
Derived integrity
Values in derived fields must reflect the underlying values of the referenced
fields. An example of a derived value is the total for a requisition that is
based on the corresponding line item detail entries.

There are two mechanisms by which a data service provider can implement data
integrity. One of these mechanisms is declarative, and the other is procedural.
Declarative data integrity uses the SQL constraint syntax and is preferred
whenever possible. There are circumstances, however, in which the logic for
maintaining data consistency cannot be expressed as a constraint. In these cases,
a trigger can be defined for maintaining data consistency.

Topic Objective
To provide an overview of
data integrity.
Lead-in
In this topic, you will learn
how to create a physical
design with data integrity.
Module 10: Data Services 11


SQL Server Distribution
!
Transactional Replication
$
Use when data modification can be separated from data
retrieval
!
Snapshot Replication
$
Use for data-sensitive information
!
Merge Replication
$
Use when updates from multiple sites must be managed


The physical design of data services should include high availability. High
availability is the ability of an application to tolerate failures in server
resources. This means that the client continues to be served during the failure,
and, ideally, the failure is transparent to the client. High availability can be

achieved through replication. In general, the physical design of data services
can use three types of replication: transactional, snapshot, or merge replication.
The particular scenario indicates the appropriate type to use.
Transactional Replication
Use transactional replication when the data is too large to refresh entirely and
you need to maintain consistency in the data.
Snapshot Replication
Use snapshot replication when the data is mostly read only, such as price lists,
and the groups using the data are not dependent on the most current version of
the data. Snapshot replication is also useful when the size of the data is small.
Merge Replication
Use merge replication when there is a situation in which the same data can be
manipulated in multiple locations and the latest update must be available at all
locations.
Topic Objective
To provide an overview of
data distribution.
Lead-in
In this topic, you will learn
the key physical design
issues of data distribution.
12 Module 10: Data Services


#
##
# Active Directory
!
Issues and Challenges of Hierarchical Data
!

Active Directory Solution
!
Active Directory Storage and Retrieval
!
Active Directory Schema
!
Distribution



The design of physical components for a data services layer can also be based
on using a directory data service provider such as Active Directory. In this
section, the most important Active Directory features will be covered in detail:
!
Issues and Challenges of Hierarchical Data
!
Active Directory Solution
!
Active Directory Storage and Retrieval
!
Active Directory Schema
!
Distribution

Topic Objective
To provide an overview of
the section topics and
objectives.
Lead-in
In this section, you will

review the important
physical design features of a
directory data service
provider such as Active
Directory.
Module 10: Data Services 13


Issues and Challenges of Hierarchical Data
!
Data Store
!
Schema
!
Global Catalog
!
Query and Index
!
Replication
!
Integrated Security


The efficient and effective management of storage for hierarchical data poses
several physical design challenges:
!
A data store must exist that stores information about the hierarchical data
objects. These objects typically include user accounts.
!
A set of rules—the schema—must be created to define the classes of objects

and attributes contained in the directory, the constraints and limits on
instances of these objects, and the format of their names.
!
A global catalog must exist to contain information about every object in the
hierarchical data set.
!
A query and index mechanism must exist, so that objects and their
properties can be published and found by users or applications.
!
A replication service must distribute the hierarchical data across a network.
!
Integration must exist with the security subsystem for authentication and
control on directory data queries and data modifications.

For more information about directory services, refer to Course 1561B,
Designing a Microsoft Windows 2000 Directory Services Infrastructure, or the
book Understanding Active Directory Services, by Daniel Blum, Microsoft
Press
®
, 1999.
Topic Objective
To provide background
about hierarchical data
needs.
Lead-in
In this topic, you will learn
about the issues and
challenges of hierarchical
data.
14 Module 10: Data Services

Active Directory Solution
!
Organizational Unit
!
Schema


Active Directory is a directory service that addresses all of the issues and
challenges listed in the previous topic. A directory service consists of both a
repository of information and the software component that makes the
information available and useable globally. Directory services are most
commonly used for storing and retrieving information about people and
companies. Active Directory is the extensible and scalable directory service for
Microsoft Windows
®
2000 Server. When creating a structure to hold
hierarchical data in Active Directory, you should consider which organizational
units you will use and how the schema of classes and attributes should be
defined.
Organizational Unit
One type of directory object contained within domains is the organizational
unit. Organizational units are Active Directory containers into which you can
place users, groups, computers, and other organizational units. An
organizational unit cannot contain objects from other domains.
The organizational unit is the smallest scope or unit to which you can assign
Group Policy or delegate administrative authority. Using organizational units,
you can create containers within a domain that represent the hierarchical,
logical structures within your organization. This enables you to manage the

configuration and use of accounts and resources based on your organizational
model.
Topic Objective
To provide background
about the Active Directory
solution.
Lead-in
In this topic, you will learn
how Active Directory can be
used to store hierarchical
data.
Module 10: Data Services 15


Schema
The schema consists of class definitions and attribute definitions. Within a
class, you can specify the attributes that you want to support, and you can
classify attributes into two categories: optional and mandatory. You also
identify where the class will be located in the hierarchy. These rules are defined
as attributes of the class object.
In Active Directory services, classes follow a simple inheritance model. When
defining a class, you must declare a parent class. This class defines which
attributes are implicitly inherited from their parent class.
16 Module 10: Data Services


Demonstration: Active Directory


This demonstration uses two utility applications: the Active Directory Browser,

named ADSVW, and ADSIEdit.
To run this demonstration, execute the following steps:
!
To browse Active Directory by using ADSVW
1. Click the Start button, and then click Run.
2. In the Open field, type install folder\Democode\Mod10\adsvw, and then
click OK.
3. In the Active Directory Browser dialog box, click ObjectViewer, and then
click OK.
4. In the Enter Ads Path text box, enter
WinNT://your_computer_name,Computer
5. In the Open As text box, enter Administrator, and then click OK.
6. In the left pane, double-click the your_computer_name entry to show the
top-level containers in your domain.
7. Note the different objects that are displayed. There are user objects, group
objects, and Service objects.
8. Click a user. Administrator is one example of a user. In the right pane, you
will see information about the Administrator object and its attributes.
9. On the File menu, click Exit.

Topic Objective
To demonstrate Active
Directory.
Lead-in
In this demonstration, you
will learn how to use Active
Directory.
Module 10: Data Services 17

!
To browse Active Directory by using ADSIEdit
1. Click the Start button, and then click Run.
2. In the Open field, type mmc, and then click OK.
3. When the Microsoft Management Console (MMC) appears, click
Add/Remove Snap-in on the Console menu.
4. Click Add.
5. In the Snap-in list, click ADSI Edit, click Add, and then click Close.
6. If ADSI Edit is not in the list, install the Windows 2000 Support Tools from
the \Support\Tools folder on the Windows 2000 Server CD.
7. Click OK to close the Add/Remove Snap-in dialog box.
8. Right-click the ADSI Edit node under Console Root and click Connect to.
9. In the Connection dialog box, verify that the Name field contains Domain
NC, and then click OK.
10. To view the top-level containers in your domain, expand the entry for your
domain tree. Note the Builtin, Computers, Domain Controllers, and Users
containers. These containers are part of every Active Directory tree.
11. To display a list of lower-level compatible users known to this domain, click
the Users container. The list will appear in the right pane.
12. To view the attributes associated with a user, right-click the user and then
click Properties. Administrator is one example of a user.
13. Choose the properties that you want to display in the property list from the
Select which properties to view list. From the Select a property to view
list, click a variety of attributes and view the information about each one.
14. On the Console menu, click Exit.

18 Module 10: Data Services


Active Directory Storage and Retrieval

!
Hierarchical
!
Low Volatility
!
Fast Retrieval


It is recommended that a data set residing in a directory service have the
following qualities: hierarchical, low volatility, and fast retrieval.
Hierarchical
In general, a data set residing in a directory service should have a hierarchical
data structure. If the data in your logical design has a parent-child relationship,
consider translating it into a schema in Active Directory as a hierarchical data
structure.
Low Volatility
It is recommended that a data set residing in a directory service have low
volatility. This implies that the data set should be relatively stable.
Fast Retrieval
The third quality of a data set has to do with its retrieval requirements. The data
service provider must be capable of providing extremely fast retrieval
capability.
The combination of these three features—hierarchical, low volatility, and fast
retrieval—defines the selection criteria for candidate data sets to reside on
Active Directory.
Topic Objective
To provide an overview of
storage and retrieval.
Lead-in
In this topic, you will learn

how to design the physical
storage and retrieval of a
directory.
Module 10: Data Services 19


Active Directory Schema
!
Class Design
$
Structural
$
Abstract
$
Auxiliary
!
Object Design
!
Attributes


The physical design issues associated with Active Directory relate to the design
of the schema.
The schema consists of class design, object design, and attribute definitions.
Class Design
A class design allows you to specify the attributes that you want to support. In a
class design, you identify where the class can reside in the hierarchy. These
rules are defined as attributes of the class object.
In Active Directory services, classes follow a simple inheritance model. When
defining a class, you must declare a parent class. This class defines which

attributes are implicitly inherited from their parent class. When defining a new
class, each class must specify a class category and an object category. The class
category describes how the class will be used in the inheritance tree. The three
valid choices for the class category are structural, abstract, and auxiliary:
!
Structural classes
This class category allows a class to have instances in Active Directory.
Structural classes are the only classes that can be stored in the directory.
!
Abstract classes
This class category is used to define sets of attributes that may belong to a
common set of classes but that are not creatable themselves.
!
Auxiliary classes
This class category is similar to include files in C. They define a set of
attributes that can be attached to a class in order to add a specific set of
attributes.

With this structure of abstract classes and auxiliary classes, a simple multiple
inheritance model can be defined for the schema in Active Directory.
Topic Objective
To provide a review of
working with data.
Lead-in
In this topic, you will learn
the details of the physical
design of working with data.