r-

DBMS Mini Project

Bachelor of Technology
In
Computer Science and Engineering

Under esteemed Guidance Ms. P. Spandana Valli

Asst. Professor
Dept.of CSE

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

AND., lfEERUKONDA INSTITUTE OF TECHNOLOGY AND SCIENCES
SANGIVALASA. VISIIAKIIAPATNAM
="''
~--
Projccl:Sporls M111111gcrncnt System
Mcm~n :
A.Va1>hi1ha(A2112r,510005)

M.Gnana Anusha(/\2112<,5100)8)

M.lukcsl~ /\2112651 0042)

Table of Contents:

'I •

. _.,..
....,._
........,.............,...
.cw, . . . . :.. ioe
 Bonafidc Certificate
This is to certify that this project repon "Hole! Management System" is the bonalide
WOl"k or A.Vanhith a (A2 l 1265 I 0005) , M.Anusha(A2l l 265 I0038) and
M.Rakesh(A21126510042).
Thia project is canicd out and Is submitted in the partial rulfilment or 1hc
requirements for the award of BACHELOR OF TECHNOLOGY in Computer
Scjencc and Engineering. under Anil Nccrukonda lnstitulc orTcc:hnology and
Scimc a during lhc academic year 2022-2023.

Dr.Ramakrishna Murthy
Head or Department
Prore$SO<
Department or CSE
ANITS

MLP.~i
PN>Jectauide
ASSISTANT PROFESSOR
~of CSB
ANl'l'S
Acknowledgement:
The satisfaction that accompanies the successful
completion of any task
would be incomplete without mentioning the people
who made it possible.
and whose constant guidance and encouragement alw
ays upheld the morale.
We take a great pleasure in presenting a project,
which is the result of a
studied blend of both resean:h and knowledge.
We first take the privilege to thank the hea
d of our department Dr.
Ramakrishna Murthy, for pcnnitting us in layi
ng the first stone of success.
We feel giateful to thank SPANDANA VALLI Ma
dam, who is our project
guide and who shared her valuable knowledge
with us and made us
understand the real essence of the topic and created
interest in us to put our
continuous efforts in lhc project.

A.Vanhitha(A21126510005)

M.Anusha(A2 I I 265 l 0038)

M.RAkcsh(A21126510042)
Declaration:

This is lo certify th3l the project work entitled ..Sports Mangcmcnt Syste
m"
is a Don3fcdc work carried out by ns 3 part of BTcch 3rd year Ist seme
ster
or Computer Science and Engineering of Anil Nccrukonda Institute
of
Technology and Sciences, Vishaklu!patnam during the academic year 202)
2024
·
.
We A. Varshitho,M.Anusha,M.Rakcsh of 3rd year DTECH, Departme
nt of
Computer Science and engineering from ANITS, Vishakhapatnam, hereb
y
declare that the project work entitled ..Sports Management System"
is
carried out by us and is submitted in the fulfilment of the requirement
for
the award ofBachclorofTcchnology in Computer Science and Engineeri
ng.
under Anil Nccrukonda Institute of Technology and Sciences durin
g the
academic year 2023•2024 has not been submitted to any other university
for
lhe award ofany kind of dcgm:.

A.Vanhitha(A21126S1000S)

M.Anushl(A21126S100l8)

M.Rakcsh(A21126S100-l2)
 DEFINITIONS

E-R model:
An entity relationship model, also called an entity-relationship (ER) diagram, is a graphical
representation of entities and their relationships to each other, typically used in computing in
regard to the organization of data within databases or information systems.

Entity Sets:
The Entity Set is a set of entities of the same type, that share the same properties or
Attributes.
Ex : Persons having an account at bank. or Each student having Admission Number.The set
of all students in a class., can be defined as the entity-set. Similarly, the entity set Admission
might represent the set of all admission awarded by a particular university.

Attributes :
Each entity has certain characteristics knows as attributes. The attributes
can be classified into-
1. Simple attributes
2. Complex/ composite attributes
3. Single – valued attributes
4. Multi - valued attributes
5. Derived attribute
6. Null Attribute
An attribute, as used in the E – R model, can be characterized by the following attribute
types.
• Simple attributes: The attributes have been simple; that is, t h e y h a v e not been
divided into subpart.
Example : Student class Roll Number.

• Composite attributes : The attributes, which can be sub divided into sub parts.
Example : Student Name, Which can be divided in parts like First name, Middle name and Last
name. Note also that a composite attribute may appear as a hierarchy. In the
composite attribute address, its component attribute street can be further divided into
street_number, street_name, and Door _ number etc.

• Single valued attributes : The attribute which contain/ accept only one value/character.
Example Sex : Male or Female
Marital status : Married or Unmarried

• Multi valued attributes : The attributes which has set of values for a specific entity. in our
example all have a single value for a particular entity.
Example 1 : Number of dependents in a family may 0,1,2,3,4.....
Example 2 : A student may have several phone numbers, and different students may have
different numbers of phones.

• Derived attribute : The value of this type of attribute can be derived from the values of other
related attributes or entities. The value of a derived attribute is not stored but is computed when
required.

• Null Attributes : An attribute takes a null value when an entity does not have a value for it.
The null value may indicate “not applicable” – that is, that the value does not exist for the
entity.
Relationship Sets:
A Relationship is an association among several entities.
For example,we can define a relationship between student entity and bank
account entity.The student named Rahul having bank account in HDFC
,Malplaquet branch with an account number A-101.

Mapping Constraints:
Mapping Personalities, or carnality ratios, express the number of entities to which another
entity can be associated via a relationship etc.
Mapping Personalities are most useful in describing binary relationship sets, although they can
contribute to the description of relationship sets that involve more than two entity sets.
For a binary relationship set R between entity sets A and B, the mapping carnality must be one
of the following.

There are 4 types of mapping personalities.

1. ONE – to – ONE Relationship

2. MANY – to – MANY Relationship
3. ONE – to – MANY Relationship
4. MANY – to – MANY Relationship

Relational Model Concepts

1. Attribute: Each column in a Table. Attributes are the properties which define a
relation. e.g., Student_Roll no, NAME,etc.

2. Tables – In the Relational model the, relations are saved in the table format.
It is stored along with its entities. A table has two properties rows and columns. Rows
represent records and columns represent attributes.

3. Tuple – It is nothing but a single row of a table, which contains a single record.
4. Relation Schema: A relation schema represents the name of the relation with its
attributes.

5. Degree: The total number of attributes which in the relation is called the degree of
the relation.

6. Cardinality: Total number of rows present in the Table.

7. Column: The column represents the set of values for a specific attribute.
8. Relation instance :Relation instance is a finite set of tuples in the RDBMS system.
Relation instances never have duplicate tuples.

9. Relation key : Every row has one, two or multiple attributes, which is called relation key.
10. Attribute domain : Every attribute has some per-defined value and scope which is
known as attribute domain

An E-R diagram can express the overall logical structure of a

database graphically. E-R
diagrams are simple and clear – qualities that may well account in large part for
the
widespread use of the E-R model. Such diagram consists of the following major
components.
An E-R diagram can express the overall logical structure of a
database graphically. E-R
diagrams are simple and clear – qualities that may well account in large part for
the
widespread use of the E-R model. Such diagram consists of the following major
components.

• Rectangles : Which represent entity sets.

• Ellipses : Which represent attributes
• Diamonds : Which represent relationship sets
• Lines : Which link attributes to entity sets and entity sets to relationship sets
• Double ellipses : Which represents multi valued attributes
• Dashed ellipses : Which denote derived attributes.
• Double Lines : Which indicate total participation of an entity in relationship set.
• Double Rectangles : Which represent weak entity sets
ER_DIAGRAM
--
LIST OF ETITIES,ATTRIBUTES AND RELATIONSHIP SET

1. ENTITY SET:
A. COACH
B. TEAMS
C. PLAYERS
D. MATCHES
2. WEAK ENTITY SET:
A.SCORE
3. MULTI-VALUED ATTRIBUTES:
A. COACH_NAME
B. POSITION
4. ATTRIBUTES:
A. TEAM_ID
B. COACH_NAME
C. EXPERIENCE
D. COACH_AGE
E. ATTRIBUTE
F. TEAM_NAME
G. HOME_GROUND
H. PLY_NAME
I. GROUND
J. DATE
K. MATCH_TEAM_ID
L. AWAY_TEAM_ID
M. MATCH_ID
N. HOME_SCORE
O. AWAY_SCORE
P. WIN_TEAM
5. RELATIONSHIP SET:
A. COACH AND PLAYERS(MANY-TO-MANY)
B. TEAMS AND MATCHES(ONE-TO-MANY)
6. PRIMARY KEYS:
A. COACH_ID
B. TEAM_ID
C. MATCH_ID
D. PLY_ID
 RELATION SCHEMA
1. teams (team_id INT PRIMARY KEY, teamname VARCHAR2(25) NOT
NULL, homeGround VARCHAR2(25) primary key, coachName
VARCHAR2(25) NOT NULL,established_year int);
2. coach (team_id INT NOT NULL, coachId INT PRIMARY KEY,
coachName VARCHAR2(25) NOT NULL, Experience NUMBER(2) NOT
NULL, coachAge NUMBER(2) NOT NULL);
3. TABLE match (match_id INT PRIMARY KEY, home_team_id INT NOT
NULL,Ground VARCHAR2(25) NOT NULL, Match_Date
VARCHAR2(10) NOT
NULL, Away_team_id INT NOT NULL);
4. players (player_id INT PRIMARY KEY,player_name VARCHAR2(25)
NOT NULL, position INT NOT NULL, team_id INT NOT NULL);
5. score (match_id INT NOT NULL, home_score INT NOT NULL,away_score
INT NOT NULL, win_team VARCHAR2(20) NOT NULL)";
Requirements:

The project requires the following components:

Database Management System (DBMS): MySQL (version

8.0.35) is utilized to store and manage the hotel's data,
including customer information, bookings, reservations,
services, and transactions

. Programming Language:

The system is implemented using SQL for database

operations.

User Interface (UI):

A user-friendly interface is essential for hotel staff to interact

with the system easily. UI design principles should prioritize
efficiency and clarity.

Security Measures:

Implement security features to safeguard sensitive customer

information and financial transaction.
Database:

• MySQL: MySQL is a relational database management

system based on SQL – Structured Query Language. ... The
most common use for MySQL however, is for the purpose of
a web database. It can be used to store anything from a single
record of information to an entire inventory of available
products for an online store.
Code used for implementation: Tables Creation: Collect data
manually and create Database /Insert the values Perform all
the Various SQL Commands Operations. Print out the Tables.
Display the Tables.
 Tables Creation:
Teams table creation-
create table teams(team_id int,team_name varchar(25),coach_id int,coach_name
varchar(20),home_city varchar(25),established_year int);
ALTER table teams add PRIMARY key(team_id,home_city);

Desc teams;

Coaches table creation-

create table coach(team_id int,coach_id int primary key,coach_name
varchar(25),experience int,coach_age int,foreign
key(team_id)refrences teams(team_id));

Desc coaches;

Match table creation-

Create table match_table(match_id int primary key,home_team_id
int,away_team_id int,home_ground varchar(25),match_date varchar(25))

Desc match_table;
Players table creation-
Create table players(player_id int primary key,player_name
varchar(25),team_id int,position int,age int);

DESC PLAYERS;

SCORES TABLE CREATION-

create table scores(match_id int not null,home_score int
not null,away_score int not null,win_team varchar(20) not
null);

Query OK, 0 rows affected (0.03 sec)

DESC SCORES;
INSERTION OF VALUES

FOR TEAMS TABLE:

insert into
teams(team_id,team_name,coach_id,coach_name,home_city,e
stablished_year)values(1,'teamA',101,'ca','stadiumA',2000),(1,'
TeamA',101,'CA','st
adiumB',2000),(2,'teamB',102,'cb','stadiumC',2005),(3,'teamc',1
03,'cc','stadiumA',2001),(3,'teamc',103,'cc','stadiumc',2001);

Query OK, 5 rows affected (0.02 sec)

Records: 5 Duplicates: 0 Warnings: 0

FOR COACH TABLE:

insert into
coach(team_id,coach_id,coach_name,experience,coach_age)va
lues(1,101,'c1',5,40),(2,102,'c2',8,45),(3,103,'c3',3,38),(1,102,'c2
',8,45),(1,1
01,'c1',5,40),(2,103,'c3',3,38);

Query OK, 6 rows affected (0.02 sec)

Records: 6 Duplicates: 0 Warnings: 0
FOR MATCH TABLE:
insert into
match_table(match_id,home_team_id,ground,match_date,aw
ay_team_id)values(1,101,'sa','2023-01-
15',102),(2,103,'sb','2023-02-20',104),(3,105,'sc','2023-03-
25',106),(4,106,'sd','2023-04-12',109);

Query OK, 4 rows affected (0.01 sec)

Records: 4 Duplicates: 0 Warnings: 0

FOR PLAYERS TABLE:

insert into
players(player_id,player_name,team_id,position,age,team_n
ame)values(1,'john',101,1,16,'teamA'),(2,'jane',102,3,27,'tea
mb'),(3,'bob',101,2,28,'teamA'),(4,'martin',102,1,29,'teamB');

Query OK, 4 rows affected (0.01 sec)

Records: 4 Duplicates: 0 Warnings: 0

FOR SCORES TABLE:

insert into
scores(match_id,home_score,away_score,win_team)va
lues(1,3,1,'uni'),(2,5,1,'pol'),(3,2,4,'uff');

Query OK, 3 rows affected (0.02 sec)

Records: 3 Duplicates: 0 Warnings: 0
DISPLAYING TABLES:

TEAMS TABLE
SELECT * FROM TEAMS;

COACH TABLE
SELECT * FROM COACH;
MATCH TABLE
SELECT * FROM MATCH_TABLE;

PLAYERS TABLE
SELECT * FROM PLAYERS;

SCORES TABLE
SELECT * FROM SCORES;
 FUNCTIONAL DEPENDENCIES
Functional dependencies are a concept in the
field of database design and normalization. They
describe the relationship between attributes
(columns) in a relational database.
In other words, if you have a functional dependency
X -> Y, it means that knowing the values of
attributes in set X will uniquely determine the
values of attributes in set Y.

Here are some key terms related to functional

dependencies:

1. **Determinant:**
- The attribute or set of attributes on the left side of
the arrow (->) is called the determinant. In X -> Y, X
 is the determinant.

2. **Dependent:**
- The attribute or set of attributes on the right side
of the arrow (->) is called the dependent. In X -> Y,
Y is the dependent.

3. **Fully Functional Dependency:**

- A functional dependency X -> Y is fully functional if
removing any attribute from X means the
dependency no longer holds.

4. **Transitive Dependency:**
- If X -> Y and Y -> Z, then there is a transitive
dependency X -> Z. Transitive dependencies should
be eliminated for a relation to be in a higher
normal form.

5. **Partial Dependency:**
- A partial dependency occurs when a non-prime
(not part of any candidate key) attribute is
functionally dependent on a part (proper subset) of
a candidate key.
Functional dependencies play a crucial role in the normalization process,
where the goal is to organize data in a way that avoids redundancy
and anomalies. The normalization process involves decomposing
relations into smaller relations to eliminate undesirable dependencies
and ensure that the resulting database schema is in a desired normal
form.

FUNCTIONAL DEPENDENCIES FOR THE

ABOVE TABLE:

TEAMS TABLE-:
THE POSSIBLE CANDIDATE KEYS FOR THE TEAMS TABLE ARE -
-TEAMiD,HOME_GROUND
-TEAM_NAME,HOME_GROUND
-COACH_ID,HOME_GROUND
-COACH_NAME,HOMEGROUND
-ESTABLISHED_YEAR,HOMEGROUND
THESE THE CANDIDATE KEYS FOR THIS TABLE
----PRIME ATTRIBUTES ARE
{TEAMID,TEAMNAME,COACH_ID,COACH_NAME,HOME_GROUND,ESTABLISHED_YEA
R)
----NON PRIME ATTRIBUTES ARE {NULL}

COACH TABLE:
THE POSSIBLE CANDIDATE KEYS ARE-
-TEAMID,COACH_ID
-TEAM-ID,COACH_NAME
-TEAM_ID,EXPERIENCE

--PRIME ATTRIBUTES
ARE{TEAM_ID,CAOCH_ID,COACH_NAME,EXPERIENCE,AGE)
--NON PRIME ATTRIBUTES{NULL}

MATCH_TABLE

MATCH_ID -> home_team_id,ground,match_date,away_team_id

Candidate key = {match_id}
Prime_attribute = match_id
Non prime_attributes =
{home_team_id,ground,match_date,away_team_id}

PLAYER TABLE
Functional dependencies

Fd1=
{player_id}>{player_name,team_id,position,age,team_name}
Fd2={player_id,player_name}-
>{team_id,position,age,team_name}
Fd3={player_id,player_name,team_id}->
{position,age,team_name}

MINIMAL CANDIDATE KEY ={player_id}

Prime attributes = player_id
Non prime atrributes =
{player_name,team_id,position,age,team_name}

SCORES TABLE
match id -> {team_id,player_id,score}
{match_id,player_id} -> {score}

Minimal super key is a candidate key therefore

Candidate key = {match_id}
Prime_attributes= {match_id}
Non prime attributes = {team_id,player_id}
NORMAL FORMS

SCORE TABLE
Prime_attributes= {match_id}
Non prime attributes = {team_id,player_id}

⚫ 1NF is satisfied because it does not have atomic values

⚫ 2nf is not satisfied because non prime attributes are
completely dependent on prime attributes
HIghest nf is 1

MATCH_TABLE
Prime_attribute = match_id
Non prime_attributes =
{home_team_id,ground,match_date,away_team_id}

-> No atomcity therefore it satisfies 1nf

-> As all NPA depends on PA it does not satisfy 1NF
Highest NF is 1

COACH TABLE
--PRIME ATTRIBUTES
ARE{TEAM_ID,CAOCH_ID,COACH_NAME,EXPERIENCE,AGE)
--NON PRIME ATTRIBUTES{NULL}

->Since table does not contain any atomic values,therefore it

satisfies 1 NF
->Non prime atrributes does not depend on prime atrributes
Therefore it satisfies 2 NF
->There is no transitive dependency in the given table I.e NPA->
NPA therefore it satisfies 3NF
Highest NF is 3NF
TEAMS TABLE

----PRIME ATTRIBUTES ARE

{TEAMID,TEAMNAME,COACH_ID,COACH_NAME,HOME_GROUND,ESTABL
ISHED_YEAR)
----NON PRIME ATTRIBUTES ARE {NULL}

->Since no atomic values In team table so it satisfies 1NF

->Non prime atrributes are not dependent on prime atrributes so
it satisfies 2NF
->There is no transitive dependency I.e NPA->NPA
Therefore it satisfies 3NF
Highest NF is 3NF

PLAYER TABLE

Prime attributes = player_id

Non prime atrributes =
{player_name,team_id,position,age,team_name}

->1NF is satisfied because it does not contain any atomic values

->As non prime atrributes =
{player_name,team_id,position,age,team_name}
Are derivied using prime atrributes player_id, therefore it does not
satisfied 2NF
Highest Normal form 1NF

QUERIES :

1. AVG age of players in each team

CONCLUSION

In conclusion, the Sports Management System project involves

four main tables: Teams, Match, Coach, Players, and Scores. The
system enables the storage and retrieval of information related to
teams, matches, coaches, players, and scores. The provided SQL
queries showcase basic functionalities, such as inserting data into
the tables and performing nested queries to extract specific
information, demonstrating the practical use of a relational
database management system for sports-related data. Further
development could include additional features, such as user
authentication, more complex queries, and a user interface for
better interaction with the system.

1. *Database Schema Design:*

- Structuring tables (Teams, Match, Coach, Players, Scores) to
organize sports-related data efficiently.

2. *Data Manipulation:*
- Inserting data into tables to populate the database with
relevant information.

3. *Querying and Retrieval:*

- Writing SQL queries for retrieving specific information,
including nested queries for more advanced filtering.

4. *Relationships:*
- Establishing relationships between tables to maintain data
integrity.

5. *Practical Application:*
- Applying database concepts to a real-world scenario,
facilitating sports-related data management.
This project provides a practical understanding of database
management in the context of sports systems, laying the
groundwork for more sophisticated applications and
improvements.

REFERENCES

1. https://www.geeksforgeeks.org/

2. https://www.javatpoint.com/