Conceptual Schema Diagrams Research Articles

Representing Part-Whole Relations in Conceptual Modeling: An Empirical Evaluation

The part-of construct is a fundamental element of many conceptual modeling grammars that is used to associate one thing (a component) with another thing (a composite). Substantive theoretical issues surrounding the part-of construct remain to be resolved, however. For instance, contrary to widespread claims, some researchers now argue the relationship between components and composites is not always transitive. Moreover, how the part-of construct should be represented in a conceptual schema diagram remains a contentious issue. Some analysts argue composites should be represented as a relationship or association. Others argue they should be represented as an entity. In this paper we use an ontological theory to support our arguments that composites should be represented as entities and not relationships or associations. We also describe an experiment that we undertook to test whether representing composites as relationships or entities enables users to understand a domain better. Our results support our arguments that using entities to represent composites enables users to better understand a domain.

TRANSLATING RELATIONAL SCHEMA WITH CONSTRAINTS INTO XML SCHEMA

With XML adopted as the technology trend on the Internet, and with investment in the current relational database systems, companies must convert their relational data into XML documents for data transmission on the Internet. In the process, to preserve the users' relational data requirements of data constraints into the converted XML documents, we must define a meaningful root element for each XML document. The construction of an XML document is based on the root element and its relevant elements. The root element can be selected from a relational entity table in the existing relational database, which depends on the requirements to present the business behind. The relevant elements are mapped from the related entities, based on the navigability of the chosen entity. The derived root and relevant elements can form a Data Type Definition Graph (DTD-graph) of an XML conceptual schema diagram which can be mapped into a Data Type Definition (DTD) of an XML schema. The result is a translated XML schema with semantic constraints transferred from a relational conceptual schema of an Extended Entity Relationship (EER) model. The data conversion from relational data to the XML documents can be done after the schema translation. The relational data are loaded into XML documents according to the translated DTD.

Metaschemas for ER, ORM and UML Data Models

This paper provides metaschemas for some of the main database modeling notations used in industry. Two Entity Relationship (ER) notations (Information Engineering, and Barker) are examined in detail, as well as Object Role Modeling (ORM) conceptual schema diagrams. The discussion of optionality, cardinality and multiplicity is widened to include Unified Modeling Language (UML) class diagrams. Issues addressed in the metamodel analysis include the normalization impact of non-derived constraints on derived associations, the influence of orthogonality on language transparency, and trade-offs between simplicity and expressibility. To facilitate comparision, the same modeling notation is used to display each metaschema. For this purpose, ORM is used because of its greater expressibility and clarity.

Should Optional Properties Be Used in Conceptual Modelling? A Theory and Three Empirical Tests

An important feature of some conceptual modelling grammars is the features they provide to allow database designers to show real-world things may or may not possess a particular attribute or relationship. In the entity-relationship model, for example, the fact that a thing may not possess an attribute can be represented by using a special symbol to indicate that the attribute is optional. Similarly, the fact that a thing may or may not be involved in a relationship can be represented by showing the minimum cardinality of the relationship as zero. Whether these practices should be followed, however, is a contentious issue. An alternative approach is to eliminate optional attributes and relationships from conceptual schema diagrams by using subtypes that have only mandatory attributes and relationships. In this paper, we first present a theory that led us to predict that optional attributes and relationships should be used in conceptual schema diagrams only when users of the diagrams require a surface-level understanding of the domain being represented by the diagrams. When users require a deep-level understanding, however, optional attributes and relationships should not be used because they undermine users' abilities to grasp important domain semantics. We describe three experiments which we then undertook to test our predictions. The results of the experiments support our predictions.

Conceptual schemas with abstractions making flat conceptual schemas more comprehensible

Flat graphical, conceptual modeling techniques are widely accepted as visually effective ways in which to specify and communicate the conceptual data requirements of an information system. Conceptual schema diagrams provide modelers with a picture of the salient structures underlying the modeled universe of discourse, in a form that can readily be understood by and communicated to users, programmers and managers. When complexity and size of applications increase, however, the success of these techniques in terms of comprehensibility and communicability deteriorates rapidly. This paper proposes a method to offset this deterioration, by adding abstraction layers to flat conceptual schemas. We present an algorithm to recursively derive higher levels of abstraction from a given (flat) conceptual schema. The driving force of this algorithm is a hierarchy of conceptual importance among the elements of the universe of discourse.

Are Attributes Entities? A Study of Database Designers' Memory Structures

A longstanding debate in the data modeling literature pertains to whether the grammars used to generate conceptual schemas should sustain a distinction between entities and attributes. The grammars used to generate entity-relationship diagrams and object-oriented conceptual models, for example, provide separate constructs for representing entities and attributes. The grammars used to generate binary data models, however, provide only a single construct for representing both entities and attributes. To sharpen the focus of the debate, a multi-trial free-recall experiment was conducted with database designers who had been trained primarily in a binary conceptual schema design methodology. In the experiment, the designers were first shown conceptual schema diagrams based on a binary model. The designers were then asked to recall the diagrams. Throughout their training as designers, they had been admonished to eschew any distinction between entities and attributes. Moreover, the diagrams they were shown in the experiment did not make a distinction between entities and attributes. Their recall protocols seemed to show, however, that they were considering some elements of the diagrams to be entities and others to be attributes. Their memory structures appear to reflect, therefore, that they perceive entities and attributes to be two distinct constructs.

An analytical evaluation of NIAM'S grammar for conceptual schema diagrams

Abstract. Nijssen's Information Analysis Method (niam) provides a powerful grammar for generating conceptual schema diagrams. We evaluate this grammar systematically using an ontological model proposed by Bunge, Wand and Weber. Our analysis shows niam'Sgrammar has many desirable features. Nevertheless, we conclude it is deficient in three respects. First, we argue that construct overload occurs in niam'Sgrammar. Multiple real‐world features are represented by the same grammatical construct in niam. As a result, we predict users of niam will sometimes be confused about which characteristics of the real world are being represented by niam'Soverloaded grammatical constructs. Second, we argue that construct redundancy occurs in niam. Multiple grammatical constructs can be used to represent the same real‐world feature. As a result, we predict users of niam will choose to employ only one of the grammatical constructs provided to represent a particular real‐world feature. Alternatively, they will equivocate in their choice of a grammatical construct and thus undermine their effectiveness and efficiency in using niam. Third, we argue niam has construct deficit. Some ontological constructs have no corresponding grammatical construct in niam. As a result, we predict users of niam will employ other grammars to represent real‐world features that cannot be represented by niam'Sgrammar. We predict that using multiple grammars to represent real‐world features, however, will evoke other problems associated with attaining consistent representations among the scripts generated via the grammars.

On the Relevance of Classification Theory to Database Design

This paper discusses a stream of research which applies some classification principles to database design. We present a data model explicitly based on classification research. Subsequently, we examine implications of th'e model for flexibly handling diverse views of the class requirements for a domain, for developing methods and techniques to design databases, and for implementing data structures which support dynamic classification. The paper concludes by proposing that applying classification research to database research can lead to advances in the former, as well as in the latter. A widely used technique for data modeling, the Entity-Relationship (ER) model, uses diagrams to express data requirements in terms of classes (termed entity types in ER jargon), relationships among classes, and attributes, which jointly are referred to as a conceptual schema. Conceptual schema diagrams provide the basis for designing the files that will store the data. The primary implementation technologies for databases today are relational and object-orienteddatabase systems, both of which are also based on organizing data according to a fixed schema of classes. In a relational database system, each file (called a relation) is defined in terms of a numberoffields Data modeling and database design have emerged as a collection of techniques for determining, verifying, and codifying data requirements for various information systems applications or uses. One key element of data modeling is identifying the classes or categories of things about which data are to be kept, which attributes of those things must be kept track of, and what relationships exist among instances of different classes. For example, an application to maintain course registration records at a university might identify relevant classes of things such as students, instructors, sections, and rooms. Relevant attributes of might include name, address, date of birth, year, and major. Important relationships among classes might include: students enroll in'courses, insttuctors teach courses, and courses have multiple sections.