Normalization with Entity Relationship Diagramming

Normalizing with Entity Relationship Diagramming

ABSTRACT

Entity relationship diagram (ERD) is one of the most widely used technique for data modeling. An ERD developed during the conceptual data modeling phase of the database development process is generally transformed and enhanced through normalization principles during the logical database design phase. This paper suggests inclusion of normalization during ERD development. Application of normalization during ERD development allows for more robust requirement analysis. The paper concludes with a set of guidelines to refine an ERD to include normalization principles.

1.0 Introduction

Entity relationship diagram (ERD) is one of the most widely used technique for data modeling. Data modeling is an essential component of database design and development. It provides a means to analyze business requirements so as to standardize organizational vocabulary, enforce business rules, and ensure adequate data quality. Since data has become a vital corporate resource (Adelman et al., 2005; Dyche, 2000; Liataud & Hammond, 2001), good data models can make a significant contribution to an organization's future success.

Data modeling is performed during the initial phases of the database development process (also referred as database life cycle) as shown in Figure 1(Mannino, 2006; Rob & Coronel, 2006). During this process, the top two phases are concerned with the information content of the database, while the last two phases are concerned with the implementation of the database on some commercial DBMS.

Figure 1

During the conceptual data modeling phase, data requirements are expressed through an ERD. The conceptual data modeling phase in general is independent of a DBMS. The logical design phase transforms the conceptual data model into a format understandable to DBMS. This phase may also enhance or refine the data model (ERD) of the previous phase to ensure efficient utilization of the database. Since most of the commercial DBMS are based on the relational model, the end product of this phase is relational model design.

One of the ways an ERD is enhanced during the logical design phase is through the process of normalization. Normalization is one of the key tenets in relational model design. It is the process of removing redundancy in a table so that the table is easier to modify (Bala & Martin, 1997; Codd, 1970; Date, 2003; Mannino, 2006; Rob & Coronel, 2006). It usually involves dividing an entity table into two or more tables and defining relationships between the tables. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made in just one table and then propagated through the rest of the database via the defined relationships.

Normalization utilizes association among attributes within an entity table to accomplish its objective. Since an ERD also utilizes association among attributes as a basis to identify entity type structure, it is possible to apply normalization principles during the conceptual data modeling phase. Performing normalization during ERD development can improve the conceptual model, and speed its implementation. This paper outlines the application of normalization principles to ERD development during the conceptual modeling phase. There are various standards for ERD. In this paper, the Crow's Foot notation is utilized.

The ERD has received many extensions and variations, which are generally termed as Enhanced Entity Relationship (EER) model (Lenzerini & Santucci, 1983; Lenzerini & Nobili, 1990; Thalheim, 1998; Balaban & Shoval, 1999; Balaban & Shoval, 2002). In the last few years, the Unified Modeling Language (UML) emerged and became the defacto industry standard for many aspects of object modeling (Bock & Ryan, 1993; Booch, 1994; Fowler, 1997; Booch, Rumbaugh & Jacobson, 1999). The EER model is an integral part of UML as all constructs of EER schemas are included, except for weak entity types, to represent the static part of object modeling. However, ERD continues to be popular for conceptual data modeling.

2.0 Application of Normalization to ERD

Data modeling is an iterative process. Generally a preliminary data model is constructed which is then refined many times. There are many guidelines (rules) for refining an ERD. Some of these rules are as follows (Mannino, 2006):

1. Transform attributes into entity types. This transformation involves the addition of an entity type and a 1-M (one-to-many) relationship.
2. Split compound attributes into smaller attributes. A compound attribute contains multiple kinds of data.
3. Expand entity types into two entity types and a relationship. This transformation can be useful to record a finer level of detail about an entity.
4. Transform a weak entity type into a strong entity type. This transformation is most useful for associative entity types.
5. Add historical details to a data model. Historical details may be necessary for legal as well as strategic reporting requirements. This transformation can be applied to attributes and relationships.
6. Add generalization hierarchies by transforming entity types into generalization hierarchy.

Application of normalization principles toward ERD development enhances these guidelines. To understand this application (i) representation of dependency concepts in an ERD is outlined, followed by (ii) representation of normal forms toward the development of entity type structure. Guidelines for identification of various dependencies is avoided in the paper so as to focus more on their application. Only the first four normal forms and the Boyce-Codd normal forms are considered.

2.1 Representation of Dependencies

Functional dependency in an entity type occurs if one observes the association among the entity identifier and other attributes as reflected in an entity instance. Each entity instance represents a set of values taken by the non entity identifier attributes for each primary key (entity identifier) value. So, in a way an entity instance structure also reflects an application of the functional dependency concept. For example, the Student entity type of Figure 2 can represent the functional dependency SID ?Name, Street, City, Zip.

Figure 2

Each entity instance will now represent the functional dependency among the entity attributes as shown in Figure 3.

Figure 3

During requirement analysis, some entity types may be identified through functional dependencies, while others may be determined through database relationships. For example, the statement, "A faculty teaches many offerings but an offering is taught by one faculty" defines entity type Faculty and Offerings. Another important consideration is to distinguish when one attribute alone is the entity identifier versus a composite entity identifier. A composite entity identifier is an entity identifier with more than one attribute. A functional dependency in which the determinant contains more than one attribute usually represents a many-to-many relationship, which is more addressed through higher normal forms. The notion of having a composite entity identifier is not very common, and often times is a matter of expediency, rather than good entity structure or design.

Transitive dependency in an entity type occurs if non entity identifier attributes have dependency among themselves. For example, consider the modified Student entity type as shown in Figure 4.

Figure 4

In this entity type, suppose there is a functional dependency BuildingName ? Fee. Existence of BuildingName ? Fee dependency implies that the value assigned to the Fee attribute is fixed for distinct BuildingName attribute values. In other words, the Fee attribute values are not specific to the SID value of a student, but rather the BuildingName value. The entity instance of transitive dependency is shown in Figure 5.

Figure 5

Multi-valued dependency equivalency in ERD occurs when attributes within an entity instance have more than one value. This is a situation when some attributes within an entity instance have maximum cardinality of N (more than 1). When an attribute has multiple values in an entity instance, it can be setup either as a composite key identifier of the entity type, or split into a weak entity type. For example, consider the following entity type Student Details as shown in Figure 6.

Figure 6

The Student Details entity type has a composite entity identifier consisting of three attributes - SID, MajorMinor, and Activity. The composition of entity identifier is due to the fact that a student has multiple MajorMinor values along with being involved in multiple activities. However, a student has only one value for Name, Street, City, Zip attributes based on the functional dependency SID, MajorMinor, Activity ? Name, Street, City, Zip. The multi-valued dependency affects the key structure. So, in the Student Details entity type, there can be an MVD SID ?? MajorMinor, Activity. This means that a SID value is associated with multiple values of MajorMinor and Activity attributes, and together they determine other attributes. The entity instance of Student Details entity type is shown Figure 7.

Figure 7

2.2 Normalized ERD

Now we utilize the representation of dependency concepts in ERD toward their use in the application of normal forms. Each normal form rule and its application is outlined.

First Normal Form (1NF)
The first normal form rule is that there should be no nesting or repeating groups in a table. Now an entity type that contains only one value for an attribute in an entity instance ensures the application of first normal form for the entity type. So in a way any entity type with an entity identifier is by default in first normal form. For example, the entity type Student in Figure 2 is in first normal form.

Second Normal Form (2NF)
The second normal form rule is that the key attributes determine all non-key attributes. A violation of second normal form occurs when there is a composite key, and part of the key determines some non-key attributes. The second normal form deals with the situation when the entity identifier contains two or more attributes, and the non-key attribute depends on part of the entity identifier. For example, consider the modified entity type Student as shown in Figure 8. The entity type has a composite entity identifier of SID and City attributes.

Figure 8

An entity instance of this entity type is shown in Figure 9. Now, if there is a functional dependency City ? Status, then the entity type structure will violate the second normal form.

Figure 9

To resolve the violation of the second normal form a separate entity type City with one-to-many relationship is created as shown in Figure 10. The relationship cardinalities can be further modified to reflect organizational working. In general, the second normal form violation can be avoided by ensuring that there is only one attribute as an entity identifier.

Figure 10

Third Normal Form (3NF)
The third normal form rule is that the non-key attributes should be independent. This normal form is violated when there exists a dependency among non-key attributes in the form of a transitive dependency. For example consider the entity type Student as shown in Figure 4. In this entity type, there is a functional dependency BuildingName ? Fee that violates the third normal form.

Transitive dependency is resolved by moving the dependency attributes to a new entity type with one-to-many relationship. In the new entity type the determinant of the dependency becomes the entity identifier. The resolution of the third normal form is shown in Figure 11. The relationship cardinalities can be further modified to reflect organizational working.

Figure 11

Boyce-Codd Normal Form (BCNF)
The Boyce-Codd normal form (BCNF) extends the third normal form. The Boyce-Codd normal form rule is that every determinant is a candidate key. Even though Boyce-Codd normal form and third normal form generally produce the same result, Boyce-Codd normal form is a stronger definition than third normal form. Every table in Boyce-Codd normal form is by definition in third normal form. Boyce-Codd normal form considers two special cases not covered by third normal form:

1. Part of a composite entity identifier determines part of its attribute, and
2. a non entity identifier attribute determines part of an entity identifier attribute.

These situations are only possible if there is a composite entity identifier, and dependencies exist from a non-entity identifier attribute to part of the entity identifier. For example, consider the entity type StudentConcentration as shown in Figure 12. The entity type is in third normal form, but since there is a dependency FacultyName ? MajorMinor, it is not in Boyce-Codd normal form.

Figure 12

To ensure that StudentConcentration entity type stays in Boyce-Codd normal form, another entity type Faculty with one-to-many relationship is constructed as shown in Figure 13. The relationship cardinalities can be further modified to reflect organizational working.

Figure 13

Fourth Normal Form (4NF)
Fourth normal form rule is that there should not be more than one multi-valued dependency in a table. For example, consider the Student Details entity type shown in Figure 6. Now, during requirements analysis if it is found that the MajorMinor values of a student are independent of the Activity performed by the student, then the entity type structure will violate the fourth normal form. To resolve the violation of the fourth normal form separate weak entity types with identifying relationships are created as shown in Figure 14. The StudentFocus and StudentActivity entity types are weak entity types. The relationship cardinalities can be further modified to reflect organizational working. It is now presumed that the Student entity type has the functional dependency SID ? Name, Street, City, Zip.

Figure 14

3.0 Conclusions

Instead of applying normalization principles during the relational design portion of logical database design phase, it is better to apply them during the conceptual modeling phase. Due to the similarity in the notion of an entity type and a relation, normalization concepts when explained or applied to an ERD may generate a richer model. Also, such an application enables a better representation of user working requirements. This application now results in the specification of additional guidelines for refining an ERD. These guidelines can be stated as follows:

1. There should be only one dependency in each entity type where the determinant is the entity identifier.
2. There should not be any additional dependency among the non entity identifier attributes. Any such additional dependency should be represented by a new entity type with one-to-many relationship.
3. If there is a composite entity identifier of three or more attributes it should be ensured that there is only one multi-valued dependency among them.

Study of dependencies among attributes during requirement analysis assist in entity type identifications and cardinality specifications. Since an ERD represents a relational model schema, a normalization ERD improves the modeling effort thereby facilitating a better fit with organizational working.

4.0 References

• Adelman, S., Moss, Larissa and Abai, Majid (2005) Data Strategy, Addison-Wesley, Readings, MA.
• Bala, Mohan and Martin, Kipp (1997) "A Mathematical Programming Approach to Data Base Normalization," Informs Journal of Computing, Vol. 9, No.1, pp. 1-14.
• Balaban, M. and Shoval, P. (1999). Enhancing the ER model with integrity methods. Journal ofDatabase Management, 10(4),14-23.
• Balaban, M. and Shoval, P. (2002). Enforcing Cardinality Constraints in ER Model with Integrity Methods. In Keng Siau (Eds) Advanced Topics in Database Research, Volume 1, 1-16.
• Bock, D. and Ryan, T. (1993). Accuracy in modeling with extended entity relationship and object oriented data models. Journal of Database Management, 4(4), 30-39.
• Booch, G. (1994). Object-Oriented Analysis and Design with Applications (second edition).
• Reading, MA: Addison-Wesley.
• Booch, G., Rumbaugh, J. and Jacobson, I. (1999). The Unified Modeling Language User
• Guide. Reading, MA: Addison-Wesley.
• Chen P. P. (1976). The entity-relationship model: toward a unified view of data. ACM
• Transactions on Database Systems, 1 (1), 9-36.
• Codd, E. F. (1970) "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM, Vol. 13, No. 6, pp. 377-387.
• Date, Chris (2003) Introduction to Database Systems, 8th edition, Addison-Wesley, Readings, MA.
• Dyche, Jill (2000) e-Data, Addison-Wesley, Readings, MA.
• Fowler, M. (1997). UML Distilled. Reading, MA: Addison-Wesley.
• Lenzerini, M. and Nobili, P. (1990. On the satisfiability of dependency constraints in entity-
• relationship schemata. Information Systems, 15 (4),45 3-461.
• Lenzerini, M. and Santucci, G. (1983). Cardinality constraints in the entity-relationship model. In Davis, Jejodia, Ng, and Yeh. (Eds.), Entity-Relationship Approach
• Liautaud, B. and Hammond, M (2001) e-Business Intelligence, McGraw-Hill, NJ.
• Mannino, M. V. (2006) Database Design, Application Development, and Administration, Third Edition, McGraw-Hill, NJ.
• Rob, Peter and Coronel, Carlos (2006) Database Systems Design Implementation & Management, Course Technology, Boston, MA.
• Thalheim, B. (1998). Fundamentals of Entity-Relationship Modeling. New York: Springer-Verlag.

NORMALIZATION

Normalization


Database design process (review)
• Gathering user needs / business
• Develop the ER model based on user needs / business
• Convert ER Model to set the relation (table)
• Normalisasikan relations, to remove anomalies
• to implement the database for each table to create relationships that are ternormalisasi

Database normalization
• normalization process is the establishment of the database structure so that most of the ambiguity can be removed.
• The normalization stage starting from the light (1NF) to most stringent (5NF)
• Usually only up to the level of 3NF or BCNF because already sufficient to generate the table-a table of good quality.

Advanced
• Why do normalization?
- Optimization table structures - Increase the speed - Eliminate income data the same
- More efficient use of storage media
- Reduce redundancy
- Avoiding anomalies (insertion anomalies, deletion anomalies, update anomalies).
- Improved data integrity

More
• A table said good (efficient) or if the normal 3 to meet the following criteria:
- If there is decomposition (decomposition) table, it must be guaranteed safe dekomposisinya (Lossless-Join Decomposition). That is, after the table is described / didekomposisi a new table-table, the table-table can generate a new table with the same exact.
- Maintain the functional dependence on the change data (Dependency preservation).
- No violate Boyce-Code Normal Form (BCNF)
• If the three criteria (BCNF) can not be met, then at least the table does not violate the Normal Form of the third stage (3rd Normal Form / 3NF).

Functional Dependency
• Functional Dependency attributes describe the relationship in a relationship
• An attribute said functionally dependant on the other, if we use the value attribute to determine the value of the other attributes.
• The symbol that is used to represent → functional dependency. → reads determine the functional

Continue
• notation: A → B A and B are attributes of a table. A means of determining the functional B or B depends on A, if and only if there are 2 rows of data with the same value of A, then B is also the same value
• notation: A → B or A x→ B It is the opposite of the previous notation.

Functional DEPENDENCY (FD)

Example

Functional Dependency:
• NRP → Name
• subject_lecture, NRP → Value

Non Functional Dependency:
• subject_lecture → NRP
• NRP → Value Functional Dependency
• Functional Dependency of the table value
- Nrp → Name Because for each value Nrp the same, then the value of the same name
- (subject_lecture, NRP) → Value Because the value of attributes depending on the NRP and subject_lecture together. In another sense subject_lecture for the NRP and the same, they also rated the same, because subject_lecture and the NRP is a key (is unique).
- subject_lecture → NRP - NRP → Value

FIRST NORMAL FORM (First Normal Form - 1NF)
A table said to be normal in the form of identity if it is not in the unnormalized form of a table, where there is a kind of field multiplication and field that allows a null (empty) Not the came by:
• Attribute values, many (Multivalued attributes).
• Attribute a composite or a combination of both.

So:
• Price is the domain attribute must be atomic rates Eg student data as follows:

Or

Table
-the table above does not meet the requirements Inf. Decomposition becomes:


Student table:

Table hobbies:

Second NORMAL FORM (Second Normal Form - 2NF)
• The form of normal 2NF met in a table if it meets the form of 1NF, and all the attributes than the primary key, have a full Functional Dependency on primary key
• A table does not meet 2NF, if there are attributes that dependence if (Functional Dependency) are only partial (only depending on the part of the primary key)
• If there are attributes that have no dependence on the primary key, then the attributes must be moved or removed Second NORMAL FORM (Second Normal Form - 2NF
• functional dependence X → Y said if fully remove an attribute A from X means that Y is no longer dependent functional.
• functional dependence X → Y if said partial delete an attribute A from X means that Y is functionally dependent.
• The scheme in the form of the relation R 2NF if every non-primary key attribute A € R depend on the full primary key fungsioanl R.

Example:
Table following this meet Inf, including tetafi not 2NF.
• Not meet 2NF, because (NIM, code lecture of subject) is regarded as the primary key:
(NIM, codelecture of subject) → Name Mhs (NIM, codelecture of subject) → Address (NIM, codelecture of subject) → lecture of subject (NIM, code lecture of subject) → SKS (NIM, code lecture of subject) → alfabeth of value

• The table should be a few tables compositioned eligible 2NF
• Functional if dependency as follows:
• (NIM, KodeMk) → NilaiHuruf (fd1)
• NIM → (NamaMhs, Address) (fd2)
• KodeMk → (Matakuliah, SKS) (fd3)
• So that:
• fd1 (NIM, KodeMk, NilaiHuruf) → Table Values
• fd2 (NIM, NamaMhs, Address) → Table Student
• fd3 (KodeMk, Matakuliah, SKS) → Table MataKuliah NORMAL FORM Third (Third Normal Form - 3NF)
• The form of normal 3NF has been met if the form meets 2NF, and if there are no non-primary key attribute that has a dependence on non-primary key attributes of the other (transitive dependencies).

Example
• Table the following students qualified 2NF, 3NF, but does not meet
• Because there are non-primary key attribute (ie, City and Provincial), which has a dependence on non-primary key attributes of the other (ie zip code):
• postcode → (City, Province)
• So that the table should be didekomposisi:
• Students (NIM, NamaMhs, Road, zip code)
- postcode(zip code, Province, City)

Boyce-Codd Normal Form (BNCF) Boyce-Codd
Normal Form constraint has a stronger form of the Normal third. To be BNCF, relations must be in the form of Normal first and forced each of the attributes depends on the function in the super key attributes. In the example below there is a relationship seminar, is the Primary Key NPM + Seminar. Students may take one or two seminars. Each seminar requires 2 each of the students and led by one of the 2 seminar. Each leader can only take one seminar course.
NPM in this example and show a Seminar of guidancers

Boyce-Codd Normal Form (BNCF) Relations Seminar is a form of Third Normal, but not BCNF Seminar Code because the function depends on the guidancers, if any guidances can only teach a seminar. Seminar depend on one key attribute is not as super disayaratakan by BCNF. But relations Seminar should be parsed into two namely:

Normal form of the fourth and fifth
• Relations in fourth normal form (4NF ) if the relation in BCNF and dependency not contain many values. To remove the dependency of many values from a relation, we divide the relationship into two new relations. Each relation contains two attributes that have a lot of relationship value.
• Relations in fifth normal form (5NF) deal with the property called the join without any loss of information (lossless join). Fifth normal form (also called the 5 NF PJNF (projection join normal form). The case is very rare and appear difficult to detect in practice.

DATA BASE AND ER- Diagram

DATABASE AND ER-Diagram

DEFINITION Database

Definition of the database:

A set of data stored in the magnetic disk, optical disk or other secondary storage Collection of integrated data-related data of an enterprise (company, government or private)

A companies manufacturing production planning data, actual production data, data ordering materials, etc.

A hospital patient data, doctor, nurse, etc.

DATABASE MANAGEMENT SYSTEM

Collection / database combined with software applications that are based database Application programs are used to access and maintain databases The main purpose DBMS is to provide an environment that is efficient and easy to use, withdrawal and storage of data and information Collection / database combined with software applications that are based database Application programs are used to access and maintain databases The main purpose

DBMS is to provide an environment that is efficient and easy to use, with drawal and storage of data and information

BIT, BYTE, Field

A part is a bit of data which contains the smallest value of 0 or 1

Byte a-bit set of bit similar

Field a-byte set of bytes is similar, in the data base used the term attribute

NIM NAME ADDRESS

9455500001 Abdullah objects RAYA NO 4

9455500002 Aminah CILEDUG NO 4

9455500003 Budiman Halimun NO 7

Attribute / Field

It is the nature or characteristics of an entity that provides provide detail on these entities

A relationship can also have attributes

Example attributes:

STUDENTS: NIM, NAME, ADDRESS

CAR: NOMOR_PLAT, COLOR, TYPE, CC TYPE-TYPE

Attribute

Single vs. multivalue Single a can only be filled at most one value a

Multivalue can be filled with more than one value with the same type of

Atomic vs. composition Atomic a can not be divided into the attributes of smaller a composition is a combination of several attributes of a smaller

Derived attribute attribute value can be derived from the value of other attributes, eg age a attributes resulting from the date of birth

Null Value attribute

Attributes that have no value to a record

Mandatory attribute Value

Attributes must have values

RECORD / TUPLE

It is a line of data in a relationship Consists of the set of attributes where the attribute-attribute-attribute is to inform each other entity / relationship fully

Entity / FILE

File is a collection of similar records and have the same elements, the same attributes but different data values.

File Type

In processing applications, files can follows occupy meaning:

- Master File

- Transaction Files

- File Reports

- File History

- File Protection

- File Work

DOMAIN

- Domain is a set of values that are allowed to reside in one or more attributes. Each attribute in a database relasional is defined as a domain

Element KEY DATA

Key elements of record which is used to find these records at the time of access, or can also be used to identify each entity / record / line

SPECIES OF KEY

Superkey is one or more attributes of a table that can be used to identify entityty / record of the table are unique (not all attributes can be superkey)

Cadidate Key is a super key with minimal attributes. Candidate must not contain a key attribute of the table so that the other candidate key is certain superkey but not necessarily vice versa. Primary Key One of the key attributes of the candidate can be selected / specified a primary key with the three following criteria:

1. Key is more natural to use as reference

2. Key is more simple

3. Key is guaranteed uniqueness.

Alternate Key is an attribute of the candidate key is not selected to be primary key.

Foreign Key is any attribute that points to the primary key in another table. Foreign key will be going on a relationship that has kardinalitas one to many (one to many) or many to many (many to many). Foreign key is usually always put on the table that point to many. External Key is a lexical attribute (or set of lexical attributes) that values are always identify an object instance

ERD (Entity Relationship Diagram)

ERD is a model of a network that uses word order is stored in the abstract system. Differences between the DFD and ERD. DFD is a model of network functions that will be implemented by the system ERD is a model that emphasizes the network data on the structure and relationship data Elements of the ERD

Entity In the ER Diagram Entity is described with the form of a rectangle. ER Entity is something that exists in the real system and the abstract where the data stored or where there are data.

Relationship ER diagram on the relationship can be described with a lozenge. Relationship is a natural relationship that occurs between entities. In general, the name given to the verb base making it easier to do the reading relations.

Relationship Degree is the number of entities participating in a relationship. Degree which is often used in the ERD.
Attribute is the nature or characteristics of each entity and relationship cardinalitationstuple indicates the maximum number that can be relations with entities on the other entity

Degree of relationship

Unary Relationship model is the relationship between the entity originating from the same entity set.

Binary Relationship model is the relationship between two entities.

Ternary Relationship is a relationship between the instance of three types of entities are unilateral

CardinalitationThere

are three cardinalitation relations, namely - One to One: Level one to one relationship with the one stated in the entity's first event, only had one relationship with one incident in which the two entities and vice versa. - One to Many or Many to One: Level one to many relationship is the same as the one to many depending on the direction from which the relationship eyes.For an incident on the first entity can have any relationship with incident many on the second entity, if the one incident on the the second entity can only have one relationship with the incident on the first entity. Many To Many: if any incident occurs in an entity have many relationships with other entities in the event

EXEMPLARY KARDINALITAS

Notation (E-R diagram)
symbolic notation in the ER diagram is

1. rectangle represent the collective entity

2. circles represent attributes

3. rhomb stated set of relationships

4. line as a link between the collective set of relationships with the entity and the collective entity with attributed.

DATA FLOW DIAGRAM (DFD)

DATA FLOW DIAGRAM

Data Flow Diagram (DFD) is a tool that is used to describe a system that already exists or the new system will be developed logically without considering the physical environment where the data flow or the physical environment where the data is saved. DFD This is also called by the name Bubble chart, Bubble diagram, process models, work flow diagrams, or models function

Foreign entity Is unity in the environment outside the system that can be a person, organization or other system that is in the outside environment that will provide input or receive output from the systemProcess A process is an activity or work done by the person, machine or a computer from the data that flow into the process to generate data that will flow out of the process
Save data Savings is a savings of data from the data can be: a. A file or database in the computer system b. A manual record keeping or c. A box where the data in a table d. A table reference manual e. Agenda or a book

DATA FLOW Diagram Component
1. Terminator components / Foreign Entity Terminator represent external entities that communicate with system that is currently being developed. Usually known as the terminator name of foreign entities (external entity).
There are two types of terminator: Terminator Source (source): the terminator into the source. Terminator Destination (sink) is the terminator of a goal data / information system.

Terminator can be a person, group of people, organizations, departments in the organization, or company but at the same system beyond the current model is made. Terminator can also be departments, divisions or outside the system systems that communicate with the system under development

There are three important issues that must be remembered about the terminator: Terminator is a part / the environment outside the system. Flow data connecting terminator system with different processes, shows the relationship system with the outside world. Professional Systems reserve the right not to change the contents or the way work organization or procedures relating to the terminator Relations between the terminator is the one with the other not depicted on the DFD.

Process Components Describe the process components of the system that transform input into output. The process is given a name to describe the process / activities that are / will be implemented. Giving the name of the process is done with using a transitive verb (the verb need object), such as Calculating Salaries .
There are a few things to note about the process:
The process must have input and output. The process can be connected with component terminator, the data store or data flow through process.
System / sections / divisions / departments that are analyzed by professional system components are described with the

Generally, errors in the DFD process is:

1. The process does not have any input but the output. This error is called the black hole (black hole), because the data into the process and does not vanish like to include in the black hole
2. The process of producing output, but did not receive this input. Mistake called miracle (magic), because the output produced magically without ever receiving input


Component Data Store This component is used to create a model set of data packets and given the name of the plural noun, such as Student. Data store is usually associated with the storage-storage, such as file or database associated with the storage of the computer, such as a diskette file, files, hard disk, magnetic tape files. Also store data related to the storage manually, such as address books, file folders, and the agenda

A data store associated with the flow of data only on the components process, not with the other components DFD. Data flows that connect the data store with an understanding of the process have the following:

1.Flow data from the data store, which means as the initialization or reading one single packet of data, more than one packet of data, part of a single packet of data, or some of the more from one packet data to a process
2.Flow of data to store data as a means updated data, such as adding a new data packet or more, remove setup packet or more, or change / modify one or more data packet


In the first clear understanding that the data store does not change, if a packet of data / information from a data store to a process. Instead of the second data store has changed as a result of the flow enter the data store. In other words, the process flow of data is responsible for the changes that occur in the data store.

Component Data Flow / Data Flow A data flow / data flow is depicted with the arrow, which indicates the direction to go and out of a process. This data flow is used to explain the movement of data or packet data / information from one system to the other part.
In addition to indicating the direction, flow data on the model made by the professional system can represent bits, characters, messages, forms, real numbers, and various information related to the computer. Flow data can also represent data / information that is not associated with the computer. Flow data should be named according to the data / information is usually the name of the data flow is done by using the noun, for example, Sales Reports. There are four concepts that need to be in the drawing groove data, namely: Concept Data Package (packets of data) When two or more data flows from a source to the same goal and have the same relationship, and should be considered as a single data flow, because the data that flow together as one package
·Spread the concept of Data Flow (Data Flow Diverging) Flow of data spread shows a number of copies of data packets that originate from the same source to a different destination, or a complex data package is divided into multiple elements of data that is sent to a different destination, or flow data for a data packet that has a different value which will be sent to a different destination
·The concept of Data Flow gather (Converging Data Flow) Some of the data flows of different resources to join together towards the same goal.
·The purpose or the concept of Data Flow All data flows must contain at least one process. The purpose is this sentence:

A flow of data generated from a process and to a data store and / or terminator .A flow of data generated from a data store and / or terminator and to a process. A flow of data generated from a process and leading to a process

INVESTMENT DATA FLOW Diagram There are two forms of DFD, the Physical Data Flow Diagram, Data Flow Diagram and Logic. Physical data flow diagram more emphasis on how the process of the system applied, while the data flow logic diagram further emphasize the processes of what is there in the system. Physical Data Flow Diagram (DADF) DADF is used to more accurately describe the existing system (old system). The emphasis of DADF is how process of the system is applied (in a way what, where and by whom), including manual processes. To obtain a description of how the system is implemented, DADF must include:

1. Manual processes are also described.

2. The name of the data flow must include a description detailed enough to show how the systems work to understand the system.

3. Savings data can show savings of non-computer.

4. The name of saving the data type of application must indicate whether manual or computerized. Manually, for example can show notes books, desk workers. How are shows such as computerized order file, database file
5. The process must show the name of the processor, the person, department, computer system, computer program or the name of the access process.

Data Flow Diagram Logic (DADL) DADL more appropriately used to describe the system that will be proposed (new system). For computerized systems, DADL drawing only shows the process needs of the proposed system of logic, usually processes described is only the processes of a computer course.

TERMS-TERMS DEVELOPMENT DATA FLOW Diagram DFD terms of making this system will help professionals to avoid the wrong formation DFD or the DFD is incomplete or does not logically consistent. Some conditions formation DFD system can help professionals to establish the correct DFD, fun to see and easy to read by the user. Terms of making DFD are:

1. Giving a name to each component DFD

2. Giving number on the component process

3. DFD representation as possible so that good views

4. Tergiversation DFD representation of complex

5. DFD is formed logically consistent

1. name for each component DFD As mentioned previously, the components represent the terminator of the environment outside the system, but have any influence on the system that is being developed. So that the user knows the system environment wherever they are related, this terminator component must be named in accordance with the external environment that affect this system. Terminator component are usually given a name with the word object.
Next is a component of the process. The components of this process represent the system functions that will be implemented or show how the system functions performed by a person, group of people or machines. So it is very clear that this component need to be given the appropriate name, so that anyone who read the DFD especially feel confident that the DFD was established that this model is accurate. Giving the name of the component process better show the rules that will be implemented by someone than by giving the name or identity of the person who will implement them. There are two reasons why not the name or identity of the person (who perform the function system) is used as the name of the process, namely:
1.people may be replaced by another person while coming, so when there is turnover every time people who carry the function, then the system must be changed again.
2.People may not perform a function of the system alone, but some of the different functions of the system. Describe the process than some of the same name but different meaning, it is better to show the tasks / functions of the actual system will be implemented
Because the component name for the process showed better task / function of the system will be implemented, the better use of the name is transitive. Giving a name for the component data store using the noun, because the data store that indicates what data is stored in the system needs to perform its tasks. If the system time when the data need to conduct its work, the data is still there, because the save system. Similarly, for the data flow component, the name given to the better use of the word. Because of this data shows the flow of data and information required and issued by the system in the implementation of its tasks

2. Tax Provision on the Process Component Usually provide a professional system with a number Ascending component in the process as a reference. It does not matter how the numbers of this process are given. The number can be given from left to right or from top to bottom, or can be also done with patterns for a specific number of these remain consistent in the number that is used
The numbers given to the process component of this process is not intended that the process is carried out sequentially. Giving this number is that a reading process in a discussion will be easier with only mention the process only if compared to the process, especially if the name is long and difficult process. Purpose of the number in the process is even more important is to show reference to the numbering scheme in the hierarchy levelisasi DFD. In other words, the number of this process is the basis of the number levelilasi DFD

DFD drawing as often as possible Depiction DFD can be done many times until the DFD technique is correct, can be received by the user, and have been professional enough so that the system rapih not ashamed to show it to the DFD and one .with other words, this depiction DFD made to form DFD is good views, and easy to read by the user and other system professionals. The beauty of drawing DFD depends on the standards required by professional organizations where the system is working and the software used by professionals in the system make DFD. delineation nice to see that can be done with attention to the following:
Size and shape the process. Some users sometimes feel confused when the size of a process different from the other process. They will think that the process with a larger size will be more important than suspected that the process is smaller. This is only the name because the process is longer than the others. So, should the process have described the size and forms of the same
Flow data and flow of data around straight. Flow data can be described with only a circle or straight line. Which is seen more comfortable depending on who will see the DFD.
DFD with the image and the image of the machine. DFD can be described manually or by using the assistance of machines, depending on the choice or professional system.

4.Giversation DFD representation of complex DFD goal is to create a model function that must be implemented by a system and the interaction between functions. Other goal is to model that made it easy to read and understand not only by the professional system to create a DFD, but also by the experienced with the subject of the case. This means that the DFD must be easy to understand, read, and fun to see

On many issues, DFD is created does not have too many processes (process a maximum of six) with the data store, data flow, and terminator that are associated with the process in one diagram. If too many processes, terminator, the data store, data flow and is described in a DFD, then the possibility exists that occurred many contradiction in the data flow in DFD. Cross flow of this data will be difficult to cause the user to read and understand the DFD certain. So the fewer the data on the cross DFD, the DFD is the better established by professional system. Contradiction flow of this data can be avoided with the DFD describes the many-level (levelisasi DFD), or by using the duplicate of the DFD components. DFD component that can use only duplicate parts store and terminator. Provision is also duplicates can not be given at a professional system that creates DFD, but little use of the duplicate, the better that DFD.
Provision of duplicate data store is done by giving straight line or symbol asterik (*), while the terminator to use a forward slash symbol (/) or asterik (*). A large number of duplicates in the duplicate symbol that is used depends on the number of duplicates is used

5. Consistent representation of DFD DFD representation of the group must be consistent another .Professional system DFD describes the DFD based on the levels of DFD with the aim that the DFD is in it easily read and understood by the system. This is in accordance with one of the goals or requirements create DFD

Drawing DFD There are no standard rules to describe the DFD. But from the various references available, outline the steps to create a DFD are:

1. Identify the first all foreign entities are involved in the system.

2. Identification of all input and output are involved with outside entities.

3.Create a Context Diagram (context diagram)
Consist of a process and depict scope from a systemRepresenting highest level of DFD depicting all system to input and output of the systemSystem is limited by boundary (depicted by dash line)There is no storage
This chart is a chart of the highest level DFD that describes the relationship with the environment outside the system. How:
Specify the name of the system.

> Determine the limits of the system.

> Specify the terminator are present in the system.

> Define what is received / given terminator from / to the system.

> picture context diagram

4. Create Diagram Level Zero Diagram of this decomposition is the context diagram. How:

> Determine the main process in the system.

> Determine what is given / received each process to / from the system while considering the concept of balance (the data flow outgoing / incoming from a level should be the same as the flow of data entry / exit to the next level).

> If necessary, store appear data (master) as the source and destination flow data.

> picture diagram level zero.

> Avoid snippet flow data

> Give the number on the main process (the number does not indicate the order process).

5.Create Diagram Level One Decomposition diagram is a diagram of the zero level. How: Define the process of smaller (sub-process) from the main in the zero level. Determine what is given / received each sub-process to / from the system and note the concept of balance. If necessary, store appear data (transaction) as the source and destination flow data.

One picture level DFD

> Avoid snippet flow of data.

> Give the number on each sub-process show that decomposition of the process before.

Example: 1.1, 1.2, 2.1

6. DFD Level Two, Three, ...

This diagram is a decomposition of the previous level. Process decomposition is done with the process until ready to poured in the program. Rules that are used with the same level one.
There are a few things to note in drawing levelisasi DFD, namely: In the context of the diagram, there are several things that need to be system such as the relationship with the outside world that influence, representation system in a process, and data representation store (optional) which is known to store data or external data master store. Data store means this is an external data store is generated by the system that is being analyzed, but is used by another system, or store the data generated by other systems but used by the system that is being analyzed.

Balancing in the drawing need to levelitation DFD DFD Balancing this is a balance between flow of data entry / exit of a level must be the same with the flow data entry / exit to the next level

Data Dictionary

1. Work to help the system to interpret the application in detail and organize all elements of the data used in the system precisely so that the system analyst and have a basic understanding of the same input, output, storage and processing .

2. At analysis, the data dictionary is used as a means of communication between the systems analyst with the user.

3. At the system design, data dictionary is used to design input, reports and databases .

4. Flow data on the global DAD, further details can be seen in the data dictionary

Restrictions in DFD

1. Data flow not be outside of the entity directly to the other outside entities without going through a process.

2. Data flow not be directly from the data store to entities outside without going through a process.

3. The data flow not store data directly from the data store without the other through a process.

4. Data flow from one process directly to the other without going through the process of a data store should / be avoided as much as possible