Student Data Store — SDS

Related Links

University Data Store (UDS)
Financial Data Store (FDS)
Human Resources Data Store (HRDS)
Research Data Store (RDS)

Data within the Student Data Store comes from Columbia's Student Information System (SIS), as well as other sources. SIS is an integrated mainframe computing system that includes admission, financial aid, registration, transcripts, billing, and housing functions for all schools and offices at the University.

In addition to the tables that replicate the SIS operational data, the Student Data Store (SDS) contains some tables derived from base SIS tables which carry details of all charges and payments to student accounts for each academic term. These details include transaction identifications, credit and debit account and subcode, charge or payment amounts, and financial department. Financial department information is added for cross referencing with other tables in the UDS. The SIS data is refreshed daily.

Data Source Details

Student Information System (SIS) Refresh Schedule

This table summarizes the various financial aid payments on behalf of a student for a particular academic term and financial aid fund.

Primary Key:

  • Department_Number
  • Award_Fund_Code
  • SIS_Identification_Number
  • Term_Identifier
  • Award_Year
  • School_Code

Data Warehouse Table Joins:

  • STUDENT_CHARGE_ITEM_SUMMARY

Extract Logic and Frequency:
Data on the FA_DISBURSEMENT_SUMMARY table is extracted from the following tables in the SIS database in the University Data Warehouse:

  • TDET_STUDENT_TRAN_DETAIL
  • MONY_FINANCIAL_AID_FUND

Payment amounts which represent award funds (Award_Fund_Code) are accumulated within unique combinations of:

  • SIS_Identification_Number
  • Term_IdentifierFiscal_Year
  • Award_YearSchool_Code
  • Award_Fund_Code
  • Account_Number
  • Account_Subcode
  • Department_Number

Each row on FA_DISBURSEMENT_SUMMARY is created by the above summarization process. The table is recreated at the beginning of each calendar month.

This table summarizes the various charges to a student for a particular academic term.

Primary Key:

  • Department_Number
  • SIS_Identification_Number
  • Term_Calendar_Year
  • Term_CodeCharge_Code

Data Warehouse Table Joins:

  • SL_ACCOUNT_DOLLARSL_ACCOUNT_DESCRIPTION

Extract Logic and Frequency:
Data on the STUDENT_CHARGE_ITEM_SUMMARY table is extracted from the following tables in the SIS database in the University Data Warehouse and is customized by department or school:

  • TDET_STUDENT_TRAN_DETAIL
  • CHRG_CHARGE_CODE
  • BTYP_BALANCE_TYPE

Transaction amounts which represent charges (Charge Code) are accumulated within unique combinations of:

  • SIS_Identification_Number
  • Term_Identifier
  • Charge_Code
  • Balance_Type_Code
  • Account_Number
  • Account_Subcode
  • Department_Number

Each row on the STUDENT_CHARGE_ITEM_SUMMARY tables is created by the above summarization process. The tables are recreated at the beginning of each calendar month.

SIS Report Inventory

Source Application: Data Warehouse

Tables

DIN_STUDENT_CHARGE_SUMMARY


Charge code, charge type name, balance type code, balance type name, account number and account subcode (limited to dept 880 only).

* Also separately indexed

FA_DISBURSEMENT_SUMMARY


List SIS identification number, award fund code, award fund description, net payment amount, account number and account subcode.

* Also separately indexed

SPH_STUDENT_CHARGE_SUMMARY


Same as Din_Student_Chg_Item_Summary but limited to department 588 only.

* Also separately indexed

SDS Job Aids and Tools

CUIT follows an industry-standard Software Development Life Cycle (SDLC) to guide the process of application systems development. To aid us in this process the following design documents must be submitted by functional owners when requesting development work.

  • High Level Design Document (HLDD) form to be completed by functional owners and reviewed with Systems Development team for completeness.  The Development Manager provides an initial estimate of work effort. Functional owners will create an infoline request to track progress. 
  • Detail Design Document - Reporting form to be completed by functional owners when requesting new and/or enhancements to reports.