RI 2025 H2 Computing Prelim Paper 1 Solutions

1 (a) [1m] All four entities shown [1m] Correct 1:1 relationship shown (Ride - Payment) [1m] Correct 1:M relationships (e.g., one Driver has many Rides, One Passenger has many Rides) (b) Ride (RideID, PickupLocation, DropoffLocation, RideDateTime, Status, DriverID, PassengerID) Driver (DriverID, FullName, VehicleNumber, LicenseExpiryDate, ContactNumber) Passenger (PassengerID, FullName, PhoneNumber, EmailAddress) Payment (PaymentID, RideID, PaymentMethod, FareAmount, PaymentStatus) (c) (i) SELECT DriverID, SUM(FareAmount) AS TotalEarnings FROM Ride JOIN Payment ON Ride.RideID = Payment.RideID WHERE PaymentStatus = 'paid' GROUP BY DriverID ORDER BY TotalEarnings DESC; (ii) UPDATE Payment SET PaymentStatus = 'paid' WHERE RideID = 'R7645'; Passenger Driver Ride Payment

(d) Reasons why NoSQL is suitable for storing customer reviews: 1. Unstructured/semi-structured data – Reviews may contain ratings, free text, emojis, images, etc., which NoSQL can store more naturally than SQL. 2. Schema flexibility – Different reviews can have different fields (e.g. some with upvotes, some without) without needing database redesign, supporting future feature expansion. 3. Horizontal scalability – NoSQL can distribute data across multiple servers, handling thousands/millions of reviews efficiently as the platform grows. 4. Fault tolerance – Reviews can be replicated across multiple servers; if one server fails, data is still accessible. This ensures reliability and availability for both passengers and drivers. 5. Hierarchical data storage – NoSQL supports nested structures. For example, a single review record could include: o Review text and rating o Driver replies o User upvotes o Timestamps This avoids the need to split into multiple relational tables and makes retrieving full review threads faster. 6. Performance on queries – Fetching a review document is faster (no complex joins across multiple tables as in SQL), which improves the app’s responsiveness. (e) (Any 2 of the following, or any other reasonable answers): 1. Location data misuse: Concern that real-time or historical pickup/drop-off locations might be shared with third parties or used to track personal habits. 2. Unconsented data sharing: Worry that personal information (e.g., name or contact number) may be shared with external advertisers or third-party apps without consent. 3. Data retention: Concern about how long the company keeps ride history and whether old data is securely deleted. (f) (Any 2 of the following, or any other reasonable answers): 1. Do not misuse passenger contact details: A driver must not use the passenger’s phone number (e.g., for personal messages or marketing) after the ride is completed.

2. Keep information confidential: A driver must not disclose passenger details (e.g., drop-off location, name) to others or post them online. 3. Report data breaches: If a driver’s device is lost or compromised, they must report it to the platform if passenger data is affected. (g) Actions the company should take: 1. Anonymise or pseudonymise data before sharing (e.g., remove names, mask phone numbers) 2. Obtain informed consent from passengers OR ensure a data sharing agreement is in place that complies with data protection laws (e.g., PDPA, GDPR) 3. Limit Data to the Minimum Necessary: e.g., transaction IDs, device fingerprints) — not unnecessary details like full names or contact numbers. 2a) • AddOrder(orderID): Hash table, O(1) average case insertion time • CheckOrderExists(orderID): Hash table, O(1) average case lookup time • GetMostRecentOrder(): Stack, O(1) to access top of stack • GetAllOrdersSorted(): Binary Search Tree, O(n) in-order traversal returns sorted list in O(n) AddOrder - Should not be Unordered List even as insert/delete can be O(1), as the system will also need to support CheckOrderExists, which makes Hash Table more suitable (b) A linked list does not support direct access to elements by key. To check whether an order exists, the system must traverse the list from start to end, resulting in O(n) time complexity. This becomes inefficient as the number of orders grows. (c) The company wants to display all active orders sorted by orderID or order time on a dashboard for warehouse staff. 1m-Weakness of HT Hash tables do not maintain any inherent order of keys. 1m – Explain the inefficiency To retrieve active orders in a sorted order, the system must first extract all values and then sort them manually, which adds an extra O(n log n) operation. 1m-Proposing suitable alternative This reduces efficiency compared to using a data structure that maintains order, such as a binary search tree or a priority queue.

(d) Use a queue to manage orders. A queue naturally supports first-come, first-served processing, which matches the requirement to fulfil orders in chronological order. Insertion of new orders is O(1) at the rear, and fulfilling orders is O(1) at the front, making it efficient even under high sales volumes. 1m – identify queue (FIFO characteristics) 1m – Justifies enqueue and dequeue operation efficiency

3a) +-----------------------------+ | Robot (Superclass) | +-----------------------------+ | - robotID: String | | - status: String | | - batteryLevel: Integer | | - location: String | +-----------------------------+ | + PerformTask() | | + get_robotID(): String | | + set_robotID(String) | | + get_status(): String | | + set_status (String) | | + get_batteryLevel(): Int | | + set_batteryLevel(Int) | | + get_location(): String | | + set_location(String) | +-----------------------------+ / | \ / | \ / | \ +----------------------+ +-------------------------+ +----------------------------+ | TransportRobot | | SortingRobot | | RestockRobot | +----------------------+ +-------------------------+ +----------------------------+ | - kgCarried: Int | | - parcelsPerHr: Int | | - shelvesRestocked: Int | +----------------------+ +-------------------------+ +----------------------------+ | + PerformTask() | | + PerformTask() | | + PerformTask() | | + get_kgCarried() | | + get_parcelsPerHr() | | + get_shelvesRestocked() | | : Int | | : Int | | : Int | | + set_kgCarried(int) | | + set_parcelsPerHr(Int) | | + set_shelvesRestocked(Int)| +----------------------+ +-------------------------+ +----------------------------+ Names of superclass and subclasses [1] Superclass attributes [1] Superclass getters and setters [1] Subclasses all attributes [1] Subclasses all getters and setters [1] Polymorphic method in super and subclasses [1] Arrows must point to superclass [1] Private minus and public plus [1]

b) (i) Instantiation is the process of creating an object from a class. For example, creating a new TransportRobot object called robot1 is instantiating the TransportRobot class. (ii) Encapsulation is the concept of hiding internal data of an object and allowing access only through methods. Accept: bundling of private data and public methods in a single class In the simulation, the robot’s batteryLevel can be made private, and only modified via the PerformTask() method. (iii) Inheritance allows a subclass to reuse attribute