Student Data Warehouse - User Guide
Student Data Warehouse - User Guide
Student Data Warehouse User Guide Page 1 Print date: 16 Sep 15 StudentDataWarehouse User Guide Contents Chapter 1: Introduction 5 What is SDW . . 5 Student Privacy . . 5 SDW Data . . 6 — — How is data stored in SDW . . 6 SDW Queries . . 8 Some Commonly Used Fields . . 9 Cautions When Using SDW . . 9 Contacts . . 9 Chapter 2: Using SDW 10 Logging into Student Data Warehouse . 10 Using the Main Console . 10 Browsing Files . 11 File and Folder Actions . 12 Opened Screen . 13 Creating a New Query . 14 — — Filters . 15 — — Advanced (Nested) Filters . 16 — — Using Translation Tables as Filters .
16 — — Columns (Details . 17 — — Groups . 18 — — Formatting Reports . 18 — — Changing the Report Title and Headers . 19 — — Using Parameters and Prompts . 19 Joining Tables . 21 — — Common Automatically Joined Fields . . 22 — — What to do when tables are not automatically joined . . 24 Running Reports/Exporting data . . 25 Saving Queries . . 26
Student Data Warehouse User Guide v.3.0 Page 2 Print date: 16 Sep 15 Contents (continued) Sharing Files . . 26 Run a Canned Report . . 27 Common Canned Reports . . 29 Schedule a Query . . 30 Chapter 3: SDW Tables Guide 31 Student Data Warehouse Tables Quick Reference . 31 SDW Tables Guide . . 33 — — ADDRESS_TYPE Table . . 33 — — ADVISOR Table . . 34 — — ADVISOR_DEPARTMENT Table . . 34 — — ATHLETICS Table . . 34 — — BUILDING Table . . 35 — — CLASS Table . . 35 — — COLLEGE Table . . 35 — — COUNTRY Table . . 35 — — COURSE Table . . 36 — — COURSE_DESCRIPTION Table . . 36 — — COURSE_DROP Table .
. 37 — — COURSE_PREREQ Table . . 38 — — COURSE_PREREQ_SYNONYMS Table . . 38 — — COURSE_PREREQ_TEXT Table . . 39 — — COURSE_RESERVATION Table . . 39 — — COURSE_SEMESTER Table . . 40 — — COURSE_WAITLIST Table . . 40 — — DEGREE Table . 41 — — DEGREE_AWARDED Table . 41 — — DEPARTMENT Table . . 42 — — ENROLLMENT_STATUS Table . . 42 — — ENTITY Table . . 43 — — FRATERNITY Table . . 43 — — GRADE_CHANGES Table . . 43 — — HIGH_SCHOOL Table . . 44 — — INSTRUCTOR Table . . 45 — — MAJOR_MINOR Table . . 45 — — MEETING Table . . 46 — — PARENT_GUARDIAN Table . . 46 — — PHONE_TYPE Table . . 47 — — PROGRAM Table .
. 47 — — QPA Table . . 48 — — RACE Table . . 49 — — SCHEDULE Table . . 49 — — SECTION Table . . 50
Student Data Warehouse User Guide Page 3 Print date: 16 Sep 15 — — SECTION_INSTRUCTOR Table . 51 — — SEMESTER Table . . 52 — — SISROOMS Table . . 52 — — STATE Table . . 53 — — STUDENT Table . . 53 — — STUDENT_ADDRESS Table . . 55 — — STUDENT_ATHLETICS Table . . 55 — — STUDENT_MAJOR_MINOR Table . . 55 — — STUDENT_PHONE Table . . 56 — — STUDENT_RACE Table . . 56 — — STUDENT_SEMESTER table . . 57 — — TEACHING_LOCATION Table . . 57 — — TRANSFER_CREDIT Table . . 58 — — VETERAN_STATUS Table . . 58 — — VISA_TYPE Table . . 59 Chapter 4: Code Translations 61 — — College Codes (COLLEGE_ID . 61 — — Department Codes (DEPARTMENT_ID .
61 — — Major Codes (MAJOR_MINOR_ID . . 64 — — CFA College of Fine Arts . . 64 — — CIT Carnegie Institute of Technology . . 67 — — CMUCarnegie Mellon University . . 69 — — DC Dietrich College of Humanities and Social Sciences . . 80 — — HC H. John Heinz III College . . 83 — — MCS Mellon College of Science . . 84 — — SCS School of Computer Science . . 86 — — TSB David A. Tepper School of Business . . 87 — — Enrollment Status Codes (ENROLLMENT_STATUS_ID . . 89 — — Entity Codes (ENTITY_ID . . 89 Contents (continued)
Student Data Warehouse User Guide Page 5 Print date: 16 Sep 15 Chapter 1: Introduction What is SDW? The Student Data Warehouse is a database of information copied from the Student Information System (SIS). This data is refreshed each morning via a data feed from SIS, around 7:00 am. Thus, data in SDW is accurate as of that morning. Because SDW is not live data, when SIS/S3 is down or unavailable, SDW may still be accessed. SDW vs. Pentaho The Student Data Warehouse (SDW) allows departments to query student data without having to request it from the University Registrar’s Office.
Pentaho is a flexible web-based business intelligence application through which users access and interact with the Student Data Warehouse.
Your SIS Confidentiality Statement still applies to the appropriate use of student data.
You may not disclose any student data to a third party outside of Carnegie Mellon. Disclosure means “to permit access to or the release, transfer, or other communication of personally identifiable information contained in education records by any means, including oral, written, or electronic means, to any party except the party that created the record.” • All requests for student directory information must be directed to the University Registrar’s Office (uro- email@example.com), whether it is an internal or external request.
• All requests for the use of student e-mail addresses for surveys and research must similarly be directed to the University Registrar (firstname.lastname@example.org).
Note on Race/Ethnicity and Aggregate Data Because students can declare more than one race/ethnicity, you should refer to the University Factbook (http://www.cmu.edu/ira/factbook/) for such data, as well as for aggregate data requests (enrollment numbers, demographic data, etc.) if for public release.
Student Data Warehouse User Guide v.3.0 Page 6 Print date: 16 Sep 15 SDW Data This section will discuss the internal structure of SDW. How is data stored in SDW? Tables SDW, like SIS/S3, is a relational database, with data is stored as data fields in interconnected tables. A table is a collection of related fields. In the example above, the table might contain student biographical data, and the fields might be something like first_name, last_name, andrew_id, birthdate, etc. We can call this table the student table and list its fields as student.first_name, student.last_name, student.andrew_id, etc.
Note: In this documentation, all table and field names will be listed in capital letters, to distinguish them from regular text. Rows In a table, each person/entity has a set of values for each field in the table. This set of values is called a row. In our example of the student table, each student would have a row in the table.
Student Data Warehouse User Guide Page 7 Print date: 16 Sep 15 Indexes To identify a particular row, each table has a field or fields known as indexes. An index field identifies a row with a particular person or entity, depending on the nature of the table.
For example, if it were a course-related table, the course number (course_id field in SDW) would be an index. All students in SDW are associated with a field called student_key, a number unrelated to Student ID or SSN which simply serves to identify a row for a particular student (see p. 24). Note: A table may have more than one index. For example, if a table is related to both students and courses, it will be indexed on the student and the course (and possibly also the section number/letter). In such cases, it is not uncommon to find that a particular student/course has multiple rows.
Types of Tables All tables in SDW can be classified as one of three types: • Semester-Dependent: These tables hold data relative to a particular semester (such as the table called student_semester, in which each student has a row for each semester pertaining to their enrollment data for that semester). • Semester-Independent: These tables hold data that is not related to any particular semester. For instance, the table called student holds biographical data about students, completely unrelated to any particular semester.
• Translation: These are a specialized type of Semester-Independent table which serves the purpose of translating a code, such as a college code (CIT, MCS, SCS, etc.) or enrollment status (E1, R3, W2, etc.) by giving its full name and possibly a few other relevant data points.
Tip: Wherever you see a field that ends in “_id,” there is usually a translation table which is the same name minus the “_id.” Examples include the college table (which translates the field college_id) or the enrollment_status table (which translates the field enrollment_status_id).
A quick-reference to each table in SDW, its type, and its general purpose can be found on pp. 31-59.
Student Data Warehouse User Guide v.3.0 Page 8 Print date: 16 Sep 15 SDW Queries What is a Query? A query is a defined search for data. SDW users create and run queries in order to generate reports based on the type of data for which the query asks. Query Terminology • Constraints — the limiting conditions which define which data a query returns. • Columns (formerly called Details) — the data fields included in the output of a query. A field may be used both as a filter and a column.
• Filters — data fields which act as constraints on a query but which do not display in the query results Questions to ask yourself when creating queries 1. What do I want to get? • I want to see _ such that _ . (students, courses, instructors, etc.) (semester = x, final grade = y, etc.) • I want to see _ about these results. (name, Andrew ID, course number, etc.) 2. What type of data am I looking for in this query? Is it: • Student-related • Course-related • Commencement-related • Etc.
3. What data do I need to see vs. what will only be used to constrain my results? 4. Where will I find this data? • Which tables contain the information I need? • Am I looking in the right table for my purpose? • Are there concerns about joining tables? (see p.
24) • Is the data actually in SDW?
Student Data Warehouse User Guide Page 9 Print date: 16 Sep 15 Some Commonly Used Fields Here are a few tables you may find yourself using often: • STUDENT — stores semester-independent data about students, such as biographical and admission data, as well as andrew_id, card_id, personal_name, etc. • STUDENT_SEMESTER — stores student semester records—semester-dependent data, such as college, department, major, class status, enrollment status, etc. for each semester a student has a record created. • SCHEDULE — stores student schedule data per semester. This table has four index fields: student_id, semester_id, course_id, and section_id.
It also contains mid_semester_grade and final_grade. • STUDENT_MAJOR_MINOR — stores semester-independent information about students’ majors and minors. This is where a student’s majors and minors actually reside (see p. 23), along with the table degree_ awarded.
• SECTION — stores data about each section of a course per semester, such as title, units, teaching_ location_id, maximum_enrollment, actual_enrollment, etc. • QPA—stores student’s QPA data per semester. Note that until QPA has run for a semester, a student will not have the corresponding row in this table. Cautions When Using SDW • Just because two tables share an identically named field does not mean that they will be automatically joined. • For example, the student_semester and student_major_minor tables both contain a semester_ id field. However, they refer to two separate things—in the first, the semester pertaining to the semester record, and in the second, the semester of certification.
• A query may also sometimes require that two identically named fields be included. For instance, querying on both the schedule and student_semester tables may require that both semester_id fields be included in constraints. See p. xx for more data on this situation. • Some students may have more than one row in a table, which may skew counts. (example: student_ athletics) • Remember that the table in which you find a field matters. • Be sure you know what data is stored in a table before including it in a query. Consult the tables guide included in this document (pp. 31–60) if unsure.
Contacts • Commencement/Degree Data Jon Samuels x8-1922 (Degrees, Majors, Minors, etc.) • Student Information Kathy Sloan x8-1949 or MaryAnn Moyer x8-1941 (Addresses, E-mails, Class Level, Grades, Registration, Advisors) • Academic Programs Jarrin Nevel x8-8250 (SIS Program Codes) • Class Schedules & Rooms Nancy Camino x8-4086 (Course information, Classrooms, Faculty Instructors) • Student Race/Ethnicity John Papinchak x87-404 • Pentaho Questions Karen Giannangeli x8-8069 • General email@example.com
Student Data Warehouse User Guide v.3.0 Page 10 Print date: 16 Sep 15 Chapter 2: Using SDW Logging into Student Data Warehouse In order to access the SDW User Console, the user must have an AndrewID and must also be set up in Active Directory with the appropriate roles enabled. To launch the User Console: 1. Launch Firefox (note: other browsers may not work; please use Firefox). 2. Go to https://reporting.andrew.cmu.edu/pentaho/. You will want to add this URL to your browser’s bookmarks. 3. You will be presented with a Web Login screen. Enter your Andrew userID and password.
4. You will see the Pentaho welcome screen.
Enter your Andrew userID and ERP password (i.e. your S3 password) and click Login. 5. The Pentaho Home Screen will load. From here, you can run and share saved queries and create new queries. Step 5: Home screen Steps 1–3 Step 4 The Menubar and Drop-Down Menu Tip: If you find yourself having to scroll excessively to view all parts of a page or all items in a list, increase your display resolution. A good resolution for using the Pentaho application is 1280×1024 or larger.
Using the Main Console The Menubar and Drop-Down Menu At the top of the browser tab containing the Pentaho application is an internal menubar. Directly under it is a large drop-down menu, which displays the name of the current page. The Menubar has three menu options: File, View, and Help. The File menu allows users to create new reports, open an existing report, or view their Recent or Favorite reports. The View menu allows users to change various settings, such as language and interface theme. The Help menu provides access to Pentaho documentation.
The Drop-Down Menu is the primary navigation tool in the Pentaho interface.
It normally appears as the name of the current page in large font. When clicked, a drop-down appears which lets users go quickly to the following pages: • Home—the Pentaho Home Screen • Browse Files—view saved reports and other files • Opened—reports/files the user currently has open • Schedules—view and edit report schedules.
Student Data Warehouse User Guide Page 11 Print date: 16 Sep 15 Browsing Files Saved queries and reports are stored on the SDW server. To view these files, click the Browse Files button from the Home screen or the Drop-Down Menu. The Browse Files screen will then appear (see screenshot below): • To open a folder, click on its name in the Folders box. You can also expand it (to show any subfolders) or collapse it (to hide subfolders) by clicking on the arrow button next to its name. • Files within the selected folder will be shown in the Files box in the middle of the screen. • To refresh the Browse Files list, click the icon above the Folders list.
Browse Files screen Home Directory Each user has a subfolder under the “Home” folder, which by default can only be accessed by that user (and Administrators). This is called the Home directory. All queries that you (and only you) use should be saved in your home directory • Note: You can give others limited access to files in your home directory. See p xx for more details. Public/SDW Folder Files that are usable by a group of people or for all SDW users are stored in the SDW folder, which is under the Public folder. The Public/SDW folder also has sub-reports for various Canned Reports (see p.
xx) made available to all academic SDW users and Grade Report queries for those who have requested access. • By default, all files in the Public/SDW folder are freely viewable by anyone. They can also (with the exception of canned reports) be edited or deleted by anyone by default. Please see p. xx, which talks about file permissions.
File Types The icon next to a file’s name indicates its type: Interactive Report Canned Report (see p. xx) Other file (.csv, .html, .xlsx, .pdf, etc.) If you highlight a file (click on it once), you will see what actions you can perform on it (see next page).
Student Data Warehouse User Guide v.3.0 Page 12 Print date: 16 Sep 15 File and Folder Actions With a file or folder selected, you can perform the following via the File Actions/Folder Actions list at the right-hand side of the screen, depending on the permissions you have for the file/ folder: • Open/Open in a New Window—executes a query or opens a file in the same window or a new one.
• Note: The “Open” option will take you from the Browse Files screen to the Opened screen (see next page), while the “Open in a New Window” option will not, since it creates a new browser window.
• Run in background...—This executes a query in a similar manner to Scheduling (see p. 30), but done immediately instead of the future. • Cut/Copy—These commands allow you to move a file from one location to another. Once you have chosen either Cut or Copy, go to the location you want to place the file and choose the new option “Paste.” • The difference between Cut and Copy is that Copy will leave the old file where it was while creating a duplicate in the new location. Cut deletes the original once you click the Paste command.
• IMPORTANT: When you move a query via Cut, any schedules, etc.
that referred to it by the old file path will no longer work. Therefore, it is usually better to Copy than to Cut if it is a file others may be using. • Move to Trash—This is much like deleting a file on your computer. Deleted files go to the folder called “Trash,” from which they can be recovered (if they were put there accidentally) or deleted permanently. • Rename—This allows you to rename a file. It does not allow you to change its file type/extension. You can also not use this tool to move a file from one location to another. • IMPORTANT: When you Rename a file, any schedules, etc. that referred to it by the old file path will no longer work.
Please be cautious when using this with queries others may be using.
• Share—This brings up the Share dialog box, which allows you to set file permissions (see p. 26) • Schedule—This allows you to schedule a query (see p. 30). • Add to Favorites —This will add the file/query to your Favorites list, viewable on the Home screen or by File -> Favorites. • Properties...—This brings up the file properties dialog box. • New Folder... (Folders only)—If you have a folder selected, you can use this option to create a subfolder within the selected folder.
File Actions Folder Actions
Student Data Warehouse User Guide Page 13 Print date: 16 Sep 15 Opened Screen Whenever you open a file (interactive report, canned report, or other) or create a new Interactive Report, you will be taken to the Opened screen.
The Drop-Down Menu will change to say “Opened.” To return to the Home or Browse Files screens, click the Drop-Down menu and select the appropriate page. • You will see a separate tab under the Opened screen for each file you have open. To move from one file to another, click the appropriate tab. To close a file, click the “x” icon at the far right of the tab.
• When closing the last tab, you will be returned to the Home screen. To open another file, you will need to go back to the Browse Files screen or go to File -> Open. • If you try to close a tab for a file that has unsaved changes, you will be prompted on whether or not to save. • When on the Opened screen, extra tool buttons appear next to the Drop-Down Menu: Open New Edit These allow you to perform several functions without having to go back to the Browse Files screen. In addition, while you have a query open, you can toggle the Edit button to enter and exit editing mode.
Student Data Warehouse User Guide v.3.0 Page 14 Print date: 16 Sep 15 Creating a New Query 1. Log into SDW (see p. 10). 2. From the Home screen, lick the Create New button, then select and click “Interactive Report” (the other two options under Create New currently have no functionality). • You can also use the File menu (File -> New -> Interactive Report) 3. You will be prompted to select a Data Source for your report (you may only have access to one). This determines the set of SDW tables to which you have access. Click OK with the proper Data Source highlighted. 4. The Interactive Report creator will now load.
This tool allows you to create queries via drag-and-drop operations, seeing the results in real time.
• Along the left-hand side is the list of SDW tables and the fields within them, all listed alphabetically. These can be dragged and dropped into different areas to build the report. • On the right-hand side and taking up the majority of the screen is a preview of how the report will look when the query is run. • Just above the query preview is the Report Toolbar, which has several tools for creating and adjusting your query. Steps 1–2 Step 3 (Select Data Source) Definitions Table A collection of related data fields. Group Creates subheadings in output. Not used often. Columns Items selected for inclusion in the output of a query.
Filters Items used to constrain output of a query, although they do not actually appear in the query output. Index * An item in a table which is used to link that table to another. For example, “STUDENT_KEY” is used to link the “STUDENT” table to the “STUDENT SEMESTER” table. Row * Conceptually, the collection of all data items in a table for a given index. * Terms not seen visually in SDW but which are useful for discussing the structure of the database (see pp. 6–7) Step 4 (Interactive Report creator) Close-up of the Report Toolbar. From left to right, the tools are: • Busy indicator • Undo, Redo • Export Data (i.e.
“Preview as”) • Select/Unselect all • Show/Hide Filters, Show/Hide Layout (groups and columns), Show/Hide Prompts • Page navigation *
Student Data Warehouse User Guide Page 15 Print date: 16 Sep 15 Filters Filters are the constraints which define what data your query will return. Filters are placed using fields. Step 2 (Adding a filter based on a condition) Step 1a (Show/Hide Filters button) Step 3 (Adding a filter from a list) Step 4 (Filters appear in Filters pane) IMPORTANT: Always add your filters first, before adding detail columns to the report. This will help avoid long wait times as the report preview refreshes. 1. To add fields to your query as filters, use one of the following methods: • Drag-and-drop method: Click the “Show Filters” button on the Report Toolbar.
Drag the field you wish to use as a filter to the Filters panel. • Right-click method: Right-click the field you wish to use as a filter and select “Filters...” 2. If your filter should be applied based on a specific condition, use the default option to specify the filter constraint and click “OK.” 3. If your filter should be applied based on a set of values, either “incude only these” or “exclude only these,” choose the top option. The list will populate automatically with possible values for your field (may take a few seconds to load). Use the arrow buttons to move the appropriate values over to the right-hand side.
Use the drop-down to specify whether this list is of those to be included or excluded. Then click “OK.” Note: You cannot use “Select from list” when the field is numeric in nature. The list is also limited in how many it displays. If you don’t see the value you want, try searching for it in the Find box.
Tip: Use CTRL+click to select multiple items. You can also use the search function to find a value quickly in a long list. 4. Your filters will now appear in the Filters pane above the report preview. You can use the downward arrow ( ) buttons beside each filter to remove or edit them as necessary. Step 1b (Right-click on a field) NOTE: Auto-Refresh Box By default, the Auto-Refresh box (click the “Query Settings” box under the Data Tab) is set as ON. This means that the query will attempt to “run” and refresh data each time you make a change.
To save loading time, you will want to turn Auto-Refresh OFF before adding any Columns (see next page).
Using the downward arrow button on a filter
Student Data Warehouse User Guide v.3.0 Page 16 Print date: 16 Sep 15 Advanced (Nested) Filters Note that there is a drop down linking each filter which shows boolean values (“AND”,”OR”). The default is “AND,” which will pull data that satisfies all the filter constraints. Switching it to “OR” pulls data that satisfies any of the filter constraints. For most queries, a single boolean relationship on all the filters will suffice. It is possible, however, to create nested filter relationships. As an example, in the query at right, the user wants to pull both graduate students (classes 10 and 20) and non-degree students (class 0) for a query involving enrollment data.
1. Add a filter on class_id from the student_semester table such that class_id is greater than 9. This will pull both class 10 and 20 (because class_id is a numeric field). Notice that this new filter is still in the same group as all the others. This is fine for now. 2. Add another filter on class_id from the student_semester table such that class_id equals 0. This new filter is also under the same “AND” grouping as the other filters. But now the report will pull no data, because it is impossible for a number to be both greater than 9 and equal to 0. 3. Click the downward arrow button ( ) next to the first class_id filter and choose Indent.
This creates a new subgroup with its own boolean drop-down. 4. Click the downward arrow button next to the second class_id filter and choose “Move Up.” This moves the filter up into the same subgroup.
5. Change the boolean drop-down for the subgroup to “OR.” This will now pull data where either class_id is greater than 9 or equal to 0. Note that Pentaho may re-order the filters in the Filters Pane to put subgroups at the top. This is normal. Note: It is possible to have a nested subgroup within a subgroup. However, please remember that the more complex the constraints, the longer it will take for Pentaho to generate the report results. Using Translation Tables as Filters Because most of the necessary table joins are made automatically in Pentaho, it is possible to use translation tables to filter data more easily.
In the example at the right, the user’s data and filters are all from the schedule table. However, the user only wants to show courses from a single department. 1. The course_id field is translated by the course table, so the user goes to that table and adds a new filter on the department_id field. 2. The report is now constrained by the new filter from the translation table. Step 1 Step 2 Step 3 Step 4 Step 5 Step 1 Step 2
Student Data Warehouse User Guide Page 17 Print date: 16 Sep 15 Adding columns via drag-and-drop Note: You can add a field as both a filter and a column.
Tip: You can also use this drop-down to add a filter based on a detail column or add a summary row to the end of the report based on this column (row count, sum, average, etc.). Removing columns via drag-and-drop Drop-down list (right-click on a column header) Columns (Details) Columns, also known as details, are the fields which show up in the report generated by your query.
1. Adding a detail field (or column) can also be done by one of three methods: • Drag-and-drop method 1: Click and drag a field onto the report preview. Columns will be added at the location indicated by the green vertical line. In this way, you can arrange and rearrange the order of columns. • Drag-and-drop method 2: Click the “Show Layout” button on the report toolbar to open the Layout pane. Drag a field from the list into the “Columns” box. These can be arranged and rearranged as above. • Right-click method: Right-click on the field you wish to add as a column and select “Add to columns.” The field will be added as the new right-most column.
• Double-click method: Double-click on the field you wish to add. It will be added to the report as the right-most column.
NOTE: After you have added columns, you can resize them much as you would in Microsoft Excel, by clicking on the border between two column headings and dragging it to the desired width. 2. To remove a column, use one of the following methods: • Click the “Show Layout” button to open the Layout panel. Then drag the column you want to delete out of the box. A trash can icon will appear; drag the column into the trash can to remove it. • Right-click on the header row for the column you wish to remove. From the drop-down list, select “Remove.”
Student Data Warehouse User Guide v.3.0 Page 18 Print date: 16 Sep 15 Groups Organizing a report by groups inserts subheadings based on a specific field (Example: grouping by major for a department report).
Groups are added in similar fashion to columns: 1. To add groups to report, use one of the following methods: • Click the “Show Layout” button on the report toolbar to open up the Layout pane. Drag a field from the list into the “Groups” box in the Layout pane. • Right-click on a field from the list and choose “Add to Groups” 2. To remove a group, you can use much the same method as removing a column: • Click the “Show Layout” button to open the Layout panel. Then drag the group you want to delete out of the box. A trash can icon will appear; drag the group into the trash can to remove it.
Note: If you typically export your report data to a plain text format, groups may not be as useful to you, especially if you plan on manipulating data by hand in Excel. Formatting Reports You can customize the look of your reports via the formatting tools available in the Interactive Report builder. Clicking the “Formatting” tab next to the “Data” tab on the left-hand side brings up these tools. To format an element of your report: 1. Select the element (column, column header, group, etc.) you wish to format by clicking on it in the Report Preview area (select multiple items by holding the CTRL key while selecting).
2. Switch to the Formatting tab. Using the tools in this tab you can: • Change the font (current choices are Arial, Courier New, or Times New Roman) • Change the text size • Make text bold or italic • Change the alignment of text in a field (left-aligned, right-aligned, or centered) • Change the text color or cell background color • Copy formatting from one element to another • Change the number format (e.g. use # . 00 to force rounding to two decimal places) Adding a group to a report Formatting tools Note: In order to change the formatting of values in a column, click on any cell in that column.
Clicking on the column header will only allow you to format the header.
Student Data Warehouse User Guide Page 19 Print date: 16 Sep 15 Changing the Report Title and Headers To edit the report title or a column/group header: 1. Double-click on the title/header in the Report Preview area. 2. Edit the text as necessary. 3. Either click outside the text box or hit ENTER. The report title will change as edited. Tip: You can use this to change the column headers on fields like mc_first_name and mc_last_name so they display as “LAST NAME” and “FIRST_NAME,” for example. Doing so does not change the field used, just the column header.
Using Parameters and Prompts Parameters are “alias” names given to filter fields which then allow those filters to be referenced by other elements of the report.
They allow, for example, the value of a particular filter field to be displayed as a report or column header. Most importantly, however, parameters can be used in prompts. Prompts give the person running a report the ability to specify values for filter fields before the report is run. This allows for writing general queries with prompts for the fields which may change based on situation (e.g., for a report run each semester, a prompt to enter the semester_id value).
The examples below show how to add parameters and prompts to a query. Adding a Parameter to a Filter 1. Create a new filter for the desired field, or click the appropriate “Edit” button in the Filters pane. 2. Enter the parameter name in the “Parameter Name” box at the bottom of the pop-up dialog. This will create the parameter based on this filter. Parameter names do not have to be all uppercase and can have spaces, but long names can become unwieldy. Using a Parameter in the Report Title/Headers Once you have given a filter a parameter name, you can use a special format to refer to it in either the report title or a group header (but not column headers).
Once you have done this, the value specified for that field will be filled in automatically wherever you reference it.
1. Double-click on the report title or group header to which you wish to add the parameter reference. 2. At the position where you wish the parameter value to appear, type $(name of parameter). Hit ENTER to make the changes. Note that the parameter name is case- sensitive. ↓ Changing the report title ↓ Adding a parameter name to a filter Using parameter name in report title
Student Data Warehouse User Guide v.3.0 Page 20 Print date: 16 Sep 15 Special Parameter Functions Built into the Interactive Report tool are a few generic parameter functions which can be used in the page header and footer (you will see some of these there by default, although you may edit them).
• PageofPages — Inserting $(PageofPages) anywhere in the page header/footer will cause the current page number and number of pages (e.g. 1/2) to display. So entering something like Page $(PageofPages) will display “Page 1/2.” This function is automatically entered in the page footer.
• report.date — Inserting $(report.date) anywhere in the page header/footer will cause the current date and time to display. You can choose the format by entering something like $(report.date, date, dd-MMM-yyyy), which will show up as, e.g. 01-Jan-2013. This function is automatically entered in the page header. • env::username — Inserting $(env::username) anywhere in the page header/footer will display the Andrew ID of the person running the report. Adding a Prompt 1. Drag a field onto the Prompts panel OR right-click on a field either in the Data sidebar or the Report Preview (to add a prompt for a column) and select “Prompt...” 2.
A default prompt will show up in the Prompts panel, but this is probably not completely correct. Click the Edit icon to open up the prompt editor.
3. Enter a Parameter name for your prompt. If the field you are using is also a filter with a Parameter name already set, it will be filled in automatically. 4. Choose the style of prompt you wish to use. The default is a drop-down list, but you may find yourself most often using the text box style (last option on the right): From left to right, these options are (1) drop-down list, (2) multi-select list, (3) radio button, (4) check-box, (5) text button, and (6) text box. 5. Set control properties in the bottom section, if necessary. 6. Click OK.
Tip: If using multiple prompts, you may want to uncheck the “Auto-Submit” box next to the “View Report” button, so that it will only refresh the report when you press “View Report,” and not each time you change a prompt value.
The default report.date format Editing the page header with the report.date function. Note that when editing the page header/footer sections special buttons appear to allow you to enter $(report.date) and $(PageofPages) quckly.
Student Data Warehouse User Guide Page 21 Print date: 16 Sep 15 Joining Tables A join between tables is a link created based on a common field, used as an index. Ordinarily, you will not have to make explicit joins in your queries, as necessary joins are made behind the scenes automatically. For example: • Every field that ends in _id is associated with a translation table which shares the same name, minus the _ id (e.g. college_id is translated by the college table, advisor_id is translated by the advisor table). These joins are automatic, so you can substitute a field translation for the _id field and the query will still work.
• Wherever tables share a common index field (e.g. course_id, student_key), they are nearly always joined automatically.
However, there are some common cases where joins are not made automatically: • Joining between two SEMESTER_ID fields not automatically joined (see p. 24). Examples: semester_id from schedule and student_semester, student_semester and degree_awarded/ student_major_minor. Note that although these tables all contain the student_key field, which is always automatically joined, they are not joined for their other common index field, semester_id (see p. 24) • Joining between MAJOR_MINOR_ID from STUDENT_MAJOR_MINOR and STUDENT_SEMESTER. When a student’s semester record is created, the major_minor_id field is copied from what is currently in student_major_minor.
However, updating one of these two fields does not automatically update the other, so they may be out of sync. Additionally, there are some cases (e.g. for undeclared students) where there is no major translation in student_major_minor for a combination that is legal in the student_semester table. • Note, however, that major_minor_id does join between student_semester and major_minor and between student_major_minor and major_minor.
• COURSE_RESERVATION_ID between COURSE_RESERVATION and SCHEDULE In the schedule table, the course_reservation_id field is typically not populated (i.e. it is usually blank), so joins on this field will typically fail. See p. 24 for more information on how to deal with situations where tables are not automatically joined.
Student Data Warehouse User Guide v.3.0 Page 22 Print date: 16 Sep 15 Common Automatically Joined Fields STUDENT_KEY The student_key field is a numeric field that uniquely identifies a student. It is unrelated to SSN/Student ID, Andrew ID, or Card ID, being assigned internally when a new student is added in S3.
For this reason, it is often also called “internal ID.” It serves as an index field to join between student-related tables. Because it always automatically joins tables, it should never need to be included in a query.
Tables joined via student_key: The following tables all contain the STUDENT_KEY field and so are always automatically joined. course_drop course_waitlist degree_awarded parent_guardian qpa schedule student student_address student_athletics student_major_minor student_phone student_semester transfer_credit COURSE_ID/SECTION_ID The course_id and section_id fields are used to tie together course-related fields for a particular course/ section. Tables which include a course_id/section_id field: Table COURSE_ID? SECTION_ID?
course x course_description x course_drop x x course_reservation x x course_semester x course_waitlist x x meeting x x schedule x x section x x section_instructor x x transfer_credit * x In general, all course-related tables (every table above othe than transfer_credit) will join automatically to the section table, with the exception of the course table, which only joins to course_semester.
*PLEASE NOTE: While the transfer_credit table does join to the course table, it does not generally interact well with tables other than student, given that the data in it is not related to actual courses a student has taken at Carnegie Mellon but merely courses for which a student has received credit. As such, it should not be used in conjunction with any of the tables on this list.
Student Data Warehouse User Guide Page 23 Print date: 16 Sep 15 DEGREE_NO Each degree entered for a student is identified by a degree_no, which represents the order in which the degrees were entered into SIS. For example, a student’s first degree would have degree_no = 1, the second would have degree_no = 2, and so on. It does not necessarily reflect the order in which a student completed each degree (or even the level of the degree), only the order in which they were entered. The degree_no field is used to join the degree_awarded table to the student_major_minor table. The join is automatic, but it may sometimes be useful to include degree_no as a Column (e.g., to help differentiate one degree from another when it is possible the same student earned multiple degrees).
DEGREE_AWARDED vs. STUDENT_MAJOR_MINOR The following chart lists the fields in both degree_awarded and student_major_minor (common index fields between both tables in bold type): DEGREE_AWARDED STUDENT_MAJOR_MINOR student_key student_key degree_no degree_no semester_id semester_id degree_id major_minor_type college_id college_id department_id department_id expected_graduation_semester major_minor_id date_degree_awarded with_honor date_updated date_updated user_updated user_updated overall_status status thesis_advisor terminal_degree majorfile_name Each degree_no in degree_awarded will match one (and only one) row in student_major_minor where major_minor_type = 1 (primary major) and possibly other rows where major_minor_type = 2 (additional major) or 3 (minor).
In the case where a student is earning a dual degree, two separate degree_awarded rows will exist, each with its own degree_no. Note that the semester_id in student_major_minor refers to the semester for which the major or minor was certified, such that an additional major or minor may be certified while the semester_id in degree_awarded is still blank (not yet certified). Certification status is shown by the status field in student_major_minor and overall_status in degree_awarded.
The following chart illustrates how the two tables are linked to store degree/major information: DEGREE_AWARDED degree_id, college_id, department_id, overall_status, with_honor, date_degree_awarded STUDENT_MAJOR_MINOR - Primary Major major_minor_type = 1 (primary); college_id, department_id same as degree_awarded; major_minor_id = major code; status, majorfile_name STUDENT_MAJOR_MINOR - Add’l Major (optional) major_minor_type = 2; college_id, department_id, major_minor_id for add’l major; status, majorfile_name STUDENT_MAJOR_MINOR - MINOR (optional) major_minor_type = 3; college_id, department_id, major_minor_id for minor; status, majorfile_name majors and minors linked to degree_awarded by degree_no and student_key
Student Data Warehouse User Guide v.3.0 Page 24 Print date: 16 Sep 15 What to do when tables are not automatically joined Background There are several common situations where you must use tables that are not automatically joined. Most of them involve the semester_id field. The semester_id field can be one of the trickiest fields to use in a query because it is so widespread. Each of the following tables contains a semester_id field: Student-Related Course Scheduling Other course_drop course_reservation semester degree_awarded * course_semester transfer_credit qpa course_waitlist schedule meeting student_major_minor * section student_semester section_instructor sisrooms In student-related tables, semester_id typically refers to the semester relative to that data.
For example, querying from the schedule table where semester_id exactly matches “S13” will return students’ courses and grades from the Spring 2013 semester; a student’s row in the student_semester table where semester_id exactly matches “F14” will contain all data in that table relative to the Fall 2014 semester; and so on. In course scheduling tables, semester_id typically refers to the semester in which a given course is offered or taken. Course information that does not change per semester is stored in the course table, which does not have a semester_id field. All other data about courses is subject to change each semester.
Classroom information stored in the sisrooms table can also change per semester.
The Big However However, there are two main cases where semester_id is not joined between tables: 1. Between all other tables and the degree-related tables degree_awarded and student_major_minor. In these two tables, the semester_id field refers to the semester of certification and so is blank until the degree/major/minor is certified. 2. Between any combination of the tables student_semester, schedule, and qpa. It is often necessary or desirable to query data from different semesters from these tables. For example, you may want to find a list of all students who are enrolled this semester and their semester QPA from the previous semester, or a list of all currently enrolled students who ever took a particular course.
For this reason, semester_id is not joined across these tables, so that these queries are possible.
What to Do When running queries containing fields which are not automatically joined (in nearly all cases, this is semester_id), you will need to include a filter for semester_id from both tables. This means there will be two nearly-identical filters in the Filters list. For this reason, • Note that filters appear in the list in the order they were added. So if you always add fields from student_semester before fields from schedule, for example, the student_ semester field will be above the other. • To avoid having to remember the order in which fields were added, use Parameter Names (p. 19), for example “SCH SEMESTER” and “ST SEMESTER,” so that you can tell which is which just by clicking on the Edit icon.
Student Data Warehouse User Guide Page 25 Print date: 16 Sep 15 Running Reports/Exporting data After you have created your query, you must export the data to save it to your computer. To export a query’s data, 1. Click the “Export Data” button. 2. Use the drop-down menu to select an output format: Query Output Formats Excel Microsoft Excel 2003 workbook CSV Comma-Separated Values— unformatted text file which can be imported easily into Excel or other programs. PDF Adobe PDF file — not editable. HTML Views as an HTML webpage, just as you would see in the report preview panel. This can be useful for viewing reports all at once, instead of page by page.
3. A new browser tab will open, and you will see a pop-up notification asking you whether to Open the file or Save it to your computer. You can choose either, but note that if you will be opening a .csv file to save it as an Excel document, it is better just to Open it. IMPORTANT: If the Auto-Refresh button is OFF, the report will only run with the placeholder data. Be sure Auto-Refresh is turned ON before exporting your query data. Steps 1-2 Step 3
Student Data Warehouse User Guide v.3.0 Page 26 Print date: 16 Sep 15 Saving Queries To save a query so that it may be run again or edited later, Whenever a query is opened for editing, new icons appear next on the toolbar next to the Drop-Down Menu, for Save and Save As.
These icons appear as a floppy disk (Save) and a floppy disk with pencil (Save As). 1. Click either button (choose Save As if you wish to save it as a copy). 2. In the Save/Save As dialog box, choose the location where you want to save it. The default will be your Home directory, but you can also save in the Public/SDW folder, or any folder to which you have appropriate permissions. 3. Enter a filename for your query. You do not have to keep the filename short, remember but long names can be unwieldy.
Sharing Files Once you have created and saved a new Interactive Report, you can share access to it with another user as well. 1. Login to SDW (see p. 10). 2. Click the Browse Files button, or choose “Browse Files” from the Drop-Down Menu. 3. Navigate to the folder where your query is located and select it in the Files box. In the File Actions list at the right- hand side of the screen, choose “Share.” 4. By default, files take the permissions of their folder. If the file should have different permissions, make sure the “Inherit folder permissions” box is unchecked. You can now add or remove users.
5. To set permissions for a user, select the appropriate Andrew ID from the “Users and Roles” list. 6. If the user or role is not on the list provided, click Add, then select the Andrew ID or role from the that list. The list shows all users with an S3 account, not necessarily those with SDW access. 7. For each user or role, select the specific permissions for the report: Manage (all permissions), Delete, Write (edit the file and save changes), Read (run the report). Note: If you would like to remove permissions from a person or role, select the appropriate Andrew ID/role and click Remove.
8. Click OK.
9. The person or role that you specified should now be able to view and run the saved report. Step 1 Steps 2-3 Tip: This same process works for all files and folders. However, for folders, you will click the “Properties...” option under “Folder Actions.”