Professional Documents
Culture Documents
Roll No. : 75
PRN : 2014110738
Academic Year : 2021-2022
PROJECT TITLE
PROJECT DESCRIPTION
The project is a Patient Health Record Management System which mainly deals
with the collection of patient’s information, diagnosis details, etc. Traditionally,
it was done manually. The main function of the system is register and store patient
details and doctor details and retrieve these details as and when required, and to
manipulate these details meaningfully System input contains patient details,
diagnosis details, while system output is to get these details on to the screen. The
project includes registration of patients, storing their details into the system, and
computerized billing .
Objectives:
APPROACH USED-
DATABASE LIFECYCLE-
INTRODUCTION-
The database life cycle is a cycle that traces the history of the database in an
information system. The database life cycle incorporates the necessary steps
involved in database development, starting with requirements analysis and ending
with monitoring and modification. The DBLC never ends because database
monitoring, improvement, and maintenance are part of the life cycle, and these
activities continue as long as the database is alive and in use.
In our project we begin analysis on patient record management system and gather
all the necessary information for our project i.e. attributes ,entities ,relationship
and all other relevant information.
Project Requirement- Store data related to patirent record .the following
attributes have been identified and will be used for storing the needed record.
1. pid
2. pname
3. gender
4. city
5. state
6. contact
7. zip code
8. dob
9. did
10.d name
11.contact
12.address
13.department
14.expertise
15.d fees
16.lid
17.lab name
18.lab address
19.ltest ID
20.test name
21.test result
22.testdate
23.labtest fees
24.pres-id
25.med-id
26.medicine
27.m-amount
28.prescription
29.dosage
30.bill-id
31.bill-date
32.tax
33.billing amount
34.total cost
Database Design-
Based on the results of the data requirements analysis, carry out the design
process. There are two database design approaches, namely:
• The top-down design uses an entity-relationship (ER) model. The design
begins with identifying entities, followed by relationships between entities
and cardinality or multiplicity. Each entity consists of attributes, primary
keys, and foreign keys (if any).
• The bottom-up design uses the process of normalization. Design starts with
identifying attributes, then grouping them into data sets to form relations.
The two approaches are complementary. The design process begins with
conceptual data modeling and continues to the logical database design and
physical database design stages. The ER model is used in the conceptual data
modeling stage. In the early ER model, normalization was carried out on entities
or relationships with multiple data attributes. The normalization results are used
to modify the initial ER model to obtain a better final ER model. In the logical
database design stage, normalization is carried out on the mapping result relations
of ER modeling, which has multiple data. The two approaches are
complementary. The design process begins with conceptual data modeling and
continues to the logical database design and physical database design stages. The
conceptual data modeling uses the ER model. In the early ER model, carry out
normalization on entities or relationships that have data redundancies. Use the
normalization results to obtain a better final ER model.
E-R DIAGRAM-
Selection of software-
• After laying out the design of database we need to select software inwhich we
will develop the project.
• So in our project we are using mysql community server.
Logical Database Design
• Based on the conceptual data model and mapping rules, every entity and
relationship with attributes are converted into relations. Relationships that
have attribute groups with data redundancies result in anomalies when
adding, updating, or deleting data. Such tables need to be normalized, at least
up to 3NF (third normal form). Each relation attribute is determined by its
data type and domain, including whether the data must be unique or not. The
result is a specification for each relation.
• In this we have normalized our database till 3nf and then on the basis of 3nf
we have developed our relations and final database.
• After that we have created table and defined our table datatypes and
constraints.
• Constraints like primary key,not null etc.
Opertation-
• Performing the required operartion like insertion and creation and
performing the sql queries to obtain result from our database.
Database Maintenance
• When the database comes into operation, monitoring is carried out to see
if performance requirements are being met; whether user expectations
increase with demands for better performance. If not, modifications must
be made to improve performance.
NORMALIZATION-
DATABASE TABLE-
THE BELOW TABLE IS OUR ORIGINAL TABLE AS IT IS VERY LARGE
WE CAN’T SEE THE TABLE CONTENTS SO WE HAVE BREAKED THE
ORIGINAL TABLE INTO SMALLER TABLE SO THAT IT IS VISIBLE.
So in our case our data is already in first normal form so we have no need to convert data into
first normal form and we can directly move to second normal form.
PID PNAME
GENDER CONTACT CITY STATE ZIPCODE DOB
1 JOHNMALE 12345 ROCHESTER YORK 1462 12-04-1990
2 TOM MALE 67891 PRINCETON JERSEY 8540 05-02-1997
3 CHRIS
MALE 55555 CAMBRIDGE PERTH 6000 05-01-1985
4 JACKMALE 54545 ALEXANDRIA SDYNEY 2000 07-07-1989
5 ROBIN
FEMALE 35798 HOPPEGARTEN BERLIN 1115 02-02-2000
6 JOHNMALE 16789 YOKOHAMA TOKYO 1001 16-06-1995
7 ROBERT
MALE 28937 NEW YORK NEW YORK 5001 18-08-2005
8 BRADMALE 33221 MANDOLI DELHI 1101 25-04-1996
MYEONG-
9 MARK MALE 12987 DONG SEOUL 1021 27-04-1990
10 DWAYNE MALE 94689 TORONTO ONTARIO 5001 15-04-1995
DEPARTMENT
DID DNAME EXPERTISE LOCATION CONTACT ADDRESS
101 MIKE UROLOGISTS UROLOGY 98889 DELHI
102 HENRY ORTHOPAEDIC ORTHOLOGIST 87778 PUNE
103 MIACHEL NEUROLOGIST NEUROSURGEON 76667 ORGEGON
104 SONNY ENT ENT SPECALIST 43334 BRISBANE
105 LEE GASTROENTEROLOGY GASTROENTEROLOGY 54345 AUCKLAND
106 ARTHUR PSYCHIATRISTS PSYCHIATRT 31123 SEOUL
107 HARVEY CARDIOTHORACIC CARDIOLOGIST 49594 OHIO
NEW
108 PAUL ENT ENT SPECALIST 49594 JERSEY
109 ALFRED HEMATOLOGISTS HEMATOLOGY 54345 TEXAS
110 THEODOR DENTIST DENTISTRY 93696 CALIFORNIA
LTEST-
LID LAB_ADDRESS LABNAME ID TESTNAME TEST - RESULT TEST-DATE
201 DELHI PUVT 501 URINE NORMAL 05-01-2022
ANKLE- HAIRLINE-
202 PUNE NEURO 502 XRAY CRACK 10-01-2022
202 PUNE NEURO 503 MRI NORMAL 19-01-2022
LOW HEARING-
203 HYD ENT-LAB 504 EAR LOSS 05-01-2022
204 BANGLORE GAESTRO 505 GAESTRIC NORMAL 25-01-2022
204 NULL NULL 506 NO-TEST NO RESULT 05-01-2022
205 PUNJAB PUVT 507 VITAMIN LOW B12 02-02-2022
203 HYD ENT-LAB 508 NOSE ASTHAMA 19-02-2022
205 PUNJAB PUVT 509 PLATELET LOW 02-02-2022
205 PUNJAB PUVT 510 CALCIUM LOW CALCIUM 28-01-2022
MED-ID PRES-ID MEDICINE PRESCRIPTION DOSAGE
1001 301 NULL NULL 0
1002 302 DOLO-650 PAINKILLER 4
1003 303 NULL NULL 0
1004 304 COMBIFLAME PAINKILLER 2
REDUCE
1005 305 DIGINE ACIDITY 1
1006 306 NULL NULL 0
1007 307 NEUROBION-20 VITAMIN SUPP. 4
1008 308 FLUCTICASONE BREATHING 2
1009 309 PREDNISONE INC. PLATELET 4
1010 310 CALCIUM SUPP. INC.CALCIUM 1
Second Normal Form –
To be in second normal form, a relation must be in first normal form and relation must not
contain any partial dependency. A relation is in 2NF if it has No Partial
Dependency, i.e., no non-prime attribute (attributes which are not part of any candidate
key) is dependent on any proper subset of any candidate key of the table.
Partial Dependency – If the proper subset of candidate key determines non-prime
attribute, it is called partial dependency.
PATIENT-
• PID (PRIMARY KEY)
• DID(FOREIGN KEY)
• PRES ID(FOREIGN KEY)
• PNAME
• GENDER
• CONTACT
• CITY
• STATE
• ZIPCODE
• DOB
D_INFO-
• DID(PRIMARY KEY)
• DNAME
• CONTACT
• ADDRESS
D_DEPARTMENT-
• DID (PRIAMRY KEY)
• DNAME
• DEPARTMENT LOCATION
D_FEES
• DID(PRIMARY KEY)
• EXPERTISE
• FEES
LABTEST
• LTEST ID(PRIMARY KEY)
• LID
• PID(FOREIGN KEY)
• TEST NAME
• TEST RESULT
• TEST DATE
• LABFEES
PRES
• PRES ID(PRIMARY KEY)
• PRESCRIPTION
• DOSAGE
LAB
• LID
• LTEST ID(PRIMARY KEY)
• LABNAME
• LAB ADDRESS
MEDICINE
• MED ID(PRIMARY KEY)
• MEDICINE
• M.AMOUNT
BILL
• PID(FOREIGN KEY)
• DID(FOREIGN KEY)
• BID(PRIMARY KEY)
• BILL DATE
• LABFEES
• M_AMOUNT
• D_FEES
• TAX
• BILLING AMOUNT
• TOTAL COST
BUILDING INDEXES->
Patient->
D_info->
d-department->
D_fees->
labtest->
Lab->
Medicine->
Prescription->
bill->
DEVELOPING THE PHYSICAL DATABASE
TABLE CREATION AND DUMPING DATA-
PATIENT-
• PID (PRIMARY KEY)
• DID(FOREIGN KEY)
• PRES ID(FOREIGN KEY)
• PNAME
• GENDER
• CONTACT
• CITY
• STATE
• ZIPCODE
• DOB
D_INFO-
• DID(PRIMARY KEY)
• DNAME
• CONTACT
• ADDRESS
D_DEPARTMENT-
• DID (PRIAMRY KEY)
• DNAME
• DEPARTMENT LOCATION
D_FEES
• DID(PRIMARY KEY)
• EXPERTISE
• FEES
LABTEST
• LTEST ID(PRIMARY KEY)
• LID
• PID(FOREIGN KEY)
• TEST NAME
• TEST RESULT
• TEST DATE
• LABFEES
PRES
• PRES ID(PRIMARY KEY)
• PRESCRIPTION
• DOSAGE
LAB
• LID
• LTEST ID(PRIMARY KEY)
• LABNAME
• LAB ADDRESS
MEDICINE
• MED ID(PRIMARY KEY)
• MEDICINE
• M.AMOUNT
BILL
• PID(FOREIGN KEY)
• DID(FOREIGN KEY)
• BID(PRIMARY KEY)
• BILL DATE
• LABFEES
• M_AMOUNT
• D_FEES
• TAX
• BILLING AMOUNT
• TOTAL COST
D_info->
D_department->
D_fees->
Prescription->
Medicine->
Patient->
Labtest->
Lab->
Bill->
FINAL TABLES->
D_info->
D_department->
D_fees->
Medicine->
Prescription->
Patient->
Labtest->
Lab->
Bill->
QUERIES-