Penn Computing

University of Pennsylvania
Penn Computing << go backback
LMS_BUSINESS_UNIT_GROUP Table - Data Element Index    Tables and Data Elements   Learning Management Home   Data Warehouse Home

LMS_BUSINESS_UNIT_GROUP Table

DWLMS Schema

Explanation
Reference table with current data on business unit groups and their business unit members. 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. Business units are arranged in a hierarchy. (See BUSINESS_UNIT_GROUP_NUMBER and BUSINESS_UNIT_GROUP_TYPE_DESC.) The members of business unit group X are business unit X itself and all of the business units that fall below it in the hierarchy. The LMS_BUSINESS_UNIT_GROUP table has one record per combination of business unit group and business unit member. You can identify a business unit group by its BUSINESS_UNIT_GROUP_NUMBER or BUSINESS_UNIT_GROUP_ID. You can identify a business unit member by its BUSINESS_UNIT_MEMBER_NUMBER or BUSINESS_UNIT_MEMBER_ID.

In addition to identifying a business unit group/business unit member combination, each LMS_BUSINESS_UNIT_GROUP record stores other information on the business unit group and the business unit member, including descriptive information (such as the unique identifiers for the business unit and its name), information on whether and how Knowledge Link users and courses can be assigned to the business unit, and information specific to the University of Pennsylvania Health System (UPHS) business units. Status-related information is provided for the business unit group only.

Common Uses

  • Joining the business unit member in LMS_BUSINESS_UNIT_GROUP to a business unit in another table, so that a report can be created for a specified business unit group.
  • Listing the business units that are members of a specified business unit group.
  • Listing the business unit groups to which a specified business unit group belongs.
Primary Key Indexed Data Elements Related Tables
BUSINESS_UNIT_GROUP_NUMBER
BUSINESS_UNIT_MEMBER_NUMBER
BU_GROUP_UPHS_ADMIN_PENNID
BU_GROUP_UPHS_ADMINISTRATOR
BU_GROUP_UPHS_COST_CENTER
BU_GROUP_UPHS_DEPT_NAME
BU_GROUP_UPHS_ENTITY
BU_GROUP_UPHS_MANAGER
BU_GROUP_UPHS_MANAGER_PENN_ID
BU_GROUP_UPHS_TRANSACTION_ID
BU_MEMBER_UPHS_ADMIN_PENNID
BU_MEMBER_UPHS_ADMINISTRATOR
BU_MEMBER_UPHS_COST_CENTER
BU_MEMBER_UPHS_DEPT_NAME
BU_MEMBER_UPHS_ENTITY
BU_MEMBER_UPHS_MANAGER
BU_MEMBER_UPHS_MANAGER_PENN_ID
BU_MEMBER_UPHS_TRANSACTION_ID
BUSINESS_UNIT_GROUP_ID	 
BUSINESS_UNIT_GROUP_NAME 
BUSINESS_UNIT_GROUP_NUMBER
BUSINESS_UNIT_GROUP_SOURCE
BUSINESS_UNIT_GROUP_STATUS
BUSINESS_UNIT_GROUP_TYPE_ABBR
BUSINESS_UNIT_GROUP_TYPE_CODE
BUSINESS_UNIT_MEMBER_ID
BUSINESS_UNIT_MEMBER_NAME
BUSINESS_UNIT_MEMBER_NUMBER
BUSINESS_UNIT_MEMBER_SOURCE
BUSINESS_UNIT_MEMBER_TYPE_ABBR
BUSINESS_UNIT_MEMBER_TYPE_CODE
COURSE_ITERATION
COURSE_OBJECT
CUSTOM_DATA
KNODE
KNODE_CRS_JOIN
KNODE_USER_JOIN
LMS_BUSINESS_UNIT_TYPE
LMS_COURSE_MASTER
LMS_CURRENT_TRAINEE_CRS_STATUS
LMS_DEFINITION
LMS_LOCATION
LMS_PERSON
LMS_REGISTRATION
LMS_TRAINEE_BU_COURSE_ASSIGN
LMS_TRAINEE_COURSE_ASSIGN
PKG
REGISTRATION
UPHS_COST_CENTER
UPHS_RAW_DATA
UPHS_USER_ENTITY
USER_COURSES


Cautions

  • A query that uses the LMS_BUSINESS_UNIT_GROUP table might run more slowly than a similar query that does not use it. Business Objects users should use the LMS_BUSINESS_UNIT_GROUP table only once per data provider.
  • The LMS_BUSINESS_UNIT_GROUP table stores only the current information for a business unit member/group combination. Historical information is not available. For example, say business unit M is a member of business unit group G. M's name was originally 'Original M' but it changed to 'Business Unit M' last year, with no changes since then. G's name was originally 'Original G' but it changed to 'Business Unit G' this year. Currently, their names are 'Business Unit M' and 'Business Unit G'. There is no way to tell from the LMS_BUSINESS_UNIT_GROUP table that the record for member M and group G ever had BUSINESS_UNIT_MEMBER_NAME = 'Original M' and BUSINESS_UNIT_GROUP_NAME = 'Original G'.
  • The LMS_BUSINESS_UNIT_GROUP table was created to facilitate reporting on a given business unit and all of the business units that fall below it in the hierarchy. The business unit hierarchy is based on the hierarchies of the administrative groupings in the source systems. See also BUSINESS_UNIT_GROUP_TYPE_DESC.
    • The hierarchy for 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.
    • The hierarchy for 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.
    • The hierarchy for 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). For the list of auxiliary affiliations, see the documentation on LMS_PERSON.PENN_COMMUNITY_MEMBER_STATUS.
  • There are several data elements that provide information about the business unit's identity:
    • The BUSINESS_UNIT_MEMBER_ID is a string that uniquely identifies the business unit member to Knowledge Link users. Examples are 'UP.12345678' and 'HS.CRDTL.NeontChiefA.A.10'. (The value is stored without the quotes.) There is also a BUSINESS_UNIT_GROUP_ID. See the documentation on these data elements for more information on how the value of the identifying string is determined.
    • The BUSINESS_UNIT_MEMBER_NAME is a phrase or string that describes the business unit member. Examples are 'UP.franklin.DM-Sleep Medicine.RESEARCH INVESTIGATO' and 'Administrator: Neonatology* (CRDTL)'. (The value is stored without the quotes.) Note: It is possible for more than one business unit to have the same name. There is also a BUSINESS_UNIT_GROUP_NAME. See the documentation on these data elements for more information on how the value of the name is determined.
    • The BUSINESS_UNIT_MEMBER_NUMBER is a number (such as 45131) used to uniquely identify the business unit member within the Knowledge Link system. There is also a BUSINESS_UNIT_GROUP_NUMBER.
  • A business unit's status and type determine whether and how Knowledge Link users and courses can be assigned to it.
    • 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. 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. (Once a business unit has been named as the owner of a course version or package, it retains ownership even if it becomes inactive.) BUSINESS_UNIT_GROUP_STATUS is 'A' (if the business unit group is active) or 'I' (if it is inactive).
      • If BUSINESS_UNIT_GROUP_NUMBER = BUSINESS_UNIT_MEMBER_NUMBER, BUSINESS_UNIT_GROUP_STATUS also indicates whether the business unit member is active or inactive. For other LMS_BUSINESS_UNIT_GROUP records, the member's status is KNODE.STATUS where KNODE.KNODE_ID = BUSINESS_UNIT_MEMBER_NUMBER. (Note that KNODE.STATUS is a numeric code, where 1 means 'active' and 0 (zero) means 'inactive.')
    • The LMS_BUSINESS_UNIT_GROUP table stores the value of the business unit type in three ways: a numeric code, an alpha abbreviation, and a description. See BUSINESS_UNIT_MEMBER_TYPE_CODE, BUSINESS_UNIT_MEMBER_TYPE_ABBR, and BUSINESS_UNIT_MEMBER_TYPE_DESC, as well as BUSINESS_UNIT_GROUP_TYPE_CODE, BUSINESS_UNIT_GROUP_TYPE_ABBR, and BUSINESS_UNIT_GROUP_TYPE_DESC.
    • 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 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.)
        • 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) or 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.
    • The business units for the University's academic divisions and majors do not have Knowledge Link users or courses assigned to them either directly or indirectly. These business units are used to create the parent business units for the students, which can have courses assigned to them. For example, the business unit UP.PDM.BMB (the Graduate Arts & Sciences MD/PhD division's Biochemistry & Molecular Biophysics major) is the basis of the business unit UP.STU-.PDM.BMB (the parent business unit for students with that primary division and primary major), which does have courses assigned to it.
    • See the KNODE_USER_JOIN table for information on business units and the Knowledge Link users assigned to them.
    • See the KNODE_CRS_JOIN table for information on business units and the courses assigned to them
  • There are several data elements providing information specific to business units that correspond to UPHS departments. These data elements have null values for other UPHS business units, and for all University business units.
    • Information identifying those who are 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):
      • BU_MEMBER_UPHS_MANAGER_PENN_ID, BU_MEMBER_UPHS_MANAGER, and BU_MEMBER_UPHS_MANAGER_AS_IS are the Penn ID, the name in upper case, and the name in mixed case, respectively, of the business unit member manager, who is responsible for the UPHS department identified by the BUSINESS_UNIT_MEMBER_NUMBER. (Also known as a cost center or accounting unit, a department is a subdivision of a UPHS entity or process level.) Examples: '12345678', 'SMITH, JANE', and 'Smith, Jane'. (The values are stored without the quotes.) It may be preferable to select and sort records based on the name in upper case rather than in mixed case. Similar information for the business unit group manager is available in BU_GROUP_UPHS_MANAGER_PENN_ID, BU_GROUP_UPHS_MANAGER, and BU_GROUP_UPHS_MANAGER_AS_IS.
      • BU_MEMBER_UPHS_ADMIN_PENNID, BU_MEMBER_UPHS_ADMINISTRATOR, and BU_MEMBER_UPHS_ADMIN_AS_IS are the Penn ID, the name in upper case, and the name in mixed case, respectively, of the business unit member administrator, who oversees the manager. Examples: '23456789', 'JONES, ANN', and 'Jones, Ann'. (The values are stored without the quotes.) It may be preferable to select and sort records based on the name in upper case rather than in mixed case. Similar information for the business unit group administrator is available in BU_GROUP_UPHS_ADMIN_PENNID, BU_GROUP_UPHS_ADMINISTRATOR, and BU_GROUP_UPHS_ADMIN_AS_IS.
      • For further information on someone who is authorized to run the Entity Administrator Report, see the record in the LMS_PERSON table for the person's Penn ID.
  • There are other data elements providing information specific to UPHS business units. These data elements have null values for all University business units:
    • BU_MEMBER_UPHS_COST_CENTER and BU_GROUP_UPHS_COST_CENTER store text used in Knowledge Link's Entity Administrator Report. The value stored in these data elements (if it is not null) is 'Cost Center' (without the quotes).
    • BU_MEMBER_UPHS_ENTITY is the name of the business unit member entity (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. (Example: HUP) Similar information for the business unit group is stored in BU_GROUP_UPHS_ENTITY.
    • BU_MEMBER_UPHS_DEPT_NAME and BU_MEMBER_UPHS_DEPT_NAME_AS_IS are the name (in upper case and mixed case, respectively) of the business unit member department. (Also known as a cost center or accounting unit, a department is a subdivision of a UPHS entity or process level.) Example: 'NURSING SILVERSTEIN 7' and 'Nursing Silverstein 7'. (The value is stored without the quotes.) It may be preferable to select and sort records based on the name in upper case rather than in mixed case. Similar information for the business unit group is stored in BU_GROUP_UPHS_DEPT_NAME and BU_GROUP_UPHS_DEPT_NAME_AS_IS.
    • BU_MEMBER_UPHS_TRANSACTION_ID is the transaction ID number for the record in the XML feed from UPHS that created the KNODE record for the business unit member. Similar information for the business unit group is stored in BU_GROUP_UPHS_TRANSACTION_ID.
  • You can create a report using business unit groups by joining the business unit member in LMS_BUSINESS_UNIT_GROUP to a business unit in another table. (Often this means that the query will include the condition WHERE LMS_BUSINESS_UNIT_GROUP.BUSINESS_UNIT_MEMBER_NUMBER = other_table.KNODE_ID.) If you select records for business unit group X, the report will include data from the other table for business unit X and for all of the business units that fall below it in the hierarchy. Because the members of business unit group X include business unit X itself, even if business unit group X has only itself as a member, your query will return any data available for that business unit group.
  • The LMS_BUSINESS_UNIT_GROUP table is a de-normalized version of the KNODE table, but it does not include all of KNODE's data elements.
    • Although a LMS_BUSINESS_UNIT_GROUP record identifies a business unit group/business unit member combination, it does not include information on how closely the group is related to the member. (The group could be the same as the member, or it could be the member's parent, or grandparent, etc.) The KNODE_ID of the parent of a given business unit is stored in KNODE.PARENT_ID.
    • Besides the UPHS administrator and manager, there can be two other UPHS employees who can run the Entity Administrator Report (which provides information on the compliancy of courses for UPHS departments, and the users within those departments). See CUSTOM_N3 and CUSTOM_N4 in the KNODE table for the Penn IDs of those two persons.
    • The LMS_BUSINESS_UNIT_GROUP table stores DATE_BU_GROUP_CREATED, DATE_BU_GROUP_MODIFIED, and BUSINESS_UNIT_GROUP_STATUS for the business unit group. If BUSINESS_UNIT_GROUP_NUMBER = BUSINESS_UNIT_MEMBER_NUMBER, these data elements also pertain to the business unit member. For other LMS_BUSINESS_UNIT_GROUP records, you can get the information for the business unit member from DATE_CREATED, DATE_MODIFIED, and STATUS in the KNODE table where KNODE.KNODE_ID = BUSINESS_UNIT_MEMBER_NUMBER. (Note that KNODE.STATUS is a numeric code, where 1 means 'active' and 0 (zero) means 'inactive.')

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 trainees 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.

LMS_BUSINESS_UNIT_GROUP Table - Data Element Index    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