Understanding Child Relationships 

1. Child relationships enable the retrieval of multiple rows of data from a single distinct event. This means that instead of limiting the scope, these relationships can actually broaden the range of data included in the report. 
   
2. A clear way to describe this is by considering the process: the user starts with a primary or “parent” data source. From this starting point, the system retrieves additional, related information, known as the “child” data, which is linked to the parent data source. 
   
3. This allows users to view and analyze connected data points within their reports, providing a more complete picture of the events or entities.
   
4. Example of Using Apparatus in Child Relationships
   
1. Starting with the Parent Data Source: The parent data source in this example could be an “Incident Report.” This is the starting point for the report, where the high-level data about the incident is first collected.
2. First Layer - Apparatus Information: From the incident report, you might want to retrieve additional information about the apparatus involved in the incident. This is the first child relationship where each piece of apparatus related to the incident is listed.
3. Second Layer - Personnel on Apparatus: To get even more granular, you can establish another child relationship to pull in data about the personnel assigned to each apparatus. This relationship adds another layer, giving you detailed information about the people on board each piece of apparatus.
4. Third Layer - Personnel Details: Going even deeper, you might want to access specific details about each personnel member, such as their records from the personnel file. This further granularity allows you to drill down from the incident level, through the apparatus, to the individual personnel members.
   
5. 
   
   

Choosing the right relationship type depends on the level of detail you need and how specific your reporting requirements are. We recommend using Inclusive relationships when you want to capture all available data related to the parent entity. Any further information you require can be achieved in the criteria section of the report setup.

1. The two main types of relationships—Inclusive and Exclusive—define how data is retrieved and filtered based on the established relationships between parent and child data sets. Below is an explanation of each relationship type and how they function in ad-hoc reporting.
   1. Inclusive Relationships: An inclusive relationship allows the report to include all relevant child data that is associated with the parent data set, without any additional filtering or exclusions. This means that all possible matches from the child data will be retrieved and included in the report.
      1. Use Case: An inclusive relationship is ideal when you want to ensure that all data linked to the parent entity is included. This is useful for generating comprehensive reports that provide a full view of the related data.
   2. Exclusive Relationships: An exclusive relationship, on the other hand, filters the data by applying specific criteria, excluding any child data that does not meet those conditions. Only the child records that satisfy the defined parameters will be included in the report.
      1. Use Case: Exclusive relationships are useful when you need a more targeted report that only focuses on specific subsets of the child data. This approach ensures that the report is limited to the most relevant information, filtering out unnecessary or irrelevant data.
2. Key Differences Example
   1. Set A: Represents Incident Reports (Parent data)
   2. Set B: Represents Personnel Records (Child data)
   3. Inclusive Relationship
      1. In this relationship, all data from Set A (Incident Reports) is included, along with all related records from Set B (Personnel Records)
      2. Even if some records in Set A (Incident Reports) don’t have matching records in Set B (Personnel Records), they are still included in the report, but the personnel fields would show as empty for those specific incidents.
   4. Exclusive Relationship
      1. In this relationship, only the data where Set A and Set B have matching records is included.
      2. If a record in Set A (Incident Reports) doesn’t have matching data in Set B (Personnel Records), it will be excluded from the report. This filters the data down to only those incidents that have personnel linked to them.