Anu Table Design

8/9/2019 Anu Table Design

1/15

Customer Table

Primary Key : Cus_id

8/9/2019 Anu Table Design

2/15

Product Master

Primary Key : Product ID

8/9/2019 Anu Table Design

3/15

Delivery Challan Table main Table

Primary Key : Del_no

Delivery Challan Table sub

Foreign Key : Del_no

8/9/2019 Anu Table Design

4/15

Invoice Main Table

Primary Key : Inv_No

Foreign Key : Del_no

8/9/2019 Anu Table Design

5/15

8/9/2019 Anu Table Design

6/15

Invoice ub Table

Foreign Key : inv_No

8/9/2019 Anu Table Design

7/15

Database Normali!ation

Database normalizationis the process of organizing the fieldsand tablesof a relational

databaseto minimize redundancy. Normalization usually involves dividing large tables into smaller

(and less redundant) tables and defining relationships between them. The objective is to isolate data

so that additions, deletions, and modifications of a field can be made in just one table and then

propagated through the rest of the database using the defined relationships.

Normal forms[edit

The normal forms(abbrev. NF) of relational database theory provide criteria for determining a

table!s degree of immunity against logical inconsistencies and anomalies. The higher the normal

form applicable to a table, the less vulnerable it is. "ach table has a #highest normal form# (HNF)$

by definition, a table always meets the re%uirements of its &N' and of all normal forms lower than its

&N' also by definition, a table fails to meet the re%uirements of any normal form higher than its

&N'.

The normal forms are applicable to individual tables to say that an entire database is in normal

form nis to say that all of its tables are in normal form n.

Newcomers to database design sometimes suppose that normalization proceeds in an iterative

fashion, i.e. a N' design is first normalized to *N', then to +N', and so on. This is not an accuratedescription of how normalization typically wors. - sensibly designed table is liely to be in +N' on

the first attempt furthermore, if it is +N', it is overwhelmingly liely to have an &N' of N'. -chieving

the #higher# normal forms (above +N') does not usually re%uire an e/tra e/penditure of effort on the

part of the designer, because +N' tables usually need no modification to meet the re%uirements of

these higher normal forms.

The main normal forms are summarized below.

Normal form Defined by In Brief definition

N''irst normal

form

Two versions$ ".'.

0odd(123),0.4.

5ate(*33+)

123[and

*33+[3

Thedomainof each attributecontains

only atomicvalues, and the value of each

attribute contains only a single value from

that domain.[

8/9/2019 Anu Table Design

8/15

*N'6econd

normal form".'. 0odd 12[*

No non7prime attribute in the table

is functionally dependenton aproper

subsetof any candidate ey

+N'Third normal

form

Two versions$ ".'.

0odd(12), 0.

8aniolo (19*)

12[*and

19*[*

"very non7prime attribute is non7transitively

dependent on every candidate ey in the

table. The attributes that do not contribute to

the description of the primary ey are

removed from the table. :n other words, no

transitive dependency is allowed.

";N'

"lementary

;ey Normal

'orm

0. 8aniolo 19*[*

"very non7trivial functional dependency in

the table is either the dependency of an

elementary ey attribute or a dependency

on a superey

onald 'agin 122[?

"very non7trivial multivalued dependencyin

the table is a dependency on a superey

N''ifth normal

form>onald 'agin 121[

"very non7trivialjoin dependencyin the

table is implied by the supereys of the

table

5;N

'

5omain@ey

normal form>onald 'agin 19[A

"very constraint on the table is a logical

conse%uenceof the table!s domain

constraints and ey constraints

AN' 6i/th normal 0.4. 5ate, &ugh *33*[2 Table features no non7trivial join

8/9/2019 Anu Table Design

9/15

form5arwen,andNios

Borentzos

dependencies at all (with reference to

generalized join operator)

Data Flow Diagram (DFD)

Introduction

The data flow diagram (DFD) is an OMT diagram that is added to the UML suite

when you activate the OMT module.

WARNING: Information secified in the DFD will !e lost during future ugrades.

Purpose

In OMT" you use DFDs to model what haens with data. #ou model the system as a

networ$ of rocesses that transform and e%change data.

The DFDs show the flow of data values from their sources in o!&ects through the

rocesses that transform them to their destination in other o!&ects. 'alues can include

inut values" outut values" and internal data stores. ontrol information is shown

only in the form of control flows.

The following ta!le lists the imortant elements of DFDs.

Symbol Stands For

Data "rocess Data "rocessing

Data #o$ Data #o$ or the e%change o& data bet$een "rocesses

Data store Data storage

'ctor (b)ect "roducing and consuming data

8/9/2019 Anu Table Design

10/15

Guidelines

#ou can follow certain guidelines to draw meaningful DFDs.

("tional in"ut #o$s do not e%ist* ' "rocess can "er&orm its&unction only i& all its in"ut #o$s are al$ays available*

+ou cannot assign the same data to t$o out"ut #o$s &rom thesame "rocess* I& a "rocess "roduces more than one data #o$,these #o$s are mutually e%clusive*

+ou can s"lit a #o$, and you can merge t$o #o$s into one*

DecompositionTo secify what a highlevel rocess does" !rea$ it down into smaller units in more

DFDs. * highlevel rocess is an entire DFD. +ach highlevel rocess is decomosed

into other rocesses with data flows and data stores. +ach decomosition is a DFD in

itself. #ou can continue to !rea$ down rocesses until you reach a level on which

further decomosition seems imossi!le or meaningless.

The data flows of the oened rocess are connected in the new diagram to the rocess

related to the oened rocess. 'ertices" and the flows and o!&ects connected to them"

are transferred with the flows that are connected to the decomosed rocess.

Example DFD

The following illustration shows a samle DFD.

8/9/2019 Anu Table Design

11/15

ymbols

Introduction

This section descri!es the sym!ols used in the DFD. The following illustration shows

the sym!ols as they aear in the diagram control anel.

Note: The 'erte%" ,elect" -ote and" -ote connector sym!ols are common to all

diagrams. They are descri!ed in hater " /or$ing /ith Diagrams.

Data process

* data rocess transforms data values.

#ou can ma$e a distinction !etween the following tyes of rocesses0

Process Type Indicates

-igh.levelProcess containing non&unctional com"onents such as data stores

or e%ternal ob)ects that cause side e/ects

0o$.levelPure &unction $ithout side e/ects, such as the sum o& t$o

numbers

8/9/2019 Anu Table Design

12/15

0ea& or atomic

"rocessesProcess that is not &urther decom"osed

The name of a rocess is usually a descrition of the transformation it erforms.

There are three sorts of transformation0

Trans&ormation o& the structure, &or e%am"le, re&ormatting

Trans&ormation o& in&ormation contained in data

1eneration o& ne$ in&ormation

If you oen a rocess" you can either create a new DFD or oen an e%isting DFD in

which the rocess is secified.

The data flows of the oened rocess are connected in the new diagram to the rocess

with the name of the oened rocess. 'ertices" and the flows and o!&ects connected to

them" are transferred with the flows that are connected to the decomosed rocess.

If a data rocess has a decomosition at a lower level" an asteris$ is laced inside the

ellise. The data rocess can !e oened only if it has a name.

Data store

* data store stores data assively for later access. * data store resonds to re1uests to

store and access data. It does not generate any oerations. * data store allows values

to !e accessed in an order different from the order in which they were generated.

Inut flows indicate information or oerations that modify the stored data such as

adding or deleting elements or changing values. Outut flows indicate information

retrieved from the store2 this information can !e an entire value or a comonent of a

value.

Actor

*n actor roduces and consumes data" driving the DFD. *ctors lie on the !oundary of

the diagram2 they terminate the flow of data as sources and sin$s of data. They are

8/9/2019 Anu Table Design

13/15

also $nown as terminators. Data flows !etween an actor and a diagram are inuts to

and oututs of the diagram. The system interacts with eole through the actor.

Ancor

* DFD anchor rovides a start or end oint. In decomosition diagrams" anchors

reresent the nodes connected to the decomosed rocess in the higher level diagram.

Data !ow

* data flow moves data !etween rocesses or !etween rocesses and data stores. *s

such" it reresents a data value at some oint within a comutation and an

intermediate value within a comutation if the flow is internal to the diagram. This

value is not changed.

The names of inut and outut flows can indicate their roles in the comutation or the

tye of the value they move. Data names are refera!ly nouns. The name of a tyical

iece of data" the data asect" is written alongside the arrow.

,ee also Flow names and inheritance!elow.

"esult !ow

* result flow is a data flow that generates an o!&ect used as the target of another

oeration. The value of the flow is su!se1uently treated as an o!&ect" usually a data

store.

,ee also Flow names and inheritance!elow.

#ontrol !ow

* control flow is a signal that carries out a command or indicates that something has

occurred. * control flow occurs at a discrete oint in time. The arrow indicates the

direction of the control flow. The name of the event is written !eside the arrow.

8/9/2019 Anu Table Design

14/15

ontrol flows can corresond to messages in Ds or events in ,TDs2 however"

!ecause they dulicate information in the DFD" use them saringly.

,ee also Flow names and inheritance!elow.

$pdate !ow

Udate (or !idirectional) flows are used to indicate an udate of a data store" that is" a

read" change" and store oeration on a data flow.

,ee also Flow names and inheritance!elow.

Flow names and ineritance

Flows in DFDs must !e named. 3owever" flows can inherit the names of the o!&ects

they are connected to. The ta!le !elow shows the rules for inheritance of names.

These rules are alied in the order shown" until nothing more can !e inherited. In

some situations" the flow4s inherited name causes an error when a hec$ command is

carried out. The result of the inheritance is confusing in the diagram.

%riginal

Situation

Situation

A&ter

Ineritance

Explanation

Diverging #o$s $ithout names inherit the name o& an

incoming #o$ $ith a name* I& the incoming #o$ has

several names, each diverging #o$ inherits all o& them*

Converging #o$s $ithout names inherit the name o& an

outgoing #o$ $ith a name* I& the outgoing #o$ has

several names, each converging #o$ inherits all o&

them*

Flo$s connected to a data store, control store,

message 2ueue, message bo%, event 2ueue, or event

#ag inherit the name o& that node*

8/9/2019 Anu Table Design

15/15

* for$ed (converging or diverging) data flow is either a slit or merging data flow" or

a comosite data flow. * comosite data flow has one name for each !ranch. *

comosite flow can slit into the original flows again. * slit or a merging data flow

has only one name.

The name of the flow is ta$en as tye name if no data tye is secified.