Entity-Relationship Modeling

Transcription

1 Entity-Relationship Modeling

2 Springer-Verlag Berlin Heidelberg GmbH

3 Bernhard Thalheim Entity-Relationship Modeling Foundations of Database Technology With 160 Figures Springer

4 Professor Dr. Bernhard Thalheim Department of Computer Science Brandenburg University of Technology at Cottbus Universitatsplatz Cottbus, Germany Library of Congress Cataloging-in-Publication Data Thalheim, B. (Bernhard), Entity-relationship modeling: foundations of database technology/ Bernhard Thalheim. p. em. Includes bibliographical references and index. ISBN ISBN (ebook) DOI / Database management. 2. Database design. I. Title QA76.9.D3 T dc ACM Computing Classification (1998): H.l-2, D.2-3, G.2.0, F.4.1, F.l.l, 1.2.4, H.4.0, K ISBN This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag Berlin Heidelberg GmbH. Violations are liable for prosecution under the German Copyright Law. Springer-Verlag Berlin Heidelberg 2000 Originally published by Springer-Verlag Berlin Heidelberg New York in 2000 Softcover reprint of the hardcover 1st edition 2000 The use of general descriptive names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Cover Design: Kiinkel + Lopka, Werbeagentur, Heidelberg Typesetting: Camera ready by the author SPIN Printed on acid-free paper- 45/3142SR

5 Preface What you inherit from your father, Ean1 it anew before you call it yours. What does not serve you is a heavy burden, What issues from the moment is alone of use. Goethe, Faust I, Night 1 Before a database system can be used the system needs to be designed. Database design is the process of determining the organization of a database application. For database design the structural, semantic and operational information of an application is acquired and used in order to derive efficient management of the database. In addition, the organizational information needs to be considered. This design task is similar to task solving. Given a task, we develop a language for representation of the task and for describing the derived solution. We also know the complexity of the language and of the solution space. This knowledge of the complexity of the language can be used to search for simpler solutions. In this case, optimization of both the task and the solution derivation is necessary. This optimization can be based on structures which are easy to operate. For a long time, database theory dealt with such structural prerequisites for optimization. One vehicle for deriving simple structures is normalization. However, this is not sufficient. Since a database system is used by a variety of users who have a diverging set of operational requirements, the design of efficient database systems becomes very difficult. The variety of users implies that the database structure, operations and maintenance should be simple and feasible for 'normal' users. Especially for large and complex databases, the development of understandable structures becomes the crucial factor with regard to later use of the database. Therefore, a database model which is understandable and comprehensible has to be developed. The relational database model was the first powerful and theoretically based model. However, in the relational model, complex database schemes were not feasible and were seldom understandable. In addition, the representation of semantic information required high abstraction abilities. Understanding this situation, Peter P. S. Chen developed the entity-relationship (ER) model. The latter is based on a simple graphical representation. Using this diagrammatic technique, even complex 1 Translations by Peter Salm (Faust I, Bantam Books, 1962) and Philip Wayne (Faust II, Penguin Books Ltd, 1959).

6 VI Preface schemes can be understood. This model has been so successful that it is used at present in many branches of computer science, even in software engineering. Many different extensions and dialects have been developed although the theoretical basis of the ER model was not well developed. Different semantics have been used in different books, articles, and systems and there are even books with changing semantics. Therefore, there is an urgent need for an overview of the theoretical background of the ER model. This book makes an attempt to bridge the gap between the ER theory and the ER application. The main aim is to provide a theoretical basis for database design. This basis is used for the development of an effective methodology. Database design methodologies should facilitate database modeling, effectively support database processing and transform the conceptual schema of the database to a high-performance database schema in the database management system (DBMS) currently in use. Since the late 1970's, various methodologies for database design have been introduced. Most of them, however, are dependent on the knowledge, comprehension and experience of the database analyst and his or her knowledge of normalization theory. The proposed methodology does not require the user to understand the theory, the implementational restrictions or the programming problems in order to design a database scheme. Thus even an inexperienced designer could create a database design successfully using this method. The ER model is extended to the Higher-order Entity-Relationship Model (HERM) by relationships of higher degrees and relationships of relationships. The latter model is used for high-level database design systems. It supports an efficient translation to nested relational, relational, network and hierarchical schemes. The model has the expressive power of semantic models and possesses the simplicity of the ER model. Cottbus, January 2000 Bernhard Thalheim

7 Acknowledgements Dedicated to Klaus f1 Konrad f1 Valeria. f3 (B.T.) This book is a record of research and discussions over the last ten years. It is distilled from courses taught at universities and during conferences and summer schools. It was enjoyable to write, particularly because it was a joint effort with many interesting people, who I would now like to thank. Firstly, I thank my family; without their uncritical support nothing would have been possible. I have benefited enormously from the comments made by early readers at the universities of Budapest, Cottbus, Dresden, Hamburg, Kuwait, Moscow and Rostock. I distinctly thank: Sabah Al-Fedaghi, Peter Bachmann, Catriel Beeri, Peter P. Chen, Janos Demetrovics, Klaus-Dieter Schewe, Joachim W. Schmidt. I would also like to thank my assistants and students in Cottbus, Dresden, Kuwait and Rostock who read various portions of the manuscript at various stages and questioned the proposed solutions. There is not enough space to thank all the colleagues who supported me by providing additional information, sending (unpublished) manuscripts and guiding me through the mass of database literature. Most of them are 'only' cited. I am very thankful to the ER, MFDBS and ICDT communities. Many insights discussed here can be traced back to discussions with colleagues from these communities. I am thankful to Edith Buchholz, Karla Kersten, Samantha Lane, Wendy Ran (Springer) and David Reinhardt for proofreading. Lastly, I thank my editors Hans Wossner and Ingeborg Mayer for putting up with me. Somehow they endured with patience, diligence, and the hundreds and hundreds of days this book to get from prospectus to publication. Human beings do their best work by iteration, and this book was no exception. The first version of it was ready in This was the time the extensive Springer support began. I am very grateful for this support, many helpful suggestions, comments, corrections, criticism and assistance that significantly helped shape the contents of this work. The book will never be finished, just published. With regard to success I would like to thank to readers for acquiring this compendium. I hope that it is useful to you and that you enjoy it as much as I enjoyed writing it. It can

8 VIII Acknowledgements be used in undergraduate, graduate and research courses. In order to support teaching additional material including slides can be found at: jwww.informatik.tu-cottbus.de/ "'thalheim/herm.htm The compendium includes research on the ER model, on extensions of the ER model, on syntax, semantics and pragmatics of database modeling. The extensions allow an integrated development and modeling of database applications. Thus, this model allows the specification of structures, behavior and interaction. The achievements of research on ER modeling are given in a survey aiming in completeness and correctness. Please address any comments (and, therefore, force me to write another more correct and complete version) to: informatik.tu-cottbus.de

9 Contents Notation Conventions XI 1. Introduction Database Design Overview of the Book Advantages of the Approach The Database Design Process Databases and Design Design Quality Objects To Be Modeled The Entity-Relationship Model The Structural Model Problems Extending the Entity-Relationship Model Overview of Extensions Entity and Relationship Types Representing Structures of Applications Through HERM Diagrams Benefits of the HERM Approach Extending the Model To Make It More Meaningful Integrity Constraints Logical Foundations of Semantics Generalizing Relational Constraints Entity-Relationship Constraints Graphical Constraints Incompleteness During Semantics Acquisition Constraints in Models with Richer Type Systems Operations ER Languages The HERM Algebra Query-By-Example The Logical Calculus Query Forms Behavior Models

10 X Contents 7. Behavior Modeling Dynamic and Temporal Integrity Constraints Dynamic Semantics Axiomatic Approach to Behavior Modeling Enforcing Integrity Constraints Soft Constraints and Deontic Logics Applying the Theory Identification in ER Schemata Classifying Binary, Is-A and Subobject Relationship Types Views Equivalence in HERM Schemes Normalization The Database Design Process in HERM Database Design Methodologies Classical Database Design Methodologies The HERM Methodology Based on Modular Design Codesign of Structures, Functions and Interaction Natural Language-Based Database Design Computer-Aided Database Design The Translation of HERM Schemes The Relational Representation The Network and Hierarchical Representations Reverse Engineering of Translated Schemes Open Problems References List of Figures Index

11 Notation Conventions Sufficient words have been exchanged; Now at least I want to see some action. While you are turning pretty compliments, Some useful thing should be afoot. Goethe, Faust I, Prelude in the Theater To begin with we need some special symbols. Symbols such as V, 3, /\,..., ~. := are used the sense defined in Discrete Mathematics and Mathematical Logic. Sets are denoted by braces {.. }, bags or multisets by {1... ~ and comprehensions by KI---~1- Throughout the text we use the following conventions: All types are in singular. Types (attribute, relationship and entity) are represented by slanted fonts in examples. Notions are highlighted by emphasized fonts. Remarks or references are highlighted by italic type styles. Relational and SQL names are denoted in capital letters. Code is denoted by the typewriter type style. Types and classes are strongly distinguished. Entity, relationship and cluster types are denoted by capital letters. Their corresponding classes are denoted by the same letters with superscript C (for class). Last capital letters are used for types or sets. The first capital letters will usually be attributes. The symbol E is reserved for entity types. C is also used for cluster types. The symbols a, (3, '"'f,... will always be formulas. The symbols E, ifj,... are sets of formulas. The symbol r is also a calculus. Since names should express also the meaning intended we use the following shortcuts: Instead of delimiters we use for type names lower and upper case, i.e. the attribute name TypeOfPayment is used for the attribute which represents the type of payment for purchases in Figure The name of an attribute can be cut into several subsequences in figures. We use numbering only by necessity. For this reason, tables are not numbered if they illustrate the text. Figures are numbered if they are used in other places as well.

12 XII Notation Conventions We distinguish between schemes and schemata. A schema is used for specification of structure. A schema is extended by constraints to the scheme. For the definition of a database we use the three-layer approach: a data scheme is defined for basic data; the database schema is used for the specification of the database structure; the database on a database scheme is based on the structure given by the scheme and obeys the constraints defined for the scheme. The schema and the scheme can be extended by operations and dynamic integrity constraints. Spacing is used in three modes: normal for the begin of the next paragraph, extended with one additional line for the beginning of a subpart and small for the beginning of examples and for delimiting subparagraphes. References are ordered by the key. The five-letter key is generated on the basis of the family names of author(s) and the publication year. If there are less than three authors then we use more than one letter from the (first) author's name. If two references cannot be distinguished on this basis then we add small letters or accents to the key. For instance, the authors T. Halpin and H. Proper published a paper in Thus, we use the key [HaP95]. J. L. Hainaut published a paper in The key is [Hai91]. If he published another referenced paper in the same year then the key is [Hai91x] for some lower case letter x depending on the order of the papers. Since only three letters are used clashes are possible. They are also resolved by lower case letters, e.g., [Alt96a] for Alter and [Alt96b] for Altus. Lower case letters are used for second or third letters in the family name. Capital letters are used for the first letter of the family name. Thus, we distinguish between [Gol89] (for Goldberg) and [GoL92] (for Goh and Ling). For ordering we do not distinguish between lower letters and capital letters. Thus, the item order [BaR84], [BaR86], [Bar92a] is the correct one, as well as [BrS80], [BRS82], [BrS94].