Entity Types Derived by Symbol-Generating Rules - Semantic Scholar

Entity Types Derived by Symbol-Generating Rules Jordi Cabot, Antoni Olivé and Ernest Teniente Universitat Politècnica de Catalunya Dept. Llenguatges i Sistemes Informàtics Jordi Girona 1-3, 08034 Barcelona (Catalonia) e-mail: [jcabot|olive|teniente]@lsi.upc.es Abstract. We review the definition of entity types derived by symbolgenerating rules. These types appear frequently in conceptual schemas. However, up to now they have received very little attention in the field of conceptual modeling of information systems. Most conceptual modeling languages, like the UML and ORM, do not allow their formal definition. In this paper, we propose a new method for the definition of entity types derived by symbol-generating rules. Our method is based on the fact that these types can always be expressed as the result of the reification of a derived relationship type. Many languages, like the UML and ORM, allow defining derived relationship types and, at the same time, provide support for reification. Using our method, these languages can directly deal with those derived entity types.

1. Introduction A fundamental principle that governs the contents of conceptual schemas is the wellknown “100 Percent” (or completeness) principle, which states that “All relevant general static and dynamic aspects, i.e. all rules, laws, etc., of the universe of discourse should be described in the conceptual schema” [6]. The relevant “aspects” include, among others, derived entity and relationship types and their derivation rules. Many conceptual modeling languages provide constructs for the definition of those rules. Most derived entity types are defined by what may be called “symbol-preserving” rules. The name comes from the object-oriented database field, in which a distinction is made between “object-preserving” and “object-generating” views. The former are those that only extract objects from existing classes, while the latter are those that create new objects [3]. For example, if Person is an entity type derived by the union of Man and Woman, then the derivation rule is “symbol preserving” because the symbols in the information base (IB) that denote people are the same as those that denote men or women. The rule does not create new symbols in the IB. However, there are many derived entity types whose rule is not “symbolpreserving”, but “symbol-generating”. A typical example may be PurchaseOrder. Assuming that an information system must generate automatically a purchase order for a product to a vendor when the product satisfies some condition (quantity on hand

-1-

below reorder level, etc.) then PurchaseOrder is derived, and its rule is ”symbolgenerating”. The symbols in the IB that denote purchase orders are quite distinct from those used to denote products or vendors. The rule must “invent” symbols for the purchase orders it derives. Most conceptual modeling languages, including the UML [11, 9] and ORM [5], do not allow defining entity types derived by symbol-generating rules. In these languages, designers must define those types as base ones since the rules cannot be defined declaratively in a single place of the schema. For this reason, the designer must determine which external events (operations, transactions) may change the value of the condition (from true to false, or the other way around) and ensure that their effects include the generation or deletion of the corresponding entities. In the previous example, the events that may change the value of the condition are those that reduce the quantity on hand, increase the reorder level, etc. The effects of these events must include checking whether the resulting state changes the value of the condition and, if it is so, generating the corresponding instances of PurchaseOrder. One of the few conceptual modeling languages that deal with symbol-preserving and symbol-generating rules is ERCLog [13,14], a logic language based on ERC+ [12]. In ERCLog, both entity and relationship types can be derived by the two kinds of rules. The rules are distinguished by syntactical criteria. The main contribution of this paper is a new method that allows defining derived entity types with symbol-generating rules, in languages that do not admit such rules. The method can be used in any conceptual modeling language that allows defining derived relationship types, and that allows the reification of relationship types [8]. Both the UML and ORM meet these requirements: associations and attributes can be derived, their derivation rules can be defined easily in a particular language (OCL in the UML, ConQuer in ORM) and association classes are the construct used to reify associations. The rationale of our method is that a derived entity type, whose derivation rule is symbol-generating, can always be defined as the result of the reification of a derived relationship type. Therefore, if a language allows defining derived relationship types and their reification, then –using our method- the own language (without any extension) allows also defining derived entity types with symbol-generating rules. As a consequence, there is no need to develop nor to extend a graphical tool to support them since they can be defined already in any CASE tool available for these languages. The main advantage of our method is its simplicity since it is based on the use of reification, a classical and well-known conceptual modeling construct, and it does not require to extend a language with a new construct (like a new kind of derivation rule). The structure of the paper is as follows. The next section introduces basic concepts and notation used throughout the paper. Section 3, based on [10], defines, in logic, the concept of entity type derived by a symbol-generating rule. Section 4 reviews, also in the logic language, the concept of reification and shows that any entity type derived by a symbol-generating rule can be expressed as the reification of a relationship type. Section 5 applies this result to the UML and ORM languages. Finally, we present our conclusions and point out future work in Section 6.

-2-

2. Basic Concepts We assume that entities and relationships are instances of their types at particular time points [2], which are expressed in a common base time unit such as second or day. We make this assumption for the sake of generality, but our work is also applicable when a temporal view is not needed. We represent by E(e,t) the fact entity e is instance of entity type E at time t. For instance, Employee(Marta,D1) means that Marta is an instance of Employee at time D1 (day in this case). The population of E at t is defined as the set of entities that are instances of E at t. A relationship type has a name and a set of n participants, with n ≥ 2. A participant is an entity type that plays a certain role in the relationship type. R(p1:E1,...,pn:En) denotes a relationship type named R with entity type participants E1,...,En playing the roles p1,...,pn, respectively. We say that R(p1:E1,...,pn:En) is the schema of the relationship type and that p1:E1, ..., pn:En are their participants. The order of the participants in the schema is irrelevant. Two different participants may be of the same entity type, but two different participants may not have the same role. When the role name is omitted, it is assumed to be the same as the corresponding entity type. We represent by R(e1,...,en,t) the fact that entities e1,...,en participate in an instance of R at time t. The referential integrity constraints associated with R guarantee that e1, ..., en are instance of their corresponding types E1,...,En.

3. Entity Types Derived by Symbol-generating Rules This section formalizes entity types derived by symbol-generating rules in temporal conceptual models of information systems and extends our work presented in [10] in two different directions. First, we compare entity types derived by symbol-generating rules with object-generating views in object-oriented databases. Second, we state the inconveniences of not specifying explicitly such derived entity types. We introduce entity types derived by symbol-generating rules by means of an example aimed at issuing automatically purchase orders for products. Assume that we have entity types Product and PurchaseOrder. Clearly, the symbols that denote purchase orders are different from those that denote products. Moreover, entity type PurchaseOrder can be derived from Product and Date if we assume that one purchase order is generated at a date when the quantity on hand of the product is below its reorder level at some moment of the date. To keep the example simple, we assume that all purchase orders are generated in this way. Then, PurchaseOrder can be formally defined by means of the symbol-generating rule: ∃!o (PurchaseOrder(o,t) ∧ HasPurchase(o,p,t) ∧ IssuedAt(o,d,t)) ↔ Product(p,t) ∧ QuantityOnHand(p,nq,t) ∧ ReorderLevel(p,nr,t) ∧ nq