The CA MDB

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


What the current MDB offers

- 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)


What the current MDB offers- 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


What the current MDB offers

- 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