This session turns the SRS of Session 3 into three analysis models of the Railway Reservation System. The Data Flow Diagrams (DFDs) show how data moves between the actors, the eight modules, and the data stores. The Entity Relationship Diagram (ERD) shows what data the system keeps and how the entities relate. The Data Dictionary defines every attribute and every data flow so that two people reading the diagrams mean the same thing. Together they are the functional model and the data model that the manual asks for in the SRS appendices, and they are the input for the modular design in Session 5.
Objectives
×Do not copy. Read for understanding and the viva
Draw a context diagram (level 0) with the RRS as one process and five external entities.
Decompose it into a level 1 DFD whose processes 1.0 to 8.0 are the eight modules.
Decompose Booking (4.0) into a level 2 DFD, balanced with level 1.
Draw the ERD of the twelve RRS entities with cardinality and participation.
Write a data dictionary for every entity and for the main data flows.
Problem Statement
Write in lab record
(a) Draw DFDs up to appropriate levels for the RRS.
(b) Draw ERDs for the RRS. Describe the relationships between different entities.
(c) Design Data Dictionary for RRS.
Concept
×Do not copy. Read for understanding and the viva
DFD symbols and the text notation
A DFD has four symbols: external entity (a rectangle, a source or sink of data outside the system), process (a circle or rounded box, numbered, named with a verb), data store (an open rectangle, named with a noun, labelled D1, D2, and so on), and data flow (an arrow with a name). On this page the text form is: external entities in plain boxes, processes as [n.0 Verb Object], stores as Dn | Name, flows as labelled arrows. Redraw them by hand with the standard symbols.
Levelling and balancing
Level 0 (the context diagram) shows one process, the whole system, and every external entity. Level 1 explodes that one process into the main processes; here one per module, so 1.0 to 8.0. Level 2 explodes one level 1 process into sub-processes 4.1, 4.2, and so on. The rule of balancing: the flows entering and leaving a process at level n must be exactly the flows entering and leaving its explosion at level n+1. If level 1 shows “booking request” going into 4.0, then some 4.x sub-process must receive “booking request”.
DFD rules that examiners check
A data flow never joins two external entities, two data stores, or an entity and a store directly. A process must be in between.
Every process has at least one input and one output.
Names on flows are data, not actions: “booking request”, not “book”.
Stores appear at level 1 and below, never on the context diagram.
ERD notation
An entity is a rectangle; a relationship is a diamond or a labelled line; an attribute is listed under the entity with the primary key underlined (shown here as PK). Cardinality says how many instances of one entity relate to one instance of the other: 1:1, 1:M, or M:N. Participation says whether every instance must take part (total, double line) or may (partial, single line). A M:N relationship is resolved with an associative entity; in the RRS, Route resolves Train to Station.
Data dictionary notation
The dictionary defines attributes (name, type, size, constraints, meaning) and data flows (composition). Flow composition uses = for “is composed of”, + for “and”, (x) for optional, and n..m of x for repetition. Every name in a DFD or ERD must appear in the dictionary once, with one meaning.
passenger list; D2 (distance between stations, rate_per_km)
fare to 4.4
4.4
Allocate Seats or Waitlist
fare and passenger list; D2 (seats of the class); D4 (seats already taken, waitlist count)
allocation to 4.5; D4 (seat hold)
4.5
Generate PNR and Record Booking
allocation; payment result from 6.0; PNR enquiry; D4
payment request to 6.0; ticket (PNR); PNR status; booking event to 7.0; D4
Balance check with level 1: the level 1 process 4.0 receives booking request, passenger details, PNR enquiry, payment result and the stores D1, D2, D3, D4; it produces ticket, PNR status, payment request, booking event and writes D4. Every one of these appears exactly once at the boundary of the level 2 diagram, so the diagrams are balanced.
Entity Relationship Diagram
Write in lab record
+-----------+ 1 places M +-----------------+ M for 1 +-----------+ M run of 1 +-----------+ 1 M+------+ | User |------------------| Booking |-------------------| Schedule |-----------------| Train |---------| Fare | +-----------+ +-----------------+ +-----------+ +-----------+ +------+ 1| 1| 1| 1| 1| priced by paid by |refund | | includes has stops | | has (1:1) |by 1:M | | (1 to 6) | | 1| M| M| M| M| +-----------+ | +-----------+ +-------+ +-------+ | Payment | | | Passenger | | Route | | Coach | +-----------+ | +-----------+ +-------+ +-------+ | | occupies stop at M| 1| contains M| | (0..1) 1| M| +-----------+ | +---------+ +------+ | Refund | | | Station | | Seat | +-----------+ | +---------+ +------+ |M 1 ^ +-------------------------------------------------------------+ Extra lines to draw by hand (Station is a target of two more relationships): Booking (M) ---- from_station ----> (1) Station Booking (M) ---- to_station ------> (1) Station
Primary keys are not repeated on the diagram; underline them by hand from the data dictionary below. Every relationship, including the two Station lines, is listed here:
Relationship
Entities
Cardinality
Participation
Meaning
places
User, Booking
1:M
User partial, Booking total
A user may make many bookings; every booking belongs to exactly one user (the passenger online or the clerk at the counter)
includes
Booking, Passenger
1:M (1 to 6)
Both total
A booking lists 1 to 6 passengers; a passenger record belongs to one booking
for
Booking, Schedule
M:1
Booking total, Schedule partial
Every booking is on one train run; a schedule may have many bookings or none
run of
Schedule, Train
M:1
Schedule total, Train partial
Every schedule is one date of one train; a train may have many schedules
has stops
Train, Route, Station
M:N resolved by Route
Train total, Station partial
Route is the associative entity: one row per (train, station) with sequence, times, distance
has
Train, Coach
1:M
Both total
A train has one or more coaches; a coach belongs to one train
contains
Coach, Seat
1:M
Both total
A coach has seat_count seats; a seat belongs to one coach
priced by
Train, Fare
1:M
Both total
One fare row per (train, class); a train must have a fare for every class it carries
occupies
Passenger, Seat
M:1, optional on the Passenger side
Passenger partial, Seat partial
A confirmed passenger holds one seat for the booking’s schedule; a waitlisted passenger holds none; a seat is used by many passengers over different schedules but by at most one per schedule
from_station
Booking, Station
M:1
Booking total, Station partial
Boarding station of the booking
to_station
Booking, Station
M:1
Booking total, Station partial
Alighting station of the booking
paid by
Booking, Payment
1:1
Both total once confirmed
Every completed booking has exactly one successful payment
refunded by
Booking, Refund
1:M
Booking partial, Refund total
A booking may produce several refunds (partial cancellations); every refund belongs to one booking
Data Dictionary
Write in lab record
Types: INT (integer), CHAR(n) (fixed length), VARCHAR(n) (variable length up to n), DATE, TIME, DATETIME, DECIMAL(p,s), ENUM (fixed set of values).
Q: What is the difference between a context diagram and a level 1 DFD? A: The context diagram shows the whole system as one process with external entities; level 1 breaks it into major processes and adds data stores.
Q: Why are there no data stores on the context diagram? A: Stores are inside the system; the context diagram shows only the boundary.
Q: What does balancing mean? A: The inputs and outputs of a process at one level equal the net inputs and outputs of its explosion at the next level.
Q: Can a data flow go from Passenger straight to D4 Booking? A: No; a process must transform or record the data. Only processes connect to stores.
Q: Why is Route a separate entity? A: Train to Station is many-to-many and the relationship carries attributes (sequence, times, distance), so it needs an associative entity.
Q: What is the cardinality between Booking and Passenger? A: One to many, limited to 1 to 6, total participation on both sides.
Q: Why is seat_id in Passenger nullable? A: A waitlisted passenger has no seat until promoted.
Q: How does the data dictionary help the coder? A: It fixes the type, size, and constraint of every field before the database and code are written, so the same name means the same thing everywhere.
Q: Where does the PNR get generated in the DFD? A: Process 4.5, after 6.0 returns a successful payment result.
Common Mistakes
×Do not copy. Read for understanding and the viva
Naming processes with nouns (“Booking”) or flows with verbs (“book”). Processes are verb phrases; flows are data.
Drawing a flow between two external entities, or from an entity directly into a data store.
Unbalanced levels: a flow appears in level 2 that never entered or left 4.0 in level 1, or the other way round.
Forgetting cardinality and participation on the ERD, or writing M:N without resolving it.
A data dictionary that lists only entities and not the data flows; the examiner checks that every arrow label has an entry.
Different names for the same thing across the three models, for example “reservation” in the DFD and “booking” in the ERD.
Session Summary
Write in lab record
Problem statement (a), (b), (c) copied verbatim.
Context diagram with five external entities and its element table.
Level 1 DFD with processes 1.0 to 8.0, tables of processes, data stores D1 to D7, and inter-process flows.
Level 2 DFD of 4.0 Book Ticket with 4.1 to 4.5, its process table, and the balance check.
ERD of the twelve entities with the relationship table (cardinality, participation, meaning).
Data dictionary: one table per entity and the data flow dictionary.
