The Current Positioning of the Nosql Database

Total Page:16

File Type:pdf, Size:1020Kb

The Current Positioning of the Nosql Database THE CURRENT POSITIONING OF THE NOSQL DATABASE SHOULD NOSQL DATABASES SUBSTITUTE OR COMPLEMENT TRADITIONAL RELATIONAL DATABASES AND HOW DOES THIS HAVE IMPLICATIONS FOR UNIVERSITY EDUCATION GIVEN THE PRACTICAL USE? Word count: 31.527 Ewoud Stroom Student number: 01409310 Supervisor: Prof. Dr. Geert Poels Master’s Dissertation submitted to obtain the degree of: Master in Business Engineering: Data Analytics Academic year: 2018 – 2019 Deze pagina is niet beschikbaar omdat ze persoonsgegevens bevat. Universiteitsbibliotheek Gent, 2021. This page is not available because it contains personal information. Ghent Universit , Librar , 2021. Preface This Master’s Dissertation was written in function of obtaining the degree of Master of Science in Business Engineering at Ghent University. I set the subject regarding the current positioning of the NoSQL database technology because of my growing interest in this emerging trend. The subject was first proposed by my promotor, Prof. Dr. Geert Poels, who emphasized how highly topical discussions about NoSQL databases are. In the current literature, there is no real consensus about the positioning of NoSQL in the database landscape. This challenge encouraged me to analyse this subject and to create and contribute my own insights and expertise to the world. In addition, it was an opportunity for me to use my obtained knowledge during 5 years of education to its full potential. On the one hand, the experience gained to conduct a correct qualitative and quantitative research could be linked with using programs such as SPSS and Nvivo in practice. On the other hand, the content of the subject could be linked with my specialization in Data Analytics, and because it was highly topical, I was able to get insights about the current trends in today’s world of data. I would also like to thank a few people in particular. First, I want to thank my promotor, Prof. Dr. Geert Poels, to give me the opportunity to work on this project and to steer me in the right direction whenever I was facing some difficulties. The most challenging aspect was for me interpreting the results of the quantitative research and finding a correct way to analyse the impact of this subject on university education, but thanks to the insights and feedback from my promotor, this has come to a right end. Furthermore, I would like to thank the interviewees for their time and cooperation, and in addition, my friends and acquaintances in helping to find the interviewees and bringing me in contact with them. Finally, I would also like to thank my family and friends for their support during some long days and nights. Ewoud Stroom Ghent, 4th of June 2019 I Abstract Nowadays, data is everything. The world is built on digitally stored information which is derived from data and without realising it, it is ingrained in today’s culture and influences everyone’s private and professional lives. This dependency on data requires a reliable way of storing, managing, and retrieving all kinds of data, and this is where the technology of databases is practised. Trends in the database landscape, like the development of the Internet and the occurrence of Big Data, cloud computing, social media… these days, caused issues for the traditional relational databases and resulted in the rise of a hype, called NoSQL databases. The choice of organizations which database type to use in a particular situation is essential, and therefore it is important to evaluate both database types and gain insight in the positioning of the NoSQL databases in comparison with the relational databases, which means defining them as complements or substitutes. This insight is exactly were the focus of this thesis lies. To obtain this insight, a qualitative study was conducted among 6 employees of different organizations, to discover possible patterns in practice. An additional quantitative study was performed in 2 Flemish universities to measure the current level of education about this subject. This resulted in a well-founded comparison of NoSQL and relational databases with implications for university education. Keywords: database, relational, NoSQL, complements, Big Data, cloud computing II Table of contents PREFACE I ABSTRACT II TABLE OF CONTENTS III LIST OF ABBREVIATIONS VI LIST OF FIGURES AND TABLES VI 1. INTRODUCTION 1 2. LITERATURE STUDY 3 2.1. RELATIONAL DATABASES 3 2.1.1. PROBLEM 3 2.1.2. SOLUTION: THE RELATIONAL DATABASE 4 2.1.2.1. Origin: the relational model of E.F. Codd 4 2.1.2.1.1. OPTIMIZING DATA INDEPENDENCY 4 2.1.2.1.2. INTERPRETATION OF THE RELATIONAL VIEW 5 2.1.2.1.3. LIMITATIONS OF CODD’S MODEL 6 2.1.2.2. Timeline: from Codd’s relational view to the current relational database 7 2.1.2.2.1. THE ‘70S 7 2.1.2.2.2. THE ‘80S 8 2.1.2.2.3. THE ‘90S AND EARLY 2000S 8 2.1.2.3. General definition 9 2.1.3. ADVANTAGES 12 2.1.3.1. Data independence 12 2.1.3.2. Acid properties 13 2.1.3.3. Simplicity 14 2.1.3.4. Security 14 2.1.3.5. Multiple access 14 2.2. NOSQL DATABASES 16 2.2.1. PROBLEM 16 2.2.1.1. Increasing volumes of data 16 2.2.1.2. Rise of unstructured data 17 2.2.1.3. Scalability 18 2.2.1.4. Connectivity 19 2.2.1.5. Cost 19 2.2.2. SOLUTION: NOSQL DATABASES 20 2.2.2.1. Initial rise 20 2.2.2.2. General definition 21 2.2.2.2.1. DEFINITION 22 III 2.2.2.2.2. NOSQL: NO SQL – NOT ONLY SQL – NON-RELATIONAL 24 2.2.2.2.3. TYPES 25 2.2.2.2.3.1. Key-value store databases 25 2.2.2.2.3.2. Document store databases 26 2.2.2.2.3.3. Column-oriented databases 27 2.2.2.2.3.4. Graph databases 29 2.2.3. ADVANTAGES 30 2.2.3.1. Big Data handling 30 2.2.3.2. Scalability 30 2.2.3.3. Continuous availability 31 2.2.3.4. Open-source 31 2.2.3.5. Cloud computing 32 2.2.3.6. Suitable architectures 32 2.3. COMPARISON OF RELATIONAL & NOSQL DATABASES 33 2.4. TRENDS IN THE DATABASE TECHNOLOGY 35 2.4.1. THE NOSQL ‘HYPE’ 35 2.4.2. CURRENT POSITIONING 36 2.5. CONCLUSION LITERATURE STUDY 37 3. METHODOLOGY 39 3.1. RESEARCH QUESTION 39 3.2. RESEARCH FRAMEWORK 40 3.3. RESEARCH SCOPE 41 3.4. RESEARCH DESIGN 42 3.4.1. QUALITATIVE RESEARCH 43 3.4.2. QUANTITATIVE RESEARCH 43 3.5. RESEARCH INSTRUMENTS 44 3.5.1. INTERVIEW AS AN INSTRUMENT 44 3.5.2. RATING SCALE AS AN INSTRUMENT 45 3.6. DATA COLLECTION 47 3.6.1. LITERATURE STUDY 47 3.6.2. EMPIRICAL RESEARCH 47 3.6.2.1. Interview research 47 3.6.2.1.1. DATA COLLECTION PLAN 47 3.6.2.1.2. SAMPLE 48 3.6.2.1.2.1. Sampling method 48 3.6.2.1.2.2. Sample size 50 3.6.2.2. Study guide research 51 3.6.2.2.1. DATA COLLECTION PLAN 51 3.6.2.2.2. SAMPLE 53 3.6.2.2.2.1. Sampling method 53 3.6.2.2.2.2. Sample size 54 3.7. DATA ANALYSIS 54 3.7.1. ANALYSIS OF THE INTERVIEWS 54 3.7.2. ANALYSIS OF THE STUDY GUIDES 56 3.8. DATA RESULTS COMPARED 62 3.9. VALIDITY AND RELIABILITY 62 4. RESULTS 64 4.1. INTERVIEW RESEARCH 64 4.1.1. CHARACTERISTICS OF THE USED DATABASE 64 IV 4.1.2. CHARACTERISTICS OF THE DATABASE TECHNOLOGY 65 4.1.3. UNIVERSITY IMPLICATIONS 67 4.1.4. OPINION ABOUT THE DATABASE TECHNOLOGY 67 4.1.4.1. Feeling about databases 68 4.1.4.2. Importance of the database type 69 4.1.5. ACQUIRED INSIGHTS 71 4.1.5.1. The link between the importance and the overall feeling 71 4.1.5.2. The link between timing and the way of obtaining and maintaining 72 4.1.5.3. The link between the positioning of the DB technology and the importance 73 4.1.5.4. Differences according to the type of employee 74 4.2. STUDY GUIDE RESEARCH 75 4.2.1. CHARACTERISTICS OF THE COURSES 75 4.2.1.1. Descriptive statistics 75 4.2.1.2. Statistical validation 81 4.2.2. INFLUENCES ON THE CHARACTERISTICS OF THE COURSES 82 4.2.2.1. Descriptive statistics 82 4.2.2.2. Statistical validation 85 5. DISCUSSION 87 5.1. DISCUSSION EMERGING FROM THE RESEARCH & IMPLICATIONS 87 5.2. LIMITATIONS OF THE RESEARCH 90 5.3. SUGGESTIONS FOR FURTHER RESEARCH 91 6. CONCLUSION 92 REFERENCES 93 APPENDICES 97 A.1 INTERVIEWING GUIDE 97 A.2 CHECKLIST WITH KEYWORDS 98 A.3 SPSS RESULTS 99 V List of abbreviations DB: database DBMS: database management system RDBMS: relational database management system SQL: Structured Query Language IDC: International Data Corporation ER: entity relationship List of figures and tables Figures FIGURE 2.1. OVERVIEW OF THE LITERATURE STUDY 3 FIGURE 2.2. EXAMPLE OF A RELATIONAL MODEL EXPLAINED WITH THE CONCEPTS 10 FIGURE 2.3. EXAMPLE OF THE WORKING OF A DBMS 11 FIGURE 2.4. SCALABLE OF DATA SIZE FROM 2007 TO 2010 (TAURO, ARAVINDH, & SHREEHARSHA, 2012) 17 FIGURE 2.5. DIFFERENCE BETWEEN STRUCTURED DATA AND UNSTRUCTURED 17 FIGURE 2.6. GROWTH OF INFORMATION CONNECTEDNESS (TAURO, ARAVINDH, & SHREEHARSHA, 2012) 19 FIGURE 2.7. EXAMPLE OF A DOCUMENT STORE DATABASE 27 FIGURE 2.8.
Recommended publications
  • SQL from Wikipedia, the Free Encyclopedia Jump To: Navigation
    SQL From Wikipedia, the free encyclopedia Jump to: navigation, search This article is about the database language. For the airport with IATA code SQL, see San Carlos Airport. SQL Paradigm Multi-paradigm Appeared in 1974 Designed by Donald D. Chamberlin Raymond F. Boyce Developer IBM Stable release SQL:2008 (2008) Typing discipline Static, strong Major implementations Many Dialects SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008 Influenced by Datalog Influenced Agena, CQL, LINQ, Windows PowerShell OS Cross-platform SQL (officially pronounced /ˌɛskjuːˈɛl/ like "S-Q-L" but is often pronounced / ˈsiːkwəl/ like "Sequel"),[1] often referred to as Structured Query Language,[2] [3] is a database computer language designed for managing data in relational database management systems (RDBMS), and originally based upon relational algebra. Its scope includes data insert, query, update and delete, schema creation and modification, and data access control. SQL was one of the first languages for Edgar F. Codd's relational model in his influential 1970 paper, "A Relational Model of Data for Large Shared Data Banks"[4] and became the most widely used language for relational databases.[2][5] Contents [hide] * 1 History * 2 Language elements o 2.1 Queries + 2.1.1 Null and three-valued logic (3VL) o 2.2 Data manipulation o 2.3 Transaction controls o 2.4 Data definition o 2.5 Data types + 2.5.1 Character strings + 2.5.2 Bit strings + 2.5.3 Numbers + 2.5.4 Date and time o 2.6 Data control o 2.7 Procedural extensions * 3 Criticisms of SQL o 3.1 Cross-vendor portability * 4 Standardization o 4.1 Standard structure * 5 Alternatives to SQL * 6 See also * 7 References * 8 External links [edit] History SQL was developed at IBM by Donald D.
    [Show full text]
  • DATABASE and KNOWLEDGE-BASE SYSTEMS VOLUME I: CLASSICAL DATABASE SYSTEMS Jeffrey D
    PRINCIPLES OF DATABASE AND KNOWLEDGE-BASE SYSTEMS VOLUME I: CLASSICAL DATABASE SYSTEMS Jeffrey D. Ullman STANFORD UNIVERSITY COMPUTER SCIENCE PRESS TABLE OF CONTENTS Chapter 1: Databases, Object Bases, and Knowledge Bases 1.1: The Capabilities of a DBMS 2 1.2: Basic Database System Terminology 7 1.3: Database Languages 12 1.4: Modern Database System Applications 18 1.5: Object-base Systems 21 1.6: Knowledge-base Systems 23 1.7: History and Perspective 28 Bibliographie Notes 29 Chapter 2: Data Models for Database Systems 32 2.1: Data Models 32 2.2: The Entity-relationship Model 34 2.3: The Relational Data Model 43 2.4: Operations in the Relational Data Model 53 2.5: The Network Data Model 65 2.6: The Hierarchical Data Model 72 2.7: An Object-Oriented Model 82 Exercises 87 Bibliographie Notes 94 Chapter 3: Logic as a Data Model 96 3.1: The Meaning of Logical Rules 96 3.2: The Datalog Data Model 100 3.3: Evaluating Nonrecursive Rules 106 3.4: Computing the Meaning of Recursive Rules 115 3.5: Incremental Evaluation of Least Fixed Points 124 3.6: Negations in Rule Bodies 128 3.7: Relational Algebra and Logic 139 3.8: Relational Calculus 145 3.9: Tuple Relational Calculus 156 3.10: The Closed World Assumption 161 Exercises 164 Bibliographie Notes 171 VIII TABLE OF CONTENTS Chapter 4: Relational Query Languages 174 4.1: General Remarks Regarding Query Languages 174 4.2: ISBL: A "Pure" Relational Algebra Language 177 4.3: QUEL: A Tuple Relational Calculus Language 185 4.4: Query-by-Example: A DRC Language 195 4.5: Data Definition in QBE 207 4.6:
    [Show full text]
  • Datalog Educational System V4.2 User's Manual
    Universidad Complutense de Madrid Datalog Educational System Datalog Educational System V4.2 User’s Manual Fernando Sáenz-Pérez Grupo de Programación Declarativa (GPD) Departamento de Ingeniería del Software e Inteligencia Artificial (DISIA) Universidad Complutense de Madrid (UCM) September, 25th, 2016 Fernando Sáenz-Pérez 1/341 Universidad Complutense de Madrid Datalog Educational System Copyright (C) 2004-2016 Fernando Sáenz-Pérez Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in Appendix A, in the section entitled " Documentation License ". Fernando Sáenz-Pérez 2/341 Universidad Complutense de Madrid Datalog Educational System Contents 1. Introduction........................................................................................................................... 9 1.1 Novel Extensions in DES ......................................................................................... 10 1.2 Highlights for the Current Version ........................................................................ 11 1.3 Features of DES in Short .......................................................................................... 11 1.4 Future Enhancements............................................................................................... 14 1.5 Related Work............................................................................................................
    [Show full text]
  • A Query Facility for Allegro Redacted for Privacy Abstract Approved: Earl F
    AN ABSTRACT OF THE THESIS OF Richard Goodemoot for the degree of Master of Science in Computer Science presented on June 11 1986. Title: A Query Facility for Allegro Redacted for Privacy Abstract approved: Earl F. Ecklund, Jr. Allegro is a network database management system being developed at Oregon State University. This project adds a user friendly query facility to the system. The user is presented with pictorial display of the network records and a query interface modeled on the QueryByExample system.By request the user may be shown the network sets of the queryschema. When necessary the user may specify query navigationofthe network schema. While implemented and functional, this facility should be considered as a feasibility study for a full query system on a network data base. To provide the desired display this facility is implemented on a system separate from the main Allegro system and uses a communication interface to it. This facility is a Smalitalk implementation. A Query Facility for Allegro by Richard Goodemoot A THESIS submitted to Oregon State University In partial fulfillment of the requirements for the degree of Master of Science Completed June 11, 1986 Commencement June 1987 APPROVED: / Redacted for Privacy Adjunct Professor of Computer Science in Charge of Major Redacted for Privacy on behalf of Walter Rudd Chairman of Department of Computer Science Redacted for Privacy Dean of Gradtfate School Date thesis is presented June 11, 1986 Typed by Richard Goodemoot TABLE OF CONTENTS Page 1 INTRODUCTION 1 1.1 Network Database
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 8.458,105 B2 Nolan Et Al
    USOO84581 05B2 (12) United States Patent (10) Patent No.: US 8.458,105 B2 Nolan et al. (45) Date of Patent: Jun. 4, 2013 (54) METHOD AND APPARATUS FOR 5,215.426 A 6/1993 Bills, Jr. ANALYZING AND INTERRELATING DATA 5,327.254. A 7/1994 Daher 5,689,716 A 11, 1997 Chen 5,694,523 A 12, 1997 Wical (75) Inventors: James J. Nolan, Springfield, VA (US); 5,708,822 A 1, 1998 Wical Mark E. Frymire, Arlington, VA (US); 5,798,786 A 8, 1998 Lareau et al. Andrew F. David, Ft. Belvoir, VA (US) 5,841,895 A 1 1/1998 Huffman 5,884,305 A 3/1999 Kleinberg et al. (73) Assignee: Decisive Analytics Corporation, 5,903,307 A 5/1999 Hwang Arlington, VA (US) 5,930,788 A 7, 1999 Wical glon, 5,953,718 A 9, 1999 Wical 6,009,587 A 1/2000 Beeman (*) Notice: Subject to any disclaimer, the term of this 6,052,657 A 4/2000 Yamron et al. patent is extended or adjusted under 35 6,064,952 A 5/2000 Imanaka et al. U.S.C. 154(b) by 771 days. 6,073,138 A 6/2000 de l'Etraz et al. 6,085,186 A 7/2000 Christianson et al. 6,173,279 B1 1/2001 Levin et al. (21) Appl. No.: 12/548,888 6,181,711 B1 1/2001 Zhang et al. 6,185,531 B1 2/2001 Schwartz et al. (22) Filed: Aug. 27, 2009 6,199,034 B1 3, 2001 Wical (65) Prior Publication Data (Continued) US 2010/0205128A1 Aug.
    [Show full text]
  • Database Management Systems Ebooks for All Edition (
    Database Management Systems eBooks For All Edition (www.ebooks-for-all.com) PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sun, 20 Oct 2013 01:48:50 UTC Contents Articles Database 1 Database model 16 Database normalization 23 Database storage structures 31 Distributed database 33 Federated database system 36 Referential integrity 40 Relational algebra 41 Relational calculus 53 Relational database 53 Relational database management system 57 Relational model 59 Object-relational database 69 Transaction processing 72 Concepts 76 ACID 76 Create, read, update and delete 79 Null (SQL) 80 Candidate key 96 Foreign key 98 Unique key 102 Superkey 105 Surrogate key 107 Armstrong's axioms 111 Objects 113 Relation (database) 113 Table (database) 115 Column (database) 116 Row (database) 117 View (SQL) 118 Database transaction 120 Transaction log 123 Database trigger 124 Database index 130 Stored procedure 135 Cursor (databases) 138 Partition (database) 143 Components 145 Concurrency control 145 Data dictionary 152 Java Database Connectivity 154 XQuery API for Java 157 ODBC 163 Query language 169 Query optimization 170 Query plan 173 Functions 175 Database administration and automation 175 Replication (computing) 177 Database Products 183 Comparison of object database management systems 183 Comparison of object-relational database management systems 185 List of relational database management systems 187 Comparison of relational database management systems 190 Document-oriented database 213 Graph database 217 NoSQL 226 NewSQL 232 References Article Sources and Contributors 234 Image Sources, Licenses and Contributors 240 Article Licenses License 241 Database 1 Database A database is an organized collection of data.
    [Show full text]
  • Non-Spatial Database Models
    UC Santa Barbara Core Curriculum-Geographic Information Science (1997-2000) Title Unit 045 - Non-Spatial Database Models Permalink https://escholarship.org/uc/item/3dj9g8m4 Authors 045, CC in GIScience Meyer, Thomas H. Publication Date 2000 Peer reviewed eScholarship.org Powered by the California Digital Library University of California Unit 045 - Non-Spatial Database Models by Thomas H. Meyer, Mapping Sciences Laboratory, Texas A&M University, USA This unit is part of the NCGIA Core Curriculum in Geographic Information Science. These materials may be used for study, research, and education, but please credit the author, Thomas H. Meyer, and the project, NCGIA Core Curriculum in GIScience. All commercial rights reserved. Copyright 1997 by Thomas H. Meyer. Advanced Organizer Topics covered in this unit This unit introduces the terms and concepts needed to understand non-spatial databases and their underlying data models, including: a motivation of the need for database management systems an overview of database terminology a description of non-spatial data models Intended Learning Outcomes After learning the material covered in this unit, students should be able to: explain the purpose of a database management system list the major non-spatial data models and their features identify the primary distinctions between the major non-spatial data models Instructors' Notes Full Table of Contents Metadata and Revision History Non-spatial Database Models 1. Motivation: Why database management systems? Database management systems (DBMSs) are very good at organizing and managing large collections of persistent data. Core Curriculum - Geographic Information Science Page 1 NCGIA 1997 - 2000 Unit 045 - Non-Spatial Database Models We use DBMSs to help cope with large amounts of data because, when problems get big, they get hard.
    [Show full text]
  • The DB World in 1970
    The DB world in 1970 the Network model (e.g. IDMS CODASYL ) application developers had to be aware of the details of the data representation on disc, and there was no generic high-level DML on the plus side, the model could capture a general graph structure Ref : Charles W Bachman 1973 ACM Turing Award winner __________________________________________ the Hierarchical model (e.g. IMS from IBM ) less of a shambles, less for the application developer to worry about, but incomplete in what it could model tree-structured data only __________________________________________ The Relational DB Model ( Ted Codd, 1970 ) work carried out at IBM (UK) Scientific Centre at Peterlee: first serious implementation of the Model, IS/1 , 1970-72 Data Manipulation Language, ISBL , based on relational algebra follow-up system, PRTV , written in 1972-74, ref. Wikipedia "the world's first relational database management system that could handle significant data volumes". in practical terms read only , update was HARD the main language supported was still ISBL . __________________________________________ 1976 joint project between IBM Peterlee and the Computer Lab new implementation (CODD) based on PRTV , coroutine-based relational DB research in the US Earliest thrust from Universities, in particular Mike Stonebraker's group at UC, Berkeley INGRES QUEL > SEQUEL 1974 work starts on System-R at the IBM San Jose Research Lab. The first serious user was Pratt & Whitney in 1977. Research on the development of SQL was a key part of the research at San Jose. System-R later became DB2 . __________________________________________ Lots of DB research at UK Universities as well, notably in Scotland: Aberdeen, Edinburgh, Glasgow, St Andrews all had good groups __________________________________________ A further important paper by Ted Codd : Extending the Database Relational Model to Capture More Meaning.
    [Show full text]
  • Maier, Chapter 15: Relational Query Languages
    Chapter 15 RELATIONAL QUERY LANGUAGES In this chapter we give a brief overview of several query languages from vari- ous relational database systems. We shall not give a complete exposition of the languages. Our point is, rather, to give the flavor of each, show how they are based on the algebra, calculus, or tableaux, and indicate where they depart from the relational model as we have defined it. We shall look at five languages: ISBL, from the PRTV system; QUEL, from INGRES; SQL, from System R; QBE, which runs atop several data- base systems; and PIQUE, from the experimental PITS system. ISBL is based on relational algebra, QUEL and SQL resemble tuple caiculus, and QBE is a domain calculus-like language, with a syntax similar to tableau queries. PIQUE is a tuple calculus-like language, but it presents a universal relation scheme interface through the use of window functions. For practical reasons and usability considerations, relational query lan- guages do not conform precisely to the relational model. They all contain fea- tures that are extensions to the model, and some have restrictions not present in the model. Nearly all relational systems have facilities for virtual relation definition. Languages based on tuple and domain calculus must allow only safe expressions. Safety is usually guaranteed by the absence of explicit quantifiers or by having variables range over relations rather than all tuples on a given scheme. Query languages often alfow a limited amount of arith- metic and string computation on domain values, and sometimes handle sets of values through aggregate operators (count, average, maximum) and set comparisons.
    [Show full text]
  • CS319 Theory of Databases Content of the Module 1 Content of The
    Content of the module 1 GENERAL BACKGROUND TO DATABASES … 0. Preface to the Theory of Databases preface 1. Generalities on Databases intro CS319 Theory of Databases 2. Ingres and Quel ingres 3. Relational Database Models RelMod [4. SQL sql ] Course Review [5. SQL-EDDI worksheets <cs233 website> ] 2004-2005 5/10/2005 1 CS319 Theory of Databases 5/10/2005 2 CS319 Theory of Databases Content of the module 2 Content of the module 3 RELATIONAL THEORY: ALGEBRA-CALCULUS RELATIONAL DATABASE DESIGN … [10. Entity-relationship modelling ERmodel ] 6. Introduction to Relational Calculus relcalc 11. Decomposition of relational schemes decomp 7. Query optimisation opt 12. Functional Dependency depend 8. From Relational Calculus to Algebra drelcalc 13. Relational Database Design RDBdesign 9. Relational Query languages / modelling state relql [14. Normal Forms RDBdesignNF ] 5/10/2005 3 CS319 Theory of Databases 5/10/2005 4 CS319 Theory of Databases Content of the module 4 Preface CRITIQUE AND EVALUATION … Principal theme of the Theory of Databases module: The OO and 3rd Gen Database Manifestos How do theory and computing practice relate with [Tim Heron : OO and Object-Relational DBs] specific reference to databases? Hugh Darwen: The Relational Model and SQL General orientation especially useful for the two essay questions 1 and 2: Mick Ridley’s reflections Hugh Darwen: Temporal data and the Relational Model Motivation for 15. Why relational? whyrel • study of relational theory 16. Why not relational? whynotrel • discussion of practice and historical context
    [Show full text]
  • User's Guide for Water9 Software
    USER’S GUIDE FOR WATER9 SOFTWARE Version 2.0.0 August 16, 2001 Note that the updated version of this manual is available in a compiled help format that is available from WATER9. Office of Air Quality Planning and Standards U. S. Environmental Protection Agency Research Triangle Park, NC WATER9: Preface 0. PREFACE Overview of WATER9 WATER9 is a Windows based computer program and consists of analytical expressions for estimating air emissions of individual waste constituents in wastewater collection, storage, treatment, and disposal facilities; a data base listing many of the organic compounds; and procedures for obtaining reports of constituent fates, including air emissions and treatment effectiveness. WATER9 is a significant upgrade of features previously obtained in the computer programs WATER8, Chem9, and Chemdat8. WATER9 contains a set of model units that can be used together in a project to provide a model for an entire facility. WATER9 is able to evaluate a full facility that contains multiple wastewater inlet streams, multiple collection systems, and complex treatment configurations. WATER9 provides separate emission estimates for each individual compound that is identified as a constituent of the wastes. The emission estimates are based upon the properties of the compound and its concentration in the wastes. To obtain these emission estimates, the user must identify the compounds of interest and provide their concentrations in the wastes. The identification of compounds can be made by selecting them from the data base that accompanies the program or by entering new information describing the properties of a compound not contained in the data base. WATER9 has the ability to use site-specific compound property information, and the ability to estimate missing compound property values.
    [Show full text]
  • Why Are There No Relational Dbmss?
    Hugh Darwen If [we] could learn from history, what lessons it might teach us! —Samuel Taylor Coleridge, Table Talk (1831) L’histoire n’est que le tableau des crimes et des malheurs. —Voltaire, L’Ingénu (1767) I describe the circumstances in which I obtained, in 1978, a good answer to a burning question: how can E.F. Codd’s relational model of data of 1970 [2] be properly embraced by a computer language? Considering that the answer to that question (reference [12]) was publicly available in 1975, I wonder why it all went wrong and suggest some possible reasons. Note: Three referenced papers, [6], [8], and [9], are companion papers to this one that were originally drafted as appendixes to this paper. “If you want something state of the art, how about developing a relational database management system?” That was my suggestion, back in 1978, in an e-mail (sometime before that term entered our lexicon!) to my colleague Vincent Dupuis in the international software development centre for IBM’s Data Centre Services (DCS), which IBM offered in most countries outside of the U.S. in those days. At that time this DCS Support Centre was split between locations in London, England, for planning and Uithoorn, The Netherlands, for development; and I was in the development department. As one of our lead planners Vincent had foreseen the need for a new service, now that cheaper computers meant that fewer businesses needed to rely on time-sharing services such as IBM’s. I was about to move from development to planning (temporarily, as it turned out) and I had long nurtured a dream to produce a relational DBMS, thanks to my attendance at Chris Date’s course on the subject in 1972.
    [Show full text]