Ppt Second Viva

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).


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.


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


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.


5/20


6/20

Relation Design


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/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


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


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


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


12/20

2.1.6 Table name: news


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



13/20

2.1.7 Table name: players


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


14/20

2.1.8 Table name: results


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


15/20

2.1.9 Table name: scrapbook


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


sdatetime datetime No Date & time


16/20

2.1.10 Table name: teams


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


createddate Date No Create date


17/20

2.1.11 Table name: tournaments


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



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


2 1 13 Table name: users


19/20

2.1.13 Table name: users


userid int 10 Primary key No User

identification

codename varchar 25 No Name

username varchar 20 No Username

password varchar 20 No Password


2.1.14 Table name: videos


videoid int 10 Primary key No Video

identification

code

videopath varchar 500 No Video path

description text No Description


3 1


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

Ppt Second Viva

Documents

Transcript of Ppt Second Viva