Objects (DSO)
Note
This feature will be removed in the next version of Microsoft SQL Server. Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible.
In Decision Support Objects (DSO) there are two ways to classify objects: objects that can be accessed and managed directly, and objects that implement a DSO interface.
Objects that can be accessed and managed directly have their own collections, methods and properties. They include the following classes:
clsColumn
clsCubeAnalyzer
clsDataSource
clsMemberProperty
clsMiningModel
clsPartitionAnalyzer
clsServer
Note
Class type designations that use the format clsClassType, such as clsServer, are used internally by the DSO ClassType property and do not necessarily correspond to a particular class definition within Microsoft® Visual Basic®.
Objects that implement an interface use a subset of the collections, methods, and properties associated with the interface. The DSO ClassType and SubClassType properties determine which features of an interface are implemented by a particular object. Information about these features appears throughout this document.
Each collection, method, and property description contains the names of the objects in which it appears. Conversely, each object description contains the names of the collections, methods, and properties that the object implements.
The following table lists the six DSO interfaces and the objects that implement them.
Interface |
Implemented by |
---|---|
For more information, see Interfaces.
Objects That Are Accessed Directly
The following objects do not implement a shared interface and are accessed directly.
Object |
ClassType |
---|---|
Column |
|
Cube analyzer |
|
Data mining model |
|
Data source |
|
Member property |
|
Partition analyzer |
|
Server |
Objects That Are Accessed Through an Interface
The DSO object model uses interfaces to simplify your interaction with groups of related objects, while maintaining parent-child inheritance throughout the object model hierarchy. For more information about the complete hierarchy, see Introducing Decision Support Objects.
Each DSO object that implements a DSO interface belongs to one of the following categories:
Aggregations
Commands
Cubes
Databases
Dimensions
Levels
Measures
Partitions
Roles
The uniqueness of multiple DSO objects within the same category is determined by where each is contained within the overall DSO object model hierarchy. For example, a cube can contain several dimensions. These dimension objects are contained in the Dimensions collection of the cube. Each of these dimension objects is a DSO object of ClassType clsCubeDimension.
Each cube also contains a collection of partition objects. Each of these partition objects also contains a collection of dimension objects in its Dimensions collection. Each of these dimension objects is a DSO object of ClassType clsPartitionDimension.
Although the DSO objects of ClassType clsCubeDimension and clsPartitionDimension are both dimension objects, their methods and properties are unique because of the parent objects in which their collections are contained. The DSO object model groups such objects together and manages them by the implementation of a common interface.
Major and Minor Objects
In DSO, most child objects cannot commit their own changes to the Analysis server, but instead must rely on their parent object to commit the changes of their child objects. Any object that can commit itself and its children is referred to in DSO terminology as a major object. Any object that cannot commit itself, but must rely on a major object to perform such an action, is referred to as a minor object.
Objects with the following ClassType property values are considered major objects:
clsCube
clsDatabase
clsDatabaseCommand
clsDatabaseDimension
clsDatabaseRole
clsDataSource
clsMiningModel
clsPartition
clsServer
All objects not included in the previous list are considered minor objects. To commit changes to major and minor objects, all major objects in DSO support the Update method. Any change to a DSO minor object must be committed through the parent DSO major object in order to be committed. For example, a change to a clsCubeRole object is committed only when the Update method of its parent clsCube object is executed. Although most interfaces in the DSO hierarchy have an Update method, attempting to use the Update method on a minor object in DSO will result in an error.