Introduction to Database

Administration
By
Dr. Mariam Rehman
Course Overview:

This course contain the following topics:

 Roles and responsibilities of a DBA
 Types of DBA
 Installation and configuration of DBMS
 Database Design ,Schemas, tables
 indexes and views management
 Database Security management
 Database Access over network
 Database Backup and recovery
Continued..

 Database Import/Export
 Data Availability
 Database Performance
 Data warehousing Administration
 DBA Tools
Database administration
 Data is the center (core) for every application.
 Organization can not operate without Data.

 Without Data, Businesses (Organization) would not be able

to manage finance
conduct transactions
contact customer
Continued..

Database is the repository of information for an organization.

Database Administrator (DBA) is a person or group of persons
responsible for the health of database.
Depending on the size of database, there may be single DBA or
a group.
Database Administrator(DBA) Skills
 Data modeling and Database design
 Management of metadata
 Schema creation and management
 Database backup and recovery
 Integrity of Data
 Database Tuning and Performance
 Data Security
Questions/Answers

For any question send an email to

[email protected]
 Database , Data and
System Administration
Database Administration
Database Administration: The list of
activities(e.g Designing, backup & recovery,
security, availability etc)) perform by the
database administrator (s) to keep the
database in well operational state.
The entire course is about the database
administration.
Data Administration
Data Administration is concern with the business
aspects of data resource management
 Most organizations treat data as a corporate

asset.
 it is more closely associated with the actual

business users of data

 The data administrator (DA) is responsible for

understanding the business lexicon (Different

terms used in business/problem area) e.g in
Accounts Credit, Debit terms.
Continued..
Transform business term into logical data
model.
DA mostly involve in requirements gathering,

analysis and conceptual design phase.

 Creating an enterprise data model that

incorporates all of the data used by all

organization's business processes
 Setting data policies for the organization
 Identifying data owners and custodian
 Setting standards for control and usage of data
Continued..
 DA deals with metadata, as opposed to the
DBA, who deals with data
Metadata is often described as data about

data, or metadata is the description of the data

e.g metadata may include,
the definition of a data element
business names for a data element
any abbreviations used for that element
data type and length of the element
System Administration
 Usually large organizations have System
administrator (SA) as well.
 The SA ensure that the IT infrastructure of the

organization is operational for database

environment.
 SA responsible for the maintenance of IT

equipments.
 The responsibilities of DA, DBA and SA are

depicted in the following figure.

DA, DBA and SA responsibilities
 Questions/Answers

For any question send an email to

[email protected]
Roles and responsibilities of DBA
By
Dr. Mariam Rehman
Roles and responsibilities

The tasks performed by the database administrator (DBA) are

known as responsibilities of DBA.

Following are some responsibilities performed by the DBA

 Database Software Installation: Being the DBA, you need

to install, that will access database. In distributed

environment, Database Server (Oracle or SQL Server), Front
end toll and database applications also need to install database
tools that connect remote computers to database server.
Continued..

 Planning the Database: DBA need to plan the logical storage

structure of the database (e.g creating table space, how many
data files in table space, which information will be store in
tablespace, on which drive data files will be stored etc),
overall database design (relational design of the database
objects, their storage characteristic for these objects, planning
relationship between objects and physical storage before
creation), Backup strategy (plan for the database backup).
Continued..

 Create and open Database: Once the database design

complete, you may create the database and open it for normal
use. The database may be created through wizard as well as
through command depending on the tool (Oracle, SQL server
etc)
 Backup the database: another task of the DBA is to take the
regular backup of the database. Backup is the copy of the
database data, while backup may be full database backup or
differential database backup (Backup which capture only
those changes in the data since recent full backup).
Continued..

 Enroll (Create) database user: One task is to create users of

the database, assigning privileges and roles to users.(privileges
may be system privilege or object privilege) system privilege
allow user to access/perform database operations, object
privilege control access to specific object (table, view etc).
Role is the collection of privileges and other roles.
Continued..

 Tuning the Database: optimizing the performance of the

database is also the responsibility of the DB. Mostly database
tool (Oracle, SQL server) provide a tool which help to control
allocation of resources among different user groups. E.g,
oracle resource manager.
 Data Base recovery: DBA also recover the database in case
of any human or system failure.
 Download and install Patches: DBA also responsible for
downloading and installing new patches in database software.
Continued..

Data Integrity: To store correct data in the database in correct

way
For this DBA uses some constraints,
Physical constraint choose appropriate data type for each
column of the table
Referential constraint Data in one column or group of columns
is valid with respect to data in other column of same or
different table
Unique Constraint value of a column occur only once in the
table
Questions/Answers

For any question send an email to

[email protected]
Types of DBAs
Types of DBAs.
There are a number of DBAs types depending
upon the organization and database size,
some of them are as follows,
 System DBA
 Database Architect

 Data Modeler

 Application DBA

 Data warehouse Administrator

Continued..
System DBA: System DBA primarily focus on the
technical issues rather than Database issues.

The typical tasks would be physical installation and

performance of the DBMS while may further include the
following.
 Installation of new versions of DBMS.

 Tuning the operating system.

 Ensuring appropriate storage for the DBMS

 Interfacing with any other technologies required by

database applications(e.g Crystal Report tool with SQL

Server).
Continued..
Database Architect: Database architect task is
to design and implement the databases for
the organization.
Typical tasks performed by the database
architect may include the following.

 Creating a logical data model

 Transforming logical data models into

physical database design.

Continued..
 Analyzing data access and modification
requirements to ensure efficient SQL and
optimal database design
 Creating backup and recovery strategies for

new databases
Continued..
Data Modeler: Data Modeler is responsible for
Data modeling tasks which may include the
following.
 Collecting data requirements for

development projects
 Analyzing the data requirements
 Designing conceptual and logical data

models (ERD, Tables etc).

Continued..
 Updating Data models where needed.
 Ensuring that the Database Architect has a

sound understanding of the data models.

Continued..
Application DBA: The Application DBA may
have the following responsibilities.
 Creating Database object like Tables,

indexes etc.
 Write Database procedures, functions,

triggers etc.
 Tune Database Queries.
 Assists Developers.
Continued..
Data warehouse Administrator: This DBA may
be responsible for designing warehouse and
merging data from multiple sources into the
data warehouse.
Data warehouse administrator will require in
those organization who implement data
warehouse for detail analysis of the data
and business intelligence.
 Chapter 5:
Logical Database Design and the Relational Model

Modern Database Management

8th Edition
Jeffrey A. Hoffer, Mary B. Prescott,
Fred R. McFadden

© 2007 by Prentice Hall 33

Objectives
 Definition of terms
 List five properties of relations
 State two properties of candidate keys
 Define first, second, and third normal form
 Describe problems from merging relations
 Transform E-R and EER diagrams to
relations
 Create tables with entity and relational
integrity constraints
 Use normalization to convert anomalous
tables to well-structured relations

34
 Relation
 Definition: A relation is a named, two-dimensional table
of data
 Table consists of rows (records) and columns (attribute or
field)
 Requirements for a table to qualify as a relation:
◦ It must have a unique name
◦ Every attribute value must be atomic (not multivalued, not
composite)
◦ Every row must be unique (can’t have two rows with exactly the
same values for all their fields)
◦ Attributes (columns) in tables must have unique names
◦ The order of the columns must be irrelevant
◦ The order of the rows must be irrelevant

NOTE: all relations are in 1st Normal form

35
Correspondence with E-R Model

 Relations (tables) correspond with entity types

and with many-to-many relationship types
 Rows correspond with entity instances and
with many-to-many relationship instances
 Columns correspond with attributes

 NOTE: The word relation (in relational

database) is NOT the same as the word
relationship (in E-R model)

36
Key Fields

 Keys are special fields that serve two main purposes:

◦ Primary keys are unique identifiers of the relation in
question. Examples include employee numbers, social
security numbers, etc. This is how we can guarantee that all
rows are unique
◦ Foreign keys are identifiers that enable a dependent relation
(on the many side of a relationship) to refer to its parent
relation (on the one side of the relationship)
 Keys can be simple (a single field) or composite
(more than one field)
 Keys usually are used as indexes to speed up the
response to user queries (More on this in Ch. 6)

37
Figure 5-3 Schema for four relations (Pine Valley Furniture Company)

Primary Key
Foreign Key
(implements 1:N relationship
between customer and order)

Combined, these are a composite

primary key (uniquely identifies the
order line)…individually they are
foreign keys (implement M:N
relationship between order and product)

38
Integrity Constraints

 Domain Constraints
◦ Allowable values for an attribute. See Table 5-1
 Entity Integrity
◦ No primary key attribute may be null. All primary
key fields MUST have data
 Action Assertions
◦ Business rules. Recall from Ch. 4

39
Domain definitions enforce domain integrity constraints

40
 Integrity Constraints

 Referential Integrity–rule states that any foreign key value

(on the relation of the many side) MUST match a primary
key value in the relation of the one side. (Or the foreign
key can be null)
◦ For example: Delete Rules
 Restrict–don’t allow delete of “parent” side if related rows exist
in “dependent” side
 Cascade–automatically delete “dependent” side rows that
correspond with the “parent” side row to be deleted
 Set-to-Null–set the foreign key in the dependent side to null if
deleting from the parent side  not allowed for weak entities

41
Figure 5-5
Referential integrity constraints (Pine Valley Furniture)

Referential
integrity
constraints are
drawn via arrows
from dependent to
parent table

42
Figure 5-6 SQL table definitions

Referential
integrity
constraints are
implemented with
foreign key to
primary key
references

43
Transforming EER Diagrams into
Relations

Mapping Regular Entities to Relations

1. Simple attributes: E-R attributes map directly
onto the relation
2. Composite attributes: Use only their simple,
component attributes
3. Multivalued Attribute–Becomes a separate
relation with a foreign key taken from the
superior entity

44
 Figure 5-8 Mapping a regular entity

(a) CUSTOMER
entity type with
simple
attributes

(b) CUSTOMER relation

45
 Figure 5-9 Mapping a composite attribute

(a) CUSTOMER
entity type with
composite
attribute

(b) CUSTOMER relation with address detail

46
 Figure 5-10 Mapping an entity with a multivalued attribute
(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

One–to–many relationship between original entity and new relation

47
Transforming EER Diagrams into
Relations (cont.)
Mapping Weak Entities
◦ Becomes a separate relation with a
foreign key taken from the superior
entity
◦ Primary key composed of:
 Partial identifier of weak entity
 Primary key of identifying relation
(strong entity)

48
Figure 5-11 Example of mapping a weak entity

a) Weak entity DEPENDENT

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

b) Relations resulting from weak entity

NOTE: the domain

constraint for the foreign key
should NOT allow null value
if DEPENDENT is a weak
entity

Foreign key

Composite primary key

50
Transforming EER Diagrams into
Relations (cont.)
Mapping Binary Relationships
◦ One-to-Many–Primary key on the one side becomes
a foreign key on the many side
◦ Many-to-Many–Create a new relation with the
primary keys of the two entities as its primary key
◦ One-to-One–Primary key on the mandatory side
becomes a foreign key on the optional side

51
Figure 5-12 Example of mapping a 1:M relationship
a) Relationship between customers and orders

Note the mandatory one

b) Mapping the relationship

Again, no null value in the

foreign key…this is because
of the mandatory minimum
cardinality
Foreign key

52
 Figure 5-13 Example of mapping an M:N relationship
a) Completes relationship (M:N)

The Completes relationship will need to become a separate relation

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

Composite primary key

Foreign key New

Foreign key
intersection
relation

54
Figure 5-14 Example of mapping a binary 1:1 relationship
a) In_charge relationship (1:1)

Often in 1:1 relationships, one direction is optional.

55
Figure 5-14 Example of mapping a binary 1:1 relationship (cont.)
b) Resulting relations

Foreign key goes in the relation on the optional side,

Matching the primary key on the mandatory side

56
Transforming EER Diagrams into
Relations (cont.)
Mapping Associative Entities
◦ Identifier Not Assigned
 Default primary key for the association
relation is composed of the primary keys
of the two entities (as in M:N
relationship)
◦ Identifier Assigned
 It is natural and familiar to end-users
 Default identifier may not be unique

57
Figure 5-15 Example of mapping an associative entity
a) An associative entity

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

Composite primary key formed from the two foreign keys

59
Figure 5-16 Example of mapping an associative entity with
an identifier
a) SHIPMENT associative entity

60
Figure 5-16 Example of mapping an associative entity with
an identifier (cont.)
b) Three resulting relations

Primary key differs from foreign keys

61
Transforming EER Diagrams into
Relations (cont.)
Mapping Unary Relationships
◦ One-to-Many–Recursive foreign key in the same
relation
◦ Many-to-Many–Two relations:
 One for the entity type
 One for an associative relation in which
the primary key has two attributes, both
taken from the primary key of the entity

62
 Figure 5-17 Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

unary relationship

(b) EMPLOYEE
relation with
recursive foreign
key

63
Figure 5-18 Mapping a unary M:N relationship

(a) Bill-of-materials
relationships (M:N)

(b) ITEM and

COMPONENT
relations

64
Transforming EER Diagrams into
Relations (cont.)
Mapping Ternary (and n-ary)
Relationships
◦ One relation for each entity and
one for the associative entity
◦ Associative entity has foreign
keys to each entity in the
relationship

65
 Figure 5-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with

associative entity

66
 Figure 5-19 Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT

Remember This is why But this makes a It would be

that the treatment date very better to create a
primary key and time are cumbersome surrogate key
MUST be included in the key… like Treatment#
unique composite
primary key
67
Transforming EER Diagrams into
Relations (cont.)
Mapping Supertype/Subtype Relationships
◦ One relation for supertype and for each subtype
◦ Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
◦ Subtype attributes go into each subtype; primary
key of supertype relation also becomes primary
key of subtype relation
◦ 1:1 relationship established between supertype
and each subtype, with supertype as primary table

68
Figure 5-20 Supertype/subtype relationships

69
Figure 5-21
Mapping Supertype/subtype relationships to relations

These are implemented as one-to-one

relationships

70
Data Normalization
 Primarily a tool to validate and improve a
logical design so that it satisfies certain
avoid unnecessary
constraints that
duplication of data
 The process of decomposing relations with
anomalies to produce smaller, well-
structured relations

71
Well-Structured Relations
 A relation that contains minimal data redundancy
and allows users to insert, delete, and update
rows without causing data inconsistencies
 Goal is to avoid anomalies
◦ Insertion Anomaly–adding new rows forces user to create
duplicate data
◦ Deletion Anomaly–deleting rows may cause a loss of data
that would be needed for other future rows
◦ Modification Anomaly–changing data in a row forces
changes to other rows because of duplication

General rule of thumb: A table should not pertain to

more than one entity type
72
 Example–Figure 5-2b

Question–Is this a relation? Answer–Yes: Unique rows and no

multivalued attributes

Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title

73
 Anomalies in this Table
 Insertion–can’t enter a new employee without
having the employee take a class
 Deletion–if we remove employee 140, we lose

information about the existence of a Tax Acc

class
 Modification–giving a salary increase to employee

100 forces us to update multiple records

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

74
Functional Dependencies and Keys
 Functional Dependency: The value of one
attribute (the determinant) determines the
value of another attribute
 Candidate Key:
◦ A unique identifier. One of the candidate keys
will become the primary key
 E.g. perhaps there is both credit card number and
SS# in a table…in this case both are candidate keys
◦ Each non-key field is functionally dependent on
every candidate key

75
Figure 5.22 Steps in normalization

76
First Normal Form
 No multivalued attributes
 Every attribute value is atomic
 Fig. 5-25 is not in 1st Normal Form
(multivalued attributes)  it is not a
relation
 Fig. 5-26 is in 1st Normal form
 All relations are in 1st Normal Form

77
Table with multivalued attributes, not in 1st normal form

Note: this is NOT a relation

78
Table with no multivalued attributes and unique rows, in 1st
normal form

Note: this is relation, but not a well-structured one

79
 Anomalies in this Table
 Insertion–if new product is ordered for order
1007 of existing customer, customer data must
be re-entered, causing duplication
 Deletion–if we delete the Dining Table from
Order 1006, we lose information concerning
this item's finish and price
 Update–changing the price of product ID 4
requires update in several records

Why do these anomalies exist?

Because there are multiple themes (entity types) in
one relation. This results in duplication and an
unnecessary dependency between the entities
80
Second Normal Form
 1NF PLUS every non-key attribute is
fully functionally dependent on the
ENTIRE primary key
◦ Every non-key attribute must be defined
by the entire key, not by only part of the
key
◦ No partial functional dependencies

81
 Figure 5-27 Functional dependency diagram for INVOICE

Order_ID  Order_Date, Customer_ID, Customer_Name, Customer_Address

Customer_ID  Customer_Name, Customer_Address
Product_ID  Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID  Order_Quantity

Therefore, NOT in 2nd Normal Form

82
Figure 5-28 Removing partial dependencies

Getting it into
Second Normal
Form

Partial dependencies are removed, but there

are still transitive dependencies

83
Third Normal Form
 2NF PLUS no transitive dependencies
(functional dependencies on non-primary-
key attributes)
 Note: This is called transitive, because the
primary key is a determinant for another
attribute, which in turn is a determinant for a
third
 Solution: Non-key determinant with transitive
dependencies go into a new table; non-key
determinant becomes primary key in the new
table and stays as foreign key in the old table

84
Figure 5-28 Removing partial dependencies

Getting it into
Third Normal
Form

Transitive dependencies are removed

85
Merging Relations
 View Integration–Combining entities from
multiple ER models into common relations
 Issues to watch out for when merging entities
from different ER models:
◦ Synonyms–two or more attributes with different names
but same meaning
◦ Homonyms–attributes with same name but different
meanings
◦ Transitive dependencies–even if relations are in 3NF
prior to merging, they may not be after merging
◦ Supertype/subtype relationships–may be hidden prior
to merging

86
Enterprise Keys

 Primary keys that are unique in the whole

database, not just within a single relation
 Corresponds with the concept of an
object ID in object-oriented systems

87
Figure 5-31 Enterprise keys

a) Relations with
enterprise key

b) Sample data with

enterprise key

88