2. Register Tables

Our catalog is created and we can start registering tables in it.

---

Step 1: Select Data

We'll work with the following seven source tables of our Credit Default Dataset:

Table	Description
NEW_APPLICATION	Contains information about new loan applications submitted by clients.
CLIENT_PROFILE	Describes the profile for each client.
BUREAU	Lists credits taken by clients from other financial institutions, as reported to the credit bureau.
PREVIOUS_APPLICATION	Details prior loan applications by the client.
INSTALLMENTS_PAYMENTS	Logs monthly installments for loans at the time of payment.
LOAN_STATUS	Tracks whether loan was terminated.
CREDIT_CARD_MONTHLY_BALANCE	Monthly balance summaries for credit cards

---

Step 2: Locate Your data

From the menu, go to the Explore section and access the Source Tables.

Go to the DEMO_DATASETS database, and select the CREDIT_DEFAULT schema.

---

Step 3: Explore Tables

To help you get familiar with the data in the CREDIT_DEFAULT schema, select tables you are interested in.

Click to generate a summary for each table. Click to read full summary.

Click one table to view its columns and preview its values.

---

Step 4: Understand Table Types

For accurate feature derivation, FeatureByte needs to recognize the roles of different tables.

Each table should be assigned a specific type based on its structure and purpose:

• NEW_APPLICATION --> Dimension table.

  Why Dimesion Table?

  While we could have registered this as an Event table, this table contains only a subset of the applications. By setting it as a Dimension Table, we disable aggregations, preventing potentially non-meaningful computations.

• CLIENT_PROFILE --> Slowly Changing Dimension (SCD) table.

  Why Slowly Changing Dimension Table?

  The table tracks the client profile that changes over time, making it a Slowly Changing Dimension (SCD) Table.

• BUREAU --> Event table.

  Why Event Table?

  The table captures event-based updates from the credit bureau regarding external credit activities.

• PREVIOUS_APPLICATION --> Event table.

  Why Event Table?

  The table records events tied to decisions made on previous loan applications.

• LOAN_STATUS --> Slowly Changing Dimension (SCD) table.

  Why Slowly Changing Dimension Table?

  The table tracks loan statuses and dynamic fields that change over time, making it a Slowly Changing Dimension (SCD) Table.

• INSTALLMENTS_PAYMENTS --> Event table.

  Why Event Table?

  The table logs discrete payment events for loan installments.

• CREDIT_CARD_MONTHLY_BALANCE --> Time Series table.

  Why Time Series Table?

  The table provides monthly reports of credit cards usage, aligning well with time series. Alternatively, it could also be registered as a Snapshots Table, since it represents periodic states captured at strict, regular intervals. Choose the Snapshots Table type if you plan to enrich other tables (e.g., by joining on the card identifiers) or to model relationships between the card and client entities.

---

Step 5: Create Managed View (if necessary)

Use a custom SQL script to define the exact subset of data that FeatureByte should use before table registration. This is especially useful for trimming long histories or excluding columns that are not suitable for modeling or feature engineering.

In this example, we will unselect the column GENDER from the source table CLIENT_PROFILE.

1. Select the CLIENT_PROFILE table.

   ---

2. Click .

3. Remove GENDER in the SQL Select statement that is automatically generated.

   ---

4. Click .

   ---

5. Click to save the view.

6. Review the newly created Managed View. If you want to register a table from this view, click .

---

Step 6: Register the NEW_APPLICATION table

1. Select the NEW_APPLICATION table.

   ---

2. Click on to start registration.

3. Set the table type as Dimension Table.

4. Specify its Dimension ID Column. Here: SK_ID_CURR.

5. Specify the Record Creation Timestamp Column if applicable. Here: available_at.

6. Complete registration by clicking .

---

Step 7: Register the CLIENT_PROFILE table as a SCD Table

1. Select the CLIENT_PROFILE table.

   ---

2. Click on

3. Click on to get assistance:

   You should confirm or update the following fields:

   • Table type

     • Set Table Type to Slowly Changing Dimension (SCD) Table

   • Key and Timestamp columns

     • Natural Key Column: ClientID
     • Surrogate Key Column: Not applicable for this table.
     • Current Flag Column: Not applicable for this table.
     • Effective Timestamp Column: SCD_effective_timestamp
     • End Timestamp Column: SCD_end_timestamp
     • Record Creation Timestamp Column: available_at

   

   ---

4. Complete registration by clicking .

For this specific table, all timestamp columns are already stored as proper timestamp values in UTC, so you do not need to provide a datetime format or time zone component.

What if timestamp columns are strings or stored in local time?

In some datasets, timestamp columns may be stored differently. If so:

• If the timestamp column is stored as a string, specify its string-based datetime format.
• If the timestamp is stored in local time, specify its time zone component.

Databricks cluster time zone settings

If you are using Databricks, keep in mind that FeatureByte retrieves timestamps exactly as they are stored, without adjusting for your Databricks cluster's time zone settings.

---

Step 8: Register the BUREAU table as an Event Table

1. Select the BUREAU table.

   ---

2. Click on .

3. Click on to get assistance:

   You should confirm or update the following fields:

   • Table type

     • Set Table Type to Event Table

   • Key and Timestamp columns

     • Event Timestamp Column: credit_update
     • Event ID Column: SK_ID_BUREAU
     • Record Creation Timestamp Column: available_at

   

   ---

4. Establish a Default Feature Job Setting, either automatically (if a Record Creation Timestamp Column is provided) or manually. We will set the job automatically by clicking .

   ---

5. Complete registration by clicking .

---

Step 9: Register the PREVIOUS_APPLICATION table as an Event Table

1. Select the PREVIOUS_APPLICATION table.

   ---

2. Click on .

3. Click on to get assistance:

   You should confirm or update the following fields:

   • Table type

     • Set Table Type to Event Table

   • Key and Timestamp columns

     • Event Timestamp Column: decision_update
     • Event ID Column: APPLICATION_ID
     • Record Creation Timestamp Column: available_at

   

   ---

4. Establish a Default Feature Job Setting, either automatically (if a Record Creation Timestamp Column is provided) or manually. We will set the job automatically by clicking .

   ---

5. Complete registration by clicking .

---

Step 10: Register the LOAN_STATUS table as a SCD Table

1. Select the LOAN_STATUS table.

   ---

2. Click on

3. Click on to get assistance:

   You should confirm or update the following fields:

   • Table type

     • Set Table Type to Slowly Changing Dimension (SCD) Table

   • Key and Timestamp columns

     • Natural Key Column: LOAN_ID
     • Surrogate Key Column: Not applicable for this table.
     • Current Flag Column: Not applicable for this table.
     • Effective Timestamp Column: SCD_Effective_Timestamp
     • End Timestamp Column: SCD_End_Timestamp
     • Record Creation Timestamp Column: available_at

   

   ---

4. Complete registration by clicking .

---

Step 11: Register the INSTALLMENTS_PAYMENTS table as an Event Table

1. Select the INSTALLMENTS_PAYMENTS table.

   ---

2. Click on .

3. Click on to get assistance:

   You should confirm or update the following fields:

   • Table type

     • Set Table Type to Event Table

   • Key and Timestamp columns

     • Event Timestamp Column: actual_installment_date
     • Event ID Column: INSTALLMENT_ID
     • Record Creation Timestamp Column: available_at

   

   ---

4. Establish a Default Feature Job Setting. We will set the job manually as a CRON job with a blind spot of 1 hour as follows:

   ---

5. Complete registration by clicking .

Why a CRON job?

CRON feature job enables monthly operations which are suitable for installments that are monthly events.

---

Step 12: Register the CREDIT_CARD_MONTHLY_BALANCE table as a Time Series Table

1. Select the CREDIT_CARD_MONTHLY_BALANCE table.

   ---

2. Click on

3. Click on to get assistance:

   You should confirm or update the following fields:

   • Table type

     • Set Table Type to Time Series Table

   • Key and Timestamp columns

     • Reference Datetime Column: balance_month
     • Reference Datetime Schema: YYYY-MMMM
     • Reference Datetime Time Zone Type: local_time
     • Reference Datetime Time Zone: America/Los Angeles instead of Pacific/Pago Pago
     • Series ID: CARD_ID
     • Time Interval: MONTH
     • Record Creation Timestamp Column: available_at

   

   ---

4. Establish a Default Feature Job Setting compatible with the series time interval and the series data availability. Here the 1st of each month at 1 PM in Los Angeles.

   ---

5. Complete registration by clicking .

What if a time zone column is used to assign individual time zones per record?

Specify the reference time zone. This should be the westernmost time zone among those specified in the column.

Westernmost Time Zone Example

Suppose you have a dataset with a user_time_zone column, where users are located in different time zones such as America/New_York, America/Chicago, and America/Los_Angeles. The reference time zone should be America/Los_Angeles, as it is the westernmost among them.

---

Step 13: Review Registered Tables

Verify the registration by checking the Table Catalog under the 'Explore' section. For some datasets, you may see sign that validation is pending as the validation run may take some time, in particular for SCD tables.