The CA MDB Revised May 16 2006. © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced

The CA MDBRevised May 16 2006

© 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

CA MDB: Summary

- Primary version based on Ingres 3.0

- Other versions based on MS SQL Server, Oracle

- Includes thousands of tables, views, indexes

- Built by combining database models from many CA products


How do you build an MDB?

- Single database instance

- Use unique data types

- Consistent schemas

- Naming conventions

- Stored procedures

- Design patterns

- Unified sets of tables for specific entities/objects


Where is the MDB today?- Single database instance

- Multiple definitions for some data elements


Today (continued)

- Mostly consistent schemas- Naming conventions- Stored procedures

- One unified set of tables: for assets- eIAM stores applications’ authentication, authorization,

access control information- May adopt industry standards (e.g. CIM) when possible- Single set of data owners, permissions


Unified model for assets

- Set of tables defined by developers for:

- ServiceDesk

- Unicenter NSM

- Argis

- Unicenter Asset Management

- Entries made by one application visible to all

- DB triggers used to update other tables, perform additional operations when assets are added.


Revolutionary Change

- Applications can access other app’s data directly

- Simplifies reporting, analysis across apps

- Multiple products can share database server


What the current MDB offers

- Central Management - Standard Configurations- Standard Patch and Upgrade- A set of best practices for:

- Scalability- Fault Tolerance- Securability (firewall and NAT)- MDB Federation



- Product Specific Federation

- Core Bridge

- Service Desk multiple MDBs, contact replication, and request broker

- Desktop and Server Management hierarchical selective replication (2-tier but n-tier designed)



- An ERwin physical model-based collection of all tables & columns used by the CA products

- A physical model that was assembled by combining DDL from various product teams

- A breakdown of tables & columns into Subject Areas that map to the respective CA products

- A partial definition of the relationships between the tables that comprise MDB



- A model that supports basic IP-address based asset reconciliation capabilities

- A model that recognizes the central importance of asset and provides some modeling of the complexity of asset

- Asset Logical model is documented

- Tools used in conjunction with ADT allow asset import using the common object registration API (CORA)


Summary

- MDB is used in r11 products and value is huge

- Most applications co-exist, with selective sharing

- Several “best in class” products coordinate use of, and share data – especially for assets and users

- Application-specific interfaces, communications are still used

- Deployment options generally rich


Common Misunderstandings…

- MDB’s availability on a specific DB does not mean all applications support that DB

- No common method/API for modifying all data in MDB

- Not used consistently by all CA products

- MDB is not a CMDB


Asset Information Scenarios- ServiceDesk and Argis:

- As Service Desk is about to enter data about an asset, the user can search through existing assets in the MDB, including those created by Argis.

- Users can pick an existing asset and avoid data entry, or the addition of a duplicate entry.

- NSM and UAM: - When Discovery runs, every object is registered as an asset. UAM is triggered by asset registration and can push out an agent to do a full hardware and software inventory.

- Trigger provides the “glue” between "continuous discovery" and UAM.

- Result: When an incident is recorded in ServiceDesk, SD will check registered assets, even those discovered by NSM, and the inventory info will be available as well.


Limitations

- No public (client) API for asset definition through the MDB

- Definitions may change, or may rely upon undocumented behavior or business logic

- Exception: UAPM packages a copy of ADT with CORA integration to add assets

- Existing application-specific APIs should be used (for now)


Deployment Choices

- One product, one MDB instance

- Multiple products, one MDB instance

- Multiple products, multiple MDB instances


Integration

- Model level: normalized data

- Database level

- triggers, stored procedures

- Application level

- API, scripts

- “Bridge” for CORe

- Presentation level

- Portal, Reporter, F&T


Deployment Issues

- Ingres issues

-Performance – you architect in scalability

-MDB issues

-May not want information shared between applications; e.g. UAM assets become managed objects in NSM

-Legally may be unable to put all data in one MDB

-Application issues?


-Distributed installation and access services

-Federation services

-Abstraction Layers

-Connectors

-Platform and additional RDBMS Support

-“ Hot” upgrade services

-Granular DDL definition/extension

Moving Forward – MDB



- Some Techie Details Under Study:

- Reduce data type duplication

- Normalize data model

- Add common methods across applications for:

- Extension of models

- Entity addition, updates

- Address MDB-specific issues:

- Filtering of shared data

- Replication vs. application distribution



- More Techie Details Under Study : - A model that supports a central Asset registry to which all

physical instances can register Assets

- A model that supports a technical solution without a single point of failure

- A model that can scale in a predictable manner

- A model that supports a central authentication and consistent data authorization facility

- A model documented at the entity and attribute level



- Even More Details Under Study :

- A model in which non IP-address based assets are accommodated

- A model that recognizes and registers assets with satisfactory performance

- A model in which critical taxonomies (Owned versus Discovered Asset, Logical versus Physical Asset, Locations, Organizations, Contacts/Users, Services, and Configuration) are normalized

Documents

The CA MDB Revised May 16 2006. © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced