Criminal Database and Crime Analysis

DBMS Project (CS254)

Submitted to:

Prof. Soumya Hegde

Submitted by:

241CS206 Aluri Shanthi

241CS223 D Jahnavi
241CS236 Madhuri Nallaboyina
241CS240 Neha Kamath

Department of Computer Science & Engineering

National Institute of Technology Karnataka, Surathkal

2026
Criminal Database and Crime Analysis DBMS Project (CS254)

Contents

1 Introduction 2
1.1 Background of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Scope and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Overview of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literature Survey 3
2.1 Review of Existing Systems . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Identified Research Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 System Analysis 4
3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6

4 System Design 7
4.1 Entity Relationship (ER) Diagram . . . . . . . . . . . . . . . . . . . . . 7
4.2 Relational Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Implementation and Results 13

5.1 Tools and Technologies Used . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Frontend Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Backend Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 SQL Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5 Application Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Conclusion and Future Work 22

6.1 Summary of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Future Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7 References 23

1
Criminal Database and Crime Analysis DBMS Project (CS254)

1. Introduction
1.1 Background of the Project
Law enforcement agencies in India and worldwide rely heavily on maintaining accurate
records of crimes, criminals, suspects, victims, and evidence. Traditionally, these records
have been maintained through paper-based systems or isolated digital files spread across
multiple departments. This fragmented approach leads to duplication of data, loss of
critical records, difficulty in tracking repeat offenders, and delayed response times during
investigations.
With the rapid advancement of digital technology, there is a growing need for central-
ized, structured, and secure systems that can store, manage, and analyze criminal data
efficiently. Government initiatives such as India’s Crime and Criminal Tracking Network
and Systems (CCTNS) project have already demonstrated the value of digitizing police
station operations at a national level.

1.2 Problem Statement

Existing paper-based and fragmented departmental record systems make it extremely
difficult for law enforcement agencies to track criminals across multiple cases, identify
recurring crime patterns, retrieve historical case data quickly, and generate actionable
analytical insights. Officers and investigators spend significant time manually searching
through records rather than focusing on active investigations. There is a clear need for
a unified digital platform that centralizes all crime-related data under a single secure
interface with role-based access for different categories of users.

1.3 Objectives
• Develop a centralised web application for digitally registering and managing crime
records and FIRs using [Link] and [Link].
• Maintain criminal profiles and link suspects to their associated crimes, arrests, and
case histories in a structured MySQL database.
• Enable investigation teams to create and manage case files, assign officers, and track
case progress from opening to closure.
• Provide interactive crime analysis dashboards and GIS-based crime maps for identi-
fying trends, hotspots, and repeat offenders.
• Implement secure role-based access control using JWT authentication, ensuring only
authorised users can access sensitive crime data.

1.4 Scope and Limitations

Scope:
• The system supports registration and management of crimes, criminals, suspects,
victims, arrests, and evidence through a web-based interface.
• Role-based access is provided for four user types: Admin, Officer, and Civilian.

2
Criminal Database and Crime Analysis DBMS Project (CS254)

• The system includes GIS-based crime mapping using latitude and longitude data
stored for every crime location.
• Crime analysis reports including crime trends, area-wise statistics, repeat offenders,
and officer performance are generated from the database.
• The system is designed for use within a single police jurisdiction or department.
Limitations:
• The system does not currently integrate with external national databases such as
CCTNS in real time.
• Facial recognition or biometric identification of criminals and suspects is not imple-
mented.
• The GIS crime map is based on stored coordinates and does not use live GPS tracking
of officers or suspects.
• The system is a prototype and has not been tested at the scale of a real police
department with thousands of concurrent users.
• Mobile application support is not included in the current version.

1.5 Overview of the System

The Criminal Database and Crime Analysis System is a full-stack web application de-
signed to help law enforcement agencies digitally record, manage, and analyse crime-
related data. The system provides a centralised platform where police officers, investiga-
tors, and analysts can register FIRs, manage criminal profiles, handle case files, and log
evidence — all from a single secure interface.
The frontend is built using [Link] for a dynamic and responsive user experience, while
the backend uses [Link] and [Link] to expose RESTful API endpoints connected
to a MySQL relational database. Role-based access control ensures that sensitive data is
accessible only to authorised personnel. The system also includes interactive dashboards
and GIS-based crime mapping to support data-driven decision making in law enforcement.

2. Literature Survey
2.1 Review of Existing Systems
Database Management for Criminal Records
Elmasri and Navathe (2016) provide essential principles of relational database design,
including ER modelling, normalisation, and query optimisation applicable to criminal
record systems. Silberschatz, Korth, and Sudarshan (2019) extend this work with trans-
action management, concurrency control, and access security crucial for sensitive law
enforcement data. MySQL 8.0, documented by Oracle (2023), offers stored procedures,
triggers, and role-based access control well suited for criminal databases. Together, these
works establish the theoretical and practical foundation for structuring entities like crim-
inals, FIRs, cases, and evidence. Proper database design ensures data consistency, in-
tegrity, and efficient retrieval across large criminal record sets.

3
Criminal Database and Crime Analysis DBMS Project (CS254)

Crime Mapping and GIS Integration

Chainey and Ratcliffe (2005) pioneered the use of GIS in law enforcement, demonstrat-
ing hotspot mapping, kernel density estimation, and spatial crime clustering techniques.
Their work showed that visualising crime geographically helps police allocate resources
more efficiently and identify high-risk areas. Kounadi et al. (2020) conducted a systematic
review of spatial crime forecasting, finding that multi-source spatial data integration sig-
nificantly improves prediction accuracy. GIS tools allow investigators to correlate offence
locations with socio-economic and demographic variables for deeper insight.

National Crime Databases and Government Initiatives

The NCRB Crime in India report (2022) provides a standardised framework for classify-
ing offences, victim demographics, case status, and geographic distribution across India.
The CCTNS project by the Ministry of Home Affairs (2009) represents India’s largest
law enforcement e-governance initiative, digitising police station operations nationwide,
providing a practical blueprint for centralised criminal database architecture with inter-
agency data sharing capabilities.

2.2 Identified Research Gaps

A review of existing systems and literature reveals the following gaps that this project
addresses:
• Lack of unified platforms: Most existing systems handle either criminal records or
crime mapping in isolation. There is no widely available open system that integrates
both under a single interface with role-based access.
• Limited public reporting mechanisms: Existing systems like CCTNS are officer-
facing and do not provide a channel for members of the public to report crimes digitally
and track their report status.
• Absence of junction-based relational modelling: Many criminal database im-
plementations use flat or semi-structured data models, which fail to capture many-to-
many relationships such as multiple suspects per crime or multiple officers assigned
to a case.
• Weak access control granularity: Most existing digital record systems use bi-
nary access (admin or user) rather than fine-grained role-based access control that
differentiates between Officers, Civilains, and Admins.
• No integrated crime history tracking: Existing systems rarely maintain a com-
plete legal and sentencing history of a criminal that persists across multiple cases and
convictions.

3. System Analysis
3.1 Functional Requirements
1. User Authentication and Access Control
• The system shall allow users to register and log in using email and password.

4
Criminal Database and Crime Analysis DBMS Project (CS254)

• The system shall issue a JWT token on successful login and use it to authenticate
all subsequent API requests.
• Access to modules shall be restricted based on the user’s role (Admin, Officer,
or Civilian).
2. Crime Record Management
• The system shall allow officers to register new crime incidents (FIRs) with details
including crime type, location, date, time, description, and status.
• The system shall allow filtering and searching of crime records by type, severity,
status, date, and location.
• The system shall allow updating the status of a crime (Open, Under Investiga-
tion, Closed).
3. Criminal Profile Management
• The system shall allow creation and management of criminal profiles with per-
sonal details, photo, and current status.
• The system shall link criminals to their committed crimes and complete legal
history.
4. Suspect and Victim Management
• The system shall allow recording suspects and linking them to specific crimes
with investigation notes.
• The system shall allow recording victim details and linking them to crimes with
injury level and statements.
5. Arrest and Evidence Management
• The system shall record arrest details including date, location, charge, and bail
status, linked to criminals, crimes, and officers.
• The system shall allow logging evidence for each crime with type, description,
collection details, and storage location.
6. Officer Management
• The system shall maintain officer profiles with badge number, rank, and depart-
ment.
• The system shall allow assigning officers to crimes and tracking case load per
officer.
7. Crime Mapping
• The system shall store latitude and longitude for every crime location.
• The system shall display an interactive GIS-based map with crime location mark-
ers filterable by area, type, and date.
8. Crime Analysis and Reporting
• The system shall display a dashboard with summary statistics for quick overview.

5
Criminal Database and Crime Analysis DBMS Project (CS254)

9. Public Crime Reporting

• The system shall allow public users to submit crime reports.
• Officers shall be able to review, accept, or reject public reports with a reason.

3.2 Non-Functional Requirements

1. Security
• All passwords shall be stored as bcrypt-hashed values; plain-text passwords shall
never be stored.
• All API endpoints shall be protected by JWT authentication middleware.
• Input validation and sanitisation shall be enforced on all API routes to prevent
SQL injection and malformed data entry.
2. Performance
• The system shall use a MySQL connection pool to handle multiple simultaneous
database requests efficiently.
• API response time for standard queries (fetch crime records, search criminals)
shall be under 2 seconds under normal load.
3. Usability
• The interface shall be responsive and usable on desktop browsers.
• Navigation between modules shall require no more than two clicks from the
dashboard.
• User feedback (success or error notifications) shall be displayed for every form
submission.
4. Reliability
• The system shall enforce foreign key constraints to maintain referential integrity
across all 17 tables.
• The database schema shall be normalised to 3NF to eliminate data redundancy.
5. Maintainability
• The codebase shall follow a modular MVC-like structure with separate con-
trollers, routes, and models.
• Environment variables shall be used for all sensitive configuration values such as
database credentials and JWT secrets.
6. Scalability
• The RESTful API design shall allow the frontend to be replaced or extended
(e.g., mobile application) without changes to the backend.

6
Criminal Database and Crime Analysis DBMS Project (CS254)

4. System Design
4.1 Entity Relationship (ER) Diagram
Figure 1 shows the Entity-Relationship diagram for the entire schema, illustrating all
entities, their attributes, and the relationships between them.

Figure 1: ER Diagram of the Criminal Database System (Part 1)

7
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 2: ER Diagram of the Criminal Database System (Part 2)

4.2 Relational Schema

The Criminal Database and Crime Analysis System uses a relational database schema
designed in MySQL. The schema consists of 17 interrelated tables connected through
26 foreign key relationships to ensure referential integrity, eliminate data redundancy,
and support efficient querying across all modules of the system.
The central table is CRIME, which acts as the hub of the entire database. Almost every
other table connects to CRIME either directly through a foreign key or indirectly through a
junction table. Supporting tables such as EVIDENCE, ARREST, and CRIMINAL_CRIME_HISTORY
extend the crime record with detailed investigative and legal information. Junction tables
resolve many-to-many relationships between core entities.
Figure 3 shows the detailed table structure with all column names and data types as
defined in the MySQL schema.

8
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 3: Detailed Table Structure of the Database Schema

List of Tables
1. CRIME — Central table storing crime details including location, type, date/time,
description, status, and estimated damage.
2. CRIMINAL — Personal profiles of known criminals with name, DOB, gender, na-
tionality, address, photo, and status.
3. SUSPECT — Individuals under suspicion, linked to crimes via CRIME_SUSPECT.
4. VICTIM — Personal details of crime victims, linked via CRIME_VICTIM.
5. OFFICER — Profiles of law enforcement officers with badge number, rank, and
department.
6. OFFICER_RANK — Available ranks with access levels controlling permissions.
7. LOCATION — Full address data including GPS coordinates for every referenced
location.
8. CRIME_TYPE — Crime categories with severity level and description.
9. EVIDENCE — Evidence collected per crime with type, collection details, and stor-
age location.

9
Criminal Database and Crime Analysis DBMS Project (CS254)

10. ARREST — Arrest records linking criminals, crimes, and arresting officers.
11. CRIMINAL_CRIME_HISTORY — Complete legal and sentencing history of
each criminal per crime.
12. USER — Login credentials and role information for all system users.
13. USER_REPORTED_CRIME — Public crime reports with status and reviewing
officer.
14. CRIMINAL_CRIME — Junction: resolves Criminal ↔ Crime (M:N).
15. CRIME_SUSPECT — Junction: resolves Crime ↔ Suspect (M:N).
16. CRIME_VICTIM — Junction: resolves Crime ↔ Victim (M:N).
17. OFFICER_CRIME — Junction: resolves Officer ↔ Crime (M:N).

Foreign Key Relationships

The schema contains 26 foreign key relationships as listed in Table 1.

Table 1: Foreign Key Relationships in the Schema

# Table References
1 OFFICER OFFICER_RANK
2 USER OFFICER
3 CRIME LOCATION
4 CRIME CRIME_TYPE
5 CRIME USER
6 EVIDENCE CRIME
7 EVIDENCE OFFICER
8 ARREST CRIMINAL
9 ARREST CRIME
10 ARREST OFFICER
11 ARREST LOCATION
12 CRIMINAL_CRIME_HISTORY CRIMINAL
13 CRIMINAL_CRIME_HISTORY CRIME
14 USER_REPORTED_CRIME USER
15 USER_REPORTED_CRIME OFFICER
16 CRIME_SUSPECT CRIME
17 CRIME_SUSPECT SUSPECT
18 CRIME_VICTIM CRIME
19 CRIME_VICTIM VICTIM
20 OFFICER_CRIME CRIME
21 OFFICER_CRIME OFFICER
22 CRIMINAL_CRIME CRIME
23 CRIMINAL_CRIME CRIMINAL
24 SUSPECT LOCATION
25 VICTIM LOCATION
26 CRIMINAL LOCATION

10
Criminal Database and Crime Analysis DBMS Project (CS254)

Entities and Attributes

Table 2: Entities and Attributes of the Schema

Entity Attributes
CRIMINAL criminal_id (PK), first_name, last_name,
date_of_birth, gender, nationality, address_id
(FK), photo_url, status
CRIME_TYPE crime_type_id (PK), type_name,
severity_level, crime_description
LOCATION location_id (PK), address1, address2,
address3, district, city, state, pincode, country,
latitude, longitude
OFFICER officer_id (PK), officer_rank (FK),
first_name, last_name, dob, department,
contact
CRIME crime_id (PK), location_id (FK),
crime_type_id (FK), reported_by (FK),
crime_date, crime_time, description, status,
damage_estimate
ARREST arrest_id (PK), criminal_id (FK), crime_id
(FK), officer_id (FK), arrest_date,
arrest_location_id (FK), charge, bail_status,
arrest_time
EVIDENCE evidence_id (PK), crime_id (FK),
evidence_type, description, collected_date,
collected_by (FK), storage_location,
collected_time
VICTIM victim_id (PK), first_name, last_name,
date_of_birth, gender, contact_number,
address_id (FK)
CRIME_VICTIM crime_id (FK), victim_id (FK), injury_level,
statement
SUSPECT suspect_id (PK), first_name, last_name,
date_of_birth, gender, contact_number,
address_id (FK), photo_url, description,
status
CRIME_SUSPECT crime_id (FK), suspect_id (FK),
added_date, notes
CRIMINAL_CRIME_HISTORY history_id (PK), criminal_id (FK), crime_id
(FK), verdict, sentence_type,
sentence_duration, prison_name,
imprisonment_date, release_date,
parole_status, notes
USER user_id (PK), officer_id (FK), username,
password_hash, is_active, created_at,
user_type, email

11
Criminal Database and Crime Analysis DBMS Project (CS254)

Entity Attributes
OFFICER_CRIME crime_id (FK), officer_id (FK), officer_role
USER_REPORTED_CRIME report_id (PK), user_id (FK), reported_at,
report_status, rejection_reason, reviewed_by
(FK), reviewed_at, notes
CRIMINAL_CRIME crime_id (FK), criminal_id (FK),
criminal_role
OFFICER_RANK rank_id (PK), rank_name, access_level

4.3 Normalization
The database schema is normalised progressively through the three normal forms to
eliminate redundancy and ensure data integrity.

First Normal Form (1NF)

A relation is in 1NF if all attributes contain atomic (indivisible) values and there are no
repeating groups.
In our schema, every table satisfies 1NF:
• Every column holds a single atomic value. For example, CRIMINAL stores first_name
and last_name as separate columns rather than a combined name field.
• There are no repeating groups. Multiple suspects for a crime are not stored as a list
inside the CRIME table — instead they are stored as separate rows in CRIME_SUSPECT.
• Every table has a defined primary key (crime_id, criminal_id, arrest_id, etc.).

Second Normal Form (2NF)

A relation is in 2NF if it is in 1NF and every non-key attribute is fully functionally
dependent on the entire primary key (no partial dependencies). This applies to tables
with composite primary keys.
In our junction tables:
• CRIME_SUSPECT(crime_id, suspect_id, added_date, notes) — added_date
and notes depend on the full composite key (crime_id, suspect_id), not on either
key alone. ⇒ 2NF satisfied.
• CRIME_VICTIM(crime_id, victim_id, injury_level, statement) — injury_level
and statement depend on the full composite key. ⇒ 2NF satisfied.
• OFFICER_CRIME(crime_id, officer_id, officer_role) — officer_role depends
on the full composite key. ⇒ 2NF satisfied.
• CRIMINAL_CRIME(crime_id, criminal_id, criminal_role) — criminal_role
depends on the full composite key. ⇒ 2NF satisfied.

12
Criminal Database and Crime Analysis DBMS Project (CS254)

Third Normal Form (3NF)

A relation is in 3NF if it is in 2NF and there are no transitive dependencies (no non-key
attribute depends on another non-key attribute).
Key examples from our schema:
• In OFFICER, rank_name and access_level could transitively depend on officer_rank
rather than directly on officer_id. This was resolved by extracting OFFICER_RANK
as a separate table, with officer_rank as a foreign key in OFFICER. ⇒ 3NF satisfied.
• In CRIME, location details (city, district, coordinates) could transitively depend on
location_id rather than crime_id. These were extracted into the separate LOCA-
TION table. ⇒ 3NF satisfied.
• In CRIMINAL_CRIME_HISTORY, sentencing attributes (verdict, sentence_duration,
prison_name) all depend directly on history_id with no transitive dependencies. ⇒
3NF satisfied.
The entire schema is in Third Normal Form (3NF), ensuring no data redundancy and
full referential integrity across all 17 tables.

5. Implementation and Results

5.1 Tools and Technologies Used

Table 3: Tools and Technologies Used

Technology Purpose
[Link] Frontend UI with functional components and
Hooks
React Router Client-side page navigation
Axios HTTP requests from frontend to backend API
Tailwind CSS Responsive UI styling
[Link] Backend JavaScript runtime environment
[Link] RESTful API framework
MySQL Relational database management system
JWT Token-based authentication and session
management
[Link] Password hashing before database storage
Multer File upload middleware for photos and evidence
Express Validator Input validation and sanitisation
CORS Cross-origin resource sharing configuration
Postman API endpoint testing
Git & GitHub Version control and collaborative development
VS Code Development environment

13
Criminal Database and Crime Analysis DBMS Project (CS254)

5.2 Frontend Description

The frontend is built using [Link] with a component-based architecture. A reusable
Layout component wraps all authenticated pages and provides a consistent sidebar nav-
igation, top header with user profile, and footer. The sidebar includes links to all major
modules: Dashboard, Crime Records, Criminals, Suspects, Victims, Arrests, Evidence,
Officers, Crime Map, and Reports.
Key pages include:
• Landing Page — Public-facing page introducing the system with feature overview
and navigation to login.
• Login / Register — JWT-authenticated login with role-based redirect. Two-step
registration form with role selection.
• Dashboard — Summary statistics cards, quick action buttons, and recent crime
activity feed.
• Crime Records — Full list of registered crimes with filtering and search.
• Criminal / Suspect / Victim pages — Profile management with linked cases.
• Arrest and Evidence pages — Detailed records linked to crimes and officers.
• Crime Map — GIS-based interactive map using latitude/longitude from the LOCATION
table.
• Reports — Analytical views including crime trends, area-wise stats, and repeat of-
fenders.

5.3 Backend Description

The backend is built using [Link] and [Link] following an MVC-like structure with
separate controllers/, routes/, and middleware/ directories. MySQL is accessed
through a connection pool configured in config/[Link].
All API routes are prefixed as follows:
• /auth — Login, register, logout
• /api/crimes — Crime record operations
• /api/criminals — Criminal profile management
• /api/suspects — Suspect tracking
• /api/victims — Victim management
• /api/arrests — Arrest records
• /api/evidence — Evidence logging
• /api/officers — Officer management
• /api/locations — Location data
• /api/crimetypes — Crime type classification
• /api/reports — Analysis and reporting
• /api/user — User profile management
Every protected route passes through the authMiddleware, which verifies the JWT token
from the request header and attaches the decoded user object to [Link].

14
Criminal Database and Crime Analysis DBMS Project (CS254)

5.4 SQL Queries

DDL — Data Definition Language
Listing 1: Creating the CRIME table
CREATE TABLE CRIME (
crime_id INT AUTO_INCREMENT PRIMARY KEY ,
location_id INT NOT NULL ,
crime_type_id INT NOT NULL ,
crime_date DATE NOT NULL ,
crime_time TIME ,
crime_description TEXT ,
crime_status ENUM ( ’ Open ’ , ’ Under Investigation ’ , ’ Closed ’)
DEFAULT ’ Open ’ ,
damage_estimate DECIMAL (15 ,2) ,
reported_by INT ,
FOREIGN KEY ( location_id ) REFERENCES LOCATION ( location_id ) ,
FOREIGN KEY ( crime_type_id ) REFERENCES CRIME_TYPE (
crime_type_id ) ,
FOREIGN KEY ( reported_by ) REFERENCES USER ( user_id )
);

Listing 2: Creating the CRIMINAL table

CREATE TABLE CRIMINAL (
criminal_id INT AUTO_INCREMENT PRIMARY KEY ,
first_name VARCHAR (60) NOT NULL ,
last_name VARCHAR (60) NOT NULL ,
date_of_birth DATE ,
gender ENUM ( ’ Male ’ , ’ Female ’ , ’ Other ’) ,
nationality VARCHAR (100) ,
address_id INT ,
photo_url TEXT ,
status ENUM ( ’ Arrested ’ , ’ Convicted ’ , ’ Absconding ’ , ’
Released ’) ,
FOREIGN KEY ( address_id ) REFERENCES LOCATION ( location_id )
);

Listing 3: Creating the ARREST table

CREATE TABLE ARREST (
arrest_id INT AUTO_INCREMENT PRIMARY KEY ,
criminal_id INT NOT NULL ,
crime_id INT NOT NULL ,
officer_id INT NOT NULL ,
arrest_date DATE NOT NULL ,
arrest_time TIME ,
arrest_location_id INT ,
charge TEXT ,
bail_status ENUM ( ’ Granted ’ , ’ Denied ’ , ’ Pending ’) ,
FOREIGN KEY ( criminal_id ) REFERENCES CRIMINAL (
criminal_id ) ,
FOREIGN KEY ( crime_id ) REFERENCES CRIME ( crime_id ) ,

15
Criminal Database and Crime Analysis DBMS Project (CS254)

FOREIGN KEY ( officer_id ) REFERENCES OFFICER ( officer_id

),
FOREIGN KEY ( arrest_location_id ) REFERENCES LOCATION (
location_id )
);

DML — Data Manipulation Language

Listing 4: Insert a new crime record
INSERT INTO CRIME ( location_id , crime_type_id , crime_date ,
crime_time ,
crime_description , crime_status ,
damage_estimate , reported_by )
VALUES (3 , 2 , ’ 2024 -03 -15 ’ , ’ 21:30:00 ’ ,
’ Armed robbery at commercial complex ’ , ’ Open ’ , 50000.00 ,
1) ;

Listing 5: Fetch all crimes with location and type

SELECT c . crime_id , ct . crime_type_name , ct . crime_severity_level ,
l . city , l . district , c . crime_date , c . crime_status
FROM CRIME c
JOIN CRIME_TYPE ct ON c . crime_type_id = ct . crime_type_id
JOIN LOCATION l ON c . location_id = l . location_id
ORDER BY c . crime_date DESC ;

Listing 6: Update crime status

UPDATE CRIME
SET crime_status = ’ Under Investigation ’
WHERE crime_id = 5;

Listing 7: Repeat offenders — criminals with more than one crime

SELECT cr . criminal_id , cr . first_name , cr . last_name ,
cr . status , COUNT ( cc . crime_id ) AS total_crimes
FROM CRIMINAL cr
JOIN CRIMINAL_CRIME cc ON cr . criminal_id = cc . criminal_id
GROUP BY cr . criminal_id
HAVING total_crimes > 1
ORDER BY total_crimes DESC ;

Listing 8: Area-wise crime count

SELECT l . city , l . district , COUNT ( c . crime_id ) AS total_crimes
FROM CRIME c
JOIN LOCATION l ON c . location_id = l . location_id
GROUP BY l . city , l . district
ORDER BY total_crimes DESC ;

16
Criminal Database and Crime Analysis DBMS Project (CS254)

Listing 9: Officer performance — cases handled per officer

SELECT o . officer_id , o . first_name , o . last_name ,
o . department , COUNT ( oc . crime_id ) AS cases_handled
FROM OFFICER o
LEFT JOIN OFFICER_CRIME oc ON o . officer_id = oc . officer_id
GROUP BY o . officer_id
ORDER BY cases_handled DESC ;

DCL — Data Control Language

Listing 10: Grant and restrict database privileges
-- Grant read - only access to analyst role
GRANT SELECT ON dbms_project .* TO ’ analyst_user ’@ ’ localhost ’;

-- Grant full access to admin

GRANT ALL PRIVILEGES ON dbms_project .* TO ’ admin_user ’@ ’ localhost ’
;

-- Revoke delete privilege from officer role

REVOKE DELETE ON dbms_project .* FROM ’ officer_user ’@ ’ localhost ’;

FLUSH PRIVILEGES ;

5.5 Application Screenshots

The following screenshots demonstrate the working frontend of the Criminal Database
and Crime Analysis System, showing all major modules connected to the live MySQL
backend.

Figure 4: Landing Page — Hero section with system title, stats (17 tables, 26 relation-
ships, 3NF), and entry buttons

17
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 5: Landing Page — Features section showing all major system modules

Figure 6: Login Page — JWT-authenticated sign-in with role display (Admin, Officer,
Investigator, Analyst)

18
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 7: Registration Page — Two-step account creation form with role selection and
Officer ID linking

Figure 8: Main Dashboard — Live summary statistics (Total Crimes, Criminals, Arrests,
Evidence, Suspects, Victims) fetched from MySQL

19
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 9: GIS Crime Map — Interactive [Link] map displaying crime location markers
loaded from the LOCATION table (latitude/longitude)

Figure 10: FIR Reports Page — Admins can view all submitted reports from all users;
civilians can only view their own reports (role-based filtering)

20
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 11: Officer Management Page — View all officers with badge number, name, rank,
department, and contact. Admin users can add new officers

Figure 12: Arrest Records Page — Searchable and filterable arrest records with officer
name, crime type, date/time, and incident details

21
Criminal Database and Crime Analysis DBMS Project (CS254)

Figure 13: Crime Records Page — All registered crimes with type, date, time, location,
linked criminals and officers. Clicking a row opens the detailed crime view

Figure 14: Register FIR Page — Any user can file a First Information Report. The report
is reviewed by an officer; once validated, it is added to Crime Records and officers are
assigned for investigation

6. Conclusion and Future Work

6.1 Summary of the Project
The Criminal Database and Crime Analysis System successfully demonstrates the prac-
tical application of relational database management concepts in building a structured,
secure, and functional law enforcement data system. The system was implemented using
a three-tier architecture with [Link] on the frontend, [Link] and [Link] on the
backend, and MySQL as the relational database.

22
Criminal Database and Crime Analysis DBMS Project (CS254)

The database schema, consisting of 17 tables and 26 foreign key relationships normalised
to 3NF, provides a robust foundation for storing and retrieving crime-related data with
full referential integrity. The system supports role-based access control through JWT au-
thentication, manages complex many-to-many relationships through junction tables, and
provides analytical capabilities through structured SQL queries and a reporting dash-
board.
Key modules successfully implemented include crime record management, criminal pro-
filing, suspect and victim tracking, arrest and evidence management, officer assignment,
GIS-based crime mapping, and crime analysis reporting.

6.2 Limitations
• The system has not been tested at production scale with thousands of concurrent
users.
• Real-time integration with national databases such as CCTNS is not implemented.
• The GIS crime map uses static coordinates and does not support live tracking.
• Mobile application support is not available in the current version.
• Advanced features such as facial recognition, biometric identification, and predictive
crime modelling are outside the current scope.

6.3 Future Enhancements

• Mobile Application: Develop a React Native mobile app to allow officers to access
and update records from the field.
• AI-based Crime Prediction: Integrate machine learning models to predict crime
hotspots and identify patterns from historical data.
• CCTNS Integration: Connect the system to India’s national Crime and Criminal
Tracking Network for real-time inter-agency data sharing.
• Biometric Authentication: Add fingerprint or facial recognition for criminal iden-
tification and officer login.
• Real-time Notifications: Implement WebSocket-based alerts for new crime regis-
trations, suspect matches, and case status updates.
• Advanced Analytics: Integrate data visualisation tools such as [Link] or [Link]
for deeper crime trend analysis and heatmap rendering.
• Audit Logs: Maintain a complete audit trail of all data modifications for account-
ability and forensic review.

7. References
1. Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems, 7th
Edition, Pearson Education, 2016.

23
Criminal Database and Crime Analysis DBMS Project (CS254)

2. Abraham Silberschatz, Henry F. Korth, and S. Sudarshan, Database System Concepts,

7th Edition, McGraw-Hill, 2019.
3. S. Chainey and J. Ratcliffe, GIS and Crime Mapping, John Wiley and Sons, London,
2005.
4. O. Kounadi, A. Ristea, A. Leitner, and M. Langford, “A Systematic Review of Spatial
Crime Forecasting,” Crime Science, vol. 9, no. 1, 2020.
5. National Crime Records Bureau (NCRB), Crime in India — Annual Report 2022,
Ministry of Home Affairs, Government of India. [Link]
6. Ministry of Home Affairs, Government of India, Crime and Criminal Tracking Net-
work and Systems (CCTNS) Project Document, 2009. [Link]
7. X. Wang, D. E. Brown, and M. S. Gerber, “Spatio-Temporal Modeling of Criminal
Incidents,” IEEE International Conference on Intelligence and Security Informatics,
2013.
8. Ethan Brown, Web Development with Node and Express, 2nd Edition, O’Reilly Media,
2019.
9. Stoyan Stefanov, React: Up and Running, 2nd Edition, O’Reilly Media, 2021.
10. OWASP Foundation, OWASP Top Ten Security Risks, 2021. [Link]
www-project-top-ten
11. MySQL Documentation, MySQL 8.0 Reference Manual, Oracle Corporation, 2023.
[Link]

24