lOM oAR c P S D | 4933 057 1

SRI VENKATESWARA COLLEGE OF ENGINEERING AND TECHNOLOGY

(AUTONOMOUS)

R.V.S Nagar,Chittoor-517127.(A.P)

(Approved by AICTE ,New Delhi, Affiliated to JNTUA Anantapur)

(Accredited by NBA, New Delhi & Delhi & NAAC A+, Bangalore)

(An ISO 9001:2000 Certified Institution)

2024-2025

Internship report
A report submitted in partial fulfilment of the requirements for the award of degree of

BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE AND ENGINEERING(AI&ML)
By
KOWSALYA GOPINATHAN
Reg no:21781A3345

Under Supervision of Excel R

(Duration: 18th June, 2024 to 30th july,2024)
 lOM oAR c P S D | 4933 057 1

SRI VENKATESWARA COLLEGE OF ENGINEERING AND TECHNOLOGY(autonomous)

R.V.S Nagar, Chittor -517 127 .(AP)

(Approved by AICTE ,New Delhi, Affiliated to JNTUA ,Anantapur)(Accredited by NBA

,New Delhi & NAAC A+ , Bangalore)

CERTIFICATE

This is to certify that the “ Internship report ” submitted by KOWSALYA

GOPINATHAN(Regd.No:21781A3345) is work done by me and submitted during
2022-2023 academic year, in partial fulfilment of the requirements for the award of
the degree of BACHELOR OF TECHNOLOGY in COMPUTER SCIENCE AND
ENGINEERING (AI & ML), at ExcelR.

DR.M.LAVANYA
Mrs.Gayathri Head of the department
College Internship coordinator Department of CSE(Ai&Ml)
 lOM oAR c P S D | 4933 057 1

CERTIFICATE
lOM oAR c P S D | 4933 057 1
 lOM oAR c P S D | 4933 057 1

ACKNOWLEDGEMENT

A grateful thanks to Dr . Ravuri Venkata swamy, Chairman of Sri Venkateswara

College of Engineering & Technology for providing education in their esteemed institution.

I wish to record my deep sense of gratitude and profound thanks to our beloved Vice Chairman, Sri
Ravuri Venkata Srinivas for his valuable support throughout the course.

I express our sincere thanks to Dr .M.MOHAN BABU, our beloved principal for his encouragement
and suggestion during the course of study.

With the deep sense of gratefulness, I acknowledge Dr . LAVANYA , Head of the

Department, Computer Science Engineering(AI &ML), for giving us inspiring guidance
in undertaking internship.

I express our sincere thanks to the Mrs. Gayathri , internship coordinator, for her keen
interest, stimulating guidance, constant encouragement with our work during all stages, to
bring this report into fruition.

Finally, I would like to express my sincere thanks to all teaching, non-teaching faculty
members, our parents, friends and for all those who have supported us to complete the
internship successfully.

Name: G.Kowsalya
Roll no:21781A3345
 lOM oAR c P S D | 4933 057 1

ABSTRACT

My Structured Query Language( My SQL) is a standardized programming language designed for managing
and manipulating relational databases. My SQL provides a powerful and flexible way to store, modify
and retrieve data stored in relational databases. with My SQL, users can perform various operations,
including creating and modifying database structures, inserting , updating and deleting data, and
querying data using complex queries.

Organization Information:

ExcelR is an internship and online training platform, based in Bangalore, India.

Founded by Ram Tavva, an IIT Madras alumnus, in 2010, the website helps students find internships with
organizations in India.

A world where you do not have to wait till 21 to taste your first work experience. A world where you
graduate fully assured, fully confident, and fully prepared to stake a claim on your place in the world.
ExcelR launched its online training in 2014.

As of 2018 , the platform had 3.5 million students and 80,000 companies.
 lOM oAR c P S D | 4933 057 1

INDEX :

1. INTRODUCTION

2. IMPLEMENTATION

3. SQL COMMANDS

4. SQL ELEMENTS

5. DATABASE

6. RELATIONSHI

7. CREATING LOGIN PAGE AND

8. LINKING IT TO DATA BASE

9. SCREENSHOTS

10. CONCLUSION
 lOM oAR c P S D | 4933 057 1

WEEKLY OVERVIEW OF INTERNSHIP ACTIVITIES

1st DATE DAY NAME OF THE TOPIC/MODULE COMPLETED

W
E
E
18/06/24 Tuesday Introduction to company
K
19/06/24 Wednesday Introduction to MYSQL
20/06/24 Thursday Introduction to MYSQL
21/06/24 Friday Quiz
22/06/24 Saturday How to use SQL

23/06/24 Sunday SQL Commands SQL

24/06/24 Monday Quiz Elements of
MYSQL,

a
2nd DATE DAY NAME OF THETOPIC/MODULE COMPLETED
25/06/24 Tuesday Elements, Quiz
W
E

E
K
26/06/24 Wednesday Quiz
27/06/24 Thursday Starting the MYSQL Monitor

28/06/24 Friday Quiz

29/06/24 Saturday Data collecting
30/06/24 Sunday MYSQL
Commands
01/07/24 Monday Quiz
 lOM oAR c P S D | 4933 057 1

3rd DATE DAY NAME OF THETOPIC/MODULE COMPLETED

02/07/24 Tuesday Data Grouping,
W
E

E
K
03/07/24 Wednesday Quiz
04/07/24 Thursday Introduction to Database
05/07/24 Friday Quiz
06/07/24 Saturday How to
develop a
database,
07/07/24 Sunday Quiz
08/07/24 Monday Database design process,

4th DATE DAY NAME OF THE TOPIC/MODULE COMPLETED

W
E
E
k
09/07/24 Tuesday Quiz,

10/07/24 Wednesday Executing different design

processes,
11/07/24 Thursday Quiz

12/07/24 Friday Entity or Relationship,

13/07/24 Saturday Quiz,

14/07/24 Sunday Representing Relationship

15/07/24 Monday Quiz

 lOM oAR c P S D | 4933 057 1
lOM oAR c P S D | 4933 057 1

5th DATE DAY NAME OF THE TOPIC/MODULE COMPLETED

W
E
E
k
16/07/24 Tuesday Week and Strong Entities Representing Relationship,

17/07/24 Wednesday Quiz

18/07/24 Thursday Entry Relationship Modeling examples ,

Quiz

19/07/24 Friday Quiz Entry Relationship Modeling examples

20/07/24 Saturday Creating a login page and linking it to the database

21/07/24 Sunday Entity or Relationship

22/07/24 Monday Quiz

6th DATE DAY NAME OF THE TOPIC/MODULE COMPLETED

W
E
E
k
23/07/24 Tuesday Week and Strong Entities

24/07/24 Wednesday Quiz

25/07/24 Thursday Modeling and designing Databases.

26/07/24 Friday Quiz

27/07/24 Saturday Creating a login page and linking it to the database

28/07/24 Sunday Quiz

29/07/24 Monday Completion of internship

 lOM oAR c P S D | 4933 057 1

INTRODUCTION

MySQL is a relatively recent entrant into the well-established area of relational

database management systems (RDBMs), a concept invented by IBM researcher
Edgar Frank Codd in 1970. Despite the arrival of newer types of data repositories
over the past 35 years, relational databases remain the workhorses of the
information world. They permit users to represent sophisticated relationships
between items of data and to calculate these relationships with the speed needed to
make decisions in modern organizations. It’s impressive how you can go from
design to implementation in just a few hours, and how easily you can develop web
applications to access terabytes of data and serve thousands of web users per second
lOM oAR c P S D | 4933 057 1

IMPLEMENTATION

Why Is MySQL so Popular?

The MySQL development process focuses on offering a very efficient implementation of the features most
people need. This means that MySQL stil has fewer features than its chief open source competitor,
PostgreSQL, or the commercial database engines. Nevertheless, the skills you get from this book will serve
you well on any platform. Many database management systems—even open source ones—preceded MySQL.
Why has MySQL been the choice for so many beginners and small sites, and now for some heavyweight
database users in government and industry? We can suggest a few factors:

Size and speed

MySQL can run on very modest hardware and puts very little strain on system resources; many small users
serve up information to their organizations by running MySQL on modest desktop systems. The speed with
which it can retrieve information has made it a longstanding favorite of web administrators. Over the past few
years, MySQL AB has addressed the need of larger sites by adding features that necessarily slow down
retrieval, but its modular design lets you ignore the advanced features and maintain the suppleness and speed
for which MySQL is famous.

Ease of installation

Partly because MySQL is small and fast, it works the way most people want straight “out of the box.” It can
be installed without a lot of difficult and sophisticated configuration. Now that many Linux distributions
include MySQL, installation can be almost automatic. This doesn’t mean MySQL is free of administrative
tasks. In particular, we’ll cover a few things you need to do at the start to tighten security. Very little
configuration is shown in this book, however, which is a tribute to the database engine’s convenience and
natural qualities.

Attention to standards

As we’ll explain in the “Structured Query Language” section later in this chapter, multiple standards exist in
the relational database world, and it’s impossible to claim total conformance. But learning MySQL certainly
prepares you for moving to other database engines. Moving code from one database engine to another is never
trivial, but MySQL does a reasonable job of providing a standard environment, and gets better as it develops
more features.
 lOM oAR c P S D | 4933 057 1

Responsiveness to community

With a few hundred employees scattered around the globe, MySQL AB is a very flexible organization that
keeps constant tabs on user needs. At its conferences, lead developers get out in front and make themselves
available to everyone with a gripe or a new idea. There are also local MySQL user groups in almost every
major city. This responsiveness is helped by the fact that MySQL is open and free; any sufficiently skilled
programmer can look at the program code to find and perhaps help in fixing problems. MySQL actually has a
dual-license approach: if you want to build your own product around it, you pay MySQL AB a license fee. If
you just want to use MySQL to serve your own data, you don’t have to pay the license fee. MySQL also offers
technical support, as do numerous other companies and consultants, some of them probably near you.

Easy interface to other software

It is easy to use MySQL as part of a larger software system. For example, you can write programs that can
interact directly with a MySQL database. Most major programming languages have libraries of functions for
use with MySQL; these include C, PHP, Perl, Python, Ruby, and the Microsoft .NET languages. MySQL also
supports the Open Database Connectivity (ODBC) standard, making it accessible even when MySQL-specific
functionality isn’t available. We’ll explore four aspects of using MySQL:

MySQL server

• We explain how to create your own MySQL installation, and how to configure and administer it.

SQL

• This is the core of MySQL use, and It’s introduced in“Structured Query Language.”

Programming languages

• SQL is not a simple or intuitive language, and it can be tedious to repeatedly perform complex operations.
You can instead use a general-purpose programminglanguage such as PHP or Perl to automatically create
and execute SQL queries onthe MySQL server. You can also hide tdetails of the interaction with the
databasebehind a user-friendly interface. We’ll show you how to do this.

Web database applications

• We explain how you can use PHP or Perl to create dynamic, database-driven webapplications that
can publish information from the database to the Web, and capture information provided by users.
lOM oAR c P S D | 4933 057 1

SQL COMMANDS

• SELECT - extracts data from a database

• UPDATE - updates data in a database

• DELETE - deletes data from a database

• INSERT INTO - inserts new data into a database

• CREATE DATABASE - creates a new database

• ALTER DATABASE - modifies a database

• CREATE TABLE - creates a new table

• ALTER TABLE - modifies a table

• DROP TABLE - deletes a table

• CREATE INDEX - creates an index (search key)

• DROP INDEX - deletes an index

 lOM oAR c P S D | 4933 057 1

SQL ELEMENTS

Elements of MySQL and Its Environment

You need to master several skills to run a database system. In this section, we’ll lay outwhat goes into
using MySQL and how we meet those needs in this book.

A MySQL installation has two components: a server that manages the data, and clients that ask the
server to do things with the data, such as change entries or provide reports. The client that you’ll
probably use most often is the mysql “MySQL monitor”program, provided by the MySQL AB
company and available in most MySQL installations. This allows you to connect to a MySQL server
and run SQL queries. Other simple clients are included in a typical installation; for example, the
mysqladmin programis a client that allows you to perform various server administration tasks.

In fact, any program that knows how to talk to the MySQL server is a client; a programfor a web-
based shopping site or an application to generate sales graphs for a marketingteam can both beclients.

PHP to write our own custom clients that run on a web server to present a web frontendto the
database for this. We’ll use the Apache web server (http://httpd.apache.org).

Apache has a long history of reliable service and has been the most popular web serverin the world
for over 10 years. The Apache web server—or “HTTP server”— projectis managed by the Apache
Foundation (http://www.apache.org). Although the webserver and MySQL server are separate
programs and can run on separate computers,it’s common to find small- to medium-scale
implementations that have both runningon a single computer.

Using the MySQL Monitor

MySQL has a client-server architecture; clients connect to the server to perform database operations
such as reading or storing data. There are many MySQL clients available,including some that have
graphical interfaces. You can also develop your own clients.

The standard MySQL command-line client or “monitor” program provided by MySQLAB is the
client you’ll probably use the most often. The monitor allows you to controlalmost all aspects of
database creation and maintenance using SQL and the custom MySQL extensions to SQL.

Here, we’ll examine how to start the monitor and how to run commands
lOM oAR c P S D | 4933 057 1

through the monitor either interactively or in batch mode. We’ll describe how you canaccess the
inbuilt
MySQL help functions, and how to test your MySQL setup using thesample databases from the book
web site. We’ll also take a quick look at a couple ofgraphical tools that you can use instead of the
monitor.
Starting the Monitor

The monitor program is called simply mysql and is found in a directory with the other MySQL
programs. The exact location depends on your operating system and how you chose to install
MySQL; we considered some of these in “Error Message About MySQL Executable Programs Not
Being Found or Recognized,”.

If your MySQL server isn’t already running, start it using the appropriate procedure foryour setup.
Now, follow these steps to start the monitor andconnect to your MySQL server as the MySQL
administrator (the MySQL root user) bytyping this from the command line:
$ mysql --user=root

MySQL root account is protected bythe password you chose earlier, and so you’ll get a message
saying that you’ve beendenied access to the server. If your server has a password, you should
specifythe
password as follows:

$ mysql --user=root --password=the_mysql_root_password

If you get a message from the operating system saying that it can’t find the MySQLprogram, you’ll
need to specify the full path to the mysql executable file as discussed in“Error Message About
MySQL Executable Programs Not Being Found or Recognized.”

If you used a nonstandard socket file when starting your server, you’ll need to providethe details to
any MySQL client programs you run, including mysql. For example, youmight type:

$ mysql \
--socket=server_socket \
--user=root \
--password=the_mysql_root_password
 lOM oAR c P S D | 4933 057 1

If you’re trying to connect to a MySQL server on a different computer or a nonstandardport, you

should specify these when starting the monitor: $mysql \

--host=server_host_name \
--port=server_port \
--user=root \
--password=the_mysql_root_password
Most of the other MySQL programs we’ll describe in this document take the same port andsocket
options to identify the server to connect to, and the same user and password options to identify and
authenticate the MySQL user.

If all goes well, you’ll get the monitor’s mysql> prompt:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 456 to server version: 5.0.22

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

You can now type in commands that MySQL understands. To start things off, ask the server what
version of MySQL it is:

mysql> SELECT VERSION();

+ +

| VERSION() |

+ +

| 5.0.22 |

+ +

1 row in set (0.03 sec)

You’ll almost certainly be using a different version number from the one we’re using.Now ask the
server to list all the databases that it has:
mysql> SHOW DATABASES;

+ +

| Database |
+ +
lOM oAR c P S D | 4933 057 1

| mysql |

| test |

+ +

2 rows in set (0.00 sec)

You may see different results on your MySQL server. There are two databases here; themysql database
is used to store information about user access privileges, and the testdatabase is an empty scratch space
for experimentation.

Style, Case, and Semicolons

When interacting with a MySQL server, you’ll use a combination of SQL keywords,MySQL
proprietary commands, and names of databases and database components.We follow common
convention and use a style to make it easier to distinguish between components of an SQL query. We
always show SQL statements and keywords in capitals, such as SELECT or FROM. We also show
the MySQL monitor’s proprietary SQLcommands—such as USE—in uppercase. We always enter
database components—suchas database, table, and column names—in lowercase. This makes our
SQL more readable and easier to follow in source code.

MySQL isn’t fussy about whether you enter SQL or the monitor’s proprietary statements in uppercase
or lowercase. For example, SELECT, select, Select, and evenSeLeCt are equivalent. However,
depending on your platform, MySQL can be fussy about database and table names. For example,
under Windows, MySQL isn’t fussy atall (because Windows itself isn’t fussy about the filenames that
store those structures),while on Mac OS X its fussiness depends on what underlying filesystem you
use to store disk files. Linux and Unix systems observe the difference between uppercase and
lowercase strictly. A reliable approach is to adopt the convention of using lowercase for all database,
table, and column names. You can control how MySQL manages different case behavior using an
option when you start the MySQL server, mysqld, but we don’t recommend you do this, and we don’t
discuss it further in this book.

There are some restrictions on what characters and words you can use in your database, table, and
other names. For example, you can’t have a column named from or select(in any mix of uppercase
 lOM oAR c P S D | 4933 057 1

and lowercase). These restrictions are mostly obvious, sincethey apply to reserved keywords that

confuse MySQL’s parser. You’ll notice that we terminate all SQL statements with the semicolon

character (;).

This tells MySQL that we’ve finished entering a statement and that it should now parseand execute it.
This gives you flexibility, allowing you to type in a statement over severallines. For example, the
following statement works fine:

mysql> SELECT User,Host

-> FROM user;

++ +

| User | Host |

+ + +

| | localhost |

| root | localhost |

| | saied-ltc.cs.rmit.edu.au |

| root | saied-ltc.cs.rmit.edu.au |

+ + +

4 rows in set (0.00 sec)

We often use this style in this book, because it helps long statements fit in the margins of a page.
Notice that the monitor shows you a different prompt (->) to indicate that it’s waiting for you to
entermore of your SQL statement or to type in a semicolon.

In fact, you can add whitespace—such as space and tab characters—anywhere between the
components of a statement to improve its formatting, and we often do this in our longer statements.
Of course, because whitespace separates keywords and values, you can’t add space within the
keywords or values themselves; for example, if you type the

keyword SELECT as SEL ECT, you’ll get an error. In contrast to SQL statements, you can’t span the
lOM oAR c P S D | 4933 057 1

MySQL monitor’s own commandsover more than one line. This is because the semicolon isn’t
actually required for these, and just pressing the Enter key has the same effect. For example, the
USEcommand tells MySQL that you want to use a particular database. The following works fine:
mysql> USE test

Database changed

However, if you try to span the command over more than one line, you won’t get far:

mysql> USE

ERROR:

USE must be followed by a database name

 lOM oAR c P S D | 4933 057 1

DATA COLLECTING

In order to structure data, one must first gather data elements and establish the domain to which this data
applies. This chapter deals with raw data information that comes from the users or other sources, and the
techniques that can help us to build a comprehensive data collection. This collection will become our input for
all further activities like data naming and grouping. To be able to build a data collection, we will first identify
the limits of the system. This will be followed by gathering documents in order to find significant data
elements. The next step will be to conduct interviews with key users in order to refine the list of data
elements.

System Boundaries Identification

Let's establish the scenario. We have been called by a local car dealer to submit a proposal about a new
information system. The stated goal is to produce reports about car sales and to help track the car inventory.
Reports are, of course, an output of the future system. The idea hidden behind reports could be to improve
sales, to understand delivery delays, or to find out why some cars disappear. The data structure itself is
probably not really important in the users' opinion, but we know that this structure matters to the developers
who produce the required output. It's important to first look at the project scope, before starting to work on the
details of the system. Does the project cover:

• The complete enterprise

• Just one administrative area
• Multiple administrative areas
• One function of the enterprise

An organization always has a main purpose; it can be selling cars, teaching, or providing web solutions. In
addition to this, every organization has sub-activities like human resource management, payroll, and
marketing. The approach to data collecting will vary, depending upon the exact area we are dealing with. Let's
say we learn that our car dealer also operates a repair shop, which has its own inventory, along with a car
rental service. Do we include these inventories in our analyzing tasks? We have to correctly understand the
place of this new information system in its context. When preparing a data model, the biggest challenge is
probably to draw a line, to clearly state where to stop. This is challenging for various reasons:
lOM oAR c P S D | 4933 057 1

• Our user might have only a vague idea of what they want, of the benefits they expect from the new system

• Conflicting interests might exist between our future users; some of them might want to prioritize issues in
a different way from others, maybe because they are involved with the tedious tasks that the new system
promises to eliminate
• We might be tempted to improve enterprise-wide information flow beyond the scope of this particular
project

It's not an easy task to balance user-perceived goals with the needs of the organization as a whole.

Modular Development

It is generally admitted that breaking a problem or task into smaller parts helps us to focus on more
manageable units and, in the long run, permits us to achieve a better solution, and a complete solution. Having
smaller segments means that defining each part's purpose is simpler and that the testing process is easier – as a
smaller segment contains less details. This is why, when establishing the system boundaries, we should think
in terms of developing by modules. In our case study, a simple way of dividing into modules would be the
following:

• Module 1: car sales

• Module 2: car inventory

Delivering an information system in incremental steps can help reassure the customer about the final product.
Defining the modules and a schedule about them can motivate users and also the developers. With a
publicized schedule, everyone knows what to expect. With the idea of modules comes the idea of budget and
the notion of priorities for development. Do we have to deliver the car sales module before or after the
inventory module? Can those modules be done separately? Are there some constraints that must be addressed,
like a new report about the car sales that the Chief Executive Officer (CEO) needs by June 20? Another point
to take into account is how the modules are related. Chances are good that some data will be shared between
modules, so the data model prepared for module 1 will probably be reused and refined during module 2
developments.
 lOM oAR c P S D | 4933 057 1

DATA GROUPING

In the previous chapters, we built a data collection, and started to clean it by proper naming. We had already
introduced, in Chapter 1, the notion of a table, which logically regroups information about a certain subject.
Some of the columns we gathered were grouped into tables during the naming process. While doing so, we
noticed that the process of name checking was sometimes leading us to decompose data into more tables, like
we did for the car_event and event tables. The goal of the present chapter is to provide finishing touches to
our structure, by examining the technique of grouping column names into tables. Our data elements won't be
living "in the air"; they will have to be organized into tables. Exactly which columns must be placed into
which table will be considered here.

Initial List of Tables

When building the structure, we can start by finding general, natural subjects which look promising for
grouping data. These subjects will provide our initial list of tables – here is an abridged example of what this
list might look like:

• vehicle
• customer
• event
• vehicle sale
• customer satisfaction survey
We'll begin our columns grouping work by considering the vehicle table.

Rules for Table Layout

There can be more than one correct solution, but any correct solution will tend to respect the following
principles:

• each table has a primary key

• no redundant data is present when considering all tables as a whole
lOM oAR c P S D | 4933 057 1

• all columns in a table depend directly upon all segments of the primary key

These principles will be studied in details in the following sections.

Primary Keys and Table Names

Let's start by defining the concept of a unique key. A column on which a unique key is defined cannot hold the
same value more than once for this table. The primary key is composed of one or more columns, it is a value
that can be used to identify a unique row in a table. Why do we need a primary key? MySQL itself does not
force us to have a primary key, neither a unique key nor any other kind of key, for a specific table. Thus
MySQL puts us under no obligation to follow Codd's rules. However, in practice it's important to have a
primary key; experience acquired while building web interfaces and other applications shows that it's very
useful to be able to refer to a key identifying a row in a unique way. In MySQL, a primary key is a unique key
where all columns have to be defined as NOT NULL; the name of this key is PRIMARY. Choosing the
primary key is done almost at the same time as choosing the table's name. Selecting the name of our tables is a
delicate process. We have to be general enough to provide for future expansion – like the vehicle table instead
of car and truck. At the same time, we try to avoid having holes – empty columns in our tables. To decide if
we should have a vehicle table or two separate tables, we look at the possible attributes for each kind of
vehicle. Are they common enough? Both vehicle types have a color, a model, a year, a serial number, and an
internal id number. , a model, a year, a serial number, and an internal id number.

Theoretically, the list of columns must be identical for us to decide that a group of columns will belong to a
single table; but we can cheat a bit, if there are only a few attributes that are different. Let's say we decide to
have a vehicle table. For reasons explained earlier, we want to track a vehicle since the moment we order it –
we'll use its internal id number as the primary key. When designing this table, we ask ourselves whether this
table can be used to store information about the vehicles we receive in exchange from the customer. The
answer is yes, since describing a vehicle has nothing to do with the transactions that happen to it (new vehicle
sold, used vehicle bought from the customer). The section Validating the Structure gives further examples that
can help catching problems in the structure. Here is version 1 of the vehicle table, with column names and
sample values – we mark the columns comprising the primary key with an asterisk:
 lOM oAR c P S D | 4933 057 1

DATA NAMING

In this chapter, we focus on transforming the data elements gathered in the collection process into a cohesive
set of column names. Although this chapter has sections for the various steps we should accomplish for
efficient data naming, there is no specific order in which to apply those steps. In fact, the whole process is
broken down into steps to shed some light on each one in turn, but the actual naming process applies all those
steps at the same time. Moreover, the division between the naming and grouping processes is somewhat
artificial – you'll see that some decisions about naming influence the grouping phase.

Data Cleaning

Having gathered information elements from various sources, some cleaning work is appropriate to improve
the significance of these elements. The way each interviewee named elements might be inconsistent;
moreover, the significance of a term can vary from person to person. Thus, a synonym detection process is in
order. Since we took note of sample values, now it is time to cross-reference our list of elements with those
sample values. Here is a practical example, using the car's id number. When the decision is made to order a
car – a Mitsou 2007 – the office clerk opens a new file and assigns a sequential number dubbed car_id number
to the file, for instance, 725.

At this point, no confirmation has been received from any car supplier, so the clerk does not know the future
car's serial number – a unique number stamped on the engine and other critical parts of the vehicle. This car's
id number is referred to as the car_number by the office clerk. The store assistants who register car
movements use the name stock_number. But using this car number or the stock number is not meaningful for
financing and insurance purposes; the car's serial number is used instead for that purpose.

At this point, a consensus must be reached by convincing users about the importance of standard terms. It
must become clear to everyone that the term car_number is not precise enough to be used, so it will be
replaced by car_internal_number in the data elements list, probably also in any user interface (UI) or report. It
can be argued that car_internal_number should be replaced by something more appropriate; the important
point here is we merged two synonyms: car_number and stock_number, and established the difference
between two elements that looked similar but were not, eliminating a source of confusion.

Car_serial_number
 lOM oAR c P S D | 4933 057 1

Car_internal_number (former car id number and stock number)

Eventually, when dealing with data grouping, another decision will have to be taken: to which number, serial
or internal, do we associate the car's physical key number.

Subdividing Data Elements

In this section, we try to find out if some elements should be broken into more simple ones. The reason for
doing so is that, if an element is composed of many parts, applications will have to break it for sorting and
selection purposes. Thus it's better to break the elements right now at the source. Recomposing it will be
easier at the application level. Breaking the elements provides more clarity at the UI level. Therefore, at this
level we will avoid (as much as possible) the well-known last-name/first-name inversion problem. As an
example for this problem, let's take the buyer's name. During the interview, we noticed that the name is
expressed in various ways on the forms:

Fig 4.1: Subdividing Data Elements

We notice that

• There is a salutation element, Mr

• The element name is too imprecise; we really have a first name and a last name
• On the sales contract, the comma after our last name should really be excluded from the element, as it's
only a formatting

As a result, we determine that we should sub-divide the name into the following elements:

• Salutation
• First name
• Last name
 lOM oAR c P S D | 4933 057 1

Sometimes it's useful to sub-divide an element, sometimes it's not. Let's consider the date elements. We could
sub-divide each one into year, month, and day (three integers) but by doing so, we would lose the date
calculation possibilities that MySQL offers. Among those are, finding the week day from a date, or
determining the date that falls thirty days after a certain date. So for the date (and time), a single column can
handle it all, although at the UI level, separate entry fields should be displayed for year, month, and day. This
is to avoid any possibility of mix-up and also because we cannot expect users to know about what MySQL
accepts as a valid date. There is a certain latitude in the range of valid values but we can take it for granted
that users have unlimited creativity, regarding how to enter invalid values. If a single field is present on the
UI, clear directions should be provided to help with filling this field correctly

Data Elements Containing Formatting Characters

The last case we'll examine is the phone number. In many parts of the world, the phone number follows a
specific pattern and also uses formatting characters for legibility. In North America, we have a regional code,
an exchange number, and phone number, for example, 418-111-2222; an extension could possibly be
appended to the phone number. However, in practice only the regional code and extension are separated from
the rest into data elements of their own. Moreover, people often enter formatting characters like (418) 111-
2222 and expect those to be output back. So, a standard output format must be chosen, and then the correct
number of sub- elements will have to be set into the model to be able to recreate the expected output.

Data that are Results

Even though it might seem natural to have a distinct element for the total_price of the car, in practice this is
not justified. The reason is that the total price is a computed result. Having the total price printed on a sales
contract constitutes an output. Thus, we eliminate this information in the list of column names. For the same
reason, we could omit the tax column because it can be computed.

By removing the total price column, we could encounter a pitfall. We have to be sure that we can reconstruct
this total price from other sub-total elements, now and in the future. This might not be possible for a number
of reasons.
 lOM oAR c P S D | 4933 057 1

DATA STRUCTURE TUNING

This chapter presents various techniques to improve our data structure in terms of security, performance, and
documentation. We then present the final data structure for the car dealer's case study.

Data Access Policies

We saw in Chapter 1 that data is an important resource, so access to this resource must be controlled and
clearly documented. As each piece of data originates, the responsibility for data entry must be clearly
established. After the data has made its way into the database, policies must be in place to control access to it,
and these policies are implemented by MySQL's privileges and the use of views.

Responsibility

We should determine who in the enterprise – in terms of a person's name or a function name – is responsible
for each data element. This should then be documented and a good place to do so is directly in the database
structure. An alternative would be to document data responsibility on paper, but information on paper can be
easily lost and has a tendency to become obsolete quickly. In some cases, there will be a primary source and
an approbation-level source. Both should be documented – this helps for

• application design, when screens have to reflect the chain of authority for data entry
• privilege management, if direct MySQL data access is granted to end users o end
users
phpMyAdmin permits us to describe each column by adding comments to it. If the current MySQL version
supports native comments, those will be used; otherwise, phpMyAdmin's linked-tables infrastructure has to be
configured to enable the storage of column comments as meta-data. We will indicate responsibility details for
this column in the corresponding column comment. To reach the page that permits us to enter comments in
phpMyAdmin, we use the left navigation panel to open the database (here marc) then the table (here
car_event). We then click on Structure and choose to edit a field's structure (here event_code) by clicking on
the pencil icon.
 lOM oAR c P S D | 4933 057 1

Fig 4.2: Editing of Structure

Security and Privileges

There are two ways of considering the security of our data. The first and most commonly implemented is at
the application level. Normally, applications should ask for credentials: user name, password, and use these
credentials to generate web pages or desktop screens that reflect the tasks permitted to this user. Note that the
underlying application still connects to MySQL with all the privileges of a developer account but, of course,
only shows appropriate data according to the user's rights. Another issue to consider is when a user has direct
access to MySQL, either using a command-line utility or an interface like phpMyAdmin. This might be the
case because the end-user application has been developed only to a certain point and does not permit
maintenance of code tables, for example. In this case, special MySQL users should be created that have only
the needed rights. MySQL supports an access matrix based on rights on databases, tables, columns, and views.
This way, we could hide specific columns, like the selling price, to all unauthorized persons.
lOM oAR c P S D | 4933 057 1

DATABASE

Modeling and Designing Databases

When implementing a new database, it’s easy to fall into the trap of trying to quicklyget something up
and running without dedicating adequate time and effort to the design. This carelessness frequently
leads to costly redesigns and re-implementations down the track. Designing a database is similar to
drafting the blueprints for a house; it’s silly to start building without detailed plans. Importantly, good
design allows you to extend the original building without having to pull everything down and start
from scratch.

How Not to Develop a Database

Database design is probably not the most exciting task in the world, but it’s still important. Before we
describe how to go about the design process, let’s look at an example of database design on the run.
Imagine we want to create a database to store student grades for a university computer science
department. We could create a Student_Grades table to store grades for each student and each course.
The table would have columns for the given names and the surname of each student as well as for
each course they have taken, the course name, and the percentage result. We’d have a different row
for each student for each of their courses:

Table 5.1:Different row for each student for each of their courses
 lOM oAR c P S D | 4933 057 1

This is nice and compact, and we can easily access grades for any student or any course.However, we
could have more than one student called Susan Smith; in the sample data,there are two entries for
Susan Smith and the Computing Mathematics course.

Which Susan Smith got an 80? A common way to differentiate duplicate data entries is to assign a
unique number to each entry. Here, we can assign a unique Student ID number to each student:

Table 5.2:Assigning a Unique Student ID number

So, the Susan Smith who got 80 is the one with the Student ID number 12345303.

There’s another problem. In our table, John Paul Bloggs has failed the ComputingMathematics course
once with 43 percent, and passed it with 65 percent in his secondattempt. In a relational database, the
rows form a set, and there is no implicit orderingbetween them; you might guess that the pass
happened after the fail, but you can’tactually be sure. There’s no guarantee that the newer grade will
appear after the olderone, so we need to add information about when each grade was awarded, say by
addinga year and semester (Sem):

Table 5.3:Adding year and semester to students

 lOM oAR c P S D | 4933 057 1

Notice that the Student_Grades table has become a bit bloated: the student ID, givennames, and surname
are repeated for every grade.

We could split up the information and create a Student_Details table:

Table 5.4:Creating a Student details table

and keep less information in the Student_Grades table:

Table 5.5:Student Grades table

To look up a student’s grades, we’d need to first look up her Student ID from theStudent_Details table
and then read the grades for that Student ID from the Student_Grades table.

There are still issues we haven’t considered. For example, should we keep informationon a student’s
enrollment date, postal and email addresses, fees, or attendance? Shouldwe store different types of
postal address? How should we store addresses so that thingsdon’t break when a student changes his
address?
 lOM oAR c P S D | 4933 057 1

Implementing a database in this way is problematic; we keep running into things we hadn’t thought
about and have to keep changing our database structure. Clearly, we can save a lot of reworking by
carefully documenting the requirements and then working through them to develop a coherentdesign.

The Database Design Process

There are three major stages in database design, each producing a progressively lowerlevel
description:

Requirements analysis

• First, we determine and write down what exactly the database is needed for, whatdata will be stored,
and how the data items relate to each other. In practice, thismight involve detailed study of the
application requirements and talking to peoplein various roles that will interact with the database
andapplication.

Conceptual design

• Once we know what the database requirements are, we distill them into a formaldescription of the
database design. In this chapter, we’ll see how to use modelingto produce the conceptual design.

Logical design

• Finally, we map the database design onto an actual database management systemand database tables

Fig 5.1:An entity set is represented by a named rectangle

At the end of the chapter, we’ll look at how we can use the open source MySQL Workbench tool to
automatically convert the conceptual design to a MySQL database schema.
lOM oAR c P S D | 4933 057 1

RELATIONSHIP

The Entity Relationship Model

At a basic level, databases store information about distinct objects, or entities, and theassociations, or
relationships, between these entities. For example, a university databasemight store information about
students, courses, and enrollment. A student and acourse are entities, while an enrollment is a
relationship between a student and a course.

Similarly, an inventory and sales database might store information about products,customers, and
sales. A product and a customer are entities, while a sale is a relationshipbetween a customer and a
product.

A popular approach to conceptual design uses the Entity Relationship (ER) model,which helps
transform the requirements into a formal description of the entities andrelationships that appear in the
database. We’ll start by looking at how the Entity

Relationship modeling process itself works, then apply it in “Entity Relationship Modeling
Examples” for three sample databases.

Representing Entities

To help visualize the design, the Entity Relationship Modeling approach involvesdrawing an Entity
Relationship (ER) diagram. In the ER diagram, an entity set is represented by a rectangle containing
the entity name.

We typically use the database to store certain characteristics, or attributes, of the entities. In a sales
database, we could store the name, email address, postal address, andtelephone number for each
customer. In a more elaborate customer relationship managment (CRM) application, we could also
store the names of the customer’s spouseand children, the languages the customer speaks, the
customer’s history of interactionwith our company, and so on. Attributes describe the entity they
belong to
 lOM oAR c P S D | 4933 057 1

An attribute may be formed from smaller parts; for example, a postal address is composed of a street
number, city, ZIP code, and country. We classify attributes as composite if they’re composed of
smaller parts in this way, and as simple otherwise.

Some attributes can have multiple values for a given entity. For example, a customercould provide
several telephone numbers, so the telephone number attribute ismultivalued.

Attributes help distinguish one entity from other entities of the same type. We coulduse the name
attribute to distinguish between customers, but this could be an inadequate solution because several
customers could have identical names. To be able to tellthem apart, we need an attribute (or a
minimal combination of attributes) guaranteedto be unique to each individual customer. The
identifying attribute or attributes forma key.

In our example, we can assume that no two customers have the same email address,so the email
address can be the key. However, we need to think carefully about theimplications of our choices.For
example, if we decide to identify customers by theiremail address, it would be hard to allow a
customer to have multiple email addresses.

Any applications we build to use this database might treat each email address as aseparate person, and
it might be hard to adapt everything to allow people to havemultiple email addresses. Using the email
address as the key also means that everycustomer must have an email address; otherwise, we
wouldn’t be able to distinguishbetween customers who don’t have one.

Looking at the other attributes for one that can serve as an alternative key, we see thatwhile it’s
possible that two customers would have the same telephone number (and sowe cannot use the
telephone number as a key), it’s likely that people who have the sametelephone number never have
the same name, so we can use the combination of thetelephone number and the name as a composite
key.

Clearly, there may be several possible keys that could be used to identify an entity; wechoose one of
the alternative, or candidate, keys to be our main, or primary, key. Youusually make this choice based
on how confident you are that the attribute will be nonempty and unique for each individual entity,
and on how small the key is (shorter keysare faster to maintain and use).

In the ER diagram, attributes are represented as labeled ovals and are connected to their owning
entity. Attributes comprising the primary key are shownunderlined. The parts of any composite
attributes are drawn connected to the oval ofthe composite attribute, and multivalued attributes are
shown as double- lined ovals.
lOM oAR c P S D | 4933 057 1

Attribute values are chosen from a domain of legal values; for example, we could specifythat a
customer’s given names and surname attributes can each be a string of up to 100characters, while a
telephone number can be a string of up to 40 characters. Similarly,a product price could be a positive
rational number.

Fig 6.1:The ER diagram representation of the customer entity

Attributes can be empty; for example, some customers may not provide their telephone numbers. The
primary key of an entity (including the components of a multiattribute primary key) must never be
unknown (technically, it must be NOT NULL); for example, if it’s possible for a customer to not
provide an email address, we cannot use the email address as the key. You should think carefully
when classifying an attribute as multivalued: are all the values equivalent, or do they in fact
representdifferent things? For example, when listing multiple telephone numbers for a customer,
would they be more usefully labeled separately as the customer’s business phone number, home
phone number, cell phone number, and so on? Let’s look at another example. The sales database
requirements may specify that a product has a name and a price. We can see that the product is an
entity because it’s a distinct object. However, the product’s name and price aren’t distinct objects;
they’re attributes that describe the product entity. Note that if we want to have different prices for
different markets, then the price is no longer just related to the product entity, and we’d need to model
it differently. For some applications, no combination of attributes can uniquely identify an entity (or it
 lOM oAR c P S D | 4933 057 1

would be too unwieldy to use a large composite key), so we create an artificial attribute that’s defined
to be uniqueand can therefore be used as a key: student numbers, Social Security numbers, driver’s
license numbers, and library card numbers are examples of unique attributes created for various
applications.

In our inventory and sales application, it’s possible that we could stock different products with the
same name and price. For example, we could sell two models of “Four-port USB 2.0 Hub,” both at
$4.95 each. To distinguish between products, we can assign a unique product ID number to each item
we stock; this would be the primary key. Each product entity would have name, price, and productID
attributes.

Fig 6.2:The ER diagram representation of the product entity

Representing Relationships

Entities can participate in relationships with other entities. For example, a customercan buy a product,
a student can take a course, an artist can record an album, and soon. Like entities, relationships can
have attributes: we can define a sale to be a relationship between a customer entity (identified by the
unique email address) and a given number of the product entity (identified by the unique product ID)
that exists ata particular date and time (the timestamp). Our database could then record each sale and
tell us, for example, that at 3:13 p.m. on Wednesday, March 22, Ali Thomson bought one “Four-port
USB 2.0 Hub,” one “300 GB 16 MB Cache 7200 rpm SATA Serial ATA133
HDD Hard Disk,” and two sets of “2000 Watt 5.1 Channel Sub- Woofer Speakers.” Different
numbers of entities can appear on each side of a relationship. For example, each customer can buy
any number of products, and each product can be bought by any number of customers. This is known
as a many- to-manyrelationship. We can also have one-to-many relationships. For example, one
personcan have several credit cards, but each credit card belongs to just one person. Looking at it the
other way, a one-tomany relationship becomes a many-to-one relationship; forexample, many credit
lOM oAR c P S D | 4933 057 1

cards belong to a single person. Finally, the serial number on a car engine is an example of a one-to-
one relationship; each engine has just one serial number, and each serial number belongs to just one
engine. We often use the shorthand terms 1:1, 1:N, and M:N for one-to-one, one-to-many, and many-
to-many relationships, respectively. The number of entities on either side of a relationship (the
cardinality of the relationship) define the key constraints of the relationship. It’simportant to think
about the cardinality of relationships carefully. There are many relationships that may at first seem to
be one-to- one, but turn out to be more complex. For example, people some times change their
names; in some applications, such as police databases, this is of particular interest, and so it may be
necessary to model a many-to-many relationship between a person entity and a name entity.
Redesigning a database can be time-consuming if you assume a relationship is simpler than it really
is.

Fig 6.3:The ER diagram representation of the customer &product entity & sale relationship

Entity or Relationship?

An easy way to decide whether an object should be an entity or a relationship is to map nouns in the
requirements to entities, and to map the verbs to relations. For example, in the statement, “A degree
program is made up of one or more courses,” we can identify the entities “program” and “course,”
and the relationship “is made up of.” Similarly, in the statement, “A student enrolls in one program,”
we can identify the entities “student” and “program,” and the relationship “enrolls in.” Of course, we
 lOM oAR c P S D | 4933 057 1

can choose different terms for entities and relationships than those that appear in the relationships,but
it’s a good idea not to deviate too far from the naming conventions used in the

Fig 6.4:The ER diagram representation of the student grades as attributes of the student entity

Fig 6.5:The ER diagram representation of the student grades as a separate entity

requirements so that the design can be checked against the requirements. All else being

equal, try to keep the design simple, and avoid introducing trivial entities where possible; i.e., there’s
no need to have a separate entity for the student’s enrollment when we can model it as a relationship
between the existing student and program entities.
lOM oAR c P S D | 4933 057 1

Fig 6.6:A passenger participates in an M:N relationship with flight

Weak and Strong Entities

Context is very important in our daily interactions; if we know the context, we can work with a much
smaller amount of information. For example, we generally call family members by only their first
name or nickname. Where ambiguity exists, we add further information such as the surname to clarify
our intent. In database design, we can omit

Fig 6.7:The intermediate booking entity b/w the passenger & flight entities

some key information for entities that are dependent on other entities. For example, if we wanted to
store the names of our customers’ children, we could create a child entity and store only enough key
information to identify it in the context of its parent. We could simply list a child’s first name on the
assumption that a customer will never have several children with the same first name. Here, the child
entity is a weak entity, and its relationship with the customer entity is called an identifying
relationship. Weak entities participate totally in the identifying relationship, since they can’t exist in
the database independently of their owning entity. In the ER diagram, we show weak entities and
 lOM oAR c P S D | 4933 057 1

identifying relationships with double lines, and the partial key of a weak entity with a dashed
underline. A weak entity is uniquely identified in the context of its regular (or strong) entity, and so
the full key for a weak entity is the combination of its own (partial) key with the key of its owning
entity. To uniquely identify a child in our example, we need the first name of the child and the email
address of the child’s parent.

Entity Relationship Modeling Examples

Earlier in this chapter, we showed you how to design a database and understand an Entity
Relationship (ER) diagram. This section explains the requirements for our three example databases—
music, university, and flight—and shows you their Entity Relationship diagrams:

The music database is designed to store details of a music collection, including the albums in
the collection, the artists who made them, the tracks on the albums, and when each track was last
played.

Fig 6.8:The ER diagram representation of a weak entity

lOM oAR c P S D | 4933 057 1

The Music Database

The music database stores details of a personal music library, and could be used to manage your MP3,
CD, or vinyl collection. Because this database is for a personal collection, it’s relatively simpleand
stores only the relationships between artists, albums, and tracks. It ignores the requirements of many
music genres, making it most useful for storing popular music and less useful for storing jazzor
classical music. (We discuss some shortcomings of these requirements at the end of the section in
“What it doesn’t do.”) We first draw up a clear list of requirements for our database:

Fig 6.9:Quick summary of the ER diagram symbols

The collection consists of albums.

• An album is made by exactly one artist.

• An artist makes one or more albums.

• An album contains one or more tracks

• Artists, albums, and tracks each have a name.

• Each track is on exactly one album.

 lOM oAR c P S D | 4933 057 1

• Each track has a time length, measured in seconds.

• When a track is played, the date and time the playback began (to the nearest second) should be
recorded; this is used for reporting when a track was last played, as well as the number of
timesmusic by an artist, from an album, or a track has been played. There’s no requirement to
capture composers, group members or sidemen, recording date or location, the source media, or
any other details of artists, albums, or tracks. You’ll notice that it consists of only one-to-many
relationships: one artist can make many albums, one album can contain many tracks, and one
track can be played many times. Conversely, each play is associated with one track, a track is on
one album, and an album is by one artist. The attributes are straightforward: artists, albums, and
tracks have names, as well as identifiers to uniquely identify each entity. The track entity has a
time attribute to store the duration, and the played entity has a timestamp to store when the track
was played.

Fig 6.10:The ER diagram of the music database

The only strong entity in the database is Artist, which has an artist_id attribute that uniquelyidentifies
it. Each Album entity is uniquely identified by its album_id combined with the artist_id of the
corresponding Artist entity. A Track entity is similarly uniquely identified by its track_id combined
lOM oAR c P S D | 4933 057 1

with the related album_id and artist_id attributes. The Played entity is uniquely identified by a
combination of its played time, and the related track_id, album_id, and artist_id attributes.

What it doesn’t do We’ve kept the music database simple because adding extra features doesn’t help
you learn anything new, it just makes the explanations longer. If you wanted to use the music
database in practice, then you might consider adding the following features:

• Support for compilations or various-artists albums, where each track may be by a different artist
and may then have its own associated album-like details such as a recording date and time. Under
this model, the album would be a strong entity, with many-to-many relationships between artists
and albums.
• Playlists, a user-controlled collection of tracks. For example, you might create a playlist of
yourfavorite tracks from an artist.
• Track ratings, to record your opinion on how good a track is.
• Source details, such as when you bought an album, what media it came on, how much you paid,
andso on.
• Album details, such as when and where it was recorded, the producer and label, the band
members orsidemen who played on the album, and even its artwork.
• Smarter track management, such as modeling that allows the same track to appear on many
albums
 lOM oAR c P S D | 4933 057 1

CREATING A LOGIN PAGE AND LINKING IT TO THE DATABASE

This chapter will demonstrate how a simple database can be linked to a web page so that the page can
interact with users. The general public will have access to the web site but will not have access to the
database structure or the data contained in the tables. They will not be permitted to view the protected
pages, such as a members-only page, because they have no password until they register. However, the
web designer must provide a way for users to interact with the database in order to (i) register as a
member, (ii) search the database, and (iii) change a password. The PHP language and MySQL code
provide the solution.
This chapter covers the following main topics:

• Creating a folder for the database

• Creating the database and a template for the web site pages
• Introducing the PHP include function
• Creating the included pages
• How does the server process a PHP page?
• An interactive version of the template page
• Connecting to the database • Creating a registration page for members
• The PHP keyword echo()
• Styling forms
• Sticky forms
• Using arrays
• Displaying members’ records
• Changing a password
• Dealing with apostrophes
• More about using arrays

We will use the simpleIdb database and the users table from the previous projects for our
interactive web pages. Be aware that this tutorial is neither secure nor practical. It is astepping
stone to the more secure and ambitious projects described in subsequent chapters. In practice,
you would never allow ordinary members to view a list of members. The interactive elements
in this project are as follows:
lOM oAR c P S D | 4933 057 1

1. Users can register as members by inserting their details into a form displayed on the screen. The
registration details would be entered into the database table and could be used by the
administrator to send regular newsletters to members.
2. Registered users can change their password.

3. A user can view the list of members (for this project only). In later chapters, this facility would be
available only to the webmaster and (to a limited extent) the membership secretary. The features
that make this example unsuitable for the real-world are as follows:
4. No provision is made for registered members to subsequently log in to access a special section or
page.
5. Users should never be able to access a table of members’ details.
6. At this early stage, for simplicity, no filtering of the users’ information is provided. The table
could therefore contain faulty data and bogus e-mail addresses.
7. In this chapter only, any user who knows a member’s e-mail address could change the member’s
password.

All these security issues will be dealt with in subsequent chapters. Despite the drawbacks,
the project will provide you with valuable practice in using your XAMPP program to test
the pages. You will also learn more database jargon and some basic PHP code.

Fig 6.11:Header Page

 lOM oAR c P S D | 4933 057 1

Fig 6.12:Register Page

19JN1A04I3 My SQL

SCREENSHOTS
 CONCLUSION

MySQL triggers allow you to execute stored program code whenever a DML statement is issued
against a database table. In MySQL 5.0, triggers can be used to automate denormalization or
loging.

Implementation of data validation in MySQL triggers is more of a challenge, as in MySQL there

is no easy or straightforward way to raise an error condition or abort the transaction when
validation fails. This will be remedied when the SIGNAL statement is implemented in MySQL
5.2. Through this internship, we presented a workaround that does allow data validation triggers
to be created in the interim, although the error text generated is far from ideal.