Penn Computing

University of Pennsylvania
Penn Computing << go backback
KNODE Table   Tables and Data Elements   Learning Management Home   Data Warehouse Home

KNODE - Data Element Index

Select a data element to view its definition and its indexed, format, and null values.

 

Data element Definition
ADDRESS_1

Indexed - no
Format - varchar2 (80)
May be null? yes

This data element currently is not used.

ADDRESS_2

Indexed - no
Format - varchar2 (30)
May be null? yes

This data element currently is not used.

AUTH_CODE

Indexed - no
Format - varchar2 (20)
May be null? yes

This data element currently is not used.

CITY

Indexed - no
Format - varchar2 (20)
May be null? yes

This data element currently is not used.

CLASSIFICATION

Indexed - no
Format - number (10)
May be null? yes

This data element currently is not used.

COUNTRY

Indexed - no
Format - varchar2 (30)
May be null? yes

This data element currently is not used.

CUSTOM_N1

Indexed - no
Format - varchar2 (20)
May be null? yes

The Penn ID of the University of Pennsylvania Health System (UPHS) manager, the person responsible for the UPHS department identified by the KNODE_ID. (Also known as a cost center or accounting unit, a department is a subdivision of a UPHS entity or process level.) See also CUSTOM_V3. Further information on the manager is available in the LMS_PERSON table.

The manager is authorized to use Knowledge Link to run the Entity Administrator Report, which provides information on the compliancy of courses for UPHS departments, and the users within those departments. See also CUSTOM_N2 & CUSTOM_V4, CUSTOM_N3, and CUSTOM_N4.

CUSTOM_N1 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

A Penn ID is an 8-digit identification number assigned to an individual by the Penn
Community system. No two persons have the same Penn ID.

Example: 10107547

Values:
List of values not available
CUSTOM_N2

Indexed - no
Format - varchar2 (20)
May be null? yes

The Penn ID of the University of Pennsylvania Health System (UPHS) administrator, who oversees the manager (CUSTOM_N1 & CUSTOM_V3). See also CUSTOM_V4. Further information on the administrator is available in the LMS_PERSON table.

The administrator is authorized to use Knowledge Link to run the Entity Administrator Report, which provides information on the compliancy of courses for UPHS departments, and the users within those departments. See also CUSTOM_N1 & CUSTOM_V3, CUSTOM_N3, and CUSTOM_N4.

CUSTOM_N2 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

A Penn ID is an 8-digit identification number assigned to an individual by the Penn
Community system. No two persons have the same Penn ID.

Example: 10226126

Values:
List of values not available
CUSTOM_N3

Indexed - no
Format - varchar2 (20)
May be null? yes

The Penn ID of one of the two University of Pennsylvania Health System employees who, as the proxy of the manager (CUSTOM_N1 & CUSTOM_V3), can use Knowledge Link to run the Entity Administrator Report. This report provides information on the compliancy of courses for UPHS departments, and the users within those departments. See also CUSTOM_N1 & CUSTOM_V3, CUSTOM_N2 & CUSTOM_V4, and CUSTOM_N4.

Information on the person identified in CUSTOM_N3 is available in the LMS_PERSON table.

CUSTOM_N3 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

Example: 10225505

Values:
List of values not available
CUSTOM_N4

Indexed - no
Format - varchar2 (20)
May be null? yes

The Penn ID of one of the two University of Pennsylvania Health System employees who, as the proxy of the manager (CUSTOM_N1 & CUSTOM_V3), can use Knowledge Link to run the Entity Administrator Report. This report provides information on the compliancy of courses for UPHS departments, and the users within those departments. See also CUSTOM_N1 & CUSTOM_V3, CUSTOM_N2 & CUSTOM_V4, and CUSTOM_N3.

Information on the person identified in CUSTOM_N4 is available in the LMS_PERSON table.

CUSTOM_N4 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

Example: 10093894

Values:
List of values not available
CUSTOM_N5

Indexed - no
Format - varchar2 (20)
May be null? yes

The transaction ID number for the record in the XML feed from the University of Pennsylvania Health System (UPHS) that created this KNODE record.

CUSTOM_N5 is used for UPHS business units, but its value is null for University business units.

Example: 3149937

Values:
List of values not available
CUSTOM_V1

Indexed - no
Format - varchar2 (250)
May be null? yes

Text used in Knowledge Link's Entity Administrator Report, which provides information on the compliancy of courses for UPHS departments, and the users within those departments. The value of CUSTOM_V1 (if it is not null) is 'Cost Center' (without the quotes).

CUSTOM_V1 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

Value:
Cost Center
CUSTOM_V2

Indexed - no
Format - varchar2 (250)
May be null? yes

The name of the University of Pennsylvania Health System (UPHS) entity, in mixed case. Also known as a process level, an entity is a division of UPHS that addresses one of the Health System's various areas and levels of service, support and practices. Entities consist of departments (also known as cost centers or accounting units).

CUSTOM_V2 is used for UPHS business units, but its value is null for University business units.

Values:
CCA   (Clinical Care Associates)
CCNJ (Clinical Care Associates - New Jersey) CNTRT (Contractors) CORP (Corporate Services) CPUP (Clinical Practices of the University of Pennsylvania) CRDTA (PAH credentialed non 2000 employees) CRDTC (CCA credentialed non 2000 employees) CRDTL (HUP credentialed non 2000 employees) CRDTP (PMC credentialed non 2000 employees) DAHR Rollup HCHS (Penn Home Care and Hospice Services) HUP (Hospital of the University of Pennsylvania) JRB (John Rhea Barton Practice) MGMT (Management Staff) PAH (Pennsylvania Hospital) PAHHM (Pennsylvania Hospital - Hall Mercer Community Mental Health) PMC (Presbyterian Medical Center) SCON (UPHS System Confidential) UPHS (University of Pennsylvania Health System) URSVC (Urology Associates) WISS (Wissahickon Hospice)
CUSTOM_V3

Indexed - no
Format - varchar2 (250)
May be null? yes

The name of the University of Pennsylvania Health System (UPHS) manager, in mixed case. The manager is the person responsible for the UPHS department identified by the KNODE_ID. (Also known as a cost center or accounting unit, a department is a subdivision of a UPHS entity or process level.). See also CUSTOM_N1. Further information on the manager is available in the LMS_PERSON table.

The manager is authorized to use Knowledge Link to run the Entity Administrator Report, which provides information on the compliancy of courses for UPHS departments, and the users within those departments. See also CUSTOM_N2 & CUSTOM_V4, CUSTOM_N3, and CUSTOM_N4.

CUSTOM_V3 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

Example: Rich, Victoria

Values:
List of values not available
CUSTOM_V4

Indexed - no
Format - varchar2 (250)
May be null? yes

The name of the University of Pennsylvania Health System (UPHS) administrator, in mixed case. The administrator oversees the manager (CUSTOM_N1; CUSTOM_V3). See also CUSTOM_N2. Further information on the administrator is available in the LMS_PERSON table.

The administrator is authorized to use Knowledge Link to run the Entity Administrator Report, which provides information on the compliancy of courses for UPHS departments, and the users within those departments. See also CUSTOM_N1 & CUSTOM_V3, CUSTOM_N3, and CUSTOM_N4.

CUSTOM_V4 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

Example: Piesieski, Patricia

Values:
List of values not available
CUSTOM_V5

Indexed - no
Format - varchar2 (250)
May be null? yes

The name of the University of Pennsylvania Health System (UPHS) department, in mixed case. Also known as a cost center or accounting unit, a department is a subdivision of a UPHS entity or process level. See also CUSTOM_V2.

CUSTOM_V5 is used for business units that correspond to UPHS departments. Its value is null for other UPHS business units, and for all University business units.

Example: Nursing Silverstein 7

Values:
List of values not available

DATE_CREATED

Indexed - no
Format - date
May be null? yes

The date when the KNODE record was created in Knowledge Link.

Example: 10/24/2006

Values:
List of values not available
DATE_MODIFIED

Indexed - no
Format - date
May be null? yes

The date when the KNODE record was last updated in Knowledge Link.

Example: 11/13/2007

Values:
List of values not available
DESCRIPTION

Indexed - no
Format - varchar2 (350)
May be null? yes

This data element currently is not used.

DISCOUNT

Indexed - no
Format - number (5,2)
May be null? yes

This data element currently is not used.

ECOMM_RULE

Indexed - no
Format - number (10)
May be null? yes

This data element currently is not used.

EMAIL

Indexed - no
Format - varchar2 (80)
May be null? yes

This data element currently is not used.

ENFORCEMENT

Indexed - no
Format - number (1)
May be null? yes

This data element currently is not used.

FAX

Indexed - no
Format - varchar2 (30)
May be null? yes

This data element currently is not used.

FED_FAC_CODE

Indexed - no
Format - varchar2 (20)
May be null? yes

This data element currently is not used.

IDENTIFIER

Indexed - yes
Format - varchar2 (250)
May be null? yes

A string that uniquely identifies the business unit to Knowledge Link users. See also KNODE_ID and NAME.

The IDENTIFIER may include letters and/or numerals and/or other characters. The letters in IDENTIFIER may be in upper case, lower case, or mixed case. The IDENTIFIER for a University of Pennsylvania Health System (UPHS) business unit begins with HS; for a University or auxiliary business unit, it begins with UP. (Auxiliary members of the Penn Community are persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation.) One of the qualifiers in an IDENTIFIER may be the Penn ID, which is an 8-digit identification number assigned to an individual by the Penn Community system. No two persons have the same Penn ID.

The KNODE table has one record per business unit. A business unit (also known as a BU, role, Knowledge Node, or K Node) is a set of one or more Knowledge Link users. Most business units correspond to bureaucratic groups that reflect various administrative subdivisions used for University of Pennsylvania Health System (UPHS) employees, University employees, University students, and auxiliary members of the Penn Community. Some business units denote privileged groups, used to classify certain Knowledge Link users according to what they are authorized to do within the Knowledge Link system.

Most IDENTIFIER values are determined in the manner described below. Generally speaking, the further down the business unit is in the hierarchy, the more qualifiers its IDENTIFIER has. (For more information on the business unit hierarchy, see PARENT_ID and TYPE.)

University business units

  • org.: UP.org. code
    • example: UP.9937
    • For information on orgs., see the General Ledger data collection's documentation on the ORG_CODES table.
    • A University employee with a FAC or STAF affiliation in the Penn Community is included in the business unit for his or her home org., which is the org. responsible for maintaining his or her record in the Payroll system.
  • individual employee with a FAC or STAF affiliation in the Penn Community: UP.Penn ID
    • example: UP.12345678
    • For information on University employees, see the Salary Management data collection's documentation on EMPLOYEE_GENERAL.
  • academic division and major: UP.division.major
    • examples: UP.NUG, UP.NUG.PERI
    • Note: if an org. exists for an academic division or major, the KNODE table will have separate records for the org. and for the academic division or major.
    • Knowledge Link users and courses are not assigned to the business units created for academic divisions and majors. These business units are used as the basis for creating the business units for students.
    • For information on academic divisions and majors, see the Student data collection's documentation on the DIVISION and MAJOR tables (updated nightly)
  • group of students: UP.STU-.academic division.major
    • examples: UP.STU-.NUG, UP.STU-.NUG.ACNP
    • A student is included in a business unit for a group of students based on his or her primary academic division and primary major, per the SRS_DIVISION and SRS_MAJOR in the record for the student in the Penn Community AFFILIATION table.
  • individual student: UP.Penn ID.STU
    • example: UP.23456789.STU
    • For information on students, see the Student data collection's documentation on the PERSON table (updated nightly).

UPHS business units

  • entity: HS.entity
    • example: HS.CRDTA
    • Entities are also known as process levels.
  • department: HS.entity.department
    • example: HS.CRDTA.SUORA
    • Departments are also known as a cost centers or accounting units.
  • departmental trainee group: HS.entity.department.jobclass
    • example: HS.CRDTA.SUORA.A62
  • Knowledge Microcommunity: HS.microcommunity abbreviation
    • example: HS.PATREG
    • A Knowledge Microcommunity is a business unit that was created to allow courses to be assigned to Knowledge Link users from unrelated UPHS departments. (See TYPE.)
  • individual nurse: HS.RN.entity.Penn ID
    • example: HS.RN.HUP.34567890
    • UPHS has created a business unit for each of its nurses, but not for each of its other employees.

Auxiliary business units

  • group of auxiliary Penn Community members: UP.AUX-.affiliation abbreviation
  • individual auxiliary Penn Community member: UP.Penn ID.AUX
    • example: UP.34567890.AUX
    • For information on auxiliary members, see the documentation on the Penn Community MEMBER table.
Values:
Refer to the KNODE table for values.
KNODE_ID

Indexed - yes
Format - number (10)
May be null? no

A number used to uniquely identify the KNODE record within the Knowledge Link system. See also IDENTIFIER and NAME.

The KNODE table has one record per business unit. A business unit (also known as a BU, role, Knowledge Node, or K Node) is a set of one or more Knowledge Link users. Most business units correspond to bureaucratic groups that reflect various administrative subdivisions used for University of Pennsylvania Health System (UPHS) employees, University employees, University students, and auxiliary members of the Penn Community (persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation). Some business units denote privileged groups, used to classify certain Knowledge Link users according to what they are authorized to do within the Knowledge Link system. See also the KNODE_CRS_JOIN table and the KNODE_USER_JOIN table.

Example: 21073

Values:
Refer to the KNODE table for values.
MAIL_STOP

Indexed - no
Format - varchar2 (20)
May be null? yes

This data element currently is not used.

MIN_DISCOUNT

Indexed - no
Format - number (10)
May be null? yes

This data element currently is not used.

MIN_PURCHASE

Indexed - no
Format - number (10)
May be null? yes

This data element currently is not used.

NAME

Indexed - yes
Format - varchar2 (250)
May be null? no

A phrase or string that describes the business unit. It is possible for more than one business unit to have the same value for NAME. The NAME may include letters and/or numerals and/or other characters. The letters in NAME may be in upper case, lower case, or mixed case. One of the qualifiers in a NAME may be the Penn Key, which is a unique name (attributable to a single individual) that serves as the Kerberos Principal and as a user name (logon ID) for the individual in various Penn systems (such as e-mail).

The KNODE table has one record per business unit. (See KNODE_ID and IDENTIFIER.) A business unit (also known as a BU, role, Knowledge Node, or K Node) is a set of one or more Knowledge Link users. Most business units correspond to bureaucratic groups that reflect various administrative subdivisions used for University of Pennsylvania Health System (UPHS) employees, University employees, University students, and auxiliary members of the Penn Community (persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation). Some business units denote privileged groups, used to classify certain Knowledge Link users according to what they are authorized to do within the Knowledge Link system. See also the KNODE_CRS_JOIN table and the KNODE_USER_JOIN table.

Most NAME values are determined in the manner described below.

University business units

  • org.: the name of the org. (see ORG_CODES.DESCRIPTION), truncated at 50 characters
    • example: Journal of Biochemistry and Molecular Biology Educ
    • For information on orgs., see the General Ledger data collection's documentation on the ORG_CODES table.
  • individual employee with a FAC or STAF affiliation in the Penn Community: UP.Penn Key.name of home org.primary job appointment title, truncated at 50 characters
    • example: UP.franklin.DM-Sleep Medicine.RESEARCH INVESTIGATO
    • A University employee with a FAC or STAF affiliation in the Penn Community is included in the business unit for his or her home org., which is the org. responsible for maintaining his or her record in the Payroll system. Information on the primary job appointment and other information on University employees is available in the Salary Management data collection's documentation on EMPLOYEE_GENERAL.
  • academic division and major: UP.division.major
    • examples: UP.NUG, UP.NUG.PERI
    • Note: if an org. exists for an academic division or major, the KNODE table will have separate records for the org. and for the academic division or major.
    • Knowledge Link users and courses are not assigned to the business units created for academic divisions and majors. These business units are used as the basis for creating the business units for students.
    • For information on academic divisions and majors, see the Student data collection's documentation on the DIVISION and MAJOR tables (updated nightly).
  • group of students: UP.STU-.academic division.major
    • examples: UP.STU-.NUG, UP.STU-.NUG.ACNP
    • A student is placed in a group based on his or her primary academic division and primary major, per the SRS_DIVISION and SRS_MAJOR in the record for the student in the Penn Community AFFILIATION table.
  • individual student: UP.Penn Key.division.major
    • example: UP.janetdoe.NUG.ACNP
    • For information on students, see the Student data collection's documentation on the PERSON table (updated nightly).

UPHS business units

  • entity: HS.entity
    • example: HS.CRDTA
    • Entities are also known as process levels.
  • department: HS.entity.department name
    • example: HS.CRDTA.PAH Surgery - Orthopaedics [SUORA]
    • Departments are also known as a cost centers or accounting units.
  • departmental trainee group: Learner: department name: .jobclass (entity)
    • example: Learner: PAH Surgery - Orthopaedics: A62 (CRDTA)
  • Knowledge Microcommunity: microcommunity name
    • example: Patient Registration
    • A Knowledge Microcommunity is a business unit that was created to allow courses to be assigned to Knowledge Link users from unrelated UPHS departments. (See TYPE.)
  • individual nurse: Nurse: Lastname, Firstname (department name)
    • example: Nurse: Nightingale, Florence (Nursing Rehab)
    • UPHS has created a business unit for each of its nurses, but not for each of its other employees.

Auxiliary business units

  • group of auxiliary Penn Community members: UP.AUX-.affiliation description
  • individual auxiliary Penn Community member: UP.Penn Key.affiliation description
    • example: UP.mcurie.Wistar Faculty
    • For information on auxiliary members, see the documentation on the Penn Community MEMBER table.
Values:
List of values not available
PARENT_ID

Indexed - yes
Format - number (10)
May be null? yes

A number that uniquely identifies the business unit that is one step up in the hierarchy from the business unit identified by the KNODE_ID. For example, if the record for KNODE_ID 45131 (UP.9145, Computer Operations) has PARENT_ID 146979, the KNODE record for the parent has KNODE_ID 146979 (UP.SEOG, Systems Engineering & Operations Group Parent). See also the LMS_BUSINESS_UNIT_GROUP table.

A business unit (also known as a BU, role, Knowledge Node, or K Node) is a set of one or more Knowledge Link users. Most business units correspond to bureaucratic groups that reflect various administrative subdivisions used for University of Pennsylvania Health System (UPHS) employees, University employees, University students, and auxiliary members of the Penn Community (persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation). Some business units denote privileged groups, used to classify certain Knowledge Link users according to what they are authorized to do within the Knowledge Link system.

Business unit X includes a person if that person is actively assigned to X (see the KNODE_USER_JOIN table) or to a business unit that that falls below X in the business unit hierarchy. That hierarchy is based on the hierarchies of the administrative groupings in the source systems, and is described briefly below. See also TYPE.

University business units

  • Business units for University orgs. follow the University's org. hierarchy. A business unit for a University employee with a FAC or STAF affiliation in the Penn Community has as its parent the business unit for the employee's home org. (The home org. is the organization that owns the employee's record and is responsible for its maintenance in the payroll system.)
    • For information on orgs., see the General Ledger data collection's documentation on the ORG_CODES table; the documentation on its PARENT_ORG_CODE data element describes the org. hierarchy. For information on University employees, see the Salary Management data collection's documentation on EMPLOYEE_GENERAL.
  • The business unit for a University major has as its parent the business unit for the University academic division that offers the major.
    • For information on academic divisions and majors, see the Student data collection's documentation on the DIVISION and MAJOR tables (updated nightly).
  • The business unit hierarchy for University students parallels the hierarchy for the academic divisions and majors. A business unit for a University student has as its parent the UP.STU- business unit for the student's primary major in his or her primary academic division, per the SRS_DIVISION and SRS_MAJOR in the record for the student in the Penn Community AFFILIATION table.

UPHS business units

  • Most Health System business units use the same hierarchy as for the UPHS entities (also known as process levels) and departments (also known as a cost centers or accounting units).
  • The UPHS branch of the business unit hierarchy has a separate sub-branch for Knowledge Microcommunities. (See also TYPE.)
  • A UPHS nurse is assigned both to a business unit in the entity/department hierarchy and to a business unit in a separate sub-branch for the Nursing Community.

Auxiliary business units

  • A business unit has been created for each auxiliary Penn Community affiliation. The business unit for a Knowledge Link user with an auxiliary affiliation has as its parent the UP.AUX- business unit for the user's auxiliary Penn Community affiliation (per the Penn Community AFFILIATION table).

Example: 44317

Values:
List of values not available
PHONE

Indexed - no
Format - varchar2 (30)
May be null? yes

This data element currently is not used.

STATE

Indexed - no
Format - varchar2 (20)
May be null? yes

This data element currently is not used.

STATUS

Indexed - no
Format - number (1)
May be null? yes

A numeral indicating whether the business unit is active or inactive. See also TYPE.

A business unit must be active if a record is to be created to assign a Knowledge Link user or course to the business unit. (See the KNODE_USER_JOIN and KNODE_CRS_JOIN tables.) Also, a business unit must be active if a record is to be created or updated to name the business unit as the owner of a course version or package. (See the COURSE_OBJECT, LMS_COURSE_MASTER, and PKG tables.) Once a business unit has been named as the owner of a course version or package, it retains ownership even if it becomes inactive.

A business unit (also known as a BU, role, Knowledge Node, or K Node) is a set of one or more Knowledge Link users. Most business units correspond to bureaucratic groups that reflect various administrative subdivisions used for University of Pennsylvania Health System (UPHS) employees, University employees, University students, and auxiliary members of the Penn Community (persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation). Some business units denote privileged groups, used to classify certain Knowledge Link users according to what they are authorized to do within the Knowledge Link system. You can identify a business unit by its KNODE_ID or IDENTIFIER.

Values:
0 (the business unit is inactive)
1 (the business unit is active)
STYLE_PATH

Indexed - no
Format - varchar2 (80)
May be null? yes

This data element currently is not used.

SVC_CHARGE

Indexed - no
Format - number (10)
May be null? yes

This data element currently is not used.

TRAINING_BAL

Indexed - no
Format - number (10,2)
May be null? yes

This data element currently is not used.

TYPE

Indexed - yes
Format - number (10)
May be null? yes

A number that uniquely identifies the business unit type, which determines whether and how Knowledge Link users and courses can be assigned to the business unit. (See also STATUS.)

To display the description of the business unit type (rather than its numeric identifier), use the LMS_BUSINESS_UNIT_TYPE table.

A business unit (also known as a BU, role, Knowledge Node, or K Node) is a set of one or more Knowledge Link users. Most business units correspond to bureaucratic groups that reflect various administrative subdivisions used for University of Pennsylvania Health System (UPHS) employees, University employees, University students, and auxiliary members of the Penn Community (persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation). Some business units denote privileged groups, used to classify certain Knowledge Link users according to what they are authorized to do within the Knowledge Link system. You can identify a business unit by its KNODE_ID or IDENTIFIER.

There are three types of business units:

  • Knowledge Position (KP)
    • A Knowledge Link user can be assigned to it directly. That is, the KNODE_USER_JOIN record cites the KP.
    • A course can be assigned to it either directly (where the KNODE_CRS_JOIN record cites the KP) or indirectly (where the KNODE_CRS_JOIN record cites a Knowledge Community or Knowledge Microcommunity that is above the KP in the business unit hierarchy).
  • Knowledge Community (KC)--a group of KPs, corresponding to a University org., academic division, or major; to a University of Pennsylvania Health System (UPHS) entity (process level) or department (cost center or accounting unit); or to an auxiliary Penn Community affiliation. (Auxiliary members of the Penn Community are persons whose training records and current training assignments are stored in Knowledge Link, but who are not UPHS employees or persons with a FAC, STAF, or STU affiliation.)
    • A Knowledge Link user cannot be assigned to a KC directly. A KC includes a user if the user has a KNODE_USER_JOIN record that cites a KP that is below the KC in the business unit hierarchy.
    • A course may be assigned to a KC either directly (where the KNODE_CRS_JOIN record cites the KC indirectly (where the KNODE_CRS_JOIN record cites a BU that is above the KC in the business unit hierarchy).
  • Knowledge Microcommunity (KMC)--a group of KPs that was created to allow courses to be assigned to Knowledge Link users from unrelated UPHS departments (also known as cost centers or accounting units)
    • A Knowledge Link user cannot be assigned to a KMC directly. A KMC includes a user if the user has a KNODE_USER_JOIN record that cites a KP that is below the KMC in the business unit hierarchy.
    • A course may be assigned to a KMC directly (where the KNODE_CRS_JOIN record cites the KMC). A course may not be assigned to a KMC indirectly. That is, if the KNODE_CRS_JOIN record cites a BU that is above the KMC in the business unit hierarchy, the KMC does not have the course assigned to it.

For information on the business unit hierarchy, see PARENT_ID.

Values:
158 (Knowledge Community)

159 (Knowledge Microcommunity)

160 (Knowledge Position)
ZIP

Indexed - no
Format - varchar2 (20)
May be null? yes

This data element currently is not used.

 

KNODE Table   Tables and Data Elements  Learning Management Home   Data Warehouse Home

Questions about this page? Email us at da-staff@isc.upenn.edu

Information Systems and Computing
University of Pennsylvania
Information Systems and Computing, University of Pennsylvania