16.10.2015 Views

Getting Started with InfoSphere Data Architect

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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!