Using Relational Databases in the Engineering Repository Systems

Total Page:16

File Type:pdf, Size:1020Kb

Using Relational Databases in the Engineering Repository Systems USING RELATIONAL DATABASES IN THE ENGINEERING REPOSITORY SYSTEMS Erki Eessaar Department of Informatics, Tallinn University of Technology, Raja 15,12618 Tallinn, Estonia Keywords: Relational data model, Object-relational data model, Repository, Metamodeling. Abstract: Repository system can be built on top of the database management system (DBMS). DBMSs that use relational data model are usually not considered powerful enough for this purpose. In this paper, we analyze these claims and conclude that they are caused by the shortages of SQL standard and inadequate implementations of the relational model in the current DBMSs. Problems that are presented in the paper make usage of the DBMSs in the repository systems more difficult. This paper also explains that relational system that follows the rules of the Third Manifesto is suitable for creating repository system and presents possible design alternatives. 1 INTRODUCTION technologies in one data model is ROSE (Hardwick & Spooner, 1989) that is experimental data "A repository is a shared database of information management system for the interactive engineering about the engineered artifacts." (Bernstein, 1998) applications. Bernstein (2003) envisions that object- These artifacts can be software engineering artifacts relational systems are good platform for the model like models and patterns. Repository system contains management systems. ORIENT (Zhang et al., 2001) a repository manager and a repository (database) and SFB-501 Reuse Repository (Mahnke & Ritter, (Bernstein, 1998). Bernstein (1998) explains that 2002) are examples of the repository systems that repository manager provides services for modeling, use a commercial ORDBMS. ORDBMS in this case retrieving, and managing objects in the repository is a system which uses a database language that and therefore must offer functions of the Database conforms to SQL:1999 or later standard. Management System (DBMS) and also additional Relational data model was introduced by Codd functions. (1970) and has been extensively studied since then. The repository manager uses custom-built data One notable revision is the Third Manifesto (Date & manager or general-purpose DBMS in order to Darwen, 2000), (Date, 2003). Relational model and manage artifacts. System Arcadia (Taylor et al., relational systems are often criticized because they 1988) is an example of the system that uses custom- are arguably not powerful enough for the repository built object manager. Omega (Linton, 1984), The C system. Information Abstraction System (Chen et al., 1990), In this work we show that these problems are PARSE (Gray, 1997) and CommonKADS repository caused by the shortages of SQL standard and (Allsop et al., 2002) are examples of the repository systems that implement that standard. There exists systems that use a Relational DBMS (RDBMS). analyzes of SQL and comparisons of it with the RDBMS in this case is a system which uses a proposals of the Third Manifesto (Date & Darwen, database language that conforms to SQL:1992 2000), (Pascal, 2000), (Date, 2003) but they don't standard or is even earlier relational database discuss problems in the context of specific language. Object-Oriented DBMSs have been often application areas like engineering repositories. seen as a suitable platform for building repository In this paper we also explain how a relational systems (Bernstein, 1998) (Dittrich et al., 2000). system that follows the rules of the Third Manifesto Object-Relational DBMS (ORDBMS) combine can be used in order to create a repository database. features of the relational data model and object- In this case we wouldn't have problems that are oriented programming languages. An example of an present in current ORDBMSs. early attempt to combine relational and object 30 Eessaar E. (2006). USING RELATIONAL DATABASES IN THE ENGINEERING REPOSITORY SYSTEMS. In Proceedings of the Eighth International Conference on Enterprise Information Systems - DISI, pages 30-37 DOI: 10.5220/0002455800300037 Copyright c SciTePress USING RELATIONAL DATABASES IN THE ENGINEERING REPOSITORY SYSTEMS We adopt definition (Date, 2003) according to Table 1: Problems of the relational model. which the relational data model consists of an Problem Authors who mention extensible collection of scalar types, relation type that problem generators, facilities for defining relation variables It is not powerful, Hardwick and Spooner (relvars) of such types, assignment operations for flexible and expressive (1989),Constantopoulos assigning relation values (relations) to relvars and an enough. et al. (1995). extensible collection of generic relational operators Fragmentation. Data Liu et al. (1996), for deriving relation values from other relation about the object is in Gray (1997). values. the different relations. The rest of the paper is organised as follows. Performance problems Hardwick and Spooner Section 2 contains results of the literature study due to fragmentation. (1989), Gray (1997). about the problems of the relational model and Lack of powerful type Taylor et al. (1988), RDBMSs that hamper their usage in the repository system. Miguel et al. (1990), systems. Section 3 explains how a RDBMS which Emmerich et al. (1992), data model follows the rules of the Third Manifesto Liu et al. (1996), can be used in a repository system. Nowadays much Gray (1997). attention is paid to the ORDBMSs. Section 4 Poor support to data Hardwick (1984), describes problems of the current ORDBMSs that that represents graph Miguel et al. (1990), make their usage in the repository systems more structures. Lack of Katz (1990), difficult. Section 5 summarizes and points to the facilities for making Emmerich et al. (1992), future work with the current topic. queries based on such Gray (1997), data including finding Lange et al. (2001). transitive closure. 2 LITERATURE STUDY Inappropriate Hardwick and Spooner transaction models for (1989) Next we classify problems of the relational model the engineering and RDBMSs based on the literature study and systems. analyze these problems in terms of the Third Detailed semantics of Engle (2003) Manifesto. Researchers and developers often present the relvars have to be these problems as reasons why relational database is captured outside the not the best choice to use in the engineering systems. relational system. Table 1 presents problems of the relational model Lack of possibility to Zhang et al. (2001) that have been identified by the researchers. preserve semantics of Some issues that have been raised by the the relationships. researchers are actually orthogonal to the relational model. We adopt the approach taken by Date and Fragmentation increases complexity to the user Darwen (2000, p. 21): "The question as to what data of database according to Gray (1997). Virtual relvars types are supported is orthogonal to the question of (views) help to overcome this problem in the system support for the relational model." Even Codd (1970) that follows the rules of the Third Manifesto. View- acknowledged possibility of the nonsimple domains defining expression can join values of relvars that which permitted values are relations. One reason contain information about the object. It can have why he argues for eliminating nonsimple domains is relation-valued attributes which values are that they require more complicated data structures at calculated using relational operator GROUP that the storage level than simple domains. Transaction provides relation "nest" capability (Date & Darwen, model is also orthogonal to the relational model. 2000). Gray (1997) writes that fragmentation may Date and Darwen (2000) have requirement for cause performance problems. But "performance is nested transactions in the section of the Other fundamentally an implementation issue, not a model Orthogonal Prescriptions. issue." (Date, 2005) Hierarchic and networked information can be Semantics of the relvar that is understandable to represented relationally (Pascal, 2000, chap. 7) Issue the human user is specified by the external predicate of making queries based on data that represents of the relvar (Date & Darwen, 2000, p. 179). It could graph structure is addressed in the Third Manifesto. well be recorded in the catalogue of the database that Relational Model Very Strong Suggestion no. 6 must be part of the database that it describes. (Date & Darwen, 2000, p. 213) requires that Semantics of the data that is understandable to the relational language should provide shorthand for system is represented by the internal predicate of the expressing generalized transitive closure query. relvar (Date, 2003, p. 262). Constraints to the value 31 ICEIS 2006 - DATABASES AND INFORMATION SYSTEMS INTEGRATION of relvar specify internal predicate. Therefore 3 USING RELATIONAL DBMS IN RDBMS should provide means for defining tuple- THE REPOSITORY SYSTEM attribute-, relvar- and database constraints. Semantics of the relationship determine constraints that are used in order to implement this A repository system permits management of artifacts relationship and operations that may be performed that are created using some language that belongs to with the data that participate in the relationships the set of its supported languages. Repository system (Zhang et al., 2001). Relational language may should allow to add new languages to this set in contain shorthand statements that cause creation of order to be most useful. Abstract syntax of the the database objects that implement particular type language can be specified using metamodel
Recommended publications
  • Further Normalization of the Data Base Relational Model
    FURTHER NORMALIZATION OF THE DATA BASE RELATIONAL MODEL E. F. Codd IBM Research Laboratory San Jose, California ABSTRACT: In an earlier paper, the author proposed a relational model of data as a basis for protecting users of formatted data systems from the potentially disruptive changes in data representation caused by growth in the data base and changes in traffic. A first normal form for the time-varying collection of relations was introduced. In this paper, second and third normal forms are defined with the objective of making the collection of relations easier to understand and control, simpler to operate upon, and more informative to the casual user. The question "Can application programs be kept in a viable state when data base relations are restructured?" is discussed briefly and it is conjectured that third normal form will significantly extend the life expectancy of appli- cation programs. Fu909umxk7) August 31,197l Information technolow (IR, Documentetion, etc.) 1. 1. Introduction 1.1 Objectives of Normalization In an earlier paper [l] the author proposed a relational model of data as a basis for protecting users of formatted data systems from the potentially disruptive changes in data representation caused by growth in the variety of data types in the data base and by statistical changes in the transaction or request traffic. Using this model, both the appli- cation programmer and the interactive user view the data base as a time-varying collection of normalized relations of assorted degrees. Definitions of these terms and of the basic relational operations of projection and natural join are given in the Appendix.
    [Show full text]
  • Sixth Normal Form
    3 I January 2015 www.ijraset.com Volume 3 Issue I, January 2015 ISSN: 2321-9653 International Journal for Research in Applied Science & Engineering Technology (IJRASET) Sixth Normal Form Neha1, Sanjeev Kumar2 1M.Tech, 2Assistant Professor, Department of CSE, Shri Balwant College of Engineering &Technology, DCRUST University Abstract – Sixth Normal Form (6NF) is a term used in relational database theory by Christopher Date to describe databases which decompose relational variables to irreducible elements. While this form may be unimportant for non-temporal data, it is certainly important when maintaining data containing temporal variables of a point-in-time or interval nature. With the advent of Data Warehousing 2.0 (DW 2.0), there is now an increased emphasis on using fully-temporalized databases in the context of data warehousing, in particular with next generation approaches such as Anchor Modeling . In this paper, we will explore the concepts of temporal data, 6NF conceptual database models, and their relationship with DW 2.0. Further, we will also evaluate Anchor Modeling as a conceptual design method in which to capture temporal data. Using these concepts, we will indicate a path forward for evaluating a possible translation of 6NF-compliant data into an eXtensible Markup Language (XML) Schema for the purpose of describing and presenting such data to disparate systems in a structured format suitable for data exchange. Keywords :, 6NF,SQL,DKNF,XML,Semantic data change, Valid Time, Transaction Time, DFM I. INTRODUCTION Normalization is the process of restructuring the logical data model of a database to eliminate redundancy, organize data efficiently and reduce repeating data and to reduce the potential for anomalies during data operations.
    [Show full text]
  • Translating Data Between Xml Schema and 6Nf Conceptual Models
    Georgia Southern University Digital Commons@Georgia Southern Electronic Theses and Dissertations Graduate Studies, Jack N. Averitt College of Spring 2012 Translating Data Between Xml Schema and 6Nf Conceptual Models Curtis Maitland Knowles Follow this and additional works at: https://digitalcommons.georgiasouthern.edu/etd Recommended Citation Knowles, Curtis Maitland, "Translating Data Between Xml Schema and 6Nf Conceptual Models" (2012). Electronic Theses and Dissertations. 688. https://digitalcommons.georgiasouthern.edu/etd/688 This thesis (open access) is brought to you for free and open access by the Graduate Studies, Jack N. Averitt College of at Digital Commons@Georgia Southern. It has been accepted for inclusion in Electronic Theses and Dissertations by an authorized administrator of Digital Commons@Georgia Southern. For more information, please contact [email protected]. 1 TRANSLATING DATA BETWEEN XML SCHEMA AND 6NF CONCEPTUAL MODELS by CURTIS M. KNOWLES (Under the Direction of Vladan Jovanovic) ABSTRACT Sixth Normal Form (6NF) is a term used in relational database theory by Christopher Date to describe databases which decompose relational variables to irreducible elements. While this form may be unimportant for non-temporal data, it is certainly important for data containing temporal variables of a point-in-time or interval nature. With the advent of Data Warehousing 2.0 (DW 2.0), there is now an increased emphasis on using fully-temporalized databases in the context of data warehousing, in particular with approaches such as the Anchor Model and Data Vault. In this work, we will explore the concepts of temporal data, 6NF conceptual database models, and their relationship with DW 2.0. Further, we will evaluate the Anchor Model and Data Vault as design methods in which to capture temporal data.
    [Show full text]
  • CONNOLLY R CAROLYN E. BEGG a Practical Approach to Design
    •.••:.... ••:••.•; ••••• •:• ; •.•••:•. • ..• .: . • •• ••••:..• CONNOLLY r CAROLYN E. BEGG 1VERS1TYOF PA1SL К m A Practical Approach to Design, Implementation, and Management Third Edition Contents Preface xxxv Part 1 Background Chapter 1 Introduction to Databases 1.1 Introduction 1.2 Traditional File-Based Systems D 1.2.1 File-Based Approach 7 1.2.2 Limitations of the File-Based Approach 12 1.3 Database Approach 14 1.3.1 The Database 14 1.3.2 The Database Management System (DBMS) 16 1.3.3 Components of the DBMS Environment 18 1.3.4 Database Design: The Paradigm Shift 20 1.4 Roles in the Database Environment 21 1.4.1 Data and Database Administrators 21 1.4.2 Database Designers 22 1.4.3 Application Developers 23 1.4.4 End-Users 23 1.5 History of Database Management Systems 23 1.6 Advantages and Disadvantages of DBMSs 25 Chapter Summary 30 Review Questions 31 Exercises 31 Chapter 2 Database Environment 33 2.1 The Three-Level ANSI-SPARC Architecture 34 2.1.1 External Level 35 2.1.2 Conceptual Level 36 2.1.3 Internal Level 36 xii Contents 2.1.4 Schemas, Mappings, and Instances 37 2.1.5 Data Independence 38 2.2 Database Languages 40 2.2.1 The Data Definition Language (DDL) 40 2.2.2 The Data Manipulation Language (DML) 41 2.2.3 Fourth-Generation Languages (4GL) 42 2.3 Data Models and Conceptual Modeling 43 2.3.1 Object-Based Data Models 44 2.3.2 Record-Based Data Models 45 2.3.3 Physical Data Models 47 2.3.4 Conceptual Modeling 47 2.4 Functions of a DBMS 48 2.5 Components of a DBMS 53 2.6 Multi-User DBMS Architectures 56 2.6.1 Teleprocessing
    [Show full text]
  • Applied Mathematics for Database Professionals
    7451FM.qxd 5/17/07 10:41 AM Page i Applied Mathematics for Database Professionals Lex de Haan and Toon Koppelaars 7451FM.qxd 5/17/07 10:41 AM Page ii Applied Mathematics for Database Professionals Copyright © 2007 by Lex de Haan and Toon Koppelaars All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13: 978-1-59059-745-3 ISBN-10: 1-59059-745-1 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editor: Jonathan Gennick Technical Reviewers: Chris Date, Cary Millsap Editorial Board: Steve Anglin, Ewan Buckingham, Gary Cornell, Jonathan Gennick, Jason Gilmore, Jonathan Hassell, Chris Mills, Matthew Moodie, Jeffrey Pepper, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh Project Manager: Tracy Brown Collins Copy Edit Manager: Nicole Flores Copy Editor: Susannah Davidson Pfalzer Assistant Production Director: Kari Brooks-Copony Production Editor: Kelly Winquist Compositor: Dina Quan Proofreader: April Eddy Indexer: Brenda Miller Artist: April Milne Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013.
    [Show full text]
  • Impedance Mismatch Is Not an “Objects Vs. Relations” Problem. (DRAFT) Evgeniy Grigoriev [email protected]
    Impedance Mismatch is not an “Objects vs. Relations” Problem. (DRAFT) Evgeniy Grigoriev [email protected] The problem of impedance mismatch between applications written in OO languages and relational DB is not a problem of discrepancy between object-oriented and relational approaches themselves. Its real causes can be found in usual implementation of the ОО approach. Direct comparison of the two approaches cannot be used as a base for the conclusion that they are discrepant or mismatched. Experimental proof of the absence of contradiction between the object-oriented paradigm and the relational data model is also presented in the paper. " -Look, your worship, - said Sancho, - what we see there are not giants but windmills, and what seem to be their arms are the sails…" Miguel de Cervantes, Don Quixote In physics, the term “impedance mismatch” (IM) may be found in fields dedicated to wave processes, e.g., in acoustics or in electrodynamics. It is used to denote an effect that appears when a wave is transferred from one medium to another [IMP]. If the impedances of the two media are different ("mismatching"), the wave energy will be reflected or absorbed, so it is difficult for the wave to cross the border between the media. A similar effect occurs when one attempts to organise the data exchange between programs written with object-oriented (OO) language and relational (R) DBMS, which is referred to as “object-relational impedance mismatch” [Copeland, Ambler]. Existing difficulties are usually explained with the discrepancy in general properties of the object program and relational DB. For example, in [Ambler1], it is defined as, “The difference resulting from the fact that relational theory is based on relationships between tuples (records) that are queried, where as the object paradigm is based on relationships between objects that are traversed“.
    [Show full text]
  • On the Logic of SQL Nulls
    On the Logic of SQL Nulls Enrico Franconi and Sergio Tessaris Free University of Bozen-Bolzano, Italy lastname @inf.unibz.it Abstract The logic of nulls in databases has been subject of invest- igation since their introduction in Codd's Relational Model, which is the foundation of the SQL standard. In the logic based approaches to modelling relational databases proposed so far, nulls are considered as representing unknown values. Such existential semantics fails to capture the behaviour of the SQL standard. We show that, according to Codd's Relational Model, a SQL null value represents a non-existing value; as a consequence no indeterminacy is introduced by SQL null values. In this paper we introduce an extension of first-order logic accounting for predicates with missing arguments. We show that the domain inde- pendent fragment of this logic is equivalent to Codd's relational algebra with SQL nulls. Moreover, we prove a faithful encoding of the logic into standard first-order logic, so that we can employ classical deduction ma- chinery. 1 Relational Databases and SQL Null Values Consider a database instance with null values over the relational schema fR=2g, and a SQL query asking for the tuples in R being equal to themselves: 1 2 1 | 2 SELECT * FROM R ---+--- R : a b WHERE R.1 = R.1 AND R.2 = R.2 ; ) a | b b N (1 row) Figure 1. In SQL, the query above returns the table R if and only if the table R does not have any null value, otherwise it returns just the tuples not containing a null value, i.e., in this case only the first tuple ha; bi.
    [Show full text]
  • Projektovanie Databázových Systémov - Úvod Zoznámenie Sa
    Projektovanie databázových systémov - úvod Zoznámenie sa Prednášky a cvičenia: Jaroslav Lach Belastingdienst Centrum voor ICT, Apeldoorn Service team Fysieke media verwerking Senior software engineer Kontakt: [email protected] 0031 55 528 1272 Skype: Jaroslav Lach Zoznámenie sa II. Cvičenia a konzultácie: Jan Fikejz Organizačné záleţitosti Týţdenný kurz Prednášky a cvičenia Výuka pondelok aţ piatok 8:00 aţ 9:00 12:30 aţ 13:30 9:15 aţ 10:15 13:45 aţ 14:45 10:30 aţ 11:30 15:00 aţ 16:00 Semestrálny projekt Konzultácie Zápočet a skúška Študijná literatúra: povinná Jim Arlow, Ila Neustadt: UML 2 a unifikovaný proces vývoje aplikací. Computer Press 2007 Meilir Page-Jones: Základy objektově orientovaného návrhu v UML. Grada 2001 Motivácia • Nainštalovaním prvej verzie softwarového produktu u zákazníka sa všetko len začína.... • Chyby a problémy (hlavne pri prvých verziách) • Zmeny a rozšírenia • Ako písať software tak, aby tento aspekt bol zvládnuteľný • Aby sa dali analyzovať problémy • S minimálnym rizikom implementovať zmeny a rozšírenia Študijná literatúra: doporučená Kraval: Objektové modelování pomocí UML v praxi, díl 1, PDF e-kniha, leden 2005 Dokumentácia procesu UP (dostupná na www.eclipse.org/epf) http://www.tonymarston.net/php-mysql/database- design.html • H. Darwen & C.J. Date: Databases, types and the relational model (The third Manifesto) • C. J. Date: An Introduction to Database Systems. Addison Wesley; 8th edition 2003 Študijná literatúra: doporučená II. • Matiaško,Karol: Databázové systémy. - 1. vyd. - Ţilina
    [Show full text]
  • Carnegie Mellon Univ. Dept. of Computer Science 15-415 - Database Applications
    Faloutsos CMU SCS 15-415 CMU SCS Carnegie Mellon Univ. Dept. of Computer Science 15-415 - Database Applications C. Faloutsos Lecture#1: Introduction CMU SCS Outline • Introduction to DBMSs • The Entity Relationship model • The Relational Model • SQL: the commercial query language • DB design: FD, 3NF, BCNF • indexing, q-opt • concurrency control & recovery • advanced topics (data mining, multimedia) Faloutsos CMU SCS 15-415 2 CMU SCS We’ll learn: • What are RDBMS – when to use them – how to model data with them – how to store and retrieve information – how to search quickly for information • Internals of an RDBMS: indexing, transactions Faloutsos CMU SCS 15-415 3 1 Faloutsos CMU SCS 15-415 CMU SCS We’ll learn (cnt’d) • Advanced topics – multimedia indexing (how to find similar, eg., images) – data mining (how to find patterns in data) Faloutsos CMU SCS 15-415 4 CMU SCS Administrivia • Weights: as announced Course grade 30% 30% 40% Sum= ASGN MT Final exam 100% 5% 5% ASGN1 … ASGN8 Faloutsos CMU SCS 15-415 5 CMU SCS Administrivia - II • FYI: ASGN3 and ASGN7 are heavy • Late policy: 4 ‘slip days’ • Exams: no aids allowed, except – 1 page with your notes (both sides) for MT – 2 such pages for Final Faloutsos CMU SCS 15-415 6 2 Faloutsos CMU SCS 15-415 CMU SCS Detailed outline • Introduction – Motivating example – How do DBMSs work? DDL, DML, views. – Fundamental concepts – DBMS users – Overall system architecture – Conclusions Faloutsos CMU SCS 15-415 7 CMU SCS What is the goal of rel. DBMSs Faloutsos CMU SCS 15-415 8 CMU SCS What is the goal of rel.
    [Show full text]
  • A Mapping of SPARQL Onto Conventional SQL
    A Mapping of SPARQL Onto Conventional SQL Eric Prud'hommeaux, Alexandre Bertails World Wide Web Consortium (W3C) {eric,bertails}@w3.org http://www.w3.org/ Abstract. This paper documents a semantics for expressing relational data as an RDF graph [RDF] and an algebra for mapping SPARQL SELECT queries over that RDF to SQL queries over the original rela- tional data. The RDF graph, called the stem graph, is constructed from the relational structure and a URI identifier called a stem URI. The al- gebra specifies a function taking a stem URI, a relational schema and a SPARQL query over the corresponding stem graph, and emitting a re- lational query, which, when executed over the relational data, produces the same solutions at the SPARQL query executed over the stem graph. Relational databases exposed on the Semantic Web can be queried with SPARQL with the same performance as with SQL. Key words: Semantic Web, SPARQL, SQL, RDF 1 Introduction Motivations to bridge SPARQL and SQL abound: science, technology and busi- ness need to integrate more and more diverse data sources; the far majority of data that we expect machines to interpret are in relational databases; SQL fed- eration extensions like SchemaSQL [SSQL] don't place these databases in the more expressive Semantic Web; etc. These points have motivated many devel- opers to produce mapping tools, but robustness and performance have been a problem, in part because of a lack of a standard semantics for this mapping. In order to draw the desired investment in the Semantic Web, we need to match the performance of conventional relational databases.
    [Show full text]
  • To Be Is to Be a Value of a Variable by C. J. Date with Apologies To
    T o B e I s t o B e a Value of a Variable by C. J. Date with apologies to George Boolos and his book Logic, Logic, and Logic (I cribbed the title of this paper from an essay in that book) If we want things to stay as they are, things will have to change —Giuseppe di Lampedusa "Change" is scientific, "progress" is ethical; change is indubitable, whereas progress is a matter of controversy —Bertrand Russell July 17th, 2006 ABSTRACT In reference [1], two writers, referred to herein as Critics A and B, criticize The Third Manifesto for its support for relation variables and relational assignment. This paper is a response to that criticism. Readers are expected to be familiar with the following concepts and terminology: A relation variable (relvar for short) is a variable whose permitted values are relation values (relations for short). Relational assignment is an operation by which some relation r is assigned to some relvar R. Reference [14] explains these notions in detail, using a language called Tutorial D as a basis for examples. Why we want relvars Critic A's objections Critic B's objections Multiple assignment Database values and variables Concluding remarks Copyright © C. J. Date 2006 page 1 References WHY WE WANT RELVARS As noted in the abstract, the term relvar is short for relation variable. It was coined by Hugh Darwen and myself in reference [9], the first published version of The Third Manifesto; Codd's first papers on the relational model [3-4] used the term time-varying relation instead, but "time- varying relations" are just relvars by another name.
    [Show full text]
  • CS253:HACD.2 Temporal Data and the Relational Model Notes Keyed to Slides
    File: CS253-TDATRM-Notes.doc Printed at: 16:32 on Wednesday, 20 October, 2010 CS253:HACD.2 Temporal Data and The Relational Model Notes keyed to slides 1. Cover slide The chapter in Date first appeared in his 7th edition, as Chapter 22, but the chapter was quite heavily revised for the 8th edition. There is an unfortunate typographical error on page 744. In the first bulleted paragraph (“The expanded form ...”), delete the last three words, “defined as follows:”. 2. Temporal Data and The Relational Model In particular, none of the leading SQL vendors (IBM, Oracle, Microsoft, Sybase ...) have implemented SQL extensions to solve the problems we describe. There was significant interest for a time in the second half of the 1990s, when an incomplete working draft for an international standard for such extensions was produced by the SQL standards committee. However, the project was abandoned when support for XML documents in SQL databases became a higher priority to the industry than temporal extensions. (Some people question the industry’s priorities!) MighTyD In the academic year 2005-6 a team of computer science undergraduates at Warwick University, for their final-year project, made the beginnings of a prototype implementation of Tutorial D with some of the temporal extensions taught in CS253. They call their product MighTyD. Like Rel, it is written in Java. It is available for free download at http://sourceforge.net/projects/mightyd. If by any chance you might be interested in continuing the work on MighTyD, please arrange a meeting with me to discuss ideas. 3. The Book’s Aims Imagine, for example, a database from which nothing is ever deleted and in which every record is somehow timestamped to show the time at which it arrived and, if its information is no longer current, the time at which it was superseded or deleted.
    [Show full text]