Inventory Management System Database Analysis and

Recommendations
Executive Summary:

This report provides a detailed analysis of the inventory management system's

database design, development practices, and security measures based on the
provided codebase. The system demonstrates several positive attributes, including
adherence to Third Normal Form (3NF) in its database schema, the implementation of
robust password hashing using PHP's password_hash() function, and the utilization of
prepared statements to mitigate the risk of SQL injection attacks. These features
indicate a foundational understanding of database design and security principles.
However, the analysis also identifies areas where enhancements can be implemented
to further optimize performance, strengthen security, and improve development
collaboration practices. Key recommendations include adding more detailed
constraints and comments to the DDL scripts, implementing indexes on frequently
searched columns to boost query performance, establishing a comprehensive user
roles and permissions system for granular access control, enforcing session timeout
to prevent unauthorized access, limiting database access privileges for the
application, implementing thorough output sanitization to prevent Cross-Site
Scripting (XSS) vulnerabilities, and improving the documentation of Git usage and
database change communication within the development team. Addressing these
recommendations will contribute to a more efficient, secure, and maintainable
inventory management system.

Database Design and Schema Definition:

Entity Relationship Diagram (ERD):

The foundation of any robust database system lies in its well-defined structure, which
is often visualized through an Entity Relationship Diagram (ERD). An ERD serves as a
blueprint, illustrating the different entities within the system and the relationships
between them.1 In the context of the inventory management system, several key
entities are evident. The users table stores information about individuals who can
access the system, with attributes such as id serving as a unique identifier, username
for login purposes, password for authentication, and created_at to track account
creation.3 The items table, on the other hand, holds details about the inventory itself,
including a unique id, the name of the item, its current quantity, and timestamps for
when it was created_at and last updated_at.6
Considering the potential growth and evolving needs of the inventory management
system, several future tables can be anticipated. A categories table, with attributes
like id and name, would allow for the organization of items into logical groupings.8 The
introduction of a transactions table, potentially including attributes like id, item_id
(referencing the items table), user_id (referencing the users table), quantity,
transaction_type (e.g., purchase, sale, restock), and transaction_date, would provide
a historical record of inventory movements.1 Furthermore, a suppliers table,
containing information such as id, name, and contact_info, would enable the tracking
of item sources.3

A crucial relationship within this data model is the connection between categories
and items. A single category can contain multiple items, while each item belongs to
only one category. This represents a one-to-many relationship, which can be
implemented by adding a category_id as a foreign key in the items table, referencing
the id in the categories table.5 Standard ERD notation would represent these entities
as rectangles, their attributes as ovals connected to the respective entities, and the
relationships as lines with appropriate cardinality symbols indicating the one-to-many
connection between categories and items.7 This visual representation clarifies the
logical structure of the database, aiding in its design and understanding.10

DDL Script Analysis and Enhancements:

The provided DDL script for the users table offers a foundational structure for storing
user data.11 However, expanding on this script with more detailed constraints and
comments can significantly enhance the database's integrity and maintainability.12 For
instance, specifying the length of the username column using VARCHAR(50) explicitly
defines the maximum allowed characters, preventing overly long usernames and
potential data truncation issues.13 Additionally, while a default value is set for the
created_at timestamp, adding a NOT NULL constraint would ensure that this crucial
information is always recorded upon user creation.14

Incorporating comments within the DDL scripts is a best practice that greatly
improves their readability and understanding, especially for developers who may be
new to the project or revisiting the code after a period.15 Explaining the purpose of
each constraint, such as the PRIMARY KEY constraint ensuring uniqueness and the
NOT NULL constraint enforcing data presence, clarifies the schema's intent.16

To illustrate how the potential future tables could be defined, consider the following
example DDL scripts:
 SQL

CREATE TABLE IF NOT EXISTS categories (

id INT AUTO_INCREMENT PRIMARY KEY COMMENT 'Unique identifier for categories',
name VARCHAR(100) NOT NULL UNIQUE COMMENT 'Name of the category'
);

CREATE TABLE IF NOT EXISTS transactions (

id INT AUTO_INCREMENT PRIMARY KEY COMMENT 'Unique identifier for transactions',
item_id INT NOT NULL COMMENT 'Foreign key referencing the items table',
user_id INT NOT NULL COMMENT 'Foreign key referencing the users table',
quantity INT NOT NULL COMMENT 'Quantity of items in the transaction',
transaction_type VARCHAR(20) NOT NULL COMMENT 'Type of transaction (e.g., purchase,
sale)',
transaction_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT 'Timestamp of the
transaction',
FOREIGN KEY (item_id) REFERENCES items(id),
FOREIGN KEY (user_id) REFERENCES users(id)
);

CREATE TABLE IF NOT EXISTS suppliers (

id INT AUTO_INCREMENT PRIMARY KEY COMMENT 'Unique identifier for suppliers',
name VARCHAR(100) NOT NULL UNIQUE COMMENT 'Name of the supplier',
contact_info VARCHAR(255) COMMENT 'Contact information for the supplier'
);

These scripts include primary keys, foreign key constraints to establish relationships
between tables (e.g., item_id in transactions referencing items), NOT NULL
constraints where appropriate, and comments explaining the purpose of each field
and constraint.17

Following best practices for writing DDL scripts ensures a well-structured and
maintainable database schema.11 This includes using uppercase for SQL keywords like
CREATE TABLE and PRIMARY KEY to improve readability.12 Consistent naming
conventions for tables and columns, such as using plural nouns for table names (e.g.,
users, items, categories) and descriptive names for columns, contribute to clarity.14
Organizing related DDL statements within the same script file and using indentation
to structure the code also enhance maintainability.15

Database Performance Optimization Strategies:

Indexing Implementation:

The current codebase implements indexes on the username column of the users table
and the name column of the items table.21 These indexes serve to optimize query
performance for frequently executed operations.22 The index on users(username)
likely aims to speed up user lookups during the login process, as usernames are
typically used to identify users.23 Similarly, the index on items(name) would accelerate
searches for specific items by their name, a common operation in inventory
management.24 By creating these indexes, the database can locate the relevant rows
much faster than performing a full table scan.25

To further enhance performance, additional indexes on other frequently queried

columns should be considered. For example, if users often browse inventory by
category, adding an index to items(category_id) would significantly speed up the
retrieval of items belonging to a specific category.27

It is important to acknowledge the trade-offs associated with indexing.29 While

indexes greatly improve the speed of read operations (queries), they can introduce
overhead on write operations such as inserts, updates, and deletes.30 This is because
the database engine must also update the corresponding index entries whenever the
underlying data changes.31 Therefore, a balance must be struck between optimizing
query performance and maintaining acceptable write speeds.32

Different types of indexes exist, each suited for specific use cases.33 The most
common type is the B-tree index, which is efficient for equality and range-based
searches on sortable columns.34 Hash indexes, on the other hand, are optimized for
equality comparisons on columns with unique values.35 Understanding these different
index types allows for a more targeted approach to performance optimization.36

Data Normalization Assessment:

The codebase description correctly states that the current schema already follows
3NF (Third Normal Form).40 Database normalization is a process of organizing data in
a database to reduce redundancy and improve data integrity.41 It involves applying a
series of normal forms to structure the database tables effectively.42

Third Normal Form (3NF) is achieved when a database schema meets the
requirements of the first and second normal forms, and additionally, all non-key
attributes are non-transitively dependent on the primary key.43 This means that every
non-key column in a table depends directly on the primary key and not on any other
non-key column.44

The benefits of adhering to 3NF are numerous.45 It minimizes data redundancy by

ensuring that each piece of information is stored only once, reducing the storage
space required and the potential for inconsistencies.46 It also improves data integrity
by making it easier to maintain the accuracy and consistency of the data.47
Furthermore, normalized tables are generally easier to query and manage.48 By
eliminating transitive dependencies, 3NF helps prevent update anomalies, where
changes to one attribute might unintentionally affect other unrelated attributes.51
While higher normal forms exist, 3NF is often considered a good balance between
data integrity and query performance for most transactional systems.60

Security Considerations and Implementation Analysis:

Password Security:

The current implementation utilizes PHP's password_hash() function for storing user
passwords securely.61 This function is a significant improvement over older, less
secure hashing algorithms like MD5 or SHA1.62 password_hash() employs strong, one-
way hashing algorithms, with bcrypt being the default as of PHP 5.5.0.63 These
algorithms are designed to be computationally expensive, making it significantly
harder for attackers to brute-force or reverse the hashes to obtain the original
passwords.64

A key security feature of password_hash() is its automatic generation of a random

salt for each password.65 A salt is a unique, random string that is combined with the
password before hashing. This prevents attackers from using pre-computed "rainbow
tables" to crack common passwords.66 The salt, along with information about the
hashing algorithm and cost factor used, is stored directly within the hash itself,
simplifying the password verification process using password_verify().67

To further enhance password security, implementing password complexity

requirements is recommended.69 This involves enforcing rules on the length and
composition of passwords, such as requiring a minimum number of characters and
the inclusion of a mix of uppercase letters, lowercase letters, numbers, and special
symbols.70 While the National Institute of Standards and Technology (NIST) guidelines
have evolved to emphasize length over strict complexity rules, a balance can be
struck to encourage users to create strong, unique passwords.71 Additionally, while
not directly supported by password_hash(), considering the use of a "pepper" – a
secret, application-wide key that is combined with the password before hashing –
can add an extra layer of defense against certain types of attacks.63

SQL Injection Prevention:

The codebase effectively uses prepared statements with parameter binding in

auth_api.php and signup.php, as demonstrated by the example $stmt-
>bind_param("ss", $username, $hashed_password);.12 Prepared statements are a
crucial security measure against SQL injection attacks.13 In a prepared statement, the
SQL query structure is defined first, with placeholders for the actual data values.14
The user-provided data is then bound to these placeholders separately.15 This
separation prevents malicious SQL code from being injected into the query and
executed, as the database treats the bound parameters purely as data rather than
executable commands.16 Ensuring that all database interactions within the application
utilize prepared statements is vital for maintaining a secure system.17

User Roles and Permissions System:

The current implementation includes a user_roles table with id and role_name

columns, and a role_id column has been added to the users table.81 This lays the
groundwork for a role-based access control (RBAC) system.82 RBAC is a method of
restricting network access based on the roles of individual users within an
organization.83 Instead of assigning permissions directly to each user, permissions are
associated with roles, and users are then assigned to one or more roles based on
their job functions and responsibilities.84

Implementing a comprehensive RBAC system offers numerous benefits for the

inventory management system.86 It simplifies permission management, as
administrators can manage access by assigning users to appropriate roles rather
than configuring individual permissions.90 It also enhances security by enforcing the
principle of least privilege, ensuring that users only have the necessary permissions
to perform their assigned tasks, thereby reducing the risk of unauthorized access or
accidental modifications.91 Different roles, such as "administrator," "inventory
manager," or "reporting user," can be created, each with specific permissions to view,
create, edit, or delete inventory items, manage users, or generate reports.85 This
granular control over access is essential for maintaining the integrity and
confidentiality of the system's data.99

Further Security Enhancements:

Several additional security measures can be implemented to further protect the

inventory management system:
● Session Timeout: Implementing session timeout functionality is crucial for
automatically terminating user sessions after a period of inactivity.100 This
reduces the risk of session hijacking, where an attacker could potentially gain
unauthorized access to a user's account if they leave their session unattended.102
Configuring a reasonable timeout period, such as 30 minutes or an hour, can
balance security with user convenience.100 This can be implemented using PHP's
session management functions or by configuring the application's framework.110
● Database Access Controls: Instead of using a privileged database user like root
for the application's database connections, creating custom database users with
limited permissions is a significant security enhancement.81 These users should
only be granted the specific privileges necessary for the application to function,
such as SELECT, INSERT, UPDATE, and DELETE on the required tables.82 This
principle of least privilege minimizes the potential damage in the event of a
database breach, as the attacker would only have access to the limited
permissions granted to the application's database user.85
● Stored Procedures: Implementing stored procedures for sensitive database
operations can add an extra layer of security and abstraction.14 Stored
procedures are pre-compiled SQL code stored in the database that can be
executed by the application.15 They can help prevent SQL injection by
encapsulating the database logic and reducing the need for dynamic SQL queries
within the application code.16
● Cross-Site Scripting (XSS) Prevention: Cross-Site Scripting (XSS) is a web
security vulnerability that allows attackers to inject malicious scripts into web
pages viewed by other users.119 To prevent XSS attacks, it is strongly
recommended to implement htmlspecialchars() for all user-generated content
that is displayed in the frontend.128 This function converts special HTML
characters (like <, >, &, ", ') into their corresponding HTML entities, which are
rendered as plain text by the browser, preventing the execution of malicious
scripts.135 Ensuring that this output sanitization is applied consistently across the
entire application is crucial for protecting users from XSS vulnerabilities.138
Development Collaboration and Version Control with Git:

Git Usage Documentation:

Documenting how the codebase utilizes Git for version control is essential for
effective team collaboration and project maintainability.147 This documentation should
clearly outline the following aspects:
● Repository Location: Specify the platform hosting the Git repository, such as
GitHub, GitLab, or Bitbucket.149 Knowing the central location of the codebase is
fundamental for all team members.
● Branching Strategy: Detail the branching strategy employed by the team.153
Common strategies include Gitflow, GitHub Flow, and Feature Branching.155
Explain the purpose of different branches (e.g., main or master for stable
releases, develop for ongoing development, feature branches for new features,
hotfix branches for bug fixes) and how they are used.167
● Commit Message Conventions: Define the commit message conventions that
the team follows.169 Consistent and informative commit messages provide a clear
history of changes, making it easier to understand the purpose and context of
each modification.171 This should include guidelines on the subject line length, the
use of imperative mood, and the inclusion of a more detailed body when
necessary.177
● Branch Usage for Development: Explain how branches are used for different
stages of development, including feature implementation, bug fixing, and
preparing for releases.167 This should cover the process of creating branches,
merging changes, and handling merge conflicts.195

Demonstration of Collaborative Development:

Evidence of collaboration in the development of the authentication and user

registration systems can be demonstrated by analyzing the project's Git history.
Examining the commit logs for auth.js, auth_api.php, signup.php, and signup.html can
reveal contributions from different developers, identified by their commit author
information.167 The use of pull requests for code review and merging is another key
indicator of collaborative development practices.195 Pull requests facilitate
discussions and feedback on proposed code changes before they are integrated into
the main codebase.200 Highlighting any comments, reviews, or discussions that took
place within these pull requests would further illustrate the collaborative nature of the
development process.
Communication of Database Changes:

Explaining how database schema changes were communicated to frontend

developers is crucial for understanding the team's workflow and ensuring seamless
integration between the frontend and backend.14 Effective communication can involve
various channels, such as dedicated communication platforms like Slack or Microsoft
Teams, email correspondence, or regular team meetings.15 Documentation updates,
including changes to README files or the creation of database schema diagrams,
also play a vital role in keeping frontend developers informed about modifications to
the database structure.16

Best practices for communicating database changes include providing clear and
concise descriptions of the changes, explaining the purpose behind them, and
outlining any potential impact on the frontend application.17 This proactive
communication helps frontend developers understand how the changes might affect
their code and allows them to make necessary adjustments in a timely manner.18
Establishing a clear process for communicating these changes ensures that all team
members are aligned and reduces the likelihood of integration issues.19

IT Security Risk Assessment:

Based on the codebase analysis, the following table summarizes the current security
measures in place, assesses the residual risks, and provides recommendations for
enhancement:

Security Area Current Recommended Benefit Snippet

Implementatio Enhancement Evidence
n

SQL Injection Prepared Ensure all Prevents 12

Prevention statements database injection of

used in interactions malicious SQL
auth_api.php utilize prepared code.
and signup.php statements.

Password password_hash( Implement Prevents weak 61 80

-
Security ) used password passwords;
complexity Adds an extra
 requirements; layer of defense
Consider adding against attacks.
a "pepper".

Session Session-based Implement Reduces the risk 100 109

-
Management authentication session timeout of session
in index.php with a hijacking.
reasonable
duration.

Database Not explicitly Create custom Minimizes the 81 89

-
Access Controls defined database users impact of a
with limited potential
permissions. database
breach.

Cross-Site Minimal output Implement Prevents the 119 146

-
Scripting (XSS) sanitization htmlspecialchar execution of
s() for all user- malicious
generated scripts in users'
output. browsers.

The identified risks can be categorized based on severity and likelihood. SQL injection
and XSS vulnerabilities are generally considered high-severity risks due to their
potential to compromise sensitive data and user accounts. Weak password policies
and inadequate session management also pose significant risks. Implementing the
recommended enhancements in a prioritized manner, starting with the highest-
severity risks, will significantly improve the overall security posture of the inventory
management system.

Conclusion:

The inventory management system demonstrates a solid foundation in database

design and security, particularly with its adherence to 3NF, the use of
password_hash(), and the implementation of prepared statements. These are
commendable practices that contribute to the system's robustness. However, this
analysis has also highlighted several key areas where further improvements can be
made. Enhancing the DDL scripts with more detailed constraints and comments will
improve data integrity and maintainability. Implementing indexes on frequently
searched columns will lead to noticeable performance gains in query execution.
Establishing a comprehensive user roles and permissions system will provide granular
control over access and enhance security. Enforcing session timeout, limiting
database access, and implementing thorough XSS prevention measures are crucial
steps in fortifying the application against common web vulnerabilities. Furthermore,
improving the documentation of Git usage and database change communication will
foster better collaboration within the development team. By addressing these
recommendations, the inventory management system can achieve a higher level of
performance, security, and maintainability, ultimately leading to a more reliable and
robust application.