LOGICAL DATABASE DESIGN pptx

Logical Database Design Lesson 2A / Slide 1 of 15©NIIT Logical Database Design Objectives In this section, you will learn to: • Map an E/R diagram to tables in relation to the following:

L ESSON : 2A

Objectives

In this lesson, you will learn to:

Map an E/R Diagram to Tables in relation to the following:

Logical Database Design Lesson 2A / Slide 1 of 15

©NIIT

Logical Database Design

Objectives

In this section, you will learn to:

• Map an E/R diagram to tables in relation to the following:

of keys and their applications In addition, this lesson explains specialization and

generalization of entities

Logical Database Design Lesson 2A / Slide 2 of 15

Logical Database Design Lesson 2A / Slide 3 of 15

©NIIT

Logical Database Design

Pre-assessment Questions (Contd )

4 A(n) is a pool of values from which one or more attributes draw their

5 Which of the following features is essential for two tables to be union compatible?

a Attributes with same data types

b Attributes with same data

c Attributes with unique data

d Attributes with different data types

Logical Database Design Lesson 2A / Slide 4 of 15

©NIIT

Logical Database Design

Solutions

Ans1 Box

Ans2 Relationship type

Ans3 Hierarchical model

Ans4 Domain

Ans5 Attributes with same data types

• The conceptual model reflects entities and their relationships based

on the data-processing needs of an organization.

• The conceptual model can be mapped to a relational, hierarchical,

or a network model.

• The conceptual model is independent of individual applications, database management systems, hardware, and physical storage of data.

• Data analysis is the first step in designing a conceptual model and begins with collecting data.

• Data analysis involves identifying entities, their attributes, and the relationships between entities based on the data collected.

• The next step is to check all the operational and data processing uses of the organization’s data, and to eliminate any unnecessary

or repeating data

• After completing data analysis, you draw the entity-relationship diagram This diagram gives an intuitive overview of the design and is particularly good for communicating ideas to users

The conceptual model reflects entities and their relationships based on the

data-processing needs of an organization To develop a database that satisfies the

information needs of the present as well as the future, you must design a conceptual model of the database first

The conceptual model design is not concerned with the implementation and operation phases of the database The conceptual model can be mapped to a relational,

hierarchical, or a network model It is independent of individual applications, database management systems, hardware, and physical storage of data

Data analysis is the first step in designing a conceptual model, and begins with

collecting information about data This usually involves using a questionnaire or any similar method to obtain a list of data that an organization needs Existing forms, bills,

and reports are the starting points for data collection The next step is to check all the operational and data processing uses of the organization’s data, and to eliminate any unnecessary or repeating data

Data analysis involves identifying entities, their attributes, and the relationships between entities based on the data collected

After you complete data analysis, you draw the entity-relationship diagram This diagram gives an intuitive overview of the design, and is particularly good for

communicating ideas to users The mapping of real objects to the symbols of the entity-relationship is subjective Often, something that was originally defined as an attribute may later, after design review iterations, become an entity There are no stated rules to identify an object as an entity or attribute or relationship

Mapping Entity-Relationship Diagrams to Tables

Logical Database Design Lesson 2A / Slide 6 of 15

©NIIT

Logical Database Design

Mapping Entity- Relationship

Diagrams to Tables

• A database that conforms to an E/R diagram can be represented by

a collection of tables in the relational system

• E/R diagrams can be mapped to tables in relation to the following:

• Regular entities

• Attributes

• Relationships

• Weak entities

• Subtypes and supertypes

A database that conforms to an E/R diagram can be represented by a collection of tables in the relational system Let’s discuss the mapping of E/R diagrams to tables in relation to the following:

„Regular entities

• Regular entities are independent entities.

• They are the “building blocks” of the database and can exist in isolation, independent of any other entity.

• Each regular entity maps to a table.

You will recall that regular entities are not dependent They can exist in isolation,

independent of any other entity They are the “building blocks” of the database Each regular entity maps to a table For example, consider the following E/R diagram:

Regular Entities

The regular entities STUDENT and BOOKS map to two separate tables

• Attributes are properties of entities.

• Each attribute in an E/R diagram maps to an attribute in the appropriate table.

Each property or attribute shown in the E/R diagram maps to an attribute in the

appropriate table (refer to the figure below) Properties or attributes of STUDENT and

BOOKS map to attributes in the relevant tables

Attributes

The primary key in the table is identified as the key in the E/R diagram, that is,

ROLL_NO and CODE Remember that the primary key must be able to uniquely

identify each tuple in the table

• The mapping of relationships depends on the type of relationship.

• Each type of relationship maps to tables in a different manner in the relational database management system.

• There should be a minimum number of tables with a minimum number of attributes.

• A join operation retrieves all information by combining two or more tables

BOOKS

The mapping of relationships depends on the type of relationship, which we discussed

in the previous session Each type of relationship maps to tables in a different manner

in the relational database management system

The most important principle is to create tables where information from the real world

is stored and retrieved in an optimal way; that is, a minimum number of tables with a minimum number of attributes In a relational system, a join operation retrieves all information by combining two or more tables

One-to-One Relationship

In one-to-one relationships, one instance of an entity can relate to only one instance

of the related entity

For example, assume that a student can do only one project and no other student can

do the same project Then, there is a one-to-one relation between the student and the project

You represent a relationship between the two entities Student and Project in the

form of an E/R diagram as follows:

One-to-One Relationship

This type of relationship can be handled in several ways One way to handle it is in the same manner as a one-to-many relationship by storing a foreign key in either table Another way is to merge the two tables into one for faster access For example, if

frequent queries required data from the two tables Student and Project, then it may

be better to merge the two tables to improve query performance

You represent the relationship between an employee and a department in the form of

an E/R diagram as follows:

Mapping One-to-Many Relationship

The Dept_ID of an employee can be stored in the Employee table as shown

Therefore, Dept_ID in the Employee table is foreign key in the Employee table

Many-to-Many Relationship

Consider the following diagram:

Many-to-Many Relationship

One student can issue many books and one book can be issued to many students The

relationship ISSUES associates students to books ISSUES may have some attributes

D E002 Polly W CA D001

E003 David J CA D002 E004 Nelson G NY D002

that are unique to it, for example, the date on which the book was issued and the date

on which the book has to be returned Therefore, you must understand that attributes

do not belong only to entities They can also belong to relationships The relationship ISSUES is a many-to-many relationship Such a relationship maps to a table

The new table ISSUE must include the primary keys of both the tables, STUDENT

and BOOKS (ROLL_NO and CODE) These are foreign keys in the ISSUE table that help join the two tables, STUDENT and BOOKS.

ROLL_NO CODE ISSUE_DATE RETURN_DATE

Mapping Relationships

Recall the join operation discussed in relational algebra Assume that a user wants to know which book was issued to a particular student, and on which date You can use the foreign keys in the ISSUE table to make a join involving all three tables This gives

a complete description of the issued transaction, as shown below

ROLL_NO NAME ADDRESS CODE DESC ISSUE

_DATE RETURN _DATE

Joining Tables

What is the primary key of the ISSUE table? There are two possibilities One

possibility is to take a combination of the two foreign keys (ROLL_NO and CODE) if

the combination uniquely identifies every row in the table The resulting key is known

as a composite key, that is, a key made up of more than one attribute Another

possibility is to create a new attribute for the primary key, for example ISSUENUM.

ROLL_NO CODE ISSUE_DATE RETURN_DATE

ISSUENUM ROLL_NO CODE ISSUE_DATE RETURN_DATE

You represent the type of relationship between two entities in an entity-relationship diagram by certain symbols An entity may be associated with one, none, or many occurrences of another entity

A weak entity is an entity whose existence depends on some other entity For

example, the dependents of an employee

Weak Entity

In the above example, we have a weak entity called DEPENDENT that depends on the entity EMPLOYEE The DEPENDENT entity can be mapped to a separate table as

follows:

Weak Entity Mapping to a Table

Subtypes and Supertypes

Logical Database Design Lesson 2A / Slide 11 of 15

©NIIT

Logical Database Design

Subtypes and Supertypes

• A subtype is a subset of another entity.

• A subtype is always dependent on the supertype for its existence.

• Each entity type (subtype or supertype) maps to a separate table.

• The primary key of the supertype is the foreign key of the subtype

It creates a link between the two.

• The foreign key of the subtype is also its primary key.

A subtype is a subset of another entity A subtype is always dependent on supertype for its existence

Subtypes and Supertypes

Each entity type (subtype or supertype) maps to a separate table (see the example

below)

EMPLOYEE

HOURLY EMPLOYEE SALARIED EMPLOYEE

ALLOW

Mapping Subtypes and Supertypes

The primary key of the supertype is the foreign key of the subtype It creates a link

between the two The foreign key of the subtype is also its primary key A coded

attribute may be included in the EMPLOYEE table to indicate the subtype, for example,

“S” for salaried employees, and “H” for hourly employees

HOURLY EMPLOYEE SALARIED EMPLOYEE

Foreign Key

EMPNO WAGES OVERTIME EMPNO SALARY BONUS CONV_

ALLOW

Table Structure with the Coded Attribute

Tips on Logical Database Design

Logical Database Design Lesson 2A / Slide 12 of 15

©NIIT

Logical Database Design

Tips on Logical Database Design

• Do not introduce any unnecessary attributes.

• Relational systems require keys that can uniquely identify the rows

Logical Database Design Lesson 2A / Slide 13 of 15

©NIIT

Logical Database Design

Tips on Logical Database Design

• Generalization simplifies multiple references.

• In generalization, every higher-level entity must also be a level entity However, specialization does not have this constraint.

lower-Here are some tips on database design Remember that these are only guidelines

Attributes

Do not introduce any unnecessary attributes An attribute serves three purposes:

„To identify its owner entity

„To refer to another entity

„To simplify the description of an entity

SALES

Attributes of a Table

Foreign Key Primary

Key

If there are any entities with common attributes, merge the entities Remember that the main objective is to come up with a database that has the minimum number of tables with minimum number of attributes

Merging Entities with Common Attributes

Keys

An RDBMS uses associative addressing; that is, it identifies and locates rows by value The physical address is transparent to the user Therefore, relational systems require keys that can uniquely identify the rows of a table

There are various types of keys, some of which you are already familiar with These keys are:

Any attribute (or set of attributes) that uniquely identifies a row in a table is a

candidate for the primary key Such an attribute is called a candidate key One of the

candidate keys is chosen to be the primary key, based on familiarity, greater usage, and so on Any attribute that is a candidate for the primary key but is not the primary

key is called the alternate key When the key that uniquely identifies the rows of the table is made up of more than one attribute, it is called a Composite key Foreign keys

always represent relationships

It is important to understand that the primary key is the only guaranteed way to

identify rows of a table Therefore, NULL values are not permitted as primary keys If

a primary key is allowed NULL values, it becomes difficult to identify the rows

uniquely

Consider the following VEHICLE table:

Candidate, Primary, and Alternate Keys

In the above table, ENGINE# and REGN# are both individually unique in every tuple Therefore, they are both candidate keys If ENGINE# is chosen as the primary key, then REGN# is the alternate key

Keys can be simple or composite A simple key is composed of a single attribute A

composite key, on the other hand, comprises two or more attributes

Consider the following Accounts table:

Account

A001 01/02/2001 12:30 P.M 1000.00 Deposit A002 01/02/2001 12:30 P.M 2000.00 Deposit A001 02/02/2001 10:30 A.M 3000.00 Deposit

In the above example, assume that only one transaction can take place for a given

account number at a time We can select AccountNumber, TransactionDate and

TransactionTime as composite key

833647 7389 Mercedes

347889 9077 Rolls Royce

Entities

Some attributes may acquire further attributes to qualify themselves during database design and become entities You can create a new entity to represent important recurring groups of attributes For example, the attribute “address” may acquire further attributes like “block”, “street”, “city”, “state”, and “pin” In this case, the attribute “address” becomes an entity as shown in the following example

Attributes may Become Entities

Subentities

Consider the following example The entity PLANT has the attributes shown in the following diagram However, some of the attributes do not apply to all plants For instance, the attribute “pressure” applies only to steam plants In this case, all non-steam plants have the value NULL stored in the “pressure” column A good practice is

to replace optional attributes with subentities This is also called specialization.

Specialization is the result of taking a subset of a higher-level entity set to form a lower-level entity set In this example, PLANT is the higher-level entity set, while