Relational Database: Definitions Ex: Instance of Students Relation • Relational Database: a Set of Relations

Total Page:16

File Type:pdf, Size:1020Kb

Relational Database: Definitions Ex: Instance of Students Relation • Relational Database: a Set of Relations Why Study the Relational Model? • Most widely used model. The Relational Model – Vendors: IBM, Informix, Microsoft, Oracle, CS 186, Fall 2002, Lecture 4 Sybase, etc. R & G, Chap. 3 • “Legacy systems” in older models – e.g., IBM’s IMS Mine eye hath play’d the painter and hath stell’d • Object-oriented concepts have recently Thy beauty’s form in table of my heart. merged in – object-relational model Shakespeare, Sonnet XXIV • Informix, IBM DB2, Oracle 8i • Early work done in POSTGRES research project at Berkeley Relational Database: Definitions Ex: Instance of Students Relation • Relational database: a set of relations. • Relation: made up of 2 parts: – Schema : specifies name of relation, plus sid name login age gpa name and type of each column. 53666 Jones jones@cs 18 3.4 • E.g. Students(sid: string, name: string, 53688 Smith smith@eecs 18 3.2 login: string, age: integer, gpa: real) 53650 Smith smith@math 19 3.8 – Instance : a table, with rows and columns. •#rows = cardinality • Cardinality = 3, arity = 5 , all rows distinct •#fields = degree / arity • Do all values in each column of a relation instance • Can think of a relation as a set of rows or tuples. have to be distinct? – i.e., all rows are distinct SQL - A language for Relational DBs SQL Overview •CREATE TABLE <name> ( <field> <domain>, … ) • SQL (a.k.a. “Sequel”), standard language •INSERT INTO <name> (<field names>) • Data Definition Language (DDL) VALUES (<field values>) – create, modify, delete relations •DELETE FROM <name> – specify constraints WHERE <condition> – administer users, security, etc. • Data Manipulation Language (DML) •UPDATE <name> SET <field name> = <value> –Specify queries to find tuples that satisfy WHERE <condition> criteria – add, modify, remove tuples •SELECT <fields> FROM <name> WHERE <condition> 1 Creating Relations in SQL Table Creation (continued) • Creates the Students relation. – Note: the type (domain) of each field is • Another example: the Enrolled table holds specified, and enforced by the DBMS information about courses students take. whenever tuples are added or modified. CREATE TABLE Enrolled CREATE TABLE Students (sid CHAR(20), (sid CHAR(20), cid CHAR(20), name CHAR(20), grade CHAR(2)) login CHAR(10), age INTEGER, gpa FLOAT) Adding and Deleting Tuples Keys • Can insert a single tuple using: • Keys are a way to associate tuples in INSERT INTO Students (sid, name, login, age, gpa) different relations VALUES (‘53688’, ‘Smith’, ‘smith@ee’, 18, 3.2) • Keys are one form of integrity constraint (IC) • Can delete all tuples satisfying some condition (e.g., name = Smith): Enrolled Students sid cid grade DELETE 53666 Carnatic101 C sid name login age gpa 53666 Jones jones@cs 18 3.4 FROM Students S 53666 Reggae203 B 53650 Topology112 A 53688 Smith smith@eecs 18 3.2 WHERE S.name = ‘Smith’ 53666 History105 B 53650 Smith smith@math 19 3.8 Powerful variants of these commands are available; more later! FORIEGN Key PRIMARY Key Primary Keys Primary and Candidate Keys in SQL • A set of fields is a superkey if: • Possibly many candidate keys (specified using – No two distinct tuples can have same values in all key UNIQUE), one of which is chosen as the primary key. fields • Keys must be used carefully! • A set of fields is a key for a relation if : • “For a given student and course, there is a single grade.” –It is a superkey – No subset of the fields is a superkey CREATE TABLE Enrolled CREATE TABLE Enrolled (sid CHAR(20) • what if >1 key for a relation? (sid CHAR(20) cid CHAR(20), vs. cid CHAR(20), – one of the keys is chosen (by DBA) to be the primary grade CHAR(2), key. Other keys are called candidate keys. grade CHAR(2), PRIMARY KEY (sid,cid)) PRIMARY KEY (sid), • E.g. UNIQUE (cid, grade)) – sid is a key for Students. “Students can take only one course, and no two students – What about name? in a course receive the same grade.” –The set {sid, gpa} is a superkey. 2 Foreign Keys, Referential Integrity Foreign Keys in SQL • Foreign key : Set of fields in one relation • E.g. Only students listed in the Students relation that is used to `refer’ to a tuple in another should be allowed to enroll for courses. relation. – sid is a foreign key referring to Students: – Must correspond to the primary key of the other relation. CREATE TABLE Enrolled (sid CHAR(20),cid CHAR(20),grade CHAR(2), – Like a `logical pointer’. PRIMARY KEY (sid,cid), FOREIGN KEY (sid) REFERENCES Students ) • If all foreign key constraints are enforced, Enrolled referential integrity is achieved (i.e., no sid cid grade Students dangling references.) 53666 Carnatic101 C sid name login age gpa 53666 Reggae203 B 53666 Jones jones@cs 18 3.4 53650 Topology112 A 53688 Smith smith@eecs 18 3.2 53666 History105 B 53650 Smith smith@math 19 3.8 Enforcing Referential Integrity Integrity Constraints (ICs) • IC: condition that must be true for any • Consider Students and Enrolled; sid in Enrolled is a instance of the database; e.g., domain foreign key that references Students. constraints. • What should be done if an Enrolled tuple with a non- – ICs are specified when schema is defined. existent student id is inserted? (Reject it!) – ICs are checked when relations are • What should be done if a Students tuple is deleted? modified. – Also delete all Enrolled tuples that refer to it? • A legal instance of a relation is one that – Disallow deletion of a Students tuple that is referred to? satisfies all specified ICs. – Set sid in Enrolled tuples that refer to it to a default sid? – DBMS should not allow illegal instances. – (In SQL, also: Set sid in Enrolled tuples that refer to it to a special value null, denoting `unknown’ or `inapplicable’.) • If the DBMS checks ICs, stored data is more faithful to real-world meaning. • Similar issues arise if primary key of Students tuple is updated. – Avoids data entry errors, too! Where do ICs Come From? Logical DB Design: ER to Relational ssn name lot • ICs are based upon the semantics of the real-world • Entity sets to tables. that is being described in the database relations. 123-22-3666 Attishoo 48 name 231-31-5368 Smiley 22 • We can check a database instance to see if an IC is ssn lot violated, but we can NEVER infer that an IC is true 131-24-3650 Smethurst 35 by looking at an instance. Employees – An IC is a statement about all possible instances! – From example, we know name is not a key, but the assertion that sid is a key is given to us. CREATE TABLE Employees • Key and foreign key ICs are the most common; (ssn CHAR(11), more general ICs supported too. name CHAR(20), lot INTEGER, PRIMARY KEY (ssn)) 3 Relationship Sets to Tables Review: Key Constraints CREATE TABLE Works_In( • Each dept has at • In translating a many-to- ssn CHAR(1), most one since many relationship set to a did INTEGER, name dname manager, since DATE, ssn lot did budget relation, attributes of the according to the PRIMARY KEY (ssn, did), relation must include: key constraint on FOREIGN KEY (ssn) Manages. Employees Manages Departments 1) Keys for each REFERENCES Employees, participating entity set FOREIGN KEY (did) (as foreign keys). This REFERENCES Departments) set of attributes forms ssn did since a superkey for the Translation to relation. 123-22-3666 51 1/1/91 relational model? 123-22-3666 56 3/3/93 2) All descriptive 1-to-1 1-to Many Many-to-1 Many-to-Many attributes. 231-31-5368 51 2/2/92 Translating ER with Key Constraints Review: Participation Constraints since name dname • Does every department have a manager? ssn lot did budget – If so, this is a participation constraint: the participation of Employees Manages Departments Departments in Manages is said to be total (vs. partial). • Since each department has a unique manager, we •Every did value in Departments table must appear in a could instead combine Manages and Departments. row of the Manages table (with a non-null ssn value!) CREATE TABLE Manages( CREATE TABLE Dept_Mgr( since ssn CHAR(11), did INTEGER, name dname ssn lot did budget did INTEGER, dname CHAR(20), since DATE, Vs. budget REAL, Employees Manages Departments PRIMARY KEY (did), ssn CHAR(11), FOREIGN KEY (ssn) since DATE, Works_In REFERENCES Employees, PRIMARY KEY (did), FOREIGN KEY (did) FOREIGN KEY (ssn) REFERENCES Departments) REFERENCES Employees) since Participation Constraints in SQL Review: Weak Entities • We can capture participation constraints involving one • A weak entity can be identified uniquely only by entity set in a binary relationship, but little else considering the primary key of another (owner) entity. (without resorting to CHECK constraints). – Owner entity set and weak entity set must participate in a one-to-many relationship set (1 owner, many weak CREATE TABLE Dept_Mgr( entities). did INTEGER, dname CHAR(20), – Weak entity set must have total participation in this budget REAL, identifying relationship set. ssn CHAR(11) NOT NULL, name cost since DATE, ssn lot pname age PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, Employees Policy Dependents ON DELETE NO ACTION) 4 name ssn lot Translating Weak Entity Sets Review: ISA Hierarchies Employees • Weak entity set and identifying relationship hourly_wages hours_worked set are translated into a single table. ISA – When the owner entity is deleted, all owned weak As in C++, or other PLs, contractid entities must also be deleted. attributes are inherited. Hourly_Emps Contract_Emps If we declare A ISA B, every A CREATE TABLE Dep_Policy ( entity is also considered to be a B pname CHAR(20), entity. age INTEGER, • Overlap constraints: Can Joe be an Hourly_Emps as well as a cost REAL, Contract_Emps entity? (Allowed/disallowed) ssn CHAR(11) NOT NULL, • Covering constraints: Does every Employees entity also have PRIMARY KEY (pname, ssn), to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE) Translating ISA Hierarchies to Relations Relational Model: Summary • A tabular representation of data.
Recommended publications
  • Foreign(Key(Constraints(
    Foreign(Key(Constraints( ! Foreign(key:(a(rule(that(a(value(appearing(in(one(rela3on(must( appear(in(the(key(component(of(another(rela3on.( – aka(values(for(certain(a9ributes(must("make(sense."( – Po9er(example:(Every(professor(who(is(listed(as(teaching(a(course(in(the( Courses(rela3on(must(have(an(entry(in(the(Profs(rela3on.( ! How(do(we(express(such(constraints(in(rela3onal(algebra?( ! Consider(the(rela3ons(Courses(crn,(year,(name,(proflast,(…)(and( Profs(last,(first).( ! We(want(to(require(that(every(nonLNULL(value(of(proflast(in( Courses(must(be(a(valid(professor(last(name(in(Profs.( ! RA((πProfLast(Courses)((((((((⊆ π"last(Profs)( 23( Foreign(Key(Constraints(in(SQL( ! We(want(to(require(that(every(nonLNULL(value(of(proflast(in( Courses(must(be(a(valid(professor(last(name(in(Profs.( ! In(Courses,(declare(proflast(to(be(a(foreign(key.( ! CREATE&TABLE&Courses&(& &&&proflast&VARCHAR(8)&REFERENCES&Profs(last),...);& ! CREATE&TABLE&Courses&(& &&&proflast&VARCHAR(8),&...,&& &&&FOREIGN&KEY&proflast&REFERENCES&Profs(last));& 24( Requirements(for(FOREIGN(KEYs( ! If(a(rela3on(R(declares(that(some(of(its(a9ributes(refer( to(foreign(keys(in(another(rela3on(S,(then(these( a9ributes(must(be(declared(UNIQUE(or(PRIMARY(KEY(in( S.( ! Values(of(the(foreign(key(in(R(must(appear(in(the( referenced(a9ributes(of(some(tuple(in(S.( 25( Enforcing(Referen>al(Integrity( ! Three(policies(for(maintaining(referen3al(integrity.( ! Default(policy:(reject(viola3ng(modifica3ons.( ! Cascade(policy:(mimic(changes(to(the(referenced( a9ributes(at(the(foreign(key.( ! SetLNULL(policy:(set(appropriate(a9ributes(to(NULL.(
    [Show 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.
    [Show full text]
  • Referential Integrity in Sqlite
    CS 564: Database Management Systems University of Wisconsin - Madison, Fall 2017 Referential Integrity in SQLite Declaring Referential Integrity (Foreign Key) Constraints Foreign key constraints are used to check referential integrity between tables in a database. Consider, for example, the following two tables: create table Residence ( nameVARCHARPRIMARY KEY, capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR ); We can enforce the constraint that a Student’s residence actually exists by making Student.residence a foreign key that refers to Residence.name. SQLite lets you specify this relationship in several different ways: create table Residence ( nameVARCHARPRIMARY KEY, capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR, FOREIGNKEY(residence) REFERENCES Residence(name) ); or create table Residence ( nameVARCHARPRIMARY KEY, capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR REFERENCES Residence(name) ); or create table Residence ( nameVARCHARPRIMARY KEY, 1 capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR REFERENCES Residence-- Implicitly references the primary key of the Residence table. ); All three forms are valid syntax for specifying the same constraint. Constraint Enforcement There are a number of important things about how referential integrity and foreign keys are handled in SQLite: • The attribute(s) referenced by a foreign key constraint (i.e. Residence.name in the example above) must be declared UNIQUE or as the PRIMARY KEY within their table, but this requirement is checked at run-time, not when constraints are declared. For example, if Residence.name had not been declared as the PRIMARY KEY of its table (or as UNIQUE), the FOREIGN KEY declarations above would still be permitted, but inserting into the Student table would always yield an error.
    [Show full text]
  • Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains
    Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual.
    [Show full text]
  • (DDL) Reference Manual
    Data Definition Language (DDL) Reference Manual Abstract This publication describes the DDL language syntax and the DDL dictionary database. The audience includes application programmers and database administrators. Product Version DDL D40 DDL H01 Supported Release Version Updates (RVUs) This publication supports J06.03 and all subsequent J-series RVUs, H06.03 and all subsequent H-series RVUs, and G06.26 and all subsequent G-series RVUs, until otherwise indicated by its replacement publications. Part Number Published 529431-003 May 2010 Document History Part Number Product Version Published 529431-002 DDL D40, DDL H01 July 2005 529431-003 DDL D40, DDL H01 May 2010 Legal Notices Copyright 2010 Hewlett-Packard Development Company L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Export of the information contained in this publication may require authorization from the U.S. Department of Commerce. Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation. Intel, Itanium, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
    [Show full text]
  • The Unconstrained Primary Key
    IBM Systems Lab Services and Training The Unconstrained Primary Key Dan Cruikshank www.ibm.com/systems/services/labservices © 2009 IBM Corporation In this presentation I build upon the concepts that were presented in my article “The Keys to the Kingdom”. I will discuss how primary and unique keys can be utilized for something other than just RI. In essence, it is about laying the foundation for data centric programming. I hope to convey that by establishing some basic rules the database developer can obtain reasonable performance. The title is an oxymoron, in essence a Primary Key is a constraint, but it is a constraint that gives the database developer more freedom to utilize an extremely powerful relational database management system, what we call DB2 for i. 1 IBM Systems Lab Services and Training Agenda Keys to the Kingdom Exploiting the Primary Key Pagination with ROW_NUMBER Column Ordering Summary 2 www.ibm.com/systems/services/labservices © 2009 IBM Corporation I will review the concepts I introduced in the article “The Keys to the Kingdom” published in the Centerfield. I think this was the inspiration for the picture. I offered a picture of me sitting on the throne, but that was rejected. I will follow this with a discussion on using the primary key as a means for creating peer or subset tables for the purpose of including or excluding rows in a result set. The ROW_NUMBER function is part of the OLAP support functions introduced in 5.4. Here I provide some examples of using ROW_NUMBER with the BETWEEN predicate in order paginate a result set.
    [Show full text]
  • Keys Are, As Their Name Suggests, a Key Part of a Relational Database
    The key is defined as the column or attribute of the database table. For example if a table has id, name and address as the column names then each one is known as the key for that table. We can also say that the table has 3 keys as id, name and address. The keys are also used to identify each record in the database table . Primary Key:- • Every database table should have one or more columns designated as the primary key . The value this key holds should be unique for each record in the database. For example, assume we have a table called Employees (SSN- social security No) that contains personnel information for every employee in our firm. We’ need to select an appropriate primary key that would uniquely identify each employee. Primary Key • The primary key must contain unique values, must never be null and uniquely identify each record in the table. • As an example, a student id might be a primary key in a student table, a department code in a table of all departments in an organisation. Unique Key • The UNIQUE constraint uniquely identifies each record in a database table. • Allows Null value. But only one Null value. • A table can have more than one UNIQUE Key Column[s] • A table can have multiple unique keys Differences between Primary Key and Unique Key: • Primary Key 1. A primary key cannot allow null (a primary key cannot be defined on columns that allow nulls). 2. Each table can have only one primary key. • Unique Key 1. A unique key can allow null (a unique key can be defined on columns that allow nulls.) 2.
    [Show full text]
  • 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]
  • The Relational Data Model and Relational Database Constraints
    chapter 33 The Relational Data Model and Relational Database Constraints his chapter opens Part 2 of the book, which covers Trelational databases. The relational data model was first introduced by Ted Codd of IBM Research in 1970 in a classic paper (Codd 1970), and it attracted immediate attention due to its simplicity and mathematical foundation. The model uses the concept of a mathematical relation—which looks somewhat like a table of values—as its basic building block, and has its theoretical basis in set theory and first-order predicate logic. In this chapter we discuss the basic characteristics of the model and its constraints. The first commercial implementations of the relational model became available in the early 1980s, such as the SQL/DS system on the MVS operating system by IBM and the Oracle DBMS. Since then, the model has been implemented in a large num- ber of commercial systems. Current popular relational DBMSs (RDBMSs) include DB2 and Informix Dynamic Server (from IBM), Oracle and Rdb (from Oracle), Sybase DBMS (from Sybase) and SQLServer and Access (from Microsoft). In addi- tion, several open source systems, such as MySQL and PostgreSQL, are available. Because of the importance of the relational model, all of Part 2 is devoted to this model and some of the languages associated with it. In Chapters 4 and 5, we describe the SQL query language, which is the standard for commercial relational DBMSs. Chapter 6 covers the operations of the relational algebra and introduces the relational calculus—these are two formal languages associated with the relational model.
    [Show full text]
  • Pizza Parlor Point-Of-Sales System CMPS 342 Database
    1 Pizza Parlor Point-Of-Sales System CMPS 342 Database Systems Chris Perry Ruben Castaneda 2 Table of Contents PHASE 1 1 Pizza Parlor: Point-Of-Sales Database........................................................................3 1.1 Description of Business......................................................................................3 1.2 Conceptual Database.........................................................................................4 2 Conceptual Database Design........................................................................................5 2.1 Entities................................................................................................................5 2.2 Relationships....................................................................................................13 2.3 Related Entities................................................................................................16 PHASE 2 3 ER-Model vs Relational Model..................................................................................17 3.1 Description.......................................................................................................17 3.2 Comparison......................................................................................................17 3.3 Conversion from E-R model to relational model.............................................17 3.4 Constraints........................................................................................................19 4 Relational Model..........................................................................................................19
    [Show full text]
  • Normalization Exercises
    DATABASE DESIGN: NORMALIZATION NOTE & EXERCISES (Up to 3NF) Tables that contain redundant data can suffer from update anomalies, which can introduce inconsistencies into a database. The rules associated with the most commonly used normal forms, namely first (1NF), second (2NF), and third (3NF). The identification of various types of update anomalies such as insertion, deletion, and modification anomalies can be found when tables that break the rules of 1NF, 2NF, and 3NF and they are likely to contain redundant data and suffer from update anomalies. Normalization is a technique for producing a set of tables with desirable properties that support the requirements of a user or company. Major aim of relational database design is to group columns into tables to minimize data redundancy and reduce file storage space required by base tables. Take a look at the following example: StdSSN StdCity StdClass OfferNo OffTerm OffYear EnrGrade CourseNo CrsDesc S1 SEATTLE JUN O1 FALL 2006 3.5 C1 DB S1 SEATTLE JUN O2 FALL 2006 3.3 C2 VB S2 BOTHELL JUN O3 SPRING 2007 3.1 C3 OO S2 BOTHELL JUN O2 FALL 2006 3.4 C2 VB The insertion anomaly: Occurs when extra data beyond the desired data must be added to the database. For example, to insert a course (CourseNo), it is necessary to know a student (StdSSN) and offering (OfferNo) because the combination of StdSSN and OfferNo is the primary key. Remember that a row cannot exist with NULL values for part of its primary key. The update anomaly: Occurs when it is necessary to change multiple rows to modify ONLY a single fact.
    [Show full text]
  • Data Definition Language
    1 Structured Query Language SQL, or Structured Query Language is the most popular declarative language used to work with Relational Databases. Originally developed at IBM, it has been subsequently standard- ized by various standards bodies (ANSI, ISO), and extended by various corporations adding their own features (T-SQL, PL/SQL, etc.). There are two primary parts to SQL: The DDL and DML (& DCL). 2 DDL - Data Definition Language DDL is a standard subset of SQL that is used to define tables (database structure), and other metadata related things. The few basic commands include: CREATE DATABASE, CREATE TABLE, DROP TABLE, and ALTER TABLE. There are many other statements, but those are the ones most commonly used. 2.1 CREATE DATABASE Many database servers allow for the presence of many databases1. In order to create a database, a relatively standard command ‘CREATE DATABASE’ is used. The general format of the command is: CREATE DATABASE <database-name> ; The name can be pretty much anything; usually it shouldn’t have spaces (or those spaces have to be properly escaped). Some databases allow hyphens, and/or underscores in the name. The name is usually limited in size (some databases limit the name to 8 characters, others to 32—in other words, it depends on what database you use). 2.2 DROP DATABASE Just like there is a ‘create database’ there is also a ‘drop database’, which simply removes the database. Note that it doesn’t ask you for confirmation, and once you remove a database, it is gone forever2. DROP DATABASE <database-name> ; 2.3 CREATE TABLE Probably the most common DDL statement is ‘CREATE TABLE’.
    [Show full text]