Skip to content

Latest commit

 

History

History
96 lines (74 loc) · 7.58 KB

business_rules.md

File metadata and controls

96 lines (74 loc) · 7.58 KB
Raw

Business rules

Below are listed the business rules that one would expect to be true in the data. Nevertheless, neither the processes nor the DBMS enforced them. Thus, they may have been violated giving rise to quality problems.

Notes

  • The identifiers at the beginning of the rules are meant to be set in stone. This number has no particular meaning and it is only used to reference to rules in the code.
  • A checked checkbox means that the rule has been implemented, although this does not guarantee that it has been tested

AMOS database

Identifiers

  • R1: workPackageID is an identifier of WorkPackage.
  • R2: workOrderID is an identifier of WorkOrders/ForecastedOrders/TechnicalLogBookOrders.
  • R3: maintenanceID is an identifier of MaintenanceEvents/OperationInterruption.
  • R4: file is an identifier of Attachments.

References

  • R5: event of an Attachment is a reference to maintenanceID of MaintenanceEvents. (Attachments->MaintenanceEvents)
    • R5-A: an maintenance event produces a number of attachments between 1 and max_attach_size
  • R30: A work order produces a number of work packages between 1 and max_work_packages. These are duplicated entries

Datatypes/Domains

  • R6: subsystem of MaintenanceEvents should be a 4 digits ATA code. See ATA codes for commercial aircrafts in https://en.wikipedia.org/wiki/ATA_100
  • R7: delayCode of OperationInterruption should be a 2 digits IATA code. See https://en.wikipedia.org/wiki/IATA_delay_codes
  • R8: workPackageID/workOrderID/maintenanceID should be simply SERIAL numbers generated by an autoincrement mechanism. See https://www.postgresql.org/docs/9.1/datatype-numeric.html#DATATYPE-NUMERIC-TABLE for details.
    • R8-A: MaintenanceID is not serial as per the datatype shown in the schema (VARCHAR(30)). From observed data, we infer that this value is the concatenation of a random integer + str(starttime + duration) (i.e. the time it ended).
  • R9: ReportKind values “PIREP” and “MAREP” refer to pilot and maintenance personnel as reporters, respectively.
  • R10: MELCathegory values A,B,C,D refer to 3,10,30,120 days of allowed delay in the repairing of the problem in the aircraft, respectively.
  • R11: airport in MaintenanceEvents must have a value.
    • R11-A: What is the value of Airport when maintenance event is of type AOG, Maintenance or Revision? Setting one at random for the moment TODO:

Other business rules

  • R12: In OperationInterruption, departure must coincide with the date of the flightID (see below how it is composed).
    • R12-A: This means that for a flight slot with flightid containing <some date>, this date is the one used as departure in the operation interruption.
    • R12-B: In a flightid, this date being used is the scheduleddeparture. TODO: Confirm this.
    • R12-C: We also use the same flightid.
  • R13: The flight registered in OperationInterruption, must exist in the Flights of AIMS database, and be marked as “delayed” (i.e., delayCode is not null) with the same IATA delay code.
    • If flight_slot.delay_code is not None, then we create an operationinterruption.
  • R14: In MaintenanceEvents, the events of kind Maintenance that correspond to a Revision (event.kind == "Revision"), are those of the same aircraft AND whose interval is completely included in that of the Revision. For all of them, the airport must be the same.
    • If there is an instance of MaintenanceEvents with kind=="Revision" and duration >= 1 days then we produce d entries, one per the d days of the duration, pointing to the same aircraft and airport. We don't consider hours or minutes in the duration, and we consider any remainder d % minutes and hours as one additional day.
  • R24: In MaintenanceEvents, the events of kind Maintenance cannot partially intersect that of a Revision of the same aircraft.
    • this means that for the same aircraft, there can't be two maintenance operations happening at the same point in time
    • this means a posterior check of the maintenance events
    • maintenance events have a starttime and a duration, so out of the final maintenance events, we need to filter out those of type Revision and those of type Maintenance, and deal with those that are overlapping
  • R15: In MaintenanceEvents, maintenance duration must have the expected length according to the kind of maintenance:
    • R15-A: Delay – minutes
    • R15-B: Safety – undetermined/unlimited,
    • R15-C: AircraftOnGround – hours
    • R15-D: Maintenance – hours to max 1 day
      • limit any random duration to max 1 day
    • R15-E: Revision – days to 1 month 1 - [x] limit any random duration to max 31 days

AIMS database

Identifiers

  • R16: flightID is an identifier of Flights.

Datatypes/Domains

  • R17: flightID is derived by concatenating the following values: Date-Origin-Destination-FlightNumber-AircraftRegistration (lengths: 6+1+3+1+3+1+4+1+6=26).
  • R18: delayCode in OperationInterruption is a 2 digits IATA code 2

Other business rules

  • R19: In a Slot, scheduledArrival must be posterior to the scheduledDeparture.
  • R20: Two Slots of the same aircraft cannot overlap in time. Here we assume it refers to flight slots.
    • How do we check this? with a posterior check and a test.
  • R21: In Flights, departure and arrival airports must be those in the flightID (unless this flight has been diverted)
    • TODO: what does it mean that it has been diverted? We assume that some flights can be diverted, and that the flightID has the original information i.e. with some airport A and the actual airport stored is different i.e. B.
  • R22: In a Flight, actualArrival is posterior to actualDeparture.
    • R22-B: If a flight is marked as cancelled, then there is no delay code, no actual arrival and no actual departure reported.
  • R23: In a Maintenance Slot, the corresponding events must exist in AMOS maintenance events, inside the corresponding time interval.
    • This means that a row in MaintenanceSlots induces a maintenance event in MaintenanceEvents within the same time interval
  • R25: A Maintenance event can include several work orders and each work order is inside one maintenance event. However, this reference is not explicit. It is represented by
    • R25-A the same aircraft registration
    • R25-B the fact that the execution date of the work order is inside the time interval of the maintenance event (startdate, startdate + duration).See issue #6 for more details
    • R25-C The execution place of the work order is the airport of the maintenance event TODO: confirm this
  • R26: In ForecastedOrders, the deadline is maintenanceevent.starttime + maintenanceevent.duration, such that planned < executiondate < deadline
  • R27: In ForecastedOrders, planned is equal to maintenanceevent.starttime
  • R28: In TLBOrders, reportingdate is equal to maintenanceevent.starttime. That is, reportingdate < starttime
  • R29: In TLBOrders, due is the within executiondate + a MEL based duration (i.e. the max delay allowed)

Configuration Requirements

These refer to any requirement related to control the data generation process.

  • C1: Users can select how many rows they wish
  • C2: Users can define a probability that a value has noise or is of bad quality