- Data Source Key best practices
- DSK management
- 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's wrong?
- Are there illegal characters for Data Source Key names?
- Are Data Source Key names case sensitive?
- Learn more
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 and 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.
Because Data Source Keys are meant 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 here are some general tips for 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.
- 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.
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.
Data source keys should consist only of the letters A-Z, numbers 0-9, periods, and underscores (_).
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 include a component that is derived from the type of feed. 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 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.
You may want 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.
Example: 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 using the described data sets.
As another example, different sets can be applied to different users:
- On the Administrator Panel, in the Building Blocks section, select Data Integration.
- Select Data Sources > Create Data Source.
- Type a unique key and optionally add a description.
- Select Submit.
All management of Data Source Keys and associated records is possible via the Data Source Administration page.
After you have created a Data Source Key, used an integration to populate data in Learn, and associated a Data Source Key with that data, go to the Data Source Key management page. On the Administrator Panel, in the Building Blocks section, select Data Integration.
Select Data Sources, and then find the Data Source Key. A window displays containing a list of Learn objects and their status (Enabled or Disabled) counts.
After you use an integration to create objects in Learn and associate them with a Data Source Key, you may choose to disable the objects when access to those objects supported by that data is no longer required. Disabling an object leaves its 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 disabled course will no longer be available to students or instructor, yet in both all cases the data is retained in Learn. If the user or course is re-enabled, it will appear as if nothing had changed.
To disable objects, go to the Administrator Panel. In the Building Blocks section, select Data Integration > Data Sources. Open the menu for the Data Source Key you want to edit and select Disable.
After you use an integration to create objects in Learn and associate them with a Data Source Key, you may choose to purge the objects when access to those objects and the associated data is no longer required. Purging an object completely removes that object's data in Learn, freeing resources for future use.
You must disable a record before you can purge it.
Go to the Data Source Key management page on the Administrator Panel. In the Building Blocks section, select Data Integration > Data Sources. Open the menu for the Data Source Key you want to remove and select Purge.
To delete a Data Source Key, go to the Administrator Panel. In the Building Blocks section, select Data Integration. Locate the Data Source Key you want to delete, open its menu, and select Delete.
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.
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's wrong?
Data Source Keys must be created in advance of use by an integration.
Are there illegal characters for Data Source Key names?
Yes. Data source keys should consist only of the letters A-Z, numbers 0-9, periods, and underscores (_).
Are Data Source Key names case sensitive?
No. Data Source Key names are not case sensitive.