Relational and Object-Oriented Databases

Total Page:16

File Type:pdf, Size:1020Kb

Relational and Object-Oriented Databases Relational and Object-Oriented Databases by Willi-Hans Steeb International School for Scientific Computing Contents 1 What is a table? 1 1.1 Introduction . 1 1.2 Examples . 5 1.3 Tables in Programs . 8 1.4 Table and Relation . 33 2 Structured Query Language 35 2.1 Introduction . 35 2.2 Integrity Rules . 38 2.3 SQL Commands . 39 2.3.1 Introduction . 39 2.3.2 Aggregate Function . 40 2.3.3 Arithmetic Operators . 40 2.3.4 Logical Operators . 40 2.3.5 SELECT Statement . 41 2.3.6 INSERT Command . 45 2.3.7 DELETE Command . 46 2.3.8 UPDATE Command . 47 2.3.9 CREATE TABLE Command . 48 2.3.10 DROP TABLE Command . 51 2.3.11 ALTER TABLE Command . 52 2.4 Set Operators . 53 2.5 Views . 60 2.6 Primary and Foreign Keys . 62 2.7 Datatypes in SQL . 63 2.8 Joins . 66 2.9 Stored Procedure . 71 2.10 MySQL Commands . 72 2.11 Cursors . 73 2.12 PL and SQL . 75 2.13 ABAP/4 and SQL . 76 2.14 Query Processing and Optimization . 77 i 3 Normal Forms 83 3.1 Introduction . 83 3.2 Anomalies . 87 3.3 Example . 89 3.4 Fourth and Fifth Normal Forms . 93 4 Transaction 101 4.1 Introduction . 101 4.2 Data Replication . 107 4.3 Locks . 108 4.4 Deadlocking . 111 4.5 Threads . 117 4.5.1 Introduction . 117 4.5.2 Thread Class . 119 4.5.3 Example . 121 4.5.4 Priorities . 123 4.5.5 Synchronization and Locks . 126 4.5.6 Producer Consumer Problem . 131 4.6 Locking Files for Shared Access . 134 5 JDBC 137 5.1 Introduction . 137 5.2 Classes for JDBC . 140 5.2.1 Introduction . 140 5.2.2 Classes DriverManager and Connection . 141 5.2.3 Class Statement . 144 5.2.4 Class PreparedStatement . 147 5.2.5 Class CallableStatement . 149 5.2.6 Class ResultSet . 151 5.2.7 Class SQLException . 154 5.2.8 Classes Date, Time and TimeStamp . 155 5.3 Data Types in SQL . 156 5.4 Example . 158 5.5 Programs . 159 5.6 Metadata . 173 5.7 JDBC 3.0 . 173 6 Object-Oriented Databases 177 6.1 Introduction . 177 6.2 Object-Oriented Properties . 181 6.3 Terms Glossary . 183 6.4 Properties of an Object-Oriented Database . 186 6.5 Example . 188 6.6 C++ . 192 6.7 The Object Query Language . 194 ii 6.8 SQL3 Object Model . 195 6.8.1 Basic Concepts . 195 6.8.2 Objects . 197 6.8.3 Operations . 198 6.8.4 Methods . 199 6.8.5 Events . 201 6.8.6 Binding and Polymorphism . 202 6.8.7 Types and Classes . 203 6.8.8 Inheritance and Delegation . 208 6.8.9 Noteworthy Objects . 210 6.8.10 Extensibility . 212 6.9 SQL3 Datatypes and Java . 214 6.10 Evaluations of OODBMSs . 219 6.11 Summary . 222 7 Versant 225 7.1 Introduction . 225 8 FastObjects 233 8.1 Introduction . 233 9 Data Mining 235 9.1 Introduction . 235 9.2 Example . 242 Bibliography 243 Index 243 iii Preface This book explores the use of databases and related tools in the various applications. Both relational and object-oriented databases are coverd. An introduction to JDBC is also given. It also includes C++ and Java programs relevant in databases. Without doubt, this book can be extended. If you have comments or suggestions, we would be pleased to have them. The email addresses of the author are: [email protected] [email protected] [email protected] The web sites of the author are: http://www.fhso.ch/~steeb http://issc.rau.ac.za iv Chapter 1 What is a table? 1.1 Introduction What is a table? As a definition for a table in the Oxford dictionary we find "orderly arrangment of facts, information etc (usually as in columns)" For a database we find the definition A database is a means of storing information in such a way that information can be retrieved from it. Thus a database is typically a repository for heterogeneous but interrelated pieces of information. Often a database contains more than one table. Codebooks and dictionaries can also be considered as tables. A dictionary is a reference book on any subject, the items of which are arranged in alphabetical order. A codebook is a list of replacements for words or phrases in the original message. A code is a system for hiding the meaning of a message by replacing each word or phrase in the original message with another character or set of characters. The list of replacements is contained in a codebook. An alternative definition of a code is any form of encryption which has no built-in flexbility, i.e. there is only one key, namely the codebook. Databases contain organized data. A database can be as simple as a flat file (a single computer file with data usually in a tabular form) containing names and telephone numbers of one’s friends, or as elaborate as the worldwide reservation system of a major airline. Many of the principles discussed in this book are applicable to a wide variety of database systems. 1 2 CHAPTER 1. WHAT IS A TABLE? Structurally, there are three major types of databases: Hierarchical Relational Network During the 1970s and 1980s, the hierarchical scheme was very popular. This scheme treats data as a tree-structured system with data records forming the leaves. Ex- amples of the hierarchical implementations are schemes like b-tree and multi-tree data access. In the hierarchical scheme, to get to data, users need to traverse up and down the tree structure. XML (Extensible Markup Language) is based on a tree structure. The most common relationship in a hierarchical structure is a one- to-many relationship between the data records, and it is difficult to implement a many-to-many relationship without data redundancy. The network data model solved this problem by assuming a multi-relationship be- tween data elements. In contrast to the hierarchical scheme where there is a parent- child relationship, in the network scheme, there is a peer-to-peer relationship. Most of the programs developed during those days used a combination of the hierarchical and network data storage and access model. During the 90s, the relational data access scheme came to the forefront. The re- lational scheme views data as rows of information. Each row contains columns of data, called fields. The main concept in the relational scheme is that the data is uniform. Each row contains the same number of columns. One such collection of rows and columns is called a table. Many such tables (which can be structurally different) form a relational database. A relational database is accessed and admin- istered using Structured Query Language (SQL) statements. SQL is a command language for performing operations on databases and their component parts. Ta- bles are the component parts we are dealing with most often. Their column and row structure makes them look a great deal like spreadsheets, but the resemblance is only surface-level. Table elements are not used to represent relationships to other elements - that is, table elements do not hold formulas, they just hold data. Most SQL statements are devoted to working with the data in these rows and columns, allowing the user to add, delete, sort, and relate it between tables. 1.1. INTRODUCTION 3 There are many ways to approach the design of a database and tables. The database layout is the most important part of an information system. The more design and thought put into a database, the better the database will be in the long run. We should gather information about the user’s requirement, data objects, and data def- initions before creating a database layout. The first step we take when determining the database layout is to build a data model that defines how the data is to be stored. For most relational databases, we create an entity-relationship diagram or model. The steps to create this model are as follows: 1. Identify and define the data objects (entities, relationship, and attributes) 2. Diagram the objects and relationship 3. Translate the objects into relational constructs (such as tables) 4. Resolve the data model 5. Perform the normalization process First, define the entities and the relationships between them. An entity is something that can be distinctively identified. An example of an entity is a specific person, an element in the periodic table, a specific.
Recommended publications
  • Powerdesigner 16.6 Data Modeling
    SAP® PowerDesigner® Document Version: 16.6 – 2016-02-22 Data Modeling Content 1 Building Data Models ...........................................................8 1.1 Getting Started with Data Modeling...................................................8 Conceptual Data Models........................................................8 Logical Data Models...........................................................9 Physical Data Models..........................................................9 Creating a Data Model.........................................................10 Customizing your Modeling Environment........................................... 15 1.2 Conceptual and Logical Diagrams...................................................26 Supported CDM/LDM Notations.................................................27 Conceptual Diagrams.........................................................31 Logical Diagrams............................................................43 Data Items (CDM)............................................................47 Entities (CDM/LDM)..........................................................49 Attributes (CDM/LDM)........................................................55 Identifiers (CDM/LDM)........................................................58 Relationships (CDM/LDM)..................................................... 59 Associations and Association Links (CDM)..........................................70 Inheritances (CDM/LDM)......................................................77 1.3 Physical Diagrams..............................................................82
    [Show full text]
  • Data Modeler User's Guide
    Oracle® SQL Developer Data Modeler User's Guide Release 18.1 E94838-01 March 2018 Oracle SQL Developer Data Modeler User's Guide, Release 18.1 E94838-01 Copyright © 2008, 2018, Oracle and/or its affiliates. All rights reserved. Primary Author: Celin Cherian Contributing Authors: Chuck Murray Contributors: Philip Stoyanov This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency- specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
    [Show full text]
  • Daten Als Objekte Speichern Mit Db4o, Eine Objektorientierte Datenbank
    Daten als Objekte speichern mit db4o, eine objektorientierte Datenbank Matthias Bordach Universitaet Siegen [email protected] ABSTRACT 2. DER ODMG STANDARD[1] Die Hausarbeit befasst sich mit der Datenbanktechnologie Verschiedene Ans¨atze fur¨ eine Datenbank auf objektorientier- db4o. Das objektorientierte Speicherkonzept zeichnet sie als ter Basis erforderten einen Standard. Diesen Standard ent- einen Vertreter der NO-SQL-Familie aus. Auf eine theoreti- wickelte eine Arbeitsgruppe der Object Management Group sche Einfuhrung¨ in den Standard ODMG folgt eine praktische (OMG). 1993 wurde die erste Version ver¨offentlicht mit dem Vorstellung der Datenbankfunktionalit¨at. Die Funktionen Namen The Object Data Standard ODMG. Die Arbeitsgrup- werden mit Beispielen gestutzt,¨ die in Java geschrieben sind. pe uberarbeitete¨ und erweiterte das Dokument in den fol- Abfrage- und Speichermethoden werden ebenso erkl¨art wie genden Jahren. Inhalt und Ziel des Dokuments ist eine Stan- die Realisierung von Beziehungen zwischen Objekten und darddefinition von Konzepten fur¨ die Anbindung eines objek- das Handling von Schema Evolution. Der Leser wird nach torientierten Datenbankmanagementsystems an die gew¨ahlte der Lekture¨ in der Lage sein, eine einfache Datenbank mit Programmiersprache. In Version 3 wird den Sprachen C++, db4o zu programmieren. Smalltalk und Java jeweils ein eigenes Kapitel fur¨ die Schnitt- stellenumsetzung gewidmet. Generell definiert die ODMG das Object Model, Objektspezifikationssprachen und die an die 1. EINLEITUNG SQL angelehnte Object Query Language (OQL). Es werden Die Idee einer Datenbank, die Objekte ohne ein aufwendiges Standardausdrucke¨ festgelegt fur¨ die Datenbankinstanziie- Mapping in ein anderes Datenmodell speichern kann, wurde rung, -nutzung (open, close), Transaktionen (commit) und erstmals in den 80er Jahren des letzten Jahrhunderts in kon- Mehrfachzugriff (Locks).
    [Show full text]
  • Object-Oriented Databases Need for Complex Data Types
    Object-Oriented Databases! ■" Need for Complex Data Types! ■" The Object-Oriented Data Model! ■" Object-Oriented Languages! ■" Persistent Programming Languages! ■" Persistent C++ Systems! 8.1! Need for Complex Data Types! ■" Traditional database applications in data processing had conceptually simple data types! é" Relatively few data types, first normal form holds! ■" Complex data types have grown more important in recent years! é" E.g. Addresses can be viewed as a ! Ø" Single string, or! Ø" Separate attributes for each part, or! Ø" Composite attributes (which are not in first normal form)! é" E.g. it is often convenient to store multivalued attributes as-is, without creating a separate relation to store the values in first normal form! ■" Applications! é" computer-aided design, computer-aided software engineering! é" multimedia and image databases, and document/hypertext databases.! 8.2! 1! Object-Oriented Data Model! ■" Loosely speaking, an object corresponds to an entity in the E- R model.! ■" The object-oriented paradigm is based on encapsulating code and data related to an object into single unit.! ■" The object-oriented data model is a logical data model (like the E-R model).! ■" Adaptation of the object-oriented programming paradigm (e.g., Smalltalk, C++) to database systems.! 8.3! Object Structure! ■" An object has associated with it:! é" A set of variables that contain the data for the object. The value of each variable is itself an object.! é" A set of messages to which the object responds; each message may have zero, one, or more parameters.! é" A set of methods, each of which is a body of code to implement a message; a method returns a value as the response to the message! ■" The physical representation of data is visible only to the implementor of the object! ■" Messages and responses provide the only external interface to an object.! ■" The term message does not necessarily imply physical message passing.
    [Show full text]
  • Object Oriented Database Management Systems-Concepts
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Global Journal of Computer Science and Technology (GJCST) Global Journal of Computer Science and Technology: C Software & Data Engineering Volume 15 Issue 3 Version 1.0 Year 2015 Type: Double Blind Peer Reviewed International Research Journal Publisher: Global Journals Inc. (USA) Online ISSN: 0975-4172 & Print ISSN: 0975-4350 Object Oriented Database Management Systems-Concepts, Advantages, Limitations and Comparative Study with Relational Database Management Systems By Hardeep Singh Damesha Lovely Professional University, India Abstract- Object Oriented Databases stores data in the form of objects. An Object is something uniquely identifiable which models a real world entity and has got state and behaviour. In Object Oriented based Databases capabilities of Object based paradigm for Programming and databases are combined due remove the limitations of Relational databases and on the demand of some advanced applications. In this paper, need of Object database, approaches for Object database implementation, requirements for database to an Object database, Perspectives of Object database, architecture approaches for Object databases, the achievements and weakness of Object Databases and comparison with relational database are discussed. Keywords: relational databases, object based databases, object and object data model. GJCST-C Classification : F.3.3 ObjectOrientedDatabaseManagementSystemsConceptsAdvantagesLimitationsandComparativeStudywithRelationalDatabaseManagementSystems Strictly as per the compliance and regulations of: © 2015. Hardeep Singh Damesha. This is a research/review paper, distributed under the terms of the Creative Commons Attribution- Noncommercial 3.0 Unported License http://creativecommons.org/licenses/by-nc/3.0/), permitting all non-commercial use, distribution, and reproduction inany medium, provided the original work is properly cited.
    [Show full text]
  • Object-Relational DBMS
    Session-7: Object-Relational DBMS Cyrus Shahabi 1 Motivation Relational databases (2 nd generation) were designed for traditional banking-type applications with well-structured, homogenous data elements (vertical & horizontal homogeneity) and a minimal fixed set of limited operations (e.g., set & tuple- oriented operations). New applications (e.g., CAD, CAM, CASE, OA, and CAP), however, require concurrent modeling of both data and processes acting upon the data. Hence, a combination of database and software-engineering disciplines lead to the 3 rd generation of database management systems: Object Database Management Systems, ODBMS. Note that a classic debate in database community is that do we need a new model or relational model is sufficient and can be extended to support new applications. 2 Motivation … People in favor of relational model argue that: New versions of SQL (e.g., SQL-92 and SQL3) are designed to incorporate functionality required by new applications (UDT, UDF, …). Embedded SQL can address almost all the requirements of the new applications. “Object people”, however, counter-argue that in the above- mentioned solutions, it is the application rather than the inherent capabilities of the model that provides the required functionality. Object people say there is an impedance mismatch between programming languages (handling one row of data at a time) and SQL (multiple row handling) which makes conversions inefficient. Relational people say, instead of defining new models, let’s introduce set-level functionality into
    [Show full text]
  • SQL Developer Data Modeler: a Top-Down Product Overview
    SQL Developer Data Modeler: A Top-Down Product Overview Sue Harper Oracle United Kingdom Keywords: SQL Developer Data Modeler, ERD, DDL Generation, model, capture, design Introduction Oracle SQL Developer Data Modeler is a graphical data modeling tool for creating, browsing and editing data models, including logical, relational, physical, multi-dimensional, and data type models. It supports forward and reverse engineering from Oracle Database, Microsoft SQL Server and IBM DB2 databases and the generation of DDL scripts for these databases. SQL Developer Data Modeler offers features and utilities that enhance the data modeling experience, improve productivity and promote the use of standards. SQL Developer Data Modeler is designed for a broad spectrum of database developers; from business architects to DBAs and from database to application developers, serving as a powerful communication tool between developers and business users. In this article we review the main modelers and features in SQL Developer Data Modeler 2.0 starting with the logical model and progressing through the features to the final DDL script. Often called the top-down approach, this is not the only flow of work through the product, as indeed, users can start by importing a data model and reverse engineering the objects to create an initial diagram and progressing from there. We will refer to various methods of creating models and updating the database using the product. Integrated Models SQL Developer Data Modeler provides facilities to build sets of related and integrated models. Many consider the core of SQL Developer Data Modeler to be the logical model. It is this logical model that provides a true implementation-independent view of enterprise information.
    [Show full text]
  • An Introduction to Oracle SQL Developer Data Modeler
    An Oracle White Paper June 2009 An Introduction to Oracle SQL Developer Data Modeler Oracle White Paper— An Introduction to Oracle SQL Developer Data Modeler Introduction ....................................................................................... 1 Oracle SQL Developer Data Modeler ................................................ 2 Architecture ................................................................................... 2 Integrated Models.............................................................................. 4 Logical Models .............................................................................. 4 Relational Models.......................................................................... 5 Physical Models............................................................................. 5 Multi-dimensional Models .............................................................. 7 Data Type and Structured Type Models ...................................... 10 Spatial Models............................................................................. 11 Creating Models .............................................................................. 13 Creating New Models .................................................................. 13 Importing from the Data Dictionary .............................................. 13 Importing from Oracle Designer................................................... 14 Generating Scripts........................................................................... 15 Generating DDL
    [Show full text]
  • Object Database Benchmarks
    Object Database Benchmarks Jérôme Darmont ERIC, Université Lumière Lyon 2, France INTRODUCTION The need for performance measurement tools appeared soon after the emergence of the first Object-Oriented Database Management Systems (OODBMSs), and proved important for both designers and users (Atkinson & Maier, 1990). Performance evaluation is useful to designers to determine elements of architecture and more generally to validate or refute hypotheses regar ding the actual behavior of an OODBMS. Thus, performance evaluation is an essential component in the development process of well-designed and efficient systems. Users may also employ performance evaluation, either to compare the efficiency of different technologies before selecting an OODBMS or to tune a system. Performance evaluation by experimentation on a real system is generally referred to as benchmarking. It consists in performing a series of tests on a given OODBMS to estimate its performance in a given setting. Benchmarks are generally used to compare the global performance of OODBMSs, but they can also be exploited to illustrate the advantages of one system or another in a given situation, or to determine an optimal hardware configuration. Typically, a benchmark is constituted of two main elements: a workload model constituted of a database and a set of read and write operations to apply on this database, and a set of performance metrics. BACKGROUND OBJECT DATABASE BENCHMARKS EVOLUTION In the sphere of relational DBMSs, the Transaction Performance Processing Council (TPC) issues standard benchmarks, verifies their correct application and regularly publishes performance tests results. In contrast, there is no standard benchmark for OODBMSs, even if the more popular of them: OO1, HyperModel, and OO7, can be considered as de facto standards.
    [Show full text]
  • Multi-Model Databases: a New Journey to Handle the Variety of Data
    0 Multi-model Databases: A New Journey to Handle the Variety of Data JIAHENG LU, Department of Computer Science, University of Helsinki IRENA HOLUBOVA´ , Department of Software Engineering, Charles University, Prague The variety of data is one of the most challenging issues for the research and practice in data management systems. The data are naturally organized in different formats and models, including structured data, semi- structured data and unstructured data. In this survey, we introduce the area of multi-model DBMSs which build a single database platform to manage multi-model data. Even though multi-model databases are a newly emerging area, in recent years we have witnessed many database systems to embrace this category. We provide a general classification and multi-dimensional comparisons for the most popular multi-model databases. This comprehensive introduction on existing approaches and open problems, from the technique and application perspective, make this survey useful for motivating new multi-model database approaches, as well as serving as a technical reference for developing multi-model database applications. CCS Concepts: Information systems ! Database design and models; Data model extensions; Semi- structured data;r Database query processing; Query languages for non-relational engines; Extraction, trans- formation and loading; Object-relational mapping facilities; Additional Key Words and Phrases: Big Data management, multi-model databases, NoSQL database man- agement systems. ACM Reference Format: Jiaheng Lu and Irena Holubova,´ 2019. Multi-model Databases: A New Journey to Handle the Variety of Data. ACM CSUR 0, 0, Article 0 ( 2019), 38 pages. DOI: http://dx.doi.org/10.1145/0000000.0000000 1.
    [Show full text]
  • The O/R Problem: Mapping Between Relational and Object-Oriented
    The O/R Problem: Mapping Between Relational and Object-Oriented Methodologies CIS515 Strategic Planning for Database Systems Ryan Somma StudenID: 9989060874 [email protected] Introduction Relational databases are set of tables defining the columns of the rows they contain, which are also conceptualized as relations defining the attributes of the tuples they store. Relational Database Management Systems (RDBMS) abstract the normalized relational structures underlying the system away from the user, allowing them to focus on the specific data they wish to extract from it. Through queries, they provide users the capability of joining sets in relations into reports, transforming data into information. Through normalization, they eliminate redundancy, ensuring there is only one source for each data element in the system, and improve integrity through relationships based on data keys and validation (Rob and Coronel, 2009). Although there are alternatives to RDBMS‟s, the top five database management systems for 2004 to 2006 were all relational (Olofson, 2007). Object orientation is a “set of design and development principles based on conceptually autonomous computer structures known as objects.” Object-oriented programming (OOP) takes related data elements and functions, known as properties and methods, and encapsulates them into objects that may interact with other objects via messaging or act upon themselves. This strategy reduces complexity in the system, hiding it within objects that are easier to understand as concepts rather than exposing their workings within a morass of procedural code. Additionally, OOP promotes reuse of coding solutions with classes, which are built to model a generalized set of properties and methods that are implemented in object instances, which reuse the class code.
    [Show full text]
  • General Object-Oriented Database for Software
    The GOODSTEP Pro ject: General Ob ject-Oriented Database for Software Engineering Pro cesses The GOODSTEP Team Abstract 1 Ob jective of GOODSTEP The goal of the GOODSTEP project is The goal of the GOODSTEP pro ject is to enhance and improve the functionality of to develop a sophisticated database system a ful ly object-oriented database management dedicated to the supp ort of software develop- system to yield a platform suited for appli- mentenvironments SDEs and make the ba- cations such as Software Development En- sis for a platform for SDE construction with a software pro cess to olset and generators for vironments SDEs. The baseline of the graphical and textual integrated to ols imple- project is the O database management sys- 2 mented on top of it. tem DBMS. The O DBMS already in- 2 The GOODSTEP pro ject started Septem- cludes many of the features required by SDEs. b er 1992 and will last for three years. This The project has identifed enhancements to pap er mainly rep orts on the rst year of work O in order to make it a real software en- 2 within the pro ject. gineering database management system. The baseline of the pro ject is an exist- These enhancements are essential ly upgrades ing Europ ean commercially available ob ject- of the existing O functionality, and hence 2 oriented database pro duct: O [4]. Rather requirerelatively easy extensions to the O 2 2 than developing a new database manage- system. They have been developedinthe ment system from scratch, GOODSTEP will early stages of the project and are now ex- enhance and improve this pro duct.
    [Show full text]