Idioms: a Pattern language for database

modelling

Marcelo Flores, Pabo Azero, and Vladimir Costas

Programa MEMI, Facultad de Ciencias y Tecnologı́a,

Universidad Mayor de San Simón
{marcelo,pabloazero,vladimir}@memi.umss.edu.bo
http://www.memi.umss.edu.bo

Abstract. The database designer can frequently take advantage from

previous models in order to give a solution to any specific problem. This
work presents small modelling structures called Idioms that represent
patterns found in successful practices. These Idioms are used as tem-
plates, and help to build solutions to common problems in database
modelling. The resulting Idiom Language specializes the native ER lan-
guage and reuses the same concrete syntax. This language avoids the
risks of incomplete and extraneous ER structures, aiming at a model
with high semantic content, correctness, high navegavility and whose
semantic is not considered in the native ER language. An important
property of idioms is that they provide an structured (and composable)
way of building ER models. A ER model viewed with the lenses of Idioms
can be empowered with syntactical refactorings to improve its legibility
and quality.

Key words: modelling language, entity-relationship model, composi-

tionality, model properties, metamodel, refactoring

1 Introduction
Idiom is a significative word in linguistical terms. It refers to a syntactical con-
struction (phrase or sentence) whose semantics is not in the word by word read-
ing. It is in the complete phrase only[1], for example:

“a piece of cake”, “pull a Homer”

Similarly, it is possible to find idioms in other languages, including program-

ming languages [19, 20]. The ER language is not an exception, as it will be shown
in this paper. In the second section of this work, the idiom concept in the ER
language will be described. The third section describes same examples of idioms.
In the fourth section, a estrategy to design the pattern language from the native
ER language is developed. A reference arquitecture is also given. The fifth section
describes the idioms metamodel (first describing the metamodel for the native
ER language). The sixth section describes some uses of the idioms language in
the design of ER models. It is also shown that with the idioms it is possible
2 Idioms: a Pattern language for database modelling

to build ER models in a compositional way. The seventh section illustrates how

model refactoring - in terms of idioms - will affect the quality of models. The
last section describes the concerns and expectations of the authors.

2 Idioms in ER

Like idioms in other languages, ER idioms, are not to be read or understood

symbol by symbol. That is, in ER the considered symbols are: type entities,
relationships, cardinality, mandatory and dependency. ER idioms are based on
syntactical structures could be powerful resources to design databases in a com-
positional way, assembling complete and consistent ideas.
The idioms give to the designer a set of puzzle pieces to design ER mod-
els. Each piece have a precise syntax and a well defined semantics. Also, the
idioms have a name and recognizable characteristics at the universe of discourse
(UoD)[7]. These characteristics help to read the ER model in terms of idioms
instead in terms of plain ER, increasing the semantic quality of the model.
En general terms an idiom ER is a structure described in terms of ER lan-
guage with precise syntactical and semantical definitions, have a name and aso-
ciated characteristcs, that differ one from each other.
Unlike the OO design patterns[6], the idioms do not pretend to give a struc-
tured solution to a specific modelling problem. They rather pretend to define
building bricks in order to map the UoD vision in terms of a ER model. They
basically represent abstractions, like those built in the OO paradigm[4]. For this
reason the few idiom structures are simple and small. One the most important
advantages of the idioms it is that they have a predefined concrete syntax in ER,
making thus the translation to ER unnecessary.
We have identified the following idioms[3]:

– Basic
– Classification or Catalogue
– Composition
– Master Detail
– Reflexive
– Historical reflexive
– Is-a

Along the paper, this list is also refered as the Idiom Catalogue.

3 Some Idioms in the catalogue

In this section some examples of idioms are given.

Note, the idioms are defined with the cardinality, mandatory or optionality
and patterns of entiti keys or attributes.
 Idioms: a Pattern language for database modelling 3

3.1 Idiom Classification or Catalogue

This idiom is the most frequently found. It is present in almost all visions of
the UoD, used to classify the entity types with a set of predefined values, for
example a city of birth (clasiffier or catalogue of values) of a person (classified or
catalogued). This is very useful to solve the first normal form. And allows that
at the rest of the design, the validations are done in terms of idioms instead of
plain ER. For example: how many type entities classify the city type entity?, can
I reuse this classificator? (Yes! reuse is intense with idioms), what is happening
if one classificator entity is deleted or added? These questions about the model
are similar to the ones posed for the UoD: how many persons classificate one
specific city? can I reuse a city? what happens if a city is removed or added?
The pattern template for Idiom Classification is shown in Fig. 1

Fig. 1. Classification Idiom

Semantics: – Q is a classifier or catalogue for P.

– Q contains a set of resources for P.
Characteristics: – Allows the freely growth of Q.
– Gives a finite classiffier and extensible entity set.
– The classifier or catalogue can be used many times.

Fig. 2. Classification Example

Example: Fig. 2 shows an example of idiom Classification. The Religion Clas-

sifier is defined with the ID Key and description atribute minimally, each new
religion may be freely added freely. Each Person entity must have only one reli-
gion. It is posible create a Religion No religion in order to avoid null references.
4 Idioms: a Pattern language for database modelling

3.2 Idiom Reflexive

Is an ideal idiom to model hierarchical structures of the UoD, it is defined with

the analogy of the fan (persons who loves)famous (persons adored) relationships.
One side at the relationships is defined by the famous role and the other side
with the set of fans entities.
The pattern template for Idiom Reflexive is shown in Fig. 3

Fig. 3. Reflexive Idiom

Semantics: Some entities W are relationships with other any entity W (may
be the same!).
Characteristics: – The hierarchical structure do not have a deep limit.
– This idioms build a nice tree structure, the root node is the top famous,
the intermediate nodes are medium famous, and the leaf nodes are the
crazy fans.

Fig. 4. Reflexive Example

Example: The example shown in Fig. 4 models the hierarchical relationships

between folder entities, some play the famous role (top of the directory structure)
and the others play the fans role (loves to the top folder). Null references can be
avoided given itself reference to top folder entity.
 Idioms: a Pattern language for database modelling 5

3.3 Idiom Historical Reflexive

Similar to the idiom Reflexive, with historical capabilities. It has a Historician

entity with registration capabilities of historical relationships. In combination
with the classification Idiom, the power of the historician entity may be dramat-
ically increased.
The pattern template for Idiom Reflexive is shown in Fig. 5

Fig. 5. Historical Reflexive Idiom

Semantics: Some entities X are related together and the history of those re-
lations is kept in Y. However is posible register the history of relationships
between the actors.
Characteristics: – The Y entity type may be classiffied, and in this way has
the freedom to register anythings.
– The Historician Entity type Y, is made for X entities only.

Fig. 6. Historical Reflexive Example

6 Idioms: a Pattern language for database modelling

The example, see Fig. 6, shows the relationship between employee entities,
one employee plays the monitor role and the other plays the monitored role.
The temporal attribute (period of monitoring) is for the historic registration
capability.

3.4 IS-A or Generalization-Specialization

This idiom is very useful to design generalization - specialization relationships.

It does not have the inheritance stigma, for this reason multiple specialization
or multiple generalization is elegantly solved.
The pattern template for Idiom is-a is shown in Fig. 7

Fig. 7. IS-A Generalization-Specialiation Idiom

Semantics: N is an specialization of M or M is an generalization of N.

Characteristics: – Allows multiple specialization.
– Allows multiple generalizations.

Example: Fig. 8 shows one example of multiple specialization and multiple gen-
eralization at the same time. The Document entity type has multiple specializa-
tion relationships and the Memorandum entity type has multiple generalization
relationships.

4 A language formed by Idioms

The central problem with ER is the excesive freedom given to the designer in
order to represent any aspects of the UoD with a reduced language. This ER
language has high representation power. This freedom results in many represen-
tations of the same observation, some of which may be correct. The different
representations will be relative to the point of view of each designer.
 Idioms: a Pattern language for database modelling 7

Fig. 8. IS-A Generalization-Specialization Example

From the idioms perspective, not all ER constructions are correct, can have
some ER constructions with wrong semantics, i.e. many to many relationships. In
the case of many to many relationships, the observer tries to model the associate
cardinality to the relationship instead of the relationship itself. Another example
is the case to model generalization or specialization relationships, it is frequent
the confusion between inheritance mechanism (from POO) with generalization
specialization concepts [5]. This problem is solved elegantly with the IS-A idiom.
Any other attempt to model generalization-specialization will not be accepted
in the idiom perspective.
If the modelling language is restricted to use just idioms, the result language
is an idiom language with well defined structures (in semantical and syntacti-
cal terms). Fortunately there is an idiom to model the different aspects of the
UoD [2], similar to the abstractions found in the OO paradigm. The discussion
of the surprising resemblance with OO abstractions will be delayed to the end
of the article.
The strategy to design the Idiom language is to build an extended language
starting from the native ER language, redefining and prunning some construc-
tions. The reference architecture is described in figure ??.

5 The Idiom Metamodel

The idiom metamodel restricts some ER constructions in such a way that only
idiom structures are accepted. The metamodel extends, redefines, and creates
some ER components. The ER model [11] will be the starting point. The meta-
model in figure 10 defines the reference model for native ER structures, its
components and its relationships. The metamodel is described in terms of UML
language [4].
8 Idioms: a Pattern language for database modelling

Fig. 9. Idiom Architecture

Fig. 10. ER Reference Metamodel

 Idioms: a Pattern language for database modelling 9

The idiom metamodel shown of figure 11 is an extension or specialization

from the ER metamodel. It requires some elements from this model and redefines
some of them as shown in figure 9.
The idiom metamodel defines two categories of entity types:
– first class entity types, are allowed to participate in other idioms with dif-
ferent roles, and
– second class entity types, are not allowed to participate with more than one
role.
This categorization defines the elements that allow idiom composition and are
useful to validate the correctness of a model (in terms of idioms).
The idiom metamodel defines the precise syntactical construction for each id-
iom at the catalogue, and the role of entities defining its semantical participation
in the idiom relationships.
The abstract syntax of each idiom is described in each class labeled with the
appropiate stereotype. The relationships with the EntityTypeFirstClass class de-
fine entity types with composition capabilities. The EntityTypeSecondClass class
defines terminal entity types or entity types without composition capabilities.
Some characteristics of the construction of the metamodel:
– Classifier entity types are typically second class.
– The relationships are bidirectional except for Reflexive and Classifier entity
types.
– All idiom structures avoid or control NULL references, may be needed in
Object-Relational mapping. Avoiding NULL references frees the program-
mer of exception handling produced by NULL references.
– In general terms, Master, Generalization and Classified entity types are re-
lated to Detail, Specialization and Classifier entity types respectively. This
visually recognizable characteristic is useful when validating or testing the
result model. Syntax checking of the idiom language model helps to validate
the ER model!

6 Designing with Idioms

The design with idioms is simple and fun. Every idiom defines qualities of the
relationships of the ER language: cardinality (both sides), dependency, roles and
mandatory/optionality (both sides). It helps the designer to concentrate to solve
the problem instead of paying attention to details.
Designing with idiom suggests a compositional approach, modeling observ-
able characteristics of the UoD by identifying the right idiom in the catalogue.
This compositional way is illustrated in the following section.

6.1 Example
In this section a full ER model is build from small observations. Each observa-
tion is translated to idiom language. Then all small fragments of ER model are
assembled by overlapping entities.
10 Idioms: a Pattern language for database modelling

Fig. 11. Idiom Metamodel

 Idioms: a Pattern language for database modelling 11

– UoD observation 1. There exists several types of work: part time work, full
time work, work by home, etc., which refer to activities or common tasks.
– idiom model 1. In figure 12:
1. Types of work is a clasiffier for activities
2. Types of work is a clasiffier for common tasks
By construction, Type of work is a candidate for second class entity type.

Fig. 12. Model of UoD observation 1

– UoD observation 2. Activities are sorted by its precedence order.

– idiom model 2. Reflexivity in activity entity type by precedence order. In
terms of ER idioms as shown in figure 13.

Fig. 13. Model of UoD observation 2

– UoD observation 3. Each Project has several activities. Activities do not

exist without a project.
– idiom model 3. Project is the master containing detail of activities. ER model
in figure 14.
12 Idioms: a Pattern language for database modelling

Fig. 14. Model of UoD observation 3

– UoD observation 4. People in the company are employees or residents.

– idiom model 4. In figure 15:
1. Employee is-a Person.
2. Resident is-a Person
By construction, a Person may have multiple specialization.

Fig. 15. Model of UoD observation 4

– UoD observation 5. Activities are assigned to employees.

– idiom model 5. Assignment of activities to employees modeled with compo-
sition as shown in figure 16.

– UoD observation 6. In a period of time, some Persons are monitored by other

Persons.
– idiom model 6. Some Persons are famous temporally by monitoring its fans.
See figure 17.

– UoD observation 7. Common tasks are assigned only to the residents.

– idiom model 7. Common task and residents in composition to produce as-
signment as illustrated in figure 18.
 Idioms: a Pattern language for database modelling 13

Fig. 16. Model of UoD observation 5

Fig. 17. Model of UoD observation 6

Fig. 18. Model of UoD observation 7

14 Idioms: a Pattern language for database modelling

Fig. 19. Final composed model

To conclude, the entire model is obtained by assembling and paste the small
pieces found with idioms as shown in figure 19.
Additionally, the entire model describes the relationships of Person entities
with its Person references, modeled by a master - detail idiom.
This process of composing ER models is surprisingly similar to design with
OO abstractions. By following this approach the designer can increment his self-
confidence, increasing dramatically the quality of the model and saving the time
to achieve it.

7 Refactoring with Idioms

Once defined the idiom structures of the idiom language, syntax checking could
be used find incorrect structures in the model. ER does not provide a way to
test the semantics of an isolated entity type or attributes.
It is possible to define a refactoring strategy with idioms based on syntax
checking and the semantic verification embed in the idiom. This testing is over
model fragments instead the isolated components. The refactoring process finds
incorrect structures or unfit pieces of the model recalling bad smells [14]. A great
advantage of this strategy is the possible refactoring process automation.
For instance: one of the most common bad smells is the “inheritance” struc-
tures (available in Oracle Designer, Power Designer and others) [5, 8] which solve
 Idioms: a Pattern language for database modelling 15

generalization or specialization relationships similar to OO abstractions, how-

ever the implementation of this “inheritance” structure does not fulfill the well
known normalization rules. The elegant solution to these bad smells is applying
the IS-A idiom instead of the “inheritance” structure.

8 Conclusions
The idioms give a style of design to database modeler, so that his work repre-
sents the central element in order to validate the model. The improvements in
the process are: saving time in the design process, quality of the model, better
navigability, flexibility and self-confidence of the designer.
The semantic qualities of the idioms allow the description in terms of the
functionality associated to each idiom in terms of standard and generalized op-
erations.

References
1. Erin McKean (Editor). The New Oxford American Dictionary, Second Edition. Ox-
ford University Press, 2005.
2. Juan Marcelo Flores and Pablo Azero. Re-Composición de Modelos ER con Id-
ioms. Septimas Jornadas Iberoamericanas de Ingenierı́a de Software e Ingenierı́a del
conocimiento (JIISIC), Guayaquil, Ecuador, February 2008.
3. Juan Marcelo Flores Soliz. Idioms en ER, Quintas Jornadas Iberoamericanas de In-
genierı́a de Software e Ingenierı́a del conocimiento (JIISIC), Puebla, Mexico, March
2006. http://memi.umss.edu.bo/idiomsER
4. Grady Booch, Ivar Jacobson and James Rumbaugh. The Unified Modeling Lan-
guage. Addison-Wesley,1998.
5. Paul Dorsey, Joseph Hudicka. Diseño de Bases de Datos con UML. Oracle Press,
1999.
6. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Design Patterns.
Addison-Wesley, 1995.
7. Roel Wieringa. Requirements Engineering: Frameworks for Understanding. Wiley,
1996.
8. Craig Larman. Applying UML and Patterns. Prentice-Hall, 2004.
9. Oracle Press. Oracle Designer-database Generator. OraclePress, 2001.
10. Ramez A. Elmasri, Shamkant B. Navathe. Fundamentos de Sistemas de Bases de
Datos, Tercera Edicion. Addison Wesley, 2002.
11. Peter Pin-Shan Chen. The Entity-Relationship Model - Toward a Unified View of
Data. ACM Transactions on DataBase Systems, Vol 1, N. 1, 1976.
12. Shamkant B. Navathe. Evolution of Data Modeling for Databases. Communications
of the ACM, Vol.35, N. 9, 1992.
13. Roel Wieringa. Design Methods for Reactive Systems: Yourdon, Statemate and
the UML. Morgan Kaufmann, 2003
14. Martin Fowler. Refactoring- Improving the design of existing code. Addison Wesley,
1999.
15. Martin Fowler. Analysis Patterns - Reusable Object Models. Addison-Wesley, 1999.
16. Martin Fowler. Patterns of enterprise application architecture. Addison Wesley,
2002.
16 Idioms: a Pattern language for database modelling

17. Martin Fowler. Patterns. IEEE Software magazine, March/April 2003.

18. F. Buschman, R. Meunier, H. Rohnert, P. Sommerland, M. Stal. A System Of
Patterns. John Wiley & Sons, 1996.
19. James Coplien. Advanced C++ Programming Styles and Idioms. Addison-Wesley
Professional, 1996.
20. Ken Henderson. The Guru’s Guide to SQL Server, Stored procedures, xml, and
html. Addison-Wesley, 2002.