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: