Chapter 3: Relational Model IStructure of Relational DatabasesConvert a ER Design to a Relational Database

RelationAnother name for tableColumns attributesRows tuplesContent of a table instance of a relation

Attribute TypesEach attribute of a relation has a nameThe set of allowed values for each attribute is called the domain of the attributeAttribute values are (normally) required to be atomic, that is, indivisibleE.g. multivalued attribute values are not atomicE.g. composite attribute values are not atomicThe special value null is a member of every domain

Example of a Relation

FormallyGiven sets D1, D2, . Dn a relation r is a subset of D1 x D2 x x Dn Thus a relation is a set of n-tuples (a1, a2, , an) where each ai Di

Relation Relates ThingsThings:customer-name = {Jones, Smith, Curry, Lindsay} customer-street = {Main, North, Park} customer-city = {Harrison, Rye, Pittsfield}RelationThen r = { (Jones, Main, Harrison), (Smith, North, Rye), (Curry, North, Rye), (Lindsay, Park, Pittsfield)} is a relation over customer-name x customer-street x customer-city

Relation SchemaA1, A2, , An are attributesR = (A1, A2, , An ) is a relation schemaE.g. Customer-schema = (customer-name, customer-street, customer-city)r(R) is a relation on the relation schema RE.g.customer (Customer-schema)

Relation InstanceThe current values (relation instance) of a relation are specified by a tableAn element t of r is a tuple, represented by a row in a tableJonesSmithCurryLindsaycustomer-nameMainNorthNorthParkcustomer-streetHarrisonRyeRyePittsfieldcustomer-citycustomerattributes(or columns)tuples(or rows)

Relations are Unordered Order of tuples is irrelevant (tuples may be stored in an arbitrary order)

DatabaseIn relational database, a database consists of many relationsBoth things and their relationships are represented by relationsNormalization theory (Chapter 7) deals with how to design relational schemas

KeysLet K RK is a superkey of R if values for K are sufficient to identify a unique tuple of each possible relation r(R) by possible r we mean a relation r that could exist in the enterprise we are modeling.Example: {customer-name, customer-street} and {customer-name} are both superkeys of Customer, if no two customers can possibly have the same name.

Candidate KeysK is a candidate key if K is minimal Example: {customer-name} is a candidate key for Customer, since it is a superkey (assuming no two customers can possibly have the same name), and no subset of it is a superkey.

Convert ER to Relational DatabaseEntity relationAttributes attributesPrimary key primary key Relationship relationAttributes attributesWe will talk about primary key later Weak entity set relationAttributes attributesWe will talk about primary key later

Representing Entity Sets as TablesA strong entity set reduces to a table with the same attributes.The primary key of the entity set becomes the primary key of the relation.

Composite AttributesComposite attributes are flattened out by creating a separate attribute for each component attributeE.g. given entity set customer with composite attribute name with component attributes first-name and last-name the table corresponding to the entity set has two attributes name.first-name and name.last-name

Multivalued AttributesA multivalued attribute M of an entity E is represented by a separate table EMTable EM has attributes corresponding to the primary key of E and an attribute corresponding to multivalued attribute ME.g. Multivalued attribute dependent-names of employee is represented by a table employee-dependent-names( employee-id, dname) Each value of the multivalued attribute maps to a separate row of the table EME.g., an employee entity with primary key John and dependents Johnson and Johndotir maps to two rows: (John, Johnson) and (John, Johndotir)

ExampleThe relation(s) the ER mapped to?customer(customer-id, first-name, last-name, middle-initial,date-of-birth,age,street-number,street-name,apartment-number,city,state,zip-code)customer-phone(customer-id,phone-number)

Representing Weak Entity SetsA weak entity set becomes a table that includes a column for the primary key of the identifying strong entity setThe primary key of the relation consists of the union of the primary key of the strong entity set and the discriminator of the weak entity set.

Weak Entity Example

Representing Relationship Sets as TablesA many-to-many relationship set is represented as a table with attributes from the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. E.g.: table for relationship set borrowerThe union of the primary keys of the related entity sets becomes a super key of the relation.

Many-to-many relationshipWhat is the relationship borrower has an attribute date?

Representing Relationship Sets as TablesMany-to-one and one-to-many relationship sets that are total on the many-side can be represented by adding an extra attribute to the many side, containing the primary key of the one sideE.g.: Instead of creating a table for relationship account-branch, add an attribute branch to the entity set accountthe primary key of the many entity set becomes the primary key that represents the relationship and the many sideIf participation is partial on the many side, replacing a table by an extra attribute in the relation corresponding to the many side could result in null values

account(account-number,balance)branch(branch-name,branch-city,assets)account-branch(account-number,branch-name)account(account-number,balance,branch-name)branch(branch-name,branch-city,assets)Redundancy!?

Representing Relationship Sets as TablesFor one-to-one relationship sets, either side can be chosen to act as the many sideThat is, extra attribute can be added to either of the tables corresponding to the two entity sets

Determining Keys from E-R SetsStrong entity set. The primary key of the entity set becomes the primary key of the relation.Weak entity set. The primary key of the relation consists of the union of the primary key of the strong entity set and the discriminator of the weak entity set.

Determining Keys from E-R SetsRelationship set. The union of the primary keys of the related entity sets becomes a super key of the relation.For binary many-to-one relationship sets, the primary key of the many entity set becomes the primary key that represent both the relationship and the many side. Why?What about one-to-one relationship sets. Why?For many-to-many relationship sets, the union of the primary keys becomes the relations primary key. Why?

Representing Specialization as TablesMethod 1: Form a table for the higher level entity Form a table for each lower level entity set, include primary key of higher level entity set and local attributes

Person(name, street, city)Customer(name, credit-rating)Employee(name, salary)Drawback: getting information about, e.g., employee requires accessing two tables

Representing Specialization as TablesMethod 2: Form a table for each entity set with all local and inherited attributesIf specialization is total, table for generalized entity (person) not required to store informationCan be defined as a view relation containing union of specialization tablesBut explicit table may still be needed for foreign key constraints

Person(name, street, city)Customer(name, street, city,credit-rating)Employee(name, street,citysalary)Drawback: street and city may be stored redundantly for persons who are both person and customers/employees

ER for Banking Enterprise

Schema Diagram for the Banking Enterprise

Convert the ER diagram to relational models.

**********************************