Balancing DFDs and DFDs for Online Movie Rental System

Part 1: Balancing DFDs

Balancing DFDs refers to the consistency that must be maintained between a parent DFD and its child DFD (exploded diagram) when decomposing a process into more detail.

Key Rules for Balancing:

• Every data flow entering or leaving a process on a higher-level DFD must also appear on the corresponding lower-level (child) DFD for that process.
• The inputs and outputs of a parent process must exactly match the inputs and outputs of the child diagram that decomposes it.
• No new external entities should appear in a child DFD that were not present or implied in the parent.
• Data stores that are used only within a child diagram (internal data stores) do not need to appear in the parent diagram, but any data store shared across processes must be consistent.

In short: what goes in and what comes out of a process must be the same at every level of decomposition.

Part 2: Context Diagram and DFDs for Online Movie Rental System

System Description

The Online Movie Rental System allows users to:

• Register and log in
• Browse and search movies
• Rent/stream movies online
• Make payments
• Receive recommendations
• Administrators manage movie catalog and generate reports

Level 0: Context Diagram

The context diagram shows the entire system as a single process with all external entities and major data flows.

                        Registration/Login Info
                   ┌─────────────────────────────────┐
                   │                                 ▼
           ┌───────┴──────┐              ┌───────────────────────┐
           │              │  Movie Search │                       │
           │    USER /    │─────────────►│                       │
           │   CUSTOMER   │◄─────────────│   ONLINE MOVIE        │
           │              │  Movie Stream │   RENTAL SYSTEM       │
           │              │◄─────────────│     (Process 0)       │
           │              │  Payment Info │                       │
           │              │─────────────►│                       │
           └──────────────┘              │                       │
                                         │                       │
           ┌──────────────┐              │                       │
           │              │ Movie Details│                       │
           │   ADMIN /    │─────────────►│                       │
           │  MANAGEMENT  │◄─────────────│                       │
           │              │  Reports     │                       │
           └──────────────┘              │                       │
                                         │                       │
           ┌──────────────┐              │                       │
           │   PAYMENT    │◄─────────────│                       │
           │   GATEWAY    │─────────────►│                       │
           └──────────────┘  Payment     └───────────────────────┘
                             Confirmation

External Entities:

Level 1: DFD (Decomposition of Process 0)

This diagram breaks the main system into major sub-processes.

USER
 │
 │ Registration Info
 ▼
┌──────────────────┐        ┌─────────────────┐
│  Process 1.0     │        │                 │
│  User            │───────►│  D1: USER DB    │
│  Registration    │        │                 │
│  & Login         │◄───────│                 │
└──────────────────┘        └─────────────────┘
        │
        │ Verified User
        ▼
┌──────────────────┐        ┌─────────────────┐
│  Process 2.0     │        │                 │
│  Browse &        │───────►│  D2: MOVIE DB   │
│  Search Movies   │◄───────│                 │
└──────────────────┘        └─────────────────┘
        │
        │ Selected Movie
        ▼
┌──────────────────┐        ┌─────────────────┐
│  Process 3.0     │        │                 │
│  Rental &        │───────►│  D3: RENTAL DB  │
│  Streaming       │◄───────│                 │
└──────────────────┘        └─────────────────┘
        │
        │ Rental/Payment Request
        ▼
┌──────────────────┐        ┌─────────────────┐
│  Process 4.0     │        │                 │
│  Payment         │───────►│ PAYMENT GATEWAY │
│  Processing      │◄───────│                 │
└──────────────────┘        └─────────────────┘
        │
        │ Payment Confirmation
        ▼
┌──────────────────┐        ┌─────────────────┐
│  Process 5.0     │        │                 │
│  Report          │───────►│  ADMIN /        │
│  Generation      │        │  MANAGEMENT     │
└──────────────────┘        └─────────────────┘
        ▲
        │ Data from D1, D2, D3

Level 2: DFD for Process 3.0 - Rental and Streaming (Exploded)

This shows balancing: inputs/outputs of Process 3.0 match those in Level 1.

                    Selected Movie (from Process 2.0)
                              │
                              ▼
                   ┌─────────────────────┐
                   │  Process 3.1        │
                   │  Check Movie        │◄──── D2: MOVIE DB
                   │  Availability       │
                   └──────────┬──────────┘
                              │ Available Movie
                              ▼
                   ┌─────────────────────┐
                   │  Process 3.2        │
                   │  Create Rental      │───────► D3: RENTAL DB
                   │  Record             │◄─────── D3: RENTAL DB
                   └──────────┬──────────┘
                              │ Rental Confirmed
                              ▼
                   ┌─────────────────────┐
                   │  Process 3.3        │
                   │  Stream Movie       │───────► USER (Movie Stream)
                   │  to User            │
                   └──────────┬──────────┘
                              │ Rental/Payment Request
                              ▼
                 (passed on to Process 4.0: Payment Processing)

Balancing Check

The Level 2 diagram takes exactly one input, Selected Movie from Process 2.0, and produces exactly one output, Rental/Payment Request to Process 4.0, which are the same input and output shown for Process 3.0 in the Level 1 diagram. The internal sub-processes (3.1, 3.2, 3.3) and the internal use of D3: RENTAL DB are visible only inside this exploded diagram, which is consistent with the balancing rule that a child DFD's external inputs and outputs must match its parent process exactly, while its internal detail need not appear at the parent level.

Physical Database Design

Definition

Physical database design is the process of transforming a logical database model into a physical implementation on a specific hardware and software platform. It involves decisions about how data will be physically stored, accessed, and managed in secondary storage (disks). In physical design, the logical specifications of the system are transformed into technology-specific details.

The main purpose of database design (both logical and physical) is to produce logical and physical designs of the proposed database system to meet the requirements of users and for high performance.

Key Activities in Physical Database Design

1. Designing Fields

• A field is the smallest unit of application data recognized by system software such as a programming language or a DBMS.
• An attribute from a logical database model may be represented by several fields.
• A field that can be derived from other database fields is called a calculated field.
• Some database technologies allow explicit definition of calculated fields; the system either stores the calculated value or computes it when requested.

2. Designing Physical Tables

A physical table is a named set of rows and columns that specifies fields in each row. The design of a physical table has two goals:

3. Designing Forms and Reports

• Forms are used to collect or present information on a single item (customer, product, event); used for both input and output.
• Reports are the product of input and output design and are purely used for reading.
• Forms provide fields for data input; reports do not.

4. Additional Physical Design Decisions (standard CS supplement)

• Choosing file organization (sequential, indexed, hashed)
• Defining indexes to speed up query processing
• Selecting storage structures and access paths
• Partitioning and clustering of data
• Allocating disk space and buffer management

Why is Physical Database Design Important?

Physical database design is important for the following reasons:

1. High Performance: Proper physical design minimizes I/O operations by storing related data close together in secondary memory, resulting in faster data retrieval and processing.

2. Efficient Storage Utilization: It ensures efficient use of secondary storage (disk space), avoiding wastage and reducing storage costs.

3. Meeting User Requirements: The main purpose of database design is to produce a system that meets the requirements of users; physical design is the stage where this is actually implemented on real hardware.

4. Technology-Specific Optimization: Logical design is platform-independent, but physical design transforms those specifications into technology-specific details suited to the actual DBMS and hardware being used.

5. Scalability and Reliability: Good physical design ensures the database can handle growing data volumes and remains reliable under heavy load.

6. Support for Application Interfaces: Physical design supports the design of forms and reports that users interact with, making the system usable and responsive.

Differentiation: Logical Database Design vs. Physical Database Design

Summary

In short, logical database design answers "What data should be stored and how are they related?" while physical database design answers "How and where will the data actually be stored on the hardware?" Both are essential phases in the database design process, and physical design is critical because it directly determines the performance, efficiency, and usability of the final database system.

Feasibility Study: Definition and Types

Definition of Feasibility Study

A feasibility study is an analysis that considers all of a project's relevant factors -- including economic, technical, legal, and scheduling considerations -- to ascertain the likelihood of completing the project successfully. Whether a project is feasible or not can depend on several factors, including the project's cost and return on investment.

The primary purpose of a feasibility study is to reduce the number of business options and determine whether a proposed project should be pursued, redirected, or abandoned.

Types of Feasibility (Economic and Schedule)

1. Economic Feasibility (Cost-Benefit Analysis)

Economic feasibility is the analysis of a system to determine whether the expected benefits equal or exceed the expected costs.

Key points:

• The main purpose is to identify the financial benefits and costs associated with the development project.
• During project initiation and planning, it may be impossible to define precisely all benefits and costs related to a particular project.
• Worksheets are used to record costs and benefits, and these worksheets are reviewed after each SDLC phase to decide whether to:
  • Continue the project
  • Redirect the project
  • Kill the project

Example considerations:

2. Schedule Feasibility

Schedule feasibility determines whether the project can be completed within the given time frame and deadlines set by the organization.

Key points:

• It evaluates whether the project timeline is realistic and achievable given the available resources.
• It considers the project size, complexity, and team capacity when estimating time requirements.
• If a project cannot be delivered on time, it may lose its business value even if technically and economically sound.
• Schedule feasibility is closely linked to project planning, where the project manager creates a blueprint mapping out estimated time and execution plan.

Factors affecting schedule feasibility:

• Size and complexity of the project
• Availability of skilled personnel
• Dependencies between project tasks
• Risk factors that may cause delays

Summary

Both economic and schedule feasibility are critical during the initiation phase of a project to ensure resources are wisely invested and deadlines are realistically met.

Traditional Methods for Determining System Requirements & Observation Method

Traditional Methods for Determining System Requirements

The traditional methods used by system analysts to determine system requirements are:

1. Interviewing - Conducting structured or unstructured interviews with users, managers, and stakeholders to gather information about the current system and requirements.

2. Observing Workers - Directly watching employees perform their day-to-day tasks to understand how the current system is actually used in practice.

3. Analyzing Procedures and Documents - Examining existing organizational documents, manuals, reports, forms, and records to find details about the current system, its problems, and the reasons why current systems are designed the way they are.

4. Questionnaires/Surveys - Distributing written sets of questions to a large number of users to collect information efficiently.

5. Joint Application Development (JAD) - Bringing together users, managers, and analysts in structured group sessions to define system requirements collectively.

Observing Workers to Determine System Requirements

Observation involves the system analyst directly watching workers perform their tasks in their actual work environment to understand how the current system operates.

Advantages of Observing Workers

1. First-hand, Accurate Information

   • The analyst sees exactly how tasks are performed in reality, not just how users think or say they perform them. This reduces misunderstandings and inaccuracies.

2. Reveals Undocumented Processes

   • Workers often follow informal procedures or shortcuts that are never written down. Observation uncovers these hidden steps that interviews or documents might miss.

3. Validates Other Information

   • Observation can confirm or contradict information gathered through interviews and questionnaires, helping the analyst cross-check data.

4. Understanding the Work Environment

   • The analyst gains insight into the physical and organizational context, such as workload, interruptions, and communication patterns, which helps in designing a more practical system.

5. No Reliance on Memory

   • Unlike interviews where users must recall how they work, observation captures real-time behavior, making the data more reliable.

Pitfalls of Observing Workers

1. Hawthorne Effect (Change in Behavior)

   • Workers may change or improve their behavior when they know they are being watched. This means the analyst may not see the true, everyday way tasks are performed, leading to inaccurate requirements.

2. Time Consuming

   • Observation requires the analyst to spend significant time at the workplace, making it an expensive and slow method, especially for complex or lengthy processes.

3. Incomplete Picture

   • Not all tasks occur frequently or during the observation period. Rare but important processes may be missed entirely.

4. Disruption to Work

   • The presence of an observer can distract workers and slow down normal operations, causing inconvenience to the organization.

5. Analyst Bias

   • The analyst may misinterpret what they observe or focus on certain activities while overlooking others, leading to a biased understanding of requirements.

6. Limited to Observable Tasks

   • Mental or decision-making processes that workers perform internally (such as judgment calls or reasoning) cannot be captured through observation alone.

Conclusion

, "both interviewing and observing have some sort of limitations", which is why observation is best used in combination with other methods such as document analysis and interviewing to get a complete and accurate picture of system requirements.