MODULE-1

INTRODUCTION TO BASIC CONCEPTS OF DATABASE SYSTEMS:

Before we move into this subject, we must be acquainted with some basic terms
used in database management system.
DATA:
The raw facts are called as data. The word “raw” indicates that they are not
processed.
It is in unorganised form. It is not used in decision making.
Example: 01 is the data.
INFORMATION:
The processed data is known as information.
It is in organised form.
It is used in decision making.
Example: Roll No: 01; then it becomes information.
KNOWLEDGE:
Knowledge refers to the practical use of information. Knowledge
necessarily involves a personal experience. It is referred to as processed
information. It is more useful in business processing to make decision for an
organisation.
Example: The Name starts with alphabetical order a has Roll No 01.

DATA/INFORMATION PROCESSING:
The process of converting the data (raw facts) into meaningful information is
called as data/information processing.

DISADVANTAGES OF FILE-ORIENTED SYSTEM:

The following are the disadvantages of File-Oriented System:
1. Data Redundancy and Inconsistency: Since files and application programs
are created by different programmers over a long period of time, the files
are likely to be having different formats and may be written in several
programming languages. Moreover, the same duplicate piece of
 information may be present in several places. This redundancy leads to
higher storage and access cost. In addition, it may lead to data
inconsistency.
2. Difficulty in Accessing Data: The conventional file processing
environments do not allow needed data to be retrieved in a convenient
and efficient manner. Therefore we need to develop a better data retrieval
system for general use.
3. Data Isolation: Since data is scattered in various files, and files may be in
different formats, it is difficult to write new application programs to
retrieve the appropriate data.
4. Concurrent Access Anomalies: In order to improve the overall performance
of the system and obtain a faster response time, many systems allow
multiple users to update the data simultaneously. In such an environment,
interaction of concurrent updates may result in inconsistent data.
5. Security Problems: Not every user of the database system should be able
to access all the data. For example, in banking system, payroll personnel
need only that part of the database that has information about various
bank employees. They do not need access to information about customer
accounts. It is difficult to enforce such security constraints.
6. Integrity Problems: The data values stored in the database must satisfy
certain types of consistency constraints. For example, the balance of a
bank account may never fall below a prescribed amount. These
constraints are enforced in the system by adding appropriate code in the
various application programs. When new constraints are added, it is
difficult to change the programs to enforce them. The problem is
compounded when constraints involve several data items for different
files.
7. Atomicity Problem: A computer system like any other mechanical or
electrical device is subject to failure. In many applications, it is crucial to
ensure that once a failure has occurred and has been detected, the data
are restored to the consistent state existed prior to the failure.

DATABASE:
A database is a collection of related data.
(OR)
A database is a collection of information that is organized so that it can be easily
accessed, managed and updated.
Examples / Applications of Database Systems:
The following are the various kinds of applications/organizations uses databases
for their business processing activities in their day-to-day life. They are:
1.Banking: For customer information, accounts, and loans, and banking
transactions.
2. Airlines: For reservations and schedule information. Airlines were among the
first to use
databases in a geographically distributed manner—terminals situated around the
world accessed the central database system through phone lines and other data
networks.
3.Universities: For student information, course registrations, and grades.
4.Credit Card Transactions: For purchases on credit cards and generation of
monthly statements.
5. Telecommunication: For keeping records of calls made, generating monthly
bills, maintaining balances on prepaid calling cards, and storing information
about the communication networks.
6. Finance: For storing information about holdings, sales, and purchases of
financial instruments such as stocks and bonds.
7. Sales: For customer, product, and purchase information.
8. Manufacturing: For management of supply chain and for tracking production
of items in factories, inventories of items in warehouses/stores, and order for
items.
9. Human resources: For information about employees, salaries, payroll taxes
and benefits, and for generation of paychecks.
10. Railway Reservation Systems: For reservations and schedule information.
11. Web: For access the Back accounts and to get the balance amount.
12. E –Commerce: For Buying a book or music CD and browse for things like
watches, mobiles from the Internet.
CHARACTERISTICS OF DATABASE: The database approach has some very
characteristic features which are discussed in detail below:
Structured and Described Data: Fundamental feature of the database approach
is that the database system does not only contain the data but also the complete
definition and description of these data. These descriptions are basically details
about the extent, the structure, the type and the format of all data and,
additionally, the relationship between the data. This kind of stored data is called
metadata or, data about data.
Separation of Data and Applications: Application software does not need any
knowledge about the physical data storage like encoding, format, storage place,
etc. It only communicates with the management system of a database (DBMS)
via a standardized interface with the help of a standardized language like SQL.
The access to the data and the metadata is entirely done by the DBMS. In this
way all the applications can be totally separated from the data.
Data Integrity: Data integrity is a byword for the quality and the reliability of the
data of a database system. In a broader sense data integrity includes also the
protection of the database from unauthorized access (confidentiality) and
unauthorized changes. Data reflect facts of the real world.
Transactions: A transaction is a bundle of actions which are done within a
database to bring it from one consistent state to a new consistent state. In
between the data are inevitable inconsistent. A transaction is atomic what
means that it cannot be divided up any further. Within a transaction all or none
of the actions need to be carried out. Doing only a part of the actions would lead
to an inconsistent database state. Example: One example of a transaction is the
transfer of an amount of money from one bank account to another.
Data Persistence: Data persistence means that in a DBMS all data is maintained
as long as it is not deleted explicitly. The life span of data needs to be
determined directly or indirectly be the user and must not be dependent on
system features. Additionally, data once stored in a database must not be lost.
Changes of a database which are done by a transaction are persistent. When a
transaction is finished even a system crash cannot put the data in danger.
TYPES OF DATABASES: Database can be classified according to the following
factors. They are:
1.Number of Users
2.Database Location
3.Expected type
4.Extent of use
1. Based on number of Users: According to the number of users the databases
can be classified into following types. They are:
a). Single user
b). Multiuser
Single user database:
 Single user database supports only one user at a time.
 Desktop or personal computer database is an example for single user
database.
Multiuser database:
 Multi user database supports multiple users at the same time.
 Workgroup database and enterprise databases are examples for multiuser
database.
Workgroup database: If the multiuser database supports relatively small number
of users (fewer than 50) within an organization is called as Workgroup database.
Enterprise database: If the database is used by the entire organization and
supports multiple users (more than 50) across many departments is called as
Enterprise database.
2. Based on Location: According to the location of database the databases can
be classified into following types. They are:
a)Centralized Database
b)Distributed Database
Centralized Database: It is a database that is located, stored, and maintained in
a single location. This location is most often a central computer or database
system, for example a desktop or server CPU, or a mainframe computer. In most
cases, a centralized database would be used by an organization (e.g. a business
company) or an institution (e.g. a university.)
Distributed Database: A distributed database is a database in which storage
devices are not all attached to a common CPU. It may be stored in multiple
computers located in the same physical location, or may be dispersed over a
network of interconnected computers.
INTRODUCTION TO DATABASE-MANAGEMENT SYSTEM:
Database Management System: A database-management system (DBMS) is a
collection of interrelated data and a set of programs to access those data.
The DBMS is a general purpose software system that facilitates the process of
defining constructing and manipulating databases for various applications.
Goals of DBMS:
The primary goal of a DBMS is to provide a way to store and retrieve database
information that is both convenient and efficient
1.Manage large bodies of information
2. Provide convenient and efficient ways to store and access information
3. Secure information against system failure or tampering
4. Permit data to be shared among multiple users
Properties of DBMS:
1.A Database represents some aspect of the real world. Changes to the real
world reflected in the database.
2.A Database is a logically coherent collection of data with some inherent
meaning.
3.A Database is designed and populated with data for a specific purpose.
Need of DBMS:
1. Before the advent of DBMS, organizations typically stored information using a
“File Processing Systems”.
Example of such systems is File Handling in High Level Languages like C, Basic
and COBOL etc., these systems have Major disadvantages to perform the Data
Manipulation. So to overcome those drawbacks now we are using the DBMS.
2.Database systems are designed to manage large bodies of information.
3. In addition to that the database system must ensure the safety of the
information stored, despite system crashes or attempts at unauthorized access.
If data are to be shared among several users, the system must avoid possible
anomalous results.
ADVANTAGES OF A DBMS OVER FILE SYSTEM:
Using a DBMS to manage data has many advantages: Data Independence:
Application programs should be as independent as possible from details of data
representation and storage. The DBMS can provide an abstract view of the data
to insulate application code from such details.
Efficient Data Access: A DBMS utilizes a variety of sophisticated techniques to
store and retrieve data efficiently. This feature is especially important if the data
is stored on external storage devices.
Data Integrity and Security: If data is always accessed through the DBMS, the
DBMS can enforce integrity constraints on the data. For example, before
inserting salary information for an employee, the DBMS can check that the
department budget is not exceeded. Also, the DBMS can enforce access controls
that govern what data is visible to different classes of users.
Concurrent Access and Crash Recovery: A database system allows several users
to access the database concurrently. Answering different questions from
different users with the same (base) data is a central aspect of an information
system. Such concurrent use of data increases the economy of a system. An
example for concurrent use is the travel database of a bigger travel agency. The
employees of different branches can access the database concurrently and book
journeys for their clients. Each travel agent sees on his interface if there are still
seats available for a specific journey or if it is already fully booked. A DBMS also
protects data from failures such as power failures and crashes etc. by the
recovery schemes such as backup mechanisms and log files etc.
Data Administration: When several users share the data, centralizing the
administration of data can offer significant improvements. Experienced
professionals, who understand the nature of the data being managed, and how
different groups of users use it, can be responsible for organizing the data
representation to minimize redundancy and fine-tuning the storage of the data
to make retrieval efficient.
Reduced Application Development Time: DBMS supports many important
functions that are common to many applications accessing data stored in the
DBMS. This, in conjunction with the high-level interface to the data, facilitates
quick development of applications. Such applications are also likely to be more
robust than applications developed from scratch because many important tasks
are handled by the DBMS instead of being implemented by the application.

DISADVANTAGES OF DBMS:
Danger of a Overkill: For small and simple applications for single users a
database system is often not advisable.
Complexity: A database system creates additional complexity and requirements.
The supply and operation of a database management system with several users
and databases is quite costly and demanding.
Qualified Personnel: `The professional operation of a database system requires
appropriately trained staff. Without a qualified database administrator nothing
will work for long.
Costs: Through the use of a database system new costs are generated for the
system itself but also for additional hardware and the more complex handling of
the system.
Lower Efficiency: A database system is a multi-use software which is often less
efficient than specialized software which is produced and optimized exactly for
one problem.
DATA MODELS: The entire structure of a database can be described using a
data model. A data model is a collection of conceptual tools for describing Data
models can be classified into following types.
1.Object Based Logical Models.
2.Record Based Logical Models.
3.Physical Models.
1.Object Based Logical Models: These models can be used in describing the data
at the logical and view levels. These models are having flexible structuring
capabilities classified into following types. a) The entity-relationship model. b)
The object-oriented model. c) The semantic data model. d) The functional data
model.
2.Record Based Logical Models: These models can also be used in describing the
data at the logical and view levels. These models can be used for both to specify
the overall logical structure of the database and a higher-level description. These
models can be classified into,
1. Relational model.
2. Network model.
3. Hierarchical model.
3. Physical Models: These models can be used in describing the data at the
lowest level, i.e. physical level. These models can be classified into 1. Unifying
model 2. Frame memory model.

DATABASE USERS & DATABASE ADMINISTRATORS: People who work with a

database can be categorized as database users or database administrators.
Database Users: There are four different types of database-system users,
differentiated by the way they expect to interact with the system.
Naive users: Naive users are unsophisticated users who interact with the system
by invoking one of the application programs that have been written previously.
For example, a bank teller who needs to transfer $50 from account A to account
B invokes a program called transfer. This program asks the teller for the amount
of money to be transferred, the account from which the money is to be
transferred, and the account to which the money is to be transferred.
Application programmers: Application programmers are computer professionals
who write application programs. Application programmers can choose from many
tools to develop user interfaces. Rapid application development (RAD) tools are
tools that enable an application programmer to construct forms and reports
without writing a program.
Sophisticated users: Sophisticated users interact with the system without writing
programs. Instead, they form their requests in a database query language. They
submit each such query to a query processor, whose function is to break down
DML statements into instructions that the storage manager understands.
Analysts who submit queries to explore data in the database fall in this category.
Specialized users: Specialized users are sophisticated users who write
specialized database applications that do not fit into the traditional data-
processing framework.
Database Administrator: One of the main reasons for using DBMSs is to have
central control of both the data and the programs that access those data. A
person who has such central control over the system is called a database
administrator (DBA).
Database Administrator Functions/Roles:
The functions of a DBA include:
Schema definition: The DBA creates the original database schema by executing a
set of data definition statements in the DDL, Storage structure and access-
method definition.
Schema and physical-organization modification: The DBA carries out changes to
the schema and physical organization to reflect the changing needs of the
organization, or to alter the physical organization to improve performance.
Granting of authorization for data access: By granting different types of
authorization, the database administrator can regulate which parts of the
database various users can access. The authorization information is kept in a
special system structure that the database system consults whenever someone
attempts to access the data in the system.
Routine maintenance: Examples of the database administrator’s routine
maintenance activities are:
1.Periodically backing up the database, either onto tapes or onto remote servers,
to prevent loss of data in case of disasters such as flooding.
2.Ensuring that enough free disk space is available for normal operations, and
upgrading disk space as required.
3. Monitoring jobs running on the database and ensuring that performance is not
degraded by very expensive tasks submitted by some users.
LEVELS OF ABSTRACTION IN A DBMS:
Hiding certain details of how the data are stored and maintained. A major
purpose of database system is to provide users with an “Abstract View” of the
data.
In DBMS there are 3 levels of data abstraction. The goal of the abstraction in the
DBMS is to separate the users request and the physical storage of data in the
database.
Levels of Abstraction:
Physical Level: The lowest Level of Abstraction describes “How” the data are
actually stored. The physical level describes complex low level data structures in
detail.
Logical Level: This level of data Abstraction describes “What” data are to be
stored in the database and what relationships exist among those data. Database
Administrators use the logical level of abstraction.
View Level: It is the highest level of data Abstracts that describes only part of
entire database. Different users require different types of data elements from
each database. The system may provide many views for the some database.
THREE SCHEMA ARCHITECTURE:
Schema: The overall design of the database is called the “Schema” or “Meta
Data”. A database schema corresponds to the programming language type
definition. The value of a variable in programming language corresponds to an
“Instance” of a database Schema.
Three Schema Architecture: The goal of this architecture is to separate the user
applications and the physical database. In this architecture, schemas can be
defined at the following three levels:
1.The internal level has an internal schema, which describes the physical storage
structure of the database. The internal schema uses a physical data model and
describes the complete details of data storage and access paths for the
database.
2.The conceptual level has a conceptual schema, which describes the structure
of the whole database for a community of users. The conceptual schema hides
the details of physical storage structures and concentrates on describing entities,
data types, relationships, user operations, and constraints. A high-level data
model or an implementation data model can be used at this level.
3. The external or view level includes a number of external schemas or user
views. Each external schema describes the part of the database that a particular
user group is interested in and hides the rest of the database from that user
group. A high-level data model or an implementation data model can be used at
this level.
 Fig: Three-Schema Architecture
DATA INDEPENDENCE:
A very important advantage of using DBMS is that it offers Data Independence.
The ability to modify a scheme definition in one level without affecting a scheme
definition in a higher level is called data independence. There are two kinds:
1. Physical Data Independence
2. Logical Data Independence
Physical Data Independence: The ability to modify the physical schema without
causing application programs to be rewritten.
Modifications at this level are usually to improve performance.
Logical Data Independence: The ability to modify the conceptual schema without
causing application programs to be rewritten.
Usually done when logical structure of database is altered.
Logical data independence is harder to achieve as the application programs are
usually heavily dependent on the logical structure of the data.

Conceptual Data Modelling:

A Conceptual Data Model is an organized view of database concepts and their
relationships. The purpose of creating a conceptual data model is to establish
entities, their attributes, and relationships. In this data modeling level, there is
hardly any detail available on the actual database structure. Business
stakeholders and data architects typically create a conceptual data model.

The 3 basic tenants of Conceptual Data Model are

  Entity: A real-world thing
 Attribute: Characteristics or properties of an entity
 Relationship: Dependency or association between two entities

Data model example:

 Customer and Product are two entities. Customer number and name are
attributes of the Customer entity
 Product name and price are attributes of product entity
 Sale is the relationship between the customer and product

Conceptual
Data Model
Characteristics of a conceptual data model

 Offers Organisation-wide coverage of the business concepts.

 This type of Data Models are designed and developed for a business
audience.
 The conceptual model is developed independently of hardware
specifications like data storage capacity, location or software
specifications like DBMS vendor and technology. The focus is to represent
data as a user will see it in the “real world.”

Conceptual data models known as Domain models create a common vocabulary

for all stakeholders by establishing basic concepts and scope.

Logical Data Model

The Logical Data Model is used to define the structure of data elements and to
set relationships between them. The logical data model adds further information
to the conceptual data model elements. The advantage of using a Logical data
model is to provide a foundation to form the base for the Physical model.
However, the modeling structure remains generic.
 Logical Data
Model
At this Data Modelling level, no primary or secondary key is defined. At this Data
modelling level, you need to verify and adjust the connector details that were set
earlier for relationships.
Characteristics of a Logical data model

 Describes data needs for a single project but could integrate with other
logical data models based on the scope of the project.
 Designed and developed independently from the DBMS.
 Data attributes will have datatypes with exact precisions and length.
 Normalization processes to the model is applied typically till 3NF.

Physical Data Model

A Physical Data Model describes a database-specific implementation of the
data model. It offers database abstraction and helps generate the schema. This
is because of the richness of meta-data offered by a Physical Data Model. The
physical data model also helps in visualizing database structure by replicating
database column keys, constraints, indexes, triggers, and other RDBMS features.

Physical Data
Model

Characteristics of a physical data model:

 The physical data model describes data need for a single project or
application though it maybe integrated with other physical data models
based on project scope.
 Data Model contains relationships between tables that which addresses
cardinality and nullability of the relationships.
 Developed for a specific version of a DBMS, location, data storage or
technology to be used in the project.
  Columns should have exact datatypes, lengths assigned and default
values.
 Primary and Foreign keys, views, indexes, access profiles, and
authorizations, etc. are defined.

Advantages and Disadvantages of Data Model:

Advantages of Data model:

 The main goal of a designing data model is to make certain that data
objects offered by the functional team are represented accurately.
 The data model should be detailed enough to be used for building the
physical database.
 The information in the data model can be used for defining the
relationship between tables, primary and foreign keys, and stored
procedures.
 Data Model helps business to communicate the within and across
organizations.
 Data model helps to documents data mappings in ETL process
 Help to recognize correct sources of data to populate the model

Disadvantages of Data model:

 To develop Data model one should know physical data stored

characteristics.
 This is a navigational system produces complex application development,
management. Thus, it requires a knowledge of the biographical truth.
 Even smaller change made in structure require modification in the entire
application.
 There is no set data manipulation language in DBMS.

Entity-Relationship model:
History:
Peter Chen is credited with introducing the widely adopted ER model in his paper
“The Entity Relationship Model-Toward a Unified View of Data“. The focus was on
entities and relationships and he introduced a diagramming representation for
database design as well.

His model was inspired by the data structure diagrams introduced by Charles
Bachman. One of the early forms of ER diagrams, Bachman diagrams are named
after him.

ER Models in Database Design:

They are widely used to design relational databases. The entities in the ER
schema become tables, attributes and converted the database schema. Since
they can be used to visualize database tables and their relationships it’s
commonly used for database troubleshooting as well.

ER diagrams in software engineering:

Entity relationship diagrams are used in software engineering during the

planning stages of the software project. They help to identify different system
elements and their relationships with each other. It is often used as the basis for
data flow diagrams or DFD’s as they are commonly known.

For example, an inventory software used in a retail shop will have a database
that monitors elements such as purchases, item, item type, item source and item
price. Rendering this information through an ER diagram would be something
like this:

ER diagram example with entity having attributes

ER Diagram Symbols and Notations:

Elements in ER diagrams
There are three basic elements in an ER Diagram: entity, attribute, relationship.
There are more elements which are based on the main elements. They are weak
entity, multi valued attribute, derived attribute, weak relationship, and recursive
relationship. Cardinality and ordinality are two other notations used in ER
diagrams to further define relationships.

Entity

An entity can be a person, place, event, or object that is relevant to a given

system. For example, a school system may include students, teachers, major
courses, subjects, fees, and other items. Entities are represented in ER diagrams
by a rectangle and named using singular nouns.

Weak Entity

A weak entity is an entity that depends on the existence of another entity. In

more technical terms it can be defined as an entity that cannot be identified by
its own attributes. It uses a foreign key combined with its attributed to form the
primary key. An entity like order item is a good example for this. The order item
will be meaningless without an order so it depends on the existence of the order.

Weak Entity Example in ER diagrams

Attribute:

An attribute is a property, trait, or characteristic of an entity, relationship, or

another attribute. For example, the attribute Inventory Item Name is an attribute
of the entity Inventory Item. An entity can have as many attributes as necessary.
Meanwhile, attributes can also have their own specific attributes. For
example, the attribute “customer address” can have the attributes
number, street, city, and state. These are called composite attributes.
Note that some top level ER diagrams do not show attributes for the sake of
simplicity. In those that do, however, attributes are represented by oval shapes.
Attributes in ER diagrams, Note that an attribute can have its own
attributes ( composite attribute )
Multivalued Attribute:
If an attribute can have more than one value it is called a multi-valued attribute.
It is important to note that this is different from an attribute having its own
attributes. For example, a teacher entity can have multiple subject values.

Example of a multivalued attribute

Derived Attribute:

An attribute based on another attribute. This is found rarely in ER diagrams. For

example, for a circle, the area can be derived from the radius.

Derived Attribute in ER diagrams

Relationship:

A relationship describes how entities interact. For example, the entity

“Carpenter” may be related to the entity “table” by the relationship “builds” or
“makes”. Relationships are represented by diamond shapes and are labeled
using verbs.
 Using Relationships in
Entity Relationship Diagrams

Recursive Relationship:

If the same entity participates more than once in a relationship it is known as a

recursive relationship. In the below example an employee can be a supervisor
and be supervised, so there is a recursive relationship.

Example of a recursive relationship in ER diagrams

Cardinality and Ordinality:

These two further defines relationships between entities by placing the

relationship in the context of numbers. In an email system, for example, one
account can have multiple contacts. The relationship, in this case, follows a “one
to many” model. There are a number of notations used to present cardinality in
ER diagrams. Chen, UML, Crow’s foot, Bachman are some of the popular
notations. Creately supports Chen, UML and Crow’s foot notations. The following
example uses UML to show cardinality.

Cardinality in ER diagrams using UML notation

How to Draw ER Diagrams:

Below points show how to go about creating an ER diagram.

1. Identify all the entities in the system. An entity should appear only
once in a particular diagram. Create rectangles for all entities and name
them properly.
2. Identify relationships between entities. Connect them using a line and
add a diamond in the middle describing the relationship.
 3. Add attributes for entities. Give meaningful attribute names so they can
be understood easily.

ER Diagram Best Practices:

1. Provide a precise and appropriate name for each entity, attribute, and
relationship in the diagram. Terms that are simple and familiar always
beats vague, technical-sounding words. In naming entities, remember to
use singular nouns. However, adjectives may be used to distinguish
entities belonging to the same class (part-time employee and full-time
employee, for example). Meanwhile attribute names must be meaningful,
unique, system-independent, and easily understandable.
2. Remove vague, redundant or unnecessary relationships between entities.
3. Never connect a relationship to another relationship.
4. Make effective use of colors. You can use colors to classify similar entities
or to highlight key areas in your diagrams.

ER Diagram Templates:
Below are some ER diagram templates so you can get started quickly. Clicking
on the image and in the new page that opens click the “Use as Template”
button. For more templates check our ER diagram templates section.

ER Diagram Template of exam database

A basic ER diagram template for a quick start
Basic ER Diagram template

Benefits of ER diagrams:

ER diagrams constitute a very useful framework for creating and manipulating

databases.

First, ER diagrams are easy to understand and do not require a person to

undergo extensive training to be able to work with it efficiently and accurately.
This means that designers can use ER diagrams to easily communicate with
developers, customers, and end users, regardless of their IT proficiency.

Second, ER diagrams are readily translatable into relational tables which can be
used to quickly build databases. In addition, ER diagrams can directly be used by
database developers as the blueprint for implementing data in specific software
applications.

Lastly, ER diagrams may be applied in other contexts such as describing the

different relationships and operations within an organization.

Constraints in Entity-Relationship Models:

• Keys are attributes or sets of attributes that uniquely identify an entity within
its entity set.

• Single-value constraints require that a value be unique in certain contexts.

• Referential integrity constrains require that a value referred to actually exists

in the database.

• Domain constraints specify what set of values an attribute can take.

• General constraints are arbitrary constraints that should hold in the database.
We will study some examples in the second half of the semester.
• Constraints are part of the schema of a database.

Mapping Cardinality Constraints:

Express the number of entities to which another entity can be associated via a
relationship set.

Most useful in describing binary relationship sets.

For a binary relationship set the mapping cardinality must be one of the following
types:

One to one

One to many

Many to one

Many to many

(a) One to One

(b) One to Many

(a)Many to One

(b)Many to Many

Cardinality Constraints:

We express cardinality constraints by drawing either a directed line (),

signifying “one,” or an undirected line (—), signifying “many,” between the
relationship set and the entity set.

One-to-one relationship:
 A customer is associated with at most one loan via the relationship borrower

A loan is associated with at most one customer via borrower

One-To-Many Relationship:

In the one-to-many relationship a loan is associated with at most one customer

via borrower, a customer is associated with several (including 0) loans via
borrower

Many-To-One Relationships:

In a many-to-one relationship a loan is associated with several (including 0)

customers via borrower, a customer is associated with at most one loan via
borrower

Many-To-Many Relationship:

A customer is associated with several (possibly 0) loans via borrower

A loan is associated with several (possibly 0) customers via borrower

Participation of an Entity Set in a Relationship Set:

Total participation (indicated by double line): every entity in the entity set
participates in at least one relationship in the relationship set

E.g. participation of loan in borrower is total

Example: Every loan must have a customer associated to it via borrower

Partial participation: some entities may not participate in any relationship in the
relationship set

Example: participation of customer in borrower is partial

Roles:

Entity sets of a relationship need not be distinct

The labels “manager” and “worker” are called roles; they specify how employee
entities interact via the works_for relationship set.

Roles are indicated in E-R diagrams by labeling the lines that connect diamonds
to rectangles.

Role labels are optional, and are used to clarify semantics of the relationship

Cardinality Constraints on Ternary Relationship:

We allow at most one arrow out of a ternary (or greater degree) relationship to
indicate a cardinality constraint
E.g. an arrow from works_on to job indicates each employee works on at most
one job at any branch.

If there is more than one arrow, there are two ways of defining the meaning.

E.g a ternary relationship R between A, B and C with arrows to B and C could

mean

1. each A entity is associated with a unique entity from B and C or

2. each pair of entities from (A, B) is associated with a unique C entity, and each
pair (A, C) is associated with a unique B

Each alternative has been used in different formalisms

To avoid confusion, we outlaw more than one arrow