BGSU PeopleSoft Query Course Query Manager Supplemental Material

Transcription

1 The supplemental material is a continuation of the topics covered in the workbook. The supplemental material was created to be used as a reference when creating queries. Queries can be difficult to create and manage. This material provides instructions on how to manage and organize queries to the importance of effective date usage and logical operators when adding criteria. The expressions section of this material provides step-bystep instructions on how to add multiplication and date format strings when adding expressions to specific fields. The section on Outer joins is worth looking at to better understand the where clause. Topics that are expanded on include (but not limited to): Effective Data and most common use for effective date logic in queries. Query organization importance including: o Copy a query to a User o Delete queries o Move queries to a folder o Rename queries Grouping criteria and the use of logical operators (and & or) Expressions and instructions on adding: o Mathematical o String Functions o Numeric Functions o Date Functions o Conversion Functions o Conditional Functions o Case Functions Outer Joins and the where clause. Aggregate queries Troubleshooting We hope that you find this documentation a helpful tool. However, there is nothing more helpful than finding a group of people that you can network with to discuss queries and the problems that you incur. Help is always available by ing bgat100@bgsu.edu. We always look forward to suggestion on how to improve this training material as well as how you use this documentation to assist in improving you process of creating queries. Page 1 of 51

2 Finding Records and Fields Normally a request for a query will be in the form of a question or a request for certain information. It will usually not come with the fields, records, and criteria given to you directly. Instead, it will be like a story problem. You ll be responsible for translating the request into a query that PeopleSoft understands. What if you don t already know where to find the information? Use the Advanced Search capabilities. You can search by record name, description, and fields used in a record, among others. For instance, if you know a query is about programs, you can search for records having program in the description or PROGRAM in the name. If this does not provide enough options or any correct ones, try abbreviations such as PGM and PROG. You could also search for records having a field with PROG in the name. Look at the descriptions. When you search for records, the description of each record is given along with the name of the record. When you show fields in a record, the description of each field is displayed. Ask the requestor to show you where the underlying data is in PeopleSoft. If he or she can show you some pages, you can get some field labels that may appear in the descriptions of fields. If the requestor shows you a field labeled Contact Person, then you can search for records that have fields with descriptions containing contact or person or names containing PERS. Use references that others have created. Lori Beeman created several lists of records and their descriptions as hierarchies, so you not only get the internal names of the records, but see which records are related to each other as parents and children. Ask your coworkers. Page 2 of 51

3 Effective Date, Effective Sequence, and Effective Status Frequently there is a need to keep track of the history of changes to something in a database. The status of a student will change as he applies to a program, matriculates, possibly adds minors, and completes that program. There may also be a need to retain information about something, such as its name, flags, and amounts. In addition, to aid in planning ahead, there may be a need to store something that will come into effect in the future. PeopleSoft uses special fields in many records to enable having data effective only at certain times Effective Date (EFFDT), Effective Sequence (EFFSEQ), and Status as of Effective Date (EFF_STATUS). Basics of Effective Data Effective Date is the most commonly used of these three fields; the other two fields will not be in a record without an EFFDT field. It indicates that the record is effective as of a certain date. This concept may be easiest to understand using an example. Consider the following rows of ACAD_PROG_TBL, which contains information about academic programs. INSTITUTION ACAD_PROG EFFDT EFF_STATUS DESCR ACAD_CAREER ACAD_CALEND AR_ID BGSUN ARTSC 8/29/1982 A College of Arts and UGRD USEM Sciences BGSUN ARTSC 9/26/1971 A College of Arts and UGRD UQTR Sciences BGSUN ARTSC 9/24/1968 A College of Liberal Arts UGRD UQTR BGSUN ARTSC 1/1/1910 A College of Liberal Arts UGRD USEM The row with the highest EFFDT that is not in the future contains the information current for today. In the example above, since August 29, 1982, the name of the arts and sciences program has been College of Arts and Sciences and the academic calendar was based on semesters (USEM). From September 26, 1971 through August 28, 1982, the name was the same, but the calendar was based on quarters (UQTR). If there is an Effective Date field in a record, the Effective Date is always part of the key, and it is the last part of the key unless there is also an Effective Sequence. The Effective Date applies to all of the key fields preceding it. In the example, EFFDT applies to the combination of INSTITUTION and ACAD_PROG. The Effective Date for program ARTSC does not indicate when data for effective for program BUSN, program MUSIC, etc. Page 3 of 51

4 By convention, the Effective Date used for the first instance of something that is effective dated is 1/1/1900 for base PeopleSoft data and 1/1/1910 for data added by BGSU. If it is likely for there to be several changes to something on the same day, an Effective Sequence field is included in the record. This is a number that starts at 0 on a particular day and increases by 1 for each change to that something (identified by key) on that day. The most current information has the highest non-future EFFDT and the highest EFFSEQ for that EFFDT. Again, an example can more clearly demonstrate this concept. EMPLID EMPL_RCD EFFDT EFFSEQ DEPTID JOBCODE SUPERVISOR_ID HR_STATUS ACTION /20/ I TER /29/ A DTA /29/ A HIR Employee 9106 was hired on 7/29/2007, into department under supervisor 1316; this is shown in the row with EFFDT of 7/29/2007 and EFFSEQ of 0. Later that day, the employee was transferred to department with supervisor 2164; this is shown in the row with EFFDT of 7/29/2007 and EFFSEQ of 1. This assignment was effective until the employee s termination on 4/20/2008. There may be cases in which something is deactivated or will be deactivated or is added to the database before it will become effective. These cases are handled by using a Status as of Effective Date field. Consider these two examples from ACAD_PLAN_TBL, which contains information on academic plans (majors). INSTITUTION ACAD_PLAN EFFDT EFF_STATUS DESCR ACAD_PLAN_TYPE ACAD_PROG DEGREE BGSUN AERO-BSTC 8/25/2015 I Aerotechnology MAJ TECH BSTC BGSUN AERO-BSTC 1/1/1910 A Aerotechnology MAJ TECH BSTC The above rows indicate that the Aerotechnology major, with a Bachelor of Science in Technology degree (DEGREE = BSTC ) upon graduation, is active (EFF_STATUS = A ) until 8/24/2015. On 8/25/2015, it will become inactive (EFF_STATUS = I ). This means that AERO-BSTC will be inactive in the future but is active now. INSTITUTION ACAD_PLAN EFFDT EFF_STATUS DESCR ACAD_PLAN_TYPE ACAD_PROG DEGREE BGSUN THEA-BSJ 5/18/2008 I Theatre MAJ ARTSC BSJ BGSUN THEA-BSJ 1/1/1910 A Theatre MAJ ARTSC BSJ The second example shows that plan THEA-BSJ a Bachelor of Science in Journalism (BSJ) for Theatre was active until 5/17/2008 and was discontinued on 5/18/2008, placing it in an inactive status. This means that THEA-BSJ is currently inactive. Page 4 of 51

5 Using Effective Data in Queries The most common use of effective date logic in queries is to report only active data current at the time the query is run. This may be referred to as the maximum non-future effective date. Writing effective date logic manually involves adding a subquery on the same record as in the main query, joining on all key fields except for the date. This can be cumbersome for records with many fields in the key. makes this unnecessary! When you add a record that has an Effective Date field to a query, an effective date criterion is automatically added to the query. A message stating this appears as soon as you add that record. You can see this criterion in the Criteria tab as Eff Date <= Current Date. You can change the criterion to look at the date in a field, expression, or a specific date of your choice. You can also show rows having the first effective date or last effective date regardless of whether the effective date is in the future. If the record also has an Effective Sequence field, the criterion will be Eff Date <= Current Date (EffSeq = Last), indicating that only the last row created on the effective date will be included in the results. You can edit this criterion to use the first row instead of the last or to show all rows regardless of Effective Sequence. If you accidentally delete a criterion on Effective Date, you can add one manually. If you choose EFFDT as a field in the criterion, you can choose from special Condition Types that apply only to effective dates: Eff Date < effective date is less than the selected date Eff Date <= effective date is less than or equal to the selected date Eff Date > effective date is greater than the selected date Eff Date >= effective date is greater than or equal to the selected date First Eff Date effective date is the earliest for the key Last Eff Date effective date is the latest for the key The selected date can be the current date, a constant, a value in a field, or the result of an expression. Recall that effective dates are tied to keys, so First Eff Date refers to the row having the earliest effective date for all rows having the same values in their key fields (except Effective Date and Effective Sequence). does not automatically add criteria on Status of Effective Date. If you are interested in only active or only inactive rows, you must manually add the criterion on EFF_STATUS to your query. There are just two possible values of EFF_STATUS: A for active and I for inactive. Page 5 of 51

6 Query Organization As the number of queries that you work with grows, you may want to group them by purpose, department, or other characteristics. You might also want to send them to other users, rename them, or delete old ones. enables you to organize your queries in a manner similar to how you may organize your files with Explorer or My Computer in Windows. However, there are some important differences. Files in a file system are uniquely identified by an internal ID. Two or more files can have the same name, though such files usually must be stored in different folders. Queries are uniquely identified by name in a storage area; two queries in the same user s storage space cannot share the same name even if they are in different folders. Two queries can only have the same name if they are in two different users private storage. No private query can have the same name as a public query. Queries may be grouped into folders. This can aid in finding queries in a large institution, since you can search for only those queries that are in a particular folder. This is similar to storing files in different folders or directories in a file system. However, unlike with file systems, you cannot store a folder inside another folder. With, there are only two levels of folders: inside a folder and not inside a folder. With a file system, you must create new folders and delete unneeded folders manually. implicitly creates a folder when you save or move a query to a folder that does not already exist. also automatically deletes a folder when you remove the last query from that folder. Page 6 of 51

7 Copy a Query to a User It may be useful to send a query to another user if that user needs to make minor modifications before running it, to see how it was built, or to run the query with different row-level security than that of the first user. enables you to copy a query to another user s storage space. To copy a query to another user, do the following: o From the search page, search for the query to be copied. In the row for the query in the Search Results area, check the Select checkbox. (You may copy multiple queries by checking the checkbox corresponding to each query to be copied.) o o From the Action dropdown, choose Copy to User. Click the Go button. o o Enter the User ID of the user who will receive the query. Click the OK button. If the copy is successful, you will receive a message confirming this. Page 7 of 51

8 If the receiving user does not have access to the records in the copied query, that query will not appear when the receiving user searches for queries. A public query cannot be copied to another user because this would result in a private query having the same name as a public query. If you want to copy a public query, the receiving user must edit the query and save it to his or her private storage. (See the Save a Query with a New Name segment.) A query cannot be copied to another user if that user has a query with the same name; you cannot overwrite an existing query by copying one. Page 8 of 51

9 Delete a Query Deleting unneeded queries, such as those that are out of date, or created as a test, can be done easily through. To delete a query, do the following: o From the search page, search for the query to be deleted. In the row for the query in the Search Results area, check the Select checkbox. (You may delete multiple queries by checking the checkbox corresponding to each query to be deleted.) o o From the Action dropdown, choose Delete Selected. Click the Go button. When asked to confirm the deletion, click the Yes button. If the last query is deleted from a folder, that folder is also deleted. It is possible for you to delete a public query. Be very careful when selecting queries to delete since you may accidentally delete a query someone else needs! Page 9 of 51

10 Move a Query to a Folder It can be useful to group queries with a similar purpose or for the same department or college into a folder. Both Query Viewer and allow you to search for queries by a folder name and filter the results of a search for queries by a folder name. To move a query to another folder, do the following: o From the search page, search for the query to be moved. In the row for the query in the Search Results area, check the Select checkbox. (You may move multiple queries by checking the checkbox corresponding to each query to be moved.) o o From the Action dropdown, choose Move to Folder. Click the Go button. A Move to Folder page appears. o To move the selected query or queries to an existing folder, click the Select an existing folder to move to radio button and choose a folder from the dropdown. o To move the selected query or queries to a new folder, click the OR enter a folder name to move to radio button and enter a folder name in the text box. A folder name may be at most 18 characters long. *Make sure to both click a radio button and choose a folder Page 10 of 51

11 o Click the OK button. * will take the action indicated by the radio button. If you enter a new folder name but do not click the second radio button, the query will be moved to whatever existing folder is showing in the dropdown! If the last query in a folder is moved out of that folder, the folder is deleted. If a new folder name is entered and a query is moved to it, a folder with that name is automatically created. To move a query so that it is not in any folder, move it to a folder with a blank name. Private queries remain private after being moved. Similarly, public queries remain public after being moved. It is possible for you to move a public query to another folder. Be very careful when selecting queries to move since you may accidentally move a query someone else needs! Page 11 of 51

12 Rename a Query On occasion, you may want to change the name of a query to make it easier to identify, correct a spelling mistake, or reduce confusion with another query. To rename a query, do the following: o From the search page, search for the query to be renamed. In the row for the query in the Search Results area, check the Select checkbox. (You may rename multiple queries by checking the checkbox corresponding to each query to be renamed.) o o From the Action dropdown, choose Rename Selected. Click the Go button. o o Enter a new name for each selected query next to the old name of each query. Click the OK button. Renaming a query does not change who owns the query or the folder in which it is stored. You cannot rename a query such that it has the same name as a private query in your storage area or a public query. WARNING It is possible to rename a public query. Be very careful when selecting queries to rename since you may accidentally rename a query someone else needs. Page 12 of 51

13 Save a Query with a New Name There are instances in which you may want to give a query a new name while keeping the existing query intact instead of renaming it. These include testing changes to a query and retaining historical versions of a query. To save a query with a new name, do the following: o From the search page, search for the query to be saved with a new name. In the row for the query in the Search Results area, click the Edit link. At the bottom of any tab page except Run, click the Save As link. o o o Enter a new name in the Query text box. Enter a new description or folder name or change the Owner between Private and Public if desired. Click the OK button. You can overwrite an existing query by saving a query with the same name as an existing query. If you attempt this, you will be told a query with that name exists and asked if you want to continue. Click Yes to overwrite or No to abandon the save. You cannot save a query to your private storage such that the query has the same name as a public query. No change is made to the original query. It is possible for you to overwrite a public query by saving a query with the same name as another public query. Be very careful when saving a public query since you may accidentally overwrite a query someone else needs. Page 13 of 51

14 Grouping Criteria and the OR operator On some occasions, you will need to write a query that returns rows that meet some criteria, but not all of them. For instance, you may be asked to limit the results to those for which the program status is either AC or LA. This could be implemented using the criterion PROG_STATUS in list AC, LA, but if the criteria involve multiple fields or cannot be enumerated in a list, you will need to create multiple criteria and link them with the OR operator. When you add criteria to a query, by default they are linked with the AND operator. This means that in order for a row to be included in the results, criterion 1 and criterion 2 and criterion 3 etc. must all be met. With an OR operator, if criterion 1 is true or criterion 2 is true, then the row will be included (assuming the other criteria are also met). Note that if both criterion 1 and criterion 2 are true, the row will still be in the results; it is only required that one of the criteria be met. Choosing Logical Operators To change the operator linking two criteria, go to the Criteria tab and select the operator from the Logical column. For the first criterion, you can only select NOT to negate that criterion. For the other criteria, you can choose AND, AND NOT, OR, and OR NOT. Typically you will use this to change from AND to OR. In the screen shot below, the AND operator links the criterion above (A.EFFDT <= Current Date) and the criterion in the same row (A.INSTITUTION equal to BGSUN). The operators are called Logical because they operate on values that are either true or false. Each criterion has a comparison that produces a true result or a false result. In a row in which INSTITUTION is BGSUN, the criterion A.INSTITUTION equal to BGSUN evaluates to true. Page 14 of 51

15 Grouping Criteria There is an important consideration when using both the AND and OR operators in a query. As in mathematics, there is a defined order of operations. The AND operators are given higher priority than OR operators. The AND operator is roughly equivalent to multiplication and the OR operator is roughly equivalent to addition in this sense. You can use parentheses to affect how the criteria are grouped, usually with the goal of combining the criteria linked with OR operators. Consider an example in which you are asked to list the academic program (ACAD_PROG record) information about students who are at BGSU (INSTITUTION = BGSUN ) in the Arts and Sciences program (ACAD_PROG = ARTSC ) and were either admitted in Fall 2006 (ADMIT_TERM = 2068 ) or completed the program in Spring 2006 (COMPLETION_TERM = 2062 ). Note that academic program data is effective dated. Here is a first attempt at building these criteria in our query: Below is an excerpt from the results returned by the query: Row 601 matches what was expected since the program is ARTSC and the admit term is Fall However, row 602 doesn t match what was intended; while the completion term is Spring 2006, the program is MAST. This row was included because it meets the COMPLETION_TERM equal to 2062 criterion. Recall that in a case of criteria linked by an OR operator, either what is before the OR or after the OR must be true to be included in the results. There are four criteria Page 15 of 51

16 linked by AND operators before the OR, so either these four criteria in combination must be true or the one criterion after the OR, have to be met for the row to appear among the results. In order to have the query worked as intended that the results are all in the ARTSC program and that either the admit term is Fall 2006 or the completion term is Spring 2006 parentheses are needed. To add parentheses to a query, go to the Criteria tab and click the Group Criteria button. The Edit Criteria Grouping page appears. In the column between Logical and Expression 1, you enter an opening parenthesis ( before the first criterion in the group that you want to create. In the column to the right of Expression 2, you enter a closing parenthesis ) after the last criterion in the group. In this case, we are creating a group containing the criterion on ADMIT_TERM and the criterion on COMPLETION_TERM. Parentheses are added are indicated in the screen shot below: Click OK to confirm the changes to the grouping. The parentheses are displayed on the Criteria page. Page 16 of 51

17 This shows that the two criteria on ADMIT_TERM and COMPLETION_TERM are now to be evaluated first. If either ADMIT_TERM is equal to 2068 or COMPLETION_TERM is equal to 2062, the result of the OR operation will be true. If neither of these are true, the result of the OR operation will be false, which will cause the row to be excluded. Running the modified query produces results like the following: Observe that all of the rows in the result set have either the admit term of Fall 2006 or the completion term of Spring 2006, and that no matter which of the two terms match the criteria, the academic program is ARTSC. In general, if you are going to use the OR operator in a query, you will likely need to group criteria together using parentheses. Page 17 of 51

18 Wildcards Wildcards are symbols that substitute for other characters in search strings. They act much like wild cards that can be used as if they were any other card in a card game. The primary use of wildcards in queries is to find rows in which a text field contains a string rather than equals a string. You may want to find instances in which that text has a particular word or a set of consecutive characters. In the Edit Criteria Part 2 segment, you learned about the like condition type, which allows you to find rows in which a text field is like a word or phrase, meaning the field contains that word or phrase. To use like in this manner, you must employ wildcards. (If you have no wildcards in your constant, then like is the same as equal!) There are two wildcards that you can use in queries. The percent sign (%) is used to substitute for zero or more characters. The underscore (_) is used to substitute for any single character. The use of wildcards is best demonstrated through examples. Consider the following search strings that use wildcards and some string that would match them. Search String Value in Field Match? Reason abc% abc Yes Starts with abc and is followed by zero characters abcd Yes Starts with abc and is followed by one character abcdefgh Yes Starts with abc and is followed by many characters ab No Does not start with abc abz No Does not start with abc aabc No Does not start with abc (even though abc is in the value) %def def Yes Begins with no characters and ends with def cdef Yes Begins with one character and ends with def abcdef Yes Begins with many characters and ends with def ef No Does not end with def ref No Does not end with ref deff No Does not end with def (even though def is in the value) %ghi% ghi Yes Begins with no characters, followed by ghi, followed by no characters efghi Yes Begins with several characters, followed by ghi, followed by no characters ghijk Yes Begins with no characters, followed by ghi, followed by no characters efghijk Yes Begins with several characters, followed by ghi, followed by no characters efgghiijk Yes Begins with efg, followed by ghi, ending with ijk efgjk No Does not contain ghi efgpijk No Does not contain ghi gh No Does not contain ghi a_c abc Yes a followed by one character followed by c a7c Yes a followed by one character followed by c ac No No characters between a and c Page 18 of 51

19 Search String Value in Field Match? Reason abbc No Too many characters between a and c Criteria and Case-Sensitive Data Criteria that involve textual data use case-sensitive comparisons. This means that hello and Hello are two distinct values that are not considered to be equal. If your query has a criterion that DESCR is equal to Psychology department but the row for this department has a DESCR of Psychology Department (note the capital D), the row will not be included in the results. By convention, codes such as those used for statuses and types are fully uppercase, to prevent issues of case sensitivity from arising and from having codes that are the same except for case. (It would be confusing to have AC, Ac, and ac all as valid options having different meanings for the same field!) In queries that use criteria involving codes, make sure to enter the code using all uppercase letters. (If the field is defined in PeopleSoft as allowing only uppercase letters, then your value will be transformed to uppercase. However, not every field that has codes is defined in this manner.) Consider exercise 6B, in which you are obtaining a list of item types that have Fine in the description. The current data is set up such that Fine is always capitalized. What if this was not the case? How might you work around this? One alternative is to have two criteria, one which checks if DESCR contains Fine and one which checks if DESCR contains fine. Note that because of the other criteria in the query, it is necessary to group the two criteria on DESCR in parentheses, and use the OR operator instead of the AND operator on those criteria. (We want rows in which either the description contains Fine or the description contains fine. ) Another alternative is to use an expression to convert DESCR to a known case either uppercase or lowercase and compare that against a constant in the same case. Page 19 of 51

20 In this example, we check if the uppercase version of DESCR, returned by the expression UPPER(A.DESCR), contains the text FINE, which is also in uppercase. Cases of Fine and fine will be matched since the comparison will be against their uppercase equivalent, which is FINE for both. Key Fields An important aspect of relational database structure is that information about an object is separated into multiple tables, with each table having data about a certain set of characteristics. For instance, in PeopleSoft, the PERSON record is the basis of personal information, the NAMES record contains the names of each person, and the ADDRESSES record has the postal and physical addresses of each person. The data about one person is spread in PERSON, NAMES, ADDRESSES, and other records. In order to collect the data about a person, the relevant records must be joined together in a query. The database management system needs to know how to find the data in one record based on data in another. This is done through the use of key fields. Primary Keys A primary key is a field or set of fields that uniquely identifies an object. No other object can have the same primary key as another. No two cars have the same vehicle identification number (VIN). No two dollar bills have the same serial number. In PeopleSoft, no two people can have the same employee ID number, so the primary key of the PERSON record is EMPLID. A primary key may contain multiple fields. For instance, the primary key of STATE_TBL is the combination of COUNTRY and STATE. The state abbreviation or code alone cannot uniquely identify a state or province; the code MI represents the province of Misiones in Argentina, the province of Milano in Italy, the state of Michigan in the United States, and the state of Miranda in Venezuela. However, all countries have a unique code, and no country has two states with the same code, so the country and state codes together can uniquely identify a state. The province of Misiones is identified by country code ARG and state code MI whereas Michigan is identified by country code USA and state code MI. When tables have a parent-child relationship, the primary key of the parent is contained within the primary key of the child. This enables all children rows of a parent row to be found by joining the tables on the primary key fields. A query for gathering information from both COUNTRY_TBL and STATE_TBL would join these two tables on COUNTRY; the COUNTRY field is the primary key of COUNTRY_TBL and is part of the key of STATE_TBL, the child table of COUNTRY_TBL. When using a hierarchy join in Query Manager, the parent and child records are automatically joined on the fields their primary keys have in common. The primary key is generally the first field or fields in the list of fields of a record. In, the primary key is indicated on the Query tab by a key icon. Page 20 of 51

21 Foreign Keys A foreign key is a field or set of fields that refer to the primary key of another table. These are typically used for restricting data in a field to only allowable values and to reduce data duplication. For example, in the ADDRESSES record, there is both a COUNTRY and a STATE field; these in combination are a foreign key to STATE_TBL. It will not be possible to enter a country/state combination that does not exist in STATE_TBL into an address. In order to get information about a state, such as its full name, one would have to join a record to STATE_TBL using both COUNTRY and STATE. A related record join in automatically joins the foreign key of one record to the primary key of another record. Page 21 of 51

22 Keep in mind that when you are manually joining two records by adding criteria that you will likely need to add them for every field in the foreign key. In the exercise in which DEPT_TBL was joined to PERSON_NAME, you had to add a criterion that requires that MANAGER_ID of DEPT_TBL was the same as EMPLID of PERSON_NAME; EMPLID is the primary key of PERSON_NAME. Keys with Effective Dates The PeopleSoft database design includes the concept of effective data (see Effective Date, Effective Sequence, and Effective Status elsewhere in this manual), in which information about an object is recorded at different points in time, and the history about that object can be retrieved. When effective data fields are in a record, they are considered to be part of the primary key. This is because the date (and sequence, if used) helps uniquely identify the information about an object at a point in time. Consider the following rows of ACAD_PROG, which contains data about the programs in which a student is participating and has participated. EMPLID ACAD_ STDNT_ EFFDT EFFSEQ INSTITUTION ACAD_PROG PROG_STATUS PROG_ACTION CAREER CAR_NBR 1379 UGRD 0 1/12/ BGSUN EDUC AC PLNC Page 22 of 51

23 EMPLID ACAD_ STDNT_ EFFDT EFFSEQ INSTITUTION ACAD_PROG PROG_STATUS PROG_ACTION CAREER CAR_NBR 1379 UGRD 0 1/7/ BGSUN EDUC AC PRGC 1379 UGRD 0 8/20/ BGSUN ACEN AC ACTV Student 1379 entered the Academic Enhancement program on 8/20/2007, then switched to Education & Human Development on 1/7/2008, then changed a plan within that program on 1/12/2009. All three of the rows are about the same student s participation, but represent different states of that participation by date. The EFFDT and EFFSEQ fields help uniquely identify the state of participation by using these fields, one can find out which program a student was in at a given point in time. The full primary key of ACAD_PROG is the combination of EMPLID, ACAD_CAREER, STDNT_CAR_NBR, EFFDT, and EFFSEQ. When joining records that have effective data fields, one must be careful to consider whether or not it is appropriate to join on EFFDT (and EFFSEQ, if present). If a parent has effective data fields and it is being joined to a child record, then the join must include EFFDT. For example, the service indicator code record SRVC_IND_CD_TBL has a key of INSTITUTION, SRVC_IND_CD, and EFFDT. The reasons belonging to service indicators are in SRVC_IN_RSN_TBL and have a key of INSTITUTION, SRVC_IND_CD, EFFDT, and SRVC_IND_REASON. To join information on codes and reasons together, one must join on INSTITUTION, SRVC_IND_CD, and EFFDT, to ensure that the reason data is linked to the proper code. However, when there is not a parent-child relationship, then EFFDT will not be part of the join. Data about academic plans is in ACAD_PLAN_TBL and the key is INSTITUTION, ACAD_PLAN, and EFFDT. Data about subplans is in ACAD_SUBPLN_TBL and the key is INSTITUTION, ACAD_PLAN, ACAD_SUB_PLAN, and EFFDT. The key of ACAD_PLAN_TBL is not contained in the key of ACAD_SUBPLN_TBL; the effective date in ACAD_PLAN_TBL is about the plan whereas the effective date in ACAD_SUBPLN_TBL is about the subplan. To join these two records, use INSTITUTION and ACAD_PLAN alone. automatically takes care of these considerations. When performing a hierarchy join, the EFFDT (and EFFSEQ, if needed) field used as part of the join. When performing a related record join, EFFDT will be left out of the join. With a manual join (such as between ACAD_PLAN_TBL and ACAD_SUBPLN_TBL), will not detect EFFDT as a possible field for the join criteria that can be automatically added. Page 23 of 51

24 Page 24 of 51

25 What is a View? A view is a special kind of query. It is a query that acts like a table in queries. Many views are delivered with PeopleSoft and developers can add their own. (However, this cannot be done through.) Views are created for many purposes: Save a commonly-used subquery so that it does not need to be rewritten in several queries Reduce the number of fields returned from a table Return only current rows so that effective date logic need not be added to the main query Join data from many tables together into one convenient result set that can be used as if it were a table In, tables and views are both considered records, so you will see no difference in how they are used. By convention, views in PeopleSoft often have names ending with VW, though some have names just containing VW. You may find it beneficial to use views when they are available, as they can simplify your queries by hiding some details like fields, joins, and effective date logic. Expressions Recall from the class that expressions are calculations, usually performed on fields from the records in your query, which produce a result. The result can be text, a date, or a number, and may be displayed and used in criteria as if it were a real field. Reference fields in expressions by using their actual name, not their description and preceding the name with their alias and a period. For example, if you have SAL_GRADE_TBL aliased as A and want to use field MID_RT_ANNUAL in your expression, refer to the field as A.MID_RT_ANNUAL (without the quotes). Reference prompts by using a colon followed by the prompt number, such as :1 (without the quotes). One type of calculation that can be performed is mathematical. You can add, subtract, multiply and divide numeric values. The mathematical operators are: + (addition) - (subtraction) * (multiplication) / (division) Standard mathematical order of operations (multiplication and division are done before addition and subtraction; computation goes from left to right) is used. Parentheses can be used to group calculations together and force them to be done out of this order. Page 25 of 51

26 The only operator that applies to strings is concatenation, which is appending one string to the end of another string. The concatenation operator is the double pipe,. (The pipe character can usually be entered by holding down the Shift key while pressing the backslash \ key, which is normally above the Enter key.) For example, if A.STR1 contains ABC and A.STR2 contains DEFG, then A.STR1 A.STR2 results in ABCDEFG. There are not operators that perform calculations on two dates. You can add to or subtract from a date. The numeric value is translated into a number of days. If A.START_DT is 2/13/2009 then the expression A.START_DT + 7 results in 2/20/2009. If the numeric value is a decimal amount, then the time will also be affected. If A.START_DT is 2/13/ :00 AM then the expression A.START_DT results in 2/13/ :00 PM. Expressions can also contain functions, which take some input values and return an output value. Functions operate similar to how they do in mathematics. The familiar square root operation can be considered a function; it takes an input value and returns the value that, when multiplied by itself, produces the original value. Some common mathematical functions are even written similar to how functions appear in queries; the sine function in trigonometry is written as sin(x), indicating that it accepts one value. Functions in expressions are of the form FUNCTION_NAME(arg1, arg2,, argn), where FUNCTION_NAME is the name of the function and arg1, arg2, etc. are its arguments, which are the input values. When using a function in an expression, the name must be spelled exactly as expected, the argument list must be enclosed in parentheses, all arguments must be separated by commas, and all required arguments must be given. (There are sometimes optional arguments. In documentation these are frequently indicated by enclosing the argument in [square brackets].) *** Note on functions: the functions listed below are for use in Oracle databases version 10 and higher; BGSU is currently using Oracle 10g. Other databases, such as DB/2, Informix, and Sybase, may support different functions. String Functions Here are some functions that can be used on strings: CONCAT(str1, str2) The CONCAT function concatenates str1 and str2, returning str1 followed immediately by str2. Equivalent to str1 str2. Page 26 of 51

27 LENGTH(str1) LENGTH returns the length of str1 in number of characters. For example, LENGTH( ABC DEF ) returns 7 (the space is included). LOWER(str1) LOWER returns a copy of str1 with all uppercase letters changed to lowercase. SUBSTR(str1, start[, how_many]) SUBSTR returns the substring a part of a string of str1, starting at position start. If how_many is not provided, all characters from start through the end of the string are returned. If how_many is provided, the substring beginning at position start and having a length of how_many are returned. Examples: SUBSTR('ABCDEFG', 1, 3) returns 'ABC' SUBSTR('ABCDEFG', 3, 4) returns 'CDEF' SUBSTR('ABCDEFG', 4) returns 'DEFG' UPPER(str1) UPPER returns a copy of str1 with all lowercase letters changed to uppercase. Numeric Functions Here are some functions that can be used on numeric values: ABS(n) ABS returns the absolute value of n. If n is positive or zero, the result is n. If n is negative, the result is n without the negative sign. For example, ABS(-5) returns 5. CEIL(n) CEIL returns the ceiling of n, which is the smallest integer equal to or greater than n. For example, CEIL(5.2) is 6, since 5 is not equal to or greater than 5.2, but 6 is greater than 5.2. Note that CEIL(-4.4) is -4. CEIL is equivalent to rounding up. FLOOR(n) FLOOR returns the floor of n, which is the largest integer equal to or less than n. For example, FLOOR(8.7) is 8, since 9 is not equal to or less than 8.7, but 8 is less than 8.7. Note that Page 27 of 51

28 FLOOR(-3.2) is -4. FLOOR is equivalent to rounding down. ROUND(n[, dec]) ROUND returns n rounded to dec decimal places, or to the nearest integer if dec is not provided. If dec is negative, the value is rounded to dec powers of 10 (-1 to the nearest 10, -2 to the nearest 100, etc.). Examples: ROUND(12.3) returns 12 ROUND(12.8) returns 13 ROUND(-12.3) returns -12 ROUND(-12.8) returns -13 ROUND( , 2) returns ROUND( , 1) returns ROUND( , 0) returns ROUND( , -1) returns ROUND( , -2) returns SQRT(n) SQRT returns the square root of n. The square root is the number, which multiplied by itself, results in n. TRUNC(n[, dec]) TRUNC returns n truncated to dec decimal places. If dec is zero or not provided, all digits after the decimal are dropped. If dec is negative, ABS(dec) digits to the left of the decimal are replaced by zero, and all digits after the decimal are dropped. Examples: TRUNC(12.3) returns 12 TRUNC(12.8) returns 12 TRUNC(-12.3) returns -12 TRUNC(-12.8) returns -12 TRUNC( , 2) returns TRUNC( , 1) returns TRUNC( , 0) returns TRUNC( , -1) returns TRUNC( , -2) returns Page 28 of 51

29 Date Functions Here are some functions that can be used on dates: ADD_MONTHS(dt, m) ADD_MONTHS returns the date that is m months in the future of dt. SYSDATE SYSDATE returns the current system date and time. Note that it does not take any arguments. Conversion Functions Here are some functions that can be used to convert values from one type (date, number, string) to another: TO_CHAR(dt[, fmt]) TO_CHAR converts a date or part of a date into a string. If fmt is not provided, the date is returned in the default format for the system, usually DD-MON-YY. (In this format, 2/13/2009 would be 02-FEB- 09.) The fmt argument is a string containing codes that instruct TO_CHAR how to format the date. There are many different format codes and several can be used at one time. Some of the format codes are: AM the AM/PM indicator DD day of the month HH hour of the day (1-12) HH24 hour of the day (0-23) MI minute of the hour (0-59) MM month (1-12, with 1 = January) MON three-character abbreviation of the month SS second of the minute (0-59) YY two-digit year YYYY four-digit year Punctuation such as dashes, colons, and slashes are included in the result string in the positions given in the fmt. Page 29 of 51

30 Assume the current date is March 15, 2009 and the time is 4:25 PM. Here are several examples of how TO_CHAR would display this date: TO_CHAR(SYSDATE, 'MM/DD/YYYY') returns 03/15/2009 TO_CHAR(SYSDATE, 'DD/MM/YYYY') returns 15/03/2009 TO_CHAR(SYSDATE, 'YYYYMMDD') returns TO_CHAR(SYSDATE, 'HH:MI') returns 04:25 TO_CHAR(SYSDATE, 'HH24:MI') returns 16:25 TO_CHAR(SYSDATE, 'MM/DD/YYYY HH24:MI:SS') returns 03/15/ :25:00 TO_CHAR(SYSDATE, 'MM') returns 03 (this could be used for grouping in order to aggregate results by month!) TO_CHAR(n[, fmt]) TO_CHAR can also convert a number to a string. If fmt is not provided, a default format will be used. This function is typically used to format numbers with commas, periods, currency symbols, and leading zeroes. The fmt argument is a string containing codes that instruct TO_CHAR how to format the number. There are many different format codes and several can be used at one time. Some of the format codes are: $ display a dollar sign 0 display a leading zero 9 display a digit, display a comma. display a period FM disable leading and trailing spaces Here are some examples of using TO_CHAR to format a number: TO_CHAR(' ') returns TO_CHAR(' ', '9,999,999') returns 1,234,568 (note the automatic rounding!); there is a leading space in front of the number to leave room for a negative sign TO_CHAR('123', '099999') returns ; there is a leading space in front of the number to leave room for a negative sign TO_CHAR('123', 'FM099999') returns ; there is no leading space TO_CHAR(' ', '$999,999.99') returns $12,345.60; there are two leading spaces, one to leave room for the sign and one because there is no hundred-thousands digit Page 30 of 51

31 Condition Functions These are functions that return different values based on a set of conditions that you specify. DECODE(x, val1, [val2, result2,, valn, result] [, default]) DECODE is used to produce a result that is based on the result of x. The x, val1, result1, etc. arguments can be numbers or strings. Up to 127 comparisons (value/result pairs) are allowed if there is not default value and up to 136 comparisons are allowed if there is a default. The value of x is compared against val1, val2, etc. through valn, one at a time. When a match occurs, the corresponding result argument is returned. If x matches val1, DECODE returns result1, if x matches val2, DECODE returns result2, and so on. If there is no match, the default argument is returned, provided it is given; otherwise the special value NULL is returned. Consider the following examples: DECODE(A.COLOR, 'R', 'Red', 'G', 'Green', 'B', 'Blue') o If A.COLOR is R then DECODE returns Red o If A.COLOR is G then DECODE returns Green o If A.COLOR is B then DECODE returns Blue o If A.COLOR is Y then DECODE returns NULL DECODE(A.DIRECTION, 0, 'North', 90, 'East', 180, 'South', 270, 'West', 'Unknown') o If A.DIRECTION is 0 then DECODE returns North o If A.DIRECTION is 90 then DECODE returns East o If A.DIRECTION is 180 then DECODE returns South o If A.DIRECTION is 270 then DECODE returns West o If A.DIRECTION is 360 then DECODE returns Unknown You can also use the DECODE function to substitute a value when a field is blank. For date fields, an empty value is the special value NULL. To replace NULL values from the field A.DATE_FIELD with a default of date of 5/22/2009, use DECODE(A.DATE_FIELD, NULL, TO_DATE('05/22/2009', 'MM/DD/YYYY'), A.DATE_FIELD). Note the second A.DATE_FIELD as the last argument; this indicates that the original value of DATE_FIELD whenever DATE_FIELD is not NULL. For text fields, an empty value is a single space. To replace a single space from the field A.TEXT_FIELD with the default string N/A, use DECODE(A.TEXT_FIELD, ' ', 'N/A', A.TEXT_FIELD). As with the previous example, the original value of the field is used when the field is not empty. Page 31 of 51

32 CASE Expression A CASE expression is a powerful tool for producing one of several possible results based on conditions. It is more flexible than DECODE, which just maps input values to output values. CASE expressions allow ranges to be mapped to output values and for multiple input fields to influence the output. CASE expressions have the following format: CASE WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [ELSE default_result] END The CASE and END keywords are required. Each possible case is designated by the WHEN keyword, followed by a condition, the THEN keyword, and the result. The result must be a value or an expression that evaluates to a single value. The condition can be simple or complex, with many Boolean operators (such as AND and OR), as long as it evaluates to a result of true or false. At least one WHEN clause must be given. All other WHEN clauses and the ELSE clause are optional. However, it is good practice to provide a default case with the ELSE clause in case unexpected values are encountered. The conditions are examined in order from the first WHEN clause to the last WHEN clause. If condition1 is true, then the result of the CASE expression is set to result1. If condition1 is false, then condition2 is examined (if given); if condition2 is true, then the result of the CASE expression is set to result2. Each condition is examined until one that is true is encountered. If none of the conditions are true, the result of the CASE expression is set to default_result if an ELSE clause is provided; otherwise, the expression is set to NULL. Consider this example of determining if a state is a Great Lakes state: CASE WHEN A.STATE IN ('OH', 'MI', 'IN', 'IL', 'WI', 'MN', 'NY', 'PA') THEN 'Y' ELSE 'N' END If the STATE field contains one out of several state codes (OH, MI, etc.) then the CASE expression evaluates to Y. Otherwise, it evaluates to N. Page 32 of 51

33 Next, consider a version of this expression that takes into account that the Canadian province of Ontario is considered part of the Great Lakes region: CASE WHEN A.COUNTRY = 'CAN' AND A.STATE = 'ON' THEN 'Y' WHEN A.COUNTRY = 'USA' AND A.STATE IN ('OH', 'MI', 'IN', 'IL', 'WI', 'MN', 'NY', 'PA') THEN 'Y' ELSE 'N' END Each of the conditions includes an AND operator and examines data in two fields, COUNTRY and STATE. The conditions can include many conditions combined together. The above could also be expressed as the following: CASE WHEN (A.COUNTRY = 'CAN' AND A.STATE = 'ON') OR (A.COUNTRY = 'USA' AND A.STATE IN ('OH', 'MI', 'IN', 'IL', 'WI', 'MN', 'NY', 'PA')) THEN 'Y' ELSE 'N' END Here is an example with many conditions. This CASE expression translates a temperature in Fahrenheit into a description. CASE WHEN A.TEMPERATURE < 30 THEN 'Very cold' WHEN A.TEMPERATURE BETWEEN 30 AND 44 THEN 'Cold' WHEN A.TEMPERATURE BETWEEN 45 AND 59 THEN 'Cool' WHEN A.TEMPERATURE BETWEEN 60 AND 69 THEN 'Mild' WHEN A.TEMPERATURE BETWEEN 70 AND 79 THEN 'Warm' WHEN A.TEMPERATURE BETWEEN 80 AND 89 THEN 'Hot' ELSE 'Very hot' END Assume that the value in A.TEMPERATURE is 53. The first condition, A.TEMPERATURE < 30, is examined and found to be false. The second condition, A.TEMPERATURE BETWEEN 30 AND 44, is examined and is also false. The third condition, A.TEMPERATURE BETWEEN 45 AND 59, is true. The result of the expression is Cool. If the value of A.TEMPERATURE is above 89, none of the conditions in the WHEN clauses will be true, so the default value Very hot will be the result. Page 33 of 51