Data Flow, Entity Relationship Diagram and DB Design

Data flow, Entity Relationship Diagram and DB Design
Lecture Notes for Symbiosis Center for Management studies (UG) TY students By Prof. Nitin C amat
@Copyright Prof Nitin C Kamat Fineness Learning Consultants

HOW TO DRAW DATA FLOW DIAGRAMS
What are Data Flow Diagrams? Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.
A data flow diagram
Data Flow Diagram Notations You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane & Sarson.
Process Notations
Yourdon and Coad Process Notations
Gane and Sarson Process Notation Process A process transforms incoming data flow into outgoing data flow. Learn how to edit text on this object.
Datastore Notations
Yourdon and Coad Datastore Notations
Gane and Sarson Datastore Notations DataStore Datastores are repositories of data in the system. They are sometimes also referred to as files. Learn how to edit text on this object.

Data low Notations
Data low Dataflows are pipelines through which packets of information flow. Label the arrows with the name of the data that mo es through it. Learn how to connect objects. !"ternal !ntit# Notations
!"ternal !ntit# !xternal entities are objects outside the system" with which the system communicates. !xternal entities are sources and destinations of the system#s inputs and outputs. Learn how to edit text on this object.

HOW TO DRAW DATA FLOW DIAGRAMS $cont%&'
Data Flow Diagram La#ers Draw data flow diagrams in se eral nested layers. A single process node on a high le el diagram can be expanded to show a more detailed data flow diagram. Draw the context diagram first" followed by arious layers of data flow diagrams.
The nesting of data flow layers
(onte"t Diagrams A context diagram is a top le el $also known as Le el %& data flow diagram. 't only contains one process node $process %& that generali(es the function of the entire system in relationship to external entities.

DFD le)els The first le el D)D shows the main processes within the system. !ach of these processes can be broken into further processes until you reach pseudocode.
An example first le!el data flow diagram
Drawing Neste& DFDs in SmartDraw You can easily nest data flow diagrams in *martDraw. Draw the high+le el diagrams first" then select the process you want to expand" go to the Tools menu" and select Insert H#*erlin+. Link the selected process notation to another *martDraw diagram or a web page.
,nce linked" a small plus sign will appear in the object" and clicking on it opens the linked file.

Clic"ing on the plus sign will open the lin"ed file
-hen you link two *martDraw files" the link created between them is absolute" not relati e. $A link to a file on your hard dri e will look something like this: .://*martDraw )iles/0roject 1/dataflow2.sdr instead of a relati e link: dataflow2.sdr& 'n order to share your files with others" you can either sa e your files to a network dri e or sa e and publish them as web pages. 'f you sa e your diagrams on a network" make sure you go to Networ+ Neigh,orhoo& or M# Networ+ Places to find the appropriate directory instead of using your local mapped dri es.
#rowse on your networ" to find the files you want to lin" to
You can use this hyperlink function to open any kind of file" including text documents" spreadsheets" web pages" or e en to launch a program3

Re-.irements !ngineering 0re /0/ !ntit# Relationshi* Diagram $!RD' .ourse .ontents 4ext
!5D complements D)D. -hile D)D focuses on processes and data flow between them" !5D focuses on data and the relationships between them. 't helps to organi(e data used by a system in a disciplined way. 't helps to ensure completeness" adaptability and stability of data. 't is an effecti e tool to communicate with senior management $what is the data needed to run the business&" data administrators $how to manage and control data&" database designers $how to organi(e data efficiently and remo e redundancies&. 't consists of three components. Entity1 't represents a collection of objects or things in the real world whose indi idual members or instances ha e the following characteristics: !ach can be identified uni6uely in some fashion. !ach plays a necessary role in the system we are building. !ach can be described by one or more data elements $attributes&.
!ntities generally correspond to persons" objects" locations" e ents" etc. !xamples are employee" endor" supplier" materials" warehouse" deli ery" etc. There are fi!e types of entities. F.n&amental entit#1 't does not depend on any other entity for its existence. )or e.g. materials S.,or&inate entit#1 't depends on another entity for its existence. )or example" in an in entory management system" purchase order can be an entity and it will depend on materials being procured. *imilarly in oices will depend on purchase orders. Associati)e entit#1 't depends on two or more entities for its existence. )or example" student grades will depend on the student and the course. Generali2ation entit#1 't encapsulates common characteristics of many subordinate entities. )or example" a four wheeler is a type of ehicle. A truck is a type of four wheeler. Aggregation entit#1 't consists of or an aggregation of other entities. )or example" a car consists of engine" chassis" gear box" etc. A ehicle can also be regarded as an aggregation entity" because a ehicle can be regarded as an aggregation of many parts. Attributes1 They express the properties of the entities. ! ery entity will ha e many attributes" but only a subset" which are rele ant for the system under study" will be chosen. )or example" an employee entity will ha e professional attributes like name" designation" salary" etc. and also physical attributes like height" weight" etc. 7ut only one set will be chosen depending on the context. Attributes are classified as entity "eys and entity descriptors. !ntity keys are used to uni6uely identify instances of entities. Attributes ha ing uni6ue alues are called candidate keys and one of them is designated as primary key. The domains of the attributes should be pre+defined. 'f

#name# is an attribute of an entity" then its domain is the set of strings of alphabets of predefined length.
Relationships1 They describe the association between entities. They are characteri(ed by optionality and cardinality. Optionality is of two types" namely" mandatory and optional. 1. Mandatory relationship means associated with e ery instance of the first entity there will be atleast one instance of the second entity. 2. Optional relationship means that there may be instances of the first entity" which are not associated with any instance of the second entity. )or example" employee+spouse relationship has to be optional because there could be unmarried employees. 't is not correct to make the relationship mandatory. Cardinality is of three types: one+to+one" one+to+many" many+to+many. 1. One-to-one relationship means an instance of the first entity is associated with only one instance of the second entity. *imilarly" each instance of the second entity is related to one instance of the first entity. 2. One-to-many relationship means that one instance of the first entity is related to many instances of the second entity" while an instance of the second entity is associated with only one instance of the first entity. 3. 'n many-to-many relationship an instance of the first entity is related to many instances of the second entity and the same is true in the re erse direction also. ,ther types of relationships are multiple relationships between entities" relationships leading to associati e entities" relationship of entity with itself" !1.L8*'9!+,5 and A4D relationships ERD notation1 There are two type of notation used: :. 0eter Chen notation 2. #achman notation. 4ot surprisingly" 0eter .hen and 7achman are the name in entors of the notation. The following table gi es the notation. (OMPON!NT !4T'TY ,5 ,7;!.T TY0! R!PR!S!NTATION <<<
5!LAT',4*='0
.A5D'4AL'TY

,0T',4AL'TY
0!T!5 .=!4 !xample for 7achman notation
7A.=>A4
!xample for 0eter .hen notation
?i en below are a few examples of !5 diagrams using 7achman notation. )irst the textual statement is gi en followed by the diagram :. 'n a company" each di ision is managed by only one manager and each manager manages only one di ision
2. Among the automobile manufacturing companies" a company manufactures many cars" but a gi en car is manufactured in only one company
<. 'n a college" e ery student takes many courses and e ery course is taken by many students
@. 'n a library" a member may borrow many books and there may be books which are not borrowed by any member
A. A teacher teaches many students and a student is taught by many teachers. A teacher conducts examination for many students and a student is examined by many teachers.
B. An extension of example+< abo e is that student+grades depend upon both student and the course. =ence it is an associati e entity
C. An employee can play the role of a manager. 'n that sense" an employee reports to another employee.
D. A tender is floated either for materials or ser ices but not both.
E. A car consists of an engine and a chassis
0re
8p .ourse .ontents
4ext

Re-.irements !ngineering 0re /03 Data Dictionar# 't contains an organi(ed list of data elements" data structures" data flows" and data stores mini specifications of the primiti e processes in the system any other details which will pro ide useful information on the system .ourse .ontents 4ext
Data element is piece of data" which can not be decomposed further in the current context of the system. !xamples are purchaseForderFno." employeeFname" interestFrate" etc. !ach data element is a member of a domain. The dictionary entry of a data element should also specify the domain. Data structure is composed of data elements or other data structures. !xamples are .ustomerFdetails" which may be composed of .ustomerFname and .ustomerFaddress. .utomerFaddress in turn is a structure. Another example is 'n oice" which may be composed of 'n oiceFidentification" .ustomerFdetails" Deli eryFaddress" 'n oiceFdetails. Data flow is composed of data structures and/or data elements. Definitions of dependent data structures/data elements precede the definition of data flow. -hile defining the data flow the connecting points should be mentioned.
Also useful to include the flow olume/fre6uency and growth rates. Data store" like data flow is made up of a combination of data structures and/or data elements. The description is similar to data flows. The notation elements used in the data dictionary are the following: GspouseFnameH This indicates that spouseFname is optional IdependentFname" relationshipJ K $% to :A& This indicates that the data strucure can be repeated % to :A times IexpenseFdescription" companyFname" chargeJ K $: to 4& This indicates that the data structure may be repeated : to 4 where 4 is not fixed

oterFidentityFnumber/customerFaccountFnumber This indicates that either of the elements will be present.
Data dictionary also contains mini specifications. They state the ways in which data flows that enter the primiti e process are transformed in to data flows that lea e the process. ,nly the broad outline is gi en" not the detailed steps. They must exist for e ery primiti e process. *tructured english is used for stating minispecifications. ,nce the D)D" !5D" and the Data dictionary are created" the three of them must be matched against each other. D)D and !5D can be created independently and parallely. ! ery data store in the D)D must correspond to atleast one entity in the !5D. There should be processes in D)D which create modify and delete instances of the entities in !5D. )or e ery relationship in !5D there should be a process in D)D which uses it. )or e ery description in the data dictionary" there should be corresponding elements in D)D and !5D. 0re 8p .ourse .ontents 4ext

Re-.irements !ngineering 0re /04 Decision Tree an& Decision Ta,les .ourse .ontents 4ext
A decision tree represents complex decisions in the form of a tree. Though isually it is appealing" it can soon get out of hand when the number and complexity of decisions increase. An example is gi en below. )irst the textual statment is gi en and then the corresponding decision tree is gi en: Rules for electricity billing are as below: If the meter reading is "OK", calculate on consumption basis(i.e. meter reading) If the meter reading appears " O!", then chec" if the house is occupied If the house is occupied, calculate on seasonal consumption basis otherwise calculate on consumption basis If the meter is damaged, calculate based on ma#imum possible electricity usage
There are two types of decision tables" binary+ alued$yes or no& and multi+ alued. An example follows:

!L!(TRI(IT5 6ILL (AL(7LATION 6AS!D ON (7STOM!R (LASS If a customer uses electricity for domestic purposes and if the consumption is less than $%% units per month then bill with minimum monthly charges. &omestic customers with a consumption of $%% units or more per month are billed at special rate. 'on(domestic users are charged double that of domestic users (minimum and special rates are double). 6INAR589AL7!D D!(ISION TA6L! Domestic (.stomer (ons.m*tion : /;; .nits *er month Minim.m rate S*ecial rate Do.,le minim.m rate Do.,le s*ecial rate Y Y Y 4 4 4 Y 4 4 Y 4 4 4 Y 4 4 Y 4 4 4 4 4 4 Y
M7LTI89AL7!D D!(ISION TA6L! (.stomer (ons.m*tion Rate D <%% * D L<%% > 4 <%% 2* 4 L<%% 2>
Like decision trees" binary+ alue decision tables can grow large if the number of rules increase. >ulti+ alued decision tables ha e an edge. 'n the abo e example" if we add a new class of customers" called Aca&emic" with the rules: If the consumption is less than $%% units per month then bill with concessional rates. Otherwise bill with twice the concessional rates. then new tables will look like the following: 6INAR589AL7!D D!(ISION TA6L! $three rows and two columns are added to deal with the extra class of customers& Aca&emic Domestic c.stomer (ons.m*tion : /;; .nits<month 4 Y Y 4 Y 4 4 4 Y 4 4 4 Y 4 Y Y 4 4

Minim.m rate S*ecial rate Twice minim.m rate Twice s*ecial rate (oncessional rate Twice concessional rate Y 4 4 4 4 4 4 Y 4 4 4 4 4 4 Y 4 4 4 4 4 4 Y 4 4 4 4 4 4 Y 4 4 4 4 4 4 Y
M7LTI89AL7!D D!(ISION TA6L! $only two columns are added to deal with the extra class of customers& (.stomer (ons.m*tion Rate Domestic <%% *pecial Domestic L<%% >inimum 4on+domestic <%% Twice special 4on+domestic L<%% Twice minimum Academic <%% Twice concessional Academic L<%% .oncessional
0re
8p .ourse .ontents
4ext

Normalization of Database Tables There is a concept of Normal Forms! that is often use" to "esign an" #u"ge the $uality of "esign of "ata%ases. There are fi&e normal forms. They!re num%ere"'con&eniently enough'one thorough fi&e. There are also a %unch of other interme"iate forms name" after something or other (usually )hoe&er came up )ith it*. +igher num%ere" normal forms ha&e all the goo"ness $ualities of the lo)er forms. For e,ample- thir".normal form "ata%ase is also in secon".normal form an" first normal form. /ithout putting too fine a point on it- )e )ant our "ata%ases to %e in as higher normal form as possi%le. +igher is %etter. 0enerally- you!re only concerne" a%out the first three normal forms Functional Dependency 1 Functional 2epen"ency is a relationship %et)een or among tri%utes such that the &alues of one 1ttri%ute "epen" on- or are "etermine" %y- The &alues of the other 1ttri%ute(s*. Partial "epen"ency3 is a relationship %et)een attri%utes such that the &alues of one 1ttri%ute is "epen"ent on- or "etermine" %y- the &alues of another attri%ute )hich is part of the composite 4ey. Partial 2epen"encies 1re Not 0oo" 2ue To "uplication of "ata an" up"ate 1nomalies5 Examples of Functional Dependencies 6f )e 4no) an 678N- then )e 4no) the 8oo4 Title an" the author(s* 678N 9 8oo4 Title 678N 9 1uthor(s*
6f )e 4no) the :6N- then )e 4no) )ho the 1uto o)ner is :6N 9 1uto;<)ner

6f )e 4no) 7tu"ent.62 (762*- then )e can uni$uely "etermine his=her Name 762 9 7;Name
Transiti e Dependencies 6s a relationship %et)een attri%utes such that the &alues of one attri%ute is "epen"ent onor "etermine" %y- the &alues of another attri%ute )hich is not a part of the Key. >,ist )hen a non 4ey attri%ute &alue is functionally "epen"ent upon another non 4ey &alue in the recor". For e,ample3 >?PL<@>>;62 ..A B<8;C1T>0<C@ B<8;C1T>0<C@ ..A +<DCL@;C1T>
1n employee "ata ta%le that inclu"es the Ehourly pay rateF )oul" re$uire searching e&ery employee recor" to properly up"ate an hourly rate for a particular #o% category. !hat is Normalization" 0ol"en Cule of NormaliGation3 >nter the minimum "ata necessary- a&oi"ing 2uplicate >ntry of 6nformation- )ith minimum ris4s to "ata 6ntegrity. 0oals <f NormaliGation3 >liminate Ce"un"ancies Cause" 8y3 Fiel"s Cepeate" /ithin 1 File Fiel"s Not 2irectly 2escri%ing The Key >ntity Fiel"s 2eri&e" From <ther Fiel"s

1&oi" 1nomalies 6n Dp"ating (1""ing- >"iting- 2eleting* Cepresent accurately the items %eing mo"ele" simplify maintenance an" retrie&al of info
Database Tables and Normalization NormaliGation is a process for assigning attri%utes to entities. 6t re"uces "ata re"un"ancies an" helps eliminate the "ata anomalies. NormaliGation )or4s through a series of stages calle" normal forms3 First normal form (1NF* This is the most %asic normal form- an" the only re$uirement is that "ata is store" in ta%les. 6f your "ata is store" in ta%les- then you!&e achie&e" first.normal form. 7econ" normal form (2NF* 1 "ata%ase is in secon".normal form if it is in first.normal form an" e&ery attri%ute is fully functionally "epen"ent on the primary 4ey. Thir" normal form (3NF* 1 "ata%ase is in thir".normal form if it is in secon".normal form an" contains no transiti&e attri%ute "epen"encies. The highest le&el of normaliGation is not al)ays "esira%le. Basic Rule for Normalization The attri%ute &alues in a relational ta%le shoul" %e functionally "epen"ent (F2* on the primary 4ey &alue.

1 relationship is functionally "epen"ent )hen one attri%ute &alue implies or "etermines the attri%ute &alue for the other attri%ute. >?;77;ND? ..A >?;N1?>
#orollaries Corollary 13 No repeating groups allo)e" in relational ta%les. Corollary 23 1 relational ta%le shoul" not ha&e attri%utes in&ol&e" in a transiti&e "epen"ency relationship )ith the primary 4ey.
Database Tables and Normalization The Nee" for NormaliGation Case of a Construction Company 8uil"ing pro#ect .. Pro#ect num%er- Name- >mployees assigne" to the pro#ect. >mployee .. >mployee num%er- Name- Bo% classification The company charges its clients %y %illing the hours spent on each pro#ect. The hourly %illing rate is "epen"ent on the employee!s position. Pro%lems )ith the Ta%le H.1 The pro#ect num%er is inten"e" to %e a primary 4ey- %ut it contains nulls. The ta%le "isplays "ata re"un"ancies. The ta%le entries in&ite "ata inconsistencies.

The "ata re"un"ancies yiel" the follo)ing anomalies3 2eletion anomalies. Dp"ate anomalies. 1""ition anomalies.
Deletion $nomaly <ccurs )hen the remo&al of a recor" results in a loss of important information a%out an entity. >,ample3 1ll the information a%out a customer is containe" in an or"er file- if the or"er is cancele"all the customer information coul" %e lost )hen the or"er recor" is "elete" 7olution3 Create t)o ta%les..one ta%le contains or"er information an" the other ta%le contains customer information. %pdate $nomaly <ccurs )hen a change of a single attri%ute in one recor" re$uires changes in multiple recor"s >,ample3 1 staff person changes their telephone num%er an" e&ery potential customer that person e&er )or4e" )ith has to ha&e the correcte" num%er inserte". 7olution3

Put the employee!s telephone num%er in one location..as an attri%ute in the employee ta%le. &nsertion $nomaly <ccurs )hen there "oes not appear to %e any reasona%le place to assign attri%ute &alues to recor"s in the "ata%ase. Pro%a%ly ha&e o&erloo4e" a critical entity. >,ample3 1""ing ne) attri%utes or entire recor"s )hen they are not nee"e". /here "o you place information on ne) >&aluator!sI 2o you create a "ummy Lea". 7olution3 Create a ne) ta%le )ith a primary 4ey that contains the rele&ant or functional "epen"ent attri%utes. Database Tables and Normalization Con&ersion to First Normal Form 1 relational ta%le must not contain repeating groups. Cepeating groups can %e eliminate" %y a""ing the appropriate entry in at least the primary 4ey column(s*. (7ee 2ata%ase Ta%le H.3*
Database Table '() The E ergreen Data

Dependency Diagram The arro)s a%o&e the entity in"icate that the entity!s attri%utes are "epen"ent on the com%ination of PC<B;ND? an" >?P;ND?. The arro)s %elo) the "epen"ency "iagram in"icate less "esira%le "epen"encies %ase" on only a part of the primary 4ey .. partial "epen"encies.
Figure '(* $ Dependency Diagram+ First Normal Form )NF Definition The term first normal form (1NF* "escri%es the ta%ular format in )hich3 1ll the 4ey attri%utes are "efine". There are no repeating groups in the ta%le. 1ll attri%utes are "epen"ent on the primary 4ey. #on ersion to ,econd Normal Form 7tarting )ith the 1NF format- the "ata%ase can %e con&erte" into the 2NF format %y /riting each 4ey component on a separate line- an" then )riting the original 4ey on the last line an" l /riting the "epen"ent attri%utes after each ne) 4ey. PCCT (PC<B;ND?- PC<B;N1?>* >?PL<@>> (>?P;ND?- >?P;N1?>- B<8;CL177-C+0;+<DC* 17760N (PC<B;ND?- >?P;ND?- +<DC7*
Figure '(*NF Definition 1 ta%le is in 2NF if3 6t is in 1NF an" 6t inclu"es no partial "epen"encies5 that is- no attri%ute is "epen"ent on only a portion of the primary 4ey. Note3 6t is still possi%le for a ta%le in 2NF to e,hi%it transiti&e "epen"ency5 that is- one or more attri%utes may %e functionally "epen"ent on non 4ey attri%utes. 7ee figure H.2 #on ersion to Third Normal Form Create a separate ta%le )ith attri%utes in a transiti&e functional "epen"ence relationship. PCCT (PC<B;ND?- PC<B;N1?>* 17760N (PC<B;ND?- >?P;ND?- +<DC7* >?PL<@>> (>?P;ND?- >?P;N1?>- B<8;CL177* B<8 (B<8;CL177- C+0;+<DC* -NF Definition 1 ta%le is in 3NF if3 6t is in 2NF an" 6t contains no transiti&e "epen"encies. Database Design and Normalization Example+ .#onstruction #ompany/ ,ummary of 0perations+ The company manages many pro#ects. >ach pro#ect re$uires the ser&ices of many employees. 1n employee may %e assigne" to se&eral "ifferent pro#ects. 7ome employees are not assigne" to a pro#ect an" perform "uties not specifically relate" to a pro#ect. 7ome employees are part of a la%or pool- to %e share" %y all pro#ect teams. >ach employee has a (single* primary #o% classification. This #o% classification "etermines the hourly %illing rate. ?any employees can ha&e the same #o% classification. T)o 6nitial >ntities3 PCCT (PC<B;ND?- PC<B;N1?>* >?PL<@>> (>?P;ND?- >?P;LN1?>- >?P;FN1?>>?P;6N6T61L- B<8;2>7CC6PT6<NB<8;C+0;+<DC*
Figure '(' The &nitial E1R Diagram for a #ontracting #ompany Three >ntities 1fter Transiti&e 2epen"ency Cemo&e" PCCT (PC<B;ND?- PC<B;N1?>* >?PL<@>> (>?P;ND?- >?P;LN1?>- >?P;FN1?>>?P;6N6T61L- B<8;C<2>* B<8 (B<8;C<2>- B<8;2>7CC6PT6<NB<8;C+0;+<DC*
Figure '(2 The 3odified E1R Diagram for a #ontacting #ompany

Creation of the Composite >ntity 17760N
Figure '(4 The Final .&mplementable/ E1R Diagram for the #ontracting #ompany 1ttri%ute 17760N;+<DC is assigne" to the composite entity 17760N. E?anagesF relationship is create" %et)een >?PL<@>> an" PCCT. PCCT (PC<B;ND?- PC<B;N1?>- >?P;ND?* >?PL<@>> (>?P;ND?- >?P;LN1?>- >?P;FN1?>>?P;6N6T61L- >?P;+6C>21T>- B<8;C<2>* B<8 (B<8;C<2>- B<8;2>7CC6PT6<NB<8;C+0;+<DC* 17760N (17760N;ND?- 17760N;21T>- PC<B;ND?>?P;ND?- 17760N;+<DC7*
Figure '(5 The Relational ,chema for the #ontracting #ompany First Normal Form.)NF/+ No Cepeating >lements or 0roups of >lements ,econd Normal Form.*NF/+ No Partial 2epen"encies on a Concatenate" Key Third Normal Form.-NF/+ No 2epen"encies on Non.Key 1ttri%utes 6igher order Normal Forms

Data Flow, Entity Relationship Diagram and DB Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Flow, Entity Relationship Diagram and DB Design

Uploaded by

Copyright:

Available Formats

Data flow, Entity Relationship Diagram and DB Design

@Copyright Prof Nitin C Kamat Fineness Learning Consultants