When you create a study dataset, LabKey creates a corresponding table in the main database to hold the data. This table is created in the studyDataset schema. For example if you create the table
"Demographics"
LabKey will create a corresponding table with a related name (container id string + Demographics), for example:
"c10d79_demographics"
When users import data to the Demographics table two things occur:
These system tables are not created by the user, but already exist as part of the study schema, for example:
The ParticipantVisit table contains one row per participant/visit combination in a study. This can be a useful table for aligning data in queries and reports. Note that when you view "ParticipantVisit/Visit" in the UI, the display for that column will show the visit label if one exists, or the SequenceNum for the field if a visit label has not been defined. This is because the grid view will "follow the lookup" to an appropriate display field. However, if you include the "ParticipantVisit/Visit" column in a query, you will not see the the same 'followed lookup', but will instead see the rowID of that row in the table. To use the actual label in your query, you need to follow the lookup, i.e. use "ParticipantVisit/Visit/Label" instead.
Data imported from different studies is intermingled in these system-level study schema tables. (The data is not intermingled in studyDataset schema tables.) To get a sense of how data is intermingled in these tables, open PGAdmin and drill down to:
Below is an example system table named "participant". Notice the "containerid" column which indicates which study folder a given participant belongs to.
container | participantid |
---|---|
"09f8feb4-e006-1033-acf0-1396fc22d1c4" | "PT-101" |
"09f8feb4-e006-1033-acf0-1396fc22d1c4" | "PT-102" |
"09f8feb4-e006-1033-acf0-1396fc22d1c4" | "PT-103" |
"143fdca3-7dd2-1033-816c-97696f0568c0" | "101344" |
"143fdca3-7dd2-1033-816c-97696f0568c0" | "103505" |
"143fdca3-7dd2-1033-816c-97696f0568c0" | "103866" |