Lecture 3

Databases and Transactions

Second stage

Department of Cyber Security Engineering

Alshaab University

Assist.Lect. Zainab Haider& Zainab

Mohammed
Database Design

When designing a database, you are modeling a real business system that

contains a set of entities and their characteristics, or attributes, and the rules or

relationships between those entities.

Overview of Database design

The database design process can be divided into five steps:

1. Requirements Analysis: The very first step in designing a database application

is to understand what data is to be stored in the database, we must find out what

the users want from the database. Several methodologies have been proposed for

organizing and presenting the information gathered in this step, and some

automated tools have been developed to support this process.

2. Conceptual Database Design: This step is often carried out using the ER

model The information gathered in the requirements analysis step is used to

develop a high-level description of the data to be stored in the database.

3. Logical Database Design: The task in the logical design step is to convert an

ER schema into a relational database schema. We must choose a DBMS to

implement our database design.

4. Schema Refinement: The fourth step in database design is to analyze the

collection of relations in our relational database schema to identify potential

problems, and to refine it.We discuss the theory of normalizing relations to

ensure some desirable properties later.

5. Physical Database Design (Implementation): In this step we must consider

typical expected workloads that our database must support and further refine

the database design to ensure that it meets desired performance criteria.

The ER diagram is used to represent database schema. The elements in ER

diagram are Entity, Attribute, and Relationship. See Figure 1.1 below

Fig. 1.1 ER diagram Symbols

An E-R diagram consists of the following major components:

Rectangles divided into two parts represent entity sets. The first part, which in

this text book is shaded blue,contains the name of the entity set.The second part

contains the names of all the attributes of the entity set.

• Diamonds represent relation ship sets.

• Undivided rectangles represent the attributes of a relationship set.Attributes

that are part of the primary key are underlined.

• Lines link entity sets to relationship sets.

• Dashed lines link attributes of a relationship set to the relationship set.

• Double lines indicate total participation of an entity in a relationship set.

• Double diamonds represent identifying relationship sets linked to weak entity

sets.
Data Modeling Using the Entity-Relationship Model

Conceptual modeling is an important phase in designing a successful database

application. The entity-relationship (ER) data model allows us to describe the

data involved in a real-world enterprise in terms of objects and their

relationships and is widely used to develop an initial database design. The ER

model is used in a phase called conceptual database design. The main motivation

for defining the ER model is to provide a high level model for conceptual

database design. The ER model achieves a high degree of data independence

which means that the database designer do not have to worry about the physical

structure of the database.

The Building Blocks of an Entity–Relationship Diagram

The ER modeling can be carried out with the help of pictorial representation of

entities, attributes, and relationships. To recall the definitions from previous

lectures:

a- Entity: any distinguishable )object that is to be represented in the DB.It may

be tangible object (e.g., person, place) or non tangible (e.g., event, customer

account).

b- Relationship: linker to the basic entities. Usually it is bi-directional.The set of

entities may be linked with any number of relationships.

c- Attributes: Attribute is used to describe the properties of the entity. This

attribute can be broadly classified based on value and structure.Usually

converted to columns in the relational database model.

Attribute Classification

Single value attribute Single value attribute means, there is only one value

associated with that attribute. One example of single value attribute is age of a

person.

Multi value attribute In the case of Multi value attribute; more than one value

will be associated with that attribute. Consider an entity EMPLOYEE. An

Employee can have many skills;hence skills associated to an employee are a

multi value attribute.

values of other related attributes or entities. Example: Age of a person can be

derived from the date of birth of the person. In this example, age is the derived

attribute.

Null Value Attribute In some cases, a particular entity may not have any

applicable value for an attribute. For such situation, a special value called null

value is created.Example In application forms, there is one column called phone

no. if a person do not have phone then a null value is entered in that column.

Composite Attribute Composite attribute is one which can be further

subdivided into simple attributes. Example: Consider the attribute “address”

which can be further subdivided into Street name, City, and State.
Entity Types and Entity Sets:

A database usually contains groups of entities that are similar. For example, a

company employing hundreds of employees may want to store similar

information concerning each of the employees. These employee entities share the

same attributes, but each entity has its own value(s) for each attribute. An entity

type defines a collection (or set) of entities that have the same attributes. Each

entity type in the database is described by its name and attributes. Figure 1.2

shows two entity types: EMPLOYEE and COMPANY, and a list of some of the

attributes for each. A few individual entities of each type are also illustrated,

along with the values of their attributes. The collection of all entities of a

particular entity type in the database at any point in time is called an entity set;

the entity set is usually referred to using the same name as the entity type. For

example, EMPLOYEE refers to both a type of entity as well as the current set of

all employee entities in the database.

Constraint

E-R enterprise schema may define certain constraints to which the contents of a

database must conform. In this section, we examine mapping cardinalities and

participation constraints.

 Mapping Cardinalities

Mapping or cardinality ratios, express the number of entities to which another

entity can be associated via a relationship set. Mapping cardinalities are most

useful in describing binary relationship sets, although they can contribute to the

description of relationship sets that involve more than two entity sets. In this

section, we shall concentrate on only binary relationship sets. For a binary

one of the following:

• One-to-one:An entity in A is associated with at most one entity in B,and an

entity in B is associated with at most one entity in A.

• One-to-many:An entity in A is associated with any number (zero or more) of

entities in B.An entity in B.however, can be associated with at most one entity in

A.

1.3 Mapping cardinalities (a) One-to-one. (b) One-to-many

• Many-to-one:An entity in A is associated with at most one entity in B.An entity

in B, however, can be associated with any number (zero or more) of entities in A.

• Many-to-many:An entity in A is associated with any number (zero or more) of

entities in B, and an entity in B is associated with any number (zero or more) of

entities in A.

1.4 Mapping cardinalities. (a) Many-to-one. (b) Many-to-many

The participation of an entity set E in a relationship set R is said to be total if

every entity in E participates in at least one relationship in R. If only some

entities in E participate in relationships in R, the participation of entity set E in

relationship R is said to be partial.In Figure1.3 , the participation of B in the

relationship set is total while the participation of A in the relationship set is

partial. In Figure1.4, the participation of both A and B in the relationship set are

total. For example, we expect every student entity to be related to at least one

instructor through the a dvisor relationship. Therefore the participation of

student in the relationship set a dvisor is total. In contrast, an instructor need not

advise any students. Hence, it is possible that only some of the instructor entities

are related to the student entity set through the a dvisor relationship, and the

participation of instructor in the a dvisor relationship set is therefore partial

 Keys

We must have a way to specify how entities within a given entity set are

distinguished. Conceptually, individual entities are distinct; from a database

perspective, however, the differences among them must be expressed in terms of

their attributes. Therefore, the values of the attribute values of an entity must be

such that they can uniquely identify the entity. In other words, no two entities in

an entity set are allowed to have exactly the same value for all attributes. The

notion of a key for a relation schema.applies directly to entity sets. That is, a key

for an entity is a set of attributes that suffice to distinguish entities from each

other.The concepts of super key, candidate key, and primary key are applicable

to entity sets just as they are applicable to relation schemas.

entities of the set. We need a similar mechanism to distinguish among the various

relationships of a relationship set.

The characteristic of primary :

 It is a unique key.

 It can identify only one tuple (a record) at a time.

 It has no duplicate values, it has unique values.

 It cannot be NULL.

 Primary keys are not necessarily to be a single column; more than one

column can also be a primary key for a table.

Super Key

The set of attributes that can uniquely identify a tuple is known as Super Key.A

super key is a group of single or multiple keys that identifies rows in a table. It

supports NULL values.

 Adding zero or more attributes to the candidate key generates the super key.

 A candidate key is a super key but vice versa is not true.

 Super Key values may also be NULL.

Candidate Key

The minimal set of attributes that can uniquely identify a tuple is known as a

candidate key.

 It is a minimal super key.

 It is a super key with no repeated data is called a candidate key.

 The minimal set of attributes that can uniquely identify a record.

 It must contain unique values.

 It can contain NULL values.

 A table can have multiple candidate keys but only one primary key.

Classification of Entity Sets:

 Strong entity: is one whose existence does not depend on other entity.

Example: Consider the example, student takes course. Here student is a

strong entity. In this example, course is considered as weak entity because, if

there are no students to take a particular course, then that course cannot be

offered. The COURSE entity depends on the STUDENT entity.

 Weak Entity: Weak entity is one whose existence depends on other entity. In

many cases, weak entity does not have primary key. Example: Consider the

example, customer borrows loan. Here loan is a weak entity. For every loan,

there should be at least one customer. Here the entity loan depends on the

entity customer hence loan is a weak entity.