PATTERNS OF DATA MODELING- P37 pptx

13.1 UML Model Figure 13.2 presents a UML model for softcoded values.. The top entity types shaded in gray EntityType, Attribute, EnumValue concern metadata.. The bottom Entity, Softcode

12.5 Chapter Summary 167

12.5 Chapter Summary

A translation service is helpful when software must support multiple languages such as Eng-lish, French, and Japanese The need for such a capability often arises and can be delivered

as a service apart from any particular application This chapter presents several approaches

to language translation

Bibliographic Notes

Several commercial products have language translation capabilities including Multilizer, Schaudin, Lionbridge, and Xataface

The terms internationalization and localization are prominent in the literature “Interna-tionalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text.” [Wikipedia] The models in this chapter deal with internationalization The population of data addresses localization

References

[Warmer-1999] Jos Warmer and Anneke Kleppe The Object Constraint Language Boston:

Addison-Wesley, 1999.

13

Softcoded Values

Most database applications directly map concepts to tables The direct approach is effective for applications with well-defined entity types and attributes However, it fails for applica-tions with open-ended requirements

Consider person data Persons are prominent in applications and can involve much data For example, a police database could have a lengthy description of suspects including height,

weight, eye color, and hair color The top of Figure 13.1 shows a database table for Person,

using a direct representation (hardcoding) The bottom shows an alternative representation using softcoding The columns in boldface are primary keys

If the requirements are uncertain, the hardcoding of person data will be fragile New at-tributes will be likely to arise, requiring model extensions and disrupting the application code Softcoding decreases efficiency and increases storage space, but the cost is tolerable for many applications

Hardcoding builds many constraints into the database structure For example, a person has one height and one weight With softcoding, metadata can declare that each person has

a single value of height and weight (Figure 13.1 omits metadata.) Careful programming must ensure that data satisfies the constraints specified by the metadata

Hardcoding is easier to visualize and develop Softcoding involves queries and program-ming that are more complex Given that applications hide behind a user interface, softcoding implies more work for the developer, but need not complicate the application for the end

us-er The database and application code can be softcoded for flexibility with the user interface being hardcoded for usability

13.1 UML Model

Figure 13.2 presents a UML model for softcoded values The model combines data and

metadata The top entity types shaded in gray (EntityType, Attribute, EnumValue) concern

metadata The bottom (Entity, SoftcodedValue) concern data Ordinary users may enter data

13.1 UML Model 169

but only privileged users should enter metadata Softcoded values extend the

Homomor-phism template (See Chapter 5.)

13.1.1 Data

An Entity is a placeholder for things that can have SoftcodedValues.

Figure 13.1 Database tables for hardcoding vs softcoding

Hardcoding

Softcoding

Person table

personID height weight eyeColor hairColor

Person table

personID 1

2

SoftcodedValue table

value ID

value Number

value String

person ID

attrib ID

1 180 1 1

5 190 2 1

7 blue 2 3

Attribute table

attribID name

EntityType

name {unique} attributeName

*

1

*

1

Attribute

dataType maxLength minMultiplicity maxMultiplicity {ordered}

*

1

{ordered}

EnumValue

valueInteger valueDecimal valueString valueDateTime

SoftcodedValue

valueInteger valueDecimal valueString valueDateTime

Entity

<logicalIdentifier>

Figure 13.2 Softcoded values: UML model The model combines data

and metadata

170 Chapter 13 / Softcoded Values

A SoftcodedValue is a piece of data for an Entity and has parallel fields for different data

types A SoftcodedValue can have one of four data types—integer, decimal, string, or

date-Time Exactly one of these four fields must be filled in (and the other three set to NULL) for

each SoftcodedValue record If additional data types are needed (such as money), you can

add more fields Note the following subtleties of the model

• Multivalues An Entity can have multiple SoftcodedValues for the same Attribute

(At-tribute is to be explained).

• Flexible data entry By default, any SoftcodedValue can be stored Alternatively, you

may restrict the possible SoftcodedValues with enumerations (to be explained).

13.1.2 Metadata

An EntityType describes a group of Entities with the same attributes, behavior, kinds of re-lationships, and semantics An EntityType can have many Attributes An Attribute is a named

property of an EntityType that describes SoftcodedValues that can be held by each Entity of the EntityType.

Thus each Entity has an EntityType that defines Attributes for which SoftcodedValues can be stored Another way of thinking about the model is that an Entity can have any number

of SoftcodedValues The EntityType constrains the SoftcodedValues by specifying the

Attri-butes that can be populated.

Each Attribute has a specified dataType (integer, decimal, string, or datetime) indicating

the appropriate field to fill in for each SoftcodedValue Attributes with a dataType of ‘string’ have a maximum length to which SoftcodedValues must conform.

The box enclosing attributeName is a UML qualifier specifying that each Attribute has

a unique attributeName for its EntityType Since the model does not specify otherwise, an

attributeName is not globally unique and may be reused across multiple EntityTypes The At-tributes are ordered within an EntityType just as you would find for a hardcoded model.

Note that the model’s structure permits an Entity and Attribute combination to have no

SoftcodedValue or multiple SoftcodedValues The minMultiplicity indicates if an Attribute is

optional (minMultiplicity = 0) or required (minMultiplicity = 1) for each Entity of an

Entity-Type Similarly, the maxMultiplicity indicates if an Attribute is single valued

(maxMultiplic-ity = 1) or multi valued (maxMultiplic(maxMultiplic-ity = *) for each Ent(maxMultiplic-ity of an Ent(maxMultiplic-ityType The maxMultiplicity is intended to be a set—if an Entity has multiple SoftcodedValues for an At-tribute, they are not ordered and there can be no duplicates.

Some Attributes have a set of possible values For example, the permissible colors for a

lawn mower might be red, green, and blue An EnumValue defines an enumeration value

for an Attribute If EnumValues are specified for an Attribute, the SoftcodedValues must con-form to the list The EnumValues for an Attribute have a defined order.

EnumValue also has parallel fields for the different data types An EnumValue can have

one of four data types—integer, decimal, string, or dateTime—corresponding to its

Attri-bute Exactly one of these four fields must be filled in (and the other three set to NULL) for

each EnumValue If additional data types were needed (such as money), it would be a simple

matter to add more fields

13.2 IDEF1X Model 171

13.2 IDEF1X Model

Figure 13.3 restates Figure 13.2 with the IDEF1X notation The IDEF1X model uses exis-tence-based identity (See Chapter 16.)

An Entity can have one or more fields that serve as a logical identifier (alternate keys, see Chapter 11) For example, taxpayer number could identify Persons Given a logical iden-tifier, a user can find an Entity and then traverse the model to retrieve associated data.

13.3 Architecture

13.3.1 Using Softcoded Values in an Application

There are two ways that an application can use softcoded values

• Inherit softcoding In Figure 13.4 and Figure 13.5 Person and Document inherit from

Entity Thus, for example, all Persons are Entities with an EntityType of “Person” that

determines Attributes for which softcoded values can be stored [Blaha-2006] shows how to write Entity stored procedures that Person and Document can reuse The example shows only Person and Document, but the inheritance approach is best when several

En-tityTypes have softcoded values.

• Clone softcoding Figure 13.6 and Figure 13.7 clone softcoding tables, once for Person

and once for Document With this approach an application not only clones schema, but

also repeats data manipulation logic Cloning provides a simple approach when few entity types have softcoded values

Figure 13.3 Softcoded values: IDEF1X model

entityTypeID

entityTypeName (AK1.1)

EntityType

entityID

logicalIdentifier (AK1.1)

Entity

attributeID dataType

Attribute

maxLength minMultiplicity maxMultiplicity entityTypeID (FK) (AK1.1, AK2.1) attributeName (AK1.2)

sequenceNumber (AK2.2)

valueString valueDateTime

SoftcodedValue

valueID

entityID (FK) attributeID (FK)

valueInteger valueDecimal

enumValueID valueInteger

EnumValue

valueDecimal valueString valueDateTime attributeID (FK) (AK1.1) sequenceNumber (AK1.2)

entityTypeID (FK)