0% found this document useful (0 votes)
35 views34 pages

DBMS Module 1

The document provides an overview of Database Management Systems (DBMS), covering key concepts such as data types, database users, data models, and entity-relationship (ER) models. It explains various relationship types, cardinality, structural constraints, and the distinction between strong and weak entity types, along with examples and ER diagram construction. Additionally, it discusses different DBMS interfaces and classifications, including centralized and client-server architectures.

Uploaded by

A K2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
35 views34 pages

DBMS Module 1

The document provides an overview of Database Management Systems (DBMS), covering key concepts such as data types, database users, data models, and entity-relationship (ER) models. It explains various relationship types, cardinality, structural constraints, and the distinction between strong and weak entity types, along with examples and ER diagram construction. Additionally, it discusses different DBMS interfaces and classifications, including centralized and client-server architectures.

Uploaded by

A K2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 34

Module 1

 Concept & Overview of Database Management Systems (DBMS)


 Structured, semi-structured and unstructured data
 Characteristics of Database system
 Database Users
 Data Models and Schema
 Three Schema architecture
 Database Languages
 Database architectures and classification
 ER model
 Basic concepts - entity set & attributes - notations,

 Relationships and constraints

 Cardinality - participation - weak entities - relationships of

degree 3.
Relationship Types, Relationship Sets

 A relationship type R among n entity types E1, E2, •••• , En


defines a set of associations or a relationship set among entities
from these entity types.

 A relationship type and its corresponding relationship set are


customarily referred to by the same name, R.

 Eg: consider a relationship type WORKS_FOR between the two


entity types EMPLOYEE and DEPARTMENT  which associates each
employee with the department for which the employee works.

 Each relationship instance in the relationship set WORKSFOR


associates one employee entity and one department entity.
 Eg: Each relationship instance Ti is shown connected to the
employee and department entities that participate in ri.
 In the mini-world represented by Figure employees e1 e3 and e6
work for department dl ; e2 and e4 work for d2; and es and e7
work for d3·

 In ER diagrams, relationship types are displayed as diamond-


shaped boxes, which are connected by straight lines to the
rectangular boxes representing the participating entity types.
 The relationship name is displayed in the diamond-shaped box
Degree of a relationship
 Degree defines the number of entity types involved.

Relationships of higher degree(Greater than 2) :


 Relationships of degree greater than 2 are called higher degree
relationship.

 The relationship due to its degree are as follows:


1. Unary relationship
2. Binary Relationships
3. Ternary Relationships
4. Quarternary relationships
Unary relationship:
 If a relationship type is between entities in a single entity type
then it is called a unary relationship type.
 Eg: Employee manages Employee

Binary Relationships:
 Exists when two entities are associated in a relationship.
 Eg:
Ternary Relationships:
 A ternary relationship implies an association among three
different entities.
 Eg:

Quarternary relationships:
 Exists when there are four entities associated.
 Eg: A relationship studies where four entities are involved-
student, Teacher, Subject and course material.
Cardinality
 Cardinality of relationship tells how many instances of an entity
type is related to one instance of other entity.
 Relationship can have different connectivity / Types of
relationships.
1-1 (one-to-one) :
 For a given occurrence of an entity, there is exactly one
occurrence of another entity.
 Eg: Employee head-of department

1-N (one-to-many) :
 For a given occurrence of an entity, there can be one or more
occurrences of another entity.
 Eg: Lecturer teaches course assuming that one course is

handled by only one lecturer


M-1(Many-to-one) : Many students belong to same college
M-N(Many-to-Many) : Can be one or more values on both sides of
Structural constraints
 Structural constraints are information about how two (or more)
entities are related to one another.

 Structural constraints are of two types

1. Mapping Constraints
2. Participation Constraints
1. Total Participation Constraints:

2. Partial Participation Constraints:


Mapping Constraints / Cardinality Ratios

 The cardinality ratio for a binary relationship specifies the maximum


number of relationship instances that an entity can participate in.
 Mapping cardinalities are most useful in describing binary relationship sets.

 Eg: In the WORKS_FOR binary relationship type, DEPARTMENT: EMPLOYEE is


of cardinality ratio l:N,
 Meaning that each department can be related to any number of ernployees but an
employee can be related to (work for) only One department.
 The possible cardinality ratios for binary relationship types are 1:1, l:N, N:l,
and M:N.

 An example of a 1:1 binary relationship is MANAGES which relates a


department entity to the employee who manages that department.

 This represents the mini-world constraints that at any point in time-an


employee can manage only one department and a department has only
one manager.
Participation Constraints
 This constraint specifies the minimum number of relationship
instances that each entity can participate in, and is sometimes
called the minimum cardinality constraint.

 There are two types of participation constraints- Total and


Partial.

Partial Participation Constraints:

 If only a part of the set of entities participate in a relationship,


then it is called partial participation.

 We do not expect every employee to manage a department, so


the participation of EMPLOYEE in the MANAGES relationship type
is partial,
Total Participation Constraints:
 An entity can exist, only if it participates in at least one
relationship instance, then that is called total participation.

 If a company policy states that every employee must work for a


department, then an employee entity can exist only if it
participates in at least one WORKS_ FOR relationship instance

 Thus, the participation of EMPLOYEE in WORKS_FOR is called total


participation, meaning that every entity in "the total set" of
employee entities must be related to a department entity via
WORKS_FOR.

 Total participation is also called existence dependency.


Strong And Weak Entity Types
 Entity types do not have key attribute of their own are called weak entity
types

 Regular entity types that do have key attribute are called strong entity
types.

 The identifying relationship is the one which relates the weak entity
(dependant) with the strong entity (Employee) on which it depends.

 Id is underlined with a dotted line because it is used to form composite key of


dependent entity along with E#.

 Entities belonging to a weak entity type are identified by being related to


specific entities from another entity type in combination with one of their
 Other entity type  identifying or Owner entity type,

 Relationship type that relates a weak entity type to its owner 


Identifying relationship of the weak entity type.

 A weak entity type always has a total participation constraint


(existence dependency) with respect to its identifying
relationship, because a weak entity cannot be identified without
an owner entity.

 In ER diagrams,  Surrounding their boxes and diamonds with


double lines.
 Consider the entity type DEPENDENT, related to EMPLOYEE, which
is used to keep track of the dependents of each employee via a
l:N relationship

 A weak entity type normally has a partial key, which is the set of
attributes that can uniquely identify weak entities that are related
to the same owner entity.

 If we assume that no two dependents of the same employee ever


have the same first name, the attribute Name of DEPENDENT is
the partial key.

 In ER diagrams,  Partial key attribute is underlined with a


dashed or dotted line.
ER Diagram
 Entity Relationship diagram (ERD) is another means of capturing
the data and their organisation.

 ERD captures the entities, their attributes and the relationship


between the entities.

 Role Names: Signifies the role that a participating entity from


the entity type plays in each relationship instance, and helps to
explain what the relationship means.

 Notations for ER diagram is shown below:


Example 1
Construct an E-R diagram for a car-insurance company whose
customers own one or more cars each. Each car has associated
with it zero to any number of recorded accidents
Example 2
A university registrar’s office maintains data about the following
entities:
1) Courses, including number, title, credits, syllabus, and
prerequisites;
2) Course offerings, including course number, year, semester,
section number, instructors, timings, and classroom;
3) Students, including student- id, name, and program:
4) Instructors, including identification number, name, department
and title.
Further, the enrolment of students in courses and grades awarded to
students in each course they are enrolled for must be
appropriately modelled.

Construct an ER Diagram of the registrar’s office.


Document all assumptions that one makes the mapping constraints.
Answer
 ER Diagram for registrar’s office is figure 1.19. In the answer
given here, main entity sets are student, course, course offerings,
and instructor.
 The entity set course offering is a weak entity set dependant on
course.
DBMS Interfaces
 User-friendly interfaces provided by a DBMS may include the
following

1. Menu-Based Interfaces for Web Clients or Browsing


2. Forms-Based Interfaces
3. Graphical User Interfaces
4. Natural Language Interfaces
5. Interfaces for Parametric Users
6. Interfaces for the DBA
Menu-Based Interfaces for Web Clients or Browsing.
 These interfaces present the user with lists of options, called
menus, that lead the user through the formulation of a request.

 Menus do away with the need to memorize the specific


commands and syntax of a query language; rather, the query is
composed step by step by picking options from a menu that is
displayed by the system.

 Pull-down menus are a very popular technique in Web-based user


interfaces.

 They are also often used in browsing interfaces, which allow a


user to look through the contents of a database in an exploratory
and unstructured manner.
Forms-Based Interfaces.
 A forms-based interface displays a form to each user.
 Users can fill out all of the form entries to insert new data, or they
fill out only certain entries, in which case the DBMS will retrieve
matching data for the remaining entries.
 Forms are usually designed and programmed for naive users as
interfaces to canned transactions.

Graphical User Interfaces.


 A graphical interface (GUI) typically displays a schema to the user
in diagrammatic form.
 The user can then specify a query by manipulating the diagram.
 In many cases, CUIs utilize both menus and forms.
 Most CUIs use a pointing device, such as a mouse, to pick certain
parts of the displayed schema diagram.
Natural Language Interfaces.
 These interfaces accept requests written in English or some other
language and attempt to "understand" them.

 A natural language interface usually has its own "schema," which is


similar to the database conceptual schema, as well as a dictionary
of important words.

 The natural language interface refers to the words in its schema, as


well as to the set of standard words in its dictionary, to interpret the
request.

 If the interpretation is successful, the interface generates a


highlevel query corresponding to the natural language request and
submits it to the DBMS for processing; otherwise, a dialogue is
started with the user to clarify the request.
Interfaces for Parametric Users
 Parametric users, such as bank tellers, often have a small set of
operations that they must perform repeatedly.
 Systems analysts and programmers design and implement a
special interface for each known class of naive users.
 Usually, a small set of abbreviated commands is included, with
the goal of minimizing the number of keystrokes required for each
request.

 example, function keys in a terminal can be programmed to


initiate the various commands.

 This allows the parametric user to proceed with a minimal number


of keystrokes.
Interfaces for the DBA.

 Most database systems contain privileged commands that can be


used only by the DBA's staff.

 These include commands for


 creating accounts,

 setting system parameters,

 granting account authorization,

 changing a schema, and

 reorganizing the storage structures of a database.


Database Architectures and
Classification
Include
1. Centralized
2. Client server
Centralized
 All process related to DB will be carried out on remote device.
 Only control and information will be send to the terminal device
Client Server
Include
1. Basic client server
2. Two tier client server
3. Three tier client server

Basic client server


 Assumes an underlying framework that consists of many PCs and
workstations as well as a smaller number of mainframe machines,
connected via LAN
 Client  User Machine  Local Processing
 Server  Provide services
Two-Tier Client/Server Architectures

 Called two tier because there are mainly two parts client and
server.
 Finding the logical point for dividing is the main process here.
 Query and transaction functionality remained on the server

side.
 The client will include user interface program and application

programs.
Three-Tier Client/Server Architectures

 A new layer between the client and server layer Application


server or web server
 Acts as an intermediate role by handling the business rules with in
it, used to access data from the database server.
 Also provide security to the data by checking the client credential
before forwarding the request to server
Questions
1. Define the entity types for the COMPANY database, based on the
requirements described as below:
2. The company is organized into departments. Each department has a
unique name, a unique number, and a particular employee who
manages the department. We keep track of the start date when that
employee began managing the department. A department may have
several locations.
3. A department controls a number of projects, each of which has a
unique name, a unique number, and a single location.
4. Need to store each employee's name, social security number, address,
salary, sex, and birthdate. An employee is assigned to one department
but may work on several projects, which are not necessarily controlled
by the same department. Keep track of the number of hours per week
that an employee works on each project. We also keep track of the
direct supervisor of each employee.
5. We want to keep track of the dependents of each employee for
insurance purposes. We keep each dependent's first name, sex,
Construct an E-R diagram for a hospital with a set of patients and a
set of medical doctors. Associate with each patient a log of the
various tests and examinations conducted
Design an E-R diagram for keeping track of the exploits of your
favourite sports team. You should store the matches played, the
scores in each match, the players in each match and individual
player statistics for each match. Summary statistics should be
modeled as derived attributes.

You might also like