1. CMPE 226 Database Systems September 9 Class Meeting Department of Computer Engineering San Jose State University Fall 2015 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Teams? 2

3. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #1  Construct a single MySQL database table that contains some data. Your choice of fields and data values.  Create an HTML page containing various types of input (text, checkboxes, radio buttons, etc.).  Create a PHP page that makes different queries of the database table based on the form data.  Dynamically generate a web page that displays the query results. 3

4. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #1, cont’d  Make screen shots of your web pages.  Create a “dump” of your database with the mysqldump command located in the XAMPP bin directory: Note: No space between –p and the password. Example: The output file create.sql will allow the graders to recreate your database table. 4 mysqldump –u username –p password dbname > create.sql mysqldump -u supercoders -psesame supercoders > create.sql

5. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #1, cont’d  Create a zip file named after your team (e.g., supercoders.zip ) containing: Your.html and.php files. Output from the mysqldump command. Screen shots of your web pages.  Email to ron.mak@sjsu.eduron.mak@sjsu.edu Subject line: CMPE 226 Assignment #1 team name CC all team members. 5

6. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #1, cont’d  This is a team assignment. One submission per team. Each team member receives the same score.  Due Friday, Sept. 11 at 11:59 PM. 6

7. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP Syntax  Very similar to C. End each statement with a semicolon.  Case sensitive: variables, constants, array keys class properties and constraints  Case insensitive: functions (pre-defined and user-defined) class constructors and methods reserved words 7

8. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP Variables  All variable names start with $.  PHP is a dynamically typed language. You don’t declare a variable’s type. A variable can be assigned a value of any type.  PHP data types scalar: integer, float, boolean, string array object resource NULL 8

9. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP Strings  Enclose a string with single or double quotes. Examples:  Variables embedded in a double-quoted string are evaluated: But not: 9 "Hello, world!" 'Hello, world!' "It's a nice day." 'Define "string" for me.' "Define \"string\" please." "The first name is $first." 'The first name is $first.'

10. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP String Operations  The string concatenation operator is.  Some string functions: strlen() strtoupper() strtolower() ucwords() capitalize the first letter of every word 10 Demo $name = $last. ", ". $first; $name.= ", Esq.";

11. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Heredocs  Use a heredoc to avoid string quoting issues. Example: 11 $first = "John"; $last = "Smith"; print <<<HERE First name: $first Last name: $last HERE; Must be on a line by itself with no indentation. Demo

12. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP Constants  Name constants with all uppercase letters, by convention. Constants are not variables, so do not use $.  Examples But not: 12 define (PI, 3.1415926); define (HOST_NAME, "localhost"); print "Host name is ". HOST_NAME; print "Host name is HOST_NAME";

13. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Two Kinds of PHP Arrays  Indexed array Indexes are integers.  Associative array Indexes are strings. key-value pairs, like a hash table. 13

14. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Creating PHP Indexed Arrays  Use the array() function:  Specify the first index value. Subsequent elements are indexed incrementally.  An array of sequential numbers: 14 $bands[] = "Beatles"; $bands[] = "Rolling Stones"; $bands[] = "Queen"; $bands = array("Beatles", "Rolling Stones", "Queen"); $bands = array(2=>"Beatles", "Rolling Stones", "Queen"); $values = range(5, 10);

15. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Creating PHP Associative Arrays  Use the array() function: 15 $states["CA"] = "California"; $states["NY"] = "New York"; $states["TX"] = "Texas"; $states = array( "CA" => "California", "NY" => "New York", "TX" => "Texas" ); An associative array is like a hash table.

16. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Looping over Array Elements  Use the foreach statement: Examples: 16 foreach ($ arrayname as $ variable ) { … } foreach ($ arrayname as $ key => $ value ) { … } foreach ($bands as $bandName) { print $bandName; } foreach ($states as $abbrev => $fullName) { print "State $fullName is abbreviated $abbrev"; } Demo

17. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Multidimensional Arrays 17 $north = array("ND" => "North Dakota", "MN" => "Minnesota"); $south = array("TX" => "Texas", "FL" => "Florida"); $east = array("NY" => "New York", "ME" => "Maine"); $west = array("CA" => "California", "OR" => "Oregon"); $us = array( "N" => $north, "S" => $south, "E" => $east, "W" => $west ); Demo

18. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP Functions  Syntax for programmer-defined functions: Examples:  A function can optionally return a value. 18 function name ( optional arguments ) { // statements in the body } function doSomething() { … } function sayHello($first, $last) { … } function greet($name, $language = "English") { … } function calculate($input, &$output) { … } return value ; Default value Passed by reference

19. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Scope of PHP Variables  Variables have the scope of the PHP file in which they reside.  A programmer-defined function creates a scope for its variables. Variables defined in a function cannot be accessed outside the function. Variables defined outside the function are not accessible inside the function.  Use the global statement inside a function to access outside variables. Example: 19 global $outsideVar;

20. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PHP Data Objects (PDO)  Create a database abstraction layer: 20 PostgresMySQLOracle PHP Data Objects (PDO) PHP query() PDO documentation: http://php.net/manual/en/book.pdo.php

21. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PDO Examples  Create a new PDO object to represent the database connection.  Set the error mode attribute to throw an exception if there is an error. 21 // Connect to the database. $con = new PDO("mysql:host=localhost;dbname=supercoders", "supercoders", "sesame"); $con->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

22. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PDO Examples, cont’d  PDO::query() executes an SQL statement and returns a result set as a PDOStatement object.  PDOStatement::fetch() fetches the next row of the result set. PDO::FETCH_ASSOC returns the row as an associative array indexed by column names. 22 // Fetch the database field names. $result = $con->query($query); $row = $result->fetch(PDO::FETCH_ASSOC);

23. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PDO Examples, cont’d  Extract the column (field) names of the fetched row to construct the header row of the HTML table. 23 // Construct the header row of the HTML table. print " \n"; foreach ($row as $field => $value) { print " $field \n"; } print " \n";

24. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak PDO Examples, cont’d  PDOStatement::setFetchMode sets the default fetch mode for this statement. 24 // Fetch the matching database table rows. $data = $con->query($query); $data->setFetchMode(PDO::FETCH_ASSOC); // Construct the HTML table row by row. foreach ($data as $row) { print " \n"; foreach ($row as $name => $value) { print " $value \n"; } print " \n"; }

25. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Database System Architecture  Database system: A computer-based system that enables efficient interaction between users and information stored in a database. 25 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

26. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Steps to Develop a Database  It’s an iterative process! 26 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

27. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Database Requirements  First and most critical step: Collect, define, and visualize requirements.  What data will the database hold and how?  What will be the capabilities and functionalities of the database?  Use the requirements to model and implement the database and to create the front-end applications. 27

28. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Conceptual Database Model  Visualize the requirements.  Use a conceptual data modeling technique. Example: Entity-relationship (ER) modeling  Implementation independent: No dependencies on the logic of a particular database management system (DBMS). Example DBMS: Oracle, MySQL, etc.  Blueprint for the logical model. 28

29. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Logical Database Model  Create the relational database model. Later: Non-relational NoSQL models.  It’s usually straightforward to map an ER model to a relational model. 29

30. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Physical Database Model  The physical model is the actual database implementation.  Use relational DBMS (RDBMS) software. Later: NoSQL systems  Structured Query Language (SQL) commands to create, delete, modify, and query database structures. 30

31. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Front-End Application Development  End users generally do not access the database directly.  Front-end applications Access the database directly. Provide end users with safe application-oriented interfaces to query and manipulate the data. Fulfill the end user’s requirements. 31

32. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Operational vs. Analytical Databases  Operational database Supports day-to-day operational business needs. Contains operational (transactional) information.  Analytical database Supports analytical business tasks. Contains analytical information.  Examples: usage patterns, sales trends, etc.  Derived from operational information. Often associated with data warehousing. 32

33. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Break 33

34. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Entities and Attributes  Entity Represents a real-world concept.  Examples: customer, product, store, event, etc. Data that the database stores.  Attribute Characteristic of an entity that the database stores.  Examples (for a customer): name, address, id, etc. A unique attribute of an entity has a value that is different for each entity instance. 34

35. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Entities and Attributes, cont’d  In an ER diagram (ERD), show an entity with a rectangle and its attributes with ovals. Underline the unique attribute. 35 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

36. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Entities and Attributes, cont’d  An entity can have multiple unique attributes. Each one is called a candidate key. 36 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

37. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Composite Attributes  A composite attribute is composed of several attributes. Parenthesize the name of the composite attribute. 37 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

38. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Composite Attributes, cont’d  An entity’s unique attribute can be composite. 38 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

39. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Multivalued Attributes  An entity instance can have multiple values for an attribute.  If the number of values is fixed, we can use a composite attribute instead. 39 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

40. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Derived Attributes  The value of a derived attribute is not stored. It’s calculated from the values of the other attributes and additional data such as the current date. Show with a dashed oval. 40 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

41. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Optional Attributes  An optional attribute does not always have to have a value. Indicate with (O). 41 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

42. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Relationships  Each entity in an ER diagram must be related to at least one other entity.  Show a relationship with a diamond and connect the diamond to the entities that are part of the relationship. 42 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

43. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Relationship Cardinality  Show cardinality (how many instances of an entity) with symbols at the end of the relationship lines. Maximum symbol closest to the entity. Minimum symbol further away. Zero, one, many 43 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

44. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Relationship Cardinality, cont’d  Read each relationship in both directions in this order: rectangle diamond cardinality rectangle 44 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

45. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Types of Relationships  One-to-one (1:1)  One-to-many (1:M) 45 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

46. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Types of Relationships, cont’d  Many-to-many (M:N) 46 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

47. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Exact Cardinalities  Indicate exact cardinalities with parenthesized minimum and maximum values. Example: (2, 6) Use M for a non-specific minimum or maximum. 47 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

48. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Relationship Attributes  An relationship can also have attributes. 48 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

49. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Unary Relationships  In a unary relationship, an entity is involved in a relationship with itself. One instance has a relationship with another instance of the same entity. You can indicate the relationship role. 49 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

50. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Multiple Relationships  Two entities can have multiple relationships with each other. 50 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

51. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Weak Entities  A weak entity does not have its own unique attribute. It only has a partial key. Underline the partial key with dashes.  Therefore, it must be associated with an owner entity via an identifying relationship. Indicate the weak entity and the identifying relationship with double borders.  The partial key and the owner attribute’s unique attribute uniquely identifies the weak entity. 51

52. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Weak Entities, cont’d 52 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

53. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Associative Entities  An associative entity is an alternate way to depict a many-to-many (M:N) relationship. 53 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

54. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Associative Entities, cont’d  Associative entity for a unary M:N relationship. 54 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

55. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak ER Diagram Example 55 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

56. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2  Create an ER diagram (ERD) for a database to enable a university to schedule classes during the school year.  The university consists of multiple schools (science, engineering, humanities, etc.).  Each school has a unique id and multiple departments. 56

57. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Each department has a unique id, a full name and an abbreviation (e.g., Computer Engineering and CMPE).  Each department schedules multiple classes.  A school year consists of multiple semesters (fall, spring, summer).  Each semester has 10-16 weeks.  Each class has one or more sections. 57

58. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Each class section has a label and a name (e.g., CMPE 226-04 Database Design).  The class label consists of the department abbreviation, a class number, and a section.  The class number is unique only within its department.  A class section is scheduled during a certain time period (e.g., 1800-2045) on certain days (MTWRF) during certain semesters. 58

59. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Each class section has a location (e.g, Clark 200), maximum capacity, and a calculated current enrollment.  Each location consists of a building name and room number.  The room number is unique only within its building. 59

60. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  A class section has one instructor and at least 15 students.  A student can take any number of different classes, including none.  A student has a grade level (freshman, sophomore, junior, senior, or graduate).  A class section optionally has a grader.  A grader grades one or more class sections. 60

61. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Each person (instructor, student, grader) has an id, a name, a gender (M or F), an address, and zero or more phone numbers.  An address consists of a house number, street, optional apartment number, city, state, and zip code. 61

62. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Or, you can create an ER diagram for your team database project instead (the preferred option). Minimum requirements: At least 8 entities including at least one weak entity Different types of relationships and cardinalities Optional and derived attributes Multivalued attributes (e.g., phone numbers) Composite attributes (e.g., address) Some hierarchical data (e.g., university  school  department) 62

63. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  If your ER diagram is for your team database project, you must also list your database’s requirements. This ER diagram will be your preliminary design. You can make changes during the semester.  Use standard Chen ER notation from the textbook and these slides. Free ERDPlus drawing tool: https://erdplus.com/#/https://erdplus.com/#/ 63

64. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Turn in a zip file containing: A screen shot, PDF, or JPEG, etc. of your ERD. Your database requirements (if the ERD is for your team database project) Name the zip file after your team, e.g. Supers.zip 64

65. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Assignment #2, cont’d  Email as an attachment to ron.mak@sjsu.eduron.mak@sjsu.edu Subject: CMPE 226 Assignment #2 Team Name  One email per team. CC all team members  Due Tuesday, September 15 at 11:59 PM 65

66. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Logical Database Model  Map the ER diagram to a logical model represented as a relational schema. 66 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

67. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Conditions for a Table to be a Relation  Each column must have a name. Within a table, each column name must be unique.  All values in each column must be from the same (predefined) domain.  Within a table, each row must be unique.  Within each row, each value in each column must be single-valued. M ultiple values of the content represented by the column are not allowed in any rows of the table. 67

68. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Relational vs. Non-Relational Tables 68 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

69. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Additional Properties for a Relational Table  The order of columns is irrelevant.  The order of rows is irrelevant. 69

70. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Primary Key  Each relation must have a primary key. A column or set of columns whose value uniquely identifies each row. Underline the primary key of the relational table. 70 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

71. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Mapping Entities 71 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

72. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Mapping Entities, cont’d 72 Entity with a composite attribute. As mapped. As seen by a front-end application. Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

73. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Mapping Entities, cont’d 73 Attribute with a composite primary key. Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

74. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Mapping Entities, cont’d 74 Entity with an optional attribute. Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

75. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Entity Integrity Constraint  No primary key column of a relational table can have null (empty) values. 75 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6

76. Computer Engineering Dept. Fall 2015: September 9 CMPE 226: Database Systems © R. Mak Entity Integrity Constraint, cont’d 76 Database Systems by Jukić, Vrbsky, & Nestorov Pearson 2014 ISBN 978-0-13-257567-6