lifecycle management of rela1onal records for external
play

Lifecycle Management of Rela1onal Records for External - PowerPoint PPT Presentation

Lifecycle Management of Rela1onal Records for External Audi1ng and Regulatory Compliance Ahmed Ataullah Frank Wm. Tompa Policies and Constraints


  1. Lifecycle ¡Management ¡ ¡of ¡Rela1onal ¡Records ¡ ¡for ¡External ¡Audi1ng ¡ ¡and ¡Regulatory ¡Compliance ¡ Ahmed ¡Ataullah ¡ Frank ¡Wm. ¡Tompa ¡

  2. Policies ¡and ¡Constraints ¡ § What ¡is ¡a ¡business ¡policy? ¡ • A ¡specifica1on ¡of ¡what ¡should ¡(or ¡should ¡not) ¡ happen ¡in ¡the ¡opera1ons ¡of ¡a ¡business. ¡ ­ Typically ¡wriHen ¡in ¡natural ¡language ¡ § Policies ¡manifest ¡themselves ¡in ¡database ¡ systems ¡as ¡constraints ¡or ¡alerts ¡ • Check ¡constraints ¡ • Transac1on ¡termina1on ¡triggers ¡ • Access ¡control ¡restric1ons ¡ 2

  3. Business ¡Model ¡ § Means ¡of ¡simplifying ¡and ¡summarizing ¡a ¡set ¡of ¡ rules ¡ ¡ • Provides ¡a ¡high-­‑level ¡overview ¡ • Intermediate ¡layer ¡between ¡natural ¡language ¡and ¡ implementa1on ¡(code) ¡ • Logical ¡or ¡graphical ¡ § Types ¡of ¡modeling: ¡ • Data ¡modeling: ¡ER, ¡UML, ¡… ¡ • Process ¡modeling: ¡Workflow, ¡Flow-­‑chart, ¡PERT ¡charts, ¡… ¡ • Policy ¡modeling: ¡Hierarchical ¡access ¡control ¡modeling, ¡ Object ¡Constraint ¡Language, ¡… ¡ 3

  4. Database ¡System ¡Perspec1ve ¡ § Database ¡reflects ¡enterprise ¡ • Database ¡instance ¡ ≡ ¡overall ¡‘state ¡of ¡a ¡business’ ¡ § Instance ¡must ¡comply ¡with ¡published ¡policy ¡ • Database ¡system ¡must ¡con1nuously ¡monitor ¡ updates ¡to ¡ensure ¡compliance. ¡ • Single ¡compliance ¡layer ¡eliminates ¡need ¡to ¡embed ¡ policy ¡checking ¡logic ¡in ¡every ¡applica1on ¡ • Significantly ¡simplifies ¡implementa1on ¡of ¡complex ¡ data ¡constraints ¡ 4

  5. Difficul1es ¡ § Each ¡department ¡has ¡its ¡own ¡constraints ¡ • Shared ¡database ¡ ⇒ ¡conflicts ¡can ¡be ¡detected ¡ beforehand ¡ • Many ¡are ¡complex ¡(temporal, ¡condi1onal, ¡path ¡ oriented) ¡ ­ “A ¡student ¡can ¡take ¡CS446 ¡only ¡if ¡she ¡has ¡passed ¡CS330 ¡and ¡ CS245 ¡with ¡a ¡score ¡of ¡75% ¡or ¡more” ¡ ¡ ­ Typically ¡correspond ¡to ¡complex ¡transac1on ¡termina1on ¡ triggers ¡ § Many ¡constraints ¡derived ¡from ¡business ¡policies ¡ • Scale ¡ ⇒ ¡manageability ¡a ¡major ¡problem ¡for ¡DB ¡ administrators ¡and ¡programmers ¡ 5

  6. Why ¡have ¡exis1ng ¡models ¡failed ¡us? ¡ § Complex ¡(temporal, ¡path) ¡constraints ¡difficult ¡to ¡model. ¡ ¡ • “A ¡professor ¡cannot ¡teach ¡CS448 ¡and ¡CS490 ¡at ¡the ¡same ¡1me.” ¡ • “A ¡professor ¡can ¡teach ¡CS348 ¡only ¡once ¡in ¡two ¡years.” ¡ § No ¡no1on ¡of ¡policy-­‑relevant ¡object ¡ § State ¡of ¡an ¡“object” ¡is ¡sta1c ¡ • Historical ¡applica1ons ¡are ¡“forgoHen” ¡ • “Salary ¡of ¡an ¡employee ¡can ¡only ¡be ¡increased ¡three ¡1mes ¡in ¡any ¡ one ¡year ¡period.” ¡ § Inter-­‑rule ¡dependencies ¡cannot ¡be ¡expressed ¡ • For ¡example: ¡“Rule ¡1 ¡should ¡only ¡be ¡enforced ¡if ¡Rule ¡2 ¡was ¡ never ¡violated ¡in ¡the ¡past ¡by ¡a ¡transac1on” ¡ ¡ ¡ 6

  7. Avoiding ¡Hand-­‑wriHen ¡Triggers ¡ § Can ¡we ¡make ¡the ¡task ¡of ¡the ¡programmer ¡easier? ¡ § Can ¡we ¡make ¡the ¡database ¡level ¡workflows ¡more ¡ transparent ¡to ¡business ¡level ¡managers? ¡ § Can ¡we ¡introduce ¡policy-­‑to-­‑constraint ¡ transparency ¡and ¡manageability ¡and ¡offer ¡ compliance ¡guarantees ¡at ¡the ¡same ¡1me? ¡ 7

  8. Step ¡1 ¡ Basic ¡Framework: ¡Objects ¡ § Start ¡with ¡the ¡object ¡defini1ons ¡ • An ¡object ¡defini1on ¡is ¡ any ¡rela(onal ¡view ¡over ¡a ¡ fixed ¡database ¡schema. ¡ § Object ¡= ¡tuple ¡(row) ¡in ¡such ¡a ¡view ¡ • View ¡can ¡represent ¡a ¡complete ¡business ¡ar1fact ¡ ­ All ¡data ¡needed ¡for ¡policy ¡making ¡ • Assume ¡each ¡row ¡in ¡view ¡is ¡uniquely ¡iden1fiable ¡ ¡ 8

  9. Step ¡2 ¡ Basic ¡Framework: ¡States ¡ § State ¡S: ¡condi1on ¡on ¡objects ¡in ¡the ¡view ¡ defini1on ¡ • Object ¡x ¡is ¡in ¡state ¡S ¡ ⇔ ¡its ¡aHributes ¡sa1sfy ¡S(x) ¡ • Example ¡ ­ EXPENSE_CLAIM_DETAILS ¡is ¡user-­‑defined ¡ view ¡ ­ “Claim ¡objects” ¡are ¡rows ¡in ¡the ¡view ¡ ­ Object ¡O ¡(tuple ¡t) ¡is ¡in ¡state ¡P, ¡the ¡“paid ¡state”, ¡if ¡the ¡ condi1on ¡EXPENSE_CLAIM_DETAILS.PAID ¡= ¡TRUE ¡for ¡t ¡ § An ¡object ¡can ¡be ¡in ¡mul1ple ¡states ¡at ¡once. ¡ ¡ ¡ ¡ 9

  10. Step ¡3: ¡Convert ¡business ¡model ¡into ¡ enforcement ¡model ¡ New expense Reviewed by claim filed supervisor Awaiting Approval Payment Reviewed by completed Finance Dept. Awaiting Paid Payment § Rectangles ¡represent ¡business ¡states ¡ ¡ § Transi1ons ¡represent ¡processes/ac1ons ¡ § S1ck-­‑figures ¡represent ¡agents ¡ § Constraints ¡implied ¡by ¡absence ¡of ¡transi1ons ¡ • E.g., ¡Paid ¡invoices ¡are ¡not ¡deleted ¡ 10

  11. Business ¡states ¡and ¡DB ¡states ¡ New expense Reviewed by Awaiting Approval claim filed supervisor Awaiting Approved = false Φ Approval AND Paid = false Payment Reviewed by completed Finance Dept. Awaiting Paid Awaiting Payment Paid Payment Approved = true Approved = true AND Paid = true AND Paid = false § States ¡of ¡an ¡object ¡are ¡typically ¡an ¡interpreta1on ¡ of ¡stages ¡in ¡business ¡process. ¡ • Including ¡object ¡crea1on ¡and ¡destruc1on ¡ § All ¡constraints ¡should ¡be ¡made ¡explicit. ¡ 11

  12. Constraints ¡on ¡State ¡Transi1ons ¡ • A(x) ¡ ⋀ ¡¬ ¡A(x) ¡ ¡ ⇒ ¡B(x) ¡ ¡ A B ¬ ¡ • B(x) ¡ ⋀ ¡B(x) ¡ ¡ ⇒ ¡ ¡ • ¡A(x) ¡ ¡ A B ♦ A( x ) ¡ ⇒ ¡¬B( x ) ¡ ¡ A B § Define ¡various ¡types ¡of ¡constraint ¡ ¡ • Use ¡past ¡temporal ¡logic ¡ • Create ¡diagramma1c ¡form ¡ § Special ¡interpreta1ons ¡for ¡transi1ons ¡to ¡or ¡from ¡ Φ ¡ 12

  13. Back ¡to ¡the ¡Example ¡ Awaiting Approval Φ Approved = false AND Paid = false Paid Awaiting Payment Approved = true Approved = true AND Paid = true AND Paid = false § Convert ¡to ¡temporal ¡logic ¡ New (x) ¡ ¡ ¡ ⇒ ¡ ¡Awai1ngApp(x) ¡ ¬ ¡ • Awai1ngPay(x) ¡ ⋀ ¡Awai1ngPay(x) ¡ ¡ ⇒ ¡ ¡ • ¡Awai1ngApp(x) ¡ ¡ ¬ ¡ • Paid(x) ¡ ⋀ ¡Paid(x) ¡ ¡ ⇒ ¡ ¡ • ¡Awai1ngPay(x) ¡ ¡ Paid(x) ¡ ⇒ ¡ Retain (x) ¡ § Test ¡these ¡condi1ons ¡in ¡the ¡database ¡ 13

  14. State ¡Configura1on ¡of ¡an ¡Object ¡ Awaiting Approval Φ Approved = false AND Paid = false Paid Awaiting Payment Approved = true Approved = true AND Paid = true AND Paid = false § States ¡= ¡{ ¡Awai1ngApproval, ¡ ¡ ¡ ¡Awai1ngPayment, ¡ ¡ ¡Paid} ¡ § State ¡space ¡= ¡{(0,0,0),(0,0,1),(0,1,0),…,(1,1,1)} ¡ § Some ¡configura1ons ¡are ¡not ¡sa1sfiable ¡ 14

  15. Maintain ¡State ¡Configura1on ¡History ¡ § A ¡ complete, ¡ temporally ¡ordered ¡ list ¡of ¡state ¡ configura1ons ¡for ¡an ¡object ¡ Object O 1 history Time ¡ Awai1ng ¡ Awai1ng ¡ Paid ¡ Approval ¡ Payment ¡ t1 ¡ 0 ¡ 0 ¡ 0 ¡ t2 ¡ 1 ¡ 0 ¡ 0 ¡ t3 ¡ 0 ¡ 1 ¡ 0 ¡ t4 ¡ 0 ¡ 0 ¡ 1 ¡ 15

  16. Implementa1on: ¡Tracking ¡the ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ State ¡Configura1on ¡History ¡ Awai1ng ¡ Awai1ng ¡ Time ¡ Paid ¡ Approval ¡ Payment ¡ t1 ¡ 0 ¡ 0 ¡ 0 ¡ t2 ¡ 1 ¡ 0 ¡ 0 ¡ t3 ¡ 0 ¡ 1 ¡ 0 ¡ … ¡ … ¡ … ¡ … ¡ t_new ¡ 0 ¡ 0 ¡ 1 ¡ § Every ¡1me ¡an ¡object ¡is ¡modified, ¡look ¡back ¡at ¡the ¡ history ¡and ¡answer ¡the ¡query ¡related ¡to ¡each ¡ constraint! ¡ 16

Recommend


More recommend