DOCSLIB.ORG

The Relational Model Constraints and SQL DDL

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Relational Model Constraints and SQL DDL The Relational Model Constraints and SQL DDL Week 2-3 Weeks 2-3 MIE253-Consens 1 Schedule Week Date Lecture Topic This week’s 1 Jan 9 Introduction to Data Management reading: 2 Jan 16 The Relational Model Chapter 3 3 Jan. 23 Constraints and SQL DDL 4 Jan. 30 DB Applications, JDBC 5 Feb 6 Relational Algebra Last week’s 6 Feb 13 Advanced SQL reading: - Feb 20 [Reading Week] Chapters 1-2 7 Feb 27 Review and Midterm (Mar 1) 8Mar5OLAP 9 Mar 12 ER Conceptual Modelling 10 Mar 19 Normalization 11 Mar 26 XML and Data Integration 12 Apr 2 Transactions and the Internet, Query Processing 13 Apr 9 Final Review Weeks 2-3 MIE253-Consens 2 Relational Database Instance Finite set of relations Each relation consists of a schema and an instance Database schema set of relation schemas constraints among relations (inter-relational constraints) Database instance set of (corresponding) relation instances Weeks 2-3 MIE253-Consens 3 Types of DBs in an Organization Weeks 2-3 MIE253-Consens 4 DB Budgets Platform Average Cost Excel $ 500 Access Individual $ 3,000 Access Simple Multi-user $ 10,000 Access Workgroup/Department $ 50,000 VB/VS.NET/Java and SQL Server $ 500,000 Oracle, IBM DB2 $ 2,000,000 SAP, etc. $ 10,000,000 Weeks 2-3 MIE253-Consens 5 Number of DBs in Organizations Platform Quantity Excel 50,000 Access Individual 5,000 Access Simple Multi-user 1,000 Access Department 500 VB/VS.NET/Java and SQL Server 50 Oracle, IBM DB2 25 SAP, etc. 10 Weeks 2-3 MIE253-Consens 6 SQL DDL Data Definition Language (DDL) Sublanguage of SQL for describing schema, manipulates the definition of tables stored in the DBMS catalog Current version of the ANSI/ISO standard is SQL:2008 (supports Objects, XML) SQL-92 is the most commonly used subset Database vendors generally deviate from standard, but eventually converge e.g., SQL in Access, SQL in JDBC Weeks 2-3 MIE253-Consens 7 Table Declaration CREATE TABLE Student ( Incorporates the Id INTEGER, table definition Name CHAR(20), Address CHAR(50), to the database Status CHAR(10) schema ) Student Id Name Address Status 101222333 John 10 Cedar St Freshman 234567890 Mary 22 Main St Sophomore Weeks 2-3 MIE253-Consens 8 Integrity Constraints Part of schema Restriction on state (or of sequence of states) of data base Enforced by DBMS Protects database from errors Enforces enterprise rules Intra-relational - involve only one relation Part of relation schema e.g., all Ids are unique Inter-relational - involve several relations Part of relation schema or database schema Weeks 2-3 MIE253-Consens 9 Kinds of Integrity Constraints Static – restricts legal states of database Syntactic (structural) e.g., all values in a column must be unique Semantic (involve meaning of attributes) e.g., cannot register for more than 18 credits Dynamic – limitation on sequences of database states e.g., cannot raise salary by more than 5% Weeks 2-3 MIE253-Consens 10 Key Constraint A key constraint is a sequence of attributes A1,…,An (n=1 possible) of a relation schema, S, with the following property: A relation instance s of S satisfies the key constraint iff at most one row in s can contain a particular set of values, a1,…,an, for the attributes A1,…,An Minimality: no subset of A1,…,An is a key constraint Key Set of attributes mentioned in a key constraint e.g., Id in Student, e.g., (StudId, CrsCode, Semester) in Transcript It is minimal: no subset of a key is a key (Id, Name) is not a key of Student Weeks 2-3 MIE253-Consens 11 Key Constraint A key constraint is a sequence of attributes A1,…,An (n=1 possible) of a relation schema, S, with the following property: A relation instance s of S satisfies the key constraint iff at most one row in s can contain a particular set of values, a1,…,an, for the attributes A1,…,An Minimality: no subset of A1,…,An is a key constraint Key Set of attributes mentioned in a key constraint e.g., Id in Student, e.g., (StudId, CrsCode, Semester) in Transcript It is minimal: no subset of a key is a key (Id, Name) is not a key of Student Weeks 2-3 MIE253-Consens 12 Key Constraint (cont’d) Superkey - set of attributes containing key (Id, Name) is a superkey of Student Every relation has a key Not with SQL bags Relation can have several keys: primary key: Id in Student (can’t be null) candidate key: (Name, Address) in Student Weeks 2-3 MIE253-Consens 13 Primary/Candidate Keys CREATE TABLE Course ( CrsCode CHAR(6), CrsName CHAR(20), DeptId CHAR(4), Descr CHAR(100), PRIMARY KEY (CrsCode), UNIQUE (DeptId, CrsName) -- candidate key ) Things that start with 2 dashes are comments in the SQL standard -- not in Access Weeks 2-3 MIE253-Consens 14 Example Database Schema Student (Id: INT, Name: STRING, Address: STRING, Status: STRING) Professor (Id: INT, Name: STRING, DeptId: DEPTS) Department(DeptId: DEPTS, Name: STRING) Course (DeptId: DEPTS, CrsName: STRING, CrsCode: COURSES) Transcript (CrsCode: COURSES, StudId: INT, Grade: GRADES, Semester: SEMESTERS) Weeks 2-3 MIE253-Consens 15 Foreign Key Constraint Referential integrity: Item named in one relation must refer to tuples that describe that item in another Transcript (CrsCode) references Course(CrsCode ) Professor(DeptId) references Department(DeptId) Attribute A1 is a foreign key of R1 referring to attribute A2 in R2, if whenever there is a value v of A1, there is a tuple of R2 in which A2 has value v, and A2 is a key of R2 Weeks 2-3 MIE253-Consens 16 Foreign Key Constraint (Example) Department Professor DeptId DeptId v3 v1 v5 v2 v1 v3 v6 v4 v2 -- v7 v3 v4 Foreign key Candidate key Weeks 2-3 MIE253-Consens 17 Foreign Key (cont’d) Names of A1 and A2 need not be the same. With tables: Teaching(CrsCode: COURSES, Sem: SEMESTERS, ProfId: INT) Professor(Id: INT, Name: STRING, DeptId: DEPTS) ProfId attribute of Teaching references Id attribute of Professor R1 and R2 need not be distinct. Employee(Id:INT, MgrId:INT, ….) Employee(MgrId) references Employee(Id) Every manager is also an employee and hence has a unique row in Employee Weeks 2-3 MIE253-Consens 18 Foreign Key (cont’d) Foreign key might consist of several columns (CrsCode, Semester) of Transcript references (CrsCode, Semester) of Teaching R1(A1, …An) references R2(B1, …Bn) There exists a 1 - 1 correspondance between A1,…An and B1,…Bn Ai and Bi have same domains (although not necessarily the same names) B1,…,Bn is a candidate key of R2 Weeks 2-3 MIE253-Consens 19 Foreign Key Constraint CREATE TABLE Teaching ( ProfId INTEGER, CrsCode CHAR (6), Semester CHAR (6), PRIMARY KEY (CrsCode, Semester), FOREIGN KEY (CrsCode) REFERENCES Course, FOREIGN KEY (ProfId) REFERENCES Professor (Id) ) Weeks 2-3 MIE253-Consens 20 Foreign Key Constraint CrsCode CrsCode ProfId c c p Course Id Teaching p Professor Weeks 2-3 MIE253-Consens 21 Constraints and SQL DDL Week 2-3 (cont.) Weeks 2-3 MIE253-Consens 22 Schedule Week Date Lecture Topic This week’s 1 Jan 9 Introduction to Data Management reading: 2 Jan 16 The Relational Model Chapter 5 (5.3) 3 Jan. 23 Constraints and SQL DDL Chapter 8 (8.5, 4 Jan. 30 SQL DML, DB Applications, JDBC 8.2.5) 5 Feb 6 Relational Algebra 6 Feb 13 Advanced SQL - Feb 20 [Reading Week] 7 Feb 27 Review and Midterm (Mar 1) 8Mar5OLAP Previous 9 Mar 12 ER Conceptual Modelling week’s: 10 Mar 19 Normalization Chapters 1-2 11 Mar 26 XML and Data Integration Chapter 3 12 Apr 2 Transactions and the Internet, Query Processing 13 Apr 9 Final Review Weeks 2-3 MIE253-Consens 23 NULL Problem: Not all information might be known when row is inserted (e.g., Grade might be missing from Transcript) A column might not be applicable for a particular row (e.g., MaidenName if row describes a male) Solution: Use place holder – NULL Not a value of any domain (although called null value) Indicates the absence of a value Not allowed in certain situations Primary keys and columns constrained by NOT NULL Weeks 2-3 MIE253-Consens 24 Default Value -Value to be assigned if attribute value in a row is not specified CREATE TABLE Student ( Id: INTEGER, Name CHAR(20) NOT NULL, Address CHAR(50), Status CHAR(10) DEFAULT ‘freshman’, PRIMARY KEY (Id) ) Weeks 2-3 MIE253-Consens 25 Semantic Constraints in SQL Primary key and foreign key are examples of structural (syntactic) constraints Semantic constraints Express the logic of the application at hand: e.g., number of registered students maximum enrollment Weeks 2-3 MIE253-Consens 26 Semantic Constraints (cont’d) Used for application dependent conditions Example: limit attribute values CREATE TABLE Transcript ( StudId INTEGER, CrsCode CHAR(6), Semester CHAR(6), Grade CHAR(1), CHECK (Grade IN (‘A’, ‘B’, ‘C’, ‘D’, ‘F’)), CHECK (StudId > 0 AND StudId < 1000000000) ) Each row in table must satisfy condition Weeks 2-3 MIE253-Consens 27 Domains Possible attribute values can be specified Using a CHECK constraint or Creating a new domain Domain can be used in several declarations Domain is a schema element CREATE DOMAIN Grades CHAR (1) CHECK (VALUE IN (‘A’, ‘B’, ‘C’, ‘D’, ‘F’)) CREATE TABLE Transcript ( …., Grade Grades, … ) Weeks 2-3 MIE253-Consens 28 Modifying the Schema ALTER TABLE Student ADD COLUMN Gpa INTEGER DEFAULT 0 ALTER TABLE Student ADD CONSTRAINT GpaRange CHECK (Gpa >= 0 AND Gpa <= 4) ALTER TABLE Student DROP CONSTRAINT GpaRange-- constraint names are useful DROP TABLE Employee Weeks 2-3 MIE253-Consens 29 Circularity in Foreign Key Constraint A1 A2 A3 B1 B2 B3 A y x xyB candidate key: A1 candidate key: B1 foreign key: A3 references B(B1) foreign key: B3 references A(A1) Problem 1: Creation of A requires existence of
Load more

Recommended publications
  • SAP IQ Administration: User Management and Security Company
    ADMINISTRATION GUIDE | PUBLIC SAP IQ 16.1 SP 04 Document Version: 1.0.0 – 2019-04-05 SAP IQ Administration: User Management and Security company. All rights reserved. All rights company. affiliate THE BEST RUN 2019 SAP SE or an SAP SE or an SAP SAP 2019 © Content 1 Security Management........................................................ 5 1.1 Plan and Implement Role-Based Security............................................6 1.2 Roles......................................................................7 User-Defined Roles.........................................................8 System Roles............................................................ 30 Compatibility Roles........................................................38 Views, Procedures, and Tables That Are Owned by Roles..............................38 Display Roles Granted......................................................39 Determining the Roles and Privileges Granted to a User...............................40 1.3 Privileges..................................................................40 Privileges Versus Permissions.................................................41 System Privileges......................................................... 42 Object-Level Privileges......................................................64 System Procedure Privileges..................................................81 1.4 Passwords.................................................................85 Password and user ID Restrictions and Considerations...............................86
    [Show full text]
  • *** Check Constraints - 10G
    *** Check Constraints - 10g *** Create table and poulated with a column called FLAG that can only have a value of 1 or 2 SQL> CREATE TABLE check_const (id NUMBER, flag NUMBER CONSTRAINT check_flag CHECK (flag IN (1,2))); Table created. SQL> INSERT INTO check_const SELECT rownum, mod(rownum,2)+1 FROM dual CONNECT BY level <=10000; 10000 rows created. SQL> COMMIT; Commit complete. SQL> exec dbms_stats.gather_table_stats(ownname=>NULL, tabname=>'CHECK_CONST', estimate_percent=> NULL, method_opt=> 'FOR ALL COLUMNS SIZE 1'); PL/SQL procedure successfully completed. *** Now perform a search for a value of 3. There can be no such value as the Check constraint only permits values 1 or 2 ... *** The exection plan appears to suggest a FTS is being performed (remember, there are no indexes on the flag column) *** But the statistics clearly show no LIOs were performed, none SQL> SELECT * FROM check_const WHERE flag = 3; no rows selected Execution Plan ---------------------------------------------------------- Plan hash value: 1514750852 ---------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 6 | 0 (0)| | |* 1 | FILTER | | | | | | |* 2 | TABLE ACCESS FULL| CHECK_CONST | 1 | 6 | 6 (0)| 00:00:01 | ---------------------------------------------------------------------------------- Predicate Information (identified by operation id): ---------------------------------------------------
    [Show full text]
  • Chapter 10. Declarative Constraints and Database Triggers
    Chapter 10. Declarative Constraints and Database Triggers Table of contents • Objectives • Introduction • Context • Declarative constraints – The PRIMARY KEY constraint – The NOT NULL constraint – The UNIQUE constraint – The CHECK constraint ∗ Declaration of a basic CHECK constraint ∗ Complex CHECK constraints – The FOREIGN KEY constraint ∗ CASCADE ∗ SET NULL ∗ SET DEFAULT ∗ NO ACTION • Changing the definition of a table – Add a new column – Modify an existing column’s type – Modify an existing column’s constraint definition – Add a new constraint – Drop an existing constraint • Database triggers – Types of triggers ∗ Event ∗ Level ∗ Timing – Valid trigger types • Creating triggers – Statement-level trigger ∗ Option for the UPDATE event – Row-level triggers ∗ Option for the row-level triggers – Removing triggers – Using triggers to maintain referential integrity – Using triggers to maintain business rules • Additional features of Oracle – Stored procedures – Function and packages – Creating procedures – Creating functions 1 – Calling a procedure from within a function and vice versa • Discussion topics • Additional content and activities Objectives At the end of this chapter you should be able to: • Know how to capture a range of business rules and store them in a database using declarative constraints. • Describe the use of database triggers in providing an automatic response to the occurrence of specific database events. • Discuss the advantages and drawbacks of the use of database triggers in application development. • Explain how stored procedures can be used to implement processing logic at the database level. Introduction In parallel with this chapter, you should read Chapter 8 of Thomas Connolly and Carolyn Begg, “Database Systems A Practical Approach to Design, Imple- mentation, and Management”, (5th edn.).
    [Show full text]
  • 2.4. Constraints
    PostgreSQL 7.3 Documentation Prev Chapter 2. Data Definition Next 2.4. Constraints Data types are a way to limit the kind of data that can be stored in a table. For many applications, however, the constraint they provide is too coarse. For example, a column containing a product price should probably only accept positive values. But there is no data type that accepts only positive numbers. Another issue is that you might want to constrain column data with respect to other columns or rows. For example, in a table containing product information, there should only be one row for each product number. To that end, SQL allows you to define constraints on columns and tables. Constraints give you as much control over the data in your tables as you wish. If a user attempts to store data in a column that would violate a constraint, an error is raised. This applies even if the value came from the default value definition. 2.4.1. Check Constraints A check constraint is the most generic constraint type. It allows you to specify that the value in a certain column must satisfy an arbitrary expression. For instance, to require positive product prices, you could use: CREATE TABLE products ( product_no integer, name text, price numeric CHECK (price > 0) ); As you see, the constraint definition comes after the data type, just like default value definitions. Default values and constraints can be listed in any order. A check constraint consists of the key word CHECK followed by an expression in parentheses. The check constraint expression should involve the column thus constrained, otherwise the constraint would not make too much sense.
    [Show full text]
  • Reasoning Over Large Semantic Datasets
    R O M A TRE UNIVERSITA` DEGLI STUDI DI ROMA TRE Dipartimento di Informatica e Automazione DIA Via della Vasca Navale, 79 – 00146 Roma, Italy Reasoning over Large Semantic Datasets 1 2 2 1 ROBERTO DE VIRGILIO ,GIORGIO ORSI ,LETIZIA TANCA , RICCARDO TORLONE RT-DIA-149 May 2009 1Dipartimento di Informatica e Automazione Universit`adi Roma Tre {devirgilio,torlone}@dia.uniroma3.it 2Dipartimento di Elettronica e Informazione Politecnico di Milano {orsi,tanca}@elet.polimi.it ABSTRACT This paper presents NYAYA, a flexible system for the management of Semantic-Web data which couples an efficient storage mechanism with advanced and up-to-date ontology reasoning capa- bilities. NYAYA is capable of processing large Semantic-Web datasets, expressed in a variety of formalisms, by transforming them into a collection of Semantic Data Kiosks that expose the native meta-data in a uniform fashion using Datalog±, a very general rule-based language. The kiosks form a Semantic Data Market where the data in each kiosk can be uniformly accessed using conjunctive queries and where users can specify user-defined constraints over the data. NYAYA is easily extensible and robust to updates of both data and meta-data in the kiosk. In particular, a new kiosk of the semantic data market can be easily built from a fresh Semantic- Web source expressed in whatsoever format by extracting its constraints and importing its data. In this way, the new content is promptly available to the users of the system. The approach has been experimented using well known benchmarks with very promising results. 2 1 Introduction Ever since Tim Berners Lee presented, in 2006, the design principles for Linked Open Data1, the public availability of Semantic-Web data has grown rapidly.
    [Show full text]
  • CSC 443 – Database Management Systems Data and Its Structure
    CSC 443 – Database Management Systems Lecture 3 –The Relational Data Model Data and Its Structure • Data is actually stored as bits, but it is difficult to work with data at this level. • It is convenient to view data at different levels of abstraction . • Schema : Description of data at some abstraction level. Each level has its own schema. • We will be concerned with three schemas: physical , conceptual , and external . 1 Physical Data Level • Physical schema describes details of how data is stored: tracks, cylinders, indices etc. • Early applications worked at this level – explicitly dealt with details. • Problem: Routines were hard-coded to deal with physical representation. – Changes to data structure difficult to make. – Application code becomes complex since it must deal with details. – Rapid implementation of new features impossible. Conceptual Data Level • Hides details. – In the relational model, the conceptual schema presents data as a set of tables. • DBMS maps from conceptual to physical schema automatically. • Physical schema can be changed without changing application: – DBMS would change mapping from conceptual to physical transparently – This property is referred to as physical data independence 2 Conceptual Data Level (con’t) External Data Level • In the relational model, the external schema also presents data as a set of relations. • An external schema specifies a view of the data in terms of the conceptual level. It is tailored to the needs of a particular category of users. – Portions of stored data should not be seen by some users. • Students should not see their files in full. • Faculty should not see billing data. – Information that can be derived from stored data might be viewed as if it were stored.
    [Show full text]
  • Data Base Lab the Microsoft SQL Server Management Studio Part-3
    Data Base Lab Islamic University – Gaza Engineering Faculty Computer Department Lab -5- The Microsoft SQL Server Management Studio Part-3- By :Eng.Alaa I.Haniy. SQL Constraints Constraints are used to limit the type of data that can go into a table. Constraints can be specified when a table is created (with the CREATE TABLE statement) or after the table is created (with the ALTER TABLE statement). We will focus on the following constraints: NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY CHECK DEFAULT Now we will describe each constraint in details. SQL NOT NULL Constraint By default, a table column can hold NULL values. The NOT NULL constraint enforces a column to NOT accept NULL values. The NOT NULL constraint enforces a field to always contain a value. This means that you cannot insert a new record, or update a record without adding a value to this field. The following SQL enforces the "PI_Id" column and the "LName" column to not accept NULL values CREATE TABLE Person ( PI_Id int NOT NULL, LName varchar(50) NOT NULL, FName varchar(50), Address varchar(50), City varchar(50) ) 2 SQL UNIQUE Constraint The UNIQUE constraint uniquely identifies each record in a database table. The UNIQUE and PRIMARY KEY constraints both provide a guarantee for uniqueness or a column or set of columns. A PRIMARY KEY constraint automatically has a UNIQUE constraint defined on it. Note that you can have many UNIQUE constraints per table, but only one PRIMARY KEY constraint per table. SQL UNIQUE Constraint on CREATE TABLE The following SQL creates a UNIQUE
    [Show full text]
  • Declarative Constraints
    THREE Declarative Constraints 3.1 PRIMARY KEY 3.1.1 Creating the Constraint 3.1.2 Naming the Constraint 3.1.3 The Primary Key Index 3.1.4 Sequences 3.1.5 Sequences in Code 3.1.6 Concatenated Primary Key 3.1.7 Extra Indexes with Pseudo Keys 3.1.8 Enable, Disable, and Drop 3.1.9 Deferrable Option 3.1.10 NOVALIDATE 3.1.11 Error Handling in PL/SQL 3.2 UNIQUE 3.2.1 Combining NOT NULL, CHECK with UNIQUE Constraints 3.2.2 Students Table Example 3.2.3 Deferrable and NOVALIDATE Options 3.2.4 Error Handling in PL/SQL 3.3 FOREIGN KEY 3.3.1 Four Types of Errors 3.3.2 Delete Cascade 3.3.3 Mandatory Foreign Key Columns 3.3.4 Referencing the Parent Syntax 3.3.5 Referential Integrity across Schemas and Databases 3.3.6 Multiple Parents and DDL Migration 3.3.7 Many-to-Many Relationships 3.3.8 Self-Referential Integrity 3.3.9 PL/SQL Error Handling with Parent/Child Tables 3.3.10 The Deferrable Option 69 70 Chapter 3 • Declarative Constraints 3.4 CHECK 3.4.1 Multicolumn Constraint 3.4.2 Supplementing Unique Constraints 3.4.3 Students Table Example 3.4.4 Lookup Tables versus Check Constraints 3.4.5 Cardinality 3.4.6 Designing for Check Constraints 3.5 NOT NULL CONSTRAINTS 3.6 DEFAULT VALUES 3.7 MODIFYING CONSTRAINTS 3.8 EXCEPTION HANDLING 3.9 DATA LOADS This is the first of several chapters that cover enforcing business rules with con- straints.
    [Show full text]
  • On Enforcing Relational Constraints in Matbase
    Scan to know paper details and author's profile On enforcing relational constraints in MatBase Christian Mancas,Valentina Dorobantu ABSTRACT MatBase is a very powerful database management system based not only on the relational data model, but also on the elementary mathematical, entity-relationship, and Datalog logic ones. This paper briefly introduces MatBase and the elementary mathematical data model, after which is focused on the five relational constraint types and their enforcement in relational database management systems, as well as in MatBase. Keywords: relational data model, domain constraint, not null constraint, unique key constraint, referential integrity constraint, tuple constraint, elementary mathematical data model, MatBase. Classification: H.2.6 H.2 Language: English LJP Copyright ID: 206059 ISBN 10: 1537631683 London ISBN 13: 978-1537631684 LJP Journals Press London Journal of Research in Computer Science and Technology 16UK Volume 17 | Issue 1 | Compilation 1.0 © 2017. Christian Mancas,Valentina Dorobantu. This is a research/review paper, distributed under the terms of the Creative Commons Attribution-Noncommercial 4.0 Unported License http://creativecommons.org/licenses/by-nc/4.0/), permitting all non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited. Powered by TCPDF (www.tcpdf.org) On Enforcing Relational Constraints in MatBase ​ α σ Valentina Dorobantu ​ & Christian Mancas ​ ​ ​ ______________________________________________ I. ABSTRACT 2.1 MatBase MatBase is a very powerful database manage- MatBase [1-5] is a powerful prototype multi- ment system based not only on the relational model, multi-user, and multi-language knowledge data model, but also on the elementary and data (KD) base management system mathematical, entity-relationship, and Datalog (KDBMS) that currently has two versions: one in MS Access 2015 and the other in MS SQL Server logic ones.
    [Show full text]
  • 8 the Effectiveness of Test Coverage Criteria for Relational Database Schema Integrity Constraints
    The Effectiveness of Test Coverage Criteria for Relational Database Schema Integrity Constraints PHIL MCMINN and CHRIS J. WRIGHT, University of Sheffield GREGORY M. KAPFHAMMER, Allegheny College Despite industry advice to the contrary, there has been little work that has sought to test that a relational database’s schema has correctly specified integrity constraints. These critically important constraints ensure the coherence of data in a database, defending it from manipulations that could violate requirements such as “usernames must be unique” or “the host name cannot be missing or unknown.” This article is the first to propose coverage criteria, derived from logic coverage criteria, that establish different levels of testing for the formulation of integrity constraints in a database schema. These range from simple criteria that mandate the testing of successful and unsuccessful INSERT statements into tables to more advanced criteria that test the formulation of complex integrity constraints such as multi-column PRIMARY KEYs and arbitrary CHECK constraints. Due to different vendor interpretations of the structured query language (SQL) specification with regard to how integrity constraints should actually function in practice, our criteria crucially account for the underlying semantics of the database management system (DBMS). After formally defining these coverage criteria and relating them in a subsumption hierarchy, we present two approaches for automatically generating tests that satisfy the criteria. We then describe the results of an empirical study that uses mutation analysis to investigate the fault-finding capability of data generated when our coverage criteria are applied to a wide variety of relational schemas hosted by three well-known and representative DBMSs— HyperSQL, PostgreSQL, and SQLite.
    [Show full text]
  • Declarative Constraints
    5685ch03.qxd_kp 11/6/03 1:36 PM Page 69 THREE Declarative Constraints 3.1 PRIMARY KEY 3.1.1 Creating the Constraint 3.1.2 Naming the Constraint 3.1.3 The Primary Key Index 3.1.4 Sequences 3.1.5 Sequences in Code 3.1.6 Concatenated Primary Key 3.1.7 Extra Indexes with Pseudo Keys 3.1.8 Enable, Disable, and Drop 3.1.9 Deferrable Option 3.1.10 NOVALIDATE 3.1.11 Error Handling in PL/SQL 3.2 UNIQUE 3.2.1 Combining NOT NULL, CHECK with UNIQUE Constraints 3.2.2 Students Table Example 3.2.3 Deferrable and NOVALIDATE Options 3.2.4 Error Handling in PL/SQL 3.3 FOREIGN KEY 3.3.1 Four Types of Errors 3.3.2 Delete Cascade 3.3.3 Mandatory Foreign Key Columns 3.3.4 Referencing the Parent Syntax 3.3.5 Referential Integrity across Schemas and Databases 3.3.6 Multiple Parents and DDL Migration 3.3.7 Many-to-Many Relationships 3.3.8 Self-Referential Integrity 3.3.9 PL/SQL Error Handling with Parent/Child Tables 3.3.10 The Deferrable Option 69 5685ch03.qxd_kp 11/6/03 1:36 PM Page 70 70 Chapter 3 • Declarative Constraints 3.4 CHECK 3.4.1 Multicolumn Constraint 3.4.2 Supplementing Unique Constraints 3.4.3 Students Table Example 3.4.4 Lookup Tables versus Check Constraints 3.4.5 Cardinality 3.4.6 Designing for Check Constraints 3.5 NOT NULL CONSTRAINTS 3.6 DEFAULT VALUES 3.7 MODIFYING CONSTRAINTS 3.8 EXCEPTION HANDLING 3.9 DATA LOADS This is the first of several chapters that cover enforcing business rules with con- straints.
    [Show full text]
  • Relational Data Model and SQL Data Definition Language
    The Relational Data Model and SQL Data Definition Language Paul Fodor CSE316: Fundamentals of Software Development Stony Brook University http://www.cs.stonybrook.edu/~cse316 1 The Relational Data Model A particular way of structuring data (using relations) proposed in 1970 by E. F. Codd Mathematically based Expressions ( queries) can be analyzed by DBMS and transformed to equivalent expressions automatically (query optimization) Optimizers have limits (=> the programmer still needs to know how queries are evaluated and optimized) 2 (c) Pearson Education Inc. and Paul Fodor (CS Stony Brook) Relational Databases In Relational DBs, the data is stored in tables Attributes (column Relation name: Student headers) Id Name Address Status 1111 John 123 Main fresh Tuples 2222 Mary 321 Oak (rows) 1234 Bob 444 Pine 9999 Joan 777 Grand senior 3 (c) Pearson Education Inc. and Paul Fodor (CS Stony Brook) Table Set of rows (no duplicates) Each row/tuple describes a different entity Each column/attribute states a particular fact about each entity Each column has an associated domain Id Name Address Status 1111 John 123 Main fresh 2222 Mary 321 Oak 1234 Bob 444 Pine 9999 Joan 777 Grand senior Domain of Id: integers Domain of Name: strings 4 Domain of(c) PearsonStatus Education= Inc.{fresh, and Paul Fodor soph, (CS Stony junior,Brook) senior} Relation A relation is the mathematical entity corresponding to a table: A relation R can be thought of as predicate R A tuple (x,y,z) is in the relation R iff R(x,y,z) is true Why Relations/Tables? Very simple model.
    [Show full text]