Entity Relationship Structures

ENTITY RELATIONSHIP STRUCTURES

Figure drawn below contains the entity set PERSONS, which is associated with two relationship sets. One relationship set is WORK ON with projects. This relationship set shows that persons work on projects. The other relationship set, ARE IN, shows that persons are in departments. Entity set PARTS is associated with three relationship sets: USE with PROJECTS to show that projects use parts, SUPPLY with SUPPLIERS to show that suppliers supply parts, and HOLD with WAREHOUSES to show that parts are held in warehouses.

Data Modeling

DATA MODELING

Data modeling is part of the development process. In the linear development cycle, it is used during the system requirements phase to construct the data components of the analysis model. The model represents the major data objects and the relationships between them.

Data modeling is a technique for organizing and documenting a system’s data. Data modeling is sometimes called database modeling because a data model is eventually implemented as a database.

There are several notations for data modeling. The actual model is frequently called an entity relationship diagram (ERD) because it depicts data in terms of the entities and relationships described by the data.

An entity relationship diagram is defined as a data model utilizing several notations to depict data in terms of the entities and relationships described by that data.

The entity relationship (E-R) data model was developed to facilitate database design by allowing specification of an enterprise schema that represents the overall logical structure of a database. It is data oriented model of .a system. It has three Main components-data entities, their relationships and their associated attributes.

Entity : An entity is something about which the business needs to store data. It is most elementary thing of an organization about which data is to be maintained. Every entity has unique identity, which distinguishes it from another entity. An entity type is the description of all entities to which a common definition and common relationships and attributes apply. It is represented by rectangular box with the name of entity written inside.

For example: the data that describes a particular student might include name, address, phone number, date of birth etc.

Entity Types

Relationship : A relationship is a natural business association that exists between one or more entities. The relationship may represent an event that links the entities or merely a logical affinity that exists between the entities. Entities are connected to each other by relationships. It indicates how two entities are associated. A diamond notation with name of relationship represents as written inside.

Relationship Entity

Degree : The degree of a relationship is the number of entities that participate in the relationship. The most common relationships in 8-R diagram are unary, i.e., degree one, binary, i.e., degree 2 and ternary, i.e., degree 3.

Cardinality : Cardinality defines the minimum and maximum number of occurrences of one entity that may be related. to a single occurrence of the other entity. Because all relationships are bi-directional, cardinality must be defined in both directions for every relationship.

A popular graphical notation for cardinality is shown in figure below :

Cardinality

Cardinality 2

Attribute : Each entity type has a set of attributes associated with it. An attribute is a property or characteristic of an entity that is of interest to the organization. It is represented by oval shaped box with name of attribute written inside it.

Attribute

Types of Attribute

  • Simple attribute : There is no need to sub-divide it into component attributes. For example, if there is no need to refer to the individual component of an address (Zip, street and so on), then the whole address is designated as a simple attribute.
  • Composite Attribute : On the other hand, it can be divided into subparts. For example, an attribute•name can be structured as a composite attribute consisting of first_name, middle_name, and last name.
  • Single valued Attribute : Single valued attribute have a single value for a particular entity. For instance, the loan_number attribute for a specific loan entity refers to only one loan number. Such attributes are said to be single valued.
  • Multivalued Attribute : There may be instances. where an attribute has a set of values for a specific entity. Consider an employee entity set with the attribute. phone-number. An employee may have zero; one or several phone numbers, and different employees may have different numbers of phones. This type of attribute is said to be multivalued.
  • Derived Attribute : The value for this type of attribute can be derived from the values of other related attributes or entities. For example, the customer entity set has an attribute loan held, which represents how many loans a customer has taken from the bank. We can derive the value for this attribute by counting the number of loan entities associated with that customer.

Decision Table

DECISION TABLE

Sometimes, it is convenient to describe a system as a set of possible conditions satisfied by the system at a given time, rules for reacting to stimuli when certain sets of those conditions are met, and actions to be taken as a result.

Decision tables provide a mechanism for recording complex decision logic. Decision tables are widely used in data processing applications and have an extensively developed literature. As illustrated in Table a decision table is segmented into four quadrants : condition stub, condition entry, action stub, and action entry.

Basic Elements of a Decision Table

The condition stub contains all of the conditions being examined. Condition entries are used to combine conditions into decision rules. The action stub describes the actions to be taken in response to decision rules, and the action entry quadrant relates decision rules to actions.

Limited-Entry Decision Table

Table illustrates the format of limited-entry decision table (entries are limited to Y, N,

, and X). In a limited-entry decision table, Y denoted “yes”, N denotes “no” denotes “don’t care,” and X denoted “perform action.” According to Table, orders are approved if the credit limit is not exceeded, or if the credit limit is exceeded but past experience is good, or if a special arrangement has been made. If none of these conditions hold, the order is rejected.

The (Y, N, –) entries in each column of the condition entry quadrant from a decision rule. If more than one decision rules has identical (Y, N, –) entries, the table is said to be ambiguous. Ambiguous pairs of decision rules that specify identical actions are said to be redundant, and those specifying different actions are contradictory. Contradictory rules permit specification of non deterministic and concurrent actions. Table illustrates redundant rules (R3 and R4) and contradictory rules (R2 and R3, and R2 and R4).

An Ambiguous Decision Table

An Ambiguous Decision Table 2

Advantages of Decision Table

The various advantages of decision table are depicted as follows :

(I) Consistency in decisions making

  • Decision rules are clearly structured
  • Documentation is easily prepared, changed or updated
  • Managers can be relieved from decision-making
  • Easy to use
  • Facilitate more compact documentation
  • Communication is easier between manager and analysis
  • Easier to follow a particular path down one column than through complex and lengthy flowcharts.
  • Easier to draw or modify in comparison to flowcharts.

Disadvantages of Decision Table

The various disadvantages of decision table are as follows :

  • Does not depict the flow
  • Cannot list all the alternatives
  • Not easy to translate it
  • Impose an additional burden

Data Flow Diagrams

DATA FLOW DIAGRAMS

The Data Flow Diagrams (DFD) is also known as a Data Flow Graph or a Bubble Chart. A DFD serves the purpose of clarifying system requirements and identifying major transformations. DFDs show the flow of data through a system. It is a important modelling tool that allows us to picture a system as a network of functional processes.

Data flow diagrams (DFDs) are a well-known and widely used notation for specifying the functions of an information system. They describe systems as collections of data that are manipulated by functions. Data can be organized in several ways : they can be stored in data repositories, they can flow in data flows, and they can be transferred to or from the external environment.

One of the reasons for the success of DFD is that they can be expressed by means of an attractive graphical notation that makes them easy to use.

Symbols Used for Constructing DFDs

There are different types of symbols used to construct DFDs. The meaning of each symbol is explained below :

Process : A process is represented using a circle. This symbol is called a process or a bubble or performs some processing of input data.

External entity : A square defines a source of destination of system data. External entities represent any entity that supplies or receives information from the system but is not a part of the system.

External entity

Data flow symbol : A directed arc or arrow is used as a data flow symbol. A data flow symbol represents the data flow occurring between two processes or between an external entity and a process in the direction of the data flow arrow.

Data flow symbolData store symbol : A data store symbol is represented using two parallel lines. A logical file can represent either a data store symbol, which can represent either a data structure, or a physical file on disk. Each data store is connected to a process by means of a data flow symbol. The direction of the data flow arrow shows whether data is being read from or written into a data store.

Data store symbolOutput Symbol : It is used to represent data acquisition and production during human computer-interaction.

Output Symbol

Example of DFD

Example figure shows how the symbols can be composed to form a DFD. The DFD describes the arithmetic expression.

(a + b)* (c + a* d)

Assuming that the. data a, b, c and are read from a terminal and the result in printed. The figure shows that arrow can be “forked” to represent the fact that the same datum is used in different places.

A DFD For Specifying the Arithmetic Expression

Example. Fig. describes a simplified information system for a public library. The data and functions shown are not necessarily computer data and computer function. The DFD describes physical objects, such as books and shelves, together with data stored that are likely to be, but are not necessarily, realized as computer files. Getting a book from the shelf can be done either automatically-by a robot-or manually. In both cases, the action of getting a book is represented by a function depicted by a bubble. The figure could even represent the organization of library with no computerized procedures.

A DFD Describing a Simplified Library Information System

Fig. A DFD Describing a Simplified Library Information System

Figure also describes the fact that, in order to obtain a book, the following are necessary: an explicit user request consisting of the title and the name of the author of the book and the user’s name; access to,the shelves that contain the books; a list of authors; and a list of titles. These provide the information necessary to find the book.

Levels of DFD

There are different levels of data flow diagram. The initial level is called context level or fundamental system model or a 0 level DFD. If two break or expand the 0 levels processes then we get the 1st level DFD and if we further expand the 1st level processes then we get the 2nd level DFD and so on.

Example : The 0th and lth levels of DFD of Production Management System are shown in figure (a) and (b).

Let us discuss the data flow diagram of Production Management system.

Level 0 DFD of PMS

Level 1 DFD of PMS

A formal DFD or Bubble Chart

Data flow diagrams can be expressed using informal notation, as illustrated in Fig. (a), or special symbols can be used to denote processing nodes, data sources, data sinks, and data stores, as illustrated in Figure (b).

A formal DFD or Bubble Chart 2

General Guidelines and Rules for Constructing DFDs

The following guidelines will help avoid constructing DFDs that are quite simply wrong or incomplete.

  • Remember that a DFD is not a flow chart.
  • All names should be unique.
  • Processes are always running, they do not start or stop.
  • All data flows are named.
  • Keep a note of all the processes and external entities. Give unique names to them. identify the manner in which they interact with each other.
  • Do numbering of processes.
  • Avoid complex DFDs (if possible)
  • The DFD should be internally consistent.
  • Every process should have minimum of one input and one output.
  • Only data needed to perform the process should be an input to the process.
  • The “direction of flow is from source to destination.

Process Modeling

PROCESS MODELING

Process modeling was founded in the structured analysis and design methodologies in 1978. Process modeling focuses on the Process part of a system. Flowcharts are one type of process model. Data flow Diagrams and structure charts have contributed significantly to reduce the communication gap that often exists between non-technical system designers and builders.

A model is a representation of reality that can be built for existing systems as a way to better understand those systems or for proposed systems as a way to document business requirement or technical designs.

Logical models show what a system is or does. They are implementation-independent; that is, they depict the system independent of any technical implementation.

Physical models show not only what a system is or does but also how the system is physically and technically implemented. They are implementation-dependent because they reflect technology choices and the limitation of those technology choices.

System analysis activities tend to focus on the logical system models for the following reasons :

  • Logical models remove biases that are the result of the way the current system is
  • Logical models reduce the risk of missing business requirement because of preoccupied technical details. Such errors can be costly to correct after the system is implemented. By separating what the system must do from how the system will do it, we can better analyze the requirements for completeness, accuracy and consistency.
  • Logical models allow us to communicate with end users in non-technical or less technical languages. Thus, we don’t lose requirements in the technical jargon of the computing discipline.

Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s process, policies, and procedures to be implemented by a system’s processes.

A data flow diagram (DFD) is a tool that depicts the flow of data through a system and the work or processing performed by that systeni. Data flow diagrams are also called bubble charts, transformation graph, and process model.

Diagrammatic representation of data helps in two ways:

  1. It helps the analysts to analyze the system and to model system components.
  2. An analyst can communicate better with the user. It is easier for the user to understand and how the analyst has interpreted his/her problem after looking at DFD’s.

Components of DFD

Just like flowcharts, Data flow diagram use standard symbols to represent different components. Following are the components of data flow diagrams :

  1. Process
  2. Data flow
  3. Data stores
  4. External Entities.

Processes

Processes show what systems do. Each process has one or more data inputs and produces one or more data outputs. In order to obtain the relevant information from data, it has to be processed. Data may be represented in a single step or process or by a number of processes. Circles in a DFD represent processes. Each process has a unique name and number which appear inside the circle that represent the process.

External Entities

External entities are outside the system, but they either supply input data into the system or use the system output. They are entities over which the designer has no control. They may be an organization’s customer or other bodies with which the system interacts.

External entities that supply data into the system are sometimes called sources. External entities that use system data are sometimes called sinks.

Data Stores

A file or data store is a repository of data. It contains data that is retained in the system.

Data is always stored on some physical medium. In case of manual systems, data is stored in paper file. In automated system, data is stored on mediums like hard disk, floppy disk or magnetic tapes etc. Process can enter data into a data store or retrieve data from the data store. Two parallel lines in the DFD represent each data store and each data store has a unique name.

Data stores form an essential part of the system and hence of DFD.

Data Flows

Data flows model the passage of data in the system and are represented by lines joining system components. The direction of the flow is indicated by an arrow and the line is labelled by the name of the data flow. Flow of data in the system can take place:

  • Between two processes.
  • From a data store to a process.
  • From a process to a data store
  • From a source to a process; and
  • FroM a process to a sink.

If an organization works to improve a business process, it must first understand it. Process modeling tools are used to represent the key elements of a process so that it can be better understood.

Now let us illustrate how systems are modeled using these symbols. A common way to begin is to model the whole system by one process. The DFD that does this is known as the context diagram. It shows all the external entities that interact with the system and the data flows between these external entities and the system.

Data Flows

Figure above is an example of a context diagram. It models the ‘budget monitoring system’. This system interacts with three external entities: DEPARTMENTS, MANAGEMENT and SUPPLIERS. In figure, the main data flows from DEPARTMENTS are ‘spending request’. In response, DEPARTMENTS either receive `rejected request’ data flows or ‘delivery advice’ data flows. MANAGEMENT receives `request for special approval’ data flows to which it responds’. MANAGEMENT also sends ‘budget allocation’ data flows to the system and gets ‘spending summaries’ data flows. Suppliers receive ‘part order’ data flows and return ‘supplier delivery advice’ data flows.

Context diagram does not describe the system in detail. In order to identify the major system processes, a DFD that shows the major system processes is called top-level DFD. The top-level DFD shows the various processes that make up the system. Each process has a unique name and number.

Figure below shows the top-level DFD :

Data Flows Diagram

In this DFD we see that data flow ‘spending request’ from DEPARTMENTS goes to the ‘check funding’ process. This process looks up the allocated budget and determines whether special permission is needed from MANAGEMENT to proceed with the request. Approved request goes to the ‘classify expenditure’ process where they are entered into data stores, DEPARTMENTAL-ACCOUNTS and TYPE-ACCOUNTS. Finally, if required, a ‘part order’ for parts originally specified in a ‘spending request’ is placed with suppliers. There are also two other processes; one is to ‘set up budget’ and the other is to `provide spending summaries’.

Guidelines for Drawing Data Flow Diagram

Data flow diagram can easily become quite complex; therefore, it is often helpful to follow a set of general guidelines. Following rules should be kept in mind for designing a good DFD :

  1. Should have no crossing lines.
  2. Should not split into a number of data flows.
  3. Should have no any flowchart structure like decision, iteration etc.
  4. Do not include control or flow of control information.
  5. Do not try to put too much information in one data flow diagram.
  6. Data flows can only be from:
  • External entity to process
  • Process to external entity
  • Process to process
  • Process to stores
  • Stores to process
  1. Naming conversion should be kept in mind:
  • Name should be meaningful.
  • Process name should be one single phrase and should not be general.
  • Data flows should be named as one word.

Advantages of Using DFD’s

  1. Represent data flows.
  2. May be used at. high or low level of analysis.
  3. Provide good system documentation.