Normalization, at a high level, is generally defined as the elimination of redundancies from an entity.
Although this is an accurate definition, it does not fully convey the true impact of what normalization is trying to accomplish, and more important, what it means not to apply it to your model.
Before we explain this any further it is necessary to define the five’s forms of normalization. These forms are known as: 1st normal form, 2nd normal form, 3rd normal form, 4th normal form and 5th normal form. Normal form is typically abbreviated “NF.” Each normal form should be dependent on the completion of the previous form, therefore, normalization should be applied in order. Below are the rules that satisfy each normal form:
1st NF: No repeating elements or repeating groups
2nd NF: No partial dependencies on a concatenated key
3rd NF: No dependencies on non-key attributes
Why do normalization :
1. optimalizing of table structures
2. increasing speed
3. eliminating of the same input data
4. more efficient in using storage
5. decreasing redundancy
6. avoid anomaly (insertion anomalies, deletion anomalies, update anomalies).
7. increase data integrity
Functional Dependency
- described connection of attributes in a relation
- an attribute told as functionally dependant inother if we using attribute value for determine another attribute value
- symsbol that used is for deputizing functional dependency that read as functional to determine.
- notation : A -> B
A and B is attribute from a table. its means as functional A determine B or B depended in A, if and as if there are 2 row data with same A value, so B value can be same.
- notation : A-/>B or Ax->B
- it is reverse from previously notation.
First Normal Form - 1NF
A table on the form said to be normal if I did not reside in the unnormalized form of a table, where there is a kind of field multiplication and field that allows a null (empty)
Not the allowed:
-Many attributes of value (Multivalued attributes).
-Attributes composite or a combination of both.
So:
-Price is the domain attribute must be atomic rates
Second Normal Form - 2NF
-Normal form 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(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
-Functional dependency X -> Y is full if it is said to delete an attribute A from X means that Y is no longer dependent functional.
-Functional dependency X -> Y said if deleting a partial attribute A from X means that Y is functionally dependent.
-Relation scheme R in the form 2NF if every non-primary key attribute A E R depend on the full primary key fungsioanl R.
Third Normal Form - 3NF
Normal form 3NF fulfilled 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).
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 Kesatu 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 lecture.
Normal form of the fourth and fifth
-Relations in the fourth normal form (NF 4) if the relation in BCNF and dependency tdak 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.
Minggu, 26 April 2009
Minggu, 19 April 2009
DATABASE AND ER-Diagram
DEFINITION 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) Is a system which consists of collection of the file (table) in a database in a computer system and a related set of data base management program (DBMS:Database Management System) that allows several users and / or other programs for acess and manipulate files ( table-table
DATABASE MANAGEMENT SYSTEM (DBMS)
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.
ER Model Concepts
-Entities and Attributes
–Entities are specific objects or things in the mini-world that are represented in the database. For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT
–Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate
–A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘
–Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange, enumerated type, …
Types of Attributes
1.Simple
Each entity has a single atomic value for the attribute. For example, SSN or Sex.
2.Composite
The attribute may be composed of several components. For example, Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name (FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite.
3.Multi-valued
An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.
4.In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels although this is rare. For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)}.
Entity Types and Key Attributes
1.Entities with the same basic attributes are grouped or typed into an entity type. For example, the EMPLOYEE entity type or the PROJECT entity type.
2.An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE.
3.A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity type with components (Number, State).
4.An entity type may have more than one key. For example, the CAR entity type may have two keys:
–VehicleIdentificationNumber (popularly called VIN) and
–VehicleTagNumber (Number, State), also known as license_plate number.
SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS
Weak Entity Types
1.An entity that does not have a key attribute
2.A weak entity must participate in an identifying relationship type with an owner or identifying entity type
3.Entities are identified by the combination of:
–A partial key of the weak entity type
–The particular entity they are related to in the identifying entity type
Constraints on Relationships
1.Constraints on Relationship Types
-( Also known as ratio constraints )
- Maximum Cardinality
* One-to-one (1:1)
* One-to-many (1:N) or Many-to-one (N:1)
* Many-to-many
-Minimum Cardinality (also called participation constraint or existence dependency constraints)
* zero (optional participation, not existence-dependent)
* one or more (mandatory, existence-dependent)
Attributes of Relationship types
A relationship type can have attributes; for example, HoursPerWeek of WORKS_ON; its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT.
Structural constraints on relationships:
-Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON THE LINK.
-Participation constraint (on each participating entity type): total (called existence dependency) or partial.
SHOWN BY DOUBLE LINING THE LINK
NOTE: These are easy to specify for Binary Relationship Types.
Alternative (min, max) notation for relationship structural constraints:
-Specified on each participation of an entity type E in a relationship type R
-Specifies that each entity e in E participates in at least min and at most max
relationship instances in R
-Default(no constraint): min=0, max=n
-Must have min£max, min³0, max ³1
-Derived from the knowledge of mini-world constraints
Examples:
- A department has exactly one manager and an employee can manage at most one department.
– Specify (0,1) for participation of EMPLOYEE in MANAGES
– Specify (1,1) for participation of DEPARTMENT in MANAGES
- An employee can work for exactly one department but a department can have any number of employees.
– Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
– Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
The (min,max) notation relationship constraints.
Relationships of Higher Degree
- Relationship types of degree 2 are called binary
- Relationship types of degree 3 are called ternary and of degree n are called n-ary
- In general, an n-ary relationship is not equivalent to n binary relationships
- Higher-order relationships discussed further in Chapter 4
Key
- Super Key
A superkey is an attribute or a set of attributes that uniquely identify the relation. That is, no two tuples have the same values on the superkey. By definition, a relation consists of a set of distinct tuples. The set of all attributes in the relation forms a superkey.
- Candidate Key
A key K is a minimal superkey, meaning that any proper subset of K is not a superkey. It is possible that a relation has several keys. In this case, each of the keys is called a candidate key.
- Primary Key
The primary key is one of the candidate keys designated by the database designer. The primary key is often used to identify tuples in a relation.
- Foreign Key
In a relational database, data are related. Tuples in a relation are related and tuples in different relations are related through their common attributes. Informally speaking, the common attributes are foreign keys. The foreign key constraints define the relationships among relations.
- External Key
The external key is a lexical attribute (or compilation lexical attribute) that the values always identify an object instance.
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) Is a system which consists of collection of the file (table) in a database in a computer system and a related set of data base management program (DBMS:Database Management System) that allows several users and / or other programs for acess and manipulate files ( table-table
DATABASE MANAGEMENT SYSTEM (DBMS)
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.
ER Model Concepts
-Entities and Attributes
–Entities are specific objects or things in the mini-world that are represented in the database. For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT
–Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have a Name, SSN, Address, Sex, BirthDate
–A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘
–Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange, enumerated type, …
Types of Attributes
1.Simple
Each entity has a single atomic value for the attribute. For example, SSN or Sex.
2.Composite
The attribute may be composed of several components. For example, Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name (FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite.
3.Multi-valued
An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.
4.In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels although this is rare. For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)}.
Entity Types and Key Attributes
1.Entities with the same basic attributes are grouped or typed into an entity type. For example, the EMPLOYEE entity type or the PROJECT entity type.
2.An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE.
3.A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity type with components (Number, State).
4.An entity type may have more than one key. For example, the CAR entity type may have two keys:
–VehicleIdentificationNumber (popularly called VIN) and
–VehicleTagNumber (Number, State), also known as license_plate number.
SUMMARY OF ER-DIAGRAM NOTATION FOR ER SCHEMAS
Weak Entity Types
1.An entity that does not have a key attribute
2.A weak entity must participate in an identifying relationship type with an owner or identifying entity type
3.Entities are identified by the combination of:
–A partial key of the weak entity type
–The particular entity they are related to in the identifying entity type
Constraints on Relationships
1.Constraints on Relationship Types
-( Also known as ratio constraints )
- Maximum Cardinality
* One-to-one (1:1)
* One-to-many (1:N) or Many-to-one (N:1)
* Many-to-many
-Minimum Cardinality (also called participation constraint or existence dependency constraints)
* zero (optional participation, not existence-dependent)
* one or more (mandatory, existence-dependent)
Attributes of Relationship types
A relationship type can have attributes; for example, HoursPerWeek of WORKS_ON; its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT.
Structural constraints on relationships:
-Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON THE LINK.
-Participation constraint (on each participating entity type): total (called existence dependency) or partial.
SHOWN BY DOUBLE LINING THE LINK
NOTE: These are easy to specify for Binary Relationship Types.
Alternative (min, max) notation for relationship structural constraints:
-Specified on each participation of an entity type E in a relationship type R
-Specifies that each entity e in E participates in at least min and at most max
relationship instances in R
-Default(no constraint): min=0, max=n
-Must have min£max, min³0, max ³1
-Derived from the knowledge of mini-world constraints
Examples:
- A department has exactly one manager and an employee can manage at most one department.
– Specify (0,1) for participation of EMPLOYEE in MANAGES
– Specify (1,1) for participation of DEPARTMENT in MANAGES
- An employee can work for exactly one department but a department can have any number of employees.
– Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
– Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
The (min,max) notation relationship constraints.
Relationships of Higher Degree
- Relationship types of degree 2 are called binary
- Relationship types of degree 3 are called ternary and of degree n are called n-ary
- In general, an n-ary relationship is not equivalent to n binary relationships
- Higher-order relationships discussed further in Chapter 4
Key
- Super Key
A superkey is an attribute or a set of attributes that uniquely identify the relation. That is, no two tuples have the same values on the superkey. By definition, a relation consists of a set of distinct tuples. The set of all attributes in the relation forms a superkey.
- Candidate Key
A key K is a minimal superkey, meaning that any proper subset of K is not a superkey. It is possible that a relation has several keys. In this case, each of the keys is called a candidate key.
- Primary Key
The primary key is one of the candidate keys designated by the database designer. The primary key is often used to identify tuples in a relation.
- Foreign Key
In a relational database, data are related. Tuples in a relation are related and tuples in different relations are related through their common attributes. Informally speaking, the common attributes are foreign keys. The foreign key constraints define the relationships among relations.
- External Key
The external key is a lexical attribute (or compilation lexical attribute) that the values always identify an object instance.
Minggu, 05 April 2009
DATA FLOW DIAGRAM
Data flow diagram functions to figure division system into smaller module, making easy user that insufficiently understand computer area for understands system that will be worked. DFD constitutes tool that is utilized on systems developmental methodology which most structure.
A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps. DFD represent a logical model that shows what the system does, not how it does. That distinction is important because focusing on implementation issues at this point would restrict your search for the most effective system design.
A DFD is a tool that shows how data enters and leaves a particular process. A DFD has four possible components:
PROCESSING SYMBOL
A process receives input data and produces output that has a different content, form, or both. For instance, the process for calculating pay uses two inputs (pay rate and hours worked) to produce one output (total pay). Process can be very simple or quite complex. In a typical company, processes might include calculating sales trends, filling online insurance claims, ordering inventory from a supplier’s system, or verifying e-mail addresses for Web costumers. Processes contain the business logic, also called business rules that transform the data and produce the required results.
The symbol for the process is a rectangle with rounded corners. The name of the process appears inside the rectangle. The process name identifies a specific function and consists of a verb (and an adjective, if necessary) fallowed by a singular noun. Examples of the process are APPLY RENT PAYMENT, CALCULATE COMMISSION, ASSIGN FINAL GRADE, VERIFY ORDER and FILL ORDER.
Processing details are not shown in a DFD. For example, you might have a process named DEPOSIT PAYMENT. The process symbol does not reveal the business logic for the DEPOSIT PAYMENT. To document the logic, you create a process description, which is
explained later in this chapter.
In DFDs, a process appears as a black box, where the inputs, outputs, and general function of the process are known, but the underlying details are not shown. A black box approach shows an information system in a series of increasingly detailed pictures. You use that technique to zoom in and explode each process without confusing the overall view of the system.
DATA FLOW SYMBOL
A data flow is a path for data to move from one path of the information system to another. A data flow in a DFD represents one or more data items. For example, a data flow could represent a single data item (such as student ID number) or it could represent a set of data (such as class roster with student ID number, names and registration dates for a specific class). The diagram does not show the structure and detailed contents of a data flow.
The symbol for a data flow is a line with a single or double arrowhead. The data flow name appears above, below, or alongside the line. A data flow name consists of a singular noun and an adjective, if needed. Examples of data flow names are DEPOSIT, INVOICE PAYMENT, STUDENT GRADE, ORDER and COMMISION. Exceptions to the singular name rule are data flow names, such as GRADING PARAMETERS, where a singular name could mislead you into thinking a singular parameter or singular item of data exists.
DATA STORE SYMBOL
A data store, or a data repository, is used in a DFD to represent a situation in which the system must retain data because one or more processes need to use the stored data at a later time. For instance, instructor needs to store students score on tests and assignments during the semester so they can assign final grades at the end of the term. In a payroll example, you store employee salary and deduction data during the year so you can report total earnings and withholdings at the end of the year.
The physical characteristics of the data store are because you are concerned with a logical model. Also, the length of time that the data is stored is unimportant— it can be a matter of seconds while a transaction is processes or a period of months while data is accumulated for year-end processing. What is important is that a process needs access to the data at some later this time. In DFD, the Gane and Sarson symbol for a data store is a flat
rectangle that is open on the right side and close on the left side. The name of the data store appears between the lines and identifies the data it contains. A data store name is a plural name consisting of a noun and adjectives, if needed. Examples of a data store names are STUDENTS, ACCOUNTS RECEIVABLE, PRODUCTS, DAILY PAYMENTS, PURCHASE ORDER, OUTSTANDING CHECKS, INSURANCE POLICIES, and EMPLOYEES. Exceptions to the plural name rule are collective nouns that represent multiple occurrence of object. For example, GRADEBOOK represents a group of students and their scores.
EXTERNAL ENTITY SYMBOL
An external entity is a person, department, outside organization, or other information that provides data to the system or receives output from the system. The symbol for an entity is a rectangle, which usually is shaded to make it look three-dimensional. The name of the external entity appears inside the square. External entities show the boundaries of the information system and how the information system interacts with the outside world. For
example, a customer submitting an order is an external entity because the customer supplies data to the order system. Other examples of external entities include a patient who supplies medical data, a homeowner who receives a property tax bill, a warehouse that supplies a list of items in stock, and an accounts payable system that receives data from the company’s purchasing system. External entities also are called terminators, because they are data origins or final destinations. Systems analysts call an external entity that supplies data to the system a source, and an external entity that receives data from the system a sink. An external entity name is the singular form of a department, outside organization, other information system, or person. Examples of external entity names are CUSTOMER, STUDENT, EMPLOYEE, MEMBER, SALES REP, WAREHOUSE, INTERNAL REVENUE SERVICE, PAYROLL SYSTEM, and GENERAL LEDGER SYSTEM.
Context Diagrams
During requirements modeling, you used interviews, questionnaires, and other techniques to gather facts about the system, and you learned how the various people, departments, data, and process fit together to support business operations. Now you are ready to create a graphical model of the information system based on your fact-finding results. To learn how to construct DFDs, you will use examples of these information systems. The simplest example is grading system that instructors use to assign final grades based on the scores the students receive during the term. The second example is an order system that a company uses to enter orders and apply payments against a customer’s balance. The third example is a manufacturing system that handles a company’s production. The first step in constructing a set of DFDS is to draw a context diagram. A context diagram is a top-level view of an information system that shoes the system’s boundaries and scope. To draw a context diagram, you start by placing a single process symbol In the center of the page. The symbol represents the entire around the perimeter of the page and use data flows to connect the entities to the central process. You do not show any data stores in a context diagram because data scores are internal to the system. How do you know what external entities and data flows to place in the context diagram? You begin by reviewing the system requirements to identify all external data sources and destinations. During that process, you record the name of the external entities, the name and content of the data flows, and the direction of the data flow. If you do that carefully, and you did a good job of fact-finding in the previous stage, you should have no difficulty drawing the context diagram.
DATA DICTIONARY
A set of DFDs produces a logical model of the system, but the details within those DFDs are documented separately in a data dictionary, which is the second component of structure analysis. A data dictionary, or data repository, is a central storehouse of information about the system’s data. An analyst uses the data dictionary to collect, document, and organize specific facts about the system, including the contents of the data flow, data stores, external entities, and processes. The data dictionary also defines and describes all data elements and meaningful combinations of data elements. A data element, or data item or field, is the smallest piece of data that has meaning within an information system. Examples of the data element are student grade, salary, Social Security number, account balance, and company name. Data elements are combined into records or data flow or retained in a data store. For example, an auto parts store inventory record might include part number, description, supplier code, minimum and maximum stock levels, cost, and list price.
Dictionary’s content Data:
1. Data Current name
Since DD is made bases data current that is adrift at DFD, therefore name of data current shall also be noted at DD, so they what do read DFD and requires more explanation about a given data current at DFD can direct look for it is squashy at DD.
2. Alias
Alias or alias of data gets to be set down if this alias available. Alias needs to be written since same data to have named that variably to person or department one by another.
3. Data Form
Was known that data current can be adrift:
• Of external entity goes to a process, data that is adrift it usually being noted at a document or form;
• Result of a process goes to external entity, data that is adrift it usually exists on write-up media or query is screen look or printed result document computer;
• Result a process goes to process the other, data that is adrift it usually deep shaped variable or needed parameter by its receiver process;
• Result a process that recorded goes to data trove, data that is adrift it usually as a field.
Shaped thus of data that is adrift get as:
• Base document or form
• Printed yielding document computer
• Published reporting
• Variable
• Parameter
• Field
4. Data current
Data current points out where data is adrift and where data will wend. This current information needs to be noted at DD so makes easy to look for current data at DFD.
5. Explanation
For over clarifies again about meaning of noted data current at DD, therefore explanation part can be filled by information about that data current.
BALANCING IN DFD
Data flow that turns in at an issue of one process has to equal data flow that turns in at an issue of details of process on level / level under it. Therefore data flow name that turns in at an issue of one process have with by the name of data flow that turns in at an issue of details of that process and entity’s amount and name external of a process has to equal total and entity’s name external of details of that process.
Things that shall be noticed on DFD who has more than one level:
• Shall available input balance and output among one level and next level
• Balance among level 0 and level 1 is seen on input / output of data flow goes to or of terminal on level 0, meanwhile balance among level 1 and level 2 are seen on input / output of data flow goes to / of process that pertinent
• Data streaming name, storage’s data and terminal on every level shall same if its object with
PROHIBITION IN DFD
Severally prohibition in DFD is as follows:
• Data current may not from external entity directing to wend entity another external without via a process
• Data current may not of direct data trove make towards external entity without via a process
• Data current may not of direct data trove wend another data trove without via a process
• Data current of one process directing to wend another process without via an advisable data trove / one can maybe be avoided
A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps. DFD represent a logical model that shows what the system does, not how it does. That distinction is important because focusing on implementation issues at this point would restrict your search for the most effective system design.
A DFD is a tool that shows how data enters and leaves a particular process. A DFD has four possible components:
PROCESSING SYMBOL
A process receives input data and produces output that has a different content, form, or both. For instance, the process for calculating pay uses two inputs (pay rate and hours worked) to produce one output (total pay). Process can be very simple or quite complex. In a typical company, processes might include calculating sales trends, filling online insurance claims, ordering inventory from a supplier’s system, or verifying e-mail addresses for Web costumers. Processes contain the business logic, also called business rules that transform the data and produce the required results.
The symbol for the process is a rectangle with rounded corners. The name of the process appears inside the rectangle. The process name identifies a specific function and consists of a verb (and an adjective, if necessary) fallowed by a singular noun. Examples of the process are APPLY RENT PAYMENT, CALCULATE COMMISSION, ASSIGN FINAL GRADE, VERIFY ORDER and FILL ORDER.
Processing details are not shown in a DFD. For example, you might have a process named DEPOSIT PAYMENT. The process symbol does not reveal the business logic for the DEPOSIT PAYMENT. To document the logic, you create a process description, which is
explained later in this chapter.
In DFDs, a process appears as a black box, where the inputs, outputs, and general function of the process are known, but the underlying details are not shown. A black box approach shows an information system in a series of increasingly detailed pictures. You use that technique to zoom in and explode each process without confusing the overall view of the system.
DATA FLOW SYMBOL
A data flow is a path for data to move from one path of the information system to another. A data flow in a DFD represents one or more data items. For example, a data flow could represent a single data item (such as student ID number) or it could represent a set of data (such as class roster with student ID number, names and registration dates for a specific class). The diagram does not show the structure and detailed contents of a data flow.
The symbol for a data flow is a line with a single or double arrowhead. The data flow name appears above, below, or alongside the line. A data flow name consists of a singular noun and an adjective, if needed. Examples of data flow names are DEPOSIT, INVOICE PAYMENT, STUDENT GRADE, ORDER and COMMISION. Exceptions to the singular name rule are data flow names, such as GRADING PARAMETERS, where a singular name could mislead you into thinking a singular parameter or singular item of data exists.
DATA STORE SYMBOL
A data store, or a data repository, is used in a DFD to represent a situation in which the system must retain data because one or more processes need to use the stored data at a later time. For instance, instructor needs to store students score on tests and assignments during the semester so they can assign final grades at the end of the term. In a payroll example, you store employee salary and deduction data during the year so you can report total earnings and withholdings at the end of the year.
The physical characteristics of the data store are because you are concerned with a logical model. Also, the length of time that the data is stored is unimportant— it can be a matter of seconds while a transaction is processes or a period of months while data is accumulated for year-end processing. What is important is that a process needs access to the data at some later this time. In DFD, the Gane and Sarson symbol for a data store is a flat
rectangle that is open on the right side and close on the left side. The name of the data store appears between the lines and identifies the data it contains. A data store name is a plural name consisting of a noun and adjectives, if needed. Examples of a data store names are STUDENTS, ACCOUNTS RECEIVABLE, PRODUCTS, DAILY PAYMENTS, PURCHASE ORDER, OUTSTANDING CHECKS, INSURANCE POLICIES, and EMPLOYEES. Exceptions to the plural name rule are collective nouns that represent multiple occurrence of object. For example, GRADEBOOK represents a group of students and their scores.
EXTERNAL ENTITY SYMBOL
An external entity is a person, department, outside organization, or other information that provides data to the system or receives output from the system. The symbol for an entity is a rectangle, which usually is shaded to make it look three-dimensional. The name of the external entity appears inside the square. External entities show the boundaries of the information system and how the information system interacts with the outside world. For
example, a customer submitting an order is an external entity because the customer supplies data to the order system. Other examples of external entities include a patient who supplies medical data, a homeowner who receives a property tax bill, a warehouse that supplies a list of items in stock, and an accounts payable system that receives data from the company’s purchasing system. External entities also are called terminators, because they are data origins or final destinations. Systems analysts call an external entity that supplies data to the system a source, and an external entity that receives data from the system a sink. An external entity name is the singular form of a department, outside organization, other information system, or person. Examples of external entity names are CUSTOMER, STUDENT, EMPLOYEE, MEMBER, SALES REP, WAREHOUSE, INTERNAL REVENUE SERVICE, PAYROLL SYSTEM, and GENERAL LEDGER SYSTEM.
Context Diagrams
During requirements modeling, you used interviews, questionnaires, and other techniques to gather facts about the system, and you learned how the various people, departments, data, and process fit together to support business operations. Now you are ready to create a graphical model of the information system based on your fact-finding results. To learn how to construct DFDs, you will use examples of these information systems. The simplest example is grading system that instructors use to assign final grades based on the scores the students receive during the term. The second example is an order system that a company uses to enter orders and apply payments against a customer’s balance. The third example is a manufacturing system that handles a company’s production. The first step in constructing a set of DFDS is to draw a context diagram. A context diagram is a top-level view of an information system that shoes the system’s boundaries and scope. To draw a context diagram, you start by placing a single process symbol In the center of the page. The symbol represents the entire around the perimeter of the page and use data flows to connect the entities to the central process. You do not show any data stores in a context diagram because data scores are internal to the system. How do you know what external entities and data flows to place in the context diagram? You begin by reviewing the system requirements to identify all external data sources and destinations. During that process, you record the name of the external entities, the name and content of the data flows, and the direction of the data flow. If you do that carefully, and you did a good job of fact-finding in the previous stage, you should have no difficulty drawing the context diagram.
DATA DICTIONARY
A set of DFDs produces a logical model of the system, but the details within those DFDs are documented separately in a data dictionary, which is the second component of structure analysis. A data dictionary, or data repository, is a central storehouse of information about the system’s data. An analyst uses the data dictionary to collect, document, and organize specific facts about the system, including the contents of the data flow, data stores, external entities, and processes. The data dictionary also defines and describes all data elements and meaningful combinations of data elements. A data element, or data item or field, is the smallest piece of data that has meaning within an information system. Examples of the data element are student grade, salary, Social Security number, account balance, and company name. Data elements are combined into records or data flow or retained in a data store. For example, an auto parts store inventory record might include part number, description, supplier code, minimum and maximum stock levels, cost, and list price.
Dictionary’s content Data:
1. Data Current name
Since DD is made bases data current that is adrift at DFD, therefore name of data current shall also be noted at DD, so they what do read DFD and requires more explanation about a given data current at DFD can direct look for it is squashy at DD.
2. Alias
Alias or alias of data gets to be set down if this alias available. Alias needs to be written since same data to have named that variably to person or department one by another.
3. Data Form
Was known that data current can be adrift:
• Of external entity goes to a process, data that is adrift it usually being noted at a document or form;
• Result of a process goes to external entity, data that is adrift it usually exists on write-up media or query is screen look or printed result document computer;
• Result a process goes to process the other, data that is adrift it usually deep shaped variable or needed parameter by its receiver process;
• Result a process that recorded goes to data trove, data that is adrift it usually as a field.
Shaped thus of data that is adrift get as:
• Base document or form
• Printed yielding document computer
• Published reporting
• Variable
• Parameter
• Field
4. Data current
Data current points out where data is adrift and where data will wend. This current information needs to be noted at DD so makes easy to look for current data at DFD.
5. Explanation
For over clarifies again about meaning of noted data current at DD, therefore explanation part can be filled by information about that data current.
BALANCING IN DFD
Data flow that turns in at an issue of one process has to equal data flow that turns in at an issue of details of process on level / level under it. Therefore data flow name that turns in at an issue of one process have with by the name of data flow that turns in at an issue of details of that process and entity’s amount and name external of a process has to equal total and entity’s name external of details of that process.
Things that shall be noticed on DFD who has more than one level:
• Shall available input balance and output among one level and next level
• Balance among level 0 and level 1 is seen on input / output of data flow goes to or of terminal on level 0, meanwhile balance among level 1 and level 2 are seen on input / output of data flow goes to / of process that pertinent
• Data streaming name, storage’s data and terminal on every level shall same if its object with
PROHIBITION IN DFD
Severally prohibition in DFD is as follows:
• Data current may not from external entity directing to wend entity another external without via a process
• Data current may not of direct data trove make towards external entity without via a process
• Data current may not of direct data trove wend another data trove without via a process
• Data current of one process directing to wend another process without via an advisable data trove / one can maybe be avoided
Langganan:
Postingan (Atom)