First published on TECHNET on Jan 28, 2009
This post is a continuation of the series started with
The System Center Platform in Service Manager
At the heart of the System Center common platform is the “model-based” database. By “model” here I am talking about the kind of model used for classification not the kind of model you take pictures of. A model in System Center is a way to describe what you are managing. For example you could have a classification model that looks like this (click to view full size):
The boxes each represent a class of things that you know about. As you go farther down the model the classes get more specific. For example (looking from the bottom going up) – Computer is a kind of Device which is a kind of Logical Hardware which is a kind of Logical Entity which is a kind of Configuration Item. Each of the black lines represents “inheritance” of properties and relationships from a parent class to a child class. The blue lines represent relationships between classes. By creating a model like this, you can describe
you might want to manage in your IT organization – coffee machines, overhead projectors, typewriters (what? you don’t have any of those anymore?), etc. In fact, this modeling concept is so flexible you could use it to describe anything – football leagues/teams/players or even classify the different kinds of web sites on the Internet.
For those of you that are familiar with database design, this may seem kind of like an
Entity Relationship Diagram
(ERD) in some ways. In a way, these models are the ERD for a model-based database in System Center. These classes, properties, and relationships can all be declared in management packs like this (click to see full size):
When a management pack containing class, property, and relationship elements is imported into a model-based database in a System Center product, the database schema itself is extended. A new table is added for each class and each property becomes a column in that table. Now data about those classes, properties, and relationships can be stored in the model-based database. For example, if you had 3,000 computers in your organization you could store them on the System.Computer table in the model-based database.
This model-based database technology is very powerful because it allows Microsoft, partners, and customers to easily extend the database behind System Center products to add new classes (tables), properties (columns), and relationships. You can extend classes that Microsoft provides by adding new properties or relationships or make entirely new ones by creating a management pack and importing it. If you decide that you no longer want to keep track of that kind of data you can uninstall the management pack which will cleanly remove the database schema extensions created by that management pack.
This model-based database is used in several System Center products. The OperationsManager database used in System Center Operations Manager and System Center Essentials is an example of this model-based database. System Center Service Manager uses this model-based database in two places – the ServiceManager (note: in Beta 1 this database is called SMDB) database and the DWStagingAndConfig (note: in Beta1 this database is called DWSMDB) database mentioned in Chad’s
Data Warehouse and Reporting
post recently. The ServiceManager database is sometimes referred to as the “
”. It is the central store of all configuration items and work items managed by Service Manager. It also stores all the customizations and configuration for the Service Manager product itself. DWStagingAndConfig stores the configuration for the data warehouse and is used as a temporary place to stage the data as it moves from the ServiceManager database into the other parts of the data warehouse (DWRepository and DWDataMart).
So – here are the first two pieces of the Service Manager architecture puzzle at full scale – the model-based databases ‘ServiceManager’ and ‘DWStagingAndConfig’.
Try it out using the information in this
Come back for the next piece of the puzzle next week – the “SDK Service”.