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. 168 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 P erson t a bl e personID height weight eyeColor hairColor 1 180 90 brown black 2 190 95 blue brown Person table personID 1 2 SoftcodedValue table value ID value Number value String person ID attrib ID 1 180 1 1 2 90 1 2 3 brown 1 3 4 black 1 4 5 190 2 1 6 95 2 2 7 blue 2 3 8 brown 2 4 Attribute table attribID name 1 height 2 weight 3 eyeColor 4 hairColor EntityType name {unique} attributeName * 1 10 1 * 1 Attribute dataType maxLength minMultiplicity maxMultiplicity {ordered} * 1 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 SoftcodedVal ue 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 (maxMultiplicity = *) for each Entity of an EntityType. 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 Perso n 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) . Softcoded values: UML model. The model combines data and metadata. 170 Chapter 13 / Softcoded Values A SoftcodedVal ue is a piece of data for an Entity and has parallel fields for different data types 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. . 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