User Views and merging relations & Journaling DBS201

Do not overstep normalization rules    Do not overstep normalization rules Order [OrderNo, , PartNo, Orderdate, CustNo, CustLname PartDesc,QtyOrd, Price)] Going from 1NF to 2NF does not give us a Customer[CustNo, CustLname] The non key value determining a non key value is handled when Going from 2NF to 3NF We should not lose any attributes, relations or composite keys when going from 1NF to 2NF to 3NF Only apply the normalization rules as written. When we reach the merge stage we will get rid of repeated attributes and reduce composite keys if possible.

   Merging Relations 1A CUSTOMER[ CustNo, CustName, CustStreet, CustZip, CustRep ] 1B ZipCode[CustZip, CustCity, CustSt] 2 PART[ PartNo, PartDescr, QtyOnHand, Class, Whse, Price] 3A CUSTOMER[CustNo, CustName] 3B CUSTORDER[CustNo, OrderNo, OrderDate] 4A ORDER [OrderNo, OrderDate, CustNo] 4B ORDERDETAIL [OrderNo, PartNum, NumOrdered QuotedPrice] 4C PART [PartNum, PartDescr] 5A CUSTORDER[CustNum, OrderNum] 5B ORDER[OrderNum, OrderDate] 5C CUST[CustNum, CustName, RepNo] 5D REP [RepNo, RepName]

Use consistent names for same attribute in each relation    Use consistent names for same attribute in each relation 2 PART[ PartNo, PartDescr, QtyOnHand, Class, Whse, Price] 4B ORDERDETAIL [ OrderNo, PartNum, NumOrdered] 4B ORDERDETAIL [ OrderNo, PartNo, NumOrdered, QuotedPrice] 4C PART [PartNum, PartDescr] 4C PART [PartNo, PartDescr] 5A CUSTORDER[CustNum, OrderNum] 5A CUSTORDER[CustNo, OrderNo] 5B ORDER[OrderNum, OrderDate] 5B ORDER[OrderNo, OrderDate] 5C CUST[CustNum, CustName, RepNo] 5C CUST[CustNo, CustName, RepNo]

Examine the Primary Key of each relation using a composite key    Examine the Primary Key of each relation using a composite key Determine if all parts should be part of the Primary Key 3B CUSTORDER[CustNo, OrderNo, OrderDate] CustNo is not required to be part of the PK because OrderNo uniquely identifies an order. If the Composite Primary key Was left as is then unique values could include (OrderNo 1001, CustNo 2) and (OrderNo 1001, CustNo 5) This would be incorrect because there is no situation where Customers 2 and 5 would each have an order numbered 1001 3B becomes 3B CUSTORDER[OrderNo, CustNo, OrderDate] 5A CUSTORDER[CustNo, OrderNo] becomes 5A CUSTORDER[ OrderNo, CustNo]

   Use consistent names for relations with the same attributes in the Primary Key Step 1 had 4A ORDER[OrderNo,OrderDate,CustNo] 5A CUSTORDER[CustNo,OrderNum] 5B ORDER[OrderNum,OrderDate] Might have been dealt with already in step 2 Fix is 4A ORDER[OrderNo,OrderDate,CustNo] 5A CUSTORDER[CustNo,OrderNo] 5B ORDER[OrderNo,OrderDate]

  Create one relation for relations having an identical Primary Key (the PK can be a one-part PK or a concatenated PK(2 or more attributes) but it must match exactly 1A,3A,5C CUSTOMER[ CustNo, CustName, CustStreet,CustZip, RepNo ] 2,4C PART[ PartNo, PartDescr, QtyOnHand, Class, Whse, Price] 3B, 4A,5A,5B ORDER [OrderNo, OrderDate, CustNo] 4B ORDERDETAIL [OrderNo, PartNum, NumOrdered,QuotedPrice] 5D REP [RepNo, RepName]

Resolve any new transitive dependencies, if any were created when merging relations. (None were in this example) An example of this would occur with merging the following relations: CUSTOMER[ CustNo, CustName, CustStreet, CustZip, RepNo ] CUSTOMER[ CustNo, CustName, RepName] Merged as CUSTOMER[ CustNo, CustName, CustStreet, CustZip, RepNo, RepName ] Which has the transitive dependency of RepName(determined by attribute RepNo) and would be Resolved as CUSTOMER[ CustNo, CustName, CustStreet, CustZip, RepNo] REP[RepNo, RepName]

After the Merge We Have: CUSTOMER[ CustNo, CustName, CustStreet, CustZip, RepNo(FK)] ZipCode[CustZip, CustCity, CustSt,] REP[RepNo, RepName] PART[ PartNo, PartDescr, QtyOnHand, Class, Whse, Price] ORDER [OrderNo, OrderDate, CustNo(FK)] ORDERDETAIL [OrderNo (FK1), PartNum (FK2), NumOrdered, QuotedPrice ] CUSTORDER[CustNo, OrderNo] CUSTORDER can be an index

Journaling and Recovery Using the Journal When you create a collection you have two special objects placed in that collection to keep track of any changes made to the tables within that collection QSQJRN – Is the journal and it is like a program that monitors activities on the tables in the collection and records that information QSQJRN0001 – is the journal receiver and this contains the entries recorded by the journal program. jrn201a45 Collection has: Object Type Text QSQJRN0001 *JRNRCV COLLECTION - created by SQL QSQJRN *JRN COLLECTION - created by SQL

DSPJRN collname/QSQJRN 99 D CT CUST2 Create database file 100 D JF CUST2 Start journaling for file 101 F JM CUST2 Start journaling for member 102 D MA CUST2 Member Added 103 F MC CUST2 Create member 104 R PT CUST2 Record added   ( A LOT OF PT's for all the records added) 136 R PT CUST2 Record added

DSPJRN collname/QSQJRN 137 R UB Cust2 Update, before-image 138 R UP - Cust2 Update, after-image   ( A LOT OF UB, UP's for all the records changed) 200 R UP - Cust2 Update, after-image Restoring the original City Names 201 F SR RMVJRNCHG command started 202 D DG Start of apply or remove 203 F RC Remove journaled changes 204 D DD End of apply or remove

Lab 10 1. Create a collection 2. View special objects used for commitment control 3. Copy a table into the collection using interactive SQL 4. View table contents and then make a small update that we want to keep. 5. Make a mistaken mass update that we will need to reverse. 6. Use the DSPJRN command to view table activities – adds and updates. 7. Determine what journal entries needs to be rolled back. 8. Use the RMVJRNCHG command to implement the rollback. 9. Prove that the table is now in the correct state using interactive SQL.

Lab 10 demonstration for JRN201???

Your Collection

Displaying the Journal There are a lot of before & after images for updates, after images for adds and before images for deletes and possibly a record of when the table was opened for reading There are a lot of tables Journal Receivers fill up and new ones are generated automatically How can you focus on a smaller subset of journal information How can you use a program to process this information You can focus on a single table You can subset according to date and time You can subset according to specific journal codes You can subset according to user profile You can send output to *PRINT or *OUTFILE

Displaying the Journal

Displaying the Journal

Displaying the Journal

Displaying the Journal

Backward Recovery

Backward Recovery

Important Information for Auditor using DSPJRN?

Important Information for Auditor?

Important Information for Auditor?

Important Information for Auditor?

Important Information for Auditor?

CRTLIB at command line vs CREATE COLLECTION in interactive SQL No database support objects created with CRTLIB

STEPS REQUIRED TO JOURNAL A FILE IN A LIBRARY (CRTLIB)

STEPS REQUIRED TO JOURNAL A FILE IN A LIBRARY (CRTLIB)

STEPS REQUIRED TO JOURNAL A FILE IN A LIBRARY (CRTLIB)

STEPS REQUIRED TO JOURNAL OBJECTS IN A LIBRARY (CRTLIB)

Lab 10 demonstration for NOTJRN???