| 3 | | This page documents Phase P6 of the Room Reservation System project. The goal of this phase is to define and implement more complex analytical database reports using SQL. The reports are designed to provide a higher-level picture of the long-term operation of the reservation system. |
| 4 | | |
| 5 | | The project has one team member, therefore two advanced analytical reports are implemented. |
| 6 | | |
| 7 | | The reports are based on the relational schema created in Phase P2 and confirmed through the normalization process in Phase P5. |
| 8 | | |
| 9 | | == Report 1: Quarterly room utilization and approval report == |
| | 3 | This page documents two complex analytical database reports for the Room Reservation System. The reports are written as SQL queries over the implemented PostgreSQL schema in the ''project'' schema. Each report uses several joined relations, grouping, aggregate calculations, conditional aggregation, derived indicators, and ranking in order to provide useful analytical information about the long-term operation of the reservation system. |
| | 4 | |
| | 5 | The selected reports are: |
| | 6 | |
| | 7 | * Quarterly room utilization and reservation status report |
| | 8 | * Quarterly equipment demand and stock pressure report |
| | 9 | |
| | 10 | Both reports are intended to support administrative decision-making. They can be used by a resource administrator or reservation approver to understand how rooms and equipment are used over time, which rooms are most frequently requested, and which equipment types may require additional stock. |
| | 11 | |
| | 12 | == Report 1: Quarterly room utilization and reservation status report == |
| | 13 | |
| | 14 | === Data requirements idea / concept title === |
| | 15 | |
| | 16 | Quarterly room utilization and reservation status report |
| 13 | | This report analyzes how rooms are used over a longer period of time. It groups reservations by quarter, building, and room, and calculates the number of reservation requests, the number of approved, rejected, cancelled, and pending reservations, the total requested hours, and the approved reservation hours. |
| 14 | | |
| 15 | | The report is useful for identifying: |
| 16 | | |
| 17 | | * which rooms are used most often, |
| 18 | | * which rooms have the highest approved reservation time, |
| 19 | | * how much demand exists for each room, |
| 20 | | * whether some rooms are frequently requested but not approved, |
| 21 | | * which rooms are important resources in the organization. |
| 22 | | |
| 23 | | This report can be used on a quarterly, annual, or multi-year level. In the current query, the report is shown for the year 2026. |
| | 20 | This report analyzes how rooms are used during a selected year, grouped by quarter, building, and room. It calculates how many reservations were made for each room, how many of them were approved, rejected, cancelled, or still pending, and how many total hours were requested and approved. |
| | 21 | |
| | 22 | The report is useful because it shows which rooms are used most often and which rooms may be underused. It also helps the organization identify whether certain buildings or room types have higher reservation demand. Since the report is grouped by quarter, it can be used for long-term analysis of room usage trends. |
| | 23 | |
| | 24 | The report uses data from the following relations: |
| | 25 | |
| | 26 | * ''project.reservations'' |
| | 27 | * ''project.rooms'' |
| | 28 | * ''project.buildings'' |
| | 29 | |
| | 30 | The report performs the following operations: |
| | 31 | |
| | 32 | * joins reservations with rooms and buildings; |
| | 33 | * filters room-based reservations only; |
| | 34 | * groups reservations by quarter, building, and room; |
| | 35 | * counts total reservations; |
| | 36 | * counts reservations by status using conditional aggregation; |
| | 37 | * calculates requested and approved reservation hours; |
| | 38 | * calculates each room's share of approved hours within the quarter; |
| | 39 | * ranks rooms by utilization within each quarter. |
| 60 | | ROUND(COALESCE(SUM(duration_hours), 0)::numeric, 2) AS requested_hours, |
| 61 | | ROUND(COALESCE(SUM(duration_hours) FILTER (WHERE status = 'approved'), 0)::numeric, 2) AS approved_hours, |
| 62 | | ROUND( |
| 63 | | (100.0 * COUNT(*) FILTER (WHERE status = 'approved') / NULLIF(COUNT(*), 0))::numeric, |
| 64 | | 2 |
| 65 | | ) AS approval_rate_percent |
| 66 | | FROM reservation_base |
| | 77 | ROUND(SUM(reservation_hours), 2) AS requested_hours, |
| | 78 | ROUND(COALESCE(SUM(reservation_hours) FILTER (WHERE status = 'approved'), 0), 2) AS approved_hours |
| | 79 | FROM room_reservation_base |
| 90 | | ORDER BY approved_hours DESC, total_room_reservations DESC, capacity DESC |
| 91 | | ) AS utilization_rank_in_quarter |
| 92 | | FROM room_report |
| | 108 | ORDER BY approved_hours DESC, total_room_reservations DESC, room_code |
| | 109 | ) AS utilization_rank, |
| | 110 | CASE |
| | 111 | WHEN approved_hours >= 4 THEN 'high_usage' |
| | 112 | WHEN approved_hours >= 2 THEN 'medium_usage' |
| | 113 | WHEN approved_hours > 0 THEN 'low_usage' |
| | 114 | ELSE 'no_approved_usage' |
| | 115 | END AS utilization_level |
| | 116 | FROM room_quarter_summary |
| | 117 | ) |
| | 118 | SELECT |
| | 119 | quarter_start, |
| | 120 | building_name, |
| | 121 | room_code, |
| | 122 | type, |
| | 123 | capacity, |
| | 124 | total_room_reservations, |
| | 125 | approved_reservations, |
| | 126 | rejected_reservations, |
| | 127 | cancelled_reservations, |
| | 128 | pending_reservations, |
| | 129 | requested_hours, |
| | 130 | approved_hours, |
| | 131 | approved_hours_share_percent, |
| | 132 | utilization_rank, |
| | 133 | utilization_level |
| | 134 | FROM room_quarter_ranked |
| 100 | | === Explanation of the SQL solution === |
| 101 | | |
| 102 | | The query first creates a temporary result named ''reservation_base''. This part joins reservations, rooms, and buildings, and calculates the duration of each room reservation in hours. |
| 103 | | |
| 104 | | The second temporary result, ''room_report'', groups the data by quarter, building, room, room type, and capacity. It calculates aggregate values such as the total number of room reservations, the number of approved reservations, the number of rejected reservations, the number of cancelled reservations, the number of pending reservations, the total requested hours, and the approved hours. |
| 105 | | |
| 106 | | The final SELECT adds a ranking value using the SQL window function RANK(). Rooms are ranked inside each quarter according to approved reservation hours, number of reservations, and capacity. |
| 107 | | |
| 108 | | This makes the report analytical because it combines joins, filtering, grouping, conditional aggregation, duration calculation, and window ranking. |
| 109 | | |
| 116 | | * Reservations = Res |
| 117 | | * Rooms = R |
| 118 | | * Buildings = B |
| 119 | | |
| 120 | | First, create the joined reservation-room-building relation: |
| 121 | | |
| 122 | | {{{ |
| 123 | | RB = |
| 124 | | σ_{reservation_date >= '2026-01-01' ∧ reservation_date < '2027-01-01'} |
| 125 | | ( |
| 126 | | Res ⋈*{Res.room_id = R.room_id} R |
| 127 | | ⋈*{R.building_id = B.building_id} B |
| 128 | | ) |
| 129 | | }}} |
| 130 | | |
| 131 | | Then calculate grouped room utilization statistics: |
| 132 | | |
| 133 | | {{{ |
| 134 | | RoomReport = |
| 135 | | γ_{quarter(reservation_date), B.name, R.room_code, R.type, R.capacity; |
| | 148 | * ''RES'' = Reservations |
| | 149 | * ''R'' = Rooms |
| | 150 | * ''B'' = Buildings |
| | 151 | |
| | 152 | First, select only room-based reservations in the selected period: |
| | 153 | |
| | 154 | {{{ |
| | 155 | A = |
| | 156 | σ room_id IS NOT NULL AND reservation_date >= '2026-01-01' AND reservation_date < '2027-01-01' |
| | 157 | (RES) |
| | 158 | }}} |
| | 159 | |
| | 160 | Then join reservations with rooms and buildings: |
| | 161 | |
| | 162 | {{{ |
| | 163 | B1 = |
| | 164 | A ⨝ A.room_id = R.room_id R |
| | 165 | }}} |
| | 166 | |
| | 167 | {{{ |
| | 168 | B2 = |
| | 169 | B1 ⨝ R.building_id = B.building_id B |
| | 170 | }}} |
| | 171 | |
| | 172 | Then group the result by quarter, building, room, room type, and capacity: |
| | 173 | |
| | 174 | {{{ |
| | 175 | C = |
| | 176 | γ quarter_start, building_name, room_id, room_code, type, capacity; |
| 137 | | COUNT_{status = 'approved'}(reservation_id) → approved_reservations, |
| 138 | | COUNT_{status = 'rejected'}(reservation_id) → rejected_reservations, |
| 139 | | COUNT_{status = 'cancelled'}(reservation_id) → cancelled_reservations, |
| 140 | | COUNT_{status = 'pending'}(reservation_id) → pending_reservations, |
| | 178 | COUNT(status = 'approved') → approved_reservations, |
| | 179 | COUNT(status = 'rejected') → rejected_reservations, |
| | 180 | COUNT(status = 'cancelled') → cancelled_reservations, |
| | 181 | COUNT(status = 'pending') → pending_reservations, |
| 151 | | ρ_{approval_rate_percent, utilization_rank_in_quarter} |
| 152 | | (RoomReport) |
| 153 | | }}} |
| 154 | | |
| 155 | | The report preserves the meaning of the original relations because every joined tuple represents a reservation connected to exactly one room and one building. |
| 156 | | |
| 157 | | == Report 2: Quarterly equipment demand and replenishment report == |
| | 191 | ρ approved_hours_share_percent, utilization_rank, utilization_level |
| | 192 | (C) |
| | 193 | }}} |
| | 194 | |
| | 195 | This corresponds to the SQL query where window functions and CASE expressions are used for ranking and classification. |
| | 196 | |
| | 197 | === Report result screenshot === |
| | 198 | |
| | 199 | The following screenshot shows the result of executing the first report in DBeaver. |
| | 200 | |
| | 201 | [[Image(report1_room_utilization.png, width=100%)]] |
| | 202 | |
| | 203 | ''Figure 1. Quarterly room utilization report showing room reservations grouped by quarter, building, room, room type, capacity, reservation status, requested hours, and utilization ranking.'' |
| | 204 | |
| | 205 | === Discussion === |
| | 206 | |
| | 207 | The first report shows how each room is used during each quarter. The result includes the number of reservations, the number of approved, rejected, cancelled, and pending reservations, and the number of requested and approved reservation hours. |
| | 208 | |
| | 209 | This report is useful for identifying rooms with high demand and rooms that are rarely used. If a room has a high utilization rank and many approved hours, the organization may consider increasing availability of similar rooms or assigning more equipment to that room type. If a room has very low usage, the organization may investigate whether its capacity, type, location, or equipment availability is not suitable for users. |
| | 210 | |
| | 211 | == Report 2: Quarterly equipment demand and stock pressure report == |
| | 212 | |
| | 213 | === Data requirements idea / concept title === |
| | 214 | |
| | 215 | Quarterly equipment demand and stock pressure report |
| 161 | | This report analyzes how often equipment is requested as part of reservations and compares that demand with the available equipment quantity in the system. It combines equipment from general stock and equipment assigned to specific rooms. |
| 162 | | |
| 163 | | The report is useful for identifying: |
| 164 | | |
| 165 | | * which equipment is requested most often, |
| 166 | | * which equipment has high demand compared to available quantity, |
| 167 | | * whether equipment demand increases or decreases between quarters, |
| 168 | | * which equipment types should be considered for replenishment, |
| 169 | | * whether the organization has enough available equipment for future reservations. |
| 170 | | |
| 171 | | This report can support planning and decision-making for equipment purchasing and resource management. |
| | 219 | This report analyzes equipment demand during a selected year, grouped by quarter and equipment type. It compares the number of requested equipment items with the registered stock quantity and the equipment assigned to rooms. It also calculates how much demand was approved, pending, or rejected. |
| | 220 | |
| | 221 | The report is useful because it helps the organization understand which equipment types are requested most often and whether the existing stock is sufficient. It can support decisions about purchasing new equipment, moving equipment between rooms, or increasing the stock of frequently requested equipment. |
| | 222 | |
| | 223 | The report uses data from the following relations: |
| | 224 | |
| | 225 | * ''project.equipment'' |
| | 226 | * ''project.room_equipment'' |
| | 227 | * ''project.reservation_equipment'' |
| | 228 | * ''project.reservations'' |
| | 229 | |
| | 230 | The report performs the following operations: |
| | 231 | |
| | 232 | * calculates how much equipment is assigned to rooms; |
| | 233 | * joins requested equipment with reservations and equipment data; |
| | 234 | * groups equipment demand by quarter and equipment type; |
| | 235 | * calculates total requested quantity; |
| | 236 | * calculates approved, pending, rejected, and cancelled requested quantities; |
| | 237 | * compares demand with total registered quantity; |
| | 238 | * calculates demand ratio; |
| | 239 | * compares demand with the previous quarter; |
| | 240 | * ranks equipment by demand in each quarter; |
| | 241 | * classifies demand level as critical, high, medium, or low. |
| 190 | | DATE_TRUNC('quarter', res.reservation_date)::date AS quarter_start, |
| 191 | | COUNT(DISTINCT re.reservation_id) AS reservations_with_equipment, |
| 192 | | COALESCE(SUM(re.requested_quantity), 0) AS total_requested_quantity, |
| 193 | | COALESCE(SUM(re.requested_quantity) FILTER (WHERE res.status = 'approved'), 0) AS approved_requested_quantity, |
| 194 | | COALESCE(SUM(re.requested_quantity) FILTER (WHERE res.status = 'pending'), 0) AS pending_requested_quantity, |
| 195 | | COALESCE(SUM(re.requested_quantity) FILTER (WHERE res.status = 'rejected'), 0) AS rejected_requested_quantity |
| 196 | | FROM project.equipment e |
| | 261 | COUNT(DISTINCT res.reservation_id) AS reservations_with_equipment, |
| | 262 | SUM(req.requested_quantity) AS total_requested_quantity, |
| | 263 | COALESCE(SUM(req.requested_quantity) FILTER (WHERE res.status = 'approved'), 0) AS approved_requested_quantity, |
| | 264 | COALESCE(SUM(req.requested_quantity) FILTER (WHERE res.status = 'pending'), 0) AS pending_requested_quantity, |
| | 265 | COALESCE(SUM(req.requested_quantity) FILTER (WHERE res.status = 'rejected'), 0) AS rejected_requested_quantity, |
| | 266 | COALESCE(SUM(req.requested_quantity) FILTER (WHERE res.status = 'cancelled'), 0) AS cancelled_requested_quantity |
| | 267 | FROM project.reservation_equipment req |
| | 268 | JOIN project.reservations res |
| | 269 | ON req.reservation_id = res.reservation_id |
| | 270 | JOIN project.equipment e |
| | 271 | ON req.equipment_id = e.equipment_id |
| 198 | | ON rs.equipment_id = e.equipment_id |
| 199 | | LEFT JOIN project.reservation_equipment re |
| 200 | | ON re.equipment_id = e.equipment_id |
| 201 | | LEFT JOIN project.reservations res |
| 202 | | ON res.reservation_id = re.reservation_id |
| 203 | | WHERE res.reservation_date IS NULL |
| 204 | | OR ( |
| 205 | | res.reservation_date >= DATE '2026-01-01' |
| | 273 | ON e.equipment_id = rs.equipment_id |
| | 274 | WHERE res.reservation_date >= DATE '2026-01-01' |
| 240 | | COALESCE(previous_quarter_requested, 0) AS previous_quarter_requested, |
| 241 | | total_requested_quantity - COALESCE(previous_quarter_requested, 0) AS requested_quantity_change, |
| 242 | | demand_to_registered_quantity_ratio, |
| | 296 | cancelled_requested_quantity, |
| | 297 | LAG(total_requested_quantity) OVER ( |
| | 298 | PARTITION BY equipment_id |
| | 299 | ORDER BY quarter_start |
| | 300 | ) AS previous_quarter_requested_quantity |
| | 301 | FROM equipment_demand |
| | 302 | ), |
| | 303 | equipment_ranked AS ( |
| | 304 | SELECT |
| | 305 | quarter_start, |
| | 306 | equipment_name, |
| | 307 | stock_quantity, |
| | 308 | assigned_room_quantity, |
| | 309 | total_registered_quantity, |
| | 310 | reservations_with_equipment, |
| | 311 | total_requested_quantity, |
| | 312 | approved_requested_quantity, |
| | 313 | pending_requested_quantity, |
| | 314 | rejected_requested_quantity, |
| | 315 | cancelled_requested_quantity, |
| | 316 | COALESCE(previous_quarter_requested_quantity, 0) AS previous_quarter_requested_quantity, |
| | 317 | total_requested_quantity - COALESCE(previous_quarter_requested_quantity, 0) AS request_change_from_previous_quarter, |
| | 318 | ROUND( |
| | 319 | total_requested_quantity::numeric / NULLIF(total_registered_quantity, 0), |
| | 320 | 2 |
| | 321 | ) AS demand_ratio, |
| | 322 | DENSE_RANK() OVER ( |
| | 323 | PARTITION BY quarter_start |
| | 324 | ORDER BY total_requested_quantity DESC, equipment_name |
| | 325 | ) AS demand_rank, |
| 244 | | WHEN demand_to_registered_quantity_ratio >= 1 THEN 'high demand - consider replenishment' |
| 245 | | WHEN demand_to_registered_quantity_ratio >= 0.5 THEN 'medium demand' |
| 246 | | ELSE 'low demand' |
| 247 | | END AS demand_assessment |
| 248 | | FROM equipment_analysis |
| | 327 | WHEN total_requested_quantity > total_registered_quantity THEN 'critical_demand' |
| | 328 | WHEN total_requested_quantity >= total_registered_quantity * 0.75 THEN 'high_demand' |
| | 329 | WHEN total_requested_quantity >= total_registered_quantity * 0.40 THEN 'medium_demand' |
| | 330 | ELSE 'low_demand' |
| | 331 | END AS demand_level |
| | 332 | FROM equipment_with_previous_quarter |
| | 333 | ) |
| | 334 | SELECT |
| | 335 | quarter_start, |
| | 336 | equipment_name, |
| | 337 | stock_quantity, |
| | 338 | assigned_room_quantity, |
| | 339 | total_registered_quantity, |
| | 340 | reservations_with_equipment, |
| | 341 | total_requested_quantity, |
| | 342 | approved_requested_quantity, |
| | 343 | pending_requested_quantity, |
| | 344 | rejected_requested_quantity, |
| | 345 | cancelled_requested_quantity, |
| | 346 | previous_quarter_requested_quantity, |
| | 347 | request_change_from_previous_quarter, |
| | 348 | demand_ratio, |
| | 349 | demand_rank, |
| | 350 | demand_level |
| | 351 | FROM equipment_ranked |
| 255 | | === Explanation of the SQL solution === |
| 256 | | |
| 257 | | The query first calculates the total quantity of each equipment type that is assigned to rooms. This is done in the temporary result ''room_stock'' by grouping records from ''project.room_equipment''. |
| 258 | | |
| 259 | | The second temporary result, ''equipment_demand'', combines equipment, room stock, requested equipment, and reservations. It calculates the number of reservations that requested each equipment type, the total requested quantity, and the requested quantity by reservation status. |
| 260 | | |
| 261 | | The third temporary result, ''equipment_analysis'', calculates the demand-to-available-quantity ratio and uses the LAG() window function to compare current quarter demand with previous quarter demand. |
| 262 | | |
| 263 | | The final SELECT returns the equipment demand analysis and adds a textual demand assessment. If the requested quantity is greater than or equal to the total registered quantity, the report marks the equipment as high demand and suggests replenishment. |
| 264 | | |
| 265 | | This makes the report analytical because it combines multiple relations, grouping, conditional aggregation, stock comparison, trend comparison, and decision-oriented classification. |
| 266 | | |
| 284 | | } |
| 285 | | (REqRoom) |
| 286 | | }}} |
| 287 | | |
| 288 | | Then join equipment with room stock, requested equipment, and reservations: |
| 289 | | |
| 290 | | {{{ |
| 291 | | EquipmentBase = |
| 292 | | E ⟕*{E.equipment_id = RoomStock.equipment_id} RoomStock |
| 293 | | ⟕*{E.equipment_id = REqRes.equipment_id} REqRes |
| 294 | | ⟕_{REqRes.reservation_id = Res.reservation_id} Res |
| 295 | | }}} |
| 296 | | |
| 297 | | Then group the data by quarter and equipment type: |
| 298 | | |
| 299 | | {{{ |
| 300 | | EquipmentDemand = |
| 301 | | γ_{quarter(reservation_date), E.equipment_id, E.name, E.stock_quantity, assigned_room_quantity; |
| 302 | | COUNT(REqRes.reservation_id) → reservations_with_equipment, |
| | 375 | (RE) |
| | 376 | }}} |
| | 377 | |
| | 378 | Then join reservation equipment with reservations and equipment: |
| | 379 | |
| | 380 | {{{ |
| | 381 | A = |
| | 382 | REQ ⨝ REQ.reservation_id = RES.reservation_id RES |
| | 383 | }}} |
| | 384 | |
| | 385 | {{{ |
| | 386 | B = |
| | 387 | A ⨝ REQ.equipment_id = E.equipment_id E |
| | 388 | }}} |
| | 389 | |
| | 390 | Then add the equipment quantity assigned to rooms using a left outer join: |
| | 391 | |
| | 392 | {{{ |
| | 393 | C = |
| | 394 | B ⟕ E.equipment_id = RS.equipment_id RS |
| | 395 | }}} |
| | 396 | |
| | 397 | Then select only reservations in the selected year: |
| | 398 | |
| | 399 | {{{ |
| | 400 | D = |
| | 401 | σ reservation_date >= '2026-01-01' AND reservation_date < '2027-01-01' |
| | 402 | (C) |
| | 403 | }}} |
| | 404 | |
| | 405 | Then group the result by quarter and equipment type: |
| | 406 | |
| | 407 | {{{ |
| | 408 | E1 = |
| | 409 | γ quarter_start, equipment_id, equipment_name, stock_quantity, assigned_room_quantity; |
| | 410 | COUNT(DISTINCT reservation_id) → reservations_with_equipment, |
| 304 | | SUM_{status = 'approved'}(requested_quantity) → approved_requested_quantity, |
| 305 | | SUM_{status = 'pending'}(requested_quantity) → pending_requested_quantity, |
| 306 | | SUM_{status = 'rejected'}(requested_quantity) → rejected_requested_quantity |
| 307 | | } |
| 308 | | (EquipmentBase) |
| 309 | | }}} |
| 310 | | |
| 311 | | Finally, extend the grouped relation with the demand ratio, previous quarter demand, and demand assessment: |
| | 412 | SUM(requested_quantity WHERE status = 'approved') → approved_requested_quantity, |
| | 413 | SUM(requested_quantity WHERE status = 'pending') → pending_requested_quantity, |
| | 414 | SUM(requested_quantity WHERE status = 'rejected') → rejected_requested_quantity, |
| | 415 | SUM(requested_quantity WHERE status = 'cancelled') → cancelled_requested_quantity |
| | 416 | (D) |
| | 417 | }}} |
| | 418 | |
| | 419 | Finally, extended relational algebra is used to calculate: |
| | 420 | |
| | 421 | * total registered quantity; |
| | 422 | * demand ratio; |
| | 423 | * previous quarter demand; |
| | 424 | * demand change; |
| | 425 | * demand rank; |
| | 426 | * demand level classification. |
| 315 | | ρ_{total_registered_quantity, |
| 316 | | demand_to_registered_quantity_ratio, |
| 317 | | previous_quarter_requested, |
| 318 | | requested_quantity_change, |
| 319 | | demand_assessment} |
| 320 | | (EquipmentDemand) |
| 321 | | }}} |
| 322 | | |
| 323 | | The report preserves the meaning of the database model because equipment demand is calculated from !ReservationEquipment, while available equipment is calculated from Equipment and !RoomEquipment. |
| | 430 | ρ total_registered_quantity, demand_ratio, previous_quarter_requested_quantity, |
| | 431 | request_change_from_previous_quarter, demand_rank, demand_level |
| | 432 | (E1) |
| | 433 | }}} |
| | 434 | |
| | 435 | This corresponds to the SQL query where window functions, arithmetic expressions, and CASE expressions are used. |
| | 436 | |
| | 437 | === Report result screenshot === |
| | 438 | |
| | 439 | The following screenshot shows the result of executing the second report in DBeaver. |
| | 440 | |
| | 441 | [[Image(report2_equipment_demand.png, width=100%)]] |
| | 442 | |
| | 443 | ''Figure 2. Quarterly equipment demand report showing requested equipment quantities, registered stock, approved, pending, rejected demand, demand ratio, previous quarter comparison, and demand level assessment.'' |
| | 444 | |
| | 445 | === Discussion === |
| | 446 | |
| | 447 | The second report shows how often each equipment type is requested and compares the requested quantity with the equipment registered in the system. This is useful for identifying equipment that is requested more often than expected. |
| | 448 | |
| | 449 | For example, if an equipment item has a high demand ratio or a critical demand level, the organization may need to purchase more units, assign more units to rooms, or manage equipment availability more carefully. If an equipment item has low demand, the organization may decide that the existing stock is sufficient. |
| | 450 | |
| | 451 | The report also includes a comparison with the previous quarter. This allows administrators to identify whether equipment demand is increasing or decreasing over time. |
| 327 | | The two implemented reports provide analytical information that is not directly visible from simple table contents. |
| 328 | | |
| 329 | | The first report focuses on room utilization. It helps identify which rooms are most frequently used and which rooms have the highest number of approved reservation hours. This can help the organization understand room demand and make better decisions about room scheduling and future room allocation. |
| 330 | | |
| 331 | | The second report focuses on equipment demand. It helps identify which equipment types are frequently requested and whether the current registered quantity is sufficient. This can help the organization decide whether certain equipment should be replenished or redistributed. |
| 332 | | |
| 333 | | Both reports are implemented with SQL queries over the normalized relational model from Phase P2 and Phase P5. No additional database tables are required because the existing schema already stores the necessary information about rooms, buildings, reservations, users, equipment, equipment assigned to rooms, and equipment requested in reservations. |
| 334 | | |
| 335 | | The reports can be reused in later phases as part of the application or as administrative database reports. |
| | 455 | The two reports provide analytical information that is not directly visible from individual reservation records. The first report focuses on room utilization and reservation status, while the second report focuses on equipment demand and stock pressure. |
| | 456 | |
| | 457 | The reports are more complex than the basic SQL queries used in previous phases because they use: |
| | 458 | |
| | 459 | * multiple joined tables; |
| | 460 | * common table expressions; |
| | 461 | * aggregate functions; |
| | 462 | * conditional aggregation with FILTER; |
| | 463 | * date-based grouping by quarter; |
| | 464 | * calculated indicators; |
| | 465 | * window functions; |
| | 466 | * ranking; |
| | 467 | * CASE-based classification. |
| | 468 | |
| | 469 | These reports can later be integrated into the prototype or into a future application interface as administrative reports. They support better planning of room capacity, equipment availability, and long-term resource management. |