chap3 design strategy

8/6/2019 Chap3 Design Strategy

1/22

Zwwinger: Major Project Report 2011

Chapter 3

DESIGN STRATEGY

Sikkim Manipal Institute Of Technology Page 20


2/22


3. DESIGN STRATEGY FOR THE SOLUTION:

3.1 Data Flow Diagram:

Request Response

Request

Respon

se

Request Response

Figure: 3.1. Context diagram or 0 Level DFD Diagram


Administrator

ZWWINGER

System

0

0

New User

Existing User


3/22




4/22


LEVEL 1 DFD

Request Emailid, password

User User Data

Retrieve Data

Registration Data User Data User Data

USER ACCOUNT DB

Updated Data User Data Searched Data

UserInformation User Information User Name

Fig: 3.2 LEVEL 1 DFD


Sign Up

0.1

User

Sign In

0.2

View

0.3

Manage profile

0.4

Manage

activities

0.5

Search friends

0.6


5/22


LEVEL 2 DFD FOR USER SIGN UP

Invalid Data

User Data

UserData

Valid Data

USER ACCOUNT DB

Fig: 3.3 LEVEL 2 DFD FOR USER SIGN UP

LEVEL 2 DFD FOR USER SIGNIN

Emailid, password

Invalid Data Authentic user

Emailid, password

User Data UserData

Display information


Get user

Registration

0.1.1

Verify

0.1.2

Get user

Sign in

details

0.2.1

0.1.1

Authenticate

0.2.2

View user

home

0.2.3


6/22


USER ACCOUNT DB

Fig: 3.4 LEVEL 2 DFD FOR USER SIGNIN

LEVEL 2 DFD FOR VIEW

SCRAPS DB

Display RetrieveScraps Display Display User Data

User Data Retrieve Comments Retrieve Request Retrieve Picture

COMMENTS DB FRIEND REQUEST DB PICTURE INFO DB

User Data Display

User Data

RetrieveMessage Display

MESSAGE DB User Data


View Scraps

0.3.1

0.1.1

View Picture

0.3.4

View

PictureComments

0.3.2

0.1.1

View Friend

Request

0.3.3

0.1.1

View

Message

0.3.5

0.1.1


7/22


USERACCOUNT DB

Fig: 3.5 LEVEL 2 DFD FOR CHECKING

LEVEL 2 DFD FOR MANAGE PROFILE

UserData

Invalid Data Valid Data

User Data

USERACCOUNT DB

NewUserData

Fig: 3.6 LEVEL 2 DFD FOR MANAGE PROFILE


Get ProfileDetails

0.4.1

0.1.1

Validate Data

0.4.2

Update

Profiles

0.4.3


8/22


LEVEL 2 DFD FOR MANAGE ACTIVITIES

USERACCOUNT DB

User Data

UserData User Data User Data User Data

Scrap Retrieve Comment Retrieve Friends Retrieve Picture Retrieve

Data scrap Data Comment Data Request Data Picture

SCRAPS DB COMMENTS DB FRIEND REQUEST DB PICTURE DB

User Data


Send/Delete

Scraps

0.5.1

0.1.1

View/Remove

Picture

0.5.4

Send/Delete

Comments

0.5.2

0.1.1

View Friend

Request

0.5.3

0.1.1

Send/Delete

Message

0.5.5

0.1.1

Report

0.5.6

0.1.1


9/22


MessageData Retrieve Message User Data

MESSAGE DB FEEDBACK DB

Fig: 3.7 LEVEL 2 DFD FOR MANAGE ACTIVITIES

LEVEL 2 DFD FOR SEARCH FRIENDS

User Data

User Information Display

Retrieve Data User Name

USER ACCOUNT DB

Fig: 3.8 LEVEL 2 DFD FOR SEARCH FRIENDS


Search

0.6.1

Prepare List

0.6.2


10/22


LEVEL 1 DFD FOR ADMINISTRATOR

Admin Username, password

Admin Data

Admin Data

ADMINSTRATOR DB

Admin Data


Admin

Login

0.1

View User

0.2

Action

0.3


11/22


UserData Action Data

FEEDBACK DB USERACCOUNT DB

Fig: 3.9 LEVEL 1 DFD FOR ADMINISTRATOR

LEVEL 2 DFD FOR ADMINISTRATOR LOGIN

Adminname,password

Invalid Data Authentic Admin

Adminname,password

Admin Data Admin Data

ADMINISTRATOR DB

Fig: 3.10 LEVEL 2 DFD FOR ADMINISTRATOR LOGIN

LEVEL 2 DFD FOR VIEW USERS BY ADMINISTRATOR

FEEDBACK DB ADMINISTRATOR DB


Get Admin

Login Details

0.1.1

0.1.1

Authenticat

e

0.1.2

View Admin

Home

0.1.3


12/22


User Data Admin Date

Display

UserData

USER ACCOUNT DB

Fig: 3.11 LEVEL 2 DFD FOR VIEW USERS BY ADMINISTRATOR

LEVEL 2 DFD FOR ACTION ON USER

ADMINISTRATOR DB

Admin Data

Action Data

USERACCOUNT DB

Fig: 3.12 LEVEL 2 DFD FOR ACTION ON USER


View

User

0.2.1

Block/Unblock

0.3.1

0.2.2


13/22


3.2 Entity Relationship Diagram

The Data Flow Diagram does not reveal the relationships between the various data

elements involved in the system. These relationships are the most important features in

the database system. This relationship is stated using an E-R Diagram.

The most important consideration in designing the database is how the information will

be used. The various applications and procedures that will use the database introduce the

requirements upon the structure of the data.

Databases are used to store structured data. The structure of this data, together with other

constraints, can be designed using a variety of techniques, one of which is called entity-

relationship modeling or ERM. The end-product of the ERM process is an entity-

relationship diagram or ERD. Data modeling requires a graphical notation for

representing such data models. An ERD is a type of conceptual data model or semantic

data model.

The first stage of information system design uses these models to describe information

needs or the type of information that is to be stored in a database during the requirements



14/22


analysis. The data modeling technique can be used to describe any ontology (i.e. an

overview and classifications of used terms and their relationships) for a certain universe

of discourse (i.e. area of interest). In the case of the design of an information system thatis based on a database, the conceptual data model is, at a later stage (usually called

logical design), mapped to a logical data model, such as the relational model; this in turn

is mapped to a physical model during physical design. Note that, sometimes, both of

these phases are referred to as "physical design".

There are a number of conventions for entity-relationship diagrams (ERDs). The classical

notation is described in the remainder of this article, and mainly relates to conceptual

modeling. There are a range of notations more typically employed in logical and physical

database design.



15/22




16/22


Figure: 3.13 ER-Diagram

3.3 TABLES

3.3.1 Useraccount



17/22


Table: 3.1 Table useraccount


Name Constraints Data Type

Emailid PRIMARY KEY Varchar(80)

password NOT NULL Varchar(80)

dob NOT NULL Date

sex NOT NULL Varchar(80)

firstname NOT NULL Varchar(80)

lastname NOT NULL Varchar(80)

secqns NOT NULL Varchar(80)

secans NOT NULL Varchar(80)

address NOT NULL Varchar(80)

Country NOT NULL Varchar(80)

City NOT NULL Varchar(80)

Pin NOT NULL Varchar(80)

Phone1 NOT NULL Varchar(80)

Phone2 NOT NULL Varchar(80)

School NOT NULL Varchar(80)

College NOT NULL Varchar(80)University NOT NULL Varchar(80)

Relationship NOT NULL Varchar(80)

Work_status NOT NULL Varchar(80)

Interest_in NOT NULL Varchar(80)

Wall_post NOT NULL Varchar(80)

About_me NOT NULL Varchar(80)

Language NOT NULL Varchar(80)

Status NOT NULL Varchar(80)


18/22


3.3.2. friendrequest:

Table: 3.2 Table - friendrequest

3.3.3. Scrap



Requestid PRIMARY KEY number

emailidFOREIGN KEY [REFERENCE

BY useraccount]Varchar(80)

fromid NOT NULL Varchar(80)

status NOT NULL Varchar(80)

reqdate NOT NULL date


scrapid PRIMARY KEY number


BY useraccount]

Varchar(80)


message NOT NULL Varchar(80)

date NOT NULL date


19/22


Table: 3.3 Table scrap

3.3.4. Picinfo

Table: 3.4 Table picinfo

3.3.5. Comment



picid PRIMARY KEY number



pictitle NOT NULL Varchar(80)


commentid PRIMARY KEY number

picidFOREIGN KEY [REFERENCE

BY picinfo]number

commentdesc NOT NULL Varchar(80)



commentdate NOT NULL Date


20/22


Table: 3.5 Table comment

3.3.6. Message

Table: 3.6 Tables Message

3.3.8. Feedback

Table: 3.8 Tables Feedback

3.3.9. Administrator



messageid PRIMARY KEY number




message NOT NULL Varchar(80)

dt NOT NULL Date




Feedbackdesc NOT NULL Varchar(80)

Reportedemailid NOT NULL Varchar(80)

feedbackdate NOT NULL Date


21/22


Table: 3.9 Table administrator

3.4 Relational Schema Diagram:

Useraccount

emailid password firstname lastname dob sex secqns secans Address country

City Pin Phone School college univerrelationship Workstatus interest wallpost

aboutm

elanguage status

friendrequestrequestid emailid fromid status reqdate

Scrapscrapid emailid fromid message sdt



username PRIMARY KEY Varchar(80)

password NOT NULL Varchar(80)


22/22


Messagemessageid emailid fromid message mdt

Picinfo

picid emailid pictitle

Commentcommentid emailid picid commentdesc cdt

Feedbackemailid feedbackdesc reportemailid feedbackdate

Administratorusername password

Figure: 3.14 Relational Schema Diagram


chap3 design strategy

Documents