FS New

TABLE OF CONTENT
Chapter 1. Introduction Page no
o Introduction to File Structures 1-3

o Record
o Fixed Length Records
o Variable Length Records
o Indexing
o Primary Indexing
o Secondary Indexing
Chapter 2. Design and Development of Player Management System 4

System using Primary Index
Chapter 3. Algorithm and Program Code 6
Chapter 4. Results and Snapshots 23
Chapter 5. Conclusion 25
Chapter 6. References 26
.
LIST OF FIGURES:
SL.NO FIG.NO. FIG.NAME PAGE

NO.
1 3.1 Components of ER Diagram 6
2 3.2 ER Diagram of apartment visitor 7
management system
3 3.3 ER to schema diagram 10
4 4.1 Symbols of data flow diagram 14
5 4.2 Zero level DFD 15
6 4.3 First level DFD 15
7 4.4 Second level DFD 16
LIST OF TABLES:
TABLE NO. TABLE NAME PAGE NO.
4.1 Admin table 25
4.2 Visitor table 25
4.3 Category table 26
4.4 Visitor table 26
DEPARTMENT OF INFORMATION SCIENCE AND ENGINEERING
VISION
To evolve as an excellent technological education Center of Information Science to create
competitive & Responsible engineering professionals for the advancement of society.
MISSION
M1. To provide application specific training for developing quality engineers in Information.
M2. To develop creativity in students to become competent in the field of Information Science.
M3. To inculcate social and ethical values in students to perform better in diverse environment.
PROGRAM EDUCATIONAL OBJECTIVES

PEO1: To develop graduates who are proficient to solve wide range of computing related
problems.
PEO2: To prepare graduates who have the necessary skills required for higher education
& entrepreneurship .
PEO3: To prepare graduates who have the ability to engage in lifelong learning.
PROGRAM SPECIFIC OUTCOMES

PSO1: Capable to design, develop & test the IT-solutions in real time.
PSO2: Competent to apply knowledge to manage & monitor IT-resources
i
ABSTRACT
Player Management System mini project in C++ is a console application build without the
use of graphics. Player management system is a c++ mini project. This project helps the authority
to manage the newcomer players. Talking about the project here, the user can manage their player
profiles. He/She can search and update them. Also, this project helps in mitigating the risk of data
loss. Whenever you save a player record it will be automatically added to the database in text
format.
The Player Management System (PMS) is a software application designed to efficiently manage
and organize player-related information in various sports organizations, clubs, or teams. An
essential aspect of PMS is the establishment of an effective file structure to store and retrieve
player data. This abstract presents an overview of the recommended file structure for the PMS,
considering the organization, accessibility, and security of player information.
In conclusion, the recommended file structure for the Player Management System provides a
logical and organized approach to store, retrieve, and manage player-related data. The hierarchical
structure, granular categorization, indexing mechanisms, and security measures contribute to an
efficient and secure player management system that can benefit sports organizations, clubs, and
teams in managing their player information effectively.
ii
ACKNOWLEDGEMENT
First and the foremost, we are highly grateful to our Principal Dr. Sanjay Pande MB
and the esteemed institution GMIT for providing an opportunity to fulfill the partial
requirement towards obtaining our degree by accomplishing the mini project on database
management system.
We are highly grateful to Dr. Sunil Kumar B S., Professor and Head, Dept. of IS&E,
GMIT., Davangere for his kind support, guidance and encouragement throughout the course
of this mini project work.
We take this opportunity to express deep sense of gratitude to the Course coordinator
of Database Management systems and our guide Dr. Neelambike S, Asst. Professor, Dept. of
IS&E, and co- guide Mr. Manjunath K.G, Asst. Professor, Dept. of IS&E, Davangere for
their support who created interest about the concepts, guided in understanding the concepts,
and their encouragement throughout the course of this mini project work.
We would like to thank all the teaching and non-teaching staff of Dept. of IS&E for
their kind Co-operation during the course of the work. Finally, we are thankful to my parents
and friends, who helped me in one way or the other throughout this mini project work.
ABHISHEK BELAGAVI
ADARSH D.C
ANANAYA H.S
ANANYA PATEL G.P
iii
CHAPTER-1
INTRODUCTION
Definition of File Structure :
A file structure is a combination of representations for data in files and of operations
for accessing the data. A file structure allows applications toread, write and modify the data. It
might also support finding the data that matches some criteria or reading through the data in
some particular order.
Record:
A record can be defined as a set of fields that belong together when the file is
viewed in terms of a higher level of organization.
Following are some of the most often used methods for organizing the records of a file:
 Require that the records be a predictable number of bytes in length.
 Require that the records be a predictable number of fields in length.
 Begin each record with a length indicator consisting of a count of the number of bytes that
the record contains.
 Use a second file to keep track of the beginning byte address for each record.
 Place a delimiter at the end of each record to separate it from the next record.
Fixed-Length Records:
A Fixed-Length record file is one in which each record contains the same number of bytes.
Fixed-Length record structure is the most commonly used method for organizing files.
It is important to realize however, that fixing the number of bytes in arecord does not imply
the size or number of fields in the record must be fixed. Fixed-Length records are frequently used
as containers to hold variable-length fields. It is also possible to mix fixed-length and variable-
length fields within a record.
Variable-Length Records:
A data record that contains one or more fields of varying lengths is a variable length record.
The length of the entire record, therefore, varies according to what data is placed in the variable length
field.
1
Indexing
Indexing refers to the organization of data according to the specific schema or plan.
In IT, the term has various similar uses including, amongother things, making
information more presentable and accessible.
Indexing is a way to optimize performance of a database by minimizingthe number

of disk accesses required when a query is processed an index or database index is a data
structure which is used to quickly locate and access the data in a database table. Indexes
are created using some database columns.
An array is a series of elements of the same type placed in contiguous memory

locations that can be individually referenced by adding an index to aunique identifier.
Like a regular variable, an array must be declared before it is used. A typical for an array
in C++ is:
Type name[elements];
One example of indexing is the legacy Microsoft Indexing Service, which

maintained an index of files on a computer or in an operating system environment.
Another example is database indexing, which involves creatingan index for a database
structure to help expedite retrieval of data.
Primary Indexing
A primary index is an index on set of field that includes the unique primary key for
the field and is guaranteed not to contain duplicated. Also called a clustered index
example ID can be example of it.
An index in which the entries are a key ordered linear list simple indexing can be useful
when the entire index can be held in the memory. Change (addition and deletions) require
both the index and the data file to be changed updates affect the index if the key field to be
changed, or if the record is moved. An update which moves a record can be handled as a
deletion followed by addition. Accessing data from a file by record position moves a
record can be handled as a deletion followed by addition. Accessing data from a file by
record position with the file, without accessing intervening records. An ordinal number
indicating the position of a record within a file. A key which uniquely identifies the
records within a file.
2
Secondary Indexing
A Secondary index provides a secondary, means number of accessing a file for
which some primary access already exits. The secondary index may be on a field which is
a candidate. Key and has a unique value in every record, or a non-key with duplicate
values.
An index built on a secondary key, Secondary indexes can be built on any field of
the data file, or on any field of the data file, or on combination offields. Secondary
indexes will typically have multiple locations for a single key. Change to the data may
now affect multiple indexes. The reference fieldof a secondary index can be a direct
reference to the location of the entry in the data file. The references field of a secondary
index can also be an indirect reference to the location of the entry in the data file,
through
Indexing
Indexing refers to the organization of data according to the specific schema or plan.
In IT, the term has various similar uses including, amongother things, making
information more presentable and accessible.
Indexing is a way to optimize performance of a database by minimizingthe number

of disk accesses required when a query is processed an index or database index is a data
structure which is used to quickly locate and access the data in a database table. Indexes
are created using some database columns.
An array is a series of elements of the same type placed in contiguous memory

locations that can be individually referenced by adding an index to aunique identifier.
Like a regular variable, an array must be declared before it is used. A typical for an array
in C++ is:
Type name[elements];
One example of indexing is the legacy Microsoft Indexing Service, which

maintained an index of files on a computer or in an operating system environment.
Another example is database indexing, which involves creatingan index for a database
structure to help expedite retrieval of data.
Primary Indexing
A primary index is an index on set of field that includes the unique primary key for
the field and is guaranteed not to contain duplicated. Also called a clustered index
example ID can be example of it.
An index in which the entries are a key ordered linear list simple indexing can be useful
3
when the entire index can be held in the memory. Change (addition and deletions) require
both the index and the data file to be changedupdates affect the index if the key field to be
changed, or if the record is moved. An update which moves a record can be handled as a
deletion followed by addition. Accessing data from a file by record position moves a
record can be handled as a deletion followed by addition. Accessing data from a file by
record position with the file, without accessing intervening records. An ordinal number
indicating the position of a record within a file. Akey which uniquely identifies the
records within a file.
Secondary Indexing
A Secondary index provides a secondary, means number of accessing afile for
which some primary access already exits. The secondary index may be on a field which is
a candidate. Key and has a unique value in every record, or a non-key with duplicate
values.
An index built on a secondary key, Secondary indexes can be built on any field of
the data file, or on any field of the data file, or on combination of fields. Secondary
indexes will typically have multiple locations for a single key. Change to the data may
now affect multiple indexes. The reference field of a secondary index can be a direct
reference to the location of the entry in the data file. The references field of a secondary
index can also be an indirect reference to the location of the entry in the data file,
through
the primary key Indirect secondary key references simplify updating of the file set.
Retrieval using combination of Secondary Keys
 The search for record by multiple keys can be done on multiple index, with
the combination of index entries defining the record matching the key
combination.
 If two keys are to be combined, a list of entries from each key index is retrieved.
 For an “or” combination of keys, the lists are merged. i.e., any entry found
in either list matches the search.
 For an “and” combination of keys, the lists are matched. i.e., only
entries found in either list match the search.
4
CHAPTER-2
DESIGN AND DEVELOPMENT OF PLAYER MANAGEMENT SYSTEM

USING PRIMARY INDEX
INTRODUCTION TO PLAYERS MANAGEMENT:

Running a league, club or association shouldn’t be a full-time job (you already have one of
those). This project is easy to learn and user friendly, our player management technology helps
different sports of baseball, softball, football, soccer, hockey, and all types of sports organizers
automate their administrative work and manage their players.
The goal is to define sports processes necessary to develop software work products that satisfy the
players management system requirements. This mini project is designed which is intended in
saving players information, games information, parents and coach information. The main objective
of players Management System is to add, delete and search respective information.
We can perform the crud operation in this project and the system also contains other features
such as count number of players in all game, count the total number of player’s record and
clear complete database of player’s record. Here, a player’s record can be searched with different
searching methods which make the user work easier for the users.
DESIGN OF PLAYERS MANAGEMENT SYSTEM
The designing of Players Management System consist of Player records and ext..
Players Information:
Players Information has the details of Player id, Player name, Player age, Player address,
Player number. With the help of Player id we can get the information of Player and we can
delete Player record.
Player id Player Player age Player Player

name address number
5
FIGURE 2.2: Variable length record for Players Information.
FUNCTIONS USED IN THE PLAYERMANAGEMENT SYSTEM

Functions of different form are used during the implementation of Air Ticket Management
System. Some of them are listed below:
INPUT( ) : Takes the Input of Player Information from user.
OUTPUT( ) : Shows the last information of Player.
WRITEINFILE( ) : Writes the Input information into the File "PlayersRecord.txt".
SEARCHINRECORD( ) : Searches the information such as Game, Player Name,

PlayerId, Dorm No., bed No. etc. in the File "PlayersRecord.txt".
DELETEINRECORD( ) : Deletes the Player's Record using either PlayerId or

PlayerName.
COUNTPLAYERSINGAME( ) : Counts the Players Enrolled in different Games.
COUNTPLAYERS( ) : Counts the Players Enrolled in different Games.
SHOWALLRECORDS( ) : Show complete Player’s Record.
CLEARCOMPLETEDATABASE( ) : Clears the complete Player's Record Database
6
CHAPTER-3
ALGORITHM AND PROGRAM CODE
ALGORITHM:
playerinput ();
1. Open the class file.
2. While until end of file.
a. Find position.
b. Erase the buffer.
c. Take and get one record from file by calling getline (fp,buffer).
d. Store the file using writefile() function.
3. End while.
4. Close the file.
5. End.
ShowAllRecords()
1. open the stored file using readfile.open()

2. Initialize count = 0.
3. While read file.
4. Read and get record from file with getline (fp,buffer)
5. End while.
6. End reading
7. Return.
8. End.
Sort index :
1. For loop until I is less than count.

2. For loop until j is equal to i+1 and is less than count.
3. If id list[i]>id list[j]
4. Swap the elements in id list and address list.
5. End if.
6. End for.
7. End for
7
This subroutine sorts the order of id in id list and address in address
9. Call Sort index function to sort
In id list and array list.

se This subroutine inserts various fields in respective
rt
In record
de
x( DeleteInRecord(String key):
): 1. Initialize delch to *.
2. Open file.
1. 3. Get address from addresslist at position.
4. Seek record at that address.
5. Put delch at that address.
6. Print Record Deleted.
7. For loop.
a. Relocate the position of records in id list and address list.
2. 8. End for loop.
9. Decrement
the count
10.Else
3.
a. Record not been
found.
11.Updatethe file using cat
command.
This subroutine finds the record in file and puts a marks indicating that the record is
4.
deleted.
Search(string key) :
5. 1. Erase the buffer.
2. Call Search index and get position.
3. if position is negative then print record not found.
6. 4. if not then call Read from file.
5. Initialize position value to t.
7. 6. While name is found in idlist and t is positive.
a. Assign position to t
8. 7. Search for the id using getline in the file.
8.If the record has been found place the record in the
Searchindex (string key) :
8
1.
low, flag and mid.
2.
to high.
3.
less or equal to
high.
a.
(low+high)/2.
b.
in name list is
equal to the key
then,
b1. Set flag to 1.
b2. Break.
c.
is greater than
key. c1. High=
mid-1.
d.
is lesser than key.
c2. Low=mid+1.
4.
return mid else
return -1. This
subroutine
searches for a
record in a file.
9
PLAYER MANAGEMENT SYSTEM
Searchindex (string key) :
1. Assign 0 to low, flag and mid.

2. Assign count to high.
3. While low is less or equal to high.
a. mid= (low+high)/2.
b. if mid element in name list is equal to the key then,
b1. Set flag to 1.
b2. Break.
c. if mid element is greater than key. c1. High= mid-1.
d. if mid element is lesser than key. c2. Low=mid+1.
4. if flag=1 then return mid else return -1. This subroutine searches for a record in
a file.
#include <iostream>
Dept. of ISE, JNNCE, Shivamogga. Page 10
21
#include <fstream>
#include <string>
using namespace std;
class Player {
private:
int playerId;
string playerName;
int age;
string address;
long long phoneNumber;
string parentName;
string game;
string coachName;
int dorm;
int bed;
public:
void input() {
cout << "\nEnter player id: ";
cin >> playerId;
cout << "Enter player age: ";
cin >> age;
cout << "Enter player name: ";
cin.ignore();
getline(cin, playerName);
cout << "Enter player address: ";
getline(cin, address);
cout << "Enter player phone number: ";
cin >> phoneNumber;
cout << "Enter parent name: ";
cin.ignore();
getline(cin, parentName);
cout << "Enter game name: ";
getline(cin, game);
cout << "Enter coach name: ";
getline(cin, coachName);
cout << "Enter dorm number: ";
cin >> dorm;
cout << "Enter bed number: ";
cin >> bed;
}
void output() {
cout << "\nPlayer Details:\n";
cout << "Player ID: " << playerId << endl;
cout << "Player Name: " << playerName << endl;
cout << "Player Age: " << age << endl;
cout << "Player Address: " << address << endl;
cout << "Player Phone Number: " << phoneNumber << endl;
cout << "Parent Name: " << parentName << endl;
cout << "Game: " << game << endl;
21
cout << "Coach Name: " << coachName << endl;
cout << "Dorm Number: " << dorm << endl;
cout << "Bed Number: " << bed << endl;
}
int getPlayerId() {
return playerId;
}
string getPlayerName() {
return playerName;
}
};
void writeToFile(Player player) {

ofstream fout("PlayersRecord.txt", ios::out | ios::app);
if (!fout) {
cout << "Error opening file!";
return;
}
fout << "Player ID: " << player.getPlayerId() << endl;

fout << "Player Name: " << player.getPlayerName() << endl;
fout << endl;
fout.close();
}
void showAllRecords() {
ifstream fin("PlayersRecord.txt");
if (!fin) {
return;
}
string line;
while (getline(fin, line)) {
cout << line << endl;
}
fin.close();
}
void deleteRecord() {
string playerName;
cout << "Enter the name of the player to delete: ";
cin.ignore();
getline(cin, playerName);
ifstream fin("PlayersRecord.txt");
if (!fin) {
return;
21
}
ofstream fout("temp.txt");
if (!fout) {
cout << "Error creating temporary file!";
fin.close();
return;
}
string line;
bool found = false;
while (getline(fin, line)) {
if (line.find(playerName) != string::npos) {
found = true;
continue;
}
fout << line << endl;
}
fin.close();
fout.close();
if (found) {
remove("PlayersRecord.txt");
rename("temp.txt", "PlayersRecord.txt");
cout << "Player record deleted successfully.";
} else {
remove("temp.txt");
cout << "Player record not found.";

21

21

21

21

21

21

21

21
FIG NO: 3.2 ER diagram for apartment visitor management system
In the above fig.3.2 An ER diagram is a form of flow chart that shows how entities in a
system are connected to another This ER diagram how admin category visitor pass visitor are
interconnected. They are similar to data structure diagram, which focus on the interactions
between pieces within entities rather than the relationships between things.

21
3.1 ENTITY RELATIONSHIP SCHEMA DIAGRAM
A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are
associated. It formulates all the constraints that are to be applied on the data.
A database schema defines its entities and the relationship among them. It contains a
descriptive detail of the database, which can be depicted by means of schema diagrams.
An Entity-Relationship Model (ERM) is an abstract and conceptual representation of data.

Entity-relationship modeling is a database modeling method, used to produce a type of
conceptual schema or semantic data model of a system, often a relational database, and its
requirements in a top-down fashion.
In order to create an ER schema you must know three main concepts: entity, attribute and
relationship.
Entity:
Entity is the central concept of the Entity-Relationship model. An entity represents a
description of the common features of set of objects of the real world. Examples of entities
are Person, Car, Artist, and Album.
Attribute:
An Attribute represents the properties of real world objects that are relevant for the
application purposes .Attributes are associated with the concept of Entity, with the meaning
that all the instances of the entity are characterized by the same set of attributes. In other
words, the entity is a descriptor of the common properties of a set of objects, and such
properties are expressed as attributes.
Relationship:
A Relationship represents semantic connections between entities, like the association

between an artist and his/her album, or between an artist and his/her reviews.

21
The possible values are one and many. Based on their maximum cardinality constraints,
relationships are called
1. "one-to-one", if both relationships roles have maximum cardinality 1,
2. "one-to-many", if one relationship role has maximum cardinality 1 and the other role has
maximum cardinality N,
3. "many-to-many", if both relationships roles have maximum cardinali
E-R Schema Normalization:

E-R includes some concept that are not minimal but which can be specified through the usage
of the three main concepts of the ER Schema. These concepts are:
 Multi value attributes.

 Attributes of an object that can take a set of values represented by an entity and a
relationship
 Composed attributes.
 Attributes with an internal structure (i.e, an address can include different fields),
represented by using an entity and a relationship
 N-ary relationships.
 Represented by a central entity and two reports
 Relationships with attributes.

 Relationships involving N entities

21
FIG NO: 3.3 Describes the Schema Diagram for Apartment Visitor Management System
In the above fig.3.3 A schema diagram is a visual representation of the entities and attributes
that will be used to define schema. Only the database design is shown in a schema diagram. It
does not display the database’s actual data. A schema might consist of a single table or
multiple tables that are linked together .The schema shows how the tables visitor, visitor
pass ,admin
,category are related.

21
3.2 CONVERSION OF ER TO SCHEMA DIAGRAM
Step 1: Mapping of Regular Entity Types. For each regular (strong) entity type in the ER
schema, create a relation R that includes all the simple attributes of E. Include only the simple
component attributes of a composite attribute. Choose one of the key attributes of E as the
primary key for R. If the chosen key of E is a
composite, then the set of simple attributes that form it will together form the primary key of R.
If multiple keys were identified for E during the conceptual design, the information describing
the attributes that form each additional key is kept in order to specify secondary (unique) keys of
relation R. Knowledge about keys is also kept for indexing purposes and other types of analyses.
Step 2: Mapping of Weak Entity Types. For each weak entity type W in the ER schema with
owner entity type E, create relation R and include all simple attributes (or simple components of
composite attributes) of was attributes of R. In addition, include as foreign key attributes of R,
the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s); this
takes care of mapping the identifying relationship type of W. The primary key of R is the
combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W,
if any. If there is a weak entity type E2 whose owner is also a weak entity type El, then El should
be mapped before E2 to determine its primary key first.
Step 3: Mapping of Binary 1:1 Relationship Types. For each binary 1: 1 relationship type R
in the ER schema, identify the relations Sand T that correspond to the entity types participating
in R. There are three possible approaches: • The foreign key approach. • The merged relationship
approach, and • The first approach is the most useful and should be followed unless special
conditions exist.
Step 4: Mapping of Binary I:N Relationship Types. For each regular binary 1:N relationship
type R, identify the relation S that represents the participating entity type at the N-side of the
relationship type. Include as foreign key in S the primary key of the relation T that represents the
other entity type participating in R; we do this because each entity instance on the N-side is
related to at most one entity instance on the I-side of the relationship type. Include any simple 7
attributes (or simple components of composite attributes) of the relationship type as attributes of
S.
Step 5: Mapping of Binary M:N Relationship Types. For each binary M:N relationship type
R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys

21
of

21
the relations that represent the participating entity types; Also include any simple attributes of the
M:N relationship type (or simple components of composite attributes) as attributes of S. Notice
that we cannot represent an M:N relationship type by a single foreign key attribute in one of the
participating relations (as we did for or I:N relationship types) because of the M:N cardinality
ratio; we must create a separate relationship relation S.
Step 6: Mapping of Multivalued Attributes. For each multivalued attribute A, create a new
relation R. This relation R will include an attribute corresponding to A, plus the primary key
attribute K—as a foreign key in R— of the relation that represents the entity type or relationship
type that has A as a multivalued attribute. The primary key of R is the combination of A and K.
If the multivalued attribute is composite, we include its simple components.
Step 7: Mapping of N-array Relationship Types. For each n-array relationship type R, where n
> 2, create a new relation S to represent R. Include as foreign key attributes in S the primary keys
of the relations that represent the participating entity types. Also include any simple attributes of
the n-array relationship type (or simple components of composite attributes) as attributes of S.
The primary key of S is usually a combination of all the foreign keys that reference the relations
representing the participating entity types. However, if the cardinality constraints on any of the
entity types E participating in R is 1, then the primary key of S should not include the foreign
key.

21
CHAPTER 4
IMPLEMENTATION
4.1 OVERVIEW
Data Flow Diagrams A Data Flow Diagram (DFD) is a traditional visual representation of the
information flows within a system. A neat and clear DFD can depict the right amount of the
system requirement graphically. It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where data is
stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communication tool between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The DFD is also called as a data flow
graph or bubble chart.
The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order
of events; arrows in DFD represents flowing data. A DFD does not involve any order of
events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a
DFD, suppress that urge! A diamond-shaped box is used in flow charts to represents
decision points with multiple exists paths of which the only one is taken. This implies an
ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling until
the end of the analysis.
Standard symbols for DFDs are derived from the electric circuit diagram analysis and are shown
in fig:4.1

21
Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a process or data store.
Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes in a
different order. The data store can have an element or group of elements.
Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink
of system outputs.
FIG NO 4.1: SYMBOLS OF DATA FLOW DIAGRAMS

21
Visitor
Management
Visitor Pass Login

Management Management
AVMS
Category Password
Admin
Management
FIG NO 4.2 ZERO LEVEL DFD
Fig 4.2 shows that it is also known as a context diagram. It's designed to be an abstraction view,
showing the system as a single process with its relationship to external entities. It represents the
entire system as a single bubble with input and output data indicated by incoming/outgoing
arrows.
Visitor Password
Visitor Pass Login
Management AVMS
Management
Category
Generate Visitor
Management
Report
Authorization
Management Generate Pass
Visitor Report
Admin
Management
FIG NO 4.3 FIRST LEVEL DFD

Fig 4.3 shows that in level 1 DFD, the single process node from the context diagram is broken
down into sub-processes. As these processes are added, the diagram will need additional data
flows and data stores to link them together.
21
Check
Admin Login to Roles of
system
Add/Manage
Category
Add New Visitor
Manage Visitor
Forgot Check
Password Credential
Add/Manage Visitor
Pass
Manage
Module
Generate Visitor
Pass Report
Change Password Update Profile Generate Visitor
Report
FIG NO 4.4 SECOND LEVEL DFD
Fig 4.4 shows that 2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to
plan or record the specific/necessary detail about the system's functioning.

21
4.2 SOURCE CODE

phpMyAdmin SQL Dump
-- version 5.2.0
-- https://www.phpmyadmin.net/
--
-- Host: 127.0.0.1
-- Generation Time: Dec 05, 2022 at 04:52 PM
-- Server version: 10.4.24-MariaDB
-- PHP Version: 7.4.29
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";

START TRANSACTION;
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;

/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS
*/;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Database: àvmsdb`
--
--
-- Table structure for table `tbladmin`
--
CREATE TABLE `tbladmin` (

ÌD` int(5) NOT NULL,
ÀdminName` varchar(45) DEFAULT NULL,
ÙserName` char(45) DEFAULT NULL,
`MobileNumber` bigint(11) DEFAULT NULL,
Èmail` varchar(120) DEFAULT NULL,
`Password` varchar(120) DEFAULT NULL,
ÀdminRegdate` timestamp NULL DEFAULT current_timestamp()
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
-- Dumping data for table `tbladmin`
INSERT INTO `tbladmin` (ÌD`, ÀdminName`, ÙserName`, `MobileNumber`, Èmail`,
`Password`, ÀdminRegdate`) VALUES
(1, 'Admin user', 'admin', 7898799797, 'admin@gmail.com',

'f925916e2754e5e03f75dd58a5733251', '2022-12-05 06:26:14');

21
--
-- Table structure for table `tblcategory`
--
CREATE TABLE `tblcategory` (
ìd` int(11) NOT NULL,
`categoryName` varchar(120) DEFAULT NULL,
`creationDate` timestamp NULL DEFAULT current_timestamp()
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb
--
-- Dumping data for table `tblcategory`
--
INSERT INTO `tblcategory` (ìd`, `categoryName`, `creationDate`) VALUES
(1, 'Maid', '2022-12-04 18:09:59'),
(2, 'NewsPaper', '2022-12-04 18:10:12'),
(3, 'Cook', '2022-12-04 18:10:26'),
(4, 'Milkman', '2022-12-04 18:10:55'),
(5, 'Driver', '2022-12-04 18:11:08'),
(6, 'Gardener', '2022-12-04 18:11:18'),
(8, 'Car Cleaner', '2022-12-04 18:14:15'),
(9, 'Other', '2022-12-04 18:14:34'),
(10, 'Guest', '2022-12-04 18:14:40');
-- Table structure for table `tblvisitor`

--
CREATE TABLE `tblvisitor` (
`VisitorName` varchar(120) DEFAULT NULL,
Address` varchar(250) DEFAULT NULL,
Àpartment` varchar(120) NOT NULL,
`Floor` varchar(120) NOT NULL,
`WhomtoMeet` varchar(120) DEFAULT NULL,
`ReasontoMeet` varchar(120) DEFAULT NULL,
ÈnterDate` timestamp NULL DEFAULT current_timestamp(),
`remark` varchar(255) DEFAULT NULL,
òuttime` timestamp NULL DEFAULT NULL ON UPDATE current_timestamp()
--

21
-- Dumping data for table `tblvisitor`
--
INSERT INTO `tblvisitor` (ÌD`, `categoryName`, `VisitorName`, `MobileNumber`, Àddress`,

Àpartment`, `Floor`, `WhomtoMeet`, `ReasontoMeet`, ÈnterDate`, `remark`, òuttime`)
VALUES
(1, 'Guest', 'Amit Kumar', 1212121233, 'H 1223 Sector 15 noida UP', 'Q707', '7', 'Anuj Kumar',
'Personal', '2022-12-04 18:24:29', 'NA', '2022-12-04 18:36:04'),
(2, 'Milkman', 'Sunny', 1425363625, 'NA', 'H911', '9', 'Amit ', 'Milk Distribution', '2022-12-04
18:27:21', 'Your Milkman has been out', '2022-12-05 05:49:09'),
(3, 'Driver', 'Sukhdev Singh', 1425362514, 'NA', 'T501', '5', 'Amit Kumar', 'Driver', '2022-12-04
19:28:04', NULL, NULL);
--
-- Table structure for table `tblvisitorpass`
--
CREATE TABLE `tblvisitorpass` (
`passnumber` bigint(20) DEFAULT NULL,
`VisitorName` varchar(120) DEFAULT NULL,
Àddress` varchar(250) DEFAULT NULL,
Àpartment` varchar(120) NOT NULL,
`Floor` varchar(120) NOT NULL,
`passDetails` varchar(120) DEFAULT NULL,
`creationDate` timestamp NULL DEFAULT current_timestamp(),
`fromDate` date DEFAULT NULL,
`toDate` date NOT NULL
--
-- Dumping data for table `tblvisitorpass`
--
INSERT INTO `tblvisitorpass` (ÌD`, `passnumber`, `categoryName`, `VisitorName`,
`MobileNumber`, Àddress`, Àpartment`, `Floor`, `passDetails`, `creationDate`, `fromDate`,
`toDate`) VALUES
(1, 94395973, 'Car Cleaner', 'Amit', 1414253625, 'NA', 'A512', '5', 'For Car Cleaning', '2022-12-04
19:01:30', '2022-12-06', '2023-01-31'),
(2, 94395972, 'Maid', 'Savita', 1233211230, 'NA', 'Q707', '7', 'Maid', '2022-12-04 19:04:40', '2022-

21
12-10', '2023-03-10');
--
-- Indexes for dumped tables
--
--
-- Indexes for table `tbladmin`
--
ALTER TABLE `tbladmin`

ADD PRIMARY KEY (ÌD`);
-
--
-- Indexes for table `tblcategory`
--
ALTER TABLE `tblcategory`
ADD PRIMARY KEY (ìd`);
ADD PRIMARY KEY (ìd`);
--
-- Indexes for table `tblvisitorpass`
--
ALTER TABLE `tblvisitorpass`
ADD PRIMARY KEY (ÌD`),
ADD KEY ÌD` (ÌD`);
--
-- AUTO_INCREMENT for dumped tables
--
-- AUTO_INCREMENT for table `tbladmin`

--
ALTER TABLE `tbladmin`
MODIFY ÌD` int(5) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
--
-- AUTO_INCREMENT for table `tblcategory`
--
MODIFY ìd` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=11;
--
-- AUTO_INCREMENT for table `tblvisitor`
--
ALTER TABLE `tblvisitor`

21
--
-- AUTO_INCREMENT for table `tblvisitorpass`
--
ALTER TABLE `tblvisitorpass`
COMMIT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
--
4.3 MY SQL DATA TABLES:
Admin Table:(Table name is admin) ,This table store admin personal and login details.
TABLE NO 4.1 Admin Table
Visitor Table: (Table name is tblvisitor),This table store the visitor details and admin remark
TABLE NO 4.2 Visitor Table

21
Category Table: (Table name is tblcategory), This table stores the category of visitor.
TABLE NO 4.3 Category Table
Visitor Pass Table: (Table name is tblvisitorpass), This table stores the details of visitor
pass.
TABLE NO 4.4 Visitor Table

21
CHAPTER 5
SNAPSHOTS
Project URL: http://localhost/avms
FIG NO 5.1 Login page

Fig 5.1 shows the login page of the apartment visitor Management system. Through this login
page both user as well as admin can login to the website
FIG NO 5.2 Forgot Password
Fig 5.2 shows the forgot password of the apartment visitor Management system. Through this
forgot password page the user can redeem his account details.

21
FIG NO 5.3 Reset Password
Fig 5.3 shows the reset password of the apartment visitor Management system. Through this reset
password page the user can reset his account details.
FIG NO 5.4 Dashboard
Fig 5.4 shows the Dashboard of the apartment visitor Management system. Through this
Dashboard page the admin can keep track of the todays visitors, yesterday visitors, etc.

21
FIG NO 5.5 Admin Profile
Fig 5.5 shows the admin page of the apartment visitor Management system. Through this admin
page the admin can get the details of the admin.
FIG NO 5.6 Change password

Fig 5.6 shows the change password page of the apartment visitor Management system. Through
this change password page user can change the password.

21
FIG NO 5.7 Manage category
Fig 5.7 shows the Manage category page of the apartment visitor Management system. Through
this Manage category page admin can manage the category of the user.
FIG NO 5.8 Add new visitor
Fig 5.8 shows the Add new visitor page of the apartment visitor Management system. Througthis
Add new visitor page admin can add the new visitor to the page.

21
FIG NO 5.9 Manage visitor

Fig 5.9 shows the Manage visitor page of the apartment visitor Management system. Through this
Manage visitor page admin can add the manage visitor to the page.
FIG NO 5.10 Visitor detail
Fig 5.10 shows the Visitor detail page of the apartment visitor Management system. Through this
visitor detail page admin can the manage visitors detail to the page.

21
FIG NO 5.11 Visitor details after update

Fig 5.11 shows the Visitor details after update page of the apartment visitor Management system.
Through this visitor details after update page admin can the update visitors details to the page.
FIG NO 5.12 Create entry pass
Fig 5.12 shows the Create entry pass page of the apartment visitor Management system. Through
this Create entry pass page admin can create a entry pass for visitors to the page.

21
FIG NO 5.13 Manage entry pass
Fig 5.13 shows the Manage entry pass page of the apartment visitor Management system.
Through this Manage entry pass page admin can manages the visitors to the page.
FIG NO 5.14 View details of entry pass
Fig 5.14 shows the View details of entry pass of the apartment visitor Management system.
Through this the View details of entry pass admin can view the details of visitors entry to the
page.

21
FIG NO 5.15 Between dates and reports
Fig 5.15 shows the Between dates and reports page of the apartment visitor Management system.
Through this Between dates and reports page the admin can view the dates between reports entry
to the page.
FIG NO 5.16 View details dates report
Fig 5.16 shows the View details dates report page of the apartment visitor Management system.
Through this View details dates report page the admin can view the details dates of the user in
the page.

21
FIG NO 5.17 Between dates report of entry pass
Fig 5.17 shows the Between dates report of entry pass page of the apartment visitor Management
system. Through this Between dates report of entry pass page the admin can view the dates
report of entry pass of the user in the page.
FIG NO 5.18 View detail between dates report of Entry Pass

Fig 5.18 shows View detail between dates report of Entry Pass page the of the apartment visitor
Management system. Through this admin can view the detail between dates report of Entry Pass
of the visitor entry pass of the in the page.

21
CHAPTER 6
CONCLUSION
This Project provides a computerized version of Apartment Visitor Management System
which will benefit the society of gate guards who have to maintain a bulky and very hard to
maintain record books for all visit who visit in the society for various reasons.
It makes entire process online and can generate reports. It has a facility of staff’s login where
staff can fill the visitor details and generate report.
The Project was designed in such a way that future changes can be done easily. The following
conclusions can be deduced from the development of the project.
• Automation of the entire system improves the productivity.
• It provides a friendly graphical user interface which proves to be better when
compared to the existing system.
• It gives appropriate access to the authorized users depending on their permissions.
• It effectively overcomes the delay in communications.
• Updating of information becomes so easier.
• System security, data security and reliability are the striking features.
• The System has adequate scope for modification in future if it is necessary.

21
7 FUTURE ENHANCMENT
Some potential future enhancements for an apartment visitor management system include:
 Integrating with smart home technology to automatically unlock doors for authorized
visitors
 Implementing facial recognition or other biometric authentication methods for added
security
 Allowing residents to pre-register guests and set access permissions for specific dates and
times
 Providing a mobile app for residents to manage their visitor list and grant access remotely
 Incorporating real-time notifications and alerts for residents when a visitor arrives or is
denied access
 Adding an option for visitors to sign in digitally, rather than using a physical sign-in sheet
 Integrating with other building systems, such as elevators or parking gates, to grant
access to certain areas of the building for authorized visitors
It's important to note that these suggestions are based on the general concepts and could vary
depending on the specific requirements and context of the visitor management system.

21
8 References
For PHP
• https://www.w3schools.com/php/default.asp
• https://www.sitepoint.com/php/
• https://www.php.net/
For MySQL
• https://www.mysql.com/
• http://www.mysqltutorial.org
For wamp
 https://www.wampserver.com/en/
TEXT BOOKS
 “Database System Concepts” by Abraham Silberschatz and S Sudarshan.

 “Database Management System” by Raghu Ramakrishnan.
 “Principles of Database System” by J D Ullman.
 Fundamentals of Database System
 The truth about HTML5.

21

FS New

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FS New

Uploaded by

Copyright:

Available Formats

TABLE OF CONTENT

Chapter 1. Introduction Page no

o Introduction to File Structures 1-3

Chapter 2. Design and Development of Player Management System 4

Chapter 3. Algorithm and Program Code 6

Chapter 4. Results and Snapshots 23

SL.NO FIG.NO. FIG.NAME PAGE

competitive & Responsible engineering professionals for the advancement of society.

PROGRAM EDUCATIONAL OBJECTIVES

PROGRAM SPECIFIC OUTCOMES

PSO2: Competent to apply knowledge to manage & monitor IT-resources

Indexing is a way to optimize performance of a database by minimizingthe number

An array is a series of elements of the same type placed in contiguous memory

One example of indexing is the legacy Microsoft Indexing Service, which

Indexing is a way to optimize performance of a database by minimizingthe number

An array is a series of elements of the same type placed in contiguous memory

One example of indexing is the legacy Microsoft Indexing Service, which

DESIGN AND DEVELOPMENT OF PLAYER MANAGEMENT SYSTEM

INTRODUCTION TO PLAYERS MANAGEMENT:

DESIGN OF PLAYERS MANAGEMENT SYSTEM

Player id Player Player age Player Player

FUNCTIONS USED IN THE PLAYERMANAGEMENT SYSTEM

OUTPUT( ) : Shows the last information of Player.

WRITEINFILE( ) : Writes the Input information into the File "PlayersRecord.txt".

SEARCHINRECORD( ) : Searches the information such as Game, Player Name,

DELETEINRECORD( ) : Deletes the Player's Record using either PlayerId or

COUNTPLAYERSINGAME( ) : Counts the Players Enrolled in different Games.

COUNTPLAYERS( ) : Counts the Players Enrolled in different Games.

SHOWALLRECORDS( ) : Show complete Player’s Record.

CLEARCOMPLETEDATABASE( ) : Clears the complete Player's Record Database

1. open the stored file using readfile.open()

1. For loop until I is less than count.

9. Call Sort index function to sort

In id list and array list.

Searchindex (string key) :

b1. Set flag to 1.

Searchindex (string key) :

1. Assign 0 to low, flag and mid.

using namespace std;

void writeToFile(Player player) {

fout << "Player ID: " << player.getPlayerId() << endl;

Dept. of ISE, JNNCE, Shivamogga. Page 13

Dept. of ISE, JNNCE, Shivamogga. Page 14

Dept. of ISE, JNNCE, Shivamogga. Page 15

Dept. of ISE, JNNCE, Shivamogga. Page 16

Dept. of ISE, JNNCE, Shivamogga. Page 17

Dept. of ISE, JNNCE, Shivamogga. Page 18

Dept. of ISE, JNNCE, Shivamogga. Page 19

Dept. of ISE, JNNCE, Shivamogga. Page 20

FIG NO: 3.2 ER diagram for apartment visitor management system

Dept. of ISE, JNNCE, Shivamogga. Page 21

3.1 ENTITY RELATIONSHIP SCHEMA DIAGRAM

An Entity-Relationship Model (ERM) is an abstract and conceptual representation of data.

A Relationship represents semantic connections between entities, like the association

Dept. of ISE, JNNCE, Shivamogga. Page 22

1. "one-to-one", if both relationships roles have maximum cardinality 1,

3. "many-to-many", if both relationships roles have maximum cardinali

E-R Schema Normalization:

 Multi value attributes.

 Relationships with attributes.

Dept. of ISE, JNNCE, Shivamogga. Page 23

Dept. of ISE, JNNCE, Shivamogga. Page 24

3.2 CONVERSION OF ER TO SCHEMA DIAGRAM

/!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT /;

/!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT /;