CPSC 603 Database Systems Lecturer: Laurie Webster II, M.S.S.E., M.S.E.E., M.S.BME, Ph.D., P.E. Lecture 3 Introduction to a First Course in Database Systems

CPSC 603 Database Systems Design Principles We have yet to learn many of the details of the E/R model. We have enough to begin study of the crucial issues of what constitutes a good design and what should be avoided

Design Principle - Faithfulness First and Foremost - Design Should Be Faithful to the Specifications of the Application ==> Entity Sets and their attributes should reflect REALITY Example: We can’t attach an attribute number- of-cylinders to Entity Stars although it makes sense for an Entity Automobile

Design Faithfulness EXAMPLE 2.12 of Text: Stars-In Movies Stars m m many - many ==> Real World tells us that Stars can appear in more than one movie, and Movies can have more than one star

Design Faithfulness Sometimes it is less obvious what the REAL WORLD requires us to do in an E/R model Consider Entity Sets Courses and Instructors with a relationship Teaches between them Courses Teaches Instructors Is Teaches many-one from Courses to Instructors?

Design Faithfulness Sometimes it is less obvious what the REAL WORLD requires us to do in an E/R model Consider Entity Sets Courses and Instructors with a relationship Teaches between them Teaches Courses Instructors Is Teaches many-one from Courses to Instructors? The Answer lies in the policy and intentions of the organization creating the database.

Design Faithfulness School Policy: Can be only one instructor for each course. - Even if several instructors may “team-teach” a course, the school may require that exactly one of them be listed in the database as the instructor responsible for the course In these cases we would make Teaches a many-one relationship form Courses to Instructors

Design Faithfulness Alternative Policy –School may use a team of instructors regularly and wish its database to allow several instructors to be associated with a course –Or, the intent of the Teaches relationship may not be to reflect the current teacher of a course, but rather those who have ever taught the course, or those who are capable of teaching the course We cannot tell simply from the name of the relationship so make Teaches be many-many

Avoiding Redundancy Say Everything ONCE ONLY Avoiding REDUNDANCY => avoid saying the same thing more than once Wastes Space and Encourages Inconsistency REAL PROBLEM for DATABASES !!!

Avoiding Redundancy EXAMPLE ManfBy Beers Manfs name addr Good Design

Avoiding Redundancy Beers name manf manf addr Bad: Repeats manufacturer’s address for each beer they manufacture

Simplicity Counts Avoid introducing more elements into your design than is absolutely necessary moviesRepresents Holdings owns studios A Poor Design with an Unnecessary Entity Set Representsthe REAL WORLD

Modeling of Constraints a)So far we have seen how to model a slice of the real world using entity sets and relationships b)HOWEVER, there are some other important aspects of the REAL WORLD that we cannot model with the tools seen so far c)This additional information often takes the form of constraints on the data that go beyond the structural and type constraints imposed by E.S., attributes, and relationships

Classification of Constraints Keys are attributes or sets of attributes that uniquely identify an entity within its entity set = key constraint Single-value constraints are requirements that the value in a certain context be unique Referential Integrity constraints are requirements that a value referred to by some object actually exists in the database Domain constraints require that the value of an attribute must be drawn from a specific set of values or lie within a specific range

Classification of Constraints An important Constraint on the entities of an entity type is the key or uniqueness constraint on attributes An entity type usually has an attribute whose vaues are distinct for each individual entity in the collection => such an attribute is called a key attribute

Use Schema to Enforce Constraints The Design Schema should enforce as many constraints as possible ==> Don’t rely on users to follow assumptions EXAMPLE If the registrar wants to associate only one instructor with a course, don’t allow sets of instructors and count on departments to enter only one instructor per course

Use Schema to Enforce Constraints Domain –A domain is a set of atomic values, i.e. every value in the domain is indivisible as far as the relational model is concerned –A common method of specifying a domain is to specify a data type from which the data values forming the domain are drawn Useful also to specify a name for the domain –EXAMPLE USA_phone_numbers: The set of 10 digit phone numbers valid in the US Local_phone_numbers: The set of 7 digit phone numbers valid within a particular area code in the United States Names: The set of names of persons

Relation Schema A relation schema R, denoted by –R(A 1, A 2, ……, A n ) Relation name R List of attributes A 1, A 2, ……, A n

Relation Schema Each attribute A i is the name of a role played by some domain D in the relation schema R D is called the domain of A i and is denoted dom (A i ) A relation schema R is used to describe a relation where R is the name of the relation The degree of a relation is the number of attributes n of its relation schema

Relation Schema Example of Relation Schema of degree 7 R(A 1, A 2, ……, A n ) ==> Student ( Name, SSN, HomePhone, Address, OfficePhone, Age, GPA) degree = 7 because there are seven attributes describes a relation schema for a university student

Relation Schema A relation (or relation state) r of the relation schema R(A 1, A 2, ……, A n ), also denoted r(R), is a set of n-tuples r = (t 1, t 2, ….., t m ) Each n-tuple t is an ordered list of n values –t =, where each value v i, 1  i  n, is an element of dom(A i ) or is a special null value. –The i th value in tuple t, which corresponds to the attribute A i, is referred to as t[A i ].

Relation Schema a) A relation state r(R) is a mathematical relation of degree n on the domains dom (A 1 ), dom (A 2 ),…,dom (A n ), which is a subset of the Cartesian product of the domains that define R: r(R)  (dom (A 1 ) × dom (A 2 ) ×… × dom (A n ) ) b) The Cartesian product specifies all possible combinations of values from the underlying domains.

Relation Schema c)If we denote the number of values or cardinality of a domain D by  D , and assume that all domains are finite, the total number of tuples in the Cartesian product is:  dom (A 1 )  *  dom (A 2 )  *……*  dom (A n )  Out of all of these possible combinations, a relation state r(R) at a given time - the current relation state - reflects only the valid tuples that represent a particular state of the REAL WORLD

Next Lecture Modeling of Constraints Weak Entity Sets Summary of Chapter 2 Relational Data Model-Conversion from ER Introduction