Data Flow Diagrams (DFDs) for a Retail Clothing Store

Part 1: Why Systems Analysts Use DFDs (4 marks)

A Data Flow Diagram (DFD) is a graphical tool that depicts the flow of data through a system, showing how data is input, processed, stored, and output. Systems analysts use DFDs for the following reasons:

1. Visual Communication

DFDs provide a clear, graphical representation of a system that can be easily understood by both technical developers and non-technical stakeholders (managers, clients). They bridge the communication gap between users and developers.

2. System Understanding and Documentation

DFDs help analysts understand how an existing system works by mapping all data flows, processes, data stores, and external entities. They serve as formal documentation of the system.

3. Logical System Modeling

DFDs focus on what the system does (logical view) rather than how it is implemented (physical view). This helps analysts design systems independent of technology constraints.

4. Identifying System Boundaries

Through the context diagram (Level 0), analysts can clearly define the scope of the system, identifying what is inside and outside the system boundary.

5. Decomposition and Complexity Management

DFDs support leveled decomposition (Level 0, Level 1, Level 2...), allowing analysts to break a complex system into manageable sub-processes without losing the overall picture.

6. Error and Inconsistency Detection

By tracing data flows, analysts can identify missing data, redundant processes, or logical errors early in the development lifecycle, reducing costly corrections later.

7. Basis for Further Design

DFDs serve as input for designing databases (data stores become tables), programs (processes become modules), and system interfaces.

Part 2: DFD Symbols Used

Part 3: Assumptions Made

Since no specific details were provided, the following assumptions are made:

1. The store sells clothes to walk-in customers.
2. Customers can browse, select, and purchase items.
3. The store maintains an inventory of clothes.
4. The store generates bills/receipts for customers.
5. The store places orders to suppliers when stock is low.
6. A manager oversees sales reports.
7. Payment is made by cash or card.

Part 4: Context Diagram (Level 0 DFD)

The context diagram shows the entire retail clothing store system as a single process with all external entities.

                    Item Inquiry / Purchase Request
                 ┌─────────────────────────────────────►
                 │                                      │
   CUSTOMER ─────┤                                      │
                 │◄─────────────────────────────────────┤
                 │    Receipt / Bill / Selected Items    │
                 │                                      │
                 │                              ┌───────────────────┐
                 │   Stock Order Request        │                   │
   SUPPLIER ─────┼─────────────────────────────►  RETAIL CLOTHING  │
                 │◄─────────────────────────────┤   STORE SYSTEM    │
                 │   Stock / Inventory Delivery  │   (Process 0)    │
                 │                              │                   │
                 │   Sales Report / Summary      └───────────────────┘
   MANAGER  ─────┼◄──────────────────────────────────────┤
                 │   Management Queries / Requests        │
                 └────────────────────────────────────────►

Cleaner Representation:

┌──────────┐   Purchase Request / Item Query    ┌─────────────────────┐
│          ├───────────────────────────────────►│                     │
│ CUSTOMER │                                    │   RETAIL CLOTHING   │
│          │◄───────────────────────────────────┤   STORE SYSTEM      │
└──────────┘   Receipt / Bill                   │     (Process 0)     │
                                                │                     │
┌──────────┐   Stock Delivery                   │                     │
│          ├───────────────────────────────────►│                     │
│ SUPPLIER │                                    │                     │
│          │◄───────────────────────────────────┤                     │
└──────────┘   Purchase Order / Reorder Request │                     │
                                                │                     │
┌──────────┐   Management Queries               │                     │
│          ├───────────────────────────────────►│                     │
│ MANAGER  │                                    │                     │
│          │◄───────────────────────────────────┤                     │
└──────────┘   Sales Reports / Stock Summary    └─────────────────────┘

Part 5: Level 1 DFD

The Level 1 DFD explodes Process 0 into its major sub-processes.

Major Processes Identified:

Data Stores Identified:

Level 1 DFD Diagram:

                      Item Query / Order
   +----------+  ------------------------>  +---------------------+
   | CUSTOMER |                             |         1.0         |
   +----------+  <------------------------  |  Manage Customer    |
        |            Bill / Receipt         |       Sales         |
        |                                   +----+-----------+----+
        | Payment                                |           |
        |                   Customer Details     |           | Sale Details
        v                                        v           v
   +---------------------+              +--------------+  +--------------+
   |         4.0         |              | D1 Customer  |  | D3 Sales     |
   |   Process Payment   |              |   Records    |  |   Records    |
   +----------+----------+              +--------------+  +------+-------+
              | Payment Record                                   | Sales Data
              v                                                  v
     +--------------+                                +---------------------+
     | D4 Order     |                                |         3.0         |
     |   Records    |                                |  Generate Reports   |
     +--------------+                                +----------+----------+
                                                                | Sales and
   +----------+   Purchase Order   +---------------------+      | Stock Report
   | SUPPLIER | <----------------- |         2.0         |      v
   +----------+ -----------------> |  Manage Inventory   |  +-----------+
                   Stock Supply    +----------+----------+  |  MANAGER  |
                                              | Stock       +-----------+
                                              | Update
                                              v
                                     +--------------+
                                     | D2 Inventory |
                                     |   Records    |
                                     +--------------+

Balancing check: the flows crossing the boundary of this diagram (Item Query, Order, Payment, Bill, Stock Supply, Purchase Order, Sales Report, Management Queries) are exactly the flows shown on the context diagram, which is the consistency rule every level of a DFD must satisfy.

Conclusion

Systems analysts use DFDs because a diagram of processes, flows, stores and boundaries is understood by the client as well as the developer, it captures what the system does without committing to how it will be built, and it can be decomposed level by level so that complexity is revealed gradually. For the retail clothing store the context diagram states the boundary and the three external entities, and the Level 1 diagram opens Process 0 into customer sales, inventory, reporting and payment, each writing to its own data store while every external flow stays identical to the level above it.

Conceptual Data Model and Logical Database Design

Conceptual Data Model (2 marks)

A conceptual data model is a high-level, abstract representation of the data requirements of an organization, independent of any specific database management system (DBMS) or physical implementation details.

It describes what data is stored, the relationships among data, and the constraints on data, without concerning itself with how the data will be physically stored or accessed.

Key characteristics:

• Technology and DBMS independent
• Focuses on entities, attributes, and relationships
• Expressed using tools like Entity-Relationship (ER) diagrams
• Understandable by both technical and non-technical stakeholders

Example: An ER diagram showing Student, Course, and Enrollment entities with their relationships is a conceptual data model.

Logical Database Design (3 marks)

Logical database design is the process of translating the conceptual data model into a logical structure that can be implemented in a specific type of DBMS (such as a relational DBMS), but still independent of the physical storage details.

Steps in Logical Database Design:

1. Mapping Entities to Tables (Relations)

   • Each entity in the ER diagram is converted into a relation (table).
   • Attributes of the entity become columns of the table.

2. Defining Primary Keys

   • A unique identifier (primary key) is assigned to each table to uniquely identify each record.

3. Handling Relationships

   • One-to-Many: The primary key of the "one" side is placed as a foreign key in the "many" side table.
   • Many-to-Many: A new junction/associative table is created with foreign keys from both related tables.
   • One-to-One: Foreign key is placed in either of the two tables.

4. Normalization

   • The logical schema is refined by applying normalization (1NF, 2NF, 3NF, etc.) to eliminate data redundancy and update anomalies.

5. Defining Integrity Constraints

   • Entity integrity, referential integrity, and domain constraints are defined.

Output of Logical Design:

A set of relation schemas with defined attributes, primary keys, and foreign keys, ready to be implemented in a relational DBMS.

Example:

Student (StudentID, Name, Address)
Course  (CourseID, CourseName, Credits)
Enrollment (StudentID, CourseID, Grade)

Note: Logical design bridges the gap between the abstract conceptual model and the physical implementation, ensuring data is organized efficiently and consistently.