DOCSLIB.ORG

ACS-3902 Ron Mcfadyen Slides Are Based on Chapter 5 (7Th Edition)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ACS-3902 Ron Mcfadyen Slides Are Based on Chapter 5 (7Th Edition) ACS-3902 Ron McFadyen Slides are based on chapter 5 (7th edition) (chapter 3 in 6th edition) ACS-3902 1 The Relational Data Model and Relational Database Constraints • Relational model – Ted Codd (IBM) 1970 – First commercial implementations available in early 1980s – Widely used ACS-3902 2 Relational Model Concepts • Database is a collection of relations • Implementation of relation: table comprising rows and columns • In practice a table/relation represents an entity type or relationship type (entity-relationship model … later) • At intersection of a row and column in a table there is a simple value • Row • Represents a collection of related data values • Formally called a tuple • Column names • Columns may be referred to as fields, or, formally as attributes • Values in a column are drawn from a domain of values associated with the column/field/attribute ACS-3902 3 Relational Model Concepts 7th edition Figure 5.1 ACS-3902 4 Domains • Domain – Atomic • A domain is a collection of values where each value is indivisible • Not meaningful to decompose further – Specifying a domain • Name, data type, rules – Examples • domain of department codes for UW is a list: {“ACS”, “MATH”, “ENGL”, “HIST”, etc} • domain of gender values for UW is the list (“male”, “female”) – Cardinality: number of values in a domain – Database implementation & support vary ACS-3902 5 Domain example - PostgreSQL CREATE DOMAIN posint AS integer CHECK (VALUE > 0); CREATE TABLE mytable (id posint); INSERT INTO mytable VALUES(1); -- works INSERT INTO mytable VALUES(-1); -- fails https://www.postgresql.org/docs/current/domains.html ACS-3902 6 Domain example - PostgreSQL CREATE DOMAIN domain_code_type AS character varying NOT NULL CONSTRAINT domain_code_type_check CHECK (VALUE IN ('ApprovedByAdmin', 'Unapproved', 'ApprovedByEmail')); CREATE TABLE codes__domain ( code_id integer NOT NULL, code_type domain_code_type NOT NULL, CONSTRAINT codes_domain_pk PRIMARY KEY (code_id) ) ACS-3902 7 Relation • Relation schema R – Name R and a list of attributes: • Denoted by R (A1, A2, ...,An) • E.g. STUDENT (Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa) – Attribute Ai • Name of a role played by some domain D in the relation schema R • Each attribute has a name and a domain • E.g. age: integer firstName: aName lastName: aName • Degree (or arity) of a relation – Number of attributes in its relation schema – E.g. STUDENT has 7 attributes ACS-3902 8 Relations • The relation (or relation state) r(R) m tuples in relation – Set of n-tuples r = {t1, t2, ..., tm} each tuple has n values – Each n-tuple t each value comes from a domain • Ordered list of n values t =<v1, v2, ..., vn> • Each value vi, 1 ≤ i ≤ n, is an element of domain Ai or is NULL – r(R) is a subset of the Cartesian product of the domains of R: • r(R) ⊆ (domain(A1) × domain (A2) × ... × domain (An)) ACS-3902 9 Relational Databases and Relational Database Schemas • Relational database schema S – Set of relation schemas S = {R1, R2, ..., Rm} – Set of integrity constraints IC • Relational database state – Set of relation states DB = {r1, r2, ..., rm} – Each ri is a state of Ri and such that the ri relation states satisfy integrity constraints specified in IC ACS-3902 10 Characteristics of Relations • No ordering of tuples in a relation – Relation defined as a set of tuples – Order of attributes is not that important (some database systems may have some practical tips) ACS-3902 11 Characteristics of Relations (cont’d.) Figures 5.1 and 5.2 show the same relation state … order of tuples is not important 7th edition Figure 5.2 5.1 ACS-3902 12 Characteristics of Relations (cont’d.) • Values – Each value in a tuple is atomic – Flat relational model • Composite and multivalued attributes not allowed • First normal form assumption – Multivalued attributes • Must be represented by separate relations – Composite attributes • Represented only by simple component attributes in basic relational model An EERD may have such things … we cover proper mapping of EERD to relations ACS-3902 13 Characteristics of Relations (cont’d.) • NULLs – Represent the values of attributes that may be unknown or may not apply to a tuple – Meanings for NULL values • Value unknown • Value exists but is not available • Attribute does not apply to this tuple (value undefined) • … ACS-3902 14 Characteristics of Relations (cont’d.) • Interpretation (meaning) of a relation • Each tuple in the relation is a fact • In the Student relation there are five assertions : five students exist and have the characteristics given • We must be able to make statements regarding the meaning of tuples … see slide 11 • E.g. Dick Davidson is identified by the SSN 422-11-2320, has an unknown home phone number, lives at 3452 Elgin Road, has an office phone number (817)749-1253, is of age 25 and has a current gpa of 3.53 ACS-3902 15 Relational Model Notation • To refer to the current set of tuples (its state): STUDENT • To refer to the schema: STUDENT ( Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa) • An attribute can be qualified with the relation name to which it belongs by using dot notation: STUDENT.Name – Needed in SQL sometimes ACS-3902 16 Constraints • Integrity Constraints – Restrictions on the actual values in a database state – Derived from the rules in the miniworld that the database represents – Three categories: • Constraints inherent in the data model • Constraints expressed in the schema • General constraints not falling into the first two categories – Expressed in application code ACS-3902 17 Constraints • Constraints expressed in a data model: – there are no duplicate tuples There is at least one attribute value that differentiates one student from another – Values for an attribute must come from its domain Each SSN value is numeric In practice these are expressed in the DDL i.e. in the schema Create table, create index, … ACS-3902 18 Relational Model Constraints (cont’d.) • Schema-based constraints – Domains – Keys – NULLs – Entity integrity – Referential integrity ACS-3902 19 Domain Constraints • In DDL we specify a datatype for an attribute – Numeric data types for integers and real numbers – Characters – Booleans – If supported …. a domain – etc CREATE TABLE Customer( First_Name char(50) , Last_Name char(50) , Address char(50) , City char(50) , Country char(25) , Birth_Date datetime ); ACS-3902 20 Domain Constraints • In DDL we can specify a check constraint for an attribute E.g. suppose the value of the age attribute in row must be greater than zero. The following will cause INSERT Customer(‘joe’,’smith’,0) to be rejected CREATE TABLE Customer( First_Name char(50) , Last_Name char(50) , Age int check (age >0) ); ACS-3902 21 Domain Constraints CREATE TABLE distributors ( did integer, name varchar(40), CONSTRAINT con1 CHECK (did > 100 AND name <> '') ); ACS-3902 22 Domain Constraints • In DDL we can ensure each row has a value for an attribute E.g. suppose the value of the age attribute in row must be known. The following will cause INSERT Customer(‘joe’,’smith’,null) to be rejected CREATE TABLE Customer( First_Name char(50) , Last_Name char(50) , Age int NOT NULL ); ACS-3902 23 Domain Constraints • SQL has a create domain statement (see page 94). Examples: CREATE DOMAIN persons_name CHAR(30) ; CREATE DOMAIN street_address CHAR(35) ; • domain definitions can be used in DDL: CREATE TABLE Customers ( ID INT DEFAULT AUTOINCREMENT PRIMARY KEY, Name persons_name, Street street_address); ACS-3902 24 Key Constraints • Superkey: combination of attributes such that every tuple will have a unique value • Key – Of course, a key is a superkey – But a key is minimal in the sense that if you remove an attribute from the key it is no longer a superkey – the term candidate keys refers to all keys of a table • One key in a table is the primary key • Other keys in a table are alternate keys ACS-3902 25 Key Constraints • Candidate key – Relation schema may have more than one key – SQL: unique constraint • Primary key of the relation – Only one CK is designated as the PK – Other candidate keys are designated as unique keys ( secondary keys or alternate keys) – SQL: primary key clause ACS-3902 26 Key Constraints CREATE TABLE Schedule ( eventID INT, room CHAR(10), startTime DATETIME, endTime DATETIME, eventDescription VARCHAR(255), CONSTRAINT pk PRIMARY KEY (eventID), CONSTRAINT ck1 UNIQUE (room, startTime), CONSTRAINT ck2 UNIQUE (room, endTime) ); ACS-3902 27 Referential Integrity Constraints Empid Mgrid Empname Salary 1 NULL Nancy 9000.00 2 1 Andrew 5000.00 3 1 Janet 5000.00 4 1 Margaret 5000.00 5 2 Steven 2500.00 6 2 Michael 2500.00 7 3 Robert 2500.00 8 3 Laura 2500.00 9 3 Ann 2500.00 10 4 Ina 2500.00 11 7 David 2000.00 12 7 Ron 2000.00 13 7 Dan 2000.00 14 11 James 1500.00 Mgrid must be null or have a value that exists in a row of Employee ACS-3902 28 Referential Integrity Constraints Mgrid must be null or have a value that exists in a row of Employee CREATE TABLE Employees ( empid int NOT NULL, mgrid int NULL, empname varchar(25) NOT NULL, salary money NOT NULL, CONSTRAINT PK_Employees_empid PRIMARY KEY (empid), CONSTRAINT FK_Employees_Employees FOREIGN KEY (mgrid) REFERENCES Employees (empid) ) ; ACS-3902 29 By convention PK is underlined PK composite PK ACS-3902 30 Structure diagram showing PKs and FKs: 5.7 A directed line shows a FK references a PK ACS-3902 31 Referential Integrity • Foreign key rules: – The attributes in a FK have the same domain(s) as the primary key attributes PK – Value of FK in a tuple t1 of the current state r1(R1) either occurs
Load more

Recommended publications
  • Relational Database Design Chapter 7
    Chapter 7: Relational Database Design Chapter 7: Relational Database Design First Normal Form Pitfalls in Relational Database Design Functional Dependencies Decomposition Boyce-Codd Normal Form Third Normal Form Multivalued Dependencies and Fourth Normal Form Overall Database Design Process Database System Concepts 7.2 ©Silberschatz, Korth and Sudarshan 1 First Normal Form Domain is atomic if its elements are considered to be indivisible units + Examples of non-atomic domains: Set of names, composite attributes Identification numbers like CS101 that can be broken up into parts A relational schema R is in first normal form if the domains of all attributes of R are atomic Non-atomic values complicate storage and encourage redundant (repeated) storage of data + E.g. Set of accounts stored with each customer, and set of owners stored with each account + We assume all relations are in first normal form (revisit this in Chapter 9 on Object Relational Databases) Database System Concepts 7.3 ©Silberschatz, Korth and Sudarshan First Normal Form (Contd.) Atomicity is actually a property of how the elements of the domain are used. + E.g. Strings would normally be considered indivisible + Suppose that students are given roll numbers which are strings of the form CS0012 or EE1127 + If the first two characters are extracted to find the department, the domain of roll numbers is not atomic. + Doing so is a bad idea: leads to encoding of information in application program rather than in the database. Database System Concepts 7.4 ©Silberschatz, Korth and Sudarshan 2 Pitfalls in Relational Database Design Relational database design requires that we find a “good” collection of relation schemas.
    [Show full text]
  • Oracle Database Advanced Application Developer's Guide, 11G Release 2 (11.2) E17125-03
    Oracle® Database Advanced Application Developer's Guide 11g Release 2 (11.2) E17125-03 August 2010 Oracle Database Advanced Application Developer's Guide, 11g Release 2 (11.2) E17125-03 Copyright © 1996, 2010, Oracle and/or its affiliates. All rights reserved. Primary Author: Sheila Moore Contributing Authors: D. Adams, L. Ashdown, M. Cowan, J. Melnick, R. Moran, E. Paapanen, J. Russell, R. Strohm, R. Ward Contributors: D. Alpern, G. Arora, C. Barclay, D. Bronnikov, T. Chang, L. Chen, B. Cheng, M. Davidson, R. Day, R. Decker, G. Doherty, D. Elson, A. Ganesh, M. Hartstein, Y. Hu, J. Huang, C. Iyer, N. Jain, R. Jenkins Jr., S. Kotsovolos, V. Krishnaswamy, S. Kumar, C. Lei, B. Llewellyn, D. Lorentz, V. Moore, K. Muthukkaruppan, V. Moore, J. Muller, R. Murthy, R. Pang, B. Sinha, S. Vemuri, W. Wang, D. Wong, A. Yalamanchi, Q. Yu 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 software or related documentation is delivered to the U.S.
    [Show full text]
  • SQL Stored Procedures
    Agenda Key:31MA Session Number:409094 DB2 for IBM i: SQL Stored Procedures Tom McKinley ([email protected]) DB2 for IBM i consultant IBM Lab Services 8 Copyright IBM Corporation, 2009. All Rights Reserved. This publication may refer to products that are not currently available in your country. IBM makes no commitment to make available any products referred to herein. What is a Stored Procedure? • Just a called program – Called from SQL-based interfaces via SQL CALL statement • Supports input and output parameters – Result sets on some interfaces • Follows security model of iSeries – Enables you to secure your data – iSeries adopted authority model can be leveraged • Useful for moving host-centric applications to distributed applications 2 © 2009 IBM Corporation What is a Stored Procedure? • Performance savings in distributed computing environments by dramatically reducing the number of flows (requests) to the database engine – One request initiates multiple transactions and processes R R e e q q u u DB2 for i5/OS DB2DB2 for for i5/OS e e AS/400 s s t t SP o o r r • Performance improvements further enhanced by the option of providing result sets back to ODBC, JDBC, .NET & CLI clients 3 © 2009 IBM Corporation Recipe for a Stored Procedure... 1 Create it CREATE PROCEDURE total_val (IN Member# CHAR(6), OUT total DECIMAL(12,2)) LANGUAGE SQL BEGIN SELECT SUM(curr_balance) INTO total FROM accounts WHERE account_owner=Member# AND account_type IN ('C','S','M') END 2 Call it (from an SQL interface) over and over CALL total_val(‘123456’, :balance) 4 © 2009 IBM Corporation Stored Procedures • DB2 for i5/OS supports two types of stored procedures 1.
    [Show full text]
  • Reactive Relational Database Connectivity
    R2DBC - Reactive Relational Database Connectivity Ben Hale<[email protected]>, Mark Paluch <[email protected]>, Greg Turnquist <[email protected]>, Jay Bryant <[email protected]> Version 0.8.0.RC1, 2019-09-26 © 2017-2019 The original authors. Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically. 1 Preface License Specification: R2DBC - Reactive Relational Database Connectivity Version: 0.8.0.RC1 Status: Draft Specification Lead: Pivotal Software, Inc. Release: 2019-09-26 Copyright 2017-2019 the original author or authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Foreword R2DBC brings a reactive programming API to relational data stores. The Introduction contains more details about its origins and explains its goals. This document describes the first and initial generation of R2DBC. Organization of this document This document is organized into the following parts: • Introduction • Goals • Compliance • Overview • Connections • Transactions 2 • Statements • Batches • Results • Column and Row Metadata • Exceptions • Data Types • Extensions 3 Chapter 1.
    [Show full text]
  • Relational Database Design: FD's & BCNF
    CS145 Lecture Notes #5 Relational Database Design: FD's & BCNF Motivation Automatic translation from E/R or ODL may not produce the best relational design possible Sometimes database designers like to start directly with a relational design, in which case the design could be really bad Notation , , ... denote relations denotes the set of all attributes in , , ... denote attributes , , ... denote sets of attributes Functional Dependencies A functional dependency (FD) has the form , where and are sets of attributes in a relation Formally, means that whenever two tuples in agree on all the attributes of , they must also agree on all the attributes of Example: FD's in Student(SID, SS#, name, CID, grade) Some FD's are more interesting than others: Trivial FD: where is a subset of Example: Nontrivial FD: where is not a subset of Example: Completely nontrivial FD: where and do not overlap Example: Jun Yang 1 CS145 Spring 1999 Once we declare that an FD holds for a relation , this FD becomes a part of the relation schema Every instance of must satisfy this FD This FD should better make sense in the real world! A particular instance of may coincidentally satisfy some FD But this FD may not hold for in general Example: name SID in Student? FD's are closely related to: Multiplicity of relationships Example: Queens, Overlords, Zerglings Keys Example: SID, CID is a key of Student Another de®nition of key: A set of attributes is a key for if (1) ; i.e., is a superkey (2) No proper subset of satis®es (1) Closures of Attribute Sets Given , a set of FD's
    [Show full text]
  • JDBC Mock Test
    JJDDBBCC MMOOCCKK TTEESSTT http://www.tutorialspoint.com Copyright © tutorialspoint.com This section presents you various set of Mock Tests related to JDBC Framework. You can download these sample mock tests at your local machine and solve offline at your convenience. Every mock test is supplied with a mock test key to let you verify the final score and grade yourself. JJDDBBCC MMOOCCKK TTEESSTT IIIIII Q 1 - Which of the following is used generally used for altering the databases? A - boolean execute B - ResultSet executeQuery C - int executeUpdate D - None of the above. Q 2 - How does JDBC handle the data types of Java and database? A - The JDBC driver converts the Java data type to the appropriate JDBC type before sending it to the database. B - It uses a default mapping for most data types. C - Both of the above. D - None of the above. Q 3 - Which of the following can cause 'No suitable driver' error? A - Due to failing to load the appropriate JDBC drivers before calling the DriverManager.getConnection method. B - It can be specifying an invalid JDBC URL, one that is not recognized by JDBC driver. C - This error can occur if one or more the shared libraries needed by the bridge cannot be loaded. D - All of the above. Q 4 - Why will you set auto commit mode to false? A - To increase performance. B - To maintain the integrity of business processes. C - To use distributed transactions D - All of the above. Q 5 - Which of the following is correct about savepoint? A - A savepoint marks a point that the current transaction can roll back to.
    [Show full text]
  • Concurrency Control and Recovery ACID • Transactions • Recovery Transaction Model Concurency Control Recovery
    Data Management Systems • Transaction Processing • Concurrency control and recovery ACID • Transactions • Recovery Transaction model Concurency Control Recovery Gustavo Alonso Institute of Computing Platforms Department of Computer Science ETH Zürich Transactions-CC&R 1 A bit of theory • Before discussing implementations, we will cover the theoretical underpinning behind concurrency control and recovery • Discussion at an abstract level, without relation to implementations • No consideration of how the concepts map to real elements (tuples, pages, blocks, buffers, etc.) • Theoretical background important to understand variations in implementations and what is considered to be correct • Theoretical background also key to understand how system have evolved over the years Transactions-CC&R 2 Reference Concurrency Control and Recovery in Database Systems Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman • https://www.microsoft.com/en- us/research/people/philbe/book/ Transactions-CC&R 3 ACID Transactions-CC&R 4 Conventional notion of database correctness • ACID: • Atomicity: the notion that an operation or a group of operations must take place in their entirety or not at all • Consistency: operations should take the database from a correct state to another correct state • Isolation: concurrent execution of operations should yield results that are predictable and correct • Durability: the database needs to remember the state it is in at all moments, even when failures occur • Like all acronyms, more effort in making it sound cute than in
    [Show full text]
  • DBMS Keys Mahmoud El-Haj 13/01/2020 The
    DBMS Keys Mahmoud El-Haj 13/01/2020 The following is to help you understand the DBMS Keys mentioned in the 2nd lecture (2. Relational Model) Why do we need keys: • Keys are the essential elements of any relational database. • Keys are used to identify tuples in a relation R. • Keys are also used to establish the relationship among the tables in a schema. Type of keys discussed below: Superkey, Candidate Key, Primary Key (for Foreign Key please refer to the lecture slides (2. Relational Model). • Superkey (SK) of a relation R: o Is a set of attributes SK of R with the following condition: . No two tuples in any valid relation state r(R) will have the same value for SK • That is, for any distinct tuples t1 and t2 in r(R), t1[SK] ≠ t2[SK] o Every relation has at least one default superkey: the set of all its attributes o Basically superkey is nothing but a key. It is a super set of keys where all possible keys are included (see example below). o An attribute or a set of attributes that can be used to identify a tuple (row) of data in a Relation (table) is a Superkey. • Candidate Key of R (all superkeys that can be candidate keys): o A "minimal" superkey o That is, a (candidate) key is a superkey K such that removal of any attribute from K results in a set of attributes that IS NOT a superkey (does not possess the superkey uniqueness property) (see example below). o A Candidate Key is a Superkey but not necessarily vice versa o Candidate Key: Are keys which can be a primary key.
    [Show full text]
  • March 2017 Report
    BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT ADVANCED DATABASE MANAGEMENT SYSTEMS March 2017 Answer any THREE questions out of FIVE. All questions carry equal marks. Time: THREE hours Answer any Section A questions you attempt in Answer Book A Answer any Section B questions you attempt in Answer Book B The marks given in brackets are indicative of the weight given to each part of the question. Calculators are NOT allowed in this examination. Section A Answer Section A questions in Answer Book A A1 Examiner's General Comments This was a fairly popular question, attempted by around half of the candidates, with two-thirds of the attempts achieving pass level marks. Therefore, the performance was generally quite good with a wide range of marks, some candidates producing near correct solutions. The definition of a true distributed database system is that it consists of a collection of geographically remote sites of physical databases, connected together via some kind of communication network, in which a user at any site can access data anywhere in the network exactly as if the data were all stored in one single database at the user’s own site. a) Explain the problems associated with achieving a true distributed database in practice. 12 marks ANSWER POINTER Fragmentation of tables requires maintenance of unique keys across horizontal fragments and consistency of primary keys that are reflected in vertical fragments. Also increased network traffic occurs as many fragments may need to be consulted to perform one query.
    [Show full text]
  • IBM DB2 11 for Z/OS Technical Overview
    IBM® Information Management Software Front cover IBM DB2 11 for z/OS Technical Overview Understand the synergy with System z platform Enhance applications and avoid incompatibilities Run business analytics and scoring adapter Paolo Bruni Felipe Bortoletto Ravikumar Kalyanasundaram Sabine Kaschta Glenn McGeoch Cristian Molaro ibm.com/redbooks International Technical Support Organization IBM DB2 11 for z/OS Technical Overview December 2013 SG24-8180-00 Note: Before using this information and the product it supports, read the information in “Notices” on page xxi. First Edition (December 2013) This edition applies to Version 11, Release 1 of DB2 for z/OS (program number 5615-DB2) and Version 11, Release 1 of DB2 Utilities Suite for z/OS (program number 5655-W87). Note: This book is based on a pre-GA version of a product and may not apply when the product becomes generally available. We recommend that you consult the product documentation or follow-on versions of this book for more current information. © Copyright International Business Machines Corporation 2013. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures . xi Tables . xiii Examples . .xv Notices . xxi Trademarks . xxii Summary of changes. xxiii December 2013, First Edition. xxiii May 2014, First Update. xxiii Preface . .xxv Authors. xxv Now you can become a published author, too! . xxvii Comments welcome. .xxviii Stay connected to IBM Redbooks publications . .xxviii Chapter 1. DB2 11 for z/OS at a glance . 1 1.1 Subsystem . 2 1.2 Application functions . 2 1.3 Operations and performance .
    [Show full text]
  • Models of Transactions Structuring Applications Flat Transaction Flat
    Structuring Applications • Many applications involve long transactions Models of Transactions that make many database accesses • To deal with such complex applications many transaction processing systems Chapter 19 provide mechanisms for imposing some structure on transactions 2 Flat Transaction Flat Transaction • Consists of: begin transaction – Computation on local variables • Abort causes the begin transaction • not seen by DBMS; hence will be ignored in most future discussion execution of a program ¡£ ¤¦©¨ – Access to DBMS using call or ¢¡£ ¥¤§¦©¨ that restores the statement level interface variables updated by the ¡£ ¤¦©¨ • This is transaction schedule; commit ….. applies to these operations ¢¡£ ¤§¦©¨ ….. transaction to the state • No internal structure they had when the if condition then abort • Accesses a single DBMS transaction first accessed commit commit • Adequate for simple applications them. 3 4 Some Limitations of Flat Transactions • Only total rollback (abort) is possible – Partial rollback not possible Providing Structure Within a • All work lost in case of crash Single Transaction • Limited to accessing a single DBMS • Entire transaction takes place at a single point in time 5 6 1 Savepoints begin transaction S1; Savepoints Call to DBMS sp1 := create_savepoint(); S2; sp2 := create_savepoint(); • Problem: Transaction detects condition that S3; requires rollback of recent database changes if (condition) {rollback (sp1); S5}; S4; that it has made commit • Solution 1: Transaction reverses changes • Rollback to spi causes
    [Show full text]
  • The Relational Model
    The Relational Model Watch video: https://youtu.be/gcYKGV-QKB0?t=5m15s Topics List • Relational Model Terminology • Properties of Relations • Relational Keys • Integrity Constraints • Views Relational Model Terminology • A relation is a table with columns and rows. • Only applies to logical structure of the database, not the physical structure. • Attribute is a named column of a relation. • Domain is the set of allowable values for one or more attributes. Relational Model Terminology • Tuple is a row of a relation. • Degree is the number of attributes in a relation. • Cardinality is the number of tuples in a relation. • Relational Database is a collection of normalised relations with distinct relation names. Instances of Branch and Staff Relations Examples of Attribute Domains Alternative Terminology for Relational Model Topics List • Relational Model Terminology • Properties of Relations • Relational Keys • Integrity Constraints • Views Properties of Relations • Relation name is distinct from all other relation names in relational schema. • Each cell of relation contains exactly one atomic (single) value. • Each attribute has a distinct name. • Values of an attribute are all from the same domain. Properties of Relations • Each tuple is distinct; there are no duplicate tuples. • Order of attributes has no significance. • Order of tuples has no significance, theoretically. Topics List • Relational Model Terminology • Properties of Relations • Relational Keys • Integrity Constraints • Views Relational Keys • Superkey • Super key stands for superset of a key. A Super Key is a set of one or more attributes that are taken collectively and can identify all other attributes uniquely. • An attribute, or set of attributes, that uniquely identifies a tuple within a relation.
    [Show full text]