Data Source Keys are labels made up of alpha-numeric strings that allow different types of data from a single data source to be grouped together so that they can be handled in a single operation. Using Data Source Keys breaks up your data to optimize system resources and meet business rules.
Data Source Keys are created as needed and can be saved for future use. They can be used in almost infinite ways to categorize data, to associate data with specific systems so that data may be visually managed within Blackboard Learn. Data Source Keys are stored in the Blackboard database and are referenced in data feeds and integration configurations.
Data Source Keys function in conjunction with your SIS integration to help manage data once it has been uploaded into Learn via an SIS integration configured to use a specific Data Source Key.
Data Source Key Best Practices
Given the basic premise behind Data Soure Keys is to enable granular identification and management of data it is worth considering how your naming conventions match your institution's data-flow and how you wish to break that data into 'chunks' or sets and the lifecycle of those chunks - the larger your overall data sets and the longer you keep the data in Learn the more important it is to be able to identify targeted portions of that data.
Data Source Keys can be used in many ways to categorize data but there are some general tips that should be followed when creating and applying Data Source Keys to data.
- Keep a consistent naming convention for the Data Source Keys to prevent confusion when it is time to modify or remove data. <l>
- Avoid creating multiple Data Source Keys for entries that will remain for a long period of time (such as Students or Faculty). Doing so may create unnecessary complications or problems.
- When archiving and removing courses at the end of a semester it is best to disable them first for a short period of time before archiving and removing them from the system. This will allow a short period to confirm that they have been archived safely before removing them and help prevent accidental deletion of courses that have not been safely preserved if desired. </l>
When assigning data sources to course and organization categories, child categories must belong to the same data source as the parent category when the category tree is inserted. If child categories do not appear in the same data source as the parent, the child-parent relationship will not be maintained.
To ensure logical application and knowledge transfer, create a system for naming Data Source Keys so that they can be easily identified. The following naming convention represents a relatively simple way to break up the data sets to enable the two most common workflows.
Legal Characters for Data Source Names
Data source keys should consist only of the letters A-Z, numbers 0-9, periods, and underscores (_).
Data Source ID
A simple ID should be assigned for the source system, for example SIS for a Student information system, or HRMS for a human resources management system. By combining this ID with an ID for each type of set, a flexible naming scheme can be derived to support typical workflows.
Type Bound Sets
Type bound sets include a component that is derived from the type of feed that is being performed. This way a data set is identified by the entities involved. For example, if the string ‘Course’ is used to mean “Course” then that string is included to indicate the type of the data set, for example SIS.COURSE.
Term Bound Sets
Term bound sets are used to group data that are related, but should not overlap time periods in the database. For example, it might be desirable to feed spring Courses into the database while fall Courses are still active. Using a key that distinguishes the two sets based on their term will prevent Snapshot operations on one set from interfering with data in the other. For example, SIS.SPRING2000 and SIS.FALL2000.
Type and Term Bound Sets
In many cases it is desirable to use a combination of type and term bound identification. The most common example is Student enrollment at an institution with a fixed academic calendar—enrollment is bound to a specific semester for example, SIS.COURSE.FALL2000.
A school wants to process student and instructor lists, course section listings, and enrollments over the course of several semesters. In general, from semester to semester, the student and instructor lists will encompass the same basic data set. However the courses and enrollments will need to be processed on a per-semester basis. That is, from semester to semester, active Students and staff will be treated as a single logical set (with fluid membership) while courses and enrollments will be treated as logically distinct sets that do not intersect from semester to semester.
One solution is to use type-bound keys for students and instructors, and type and term bound keys for courses and enrollment. A Data Source Key is created called SIS.USERS that is used to identify the set of users over time. This way, all active students, and instructors may be processed as a single set of data.
Separate Data Source Keys are created for courses, enrollment, instructors and students, all which are both type and term bound:
That way, all user feeds may use the SIS.USERS Data Source Key, while courses and enrollment can use the SIS.COURSE.* keys, allowing for searches and data visualization utilizing the described data sets.
As another example, different sets can be applied to different users:
How to Create DSKs Using the Data Source Administration page
- On the Administrator Panel, in the Building Blocks section, click Data Integration.
- Click Data Sources.
- Click Create Data Source.
- Type a unique key and optionally add a description.
- Click Submit.
All management of Data Source Keys and associated records is possible via the Data Source Administration Page.
Viewing Associated Records
After you have created a Data Source Key and used an integration to populate data in learn and associated a Data Source Key with that data you may go to the Data Source Key management page (On the Administrator Panel, in the Building Blocks section, click Data Integration).
Click Data Sources, and then click the Data Source Key of interest. A window displays containing a list of Learn objects and their status (Enabled, Disabled) counts.
Once you have used an integration to create objects in learn and associated a Data Source Key with them you may, when access to those objects supported by that data is no longer required, choose to disable the objects. Disabling an object has the utility of leaving it's data in Learn while eliminating access to that object. For example: an enrollment may be disabled and the data for that enrollment (and related activity data) are retained in Learn, but the user with whom that data is associated may no longer access the course or organization. Similarly a User who has been disabled will no longer have access to Learn, and a course which has been disabled will no longer be available to students or instructors - yet in both all cases the data is retained in Learn such that should the User or course be enabled again it will be as if nothing had changed.
To disable objects, go to the Data Source Key management page - on the Administrator Panel, in the Building Blocks section, click Data Integration, click Data Sources and select the contextual menu for the Data Source Key of interest and select Disable.
You may now choose from the list the object types you wish to disable.
After you have used an integration to create objects in learn and associated a Data Source Key with them you may, when access to those objects and the associated object data is no longer required, choose to purge the objects. Purging an object has the utility of completely removing that object's data in Learn thus freeing resources for future use.
In order to purge records they must first be disabled - once you have completed the steps outlined in the Disabling Records section of the DSK management document you may purge the disabled records.
To purge disabled records go to the Data Source Key management page - on the Administrator Panel, in the Building Blocks section, click Data Integration, click Data Sources and select the contextual menu for the Data Source Key of interest and select Purge.
You may now choose from the list presented the objet types you wish to purge.
You may delete a Data Source Key from the Data Source Key's contextual menu - on the Administrator Panel, in the Building Blocks section, click Data Integration and select the contextual menu for the Data Source Key of interest and select the Delete option.
You can delete a DSK only if no associated records exist. If associated records exist, you first must disable and purge those records as outlined in this topic.
Q: I am receiving a Data Source Key not found error even though I have my integration set to use the incoming Data Source Key - what is wrong?
A: Data Source Keys must be created in advance of use by an integration. To learn more, see Creating Data Source Keys.
Q: Are there Illegal characters for Data Source Key Names?
A: Yes. Data source keys should consist only of the letters A-Z, numbers 0-9, periods, and underscores (_).
Q: Are Data Source Key names case sensitive?
A: No. Data Source Key names are not case sensitive.
Q: Why does the SIS Integration Framework seem to ignore my Data Source Keys?
A: The SIS Integration Framework treats Data Source Keys differently than previous integration techniques such as command line Snapshot. Please review the Migrate to the SIS Integration Framework from Command Line Snapshot, Data Source Key Overview, Planning Integrations, and integration type specific configuration Knowledge Paths.
Related Knowledge Paths
- SIS Framework Overview
- Migrating from Command Line Snapshot to Snapshot Flat File
- Follow Knowledge Paths for specific integration types for information regarding installation, configuration, and management of integrations.