现在位置: >

Modeling Collections in UML and ORM

[This paper first appeared in Halpin, T.A. 2000, ‘Modeling collections in UML and ORM’, Proc. EMMSAD’00: 5th

Modeling Collections in UML and ORM

Terry Halpin

Microsoft Corporation, USA

email: TerryHa@http://doc.xuehai.net

[This paper first appeared in Halpin, T.A. 2000, ‘Modeling collections in UML and ORM’, Proc. EMMSAD’00: 5th IFIP WG8.1 Int. Workshop on Evaluation of Modeling Methods in Systems Analysis and Design, ed. K. Siau, Kista, Sweden (June), and is reproduced here by permission.]

Abstract: Collection types such as sets, bags and arrays have been used as data structures in

both traditional and object oriented programming. Although sets were used as record

components in early database work, this practice was largely discontinued with the

widespread adoption of relational databases. Object-relational and object databases once

again allow database designers to embed collections as database fields. Should collections be

specified directly on the conceptual schema, as mapping annotations to the conceptual

schema, or only on the logical database schema? This paper discusses the pros and cons of

different approaches to modeling collections. Overall it favors the annotation approach,

whereby collection types are specified as adornments to the pure conceptual schema to guide

the mapping process from conceptual to lower levels. The ideas are illustrated using notations

from both object-oriented (Unified Modeling Language) and fact-oriented (Object-Role

Modeling) approaches.

1 INTRODUCTION

Information systems may be modeled at various levels. For analysis purposes, a conceptual schema of the application domain should first be developed. At this stage, modelers communicate with domain experts in their own terms, making it easier to get a clear, correct and complete picture of the requirements. Once the business model is understood, it can be implemented by mapping the conceptual schema to logical, physical, and external schemas. During this mapping process, further implementation details may be added. For database applications, the mapping from a conceptual schema to a logical database schema often involves a transformation in data structures. For example, a conceptual association may map to a relational table attribute. Though commonly used in programming, the practice of using collection types (e.g. sets, bags and arrays) as record components in database schemas largely disappeared with the widespread adoption of relational databases, where each table column is based on an atomic domain. However, the recent emergence of object-relational and object databases once again allows collections as database fields.

How should collection types be specified within the conceptual analysis and logical design of data? Some approaches use collections directly within the conceptual schema, some specify them as annotations to the conceptual schema, while others relegate them to the logical schema. This paper examines these alternative approaches by way of examples, highlighting the conceptual and pragmatic issues underlying such choices. Its focus is on how and where to specify collection types in the modeling process, not on the advisability or otherwise of using collection types in a database implementation. The ideas are illustrated using notations from both object-oriented (Unified Modeling Language (UML)) and fact-oriented (Object-Role Modeling (ORM)) approaches. The discussion is also relevant to some extended Entity Relationship (ER) approaches.

Procedures for mapping from conceptual models to logical models are readily available (e.g. [3, 11, 13, 27]). For relational database systems, denormalization and fragmentation are often used to improve performance. Object-relational and object databases allow further denormalization, since table fields may contain collections rather than just atomic values. In practice, these performance-based design options are usually specified on the logical or internal model, and often the conceptual model is ignored after these changes are made. This practice can lead to weak coupling or inconsistencies between the conceptual and lower level models, making it difficult to leverage the conceptual model to facilitate schema evolution as the business changes, or to provide a conceptual means of accessing the data. One solution to this problem is to include collection types within the conceptual schema itself, where these collections map directly to

相关文档
相关主题
返回顶部
热门文档