Ad-Hoc Reporting: Data Source Configuration

Ad-Hoc Reporting: Data Source Configuration

Purpose

This article will review the Ad-Hoc Data Source Configuration within the Reports module. 
In this section of generating an ad-hoc report, you’ll be able to choose the specific data you want to retrieve. This selection will then query the dataset in the database.

Related Articles


Video




Instructions


1. Navigate to the Reports Module and select Ad-Hoc Reports from the menu. Click on Create Report. Follow this article on Ad-Hoc: Basic Information for the first step. Select Next on the Basic Information tab to move to Data Source Configuration.





2. Select the main (parent) data source you want to pull information from. You will notice that you have very broad options from each module and very specific options for each module. Try to collect the broadest amount of data first and we can limit it down later using criteria.


Select the main (parent) data source you want to pull information from. You will notice that you have very broad options from each module and very specific options for each module. Try to collect the broadest amount of data first and we can limit it down later using criteria.



3. You can now add child data sources from your parent data source to create a broader pull of information using inclusive relationships. Or you can create a smaller data set by using exclusive relationships.

Info
Inclusive versus Exclusive are explained below. If you are not sure, use Inclusive and filter your data down using criteria later.


You can now add child data sources from your parent data source to create a broader pull of information using inclusive relationships. Or you can create a smaller data set by using exclusive relationships.



4. You will add the first child relationship you want to use directly from the parent data source. Notice the grey line connecting the boxes. Then select Inclusive or Exclusive using the radial buttons.


You will add the first child relationship you want to use directly from the parent data source. Notice the grey line connecting the boxes. Then select Inclusive or Exclusive using the radial buttons.



5. Continue adding child relationships to the parent data source by selecting Add Child next to the parent field. Notice the grey line connections this child to the original parent field.


Continue adding child relationships to the parent data source by selecting Add Child next to the parent field. Notice the grey line connections this child to the original parent field.



6. You can also add child data fields from the first child field by clicking the Add Child button next to the child data field. Notice the grey line has moved and links the new child field as a subset of the first child field.


You can also add child data fields from the first child field by clicking the Add Child button next to the child data field. Notice the grey line has moved and links the new child field as a subset of the first child field.



7. Once you have selected all of the areas that you want to include or exclude data from, click Next to move to the next tab in Ad-Hoc. Click Previous to move back to the Basic Information tab.


Once you have selected all of the areas that you want to include or exclude data from, click Next to move to the next tab in Ad-Hoc. Click Previous to move back to the Basic Information tab.



8. Follow the next article Ad-Hoc: Report Type to continue building your report. 

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.





Another way to view Parent / Child Relationships:




Understanding Inclusive versus Exclusive Relationship Types


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.

A. 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.

a) 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.

B. 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.

a) 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

A. Set A: Represents Incident Reports (Parent data)

B. Set B: Represents Personnel Records (Child data)

C. Inclusive Relationship

a) In this relationship, all data from Set A (Incident Reports) is included, along with all related records from Set B (Personnel Records)

b) 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.

D. Exclusive Relationship

a) In this relationship, only the data where Set A and Set B have matching records is included.

b) 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.







    • Related Articles

    • Ad-Hoc Summary Reports: Grouping

      Purpose This article demonstrates uses cases and provides an overview of grouping options available within a Summary Ad-Hoc report. Summary Reports Grouping is in beta phase. The First Due Team will be making quick and frequent updates to this ...

    • Ad-Hoc Reporting: Columns

      Purpose This article will review the Columns Tab within an Ad-Hoc Report. The columns contain all data points that you selected from the Data Source Configuration Tab. Related Articles Report List Features Ad-Hoc: Data Source Configuration Ad-Hoc: ...

    • Ad-Hoc Reporting: Report Type

      Purpose This article will review selecting your Ad-Hoc Report Type within the Reports module. The options available in each tab will vary based on if you choose Tabular Report or Summary Report. Related Articles Reports List Features Ad-Hoc ...

    • Inspection Record - Ad Hoc Violations

      Purpose To demonstrate how to add Ad Hoc Violations to an Inspection Checklist. An Ad-Hoc Violation is a feature to add a violation to the Checklist that is not contained within the current Checklist. Video Instructions Note: Ad-Hoc Violations must ...

    • Ad-Hoc Reporting: Filters

      Purpose This article will review the Ad-Hoc Filters within the Reports module. Information The Filters section in the ad-hoc reporting module allows users to refine the data included in their reports by applying specific conditions. Filters are ...