Professional Documents
Culture Documents
Identify Physical Database Requirements
Identify Physical Database Requirements
Under
ETHIOPIAN TVET-SYSTEM
DATABASE ADMINISTRATION
LEVEL III
LEARNING GUIDE # 02
Unit of Competence: Identify Physical Database Requirements
LEARNING OUTCOME:
LO1: Identify database scope
User Requirements.............................................................................................................................. 2
1.4 Evaluating Several database management systems and making appropriate selection ........... 11
A database is a collection of information related to a particular subject or purpose (e.g., tracking customer
orders or maintaining a music collection). If your database isn't stored on a computer, or only parts of it are,
you may be tracking information from a variety of sources that you have to coordinate and organize yourself.
Database design is the process of coming up with different kinds of specification for the data to be stored in
the database. Design is the part on which we would be engaged to describe how the data should be perceived
at different levels and finally how it is going to be stored in a computer system. Database design classified
into: -
1. Conceptual Design
2. Logical Design
It is a process of constructing a model of the information used in an enterprise based on a specific data
model (e.g relational hierarchy or network or project).
3. Physical Design
It is the process of producing a description of the implementation of the database on secondary storage.
Defines specific storage or access methods used by database
- The purpose of defining the scope is to define the boundary of the system and the project.
- The scope shows what aspects of the system will and will not be included in the project.
One can use ERDs (Entity-Relationship Diagrams) or EERDs (Enhanced-Entity Relationship Diagrams) in order
to make a good database.
User Requirements
From the model of system components in our generic system, the user component is at the highest layer. The
term user represents primarily the end users of the system, but it can be expanded to include everyone involved
in the system, such as network and system administrators and management. User requirements is the set of
requirements gathered or derived from user input and is what is needed by users to successfully accomplish
their tasks on the system. Typically, when gathering requirements, everyone involved with that network is
considered a potential user. Figure 2.2 shows some example user requirements.
We begin describing requirements at this layer, which will lead to the development of more specific
requirements as we work through each of the components.
From the user perspective, we can ask, "What does it take to get the job done?" This will usually result in a
set of qualitative, not quantitative, requirements. Part of our job in gathering and deriving user requirements
is to make them quantitative whenever possible.
System Architectures
System architecture encompasses decisions as to where to place specific software components. Should certain
components be placed on the same server or on different machines? Enterprises may have a specific high-
speed processing server or high-end reliable storage facility that they’ll want to leverage for specific
components. These decisions will lead to different types of architectural organizations. We can broadly
categorize them into centralized and decentralized organizations.
A server is a process implementing a specific service (e.g. database service). The client is a process requesting
that service from a server. The client sends the request and waits for the reply (request-reply behavior). Where
these processes are physically distributed will lead to different multitiered architectural styles.
Remember the three layers discussed above (interface, processing, data layer)? While we distinguish between
three logical levels, there are several ways to physically distribute a client-server application across machines.
The simplest organization is using two types of machines: 1) a client machine with the user interface (layer
one), and 2) the server interface containing the program implementing the process and the data (layers two
and three). In this case, everything is handled by the server while the client is nothing more than a dumb
terminal. This is called a (physically) two-tiered architecture. However, there are other ways to separate
these three layers on two machines. Possibilities range between separation, as mentioned above, to having
everything, except the stored data, running on the client machine. You can see these different variations in the
graphic below.
In (physically) three-tiered architectures, one of the servers also has to act as a client. The application is
spread across three machines, one client and two servers. One of the servers may need input from the other
server to process the client request, acting as a client.
Figure 3: Three-tier architecture: one client and two servers with the app server also acting as a client.
Multitiered client-server architectures are a direct consequence of dividing distributed applications into a user
interface, processing components, and data-management components. Different tiers correspond directly with
the logical organization of applications (software architecture corresponds to system architecture). This is
called vertical distribution in which logically different components are placed on different machines. This
allows for each machine to be tailored to a specific function, for example, placing the processing layer on a
high-end processing server.
In modern architectures, clients and servers themselves are distributed, in so-called horizontal distribution.
A client or server may be physically split, but each part operates on its own share of complete data thus
balancing the load. So, instead of having one data store all components have access to, potentially turning into
a bottleneck, each component has its own dataset. These are called peer-to-peer systems. Each process acts
as client and server at the same time, often referred to as servant.
Peer-to-peer architectures evolve around the question of how to organize processes in an overlay network —
a network in which nodes are formed by processes and links represent possible communication channels.
As we’ve seen, there are multiple ways of organizing applications into logical components (software
architecture considerations). Whether layered, object/service-oriented, REST, or pub/subscribe is the best
approach largely depends on the application. These components are then placed on different physical
machines (system architecture considerations), either in a client-server or peer-to-peer fashion.
Characteristics
Traditionally data was organized in file formats. DBMS was all new concepts then and all the research was done
to make it to overcome all the deficiencies in traditional style of data management. Modern DBMS has the
following characteristics:
✓ Real-world entity: Modern DBMS are more realistic and uses real world entities to design its architecture.
It uses the behavior and attributes too. For example, a school database may use student as entity and their
age as their attribute.
✓ Relation-based tables: DBMS allows entities and relations among them to form as tables. This eases the
concept of data saving. A user can understand the architecture of database just by looking at table names
etc.
✓ Isolation of data and application: A database system is entirely different than its data. Where database is
said to active entity, data is said to be passive one on which the database works and organizes. DBMS also
stores metadata which is data about data, to ease its own process.
✓ Less redundancy: DBMS follows rules of normalization, which splits a relation when any of its attributes
is having redundancy in values. Following normalization, which itself is a mathematically rich and
scientific process, make the entire database to contain as less redundancy as possible.
✓ Consistency: DBMS always enjoy the state on consistency where the previous form of data storing
applications like file processing does not guarantee this. Consistency is a state where every relation in
database remains consistent. There exist methods and techniques, which can detect attempt of leaving
database in inconsistent state.
✓ Query Language: DBMS is equipped with query language, which makes it more efficient to retrieve and
manipulate data. A user can apply as many and different filtering options, as he or she wants. Traditionally
it was not possible where file-processing system was used.
✓ ACID Properties: DBMS follows the concepts for ACID properties, which stands for Atomicity,
Consistency, Isolation and Durability. These concepts are applied on transactions, which manipulate data
DBMS is used by various users for various purposes. Some may involve in retrieving data and some may
involve in backing it up. Some of them are described as follows:
• MySQL
• Oracle
• PostgreSQL
• dBASE
• FoxPro
• SQLite
• IBM DB2
• LibreOffice Base
• MariaDB
• Microsoft SQL Server etc.
Types of DBMS
• Hierarchical database
• Network database
• Relational database
• Object-Oriented database
Hierarchical DBMS
In a Hierarchical database, model data is organized in a tree-like structure. Data is Stored Hierarchically (top
down or bottom up) format. Data is represented using a parent-child relationship. In Hierarchical DBMS
parent may have many children, but children have only one parent.
Network Model
The network database model allows each child to have multiple parents. It helps you to address the need to
model more complex relationships like as the orders/parts many-to-many relationship. In this model, entities
are organized in a graph which can be accessed through several paths.
Relational model
Relational DBMS is the most widely used DBMS model because it is one of the easiest. This model is based
on normalizing data in the rows and columns of the tables. Relational model stored in fixed structures and
manipulated using SQL.
Object-Oriented Model
In Object-oriented Model data stored in the form of objects. The structure which is called classes which
display data within it. It defines a database as a collection of objects which stores both data members values
and operations.
Disadvantage of DBMS
• Cost of Hardware and Software of a DBMS is quite high which increases the budget of your organization.
• Most database management systems are often complex systems, so the training for users to use the DBMS
is required.
• In some organizations, all data is integrated into a single database which can be damaged because of
electric failure or database is corrupted on the storage media
• Use of the same program at a time by many users sometimes lead to the loss of some data.
• DBMS can't perform sophisticated calculations
- You can specify sizes for data and log file in the definition of a database.
- File Growth: You can specify whether a file will grow in size in the future if necessary.
Example: - Specifying memory size during database Creation
When you design a database, you may have to estimate how large the database will be when filled with data.
Estimating the size of the database can help you determine the hardware configuration you will require to do
the following:
• Achieve the performance required by your applications.
• Guarantee the appropriate physical amount of disk space required to store the data and indexes.
Estimating the size of a database can also help you determine whether the database design needs refining.
1.3 Documenting Database and scope of project
Documenting a database means collecting and analyzing information about the organization to be supported by
the database system, and use this information to identify the requirements for the new database system.
- Before attempting to design a database system, you must first identify the scope and boundary of the
project.
- When defining the system boundary for a database system, we include not only the current user views but
also any known future user views.
1.4 Evaluating Several database management systems and making appropriate selection
Evaluating DBMS software means comparing DBMSs software one from the other to select the appropriate one.
The selection must be based on its feature to create a database, disk space it needs, its strength, its flexibility and
cost.
Qualitative and quantitative analysis of different database management systems (DBMS) have been performed in
order to identify and compare those which address requirements such as public domain licensing, free of charge,
high product support, .NET Entity Framework compatibility, good performance, referential integrity, among
others.
➢ Examples for quantitative analysis; .NET Entity Framework compatibility, cost, license, etc.
➢ Examples for qualitative analysis; good performance, referential integrity, and others.
The various types of database software come with advantages, limitations and optimal uses that prospective
buyers should be aware of before choosing a DBMS.
An entity is an object in the real world with an independent existence that can be differentiated from other
objects. An entity might be
Entities can be classified based on their strength. An entity is considered weak if its tables are existence
dependent.
An entity is considered strong if it can exist apart from all of its related entities.
In E-R Diagram, an entity type is represented by a rectangle, and the name is indicated in capital letters.
Example: - a company have many employees, and these employees are defined as entities (e1,e2,e3....) and all
these entities having same attributes are defined under ENTITY TYPE employee.
▪ Entity Instance is a single occurrence of a particular entity type. An entity type is described just one time in
the data model, but many instances of that entity type may be represented by data stored in the database.
Example: - There may be hundreds or thousands of employees in an organization – each one is an instance of the
Employee entity type.
An entity’s existence isendependent on the existence of the related entity. It is existence-dependent if it has a
mandatory foreign key (i.e., a foreign key attribute that cannot be null). For example, in the COMPANY
database, a Spouse entity is existence -dependent on the Employee entity.
Kinds of Entities
You should also be familiar with different kinds of entities including independent entities, dependent entities
and characteristic entities. These are described below.
Independent entities
Independent entities, also referred to as kernels, are the backbone of the database. They are what other tables
are based on. Kernels have the following characteristics:
If we refer back to our COMPANY database, examples of an independent entity include the Customer table,
Employee table or Product table.
Dependent entities, also referred to as derived entities, depend on other tables for their meaning. These entities
have the following characteristics:
Characteristic entities
Characteristic entities provide more information about another table. These entities have the following
characteristics:
Relationships are the glue that holds the tables together. They are used to connect related information between
tables.
Relationship strength is based on how the primary key of a related entity is defined. A weak, or non-
identifying, relationship exists if the primary key of the related entity does not contain a primary key
component of the parent entity. Company database examples include:
• Customer(CustID, CustName)
• Order(OrderID, CustID, Date)
A strong, or identifying, relationship exists when the primary key of the related entity contains the primary
key component of the parent entity. Examples include:
Types of Relationships
A one to many (1:M) relationship should be the norm in any relational database design and is found in all
relational database environments. For example, one department has many employees. Figure 8.7 shows the
relationship of one of these employees to the department.
Above, tables with data about customers and orders that have a one-to-many relationship
In a one-to-many relationship, the table on the one side of the relationship is the primary table and the table on
the many side is the related table.
A one-to-many relationship is the most common relationship found between tables in a relational database. The
following is an example of a form used in a database to display the data from two tables with a one-to-many
relationship.
A one to one (1:1) relationship is the relationship of one entity to only one other entity, and vice versa. It
should be rare in any relational database design. In fact, it could indicate that two entities actually belong in
the same table.
An example from the COMPANY database is one employee is associated with one spouse, and one spouse is
associated with one employee.
PERSONAL
EmployeeID FirstName LastName Address City State Zip
EN1-10 Carol Schaaf 2306 Palisade Ave. Union City NJ 07087
EN1-12 Gayle Murray 1855 Broadway New York NY 12390
EN1-15 Steve Baranco 742 Forrest St. Kearny NJ 07032
EN1-16 Kristine Racich 416 Bloomfield St. Hoboken NJ 07030
EN1-19 Barbara Zumbo 24 Central Ave. Ritchfield Park NJ 07660
EN1-20 Daniel Gordon 2 Angelique St. Weehawken NJ 07087
EN1-22 Jacqueline Rivet 3600 Bergeline Ave. Union City NJ 07087
EN1-23 Betsy Rosyln 1800 Boulevard East Weehawken NJ 07086
EN1-25 Will Strick 2100 91st St. North Bergen NJ 07047
EN1-26 Susan Shipe 240 Fifth Ave. New York NY 10018
PAYROLL
EmployeeID PayRate
EN1-10 $25.00
EN1-12 $27.50
EN1-15 $20.00
EN1-16 $19.00
EN1-19 $22.75
EN1-20 $23.00
EN1-22 $22.50
EN1-23 $19.50
EN1-25 $12.50
EN1-26 $14.00
Above, tables with a one-to-one relationship from a database of
information about employees
In a one-to-one relationship, either table can be considered to be the primary or parent table.
Figure 3 shows another another aspect of the M:N relationship where an employee has different start dates
for different projects. Therefore, we need a JOIN table that contains the EID, Code and StartDate.
Figure 3. Example where employee has different start dates for different projects.
~20~ Prepared By: Masresha T…
Examine the sample data below. These tables hold data about employees and the projects to which they are
assigned. Each project can involve more than one employee and each employee can be working on more than one
project (the "do more with less" thing). This constitutes a many-to-many (N:N) relationship.
EMPLOYEES
Degree of a relationship
The number of entities participating in a relationship is called the degree of the relationship.
A unary relationship, also called recursive, is one in which a relationship exists between occurrences of the
same entity set. In this relationship, the primary and foreign keys are the same, but they represent two entities
with different roles. See Figure 8.9 for an example.
For some entities in a unary relationship, a separate column can be created that refers to the primary key of
the same entity set.
Ternary Relationships
A ternary relationship is a relationship type that involves many to many relationships between three tables.
Refer to Figure 5 for an example of mapping a ternary relationship type. Note n-ary means multiple tables in
a relationship. (Remember, N = many.)
• For each n-ary (> 2) relationship, create a new relation to represent the relationship.
• The primary key of the new relation is a combination of the primary keys of the participating entities that
hold the N (many) side.
• In most cases of an n-ary relationship, all the participating entities hold a many side.
A data dictionary is a collection of descriptions of the data objects or items in a data model for the benefit
of programmers and others who need to refer to them.
* In DBMS, a data dictionary is a file that defines the basic organization of a database.
* Most DBMS keep the data dictionary hidden from users to prevent them from accidentally destroying its
contents.
* A data dictionary may contain:
- The definitions of all schema objects in the database (tables, views, indexes, procedures, functions,
triggers, and so on). Example: Name of the tables, field names of each table, Data type of each field,
Length of each field, constraints of each table and field, etc.
• How much space has been allocated for, and is currently used by the schema objects
- Default values for columns (Constraints on data i.e. range of values permitted)
• Integrity constraint information (Constraints that apply to each field, if any)
• Auditing information, such as who has accessed or updated various schema objects
• Privileges and roles each user has been granted (Access Authorization)
- Description of database users, their responsibilities and their access rights.
Simple Example of data dictionary
Pname Char 17
Dname Char 20
Data dictionaries do not contain any actual data from the database, only book keeping information for managing
it.
When a new user is introduced to the system or a new administrator takes over the system, identifying table
structures and types becomes simpler.
➢ Table attributes
Attributes
Each entity is described by a set of attributes (e.g., Employee = (Name, Address, Birthdate (Age), Salary).
Each attribute has a name, and is associated with an entity and a domain of legal values. However, the
information about attribute domain is not presented on the ERD.
- It can also be represented by listing them within the entity rectangle, under the entity name.
Example: EMPLOYEE
Emp_Id
Fname
Lname
*
In the entity relationship diagram, shown in Figure 6, each attribute is represented by an oval with a name
inside. *
Types of Attributes
There are a few types of attributes you need to be familiar with. Some of these are to be left as is, but some
need to be adjusted to facilitate representation in the relational model. This first section will discuss the types
of attributes. Later on we will discuss fixing the attributes to fit correctly into the relational model.
Simple attributes are those drawn from the atomic value domains; they are also called single-valued
attributes. In the COMPANY database, an example of this would be: Name = {John} ; Age = {23}
Composite attributes are those that consist of a hierarchy of attributes. Using our database example, and
shown in Figure 8.3, Address may consist of Number, Street and Suburb. So this would be written as →
Address = {59 + ‘Meek Street’ + ‘Kingsford’}
. The value of composite attribute is the concatenation of the values of its constituent simple attributes.
Multivalued attributes are attributes that have a set of values for each entity. Have more than one value.
Example: colour attribute for a car, college degree for a person, address.
-- Age attribute is derived attribute, and the Birth-Date attribute is stored attributed
• No data entry
• Not permitted in the primary key
• Should be avoided in other attributes
• Can represent
o An unknown attribute value
o A known, but missing, attribute value
o A “not applicable” condition
• Can create problems when functions such as COUNT, AVERAGE and SUM are used
• Can create logical problems when relational tables are linked
Keys
An important constraint on an entity is the key. The key is an attribute or a group of attributes whose values
can be used to uniquely identify an individual entity in an entity set.
Types of Keys
From our COMPANY database example, if the entity is Employee(EID, First Name, Last Name, SIN,
Address, Phone, BirthDate, Salary, DepartmentID), possible candidate keys are:
• EID, SIN
• First Name and Last Name – assuming there is no one else in the company with the same name
• Last Name and DepartmentID – assuming two people with the same last name don’t work in the same
department
Composite key
Using the example from the candidate key section, possible composite keys are:
• First Name and Last Name – assuming there is no one else in the company with the same name
• Last Name and Department ID – assuming two people with the same last name don’t work in the same
department
Primary key
The primary key is a candidate key that is selected by the database designer to be used as an identifying
mechanism for the whole entity set. It must uniquely identify tuples in a table and not be null. The primary
key is indicated in the ER model by underlining the attribute.
• A candidate key is selected by the designer to uniquely identify tuples in a table. It must not be null.
• A key is chosen by the database designer to be used as an identifying mechanism for the whole entity
set. This is referred to as the primary key. This key is indicated by underlining the attribute in the ER
model.
Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)
Secondary key
A secondary key is an attribute used strictly for retrieval purposes (can be composite), for example: Phone
and Last Name.
Alternate key
Alternate keys are all candidate keys not chosen as the primary key.
Foreign key
A foreign key (FK) is an attribute in a table that references the primary key in another table OR it can be null.
Both foreign and primary keys must be of the same data type.
Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)
Database reports are the formatted result of database queries and contain useful data for decision-making and
analysis. Most good business applications contain a built-in reporting tool; this is simply a front-end interface that
calls or runs back-end database queries that are formatted for easy application usage.
For example, a banking software application may contain specifically defined reports on all customers with large
deposits or reports on monthly loan summaries for all customers.
The reports are normally used to provide hard copy printouts for reviews at meetings or to mark up the information
in your database that needs updating.
System security means Control of access to a computer system's resources, specially its data and operating system
files.
- It covers access and use of the database at the system level, such as a username and password.
DB security
Data is a valuable entity that must have to be firmly handled and managed as with any economic
resource. So some part or all of the commercial data may have tactical importance to their
respective organization and hence must have to be kept protected and confidential. In this chapter,
you will learn about the scope of database security. There is a range of computer-based controls
that are offered as countermeasures to these threats.
Database security is the technique that protects and secures the database against intentional or
accidental threats. Security concerns will be relevant not only to the data resides in an
organization's database: the breaking of security may harm other parts of the system, which
may ultimately affect the database structure. Consequently, database security includes
hardware parts, software parts, human resources, and data. To efficiently do the uses of security
needs appropriate controls, which are distinct in a specific mission and purpose for the system.
The requirement for getting proper security while often having been neglected or overlooked
in the past days; is now more and more thoroughly checked by the different organizations.
These listed circumstances mostly signify the areas in which the organization should focus on
reducing the risk that is the chance of incurring loss or damage to data within a database. In
some conditions, these areas are directly related such that an activity that leads to a loss in one
area may also lead to a loss in another since all of the data within an organization are
interconnected.
What is a Threat?
Any situation or event, whether intentionally or incidentally, can cause damage, which can
reflect an adverse effect on the database structure and, consequently, the organization. A threat
may occur by a situation or event involving a person or the action or situations that are probably
to bring harm to an organization and its database.
The degree that an organization undergoes as a result of a threat's following which depends
upon some aspects, such as the existence of countermeasures and contingency plans. Let us
take an example where you have a hardware failure that occurs corrupting secondary storage;
all processing activity must cease until the problem is resolved.
Computer-Based Controls
The different forms of countermeasure to threats on computer systems range from physical
controls to managerial procedures. In spite of the range of computer-based controls that are
preexisting, it is worth noting that, usually, the security of a DBMS is merely as good as that
of the operating system, due to the close association among them.
• Access authorization.
• Access controls.
• Views.
• Backup and recovery of data.
• Data integrity.
• Encryption of data.
• RAID technology.
The usual way of supplying access controls to a database system is dependent on the granting
and revoking of privileges within the database. A privilege allows a user to create or access
some database object or to run some specific DBMS utilities. Privileges are granted users to
achieve the tasks required for those jobs.
3.3 Identifying, evaluating and recording DB performance recovery and audit trails.
What is auditing?
Auditing is the monitoring and recording of selected user database actions.
Database performance can be defined as the optimization of resource use to increase throughput
and minimize contention, enabling the largest possible workload to be processed.
Database Recovery is responsible for preserving the database consistency after a failure of any
kind (transaction, system or media). Relevant information solely for recovery is saved in a log
during normal transaction processing.
Recovery performance focuses primarily on crash recovery rather than on recovery after
restoring a backup. However, optimizations are possible for recovery after restoring from a
backup.
An audit trail (or audit log) is a record showing who has accessed a computer system and
what operations he or she has performed during a given period of time. Audit trails are useful
both for maintaining security and for recovering lost transactions.
Most accounting systems and database management systems include an audit trail component.
In addition, there are separate audit trail software products that enable network administrators
to monitor use of network resources.
What is feedback?
Feedback is a Process in which the effect or output of an action is 'returned' to modify the next
action.
There are two main approaches to improving the effectiveness of database interfaces. One is to
raise the level of abstraction for the content of the user-database interaction. The relational model
belonging to the logical level has replaced the hierarchical and network models that belong to the
lower physical level. It is likely that the relational model will eventually be replaced by models
belonging to the even higher conceptual level, such as entity relationship models and object-
oriented models. The second approach is to enhance the actual interaction process. This can be
done by providing better feedback to the user. Feedback can be in the form of more comprehensible
error messages, and the provision of a natural language interpretation of user's query. Such a
feedback system was developed, and its effectiveness tested in an experiment. The results showed
that the feedback system enhanced user performance greatly. Specifically, users who used the
feedback system were 12.9% more accurate than those without the feedback system. They were
also 41.2% more confident of their answers, and they took 29.0% less time than those without the
feedback system
This may sound obvious, but it is vital that you actually analyse all the feedback you get –
otherwise why bother collecting it in the first place!
Whilst some feedback may give fairly standard or unremarkable details (which will also be useful
– see the section below on trends), some may contain information that could potentially be a major
breakthrough for your business.
You will find rapidly that feedback will start to fall into more general categories – these could
include the speed of your service (or lack of), accuracy, courtesy and helpfulness of particular
staff, price and choice of products, availability or location etc.
Sorting feedback into categories will immediately help to show a wider picture of how the
customer views your business and services. Of course some customers may comment on a number
of categories and you can file these accordingly.
You will probably find that sub-categories are also very useful. This will help to highlight the less
noticeable elements of your business operations, which could actually prove to be very significant
to your overall proposition. Often these ‘hidden’ elements are the ones that are significantly
pleasing or annoying your customers and website visitors.
Inevitably feedback will range from complaints to (hopefully) high praise! It makes sense to divide
the results using these criteria, as your response to each will vary greatly. It is worth pointing out
~38~ Prepared By: Masresha T…
at this juncture that positive comments are just as valuable as complaints because they show you
what pleases and excites your repeat customers. Compliments will also motivate your team and
thanking customers for positive feedback helps to build customer loyalty.
In a similar way, negative comments will highlight why customers leave and go to your
competitors. You need to close the loop and resolve these problems – this is a well proven way of
retaining more business. In both cases, your business will improve and thrive by reacting positively
to feedback.
Start delivering email messages your audience craves with Mopinion for Email.
Naturally you need to understand what is driving customer loyalty if you want to improve it and
customer feedback will help you to do this. Therefore, it is useful to make the analysis of root
causes a priority above settling more complex or niche problems reported by your customers.
To achieve this, it is vital to have a management system in place which will qualify feedback and
help you search through potentially large amounts of data. You also need to be able to determine
the data which will help identify root causes of issues, before you move onto more complex (and
sometimes niche) problems that will result from these.
All customers are valuable to your business, but some are more valuable than others! It is important
to understand the value of a customer/group of customers so you can prioritise changes to your
sales funnel or customer management regime.
This also applies to making a business case for internal changes. For example, if you want to invest
in schemes designed to drive up customer loyalty you need to be aware of how much this will be
worth to your business compared to the cost of implementing it (investment cost Vs return on
investment) to ensure it is worthwhile.
Of all the criteria you use to analyse customer feedback, identifying trends is one of the most
important. Trends will show where you are getting things right or wrong and will become even
more important when your volume of feedback increases.
Looking at individual feedback, you might find particularly strong opinions or complaints.
However, these need to be seen in the context of your overall sales. For example, one customer
may have a terrible experience with a product you have sold them, but then the rest of the
customers who have bought the same item may give a glowing review.
Looking at longer term trends can also help to ascertain if you have a statistical aberration or a
genuine trend that needs to be addressed. If a trend rises or decreases on a regular basis you can
be fairly certain this is an important factor that will need to be focussed upon – be that a negative
or a positive.
You may have an urge to compare different geographies, completely separate parts of the business
or different survey results – but this can be very misleading. Taking results out of context (even if
they may seem related) can offer a very distorted view.
For example, customers in different regions or countries can be notoriously different to those in
other parts of the world (through cultural or lifestyle difference etc.) Some markets may be stronger
than others, which can be for a number of different reasons and not necessarily down to the quality
or availability of your products or services. Each sector or region needs to be seen in its wider
complex and the feedback data considered with this in mind.
With all the insights from your collected feedback it is important to ensure everyone involved with
customer service and support is aware of the results.
Be it pricing issues, quality of products, logistical issues or website problems – the appropriate
managers need to be made aware so they can carry out the right actions (even if this is to continue
doing the right things!) Equally, customer-facing teams will be well-informed to help potentially
frustrated customer with known queries.
Once you have sorted through and understand the feedback results it is time to put together a
feasible and effective plan of action to address any issues.
You also need to ensure that the parts of your service which work well and have had positive
feedback continue to do this going forward. When you are addressing issues it can be easy to
disrupt the parts of the process that work well, so you need to be aware of this.
Hopefully your feedback process will prove to be popular with your customers and generate a high
volume of results. This is a ‘nice problem’ to have, but you might consider using specialised and
automated tools to help you make sense of it, such as text and sentiment analysis. This will identify
which words are used most and in which combinations, along with whether feedback is positive,
neutral or negative.
Automatic learning systems are the next step for analysing feedback. These use machine learning
to automatically assign feedback to the right category and ascertain which feedback is useful,
depending on your chosen criteria. This offers a truly powerful and accurate way of assessing
feedback, yet reduces the hours required by your team to do so.