lec 04 logical database design and relational database

8/2/2019 LEC 04 Logical Database Design and Relational Database

1/12

2/16/2012

1

LOGICAL DATABASEDESIGN AND RELATIONALDATABASE

3

A relation is a named, two-dimensional table ofdata.A table consists of rows (records) and columns(attribute or field).

Relation

4

Requirements for a table to qualify as arelation:

It must have a unique name.Every attribute value must be simple.Every row must be unique.Attributes in tables must have unique names.The order of the columns must be irrelevant.The order of the rows must be irrelevant.

Relation6

Keys are special fields that serve two main purposes:Primary keys are unique identifiers of the rows in the relation.This is how we can guarantee that all rows are unique.Foreign keys are identifiers that enable a dependent relation torefer to its parent relation.

Keys can be simple (a single field) or composite (morethan one field).Keys usually are used as indexes to speed up theresponse to user queries.

Key Fields


2/12

2/16/2012

7

Figure 4-3 Schema for four relations (Furniture Company)

8

Constraints or rules limiting acceptable values andactions, whose purpose is to facilitate maintainingthe accuracy and integrity of data in the database.Domain Constraints

Allowable values for an attribute.Domain: set of values that may be assigned to anattribute

Entity IntegrityNo primary key attribute may be null. All primary keyfields MUST have data

Integrity Constraints

9

Domain definitions enforce domain integrity constraints

Integrity Constraints10

Referential IntegrityStates that any foreign key value (on the relation of themany side) MUST match a primary key value in therelation of the one side. (Or the foreign key can benull)

For example: Delete Rules

Cascade automatically delete dependent side rows thatcorrespond with the parent side row to be deletedRestrict dont allow delete of parent side if related rows existin dependent sideSet-to-Null set the foreign key in the dependent side to null ifdeleting from the parent side is not allowed for weak entities


3/12

2/16/2012

11

Figure 4-5Referential integrity constraints (Furniture shop)

Referentialintegrity constraints

are drawn viaarrows from

dependent to parenttable

12

Figure 4-6 SQL table definitions

Referentialintegrity constraints

are implementedwith foreign key to

primary keyreferences

Mapping Regular Entities to Relations13

Simple attributes: E-R attributes map directlyonto the relationComposite attributes: Use only their simple,component attributesMulti-valued attributes: Becomes a separate

relation with a foreign key taken from the superiorentity

14

(a) CUSTOMERentity type withsimpleattributes

Figure 4-8 Mapping a regular entity

(b) CUSTOMER relation


4/12

2/16/2012

15

(a) CUSTOMERentity type withcompositeattribute

Figure 4-9 Mapping a composite attribute

(b) CUSTOMER relation with address detail

16

Figure 4-10 Mapping an entity with a multivalued attribute

(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

Mapping Weak Entities17

Becomes a separate relation with a foreignkey taken from the superior entityPrimary key composed of:

Partial identifier of weak entityPrimary key of identifying relation (strong

entity)

18

Figure 4-11 Example of mapping a weak ent ity

a) Weak entity DEPENDENT


5/12

2/16/2012

19

NOTE: the domain constraintfor the foreign key shouldNOT allow null value if DEPENDENT is a weak entity

Foreign key

Composite primary key

Figure 4-11 Example of mapping a weak entity (cont.)

b) Relations resulting from weak entityMapping Binary Relationships

20

One-to-Many: Primary key on the one sidebecomes a foreign key on the many sideMany-to-Many: Create a new relation with theprimary keys of the two entities as its primarykeyOne-to-One: Primary key on the mandatoryside becomes a foreign key on the optional side

21

Figure 4-12 Example of mapping a 1:M relationship

a) Relationship between customers and orders

Note the mandatory one

b) Mapping the relationship

Foreign key

22

Figure 4-13 Example of mapping an M:N relationship

a) Completes relationship (M:N)

The Completes relationship will need to become a separate relation


6/12

2/16/2012

23

Newintersection

relation

Foreign key

Foreign key

Composite primary key

Figure 4-13 Example of mapping an M:N relationship (cont.)b) Three resulting relations

24

Figure 4-14 Example of mapping a binary 1:1 relationshipa) In charge relationship (1:1)

Often in 1:1 relationships, one direction is optional

25

b) Resulting relations

Figure 4-14 Example of mapping a binary 1:1 relationship (cont.)

Foreign key goes in the relation on the optional side,matching the primary key on the mandatory side

Mapping Associative Entities26

Identifier Not AssignedDefault primary key for the association relationis composed of the primary keys of the twoentities (same as M:N relationship)

Identifier AssignedIt is natural and familiar to end-users

Default identifier may not be unique


7/12

2/16/2012

27

Figure 4-15 Example of mapping an associative entitya) An associative entity

28

Figure 4-15 Example of mapping an associative entity (cont.)b) Three resulting relations

Composite primary key formed from the two foreign keys

29

Figure 4-16 Example of mapping an associative entity withan identifier

a) SHIPMENT associative entity

30

Figure 4-16 Example of mapping an associative entity withan identifier (cont.)

b) Three resulting relations

Primary key differs from foreign keys


8/12

2/16/2012

Mapping Unary Relationships31

One-to-Many: Recursive foreign key in the samerelationMany-to-Many: Two relations:

One for the entity typeOne for an associative relation in which theprimary key has two attributes, both takenfrom the primary key of the entity

32

Figure 4-17 Mapping a unary 1:N relationship

(a) EMPLOYEEentity with unaryrelationship

(b)EMPLOYEErelation withrecursiveforeign key

33

Figure 4-18 Mapping a unary M:N relationship

(a) Bill-of-materialsrelationships (M:N)

(b) ITEM andCOMPONENTrelations

Mapping Ternary (and n-ary) Relationships34

One relation for each entity and one for theassociative entityAssociative entity has foreign keys to eachentity in the relationship


9/12

2/16/2012

35

Figure 4-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship withassociative entity

36

b) Mapping the ternary relationship PATIENT TREATMENT

NOTE: Remember that the primary key MUST be unique

Figure 4-19 Mapping a ternary relationship (cont.)

Data Normalization37

Primarily a tool to validate and improve a logicaldesign so that it satisfies certain constraints thatavoid unnecessary duplication of data Goal: decompose relations with anomalies toproduce smaller, well-structured relationsAnomaly: an error or inconsistency that may result

when a user attempts to update a table that containsredundant data.

Well-Structured Relations38

A relation that contains minimal data redundancy andallows users to insert, delete, and update rows withoutcausing data inconsistenciesGoal is to avoid anomalies

Insertion Anomaly : adding new rows forces user tocreate duplicate dataDeletion Anomaly : deleting rows may cause a loss

of data that would be needed for other future rowsModification Anomaly : changing data in a rowforces changes to other rows because of duplication

General rule of thumb: A table should not pertain tomore than one entity type


10/12

2/16/2012

1

Question Is this a relation? Answer Yes: Unique rows and nomulti-valued attributes

Question Whats the primarykey?

Answer Composite: EmpID, CourseTitle

Anomalies in this Table40

Insertion cant enter a new employee withouthaving the employee take a classDeletion if we remove employee 140, we loseinformation about the existence of a Tax Acc classModification giving a salary increase to employee100 forces us to update multiple records

Why do these anomalies exist?Because there are two themes (entity types) in this onerelation. This results in data duplication and anunnecessary dependency between the entities

Functional Dependencies and Keys41

Functional Dependency: The value of oneattribute (the determinant ) determines thevalue of another attributeCandidate Key: A unique identifier. One of thecandidate keys will become the primary key

E.g. perhaps there is both credit card number andSS# in a tablein this case both are candidate keysEach non-key field is functionally dependent onevery candidate key

42

Steps in normalization

3rd normal form isgenerally consideredsufficient


11/12

2/16/2012

First Normal Form43

No multi-valued attributesEvery attribute value is atomicAll relations are in 1 st Normal Form

45

Insertion : if new product is ordered for order 1007 of existingcustomer, customer data must be re-entered, causingduplicationDeletion : if we delete the Dining Table from Order 1006, welose information concerning this item's finish and priceUpdate : changing the price of product ID 4 requires update in

multiple records

Second Normal Form47

1NF PLUS no partial functional dependencies

Partial functional dependency: exists when anon-key attribute is functionally dependent onpart of the primary key

Every non-key attribute must be defined bythe entire key, not by only part of the key

OrderID: OrderDate, CustomerID, CustomerName, CustomerAddressProductID: ProductDescription, ProductFinish, ProductStandardPrice

OrderID, ProductID: OrderQuantity

Functional dependency diagram for INVOICE


12/12

2/16/2012

49

Partial dependencies are removed, but thereare still transitive dependencies

Removing partial dependenciesThird Normal Form

50

2NF PLUS no transitive dependencies (functional dependency between the primary keyand one or more non-key attributes)Note: This is called transitive, because theprimary key is a determinant for another attribute,which in turn is a determinant for a thirdSolution: Non-key determinant with transitivedependencies go into a new table; non-keydeterminant becomes primary key in the newtable and stays as foreign key in the old table

Transitive dependencies are removed

Removing partial dependencies

lec 04 logical database design and relational database

Documents