Physical Database Requirements.pdf

SATA TECHNOLOGY AND BUSINESS COLLEGE
Instructor: - Tsega S. E-mail address:- tebibu4.ts212@gmail.com Page 1
Ethiopian TVET System
Database Administration
Identifying Physical Database Requirements
Level=4 Year=2 Program= Regular
Compiled by: Tsega Solomon
Jun 2021

LO 1: Define Database Design
What is Database Design?
Database design is defined as a collection of series of steps which are used in designing, creating,
implementing, and maintaining database system.
The main purpose of designing a database is to produce Conceptual, logical and physical models of designs
for the proposed database system.
The database design process involves three major stages:
The Database Design Process
There are 3 Database Design Process. These are
1. Conceptual Database Design
2. Logical Database design
3. Physical Database design
1. Conceptual Database Design
Conceptual database design is a process of building/ formation Conceptual Data Model or Conceptual
Database structure.
Conceptual Data Model / Conceptual Database structure or conceptual Database representation is organized
view of database concepts and their relationships.
Conceptual schema or conceptual data model is a map of concepts and their relationships used
for databases. So Conceptual Database design is a process of building organized view of database concepts
and their relationships.
Conceptual Database design is a process of building conceptual representation of database, which has the
identification of the important entities, relationships, and attributes.
Conceptual Data Model / Conceptual Database structure or conceptual Database representation
Conceptual Database design is a process of building organized view of database concepts and their
relationships means identifying important entities, relationships, attributes and constructing ERD/ERM.
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.

Tenants of 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.
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
7
Characteristics of a Conceptual Data Model
 They represent the overall view of structure of data required for the database independent of any
software or data storage structure.
 They focus to represent data as a user will see it in the "real world."
 They Offers the databases wide coverage of concept mapping and their Relationship.
 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.
2. Logical Database Design
Logical Database design is a process of building/ formation Logical Data Model or Logical Database
structure.
Logical Database design is a process of translating conceptual Database design into a logical data model.
Logical Data Model or Logical Database structure is a process of translating conceptual design ERM into a
set of relations.
Logical design is the process of constructing a model of the information used in an enterprise based on a
specific data model (e.g. relational, hierarchical or network or object), but independent of a particular
DBMS and other physical considerations.

The logical design is more conceptual and abstract representation of conceptual design.it is a higher level
conceptual abstraction with selected specific data model to implement the data structure. It is particular
DBMS independent and with no other physical considerations.
Logical database design is a process that define the specific data content, relationships within and between
groups of data, the system environment supporting your data warehouse, the data transformations required,
and the frequency with which data is refreshed. 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 database design is the process of transforming (or mapping) a conceptual schema of the application
domain into a schema for the data model underlying a particular DBMS, such as the relational or object-
oriented data model. This mapping can be understood as the result of trying to achieve two distinct sets of
goals: (i) representation goal: preserving the ability to capture and distinguish all valid states of the
conceptual schema; (ii) data management goals: addressing issues related to the ease and cost of querying
the logical schema, as well as costs of storage and constraint maintenance. This entry focuses mostly on the
mapping of (Extended) Entity-Relationship (EER) diagrams to relational databases.
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 data types with exact precisions and length.
 Normalization processes to the model is applied typically till 3NF.
Customer Table
Name Customer Number
Product Table
Product Name Price

3. Physical Database Design
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 database design is concerned with transforming the logical database structures into an internal
model consisting of stored records, files, indexes and other physical structures”
Physical database design is the process of implementing the logical data model in a DBMS.
The process of implementing a relational data model in a DBMS involves creating a set of relations.
Creating relations in a DBMS involves:
 Selecting the files in which to store the relations.
 Ensuring that the set of relations are efficient to access.
 Implementing additional database structures to improve the efficiency of the database. For example,
an index improves the speed of some queries and the database design must decide which indexes
should be created.
 The decisions made during the physical database design stage affect the speed of the database, the
accessibility of the database, the security implemented on the database and the user-friendliness of
the database.
Characteristics of a Physical Data Model
 The physical data model describes data need for a single project or application though it may be
integrated with other physical data models based on project scope.
 Data Model contains relationships between tables that which addresses cardinality and null ability 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 data types, lengths assigned and default values.
 Primary and Foreign keys, views, indexes, access profiles, and authorizations, etc. are defined.
What Information is needed for Physical Database Design.
Information needed for physical file and database design includes:
 Normalized relations plus size estimates for them
 Definitions of each attribute
 Descriptions of where and when data are used
 Entered, retrieved, deleted, updated, and how often
 Expectations and requirements for response time, and data security, backup, recovery, retention and
integrity
 Descriptions of the technologies used to implement the database.

What issues affect physical design?
Three things affect physical database design. These are
1. Database Size
2. Database Usage
3. DBMS Manufacturer
1. Database Size
The maximum size of the database. The size of a database is determined by how many relations are in the
database and how much data is held in each relation. The amount of data in the database will determine how
long operations take to perform.
Generally size of a database will affect physical design and it is determined by
 Number of relations
 Number of tuples
 Size of each tuple
2. Database Usage
The use that will be made of the database. If a database is queried often then it will have to be designed to
answer a large number of queries quickly. If data is added to the database often then it will have to be
designed to handle many inserts quickly.
Number of database operation‟s carried out on the database such as
 Number of updates
 Number of inserts
 Number of deletes
 Number of queries
The objective of physical database design is to use the knowledge gained from analyzing the use and size of
the database to improve the efficiency of the database.
The efficiency of the database is determined by the requirements of the users and the database designer.
For example, an efficient database may be one that executes queries quickly or uses the least amount of disc
space.
There are many different tools that the database designer may use when implementing the physical database.
Indexing increases the speed of accessing the data by storing special data structures which can be processed
very quickly. Caching uses part of the computer‟s main memory to store part of the database. Main memory
is very quick to access.
Renormalization/De normalization is a process of changing the structure of the relations to improve the
performance of queries and updates.

3. DBMS Manufacturer
What is Database Management System (DBMS).
A database management system (DBMS) is a software package with computer programs that controls the
creation, maintenance, and use of a database. It allows organizations to conveniently develop databases for
various applications. A database is an integrated collection of data records, files, and other objects. A
DBMS allows different user application programs to concurrently access the same database. DBMSs may
use a variety of database models, such as the relational model or object model, to conveniently describe and
support applications. It typically supports query languages, which are in fact high-level programming
languages, dedicated database languages that considerably simplify writing database application programs.
Database languages also simplify the database organization as well as retrieving and presenting information
from it. A DBMS provides facilities for controlling data access, enforcing data integrity, managing
concurrency control, and recovering the database after failures and restoring it from backup files, as well as
maintaining database security.
Database Architecture
What is Database Architecture?
A Database Architecture is a representation of DBMS design. It helps to design, develop, implement, and
maintain the database management system.
DBMS architecture allows dividing the database system into individual components that can be
independently modified, changed, replaced, and altered. It also helps to understand the components of a
database.
Database architecture is a model describing the logic of distribution of database objects throughout the
system. It is usually designed in accordance with the business logic of a particular application that will use
the database.
Database Architecture Principles
Generally, the architecture takes into account three aspects of the application‟s logic:
 What objects are stored in the database?
 How the objects are accessed and updated
 How the objects interact with each other
 In an ideal situation, information required by an application should be extracted from the database as
quickly and with as little consumption of system resources as possible.
 The better database architecture is, the faster application can obtain the necessary and sufficient
amount of data, and the faster it can help the user.

Database Construction Basics
Databases store information in tables. Each table can have its own storage engine, and different storage
engines perform differently. Their performance depends on algorithms handling HDD read-write requests,
working with memory, data caching, and other features.
Therefore, the design of database architecture is inseparably connected with development of an application.
A practical approach is to divide business objects in groups by their properties, access rates, and types of
operations that will be performed upon them.
Type of Database Architecture
There are mainly three types of Database architecture:
1. One (Single) Tier Architecture
2. Two Tier Architecture
3. Three Tier Architecture

1. One Tier Architecture
It is the simplest architecture of Database in which the data base user, the client side application program,
server side application program, and Database system all reside(located) on one machine called client
machine.
In this architecture, the database is directly available to the user; any request made by client doesn‟t require
a network connection to perform the action on the database. It means the user can directly sit on the DBMS
and uses it. Any changes done here will directly be done on the database itself. It doesn't provide a handy
tool for end users.
The 1-Tier architecture is used for development of the local application, where programmers can directly
communicate with the database for the quick response.
For example
A simple one tier architecture example would be anytime you install a Database in your system and access it
to practice SQL queries. Or
Let‟s say you want to fetch the records of employee from the database and the database is available on your
computer system, so the request to fetch employee details will be done by your computer and the records
will be fetched from the database by your computer as well. This type of system is generally referred as
local database system.

2. Two Tier Client/Server Architectures
It is architecture of Database in which the data base user, and the client side application program reside
(located) on one machine called client machine and the and Database system the server side application
program reside (located) on other machine called server machine.
In two-tier architecture, the Database system and server side application program are presented at the server
machine and the DBMS application and DBMS user are presented at the client machine and these two
machines are connected with each other through a reliable network.
Whenever client machine makes a request to access the database present at server using a query language
like SQL, the server perform the request on the database and returns the result back to the client. The
application connection interface such as JDBC, ODBC are used for the interaction between server and
client.
Two tier architecture provides added security to the DBMS as it is not exposed to the end-user directly. It
also provides direct and faster communication.
A 2 Tier Architecture in DBMS is a Database architecture where the presentation layer runs on a client (PC,
Mobile, Tablet, etc.), and data is stored on a server called the second tier.
In Short
The 2-Tier architecture is same as basic client-server. In the two-tier architecture, applications on the client
end can directly communicate with the database at the server side. For this interaction, API's
like: ODBC, JDBC are used.
The user interfaces and application programs are run on the client-side.
The server side is responsible to provide the functionalities like: query processing and transaction
management.
To communicate with the DBMS, client-side application establishes a connection with the server side.
2-Tier Architecture

3. 3-Tier Architecture
In three-tier architecture, another layer is present between the client machine and server machine.
In this architecture, the client application doesn‟t communicate directly with the database systems present at
the server machine, rather the client application communicates with server application and the server
application internally communicates with the database system present at the server.
The Application layer resides between the user and the DBMS, which is responsible for communicating the
user's request to the DBMS system and send the response from the DBMS to the user. The application layer
(business logic layer) also processes functional logic, constraint, and rules before passing data to the user or
down to the DBMS.
Goal of Three Tier Client-Server Architecture
The goal of Three Tier client-server architecture is:
 To separate the user applications and physical database
 To support DBMS characteristics
 Program-data independence
 Supporting multiple views of the data
Example of Three Tier Architecture:
Any large website on the internet, including Goggle .com.

Important Concepts in Physical Database Requirement
1. Table
A data in RDBMS is stored in table. So table is database object which stores data in RDBMS. It is most
common and simplest form of data storage object in RDBMS.
.
Table is horizontal and vertical collation or group or set of cells.
Each cell in a table is data placing places or they are called data banks.
The data that is placed (putted) in this cell are called values. (Horizontally arranged values are called
horizontal values and vertically arranged values are called vertical values).
A. Cell
Cell is a place in a table where one data item or one item of information or values is recorded (putted) or
placed or stored.
The horizontal collations of call are data placing places or data banks which are used to putt (place)
horizontal values. These horizontal collations of cell are called rows which are used to putt horizontal
values.
B. Row
Rows are horizontal series of calls or horizontal series of data placing places (data banks) which are used to
putt horizontal values. Row goes across left to right.
C. Column
The vertical collations of cells are called columns which are used to putt vertical values. Columns are
vertical series of calls or vertical series of data banks which are used to putt (store) vertical values.
Columns goes from top to bottom or from up to dawn.
D. Record
Record is also called = Tuple = Instance or Row.
The horizontal collection of values or entries or single data items in one particular row is called record.
It is a horizontal collection of values about one particular entity arranged in one particular horizontal line (in
one particular row)
It is horizontal collection of values about one particular entity in which is arranged in one particular
horizontal line (one particular row).
Record is one particular row in a table.

E. Field
Field is also called attribute =column =category = Characteristics of entity.
It is single item of data (single data item) or value which is common to all other values or common to all
records. It is single data item about on particular entity but common to all records or entries.
It is the first vertical collection of calls or the first column in the table that is common to all records. It is the
first, and the first value which enters in to the first vertical cells of a table and common to all records.
It is the first vertical value that enters in to that first vertical cells of table and maintain common
information about every other values or records or entities. It is the first value that enters in to the first cells
of a table and maintain common information about every record.
It is a column in a table that is designed to maintain common information about every record in the table.
It is the first vertical value that enters in to the first cell in the table and contain all information‟s associated
with all records.
2. Entity
An entity is any real object.
An entity may be an object with a physical existence or conceptual existence.
A. Physical Entity
Physical entity is entity that has physical existence.
For example
A particular person, car, house, or employee
B. Conceptual Entity
Conceptual entity is entity that has conceptual existence.
For example
A company, job, University Course, Payment or Project that exists by itself.
To develop a company's database for maintaining information on employees, the application should be able
to store and provide data on employee such as:
Which department does employee work for who is his/her manager
What is his/her skill level, etc.

Generally, Entity can be roles, events, locations, tangible things or concepts.
Each entity must have its own identity that distinguishes it from every other entity, called unique identifier.
In E-R Diagram, an entity is represented by a rectangle, and the name is indicated in capital letters.
3. Attribute
Attribute is quality or feature or characteristics or inherent part of someone or same thing.It is a piece of
information which determines the properties of someone or same thing.
It is a quality or feature or characteristics or inherent part of an object, especially one that is important part
of nature. It is a specification that defines a property of an object, element or file. Attribute are
characteristics of an object and field of a table.
Attribute have domain (data type) and type.
1. Domain of Attribute
Domain of attribute is a set of values from which attribute are taken. Each attribute has values taken from a
domain. Domain is data type from which attribute is taken.
Example
Name=is taken from string
Salary =is taken from numbers.
2. Types of Attribute
There are four type of attribute
1. Simple vs. Composite attribute
2. Single valued vs. multi valued attributes.
3. Stored vs. derived attributes.
4. Null attributes.
1. Simple Vs. Composite Attribute
A. Simple (Atomic)
It is an attribute which can‟t be divided in to sub parts.
It contains (stores) single values that can‟t be divided in to sub parts.
Example
 Age
 Gender

B. Composite
It is an attribute that can be divided in to sub parts.
It contains (stores) single values that can be divided in to sub parts.
It is composed of at attributes.
Example
 Name =F-name and L- name
 Address = F- Address and L- Address
2. Single Valued Vs. Multi Valued Attributes
A. Single Valued Attribute
It is attribute that have only one (single) value at a time (at one time).
It contains (stores) single values at a time (at one time) but the value may change over time.
Example
 Name
 ID
 SSN=Social Security Number
 Color of eyes etc.
B. Multi Valued Attributes
It is attribute that have more than one (single) or multiple value at a time (at one time).
It contains (stores) more than one value at a time (at one time).
Example
 Address
 Degree (qualification)
3. Stored Vs. Derived Attributes
A. Stored (Non- Derived or Non-Computed)
It is an attribute that can‟t be derived or computed from other attribute.
It contains (stores) values that can‟t be derived or computed from other values.
Example
 Address
 Name

B. Derived
It is an attribute that can be derived or computed from other attribute.
It contains (stores) values that can be derived or computed from other values.
Example
 Age
 Length of employment
4. Null Attribute
Null attribute is an attribute which is not applicable or which do not store a value or which do not have a
value. Null attribute contains (stores) unknown value or a value that do not exist.
NB
Because attributes store values, values have also the above type.
Relationship
A relationship is a connection among things. Relationships exist in many forms.
In UML, the common types of relationships are
 Inheritance
 Dependency
 Aggregation
 Containment
 Realization
 Generalization
 Association
The notation for different form of relationship is shown as:
Common Relationship Types

A dependency is a relationship that states, that a change in specification of one thing may affect another
thing, but not necessarily the reverse. In UML, it is shown as a dashed directed line. The notation for
dependency between components and packages is shown as:
Dependency between components
A generalization is a relationship between a general thing and a specific kind of thing. It is also called “is-
a-kind-of” relationship. Inheritance may be modeled using generalization. In UML, it is shown as a solid
directed line with a large open arrow pointing to the parents.
An association is a structural relationship that specifies that the objects of one thing are connected with the
objects of another. It is a connection b/n two objects for common goal. In UML, it is shown as a solid line
connecting same or different class. The notation for association between nodes is shown as:
Association between nodes
A state encompasses all the properties of the object along with the values of each of these properties.
An instance is a concrete manifestation of an abstraction to which a set of operations can be applied and
which has a state that stores the effect of the operation.

A transition is a relationship between two states indicating that an object in the first state will perform
certain action and enter the second state when a specific event occurs and specific conditions are satisfied.
A note is a graphical symbol for rendering constraints or comments attached to an element or collection of
elements.
For object modeling some standard notations are used. Now let us discuss these basic notations. A well-
defined logical notation is important in the software development process. It helps the software architect to
clearly establish the software architecture and implement module integration. In order to define the
commonly used diagrams in UML, it is essential to understand the basic concepts of the object modeling.
Relationship in DBMS
A relationship, in the context of databases, is association between entity types. It is Set of meaningful
associations among entity types.
Any association between entity types is called a relationship. Entities take part in the relationship. It is
represented by a diamond shape.
Relationship is a situation that exists between two relational database tables when one table has a foreign
key that references the primary key of the other table. Relationships allow relational databases to split and
store data in different tables, while linking disparate data items. Relationships in Database are associations
between tables that are created using join statements to retrieve data.
For example
We have two entity types of 'Customer'(Customer_Id, Name, City, Phone) and 'Account'(Account_no,
Type, Balance).
We store the data of 'Customer' in one table and his accounts details in the 'Account' table. Now, to link
these two tables we need to insert the primary key 'Customer_id' of the 'Customer' table in the 'Account'
table. This key acts as a foreign key for the 'Account' table and refers to a column with the same name in
the 'Customer' table. This is how a relationship between two tables is established.
Representation of Relationship in Database
Relationship type is represented by a diamond shape with the relationship verb in it.
For example
A teacher teaches students. Here, "teaches" is a relationship and this is the relationship between a Teacher
entity and a Student entity.
Relationship between Teacher and Student
Teacher Student
Teaches

 Relationship has a Type and Occurrence
1. Relationship Occurrence
Occurrence = is action or process /act/ or event of happening or existing or being found in a place or under
a particular set of conditions or being present. It is condition or fact of being present
Relationship occurrence is uniquely identifiable association, which includes one occurrence from each
participating entity type.
Occurrence of Relationship in DBMS is participation.
2. Relationship Type
Type of Relationship in DBMS is Degree of a Relationship (Set of meaningful associations among entity
types.)
Degree of a Relationship is number of participating entities in relationship.
There are several types of Relationship
1. Urinary Relationship
Urinary Relationship is Relationship in which only one entity type occur in the Relationship or only one
entity type participate in the Relationship with same Relationship role.( this Relationship role may be
similar or different or they may be one or more than one)
2. Binary Relationship
Binary Relationship is Relationship in which two entity types occur in the Relationship or two entity types
participate in the Relationship with same Relationship role.( this Relationship role may be similar or
different or they may be one or more than one).
The most common degree for relationships is binary.
Binary relationships are generally referred to as being:
 One-to-one (1:1)
 One-to-many (1 :*)
 Many-to-many (* :*)
Example
Binary Relationship called POwns

3. Ternary Relationship
Ternary Relationship is Relationship in which three entity types occur in the Relationship or three entity
types participate in the Relationship with same Relationship role.( this Relationship role may be similar or
Example
Ternary Relationship called Registers
4. Quaternary Relationship
Quaternary Relationship is Relationship in which four entity types occur in the Relationship or four entity
types participate in the Relationship with same Relationship role.( this Relationship role may be similar or
Example
Quaternary Relationship called Arranges

NB
Recursive Relationship
Relationship type where same entity type participates more than once in different roles is called Recursive
Relationship
.
Relationships may be given role names to indicate purpose that each participating entity type plays in a
relationship.
Example
Recursive Relationship called Supervises with Role Names

Relationship Constraints
The main type of constraint on relationships is called multiplicity.
Multiplicities specify the number of objects that can participate in a particular association, which is a typical
consistency rule.
Multiplicity in association indicate number of objects participate in any relationship. The Multiplicity is the
constraint on the collection of the association objects.
The multiplicity is actually the constraint on cardinality and Participation. Multiplicity define Cardinality
and Participation
Multiplicity of an event = Participation of an element + cardinality of an element.
Multiplicity as Cardinality and Participation Constraint

From given example above:
1-1 ---------- 0-1
Multiplicities:
First multiplicity, for the left entity: 1-1
Second multiplicity, for the right entity: 0-1
Cardinalities for the first multiplicity:
Lower cardinality: 1
Upper cardinality: 1
Cardinalities for the second multiplicity:
Example 2
1:1 1:1
Manager between Teacher and Breach
Multiplicities: 1:1 ---------- 1:1
First multiplicity: 1:1
Cardinalities for the first multiplicity:
Second multiplicity: 1:1
Cardinalities for the second multiplicity:
Manager Breach
Manages

1. Cardinality of Relationship
Cardinality means the maximum (upper bound) and the minimum (lower bound) number of occurrence of
the specific entity in a relationship. It describes maximum number of possible relationship occurrences for
an entity participating in a given relationship type (1, 4), (1, N)...
Cardinality is the count of the objects that are in collection. Cardinality is made up of a lower and an
upper cardinality
There are three types of Cardinality that can exist between two entities.
1. One-to-One Relationship
2. One-to-Many or Many-to-One Relationship
3. Many-to-Many Relationship
1. One-to-One Relationship
Such a relationship exists when each record of one table is related to only one record of the other table.
For example
If there are two entities „Person‟ (Id, Name, Age, Address) and „Passport‟ (Passport_id, Passport_no). So,
each person can have only one passport and each passport belongs to only one person.

One-to-One relationship is not very common. However, such a relationship is used for security purposes.
In the above example, we can easily store the passport id in the „Person‟ table only. But, we make another
table for the „Passport‟ because Passport number may be sensitive data and it should be hidden from
certain users. So, by making a separate table we provide extra security that only certain database users can
see it.
2. One-to-Many or Many-to-One Relationship
One-to-Many relationship exists when each record of one table can be related to one or more than one
record of the other table. This relationship is the most common relationship found. A one-to-many
relationship can also be said as a many-to-one relationship depending upon the way we view it.
For example
If there are two entity type „Customer‟ and „Account‟ then each „Customer‟ can have more than one
„Account‟ but each „Account‟ is held by only one „Customer‟. In this example, we can say that each
Customer is associated with many Accounts. So, it is a one-to-many relationship. But, if we see it the
other way i.e. many Account is associated with one Customer then we can say that it is a many-to-one
relationship.
3. Many-to-Many Relationship
Many-to-Many relationship exists when each record of the first table can be related to one or more than
one record of the second table and a single record of the second table can be related to one or more than
one record of the first table.
A many-to-many relationship can be seen as a two one-to-many relationship which is linked by a 'linking
table' or 'associate table'. The linking table links two tables by having fields which are the primary key of
the other two tables. We can understand this with the following example.
Example
If there are two entities type „Customer‟ and „Product‟ then each customer can buy more than one product
and a product can be bought by many different customers.

Now, to understand the concept of the linking table here, we can have the „Order‟ entity as a linking table
which links the „Customer‟ and „Product‟ entity. We can break this many-to-many relationship in two
one-to-many relationships. First, each „Customer‟ can have many „Order‟ whereas each „Order‟ is related
to only one „Customer‟. Second, each „Order‟ is related only one Product where there can many orders for
the same Product.
In the above concept of linking can be understood with the help of taking into consideration all the
attributes of the entities 'Customer', 'Order' and 'Product'. We can see that the primary key of both
'Customer' and 'Product' entity are included in the linking table i.e. 'Order' table. These key act as foreign
keys while referring to the respective table from the 'Order' table.

2. Participation of Relationship
In a Relationship, Participation constraint specifies the existence of an entity when it is related to another
entity in a relationship type. It is also called minimum cardinality constraint. This constraint specifies the
number of instances of an entity that can participate in a relationship type.
It specifies the least (the smallest) number of the occurrence of the entity in a specific relationship.
It determines whether all or only some entity occurrences participate in a relationship (optional/mandatory).
Types of Participation Constraints
There are two types of participation constraints
1. Total Participation
It specifies that each entity in the entity set must compulsorily participate in at least one relationship
instance in that relationship set. That is why; it is also called as mandatory participation.
Total participation is represented using a double line between the entity set and relationship set.
Example

2. Partial Participation
It specifies that each entity in the entity set may or may not participate in the relationship instance of the
relationship set. It is also called as optional participation.
Partial Participation exists when all the entity of an entity type is not associated with one or the other entity
of another entity type. This is represented by joining the relationship with the entity type with the help of
one line.
It is represented using a single line between the entity set and relationship set in the ER diagram.
Example of partial participation
A single line between the entities i.e. courses and enrolled in a relationship signifies the partial participation,
which means there might be some courses where enrollments are not made i.e. enrollments are optional in
that case.
Key constraints
What is key?
Key is an attribute or set of attributes that is used to identify a tuple within a relation.
If tuples are need to be unique in the database, and then we need to make each tuple distinct. To do this we
need to have relational keys that uniquely identify each relation.

Super Key: an attribute or set of attributes that uniquely identifies a tuple within a relation.
Candidate Key: a super key such that no proper subset of that collection is a Super Key within the relation.
A candidate key has two properties:
1. Uniqueness
2. Irreducibility
If a super key is having only one attribute, it is automatically a Candidate key.
If a candidate key consists of more than one attribute it is called Composite Key.
Primary Key: the candidate key that is selected to identify tuples uniquely within the relation.
The entire set of attributes in a relation can be considered as a primary case in a worst case.
Foreign Key: an attribute, or set of attributes, within one relation that matches the candidate key of some
relation.
A foreign key is a link between different relations to create the view or the unnamed relation

Physical Database Requirements.pdf

More Related Content

Similar to Physical Database Requirements.pdf

Recently uploaded

Physical Database Requirements.pdf