this is a report on dental treatment & management system which provides web application base dental treatment services for dental patients through internet. people get treatment remotely from all over the world.

1. 1 | P a g e
Acknowledgement
To begin with, I desire to show gratitude to Almighty Allah the kind, the sympathetic who has
rewarded me with bestowing skill, intellect and self-reliance to complete this project paper.
I humbly wish to express my cordial thankfulness to my group mates for their assistance, ideas
and constant inspiration during the project.
I also acknowledge all of my seniors because without their direction and backing it would be hard
challenge to finish the project.

2. 2 | P a g e
TABLE OF CONTENTS
Chapter Title Page
Table of Contents 4
List of Figures 6
List of Tables 7
1 Introduction and Motivation 8
1.1 Introduction 8
1.2 Background 8
1.3 Objectives of the Project 9
2 Literature Review 10
2.1 Data 10
2.2 Database 10
2.3 Database Management System (DBMS) 10
2.4 Data Model 10
2.5 View of data 10
2.6 Instances and schemas 10
2.7 Database Language 11
2.8 Data Definition Language (DDL) 11
2.9 Data-Manipulating Language (DML) 11
2.10 Database Administrator 11
2.11 Database User 11
2.12 Overall System structure 11
2.13 Entity Relationship Model 13

3. 3 | P a g e
2.13.1 Attribute 13
2.13.2 Entity 13
2.13.3 Weak Entity Set 13
2.14 Mapping constraints 13
2.15 Key 13
2.15.1 Primary Key 14
2.15.2 Foreign Key 14
2.15.3 Compound key 15
2.16 Mapping Cardinality 15
2.17 Reduction of an E-R schema to Table 17
3 System Analysis and Design 18
3.1 Information Collection 18
3.2 Analysis 18
3.2.1 The Entity Relationship (E-R) Model 19
3.2.2 Entity Relationship Diagram (ERD) 20
3.3 System Design 21
3.4 Design Procedure 22
3.5 Performances and Efficiency 23
3.6 APIs, Application Module, Software and Database Technology
Requirements
23
4 Conclusion and Recommendations 25
4.1 Conclusion 25
4.2 Limitations 25
4.3 Future plan 25

4. 4 | P a g e
LIST OF FIGURES
Figure No. Name of Figures Page
2.1 Primary Key Indication in Table “tbl_patient” 14
2.2 Foreign Key Indication in Table “tbl_patient” and “tbl_payment” 14
2.3 Compound Key Indication in Table “tbl_payment” 15
2.4 One to One Mapping Cardinality 15
2.5 One to Many Mapping Cardinality 16
2.6 Many to One Mapping Cardinality 16
2.7 Many to Many Mapping Cardinality 17
3.1 Entity Relationship (E-R) model 19
3.2 Entity Relationship Diagram 20
3.3 Overall Steps in System Design 21

5. 5 | P a g e
LIST OF TABLES
Figure No. Name of Tables Page
1.1 Table of Required Software, Database, API’s and Application
Module
24

6. 6 | P a g e
Chapter I
Introduction and Motivation
1.1 Introduction
Nowadays, dentists are forced to balance between providing the best patient care and staying
profitable and efficient. Recent changes in the dental industry and patient expectations have
created a competitive market and introduced new challenges dentists never had to deal with in the
past.
What was acceptable ten years ago is no longer tolerated by patients. Long gone are the days when
patients accepted average level of service. Long gone are the days when dentists were booked
weeks in advance. Market research indicated that patients not only demand excellent dental care,
they also demand for a modern hassle free environment, zero wait time, automatic email reminder,
web access to their billing information, e-prescriptions, patient’s medicine records, patient’s
treatment plans, and reasonable prices also.
The ability to keep patient’s health record online, patient’s specific problem and habit history,
create and manage a dental treatment plan, prepare paperless e-prescription, graphical and visual
report generation, medical test record keeping facility and billing information are very important
features in today’s dental software packages. Paperless planning the patients’ objectives of long-
term treatments is not only convenient but also is easy to follow through completion. In addition,
being able to share each dental treatment plan with all the associated specialists makes the health
goals of each patient much easier to reach.
“Dental Treatment and Management Application” is a web application that is based on database
management scheme. Our objective is to design and implement such a system which is more user
friendly and which allows all types of activities related to dental treatment to perform easily and
efficiently using this management system for modern dentists.
1.2 Background
In most of the dental care point or chamber, a dentist needs to be in the chamber at a workstation
to access patient’s files and data. On the other hand, they habituated with paper-based treatment
and prescription system. All kinds of information related to patient general information, patient’s
habit related to brushing teeth, patient’s specific and other problems that can affect their dent,
treatment plan, medical examination details, billing information, next visiting appointment etc. are

7. 7 | P a g e
stored in prescription or a register book manually. It is very time consuming and very slow. So if
we make it web based automated and computerized, then it will be very fast, efficient and patient
can be prescribed from distant area over smart phone. In the manual record keeping and
prescription method, the assistant or compounder has to write down all types of general health and
dent related information of patient after then the dentist starts the treatment. In this case there is
often possibility to make error and there might be a possibility to lost the prescription from the
patient. Whereas our web based “Dental Treatment and Management Application” ensures the
paperless dental care point and patient data also can be easily retrieved from anywhere.
1.3 Objectives of the Project
Our Objective is to develop a web-based Dental Treatment and Management Application for
dentist that will cover patient management, billing, e-prescription, visual presentation of reports.
Specific objectives of this Application are:
1. To develop a system that can maintain a large amount of patient’s general information
and treatment plan.
2. Provide security and ensure reliability through user access privilege.
3. Easy to use and meet with the requirement.
4. Automatically report generation and visual presentation that will help a dental
practitioner to predict and analyze patient’s problem and the medication.
5. To develop a complete real time and dynamic application that can access without any
barrier of geographic location. (i.e. Dentist can serve a patient from anywhere of the
world as patient’s data stored as cloud environment).

8. 8 | P a g e
Chapter II
Literature Review
2.1 Data
A data is nothing but the collection of facts. A major purpose of a database management system is
to provide users with an abstract view of data.
2.2 Database
The collection of data usually refers to as the database. It consists information about one particular
enterprise.
2.3 Database Management System (DBMS)
A database management system consists of a collection of interrelated data and a set of programs
to access the data. The collection of data usually referred to as database contains information about
the enterprise. The primary goal of a database management system is to provide an environment
that is both convenient an efficient to use in retrieving and storing database information.
2.4 Data Model
Underlying the structure of a database is the data model: a collection of conceptual tools for
describing data, data relationship, data semantics and consistency constrains. To illustrate the
concept of a data model we outline two data models.
2.5 View of data
A database system is collection of interrelated files and asset of programs that allow users to access
and modify these files. A major purpose of a database system is to provide users with an abstract
view of the data. That is, the system certain details of how the data are stored and maintained.
2.6 Instances and schemas
Databases change over time as information is inserted and deleted. The collection of information
stored in the database at a particular moment is called an instance of the database. The overall
design of the database is called the database schema. Schemas are change infrequently, if at all.
The concept of database schemas and instances can be understood by analogy to a program written
in a programming language. a database schema corresponds to the variable declarations (along
with associated type definitions) in a program. Each variable has a particular value at a given

9. 9 | P a g e
instant. The values of the variables in a program at a point in time correspond to an instance of a
database schema.
Database systems have several schemas, partitioned according to the levels of abstraction. The
physical schema describes the database design at the logical level. A database may also have
several schemas at the view level, sometimes called subschema’s, that describe different views of
the database.
Of these, the logical schema is by far the most important, in terms of its effect on application
programs since programmer’s construct applications by using the logical schema. The physical
schema is hidden beneath the logical schema and can usually be changed easily without affecting
application programs. Application programs are said to exhibit physical data independence if they
do not depend on the physical schema, and thus need not be rewritten if the physical schema
changes.
2.7 Database Language
A database system provides a knowledge definition language to specify the database schema and
data manipulation language to specific queries and updates. In practice, the information
definition and data manipulation language do not seem to be separate language, instead the
simplify form parts of single database language, like the widely use SQL language.
2.8 Data Definition Language (DDL)
We specify a database schema by a set of definitions expressed by a special language called data
definition language. For instance, the following statement in the SQL language defines the
tbl_patient table:
CREATE TABLE `tbl_patient` (
`id` int(11) NOT NULL,
`patient_name` varchar(255) NOT NULL,
`patient_age` varchar(20) NOT NULL,
`patient_addrs` varchar(255) NOT NULL,
`patient_occup` varchar(255) NOT NULL,
`patient_mobile` varchar(20) NOT NULL,
`pFather_child` varchar(255) NOT NULL,
`reg_date` date NOT NULL
);

10. 10 | P a g e
Execution of the above DDL statement creates the tbl_patient table. In addition, it updates special
set of tables called a data dictionary or data directory.
2.9 Data-Manipulating Language (DML)
Data manipulation is:
 Retrieval of information stored in the database.
 Insertion of new information to the database.
 Deletion of information to the database.
 Modification of information to the database.
A data manipulating language is a language that enables users to access or manipulate data as
organized by the appropriate data model. For instance, the following statement in the SQL
language defines the “tbl_treatmentplan” table:
[ SELECT * FROM `tbl_treatmentplan` ORDER BY `tplan_name` DESC ]
2.10 Database Administrator
One of the main reasons for using DBMS 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.
2.11 Database User
The person who uses the database system is called a database user. They are four different types
of database system user, differentiated by the way expectation to interact with the system. They
are naïve user, application programmer, sophisticated user, specialized user.
2.12 Overall System structure
A database system is partitioned into modules that deal with the overall system. The functional
component of the database system can be broadly divided into the storage manager and the query
processor component.
The storage manager is important because database typically require a large storage space. Storage
manager manages the storage space and maintains the movement of data one disk to another.
The query processor is important because it helps the database system to simplify and facilitates
access to data. High level views help to achieve this goal.

11. 11 | P a g e
2.13 Entity Relationship Model
The entity relationship data model is based on perception of the real world that consists of a
collection of basic object called entities and of relationship among these object. An entity is a
“thing”, or “object” in the real world that is distinguishable from other object. For example, each
“patient” is an entity, and “treatment plan” can be considered as entities.
2.13.1 Attribute
The element of an entity set is called attributes. For example, “patient_name” is an attribute for
the entity set student.
2.13.2 Entity
An entity is a thing or object in the real object that is distinguishable from all other objects.
2.13.3 Weak Entity Set
An entity set without having sufficient attributes tom form a primary key is called weak entity set.
2.14 Mapping constraints
An E-R enterprise schema may define certain constraints to which the contents of a database must
conform. Most important types of constraints are mapping cardinalities and participation
constraints.
2.15 Key
The values of the attributes of an entity set must be such that they can uniquely identify the entity.
In other words, no two entity sets are allowed to have exactly the same value for all attributes.
There are some keys below:
2.15.1 Primary Key
PRIMARY KEY is a column or group of columns in a table that uniquely identify every row in that
table. The Primary Key can't be a duplicate meaning the same value can't appear more than once
in the table. A table cannot have more than one primary key. For example, “id” attribute of the
table “tbl_patient” is sufficient to distinguish each patient uniquely.

12. 12 | P a g e
Figure 2.1: Primary Key Indication in Table “tbl_patient”
2.15.2 Foreign Key
FOREIGN KEY is a column that creates a relationship between two tables. The purpose of Foreign
keys is to maintain data integrity and allow navigation between two different instances of an entity.
It acts as a cross-reference between two tables as it references the primary key of another table.
For example, “id” attribute of the table “tbl_patient” is the same as “regi_no” to identify a record
uniquely of “tbl_payment”.
Figure 2.2: Foreign Key Indication in Table “tbl_patient” and “tbl_payment”
2.15.3 Compound key
COMPOUND KEY has two or more attributes that allow you to uniquely recognize a specific
record. It is possible that each column may not be unique by itself within the database. However,
when combined with the other column or columns the combination of composite keys become
unique. The purpose of the compound key in database is to uniquely identify each record in the
table. For example, only “regi_no” is not sufficient to identify uniquely the entity set “Payment”.
Whereas both “regi_no” and “treat_no” together used to identify uniquely the entity set
“Payment”.

13. 13 | P a g e
Figure 2.3: Compound Key Indication in Table “tbl_payment”
2.16 Mapping Cardinality
Mapping Cardinality or cardinality ratios, express the number of entities to which another entity
can be associated via a relationship set. For relationship set R between entity sets A and B, the
mapping cardinality must be one of the following:
One To One:
An entity in A is associated with at most one entity in B and one entity in B is associated with at
most one entity in A.
A B
Figure 2.4: One to One Mapping Cardinality
a1
a2
a3
a4
b1
b2
b3
b4

14. 14 | P a g e
One to Many:
An entity in A is associated with any number of entities in B and an entity in B is associated with
at most one entity in A.
A B
Figure 2.5: One to Many Mapping Cardinality
Many to One:
An entity in B is associated with any number of entities in A and an entity in A is associated with
at most one entity in B.
A B
Figure 2.6: Many to One Mapping Cardinality
a1
a2
a3
b1
b2
b3
b4
b5
a1
a2
a3
a4
b1
b2
b3
a5

15. 15 | P a g e
Many to Many:
An entity in A is associated with any number of entities in B and an entity in B is associated with
any number of entities in A.
A B
Figure 2.7: Many to Many Mapping Cardinality
2.17 Reduction of an E-R schema to Table
We can represent a database that conforms to an E-R database schema by a collection of tables.
For each entity set and for each relationship set in the database there is a unique table to which we
assign the name of the corresponding entity set or relationship set. Each table has multiple
columns, each of which have unique name.
a1
a2
a3
a4
b1
b2
b3
b4

16. 16 | P a g e
Chapter - III
System Analysis and Design
3.1 Information Collection
It is the first step of any project. Success of a project depends upon proper information collection.
If information is wrong, our project will lose its aim. So we give a greater concern to collect proper
information. Our project is “Dental Treatment and Management Application” and this
application has been created on the basis of the Patient records management, Dental treatment
planning and Inventory management. So we have collected various information from the real life
dental practitioners and dentists in Bangladesh to know the workflow of a dental care point. We
also gathered information from patients and other stakeholders.
3.2 Analysis
System analysts work with users or stakeholders to identify goals and build systems to achieve
them. System development revolves around a life cycle that begins with the recognition of user
needs. Following a feasibility study, the key stages of the cycle are evaluation of the present
system, information gathering, cost/benefit analysis, detailed design and implementation of the
candidate system. The life cycle is not only a procedure that deals with hardware and software, it
also the building block of a web-based application to help the user to operate, make decisions
effectively and manage an enterprise and office successfully. This is the basics of system analysis.
Analysis also detailed study of the various operations performed by a system or application and
their relationships within and outside of the system. This involves gathering data and using
structured tools to make information for analysis. A key question is: What must be done to solve
the problem? Once aspect of analysis is defining the boundaries of the system and determining
whether or not a candidate system should consider other related systems. During analysis, data are
collected on the available files, decision points and transactions handled by the present system.
Data flow diagrams (DFDs), Flow Chart, Entity-Relationship (E-R) diagram, interviews, in-site
observations, and questionnaires are examples of analysis.

17. 17 | P a g e
3.2.1 The Entity Relationship (E-R) Model
E-R model consists of a collection of basic objects called entities and of relationships among these
objects. It provides a convenient graphical representation to view data. Entities are described in a
database by a set of attributes. For example, in our “dental” database, patient_name, patient_age,
patient_addrs, patient_occup, patient_mobile, patient_child are entities and patient considered as an
entity. An E-R model has been designed among above mentioned relational tables. The model is
as follows:
Figure 3.1: Entity Relationship (E-R) model

18. 18 | P a g e
3.2.2 Entity Relationship Diagram (ERD)
Figure 3.2: Entity Relationship Diagram
id
regi_no
treat_no
treatplan
_id
tpq1
Tpq2
Tpq3
Tpq4
Patient
patient_name
patient_age
patient_addrs
Has
Problem Treatment
id
patient_occup
reg_date
pFather_child
patient_mobile
Habit
habit_name
id
habit_des
c
HabitsBrush Time
Brush With
brush_time
id
brush_tim
e_desc
brush_with
id Brush_with_
desc
id
tplan_name
tplan_des
c
tplan_cos
t
tplan_disc_cost
specprob_nam
e
specprob_des
c
id
Problem
problem
Treatment Plan
Specific problem
problem_name
problem_des
c
id
Treatment
Start
Payment
id
regi_no
treat_no
treatment_cost
_sum
addi_treatment
_cost_sum
addi_treatment
_discount_sum
total_treatment
_cost
treatment_di
scount_sum
pay_now
Due_pa
yment
total_payable
current_treat
ment_date

19. 19 | P a g e
3.3 System Design
Once analysis is completed, the analysis has a firm understanding of what is to be done. The next
step is to decide how the problem might be solved. Thus, in system design, we move from the
logical to the physical aspects of the system life cycle.
The most creative and challenging phase of the system is system design. The term design describes
a final system and the process by which it is developed. It refers to the technical specifications
(analogous to the engineer's blueprints) that will be applied in implementing the candidate system.
It also includes the construction of programs and program testing. The key question here is: How
should the problem be solved? The major steps in design are shown below:
Figure 3.3: Overall Steps in System Design

20. 20 | P a g e
In the first step the output has been determined what should be produced and in what format.
Samples of the output are also presented in Appendix. Second, input forms have been designed to
meet the requirements of the proposed output. The designed various input forms which are shown
later. The operational (processing) phases are handled through program construction and testing,
including a list of the programs needed to meet the system's objectives and complete
documentation. In next steps details system documentation has been prepared and submitted to
supervisor for approval. Finally, documentation submitted as a step toward implementation.
3.4 Design Procedure
The whole project has been divided in several modules:
a) Patient’s General Information Module
b) Patient’s Habit Module
c) Patient’s Problem Module
d) Patient’s Specific Problem Module
e) Patient’s Brush Time Module
f) Patient’s Treatment Plan Module
g) Treatment Plan Start Module
h) Medical Test Examination Module
i) Billing Module
j) E-Prescription Module
k) Patient’s Treatment History Module
l) Report Module
m) Graphical Analysis and Report Module

21. 21 | P a g e
3.5 Performances and Efficiency
This application is efficient enough in solving all transaction problems with corresponding
reports. The following properties of this software increase its competence.
 Integrity
 Clarity
 Simplicity
 Generality
In Treatment Plan Form, if the practitioner (dentist) accidentally presses the cancel tab for a
specific patient or by mistakenly starts a new patient’s session while running a previous session
then a pop-up menu will appear to reset or complete the previous patient’s treatment session and
that will not hamper the overall treatment procedure.
3.6 APIs, Application Module, Software and Database Technology Requirements
Technology requirements including Personal computer / Laptop
Software
PHP Scripting Language.
Sublime text 3 for windows and
Notepad ++
HTML, CSS, JavaScript and PHP
Code Editor.
Hypertext Markup Language (HTML) It is markup language for documents
designed to be displayed in a web
browser.
Cascading Style Sheets (CSS) CSS is style sheet language used for
describing the presentation of a
document written in a markup
language like HTML.
bootstrap-3.3.7 Bootstrap is the most popular CSS
Framework for developing
responsive websites.
Font Awesome (font-awesome.min) Font Awesome is
a font and icon toolkit based
on CSS.

22. 22 | P a g e
jQuery 2.2.4, jquery-ui-1.12.1.min,
bootstrap-datepicker,
dataTables.responsive.min
Java Script Library (JS Library). The
purpose of jQuery is to make it
much easier to use JavaScript on
website.
mPDF mPDF is a PHP library which
generates PDF files from encoded
HTML.
Web-Server Apache Tomcat which is an open source web server.
Database
Server
MySQL MySQL is one of widely used open-
source relational database
management system RDBMS.
API’s Google Charts It provides a perfect way to visualize
data on your website.
Software
Package
XAMPP It is a software distribution which
provides the Apache web server,
MySQL database, PHP and Perl all
in one package.
Table 1.1: Table of Required Software, Database, API’s and Application Module

23. 23 | P a g e
Chapter IV
Conclusion and Recommendations
4.1 Conclusion
We have tried our best and still trying to complete the whole project having a bright prospect. By
working for this project we have had conceptions about MySQL server, SQL Query, JavaScript
manipulations and uses of mPDF, handling multiple features randomly and many other instance
of it. It is easy to handle and lively for all the user and advanced operators. As it is an interesting
topic farther proceed of it remains as a matter of our interest.
4.2 Limitations
Full perfection cannot be possible for any application. Although our application supports all the
current needs for a dentist care-point, rather there are some limitations left behind due to lack of
proper time, our inefficiency. That is - in the treatment stage if we can add test report integrated
with billing stage and also can have a payment gateway, then there may be anomalous result arise.
4.3 Future plan
The project is our first work in the big arena of database. For this we have to face some problems,
as we have not much experience in this zone. But we have tried our best to do the job perfectly
within a short time. We don't think that this project is a perfect one but it does not mean that we
are not satisfied in our work. We are happy in our work and at the same time we are thinking the
more implementation of this project with the experience that we have gained in this work. Our
future plane is to make this project a perfect one for the larger use.
i. We want to overcome all the limitations that we have in the present condition of the
project.
ii. We want to make it more user friendly and comfortable for use.
iii. We shall reduce mouse dependency and make it easy for keyboard.
iv. We will integrate payment gateway in billing module.
v. Integrate patient’s test report with treatment and billing module.
vi. Share the e-Prescription with other dentist or dental care-point through online system.