Namespaces and partitioning the data model
You can partition the data model by using namespaces. Unlike datasets, which partition instance data, namespaces partition classes and attributes in the data model. This allows you to specify the provider or consumer of a certain type of data, or to make other arbitrary groupings. For example, all classes in the Common Data Model are in the
BMC.CORE namespace, and other classes provided by BMC Atrium CMDB that hold information such as configuration definitions are in the
Other BMC Software products that extend the data model, such as BMC Impact Solutions or BMC Atrium Discovery and Dependency Mapping, create their own namespaces to hold the new classes and attributes. Likewise, BMC extensions that are distributed independently of BMC products use their own namespaces.
Namespaces can be applied at the attribute level as well as the class level. This means that some, or even all, of the attributes of a class can reside in a different namespace from the class itself. This is useful when you have a class that is used for more than one purpose, but one of those purposes requires an extra attribute.
A namespace serves as a label to identify classes that serve different purposes, and serves also to create unique names. A namespace prepends the names of its class forms, though not its attribute fields. Therefore, a class that you create in one namespace can have the same name as an existing class in another namespace. However, attributes of the same class in different namespaces cannot share the same name.
Namespaces do more than just serve as a logical categorization system for the data model. Because many reconciliation definitions allow you to specify namespaces, you can easily target a reconciliation activity to include only data that is being stored for a particular purpose. Instead of creating a lengthy qualification to select or omit several specific classes, you can include or omit them from an activity by specifying their namespace.
Whenever you extend the data model, use your own namespace instead of
BMC.CORE. This prevents your extensions from being overwritten by new BMC Software classes when you upgrade to a future version of the CDM. When creating namespaces, use the naming convention
COMPANYNAME.PURPOSE. For example, if the Calbro Services company created a set of classes for storing data about buildings and other facilities-related CIs, they might store them in the namespace