Decision Support Objects Architecture
[!NOTA] Questa funzionalità verrà rimossa a partire dalla prossima versione di Microsoft SQL Server. Non utilizzare questa funzionalità in un nuovo progetto di sviluppo e modificare appena possibile le applicazioni in cui questa funzionalità viene utilizzata.
Decision Support Objects (DSO) is a library of Component Object Model (COM) classes and interfaces that provide access to the Analysis server. These classes and interfaces, when used together, form an object model that corresponds to the internal structure of the objects managed by Microsoft® SQL Server™ 2000 Analysis Services and can be used to manage them programmatically.
Conceptually, DSO uses hierarchically arranged groups of objects to define basic elements of Analysis Services data storage, as implemented by the Analysis server. These basic elements are databases, data sources, dimensions, cubes, data mining models, and roles. DSO maintains these basic elements in a hierarchical structure where elements contain other elements in a tree, with the server object at the root of the tree. Other objects support this basic structure. For example, databases, cubes, partitions, and aggregations support dimensions. The following diagram shows an overview of the DSO object model hierarchy.
The DSO Server object contains a collection that defines databases accessed by the server. Each database can contain groups of objects that define cubes, linked cubes, or virtual cubes. A cube contains one or more partitions, which contain one or more aggregations. Linked cubes serve to provide local server access to a cube on another server; the remote server publishes the cube, and the local server subscribes to it by creating a linked cube. A virtual cube is a special case of a cube, combining portions of the cubes it contains, similar to the way a relational database view combines portions of tables. A database can also contain one or more relational or OLAP data mining models, represented in DSO by the MiningModel object. Data mining models can contain one or more data mining columns. Databases also can contain roles, used to manage security on the database and its associated cubes and data mining models.
MDStore Interface
You will notice in the diagram that two of the most important collections of objects in DSO, databases and cubes, are supplied with a collection named MDStores, unlike other objects in DSO, such as data mining models or commands.
Databases, cubes, partitions, and aggregations expose a common interface, called MDStore, that provides the methods and properties you use to manipulate the objects. These objects must be referenced from its parent object, and they cannot be created independently; the only way to create a database, cube, partition, or aggregation is through the MDStores collection of the parent object. For example, the only way to obtain an object reference to a database in DSO, or to create a new database using DSO, is through the MDStores collection of the DSO Server object.
This special collection maintains references to the objects that make up the elements of this hierarchy beneath the server. The MDStores collection provides special implementations of Add, Find, and Remove methods, and a convenient AddNew method, which maintain parent-child relationships among the various DSO objects. The ContainedClassType property determines what type of objects the MDStores collection can contain; the value of this property directly corresponds to the ClassType property of the MDStore objects contained by the collection.
The MDStore interface also uses the SubClassType property to further differentiate DSO objects. For example, this property is used to tell the difference between a cube, a linked cube, and a virtual cube.
This figure shows an expanded view of the DSO structure as viewed by its collections, including the value of the ClassType property of the objects contained in each collection.
There are two major object classifications in DSO: objects that can be accessed and managed directly using their default interface, and objects that implement other DSO interfaces in addition to their default interface.
Objects that can be accessed and managed directly have their own collections, methods, and properties, and they fully implement their default interface; there is no change in the behavior of the interface based on its usage or parent-child association. For example, the DSO DataSource object behaves the same way whether the parent is the DSO Server object or the DSO Cube object.
The following table lists the eight directly accessible DSO interfaces and the ClassType property values associated with them.
| Interface | ClassType property value |
|---|---|
clsColumn |
|
clsCubeAnalyzer |
|
clsDataSource |
|
clsMemberProperty |
|
clsMiningModel |
|
clsPartitionAnalyzer |
|
clsServer |
Objects that are implemented with more than one interface use a subset of the collections, methods, and properties associated with the interface for the implemented variation of a DSO object; for example, the Command interface is implemented differently for database commands, cube commands, and role commands. 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 it implements.
The following table lists the six DSO interfaces and the ClassType property values associated with them.
| Interface | ClassType property value |
|---|---|
Command |
clsDatabaseCommand clsCubeCommand clsRoleCommand |
Dimension |
clsDatabaseDimension clsCubeDimension clsPartitionDimension clsAggregationDimension |
Level |
clsDatabaseLevel clsCubeLevel clsPartitionLevel clsAggregationLevel |
MDStore |
clsDatabase clsCube clsPartition clsAggregation |
Measure |
clsCubeMeasure clsPartitionMeasure clsAggregationMeasure |
Role |
clsDatabaseRole clsCubeRole clsMiningModelRole |
Scripting Considerations
The DSO library is not marked safe for scripting. Objects in libraries that are marked safe for scripting take into account the security context in which they are created. When a control or a library that is not marked safe for scripting is loaded in Microsoft Internet Explorer 4.0 or later, the browser can run a script only within the Low security mode of Internet Explorer, and even then only after a user responds to a message stating that a script will be run. If you use DSO as part of a middle-tier component in a n-tier or client/server application, use a design pattern that does not pass direct references to DSO objects; instead, implement other objects or functions, that in turn, call DSO objects.