Dict-Physical

Table MD_Application

Card of table MD_Application

Name	MD_Application
Dimensional Type	Dimension
Comment	Information on student applications. Note that typically application status information is identical to the prospective student status information. Sometimes, though, it differs, e.g., when students submit multiple applications or get accepted, then defer admission. Some of the differences here depend on consistent data entry by Admissions. Since our practices have varied over time, the numbers are not entirely reliable. Yield stats typically go by application, not by student. Headcount stats ("Who will be arriving in the fall?") go by student.

Check constraint name of the table MD_Application

CKT_MD_APPLICATION

List of incoming references of the table MD_Application

Relationship_90

MF_Yield

MD_App_SurrogateKey

List of referencing views of the table MD_Application

VMD_Application

VMD_APPLICATION

List of diagrams containing the table MD_Application

DimsOtherDiagrams

List of columns of the table MD_Application

MD_App_SurrogateKey

<None>

numeric

MD_App_AppRPlusPKID

Unique identifier for application (different from that of student).

DW_RecruitmentPlusPKID

int

MD_App_StudentRPlusPKID

Unique identifier for student (different from that of the application).

Note that this attribute is not a business key for MD_Application, and it should not be used for joins, since an application might be submitted then later reassigned to (or deleted and recreated for) a new student with a different ID, e.g., as a result of a merge/de-duplication. Such operations can leave "orphaned" student identifiers as well as orphaned applications (which no longer exist in the system of record).

We do not delete orphaned applications from this attribute's dimension table, because orphaned applications will automatically be ignored when used in conjunction with any fact table, because nothing in the fact table will join to the orphaned application.

DW_RecruitmentPlusPKID

int

MD_App_StatusCategory

Generalized/broader version of applicationt status. Coalesces detailed application states into broader categories. E.g., applications that are complete, or that have triggered a waitlist response, etc. are all listed as 'applied.'

DW_CodeDesc

varchar(32)

MD_App_Status

Detailed application status. Cf. MD_App_StatusCategory (which is more general, and typically more useful).

DW_CodeDescLong

varchar(64)

MD_App_RequirementRule

Specifies what set of requirements are applied to the application. Example values: Regular Decision, Transfer, Winter Early Decision.

DW_CodeDesc

varchar(32)

MD_App_EntryTerm

Projected term for which a student is applying for entrance (typically, but not always a fall term), in a given application.

DW_TermShortName

char(7)

MD_App_EntryTermYear

Projected year for which a student is applying for entrance, in a given application. Students may, naturally, end up submitting multiple apps (e.g., one for regular admission as a freshman, then another for admission as a transfer student a year or two later).

DW_YearAtCarleton

int

MD_App_AdmitCondition

This field is used, at Carleton (as of 2011) to tell us how an application came into the system. Typical values are either "RW-Carleton App Web" or "CM-Common App Mail."

DW_CodeDesc

varchar(32)

MD_App_IsPrimaryApp

If a student submits multiple applications for the same entry term (often this happens by accident), we designate one or another as the primary.

DW_YesOrNoNOTNULL

char(3)

MD_App_InsDate

Integer representing date of first insertion, i.e., the application's initial entry into our systems.

DW_DateInteger

int

MD_App_AuditKey

DW_AuditKey