Transcript
8/12/2019 Ppt Second Viva
1/20
1.1 Entity Relationship Diagram
Entity Relationship Diagrams (ERDs) illustrate the logical structure of
databases.
A set of primary components are defined for the E-R Diagram : data
object, attributes, relationships and various type indicators. The primary
purpose of the E-R diagram is to represent data objects and their
relationships.
Data Objects: A data object is a representation of almost any compositeinformation that must be understood by software. Components
information refers to something that has a number of different
properties or attributes.
A data object can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display) or event (e.g.
, salesperson), an organizational unit (e.g., accounting department), a
place(e.g., a warehouse), or a structure (e.g., a file).
8/12/2019 Ppt Second Viva
2/20
Entity Relationship Diagram Notations:
EntityAn entity is an object or concept about which you want to store information.
eak EntityA weak entity is an entity that must defined by a foreign key relationship with
another entity as it cannot be uniquely identified by its own attributes alone.
Key attributeA key attribute is the unique, distinguishing characteristic of the entity. For
example, an employee's social security number might be the employee's key
attribute.
8/12/2019 Ppt Second Viva
3/20
Multivalued attribute
A multivalued attribute can have more than one value. For example, an employee
entity can have multiple skill values.
Derived attribute
A derived attribute is based on another attribute. For example, an employee'smonthly salary is based on the employee's annual salary.
Relationships
Relationships illustrate how two entities share information in the database structu
8/12/2019 Ppt Second Viva
4/20
CardinalityCardinality specifies how many instances of an entity relate to one instance of
another entity.
Ordinality is also closely linked to cardinality. While cardinality specifies the
occurences of a relationship, ordinality describes the relationship as eithermandatory or optional. In other words, cardinality specifies the maximum number
of relationships and ordinality specifies the absolute minimum number of
relationships.
Taking into consideration all combinations of one and many, two objects can be
as:One-to-one (1:1) An occurrence of [object] A can relate to one and only one
occurrence of [object] B, and an occurrence of B can relate to only one
occurrence of A.
One-to-many (1:N) One occurrence of [object] A can relate to one or many
occurrences of [object] B, but an occurrence of B can relate to only one
occurrence of [object] A.
Many-to-many(M:N) An occurrence of [object] A can relate to one or more
occurrence of B, while an occurrence of B can relate to one or more
occurrences of A.
8/12/2019 Ppt Second Viva
5/20
8/12/2019 Ppt Second Viva
6/20
Relation Design
8/12/2019 Ppt Second Viva
7/20
2.1 Table Design
2.1.1 Table name: advertisers
Field name DataType Size Constraints Null Description
advertsmentid Int 10 Primary Key No Advertisement
Identification
code
advertisement varchar 50 No Advertisement info
image varchar 500 No Advertisement
image
position varchar 50 No Position of the
advertisements
status varchar 10 No Shows Ads are
active/inactive
8/12/2019 Ppt Second Viva
8/20
2.1.2 Table name: batperformance
Field name Data Type Size Constraints Null Description
batperformanceid int 10 Primary key No Batting identification
code
fixtureid int 10 Foreign key No Fixture identification
code
playerid int 10 Foreign key No Player identification
code
catchid int 10 No Catch identification
code
bowledid int 10 No Bowled identification
code
dismisstype varchar 25 No Dismiss type
runs int 10 No Runs
balls int 10 No Balls
fours int 10 No Fours Scored
sixes int 10 No Sixes Scoreddismissovers int 10 No Dismiss over
8/12/2019 Ppt Second Viva
9/20
2.1.3 Table name: bowlingperformance
Field name Data
Type
Size Constraints Null Description
bowlperformanceid int 10 Primary key No Bowling
identification
code
fixtureid int 10 Foreign Key No Fixture
identification
code
playerid int 10 Foreign Key No Player
identification
code
overs float (10,2) No Overs
maidens Int 10 No Maiden overs
runs Int 10 No Runs
wickets Int 10 No Wickets
8/12/2019 Ppt Second Viva
10/20
2.1.4 Table name: fixtures
Field name Data Type Constraints Null Description
fixtureid int 10 Primary key No Fixture
identificationcode
tournamentid int 10 Foreign Key No Tournament
identification
code
teamid1 int 10 No Team 1identification
code
teamid2 int 10 No Team 2
identification
code
venue varchar 25 No Match Venue
fixdatetime datetime No Fixture date &
time
matchtype varchar 25 No Match type
8/12/2019 Ppt Second Viva
11/20
2.1.5 Table name: galleryField name Data Type Size Constraints Null Description
galleryid int 10 Primary key No Bowling
identification
code
id int 10 No Identification
code
type int 10 No Gallery type
imagepath varchar 250 No Image path
description text No description
date date No date
status varchar 10 No status
8/12/2019 Ppt Second Viva
12/20
2.1.6 Table name: news
Field name Data Type Size Constraints Null Description
newsid Int 10 Primary key No Newsidentification
code
publishingdate Date No Publish date
newstitle varchar 150 No News title
Image varchar 250 No Image
newsdescriptio
n
Text No News
description
status varchar 10 No status
8/12/2019 Ppt Second Viva
13/20
2.1.7 Table name: players
Field name Data Type Size Constraints Null Description
playerid int 10 Primary key No Player
identification
codeteamid int 10 Foreign Key No team
identification
code
name varchar No Players name
dob date No Date of birthpetname varchar No Pet name
playingrole varchar 50 No Playing role
battingstyle varchar 50 No Batting role
bowlingstyle varchar 50 No Bowling role
playerprofile text No Player profile
profilepic varchar 50 No Profile picture
phoneno varchar 25 No Phone number
createddate date No Created date
status varchar 25 No Status
8/12/2019 Ppt Second Viva
14/20
2.1.8 Table name: results
Field name Data Type Size Constraints Null Description
resultid int 10 Primary key No Result identification
code
fixtureid int 10 Foreign Key No Fixture identification
code
team1score int 10 No Team 1 score
team2score int 10 No Team 2 score
tossid int 10 No toss identification
code
comment text No comments
8/12/2019 Ppt Second Viva
15/20
2.1.9 Table name: scrapbook
Field name Data Type Size Constraints Null Description
sbid Int 10 Primary key No Scrapbookidentification
code
Typeid Int 10 No typeidentification
code
name varchar 20 No Name
posttype varchar 10 No Post type
message text No message
status varchar 25 No status
sdatetime datetime No Date & time
8/12/2019 Ppt Second Viva
16/20
2.1.10 Table name: teams
Field name Data Type Size Constraints Null Description
teamid Int 10 Primary key No Team
identificationcode
teamname varchar 50 No Team name
teamlogo varchar 75 No Team logo
teaminfo Text No Team info
teamowner
s
varchar 50 No Team owners
teamorgani
ser
varchar 50 No Team
organizers
address Text No Address
contactno varchar 15 No Contact
number
status varchar 10 No Status
createddate Date No Create date
8/12/2019 Ppt Second Viva
17/20
2.1.11 Table name: tournaments
Field name Data Type Size Constraints Null Description
tournamentid
Int 10 Primary key No Tournamentidentificatio
n code
type varchar 25 No Tournamenttype
name varchar 50 No Tournament
name
noofteams Int 10 No Number of
teams
startdate date No Start date
enddate date No End date
overs int 10 No Overs
status varchar 10 No Status
8/12/2019 Ppt Second Viva
18/20
2.1.12 Table name: tournamentteams
Field name DataType Size Constraints Null Description
tournamentteamsid int 10 Primary key No Tournamentteam
identification
code
tournamentid int 10 Foreign Key No Tournament
identification
code
teamid int 10 Foreign Key No teamidentification
code
description text No Description
status varchar 10 No Status
2 1 13 Table name: users
8/12/2019 Ppt Second Viva
19/20
2.1.13 Table name: users
Field name Data Type Size Constraints Null Description
userid int 10 Primary key No User
identification
codename varchar 25 No Name
username varchar 20 No Username
password varchar 20 No Password
status varchar 10 No Status
2.1.14 Table name: videos
Field name Data Type Size Constraints Null Description
videoid int 10 Primary key No Video
identification
code
videopath varchar 500 No Video path
description text No Description
status varchar 10 No Status
3 1
8/12/2019 Ppt Second Viva
20/20
3.1 Normalization
Normalization provides for table optimization through the investigation of
entity relationships. Main purpose of normalization is to avoid Data
redundancy and some unforeseen scalability factors. Normalization is done
to remove Insertion, Updating and Modification anomalies and redundancy
of data. A certain level of normalization of tables in database gives a
particular normal form based of particulars steps followed. Database can be
normalized up to any defined normal forms according as the need of
application and its effectiveness.
Database of Gonzaga Student Information system is normalized up to Third
Normal Form. Further normalization of database was not considered takinginto account the need of application and ease of working with database.
The database is not in First Normal Form as all the fields of all tables are not
atomic. There are two multivalued fields in the above tables i.e Address and
Main Subjects.
The database is in Second Normal Form as it satisfies the constraint of fullfunctional dependency. All the fields of all tables are fully functional dependent
on the primary key.
The database is in Third Normal Form as all its tables satisfy the constraint
that there should be no transitive dependency. No field has transitive
dependency on the key field. Thus database also satisfies the constraints ofthird normal form
top related