KNODE_USER_JOIN
Table
DWLMS Schema
Explanation
Tracks
current information on business units and the Knowledge Link users that were
assigned to them on or after November 15, 2004.
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 (members 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. There
is one KNODE_USER_JOIN record per combination of business unit (KNODE_ID)
and user (USER_REC_ID).
Common Uses
- Listing the users that belong to
specified business units.
- Listing the business units to which specified users belong.
| Primary Key |
Indexed Data Elements |
Related Tables |
KNODE_ID
USER_REC_ID
|
KNODE_ID
USER_REC_ID
|
COURSE_ITERATION
COURSE_OBJECT
CUSTOM_DATA
GEN21_USER
KNODE
KNODE_CRS_JOIN
LMS_BUSINESS_UNIT_GROUP
LMS_COURSE_ITER_INSTRUCTOR
LMS_CURRENT_CRS_ITER_REG_INSTR
LMS_CURRENT_TRAINEE_CRS_STATUS
LMS_CURR_TRNEE_CRS_STAT_MV
LMS_PERSON
LMS_REGISTRATION
LMS_STAFF_QUAL
LMS_TRAINEE_BU_COURSE_ASSIGN
LMS_TRAINEE_COURSE_ASSIGN
PKG
REGISTRATION
UPHS_COST_CENTER
UPHS_USER_ENTITY
USER_COURSES |
Cautions
- The KNODE_USER_JOIN table stores only the current information for
a business unit/user combination. Historical
information is not available.
For example,
if Knowledge Link user U was actively assigned to business unit B two
years ago, had the assignment set to inactive last year, but had the assignment
re-set
to
active this year, there is no way
to
tell
from
the
KNODE_USER_JOIN
table
that
the assignment was ever inactive.
- The KNODE_USER_JOIN table has information on business units and the Knowledge
Link users assigned to them.
- A business unit (KNODE_ID) may have zero, one, or more users assigned
to it. Only business units that are Knowledge Positions can have users
assigned to them. (Information on the business
unit is available in the KNODE table. For an explanation of what a Knowledge
Position is, see the LMS_BUSINESS_UNIT_TYPE table.)
- A user (USER_REC_ID) may be assigned to one or more business
units. For example, a student that is also a University employee with
a FAC or STAF affiliation in the Penn Community will have
two KNODE_USER_JOIN records.
A University of Pennsylvania Health System (UPHS) employee that is also
part of a UPHS Knowledge Microcommunity will have
two KNODE_USER_JOIN records. (Information on the
user is
available in the LMS_PERSON table. For an explanation of what a Knowledge
Microcommunity is, see the LMS_BUSINESS_UNIT_TYPE table.)
- While a KNODE_USER_JOIN record specifies the user and a business unit
to which the user is assigned, the user is included in
that business unit and in the business units that are above it in the
business unit hierarchy. (For more information on the business unit hierarchy,
see PARENT_ID and
TYPE in the KNODE table.)
- STATUS indicates whether the user's assignment to the business
unit is active. A Knowledge Link user may register for a
course only if the course is assigned to a business unit that currently includes
the
user.
If a
course
is assigned to a business unit, a user is included
in that business unit
if
he or she has a KNODE_USER_JOIN record that has STATUS = 1, and that has
the KNODE_ID of the business unit itself or of a business unit that is below
it in the hierarchy. (If the user's assignment to the business
unit is inactive, STATUS = 0
(zero).)
- If the KNODE_USER_JOIN record is inactive, the EXPIRATION_DATE
is the date when it became inactive. EXPIRATION_DATE should be used in
reports only if the KNODE_USER_JOIN record is inactive. An active record
might or
might not have a non-null
value for EXPIRATION_DATE if the record was inactive in the past.
- In some cases, when a mandatory course is assigned to a business unit, not
all of the trainees included in that business unit are required to take the
course; some are "grandfathered". One of the things that may qualify
trainees to be grandfathered is their TRANSFER_TYPE.
- For example, say a mandatory course assignment is created that specifies
course C, course version CV, and business unit B1. John Doe has an active
assignment to business unit B2, which falls under B1 in the business
unit hierarchy, so he is included in the mandatory course assignment.
John is grandfathered for this mandatory course assignment if his TRANSFER_TYPE
for B2 is grandfathered per the GRANDFATHERING_VALUE for CV. John is
grandfathered for course C if he is grandfathered for all of the mandatory
course assignments for C that include him. For more information on grandfathering,
see the Cautions for the COURSE_OBJECT table on GRANDFATHERING_VALUE.
- Note: currently, the TRANSFER_TYPE is stored for trainees who are
University of Pennsylvania Health System (UPHS) employees, but not
for other trainees.
Source
Knowledge Link, the learning management system used by the University and
by the University of Pennsylvania Health System (UPHS) since March, 2005.
Knowledge Link enables authorized administrators to schedule training
courses, assign resources to courses, assign groups of Knowledge Link users
to courses, and to create online courses. It enables trainees to find out what
courses
have been assigned to them, to register for those courses (whether those courses
are on-line or instructor-led), to take on-line courses, and to provide feedback
via course evaluations. Knowledge Link was first used to track information
on training required by regulation, but it now tracks information on a variety
of training
courses.
Questions about this page? Email us at da-staff@isc.upenn.edu
|
