16.10.2015 Views

Getting Started with InfoSphere Data Architect

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 3 – Logical <strong>Data</strong> Modeling 65<br />

values.<br />

SET_DEFAULT<br />

DO_NOT_ENFORCE<br />

When a parent entity is altered, each nullable foreign key<br />

attribute is set to its default value. This option can only be<br />

specified if all foreign-key attributes have default values.<br />

This generates an informational constraint for DB2 systems.<br />

The code that is generated is not enforced.<br />

An informational referential constraint is a constraint that DB2<br />

does not enforce during normal operations. Use these<br />

constraints only when referential integrity can be enforced<br />

through other means, such as when you retrieve data from<br />

other sources. These constraints might improve performance by<br />

allowing the system to automatically rewrite the query.<br />

Table 3.1 – Definitions for parent and child entity actions<br />

5. Save your work.<br />

3.3 Working <strong>with</strong> glossary models<br />

Sometimes, when working <strong>with</strong> various people on the same project, data object naming<br />

varies. Where one data architect might refer to sales entities as SALES_x, another data<br />

modeler might prefer SLS_x. Over time, the system becomes difficult to understand, and<br />

the inconsistency can spread across systems, causing confusion, longer application<br />

development times, or even the inability to make the connection between two fields that<br />

mean the same thing in two different systems.<br />

To avoid this problem, you should develop a set of naming standards early in the data<br />

design process. Naming standards help you and other people in your organization look at<br />

your data in a consistent manner, so that you all get the same meaning. With IBM<br />

<strong>InfoSphere</strong> <strong>Data</strong> <strong>Architect</strong>, you can create a set of rules that all data modelers should<br />

follow, and the workbench can automatically create names of some of the data objects<br />

(such as relationships) for you.<br />

A glossary model is a model that describes the names and abbreviations that an<br />

organization allows for data objects. <strong>Data</strong> object naming standards promote a common<br />

understanding of data, since you use the same name conventions across the entire<br />

organization. You can use glossary models to enable sharing of data across organizational<br />

boundaries and reduce data redundancy through the consolidation of synonymous and<br />

overlapping data elements.<br />

When you name a data object, you need to take into account two items: semantic rules and<br />

format. Semantically, glossary model objects include prime words, class words, and<br />

modifiers:

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!