D56261GC10 sg3 PDF

Oracle Internal & Oracle Academy Use Only
Oracle Database 11g:

Data Warehousing Fundamentals
Volume III • Student Guide
D56261GC10
Edition 1.0
July 2009
D61351
Author Copyright © 2009, Oracle. All rights reserved.
Lauran K. Serhal Disclaimer
This document contains proprietary information and is protected by copyright and

Technical Contributors other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered in
and Reviewers any way. Except where your use constitutes "fair use" under copyright law, you may
David Allan not use, share, download, upload, copy, print, display, perform, reproduce, publish,
license, post, transmit, or distribute this document in whole or in part without the
Hermann Baer express authorization of Oracle.
Herbert Bradbury
The information contained in this document is subject to change without notice. If you
Harald Van Breederode find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
Yanti Chang warranted to be error-free.
Joel Goodman
Restricted Rights Notice
Richard.Green
Nancy Greenberg If this documentation is delivered to the United States Government or anyone using

the documentation on behalf of the United States Government, the following notice is
Martin Gubar applicable:
Yash Jain U.S. GOVERNMENT RIGHTS
Gerry Jurrens The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Dr. Thomas Merz license agreement and/or the applicable U.S. Government contract.
Brian Pottle
Trademark Notice
Jan Van Stappen
S Matt Taylor Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other
names may be trademarks of their respective owners.
Jean-Francois Verrier
Andreas Walter2
Editors
Nita Pavitran
Raj Kumar
Graphic Designer
Rajiv Chandrabhanu
Publishers
Sujatha Nagendra
Veena Narasimhan
Michael Sebastian Almeida
Case Study
Contents
RISD_Project_Plan_V1.3
Project Management Plan
RD.049 Portal Security Requirements

RA.100 RISD Logical Data Model
MD.070 Physical Database Design
TA.010 RISD Data Warehouse Architecture
TE.100 - ETL Test Results RISD Data Warehouse
TE.100 - Report Test Results RISD Data Warehouse
MD.120 Production Readiness Application Operations Handbook
TAKS Disco Spec Version 4.0

Project Start: Mon

Project 1/19/04
Finish: Tue 8/3/04
Tasks

ID Task Name Duration Start Finish Resource Names % Complete
1 DW Implementation Project 142 days Mon 1/19/04 Tue 8/3/04 8%
2
3 Pre Project Planning 76 days Mon 1/19/04 Mon 5/3/04 30%
4 Obtain Board Approval 1 day Mon 1/19/04 Mon 1/19/04 District 100%
5 Sign Contract 14 days Tue 1/20/04 Fri 2/6/04 District,Oracle 100%
6 Obtain Development/Test 10 days Mon 2/9/04 Fri 2/20/04 District 75%
Set up Dev/Test
7 3 days Mon 2/23/04 Wed 2/25/04 District 0%
Environment
Obtain and setup
8 75 days Tue 1/20/04 Mon 5/3/04 District 0%
Production Environment
9 Establish Finance Plan 3 days Tue 1/20/04 Thu 1/22/04 Oracle[25%] 80%
10 Establish Staffing Plan 3 days Tue 1/20/04 Thu 1/22/04 Oracle[50%] 50%
11 Establish Management Plans 3 days Tue 1/20/04 Thu 1/22/04 Oracle[25%] 90%
12 Preliminary Kickoff 1 day Wed 1/28/04 Wed 1/28/04 100%
Prepare Preliminary PMP
13 5 days Thu 1/29/04 Wed 2/4/04 OPM 100%
and Draft Project Plan
14 Project Start 0 days Fri 2/6/04 Fri 2/6/04 0%
15
16 DEFINITION PHASE 14 days Fri 2/6/04 Wed 2/25/04 26%
Requirements Definition
17 8 days Fri 2/6/04 Tue 2/17/04 59%
Process
Confirm Detail Business OPM[33%],RPM
18 2 days Fri 2/6/04 Mon 2/9/04 100%
and System Objectives [33%],Director[33%]
M1_RISD_Baseline_Project_Plan_ks.htm (1 of 16)
Define Requirements OPM[25%],Director

19 1 day Tue 2/10/04 Tue 2/10/04 50%
Standards and Guidelines [25%]
Define Information
20 2 days Thu 2/12/04 Fri 2/13/04 OPM[25%] 50%
Requirements
Develop/Confirm
MoSCoW list for Report OPM[50%],RPM
21 2 days Mon 2/16/04 Tue 2/17/04 50%
Requirements[State = [50%]
Initial]
Obtain Existing
22 Reference Material 1 day Fri 2/6/04 Mon 2/9/04 RPM 50%
[State = Initial]
Finalize Baseline Project
23 3 days Tue 2/10/04 Thu 2/12/04 OPM[25%] 50%
Plan
24 Signoff on Project Plan 3 days Fri 2/13/04 Tue 2/17/04 RPM[25%] 0%

25 Requirements Analysis 11 days Fri 2/6/04 Fri 2/20/04 15%
Working Sessions with District[20%],Director
26 5 days Mon 2/16/04 Fri 2/20/04 0%
Functional Team [20%]
Construct Business Data
27 4 days Fri 2/6/04 Wed 2/11/04 Arch 25%
Model [State = Initial]
Define Data Quality
28 3 days Mon 2/16/04 Wed 2/18/04 District[25%] 25%
Approach [State=Initial]
29 Finalize PMP 0 days Wed 2/18/04 Wed 2/18/04 0%
30 Data Acquisition Process 1 day Mon 2/16/04 Mon 2/16/04 50%
OPM[25%],Director
31 Confirm Data Sources 1 day Mon 2/16/04 Mon 2/16/04 50%
[25%]
Technical Architecture
32 12 days Tue 2/10/04 Wed 2/25/04 0%
Process
Define Architecture
33 12 days Tue 2/10/04 Wed 2/25/04 0%
[State = Initial]
Technical Team work Team[25%],Arch
34 2 days Tue 2/24/04 Wed 2/25/04 0%
session [25%],Director[25%]
Document Arch
35 2 days Tue 2/10/04 Wed 2/11/04 Arch[25%] 0%
(Initial)
Establish Portal
36 2 days Tue 2/17/04 Wed 2/18/04 District 0%
Requirements (initial)
37 Adoption and Learning 1 day Tue 2/10/04 Tue 2/10/04 0%
Conduct interfaces team
Team[25%],OPM
38 Meeting & schedule 1 day Tue 2/10/04 Tue 2/10/04 0%
[25%],Director[25%]
follow-up sessions
39
REQUIREMENTS
40 24 days Fri 2/13/04 Wed 3/17/04 1%
MODELING PHASE
41 9 days Fri 2/13/04 Wed 2/25/04 8%
Process
Develop MoSCoW list
42 Report Requirements 4 days Fri 2/13/04 Wed 2/18/04 8%
[State = Refine]
Assessment Team OPM,Director,Arch,
43 0.25 days Mon 2/16/04 Mon 2/16/04 100%
Kickoff District
Functional reports Team[50%],OPM
44 1 day Wed 2/18/04 Wed 2/18/04 0%
team work session [50%],Arch[50%]
OPM[25%],RPM
Initial Data Model [25%],District[25%],
45 2 days Fri 2/13/04 Mon 2/16/04 0%
Review Director[25%],Arch
[25%]
Obtain Existing

46 Reference Materials 0 days Wed 2/25/04 Wed 2/25/04 RPM 0%
(Final)
Requirements Analysis
47 6.5 days Wed 2/18/04 Thu 2/26/04 0%
Process
Deploy Development OPM[50%],RPM
48 0.5 days Thu 2/26/04 Thu 2/26/04 0%
Standards and Guidelines [50%]
49 1 day Wed 2/18/04 Wed 2/18/04 Arch 0%
Model [State = Revise]
Define Solution
50 Integration Functional 2 days Thu 2/19/04 Fri 2/20/04 OPM[25%] 0%
Architecture
Obtain and Review
51 1 day Wed 2/18/04 Wed 2/18/04 Director 0%
Campus EAI templates
Define Solution
52 integration technical 2 days Thu 2/19/04 Fri 2/20/04 OPM[25%] 0%
Architecture
Define Data Quality OPM[25%],RPM
53 1 day Mon 2/23/04 Mon 2/23/04 0%
Approach [State=Final] [25%]
Conduct Data Source
54 3 days Thu 2/19/04 Mon 2/23/04 Arch[50%] 0%
Gap Analysis
55 Data Acquisition Process 3 days Tue 2/17/04 Thu 2/19/04 0%
Confirm Data OPM[20%],Director
56 3 days Tue 2/17/04 Thu 2/19/04 0%
Acquisition Approach [17%]
57 Data Access Process 3 days Thu 2/26/04 Tue 3/2/04 0%
Define Data Access
58 3 days Thu 2/26/04 Tue 3/2/04 0%
Approach
Define Interface
OPM[25%],Director
59 Requirements with 2 days Thu 2/26/04 Mon 3/1/04 0%
[25%]
Portal (Initial)
Define Security
60 1 day Mon 3/1/04 Tue 3/2/04 Director 0%
Requirements (Initial)
61 7 days Mon 2/23/04 Tue 3/2/04 0%
Process
Define Architecture
62 2 days Mon 2/23/04 Tue 2/24/04 OPM[50%] 0%
[State = Refine]
Define Capacity Plan
63 2 days Wed 2/25/04 Thu 2/26/04 Arch[25%] 0%
[State=Initial]
Construct Development
64 Environments [State = 2 days Thu 2/26/04 Fri 2/27/04 District 0%
Initial]
Define Detailed System
65 Operational 1 day Fri 2/27/04 Fri 2/27/04 OPM 0%
Requirements

Define Administration
66 2 days Mon 3/1/04 Tue 3/2/04 OPM[50%],RPM 0%
Approach
Conduct Technical Risk
67 2 days Fri 2/27/04 Mon 3/1/04 OPM[25%] 0%
Assessment
Confirm Portal
68 2 days Mon 2/23/04 Tue 2/24/04 District 0%
Requirements
Database Design and
69 1 day Wed 3/3/04 Wed 3/3/04 0%
Build Process
Deploy Database
70 1 day Wed 3/3/04 Wed 3/3/04 OPM[50%] 0%
Standards and Guidelines
71 Testing Process 5 days Wed 3/3/04 Tue 3/9/04 0%
Define Acceptance OPM[33%],RPM
72 3 days Wed 3/3/04 Fri 3/5/04 0%
Criteria [33%]
Define Testing
73 Requirements & Testing 2 days Mon 3/8/04 Tue 3/9/04 OPM[25%] 0%
Approach
Performance Testing
74 4 days Wed 3/10/04 Mon 3/15/04 0%
Process
Define Performance
75 4 days Wed 3/10/04 Mon 3/15/04 OPM[25%] 0%
Testing Approach
76 Transition 2 days Tue 3/16/04 Wed 3/17/04 0%
Define Cut-Over
77 2 days Tue 3/16/04 Wed 3/17/04 OPM[50%] 0%
Approach
78
79 CONSTRUCTION PHASE 108 days Thu 2/19/04 Mon 7/19/04 0%
80 32 days Thu 2/19/04 Fri 4/2/04 0%
Process
Develop MoSCoW list
OPM[50%],RPM
81 Report Requirements 2 days Thu 2/19/04 Fri 2/20/04 0%
[50%]
[State = Final]
Create Reporting
82 30 days Mon 2/23/04 Fri 4/2/04 OPM[25%] 0%
Requirements Document
Signoff Reporting
83 3 days Mon 4/5/04 Wed 4/7/04 RPM 0%
Requirements Analysis
84 5 days Mon 3/1/04 Fri 3/5/04 0%
Process
85 2 days Mon 3/1/04 Tue 3/2/04 Arch[25%] 0%
Model [State = Final]
Construct Preliminary
86 1 day Wed 3/3/04 Wed 3/3/04 Arch[50%] 0%
Database Object
Conduct Data Quality
87 2 days Wed 3/3/04 Fri 3/5/04 District,Director[0%] 0%
Assessment
88 Data Acquisition Process 59 days Fri 3/5/04 Thu 5/27/04 0%

89 Initial ODS Design 0 days Fri 3/5/04 Fri 3/5/04 District 0%
Map Source Data to
90 Target Logical Database 5 days Fri 3/12/04 Thu 3/18/04 Arch[80%] 0%
Design(s)
91 Final ODS Design 0 days Fri 3/19/04 Fri 3/19/04 District 0%
Populate ODS with Data
92 0 days Fri 3/19/04 Fri 3/19/04 0%
for testing
Define Data Acquisition
93 5 days Fri 3/19/04 Thu 3/25/04 Arch[80%] 0%
Model in OWB
Develop Data
Acquisition (ETTL)
94 45 days Fri 3/26/04 Thu 5/27/04 0%
Components using
OWB
Create ETL Modules
95 15 days Fri 3/26/04 Thu 4/15/04 Arch 0%
and unit test
Support additional
96 ETL activities and 30 days Fri 4/16/04 Thu 5/27/04 ETL 0%
unit test
Define Portal Security OPM[10%],Director
97 3 days Fri 4/23/04 Tue 4/27/04 0%
Requirements [50%]
Signoff on Portal
98 3 days Wed 4/28/04 Fri 4/30/04 RPM 0%
Security Requirements
Implement Security Input
99 45 days Fri 3/19/04 Thu 5/20/04 0%
forms and interfaces
Create and unit test Input
100 10 days Fri 4/23/04 Thu 5/6/04 Arch[50%] 0%
forms
Create Security updates
101 10 days Fri 5/7/04 Thu 5/20/04 Arch[50%] 0%
from input form
Design Reporting Data
102 10 days Fri 3/19/04 Thu 4/1/04 Portal 0%
Interface
103 Data Access Process 50 days Mon 4/12/04 Fri 6/18/04 0%
Define Data Access

104 5 days Mon 4/12/04 Fri 4/16/04 Disco 0%
Model - Discoverer EUL
Develop User Role
105 2 days Mon 4/19/04 Tue 4/20/04 Disco 0%
Access [State = Initial]
Develop 8 Data Access
106 15 days Wed 4/21/04 Tue 5/11/04 Disco 0%
Discoverer Reports
107 40 days Wed 4/21/04 Tue 6/15/04 District 0%
Discoverer Reports
Develop Business
108 3 days Wed 6/16/04 Fri 6/18/04 OPM 0%
Metadata for Data Access
109 24 days Fri 2/27/04 Wed 3/31/04 0%
Process
110 2 days Fri 2/27/04 Mon 3/1/04 Arch[12%] 0%
[State=Final]

Construct Dev/Test
111 Environment [State = 5 days Mon 3/1/04 Fri 3/5/04 District 0%
Final]
Define Architecture
112 5 days Wed 3/3/04 Tue 3/9/04 Arch[20%] 0%
[State = Final]
Detail Recovery and
113 2 days Wed 3/10/04 Thu 3/11/04 District 0%
Fallback Approach
Define Security and
114 2 days Fri 3/12/04 Mon 3/15/04 OPM[50%],District 0%
Control Approach
115 4 days Tue 3/16/04 Fri 3/19/04 District 0%
Model
Create Technical
116 5 days Mon 3/22/04 Fri 3/26/04 OPM[50%] 0%
Architecture Document
Develop Administration
117 3 days Mon 3/29/04 Wed 3/31/04 District 0%
Components
Signoff on Technical
118 3 days Mon 4/12/04 Wed 4/14/04 RPM 0%
Database Design and
119 7 days Wed 3/3/04 Thu 3/11/04 0%
Build Process
Create Logical
120 4 days Thu 3/4/04 Tue 3/9/04 0%
Database Design
121 Finalize Dimension 2 days Thu 3/4/04 Fri 3/5/04 Arch 0%
Finalize Facts and
122 derived fields business 2 days Mon 3/8/04 Tue 3/9/04 Arch 0%
rules
Review Logical Data
123 2 days Wed 3/10/04 Thu 3/11/04 OPM 0%
Model
Create Physical Database
124 1 day Wed 3/3/04 Wed 3/3/04 Arch 0%
Design [State = Initial]
Signoff on Logical Data

125 3 days Fri 3/12/04 Tue 3/16/04 RPM 0%
Model
126 Testing Process 56 days Mon 5/3/04 Mon 7/19/04 0%
Create Integration and
127 3 days Mon 5/3/04 Wed 5/5/04 OPM 0%
Testing Plan
Develop Component
128 2 days Thu 5/6/04 Fri 5/7/04 OPM 0%
Test Checklists
Develop Component
129 5 days Mon 5/10/04 Fri 5/14/04 OPM[75%] 0%
Tests
Create System Test Draft
130 Document (ETL & 5 days Mon 5/17/04 Fri 5/21/04 OPM 0%
Reports)
Assist RISD with User
131 Acceptance Test 3 days Mon 5/24/04 Wed 5/26/04 OPM[50%] 0%

Approach
ODS Populated with
132 0 days Mon 6/21/04 Mon 6/21/04 District 0%
Historical Data
Perform System
133 5 days Mon 6/21/04 Fri 6/25/04 Arch 0%
Integration Test (ETL)
Correct issues from ETL
134 3 days Mon 6/28/04 Wed 6/30/04 Arch 0%
System Test
Compile ETL test reports
135 and update ETL test 2 days Thu 7/1/04 Fri 7/2/04 OPM[50%] 0%
Document
Perform System Test
136 5 days Mon 6/28/04 Fri 7/2/04 OPM 0%
(Reports)
Correct Issues from
137 3 days Mon 7/5/04 Wed 7/7/04 Arch 0%
Reports System Test
Perform System
138 Integration Test (user 5 days Tue 7/13/04 Mon 7/19/04 Arch 0%
Acceptance)
Compile Report Test
Results & Update
139 3 days Thu 7/8/04 Mon 7/12/04 OPM 0%
Reports System Test
Document
Signoff on ETL System
140 3 days Tue 7/13/04 Thu 7/15/04 0%
Test Results
Signoff on Report System
141 3 days Tue 7/13/04 Thu 7/15/04 RPM 0%
Test Results
142 Transition 5 days Mon 5/10/04 Fri 5/14/04 0%
143 Develop Installation Plan 5 days Mon 5/10/04 Fri 5/14/04 OPM[15%],Arch[40%] 0%
144 Adoption and Learning 23 days Fri 5/21/04 Tue 6/22/04 0%
Conduct User Learning
145 3 days Thu 5/27/04 Mon 5/31/04 RPM 0%
Needs Analysis
Provide technical support

146 20 days Fri 5/21/04 Thu 6/17/04 Arch[25%] 0%
to Richardson
Document Training
147 3 days Fri 6/18/04 Tue 6/22/04 OPM[75%] 0%
Recommendation
148
149 PRODUCTION PHASE 114 days Thu 2/26/04 Tue 8/3/04 0%
150 Data Acquisition Process 7 days Tue 7/13/04 Wed 7/21/04 0%
Support final testing and
151 Move Test environment 5 days Tue 7/13/04 Mon 7/19/04 DBA 0%
to production
Perform Initial Load of
152 2 days Tue 7/20/04 Wed 7/21/04 Arch 0%
Production Databases
153 Data Access Process 41 days Thu 2/26/04 Thu 4/22/04 0%

Develop Business
154 5 days Thu 2/26/04 Wed 3/3/04 Arch[20%] 0%
Metadata for Data Access
Develop User Role
155 2 days Wed 4/21/04 Thu 4/22/04 Arch[25%] 0%
Access [State = Final]
Database Design and
156 28 days Thu 3/4/04 Mon 4/12/04 0%
Build Process
157 25 days Thu 3/4/04 Wed 4/7/04 Arch[10%] 0%
Design [State = Final]
Create Physical Design
158 3 days Thu 4/8/04 Mon 4/12/04 OPM 0%
Document
159 Update Database Schema 2 days Thu 4/8/04 Fri 4/9/04 Arch[25%] 0%
Signoff Physical Database
160 3 days Tue 4/13/04 Thu 4/15/04 RPM 0%
Design
161 Testing Process 3 days Thu 7/22/04 Mon 7/26/04 0%
Execute Final Data
162 Validation & Data 2 days Thu 7/22/04 Fri 7/23/04 District,Arch,OPM 0%
Access Test
Execute Pre-Production
163 1 day Mon 7/26/04 Mon 7/26/04 District,Arch[50%] 0%
Validation
Document Production
164 1 day Mon 7/26/04 Mon 7/26/04 OPM 0%
Readiness
165 Transition 0 days Mon 7/26/04 Mon 7/26/04 0%
166 Go Production 0 days Mon 7/26/04 Mon 7/26/04 0%
Close out Adoption and
167 3 days Tue 7/27/04 Thu 7/29/04 0%
Learning
Conduct User Learning OPM,Arch[50%],
168 2 days Tue 7/27/04 Wed 7/28/04 0%
Events District
Conduct Effectiveness
169 1 day Thu 7/29/04 Thu 7/29/04 0%
Assessment
170 Support Process 6 days Tue 7/27/04 Tue 8/3/04 0%

171 Solution Support 5 days Wed 7/28/04 Tue 8/3/04 Arch[50%],District 0%
172 Create Test Environment 5 days Tue 7/27/04 Mon 8/2/04 Arch[50%] 0%
Signoff on Production
173 3 days Tue 7/27/04 Thu 7/29/04 RPM 0%
Readiness

Resources
ID Name Group Max Units Peak Units

1 OPM 100% 200%
2 RPM 100% 200%
3 Arch 100% 190%
4 Team 100% 50%
5 District 100% 370%
6 Disco 100% 100%
7 ETL 100% 100%
8 Oracle 100% 200%
9 DBA 100% 100%
10 Director 100% 170%
11 Portal 100% 100%
Assignments
Task ID Task Name Resource Name Work Start Finish % Work Complete
4 Obtain Board Approval District 8 hrs Mon 1/19/04 Mon 1/19/04 100%
5 Sign Contract District 112 hrs Tue 1/20/04 Fri 2/6/04 100%
5 Sign Contract Oracle 112 hrs Tue 1/20/04 Fri 2/6/04 100%
6 Obtain Development/Test District 80 hrs Mon 2/9/04 Fri 2/20/04 75%
7 Set up Dev/Test Environment District 24 hrs Mon 2/23/04 Wed 2/25/04 0%
Obtain and setup Production
8 District 600 hrs Tue 1/20/04 Mon 5/3/04 0%
Environment

9 Establish Finance Plan Oracle 6 hrs Tue 1/20/04 Thu 1/22/04 80%
10 Establish Staffing Plan Oracle 12 hrs Tue 1/20/04 Thu 1/22/04 50%
11 Establish Management Plans Oracle 6 hrs Tue 1/20/04 Thu 1/22/04 90%
Prepare Preliminary PMP and
13 OPM 40 hrs Thu 1/29/04 Wed 2/4/04 100%
Draft Project Plan
Confirm Detail Business and
18 OPM 5.33 hrs Fri 2/6/04 Mon 2/9/04 100%
System Objectives
18 RPM 5.33 hrs Fri 2/6/04 Mon 2/9/04 100%
System Objectives
18 Director 5.33 hrs Fri 2/6/04 Mon 2/9/04 100%
System Objectives
Define Requirements
19 OPM 2 hrs Tue 2/10/04 Tue 2/10/04 50%
Define Requirements
19 Director 2 hrs Tue 2/10/04 Tue 2/10/04 50%
Define Information
20 OPM 4 hrs Thu 2/12/04 Fri 2/13/04 50%
Requirements
Develop/Confirm MoSCoW
21 list for Report Requirements OPM 8 hrs Mon 2/16/04 Tue 2/17/04 50%
[State = Initial]
Develop/Confirm MoSCoW
21 list for Report Requirements RPM 8 hrs Mon 2/16/04 Tue 2/17/04 50%
[State = Initial]
Obtain Existing Reference
22 RPM 8 hrs Fri 2/6/04 Mon 2/9/04 50%
Material [State = Initial]
23 Finalize Baseline Project Plan OPM 3.2 hrs Tue 2/10/04 Wed 2/11/04 94%
24 Signoff on Project Plan RPM 6 hrs Fri 2/13/04 Tue 2/17/04 0%
Working Sessions with
26 District 8 hrs Mon 2/16/04 Fri 2/20/04 0%
Functional Team

Working Sessions with

26 Director 8 hrs Mon 2/16/04 Fri 2/20/04 0%
Functional Team
27 Arch 32 hrs Fri 2/6/04 Wed 2/11/04 25%
Model [State = Initial]
Define Data Quality Approach
28 District 6 hrs Mon 2/16/04 Wed 2/18/04 25%
[State=Initial]
31 Confirm Data Sources OPM 2 hrs Mon 2/16/04 Mon 2/16/04 50%
31 Confirm Data Sources Director 2 hrs Mon 2/16/04 Mon 2/16/04 50%
34 Technical Team work session Team 4 hrs Tue 2/24/04 Wed 2/25/04 0%
34 Technical Team work session Arch 4 hrs Tue 2/24/04 Wed 2/25/04 0%
34 Technical Team work session Director 4 hrs Tue 2/24/04 Wed 2/25/04 0%
35 Document Arch (Initial) Arch 4 hrs Tue 2/10/04 Wed 2/11/04 0%

Establish Portal Requirements
36 District 16 hrs Tue 2/17/04 Wed 2/18/04 0%
(initial)
38 Meeting & schedule follow-up Team 2 hrs Tue 2/10/04 Tue 2/10/04 0%
sessions
38 Meeting & schedule follow-up OPM 2 hrs Tue 2/10/04 Tue 2/10/04 0%
sessions
38 Meeting & schedule follow-up Director 2 hrs Tue 2/10/04 Tue 2/10/04 0%
sessions
43 Assessment Team Kickoff OPM 2 hrs Mon 2/16/04 Mon 2/16/04 100%
43 Assessment Team Kickoff Director 2 hrs Mon 2/16/04 Mon 2/16/04 100%
43 Assessment Team Kickoff Arch 2 hrs Mon 2/16/04 Mon 2/16/04 100%
43 Assessment Team Kickoff District 2 hrs Mon 2/16/04 Mon 2/16/04 100%
Functional reports team work
44 Team 4 hrs Wed 2/18/04 Wed 2/18/04 0%
session
44 OPM 4 hrs Wed 2/18/04 Wed 2/18/04 0%
session
44 Arch 4 hrs Wed 2/18/04 Wed 2/18/04 0%
session
45 Initial Data Model Review OPM 4 hrs Fri 2/13/04 Mon 2/16/04 0%
45 Initial Data Model Review RPM 4 hrs Fri 2/13/04 Mon 2/16/04 0%
45 Initial Data Model Review District 4 hrs Fri 2/13/04 Mon 2/16/04 0%
45 Initial Data Model Review Director 4 hrs Fri 2/13/04 Mon 2/16/04 0%
45 Initial Data Model Review Arch 4 hrs Fri 2/13/04 Mon 2/16/04 0%
Obtain Existing Reference
46 RPM 0 hrs Wed 2/25/04 Wed 2/25/04 0%
Materials (Final)

Deploy Development
48 OPM 2 hrs Thu 2/26/04 Thu 2/26/04 0%
Deploy Development
48 RPM 2 hrs Thu 2/26/04 Thu 2/26/04 0%
49 Arch 8 hrs Wed 2/18/04 Wed 2/18/04 0%
Model [State = Revise]
Define Solution Integration
50 OPM 4 hrs Thu 2/19/04 Fri 2/20/04 0%
Functional Architecture
Obtain and Review Campus
51 Director 8 hrs Wed 2/18/04 Wed 2/18/04 0%
EAI templates
Define Solution integration
52 OPM 4 hrs Thu 2/19/04 Fri 2/20/04 0%
technical Architecture
53 OPM 2 hrs Mon 2/23/04 Mon 2/23/04 0%
[State=Final]

53 RPM 2 hrs Mon 2/23/04 Mon 2/23/04 0%
[State=Final]
Conduct Data Source Gap
54 Arch 12 hrs Thu 2/19/04 Mon 2/23/04 0%
Analysis
Confirm Data Acquisition
56 OPM 4.8 hrs Tue 2/17/04 Thu 2/19/04 0%
Approach
Confirm Data Acquisition
56 Director 4 hrs Tue 2/17/04 Thu 2/19/04 0%
Approach
Define Interface Requirements
59 OPM 4 hrs Thu 2/26/04 Mon 3/1/04 0%
with Portal (Initial)
Define Interface Requirements
59 Director 4 hrs Thu 2/26/04 Mon 3/1/04 0%
with Portal (Initial)
Define Security Requirements
60 Director 8 hrs Mon 3/1/04 Tue 3/2/04 0%
(Initial)
Define Architecture [State =
62 OPM 8 hrs Mon 2/23/04 Tue 2/24/04 0%
Refine]
63 Arch 4 hrs Wed 2/25/04 Thu 2/26/04 0%
[State=Initial]
Construct Development
64 District 16 hrs Thu 2/26/04 Fri 2/27/04 0%
Environments [State = Initial]
Define Detailed System
65 OPM 8 hrs Fri 2/27/04 Fri 2/27/04 0%
Operational Requirements
66 OPM 8 hrs Mon 3/1/04 Tue 3/2/04 0%
Approach
66 RPM 8 hrs Mon 3/1/04 Mon 3/1/04 0%
Approach
Conduct Technical Risk
67 OPM 4 hrs Fri 2/27/04 Mon 3/1/04 0%
Assessment
68 Confirm Portal Requirements District 16 hrs Mon 2/23/04 Tue 2/24/04 0%

Deploy Database Standards

70 OPM 4 hrs Wed 3/3/04 Wed 3/3/04 0%
and Guidelines
72 Define Acceptance Criteria OPM 8 hrs Wed 3/3/04 Fri 3/5/04 0%
72 Define Acceptance Criteria RPM 8 hrs Wed 3/3/04 Fri 3/5/04 0%
Define Testing Requirements
73 OPM 4 hrs Mon 3/8/04 Tue 3/9/04 0%
& Testing Approach
Define Performance Testing
75 OPM 8 hrs Wed 3/10/04 Mon 3/15/04 0%
Approach
77 Define Cut-Over Approach OPM 8 hrs Tue 3/16/04 Wed 3/17/04 0%
Develop MoSCoW list Report
81 OPM 8 hrs Thu 2/19/04 Fri 2/20/04 0%
Requirements[State = Final]
Develop MoSCoW list Report
81 RPM 8 hrs Thu 2/19/04 Fri 2/20/04 0%

Create Reporting
82 OPM 60 hrs Mon 2/23/04 Fri 4/2/04 0%
Signoff Reporting
83 RPM 24 hrs Mon 4/5/04 Wed 4/7/04 0%
85 Arch 4 hrs Mon 3/1/04 Tue 3/2/04 0%
Model [State = Final]
Construct Preliminary
86 Arch 4 hrs Wed 3/3/04 Wed 3/3/04 0%
Database Object
Assessment
87 Director 0 hrs Wed 3/3/04 Wed 3/3/04 0%
Assessment
89 Initial ODS Design District 0 hrs Fri 3/5/04 Fri 3/5/04 0%
Map Source Data to Target
90 Arch 32 hrs Fri 3/12/04 Thu 3/18/04 0%
Logical Database Design(s)
91 Final ODS Design District 0 hrs Fri 3/19/04 Fri 3/19/04 0%
Define Data Acquisition
93 Arch 32 hrs Fri 3/19/04 Thu 3/25/04 0%
Model in OWB
Create ETL Modules and unit
95 Arch 120 hrs Fri 3/26/04 Thu 4/15/04 0%
test
Support additional ETL
96 ETL 240 hrs Fri 4/16/04 Thu 5/27/04 0%
activities and unit test
Define Portal Security
97 OPM 2.4 hrs Fri 4/23/04 Tue 4/27/04 0%
Requirements
Define Portal Security
97 Director 12 hrs Fri 4/23/04 Tue 4/27/04 0%
Requirements
Signoff on Portal Security
98 RPM 24 hrs Wed 4/28/04 Fri 4/30/04 0%
Requirements
100 Create and unit test Input forms Arch 40 hrs Fri 4/23/04 Thu 5/6/04 0%

Create Security updates from

101 Arch 40 hrs Fri 5/7/04 Thu 5/20/04 0%
input form
Design Reporting Data
102 Portal 80 hrs Fri 3/19/04 Thu 4/1/04 0%
Interface
Define Data Access Model -
104 Disco 40 hrs Mon 4/12/04 Fri 4/16/04 0%
Discoverer EUL
Develop User Role Access
105 Disco 16 hrs Mon 4/19/04 Tue 4/20/04 0%
[State = Initial]
106 Disco 120 hrs Wed 4/21/04 Tue 5/11/04 0%
Discoverer Reports
107 District 320 hrs Wed 4/21/04 Tue 6/15/04 0%
Discoverer Reports
Develop Business Metadata
108 OPM 24 hrs Wed 6/16/04 Fri 6/18/04 0%
for Data Access

110 Arch 1.92 hrs Fri 2/27/04 Mon 3/1/04 0%
[State=Final]
Construct Dev/Test
111 District 40 hrs Mon 3/1/04 Fri 3/5/04 0%
Environment [State = Final]
Define Architecture [State =
112 Arch 8 hrs Wed 3/3/04 Tue 3/9/04 0%
Final]
Detail Recovery and Fallback
113 District 16 hrs Wed 3/10/04 Thu 3/11/04 0%
Approach
Define Security and Control
114 OPM 8 hrs Fri 3/12/04 Mon 3/15/04 0%
Approach
Define Security and Control
114 District 16 hrs Fri 3/12/04 Mon 3/15/04 0%
Approach
115 Define Administration Model District 32 hrs Tue 3/16/04 Fri 3/19/04 0%
Create Technical Architecture
116 OPM 20 hrs Mon 3/22/04 Fri 3/26/04 0%
Document
Develop Administration
117 District 24 hrs Mon 3/29/04 Wed 3/31/04 0%
Components
Signoff on Technical
118 RPM 24 hrs Mon 4/12/04 Wed 4/14/04 0%
121 Finalize Dimension Arch 16 hrs Thu 3/4/04 Fri 3/5/04 0%
Finalize Facts and derived
122 Arch 16 hrs Mon 3/8/04 Tue 3/9/04 0%
fields business rules
123 Review Logical Data Model OPM 16 hrs Wed 3/10/04 Thu 3/11/04 0%
124 Arch 8 hrs Wed 3/3/04 Wed 3/3/04 0%
Design [State = Initial]
125 Signoff on Logical Data Model RPM 24 hrs Fri 3/12/04 Tue 3/16/04 0%
Create Integration and Testing
127 OPM 24 hrs Mon 5/3/04 Wed 5/5/04 0%
Plan

Develop Component Test

128 OPM 16 hrs Thu 5/6/04 Fri 5/7/04 0%
Checklists
129 Develop Component Tests OPM 30 hrs Mon 5/10/04 Fri 5/14/04 0%
Create System Test Draft
130 OPM 40 hrs Mon 5/17/04 Fri 5/21/04 0%
Document (ETL & Reports)
Assist RISD with User
131 OPM 12 hrs Mon 5/24/04 Wed 5/26/04 0%
Acceptance Test Approach
ODS Populated with Historical
132 District 0 hrs Mon 6/21/04 Mon 6/21/04 0%
Data
Perform System Integration
133 Arch 40 hrs Mon 6/21/04 Fri 6/25/04 0%
Test (ETL)
Correct issues from ETL
134 Arch 24 hrs Mon 6/28/04 Wed 6/30/04 0%
System Test

Compile ETL test reports and
135 OPM 8 hrs Thu 7/1/04 Fri 7/2/04 0%
update ETL test Document
136 Perform System Test (Reports) OPM 40 hrs Mon 6/28/04 Fri 7/2/04 0%
Correct Issues from Reports
137 Arch 24 hrs Mon 7/5/04 Wed 7/7/04 0%
System Test
Perform System Integration
138 Arch 40 hrs Tue 7/13/04 Mon 7/19/04 0%
Test (user Acceptance)
Compile Report Test Results
139 & Update Reports System Test OPM 24 hrs Thu 7/8/04 Mon 7/12/04 0%
Document
Signoff on Report System Test
141 RPM 24 hrs Tue 7/13/04 Thu 7/15/04 0%
Results
143 Develop Installation Plan OPM 6 hrs Mon 5/10/04 Fri 5/14/04 0%
143 Develop Installation Plan Arch 16 hrs Mon 5/10/04 Fri 5/14/04 0%
Conduct User Learning Needs
145 RPM 24 hrs Thu 5/27/04 Mon 5/31/04 0%
Analysis
Provide technical support to
146 Arch 40 hrs Fri 5/21/04 Thu 6/17/04 0%
Richardson
Document Training
147 OPM 18 hrs Fri 6/18/04 Tue 6/22/04 0%
Recommendation
Support final testing and Move
151 DBA 40 hrs Tue 7/13/04 Mon 7/19/04 0%
Test environment to production
Perform Initial Load of
152 Arch 16 hrs Tue 7/20/04 Wed 7/21/04 0%
Production Databases
Develop Business Metadata
154 Arch 8 hrs Thu 2/26/04 Wed 3/3/04 0%
for Data Access
Develop User Role Access
155 Arch 4 hrs Wed 4/21/04 Thu 4/22/04 0%
[State = Final]
157 Arch 20 hrs Thu 3/4/04 Wed 4/7/04 0%
Design [State = Final]

Create Physical Design

158 OPM 24 hrs Thu 4/8/04 Mon 4/12/04 0%
Document
159 Update Database Schema Arch 4 hrs Thu 4/8/04 Fri 4/9/04 0%
Signoff Physical Database
160 RPM 24 hrs Tue 4/13/04 Thu 4/15/04 0%
Design
Execute Final Data Validation
& Data Access Test
162 Arch 16 hrs Thu 7/22/04 Fri 7/23/04 0%
& Data Access Test
162 OPM 16 hrs Thu 7/22/04 Fri 7/23/04 0%
& Data Access Test
163 District 8 hrs Mon 7/26/04 Mon 7/26/04 0%
Validation

163 Arch 4 hrs Mon 7/26/04 Mon 7/26/04 0%
Validation
Document Production
164 OPM 8 hrs Mon 7/26/04 Mon 7/26/04 0%
Readiness
168 Conduct User Learning Events OPM 16 hrs Tue 7/27/04 Wed 7/28/04 0%
168 Conduct User Learning Events Arch 8 hrs Tue 7/27/04 Wed 7/28/04 0%
168 Conduct User Learning Events District 16 hrs Tue 7/27/04 Wed 7/28/04 0%
171 Solution Support Arch 20 hrs Wed 7/28/04 Tue 8/3/04 0%
171 Solution Support District 40 hrs Wed 7/28/04 Tue 8/3/04 0%
172 Create Test Environment Arch 20 hrs Tue 7/27/04 Mon 8/2/04 0%
Signoff on Production
173 RPM 24 hrs Tue 7/27/04 Thu 7/29/04 0%
Readiness
Microsoft Home Page

Microsoft Project Home Page

PROJECT MANAGEMENT PLAN
M1_RISD_PMP_V1.doc

Roy Independent School District
(RISD)
Decision Support System
Author: Oracle Services Industries
Last Updated: February, 2000

Document Ref: RISD/DW/004
Version: 1.0
Approvals:
RISD: _____________________________________________
Oracle: _____________________________________________
Project Management Plan Doc Ref:RISD/DW/004
Document Control
Change Record
4
Date Author Version Change Reference

Reviewers
Name Position
- ii -
Distribution
Copy No. Name Location
1 Library Master Project Library

2
3
4
RIDS Data Warehouse Page ii

Contents
Document Control .......................................................................................... ii

Change Record......................................................................................... ii
Reviewers.................................................................................................. ii

Distribution................................................................................................. ii
Introduction.......................................................................................................1
Purpose.......................................................................................................1
Background ................................................................................................2
Scope & Application..................................................................................2
Related Documents ..................................................................................3
Scope ................................................................................................................4
Scope of Project ........................................................................................4
Constraints and Assumptions................................................................10
Scope Control ..........................................................................................11
Objectives.......................................................................................................12
District Goal..............................................................................................12
Critical Success Factors.........................................................................12
Project Objectives ...................................................................................13
Approach ........................................................................................................14
Project Methods.......................................................................................14
Acceptance...............................................................................................15
Project Administration.............................................................................16
Control and Reporting ..................................................................................17
Issue Management .................................................................................17
Action Item Management .......................................................................17
Risk Management ...................................................................................18
Change Management .............................................................................18
Status Monitoring and Reporting ..........................................................18
Work Management........................................................................................20
Resource Management ................................................................................21

Staff Resources .......................................................................................21
RIDS Data Warehouse Page iii

Configuration Management .........................................................................22

Software Configuration Management Standards and Procedures..22
Document Control ...................................................................................23
Release Management ............................................................................23
Appendix A - Work Plan ...............................................................................24
Appendix B - Roles and Responsibilities...................................................29
Attachment C - Change Request Form .....................................................31
RIDS Data Warehouse Page iv

Introduction
On January 2000, the RISD and Oracle representatives met to discuss the details of the
Data Warehouse project. The board approved the proposal and the contract was signed.
The contract reflects the scope agreed upon in the Data Warehouse proposal.
Area Scope/Tasks Clarifications

Duration • The initial baseline plan had a start date of January 24. A
preliminary meeting confirmed that the project must be
completed by the August timeframe. The baseline plan will be
updated to target mid July for user acceptance testing with an
8/1 delivery due.
• Oracle resources began work prior to the contract being
signed but it does not impact the fixed price contract.
ETL • Confirmed that the highest priority assessment interface areas

are for SDAA II (State Developed Alternative Assessment)
and TAKS (Texas Assessment of Knowledge & Skills)
• Confirmed OWB will be used as the development ETL tool
• Confirmed all interface data will be stored in a staging area/
Operational Data Store (ODS) that will be used to source the
Data Warehouse. The ODS is the responsibility of RISD.
Historical data will not be maintained in the ODS but it is
possible up to one year of data will be stored in the ODS
• History will need to be contained in the ODS for initially
populating the Data Warehouse
• Norma Comer confirmed she is considering using OWB as the
tool to update the Operational Data Store (ODS) staging area.
Reports • Confirmed that the highest priority reports are for SDAA II
data (State Developed Alternative Assessment) and TAKS
data (Texas Assessment of Knowledge & Skills)
• The system can go “live” as long as the two priority reports are
complete and the data has been verified.
• RISD has experience building Discoverer End User Layers
against the Oracle Applications
Resources • The RISD PMO team confirmed that an experienced OWB
ETL resource with Oracle DBA experience would be hired to
assume maintenance of the Data Warehouse and the update
processes. The individual should be on staff by mid April to
begin knowledge transfer.
• RISD confirmed a DBA resource is available to support the
project.
• Oracle Consulting confirmed that several Oracle resources
with K-12 experience would be available remotely to provide
input and quality assure (QA) the design process as needed.
Purpose
The purpose of this Project Management Plan (PMP) is to confirm the scope of work to
be performed as agreed upon in the Oracle Proposal document and the corresponding
Fixed Price contract. It also defines the approach to project management and quality
control that will be applied to the Data Warehouse, PHASE I project for the Roy
Independent School District (RISD). This document is intended to supplement the original
statement of work in the proposal and the contract by providing additional details
RIDS Data Warehouse Page 1
regarding project work products and milestone completion criteria. A detailed baseline
work plan accompanies this project management plan document. The high-level project
plan is attached as Appendix A.
Background
The Data Warehouse environment will provide decision makers throughout the District
with information to help improve student achievement. Users will access the system via
Windows based Internet-capable computers accommodating the needs of both computer
novices and experts. Discoverer report data will be available online and can be
downloaded into local applications where appropriate (for example, spreadsheets and
PC databases) to perform additional analysis or for integration with local data.
User groups will be restricted to accessing information associated with their

responsibilities, needs, and skills. The majority of end users will view simple reports.
Dashboard reports will provide summarized tabular and/or graphical information to

various user groups. The system would be designed so RISD can develop relevant
reports as new data becomes available. Some power users will go directly to Discoverer
Plus to run reports and create new reports on an as needed basis while most users will
have access to Discoverer viewer to run parameter driven reports and/or view existing
standard reports.
This project will utilize Oracle Data Warehousing Methodology (DWM) and Project
Management Methodology (PJM). These are discussed more fully later in the Project
Methods section.
Scope & Application

This Project Management Plan defines:
• Scope
• Objectives
• Approach
• Project Tasks, Work Products, and Milestones
Standards and procedures will be followed in the following areas:
• Control and Reporting (issue management, scope change control, progress
reporting, and so on)
• Work Management (management of tasks and project budget information)
• Resource Management (management of staff including Roles and Responsibilities,
as well as physical resources)
• Quality Management (reviews of Work Products, testing, and so on)
• Configuration Management (how project intellectual capital and software are to be
managed)
The Project Management Plan (PMP) defines the implementation approach needed to
meet the defined objectives.

Related Documents
• RISD DW baseline Project Plan
• Proposal
• Fixed Price Engagement Contract Order Form

Scope
Scope of Project
Oracle shall perform the planning, design, development and deployment of the RISD
Data Warehouse Phase I to provide decision makers throughout the District with
information to assist in improving student achievement.
Technical Architecture - DBA

Oracle will develop the technical architecture for the Development, Test, and Production
instance of the Data Warehouse based on the infrastructure components ordered by
RISD. Developer suite 10g will be used unless there are certification issues. Oracle will
assist with recommending production environment hardware and document the

infrastructure in the Technical architecture document. Oracle will provide guidance with
the installation of hardware and software where necessary. Oracle will create the
Database and ETL necessary to load and update the database environment.
Oracle’s approach includes shifting responsibility for the technical environment to the
RISD DBA and System Administrator during the Design and Build Phase of the project.
This approach coincides with Oracle’s objective to enable the RISD staff to administer
the technical environment by project completion with minimal assistance from Oracle.
RISD should attempt to use the same versions of software across applications where
possible. For example, the Operational Data Store (ODS) developed by RISD staff and
the Data Warehouse developed primarily by Oracle staff should use the same Oracle
10g version of the database. If Oracle Warehouse Builder (OWB) is used for the ETL
process and the design of the ODS, the DW and ODS environment should use the same
versions.
Data Warehouse Design

Oracle will develop the logical and physical data models to support the reporting and
analysis requirements gathered during the initial phase of the project in Oracle Designer.
Derived fields and database views (including materialized views to support the
Discoverer End User Layer) will be developed during the physical design phase and
expanded during the reporting technical design and updated to support performance.
Data Quality
RISD will be responsible for data cleansing before data is extracted from the ODS to load
the data warehouse. Data elements not passing simple edits will be set to unknown in the
DW ETL process in order to avoid dropping records during the database load. Errors
such as correcting duplicate Student records or merging student records after the load,
will be the responsibility of the district. However, the DW ETL correction process must
have the ability to correct student records. Oracle will accept preliminary assessments
data extract and at some point, accept the final assessment data extract. Decisions on
whether the DW pulls data from the ODS or the ODS pushes data from the DW will be
determined during detail design. The ETL process will be designed with the
capability to delete a load and reload a replacement file with corrected data
provided by RISD.

Data Acquisition
All data will be stored in the RISD ODS before being extracted and loaded into the
Data Warehouse. Extract programs and testing to obtain source data for loading into the
ODS are the responsibility of RISD. Oracle will design, develop, and test software to
populate the Data Warehouse target tables and materialized views (The final design will
determine if the ODS will ‘Push’ data to the DW or if the DW will ‘Pull” data from the
ODS. Business rules for ensuring records have a valid student identifier will be a
district responsibility. Records that fail the edit will be assigned a temporary unique
student identifier in the ODS so that the data can be loaded into the DW to ensure
summary reports are correct. Student identifiers will be corrected as quickly as possible
and sent to the data warehouse as part of a full replacement file. Simple business rules
such as editing for a numeric field will be provided to the ETL process by Roy business
analysts. As mentioned, data not passing these simple edits will be defaulted to
unknown. Business rules to define metrics for inclusion in the Data Warehouse will be
defined by RISD business analysts but Oracle Consulting will be responsible for creating
the derived fields within the Data Warehouse. In some cases, metrics can be created
within the report. OWB will be used to document these business rules.

As additional database views are created to enhance reporting (primarily materialized
views associated with the EUL), they will be reverse engineered back into OWB for
documentation and future enhancements.
Data Conversion
Conversion and update processes will use the same software. RISD will ensure all
conversion history will be available in the ODS environment. That is, RISD must obtain
data for prior years, for the initial load process. After conversion, RISD may choose to
delete older historical data in the staging area, ODS, or both.
SIS Student Information
R10, RIMS, PEIMS information will be updated monthly in the Operational Data Store
(ODS) staging area. Data needed to update the Data Warehouse will be accessed via a
single database link to the ODS. Please note that there is overlapping information in
some of the source systems that may be out-of-sync in the source systems. The intent of
the ODS will be to develop business rules to have a single source for every target
element in the Data Warehouse. Since R10 is the official source for state reporting, it is
likely that R10 will be considered the system of record for overlapping elements.
However, detailed business rules will be developed during the design of the ETL process
for the ODS and it may be necessary to carry multiple elements depending on the
reporting needs. The goal of the DW is to have a “single version of the truth” for district
student profile information as much as possible. The business rule to use the student
demographics associated with each assessment will cause the student’s demographic
information to vary in some cases. For example, the TAXS report would show the student
as grade 2 and the SDAA report would show the student as grade 1 at the same point in
time. The only way to avoid this would be to use just a single source for student
demographics, like the SIS.
Assessment Information
The ETL process can accept data in flat file formats or simple tables from the staging
area but the final design expects to obtain all Phase 1 source data from the operational
data store. Business rules can be applied to cleanse key identifiers before the data is
made available to the Data Warehouse. Please note that student data provided by the
assessment office must be maintained in addition to the SIS Student data.

Student profile data provided by the assessment office will be used for state reporting
and in other cases when cross assessment test reporting are required, SIS student
profile data may be used.
Since the actual dates data available for processing will vary, all update process will need
to be scheduled. It is likely that the DW will run an automated CRON job to determine if
assessment data is available. Dependencies will be noted in the documentation process.
For example, all students on an assessment file must already have a matching student
record. As noted earlier, a process to create a temporary student identifier is needed to
ensure no assessment records are dropped. The DW ETL business rule will be to add
the record unless the student ID is invalid. Duplicate student IDs for the same subject for
the same test will be added through sequence loading.
Annual flat files will be provided plus periodic supplementary data files for new students
SDAA II – State Developed Alternative Assessment

RPTE – Reading Proficiency Test in English

Additional annual flat files currently used by Assessment Office
LDAA – Locally Developed Alternative Assessment

AP Advanced Placement Exam Results
ACT Results
Preliminary Scholastic Aptitude Test (PSAT) Results
Up to 8 administrations per year of
SAT – Scholastic Aptitude Test Results
6 Administration times per year
TAKS – Texas Assessment of Knowledge & Skills

Benchmark TEKS Checks – Texas Essential Knowledge & Skills
ERWA / TPRI – Early Reading/Writing Assessment and Texas Primary Reading

Inventory
Tejas Lee

st nd
K-2 Math - Kindergarten, 1 grade, 2 grade Math
For a total of 12 assessment files
Maintaining the Location hierarchy
RISD will provide a full Location hierarchy on a monthly basis when the SIS data is
updated. Detail layouts will be created during the design phase.
District – District Administrators
Area – Area Administrators
Location Type (HS, JHS, Elementary)
Campus (school) – Principal and School administrators
In addition, an HR interface to provide Employee – Role – Location relationships.

Report Integration with Portal

All end users and the general public can access Data Warehouse reports via an Oracle
Portal being implemented by Campus EAI. The system will be designed for 800
concurrent users who will primarily view summary results. A subset of RISD “power
users” will have the ability to go directly to Discoverer Plus to run standard reports or
create ad hoc reports. Oracle Consulting is not responsible for the portal design or
implementation of the portlets, but Oracle will provide the portlet content (see
below for Oracle obligations). Some reports may run prior to an end user accessing
the dashboard for their role in order to display aggregate without running the same report
for every user.
Portal Obligations
The third party vendor "Campus EAI" will install Oracle 10g AS Version 10.1.2 or higher
and set up the basic look and feel, graphics, template pages, portlets, RISD content, and
users and roles needed for the Data Warehouse. Therefore, the portal design is

complete and will be implemented by Campus EAI. The template pages will include
logos, page navigation, and regions for parameters, reports, and links. The report regions
will contain one or more portlets dependent upon the anticipated use of the page
template. Oracle will be responsible for providing the report links (with parameter logic),
tabs if needed for segmenting the dashboard content or report links, and the Discoverer
report portlets for the dashboards. If there are issues with the Campus installation or links
during testing, Campus EAI will be available to provide support; onsite or offsite is
acceptable, just in a reasonable period of time.
Data Access - Reporting

The Subject Areas and Information Sets in the warehouse will be organized into multiple
report areas for Phase I. The table below indicates the areas associated with the initial
reports that will be created by Oracle Consulting and RISD.
Aggregate reports may link to one or more detail reports. In some cases, reports will
have the ability to “drill” to lower levels in a hierarchy. For example, a report may begin
with a district summary and drill though the hierarchy down to a specific school.
Subject Information Sets Notes Aggregate Detail

Area Reports Reports
Assessments & Student Achievement
Texas Content High Priority 2 1
Standards
Performance (TAKS)
Texas Assessment
of Knowledge &
Skills
Adequate Yearly Medium Priority 1 0
Progress (AYP)
SDAA II State High Priority 1 1
Developed
Alternative
Assessment
RPTE - Reading Medium Priority 1 1
Proficiency Test in
English Alternative
Assessment for LEP
Students
AP Exam Pass rates Reports to be 1 1
developed by RISD

Subject Information Sets Notes Aggregate Detail

Area Reports Reports
6 Week Benchmark Reports to be 1 1
TEKS Checks developed by RISD
ACT Results Reports to be 1 1
developed by RISD
LDAA Locally Reports to be 1 1
Developed developed by RISD
Alternative
Assessment
SAT Results Reports to be 1 1
developed by RISD
PSAT Reports to be 1 1
developed by RISD
K-2 Math Reports to be 1 1
developed by RISD
ERWA / TPRI Reports to be 1 1

developed by RISD
Tejas Lee Reports to be 1 1
developed by RISD
Oracle 5 3
Subtotals
RISD 9 9
Subtotals
Dashboard
District Dashboard These are portlet 1 NA
versions of other
existing aggregate 5 Additional
reports Portlet reports
to be
developed by
RISD
Area Dashboard These are portlet 1 NA
versions of other
existing aggregate 3 Additional
reports – Also use Portlet reports
District Portlets to be
developed by
RISD
School Dashboard These are portlet NA
versions of other 2 Portlet
existing aggregate reports to be
reports - Also use developed by
District & Area Portlets RISD
Oracle 2 NA
Dashboard
Sub totals
RISD 10
Dashboard
Sub Totals
Total 26 12
Note: 8 Unique and 2 dashboard duplicate reports will be created by Oracle.
As noted earlier, some aggregate reports may need the ability to view a breakout of
report data using various dimensions. Sample dimensions are listed below; actual
dimensions will be defined during the requirements process.
• Location Hierarchy
∗ District Total
∗ Area
∗ Campus Type
∗ Campus (School)
• Gender
• Ethnicity
• Language Classification
∗ Home Language
• Poverty Indicator
∗ Meal Program (Free, Reduced)
The Data Warehouse will need to capture and display data as reported by the
assessment office to the state as well as reported by the internal RISD student SIS
system. This will be done in separate reports for simplicity of understanding.
• Source system student dimensionality as supplied from providers or source

systems (for example, TAKS to match official report filed with the state). Using the
student dimensionality provided by the source system will lead to some students

being reported with inconsistent dimensions. For example, the TAKS report could
show student 'A' in grade 4 and the LDAA report would show student 'A' in grade
3. This is not expected to be a large number of students so that it would not be
obvious on aggregate reports, but at a student level it will look like an error. Each
dimension needs to be labeled so that the source of the value is clear.
• RISD SIS dimensionality (Student ID linked to SIS dimensionality view). This may
include cleansed data.
Data Access Security

The Team will implement database level software security based on the following user
roles:
1. School Board (Includes School Board & Public) – Achievement Aggregate Data (no
individual students identified). No sign-in is necessary.
2. Central Staff (Includes Superintendent, Central Administrators, Researchers) –
Superintendent, Central Administrators, and Researchers can see all aggregate and
detail student data.
3. Area Staff (Includes Area Superintendent & Area Administrators) – Area
Superintendent and Administrators can only see the current students of the area.
4. Campus Staff (Includes Principals & Campus Administrators) – Principal & Campus
Administrator can only see the current students of the school
5. Teachers - Teacher can only see his or her current students.
6. Students (Includes Parents & Students) – Student can only see his or her
information, Parent can see only his or her students.
Additionally, roles will be created for Application Developers and Discoverer

Administrators.
RISD will provide interface files with the Employee to location relationships and the
employee to student relationship for teachers (course enrollment data). RISD will add
new users to the OID directory for the portal that drives the Data Warehouse and send
security relationship data to the Data Warehouse. The format of these interface files will
be developed during the security design phase after the security requirements are fully
documented. In addition, a simple Oracle Form will be created to allow a RISD
administrator to add a user to an existing security group (listed above). For example, for
small user groups such as central staff with ad hoc capabilities, it may be easier to add

and delete users online rather than develop an interface. The creation of new user
groups is out of scope for this project.
Data Validation and Testing

Data validation and report user acceptance testing is the responsibility of RISD. RISD
may choose to match data created via Excel spreadsheets from previous report cycles to
reports generated from the data warehouse. Oracle will correct report logic that does not
match the report specifications. User acceptance test will test the integration with portal
and includes the ability to enter parameters as per the specifications as well as verifying
the report logic.
Oracle is responsible for ensuring the update process loads data from the source files as
per the documented update specifications and properly applies business rules for
transformations and the creation of standard metrics.
Oracle is responsible for ensuring the 8 unique and 2 dashboard duplicate reports they

create match the agreed upon specification based on the data in the warehouse. Having
RISD provide expected results from previous assessment reports done manually will
facilitate the overall testing procedures.
Data load performance testing will test the ability of the system to handle the data load
and update volumes. Since the updates are no more frequent than monthly and all data
files are not available at exactly the same time, performance loading should not be of
consequence as it can be scheduled on off hours and weekends during an update
window. Except for the possible exception of the initial conversion, normal update cycles
will fit into an overnight update window.
Report generation performance has two pieces. Static reports that are created once and
viewed by many will be created in “batch” immediately after the data loads and published.
For example, static aggregate metrics that would be posted on the dashboard page
would probably be created in advance. Some reports that allow parameters to be entered
or reporting allowing drill down on dimensions will be run in real time. These
requirements will be documented when the report specifications are gathered. Response
time will be dependent on the number of users simultaneously accessing the system to
create reports.
ETL and report acceptance criteria will be documented in the ETL and Report Test plans.
Production Support Processes

RISD is responsible for all backup and recovery processes for the data warehouse.
Oracle will assist RISD in developing a process to schedule DW source updates into the
data warehouse. An automated update process cannot be developed because the inputs
will not be available on a fixed schedule.
Constraints and Assumptions

Please refer to the Fixed Price Engagement Contract Order Form for a list of
assumptions. The following items are of particular importance to keeping the project on
schedule.
• Approved decisions that are subsequently changed or “revisited” by RISD will be

handled through a change control process.

• RISD will provide Oracle with a stable technical environment and ensure that
hardware and operating system environments are available when required and in
working order.
• The single development/test HP machine will have sufficient storage to support
two full copies of the initial conversion data that will in unit and system testing.
Usable space is estimated at 500 GB for the development/test environment.
Please note, if mirroring is used, 1 TB is needed to obtain 500 GB of usable
storage. At the end of the project Oracle Consulting will clone the initial production
environment to create the development/unit test DW and the Test DW.
• The production machines will be available by May 1, 2000 or sooner.
Scope Control
Change control will be managed through the Change Control procedure defined in the
proposal. The form is in Appendix C of this document.

Objectives
District Goal
The goal of the Data Warehouse is to supply useful consistent information to decision
makers at various levels of the District via a Web-based interface in order to work
towards improving student achievement, projecting trends in student achievement, and
implement or refine instructional interventions and programs in a timely manner.
Critical Success Factors

Some critical success factors to meeting the project goals are:

• Strong executive sponsorship and management support
• Adequate project staffing to meet timelines
• Clear roles and responsibilities in order to assure accountability, ownership, and
quality
• A committed and well-informed project manager and project team having a
thorough understanding of the project goals
• A comprehensive project work plan and Project Management Plan (Scope,
Objectives, and Approach)
• A defined and maintained project infrastructure
• A thorough understanding of known project risks and assumptions by the
executive committee and project team.
• The commitment of senior user management to provide significant end user
involvement. The users' commitment and agreed participation is essential.
• Easy access by developers to end users. Ideally the developers and end users will
be co-located in their own dedicated environment, free from daily interruptions.
However, the ideal is not essential as long as contact is continual and frequent
throughout the project.
• The stability of the team. Due to the overlapping development skills required (that
is, strong interaction throughout between information analysts, database designer
and analysts) and the speed of development, the project will be put at risk if staff is
swapped in and out. Of course, specialists can be called in as required to support
the team, but the core team should be constant throughout.
• Dedicated Team Members. The District team members should be fully dedicated
or have the understanding that the Data Warehouse development is top priority..
When a team member is trying to split time and priority between other projects and
the Data Warehouse they often face conflicts and milestones are missed.
• A supportive commercial relationship. Where developers and users are from
different organizations and the development is covered by formal contract or
where developers are from the same organization but working within a service
level agreement, the relationship must accommodate the evolution of the system's
requirements without imposing onerous change management overheads.

Project Objectives
The objectives of the project are to:
• Support the mission of increasing student achievement by providing data to those

being held accountable for results
• Provide consistent access to data at the right level of detail based on an end
user’s role or responsibility

Approach
The approach includes the following main areas:
• Project Methods
• Project Work Products Completion Criteria
• Plans
• Acceptance
• Project Administration
Oracle will use Oracle Designer and Oracle Warehouse Builder (OWB) to design the
process. The logical data model will be created in Designer using Oracle’s experience
with K-12 data models to create the initial design. Similarly, Oracle will use its K-12
experience to create the initial OWB Meta Data Layer (MDL). Designer information can
be imported into OWB for full documentation. Naturally, the data model and metadata will
be adjusted to support Roy unique requirements.

Project Methods
The RISD Data Warehouse will be developed using Oracle Methodology.
Project Management Processes

The five management processes shown below collectively form a complete set of the key
tasks required to manage an information technology project. Every project involves most
of these processes, whether they are the responsibility of Oracle, RISD or a third party.
The processes overlap in time with each other, and are interrelated through common
work products.
Planning Control Completion

Project
Management
Control and Reporting
Processes
Work Management
Resource Management
Quality Management
Configuration Management
Figure 1 Project Management Processes
PJM tasks are organized into processes that help project management understand the
tasks to be performed for a successful project. The PJM processes are as follows:
The Control and Reporting process determines the scope and approach of the project,
manages change, and controls risks. It contains guides for reporting progress status
externally and for controlling the Quality Plan.
The Work Management process defines, monitors, and directs the work performed on
the project. It also maintains the financial view of the project for Oracle management.

The Resource Management process determines the right level of staffing and skills for
the project, and the working environment to support them.
The Quality Management process implements quality measures, so that the project
responds to the District’s expectations throughout the project life cycle.
The Configuration Management process stores, organizes, tracks, and controls the
items produced from the project. It also provides a single location from which the project
work products are published.
Acceptance
Contract deliverables requiring a signed acceptance certificate

1 CR.010 Delivery of a detailed project plan including both Oracle and District
Detailed resources for the entire project, including all tasks defined in the

Project Plan Preparation Phase Include Microsoft Projects Project Plan and Oracle
Project Management Plan (PMP) document
2 RD.049 Report Delivery of the Detailed Report Specifications Document that describes
Requirements all reports, dimensions, measures, calculations and business rules for the
Document required reports.
3 RD.049 Portal Delivery of the Detailed Data Warehouse Portal Security Design
Security Document that describes the functionality of the Portal pages, required
Requirements for the required Data Warehouse reports and Dashboards. The look and
feel, navigation colors and graphics and the like for the portal are not part
of these requirements, only the Data Warehouse page content, report
links and how roles and geographic defaults will operate.
4 RA.100 Logical Logical Data Model Design contains all the entities (facts, dimensions and
Data Model measures) to deliver the report requirements. The actual design will be
contained in the Designer Repository.
5 MD.070 The Physical Data Model Design contains all the logical model entities,
Physical Data needed indexes, partitioning and parameters to define the objects for the
Model data warehouse. Only the standard materialized views and indexes will
be included in this design.
6 TA.010 The Technical Architecture Document describing all Development, Test
Technical and Production components, including the hardware, platform, software
Architecture versions, set up configurations and database schemas and development
Document repositories
7 TE.100 ETL Test Results as per test plan, agreed upon during the design phase
Integrated ETL
System Test
Results
8 TE.100 Report Test Results as per test plan, agreed upon during the design phase
Integrated
Report System
Test Results
9 MD.120 Verify System has been stable in production for 1 week after the signoff on the
Production Integrated ETL System Tests and Integrated Report System Tests. Stable
Readiness is defined as running with no critical or high priority errors with only
planned or down times not a result of Data Warehouse problems. Power
outages, network issues, human errors are not considered a Data
Warehouse problem.
All Work Product project documentation will be submitted not more than twice and the
review must be completed within a total of three business days. Draft Work Products will
be available for review before the “final” Work Product is presented. The RISD project
manager will review all Work Products within three (3) working days from delivery and
return one consolidated set of comments to Oracle. Upon receipt of comments from
RISD, Oracle will resubmit the Work Product in final form after incorporating the
applicable and necessary changes. When the final form is submitted, acceptable will be
based on the comments previously raised, no new issues can be raised. Following
Oracle’s delivery of the final version of documentation, assuming proper incorporation of
team member comments, RISD or its representative will have three (3) working days
from delivery in which to provide Oracle with written notification of its acceptance of the
Work Product. RISD written notification will normally take the form of an executed copy of
Oracle’s standard Certificate of Acceptance. In the absence of RISD’s specific
acceptance or rejection of these Work Products at the end of the three (3) working day
acceptance periods (draft and final, respectively), the Work Product and applicable
services will be deemed to have been approved and accepted. However, the intent is to
obtain Roy’s comments and feedback for work in progress to minimize the time for
“official” review and acceptance.

Project Administration
The following administrative arrangements have been made for this project:
• RISD has provided a workroom with 4 terminals and two work areas for team
meetings.
• All draft and final work products, and DSS related documents, will be stored on the
project server provided and backed up by RISD.
• Oracle will honor all holidays recognized by Oracle or RISD, although with
permission, Oracle may choose to work on holidays and weekends.
• Oracle may work off site during extended Roy vacations, such as the Spring
Break, March 4 – March 11.
• There is a two to three week break at the end of June to mid-July where most staff
is not available and must be factored into the schedule
• There should be no Friday meetings scheduled for June as many staff members
are on a 4-day, 10-hour schedule.
• School begins 8/17 and there will be limited access to Roy personnel between
8/10 and 8/24.

Control and Reporting

The Control & Reporting process determines the scope and approach of the project,
manages change, and controls risks. This process reports progress status externally and
controls Project Management Plan preparation and updating.
Issue Management
Issues and action items will be tracked using an Excel spreadsheet maintained by the
Oracle project manager. Roy’s internal tracking system may be used in at some point
later in the project.
Record Issue Details

Any team member or RISD staff may raise an issue and get it added to the RISD
Issue tracking system.
The Oracle Project Manager, or the agreed upon owner, will investigate the issue
and, if necessary, will update the Issue Log with background information to place the
issue in perspective.
Issue resolution will be tracked in the RISD system. Issues that cannot be resolved
will be brought to the attention of the steering committee for resolution.
Occasionally an issue resolution might lead to a change request.
If no action is taken, this fact must be clearly indicated in the Issue Log.
Risks and Issues will be reviewed and addressed during the weekly PMO meetings
tentatively scheduled for every Tuesday. In the event the Oracle staff is working off site,
the meeting will be conducted via conference call. Issues that have potential to
significantly impact the project schedule or budget are presented biweekly at the
executive sponsors meeting.
In the course of the project, team members will identify problems. The Oracle and RISD
project managers and technical team leaders will work with project members to resolve
any problem areas. Potential problem areas have already been identified as risks. Some
problems may be added as issues and/or action items as determined by the project
managers. We do not wish to track every question a team member has but to track items
that may impact the work plan or budget.
The valid statuses for an issue are as follows:
Status Description
Identified The issue has been identified for investigation.

Assigned The issue has been assigned for investigation or clarification.
Resolved A resolution of the issue has been resolved. In some cases the
resolution leads to an action item or to a change request.
Deferred A resolution of the issue has been deferred until the specified target
date. In some cases no action will be necessary.
Action Item Management

Action items refer to detailed tasks that arise during the course of a project that have not
been identified in the project plan. The intent is to assign action items to team members
before they become issues. The Oracle project manager and the RISD project manager
will ensure action item commitment dates are met and unresolved items will be brought
to the steering committee for resolutions. Action items will be tracked in the RISD
tracking system.
Risk Management
A Risk Management Procedure will be implemented by tracking risks in an Excel
spreadsheet. Risks will be reviewed periodically at weekly progress meetings. Any team
member can identify a risk to either the Roy project manager or the Oracle project
manager. For new risks, the project managers will make a joint decision on whether or
not a special meeting is required or if the risk can be discussed at the next scheduled
status meeting. The Oracle project manager will maintain the risks spreadsheet.
A risk is any characteristic, situation, or circumstance that is recognized as having a

potentially adverse effect on the project or on the quality of a deliverable. A critical
success factor within project management is to identify and manage risk to avoid cost
overruns and missed milestones.
All risks are entered on the risk tracking spreadsheet. Provide as much detail as possible
to fully explain the nature of the risk. Investigate mitigation approach and contingency
action(s). All open risks (yellow or red status) will be reviewed on a weekly basis. Project
Managers will monitor current status very closely until the risk status changes to green.
Risks are escalated to the next level based on the current status and magnitude of risk.
Project Managers will develop and implement mitigation strategies that minimize or
eliminate identified risks. Project Managers will monitor risk mitigation strategies’
effectiveness and compile and interpret performance measurement.
Change Management
To complete the project on time and on budget it, is imperative to manage to the original
scope of the project. The Change Request form will be used to propose a change to
initial activities or to add project activities. The forms will be filled out even if the change
or addition has no impact on schedule or budget. Naturally, change requests having an
impact on schedule or budget need to be addressed and approved or rejected quickly.
Any project team member that may initiate the Change Order process. Initially, a Change
Request Form, Attachment C, will be prepared and provided to the Project Managers.
The Oracle and RISD Project Managers will review all open requests weekly. When a
Change Order that effects schedule or budget is necessary, the Project Managers will
present their findings to the Project Sponsors. Approved budget changes will require a
change order.
Status Monitoring and Reporting

Reviews
The purpose of a Status Meeting is to ascertain the health of a project, identify issues
and agree on appropriate actions. In addition, Project and Phase Status Meetings are
intended to make sure that the project has planned to address the requirements of the
contract and that RISD and the Oracle project teams are fully briefed on the objectives
and their responsibilities. Oracle has planned for and included regularly scheduled status

meetings within this plan. Team Progress Reviews will be held on a weekly basis to
assess the progress of each team member and to plan for the following week(s).
Progress Reporting
Oracle shall provide a written weekly status report:
Project to date summary and status (green, yellow, red)
Reporting week accomplishments and work activities
Milestone Status and Targets
Planned activities for the next period
Open Issues
Open TARS
Administrative Plans

Work Management
The Work Management process is responsible for defining, monitoring, and directing all
work performed on the project. In addition, it must maintain a financial view of the project
for management review.
The Work Plan for this project is maintained in Microsoft Project. The project plan will
supplement this document.
Unplanned activities will be tracked by each team member and documented in the
weekly status reports to the Oracle Project Manager. The Oracle Project Manager will
work with the RISD Project Manager to determine impact to the project.

Resource Management
The Resource Management process provides the project with the right level of staffing
and skills and the right environments to support them. It does not cover purchasing,
recruiting, and accounting procedures; these are practice management issues and are
therefore outside the scope of this Project Management Plan. Oracle Consulting will bring
resources to the project as appropriate to meet project schedules. At times it may be
necessary to “crash” the schedule by bringing on additional resources and at other times
to reassign resources to other projects in order to manage the budget.
Staff Resources
Project Team

The composition of the project team is critical to produce a successful system. The
Project Team will take advantage of the functional experience and business knowledge
provided by the RISD team members and the technical knowledge and experience of the
Oracle Team members. To promote the success of the implementation, the following
project organization is proposed.

Configuration Management
Three types of procedures will be developed: Document Control, Configuration Control
and Release Management.
Software Configuration Management Standards and Procedures

The goal of configuration management is to ensure that work products from the team can
be reproduced at any point in time. To ensure this, RISD and Oracle Consulting will
utilize the directory structure and version control numbers below to manage the
deployment and recovery of new software.
This section describes the directory structure and versioning scheme for development,
test, and production environments.

Development:
Working code is stored in the repository of the developer's PC, but all developers will
back up their code once a day
Objects Description
OWB OWB-defined or OWB-stored metadata (mappings,

tables, sequences, generated code, and so on) will
be managed within OWB using the deployment
management functionality in the tool. Key project
points and releases will be archived as well via
exports to a file system directory.
Designer Designer defined or stored meta data tables, views

materialized views, sequences, and generated DDL
using the Designer. Key project points and releases
will be archived well via exports to a file system
directory.
Custom Custom written data definition language scripts for

tables, views, materialized views and/or summaries,
indexes, and so on and custom written PL/SQL
packages, triggers, functions and procedures will be
reverse engineered into Designer, imported into
OWB or both.
Operating Operating System scripts for populating DW

System warehouse
Scripts
Disco Discoverer EUL and reports will be exported to a file

system directory.
Portal All portal configuration management will be the

responsibility of the Portal team outside of the Data
Warehouse.

Document Control
All documents produced as project work products will be subject to Version Control.
The Version Control procedure includes the following steps:

1. Documents that are work-in-progress and are not ready for first review are not
subject to Version Control.
2. Once a document is ready for first review, it will be versioned as 1.0, Draft with the
date of last update on the title page.
3. Subsequent updates to the document require an update to the document history
stating who updated the document and what types of edits/updates were made and
the date (1.1 Draft, 1.2 draft).
4. The Older version of the document should be saved using the version of the
document as the file’s suffix, that is, filename.v01.

5. The current version of the document will have the suffix used by the tool used to
generate the document, that is, filename.doc if it is a Word document, or
filename.mpp if it is a MS Project document.
6. When a new version is created, the appropriate team members should be notified
verbally or via e-mail and all OLD (noncurrent) hard copies of files should be
disposed of immediately.
7. All documents shall have the file name and path included in the footer.
Release Management
Over the course of this project, a single release will be developed and transitioned to
production.

Appendix A - Work Plan

The detailed Project plan is in Microsoft Project.
ID Task Start End Resource
DW Implementation Project 1/17/00 8/4/00
Pre Project Planning 1/17/00 5/2/00

APPROVAL Obtain Board Approval 1/17/00 1/17/00 District
RISD Sign Contract 1/18/00 2/4/00 District, Oracle
RISD Obtain Development/Test 2/7/00 2/18/00 District
RISD Set up Dev/Test Environment 2/21/00 2/23/00 District
RISD Obtain and setup Production Environment 1/18/00 5/2/00 District
RISD Preliminary Kickoff 1/28/00 1/28/00

Prepare Preliminary PMP and Draft 1/31/00 2/4/00 OPM
Project Plan
START Project Start 2/7/00 2/7/00
DEFINITION PHASE 2/7/00 2/23/00

Requirements Definition Process 2/7/00 2/15/00
A.RF.010 Confirm Detail Business and System 2/7/00 2/8/00 OPM[33%],RPM[33%],Director[3
Objectives 3%]
A.RF.020 Define Requirements Standards and 2/9/00 2/9/00 OPM[25%],Director[25%]
Guidelines
A.RF.025 Define Information Requirements 2/10/00 2/11/00 OPM[25%]
A.RF.090.1 Develop/Confirm MoSCoW list for Report 2/14/00 2/15/00 OPM[50%],RPM[50%]
Requirements[State = Initial]
A.RF.095.1 Obtain Existing Reference Material [State 2/7/00 2/7/00 RPM
= Initial]
Finalize Baseline Project Plan 2/9/00 2/11/00 OPM[25%]
Milestone 1 Signoff on Project Plan 2/14/00 2/16/00 RPM[25%]
Requirements Analysis 2/7/00 2/18/00
RISD Working Sessions with Functional Team 2/14/00 2/18/00 District[20%],Director[20%]
A.RA.100.1 Construct Business Data Model [State = 2/7/00 2/10/00 Arch

Initial]
A.RA.150.1 Define Data Quality Approach 2/14/00 2/16/00 District[25%]
[State=Initial]
Finalize PMP 2/16/00 2/16/00
Data Acquisition Process 2/14/00 2/14/00
A.DA.010 Confirm Data Sources 2/14/00 2/14/00 OPM[25%],Director[25%]
Technical Architecture Process 2/9/00 2/23/00

A.TAD.010.1 Define Architecture [State = Initial] 2/9/00 2/23/00
RISD Technical Team work session 2/22/00 2/23/00 Team[25%],Arch[25%],Director[2

5%]
Document Arch (Initial) 2/9/00 2/10/00 Arch[25%]


RISD Establish Portal Requirements (initial) 2/15/00 2/16/00 District
Adoption and Learning 2/9/00 2/9/00
A.AP.020 Conduct interfaces team Meeting & 2/9/00 2/9/00 Team[25%],OPM[25%],Director[
schedule follow-up sessions 25%]
REQUIREMENTS MODELING PHASE 2/7/00 3/16/00

B.RF.090.2 Develop MoSCoW list Report 2/7/00 2/16/00
Requirements[State = Refine]
Assessment Team Kickoff 2/14/00 2/14/00 OPM,Director,Arch,District
Functional reports team work session 2/16/00 2/16/00 Team[50%],OPM[50%],Arch[50

%]
Initial Data Model Review 2/14/00 2/15/00 OPM[25%],RPM[25%],District[25

%],Director[25%],Arch[25%]
B.RF.095.2 Obtain Existing Reference Materials 2/23/00 2/23/00 RPM

(Final)
Requirements Analysis Process 2/16/00 2/24/00
B.RA.001 Deploy Development Standards and 2/24/00 2/24/00 OPM[50%],RPM[50%]
Guidelines
B.RA.100.2 Construct Business Data Model [State = 2/16/00 2/16/00 Arch
Revise]
B.RA.135 Define Solution Integration Functional 2/17/00 2/18/00 OPM[25%]
Architecture
RISD Obtain and Review Campus EAI 2/16/00 2/16/00 Director
templates
B.RA.140 Define Solution integration technical 2/17/00 2/18/00 OPM[25%]
Architecture
B.RA.150.2 Define Data Quality Approach 2/21/00 2/21/00 OPM[25%],RPM[25%]
[State=Final]
B.RA.160 Conduct Data Source Gap Analysis 2/17/00 2/21/00 Arch[50%]
B.DA.075 Confirm Data Acquisition Approach 2/15/00 2/17/00 OPM[20%],Director[17%]
Data Access Process 2/24/00 3/1/00

B.AC.015 Define Data Access Approach 2/24/00 3/1/00
RISD Define Interface Requirements with Portal 2/24/00 2/28/00 OPM[25%],Director[25%]
(Initial)
Define Security Requirements (Initial) 2/28/00 3/1/00 Director
B.TAD.010.2 Define Architecture [State = Refine] 2/21/00 2/22/00 OPM[50%]
B.TAD.020.1 Define Capacity Plan [State=Initial] 2/23/00 2/24/00 Arch[25%]
B.TAD.035.1 Construct Development Environments 2/24/00 2/25/00 District

[State = Initial]
B.TAD.040 Define Detailed System Operational 2/25/00 2/25/00 OPM
Requirements

B.TAD.050 Define Administration Approach 2/28/00 3/1/00 OPM[50%],RPM
B.TAD.055 Conduct Technical Risk Assessment 2/25/00 2/28/00 OPM[25%]
RISD Confirm Portal Requirements 2/21/00 2/22/00 District
Database Design and Build Process 3/2/00 3/2/00
B.DB.002 Deploy Database Standards and 3/2/00 3/2/00 OPM[50%]
Guidelines
Testing Process 3/2/00 3/8/00
B.TE.007 Define Acceptance Criteria 3/2/00 3/4/00 OPM[33%],RPM[33%]
B.TE.009 Define Testing Requirements & Testing 3/7/00 3/8/00 OPM[25%]

Approach
Transition 3/15/00 3/16/00
B.TS.005 Define Cut-Over Approach 3/15/00 3/16/00 OPM[50%]

CONSTRUCTION PHASE 2/17/00 7/20/00
C.RF.090.3 Develop MoSCoW list Report 2/17/00 2/18/00 OPM[50%],RPM[50%]
Create Reporting Requirements 2/21/00 4/1/00 OPM[25%]
Document
Milestone 2 Signoff Reporting Requirements 4/4/00 4/6/00 RPM
Document
Requirements Analysis Process 2/28/00 3/4/00
C.RA.100.3 Construct Business Data Model [State = 2/28/00 3/1/00 Arch[25%]
Final]
Construct Preliminary Database Object 3/2/00 3/2/00 Arch[50%]
C.RA.170 Conduct Data Quality Assessment 3/2/00 3/4/00 District,Director[0%]
RISD Initial ODS Design 3/4/00 3/4/00 District
C.DA.240 Map Source Data to Target Logical 3/11/00 3/17/00 Arch[80%]
Database Design(s)
RISD Final ODS Design 3/17/00 3/17/00 District
RISD Populate ODS with Data for testing 3/28/00 3/28/00
C.DA.255 Define Data Acquisition Model in OWB 3/18/00 3/24/00 Arch[80%]
C.DA.455 Develop Data Acquisition (ETL) 3/25/00 5/26/00
Components using OWB
Create ETL Modules and unit test 3/25/00 4/14/00 Arch
Support additional ETL activities and unit 4/15/00 5/26/00 ETL
test
Define Portal Security Requirements 4/22/00 4/26/00 OPM[10%],Director[50%]
Milestone 3 Signoff on Portal Security 4/27/00 4/29/00 RPM

Requirements
Implement Security Input forms and 3/21/00 5/19/00
interfaces
Create and unit test Input forms 4/22/00 5/5/00 Arch[50%]
Create Security updates from input form 5/6/00 5/19/00 Arch[50%]
Design Reporting Data Interface 3/21/00 4/1/00 Portal

C.AC.125 Define Data Access Model - Discoverer 4/11/00 4/15/00 Disco
EUL
C.AC.170.1 Develop User Role Access [State = Initial] 4/18/00 4/19/00 Disco
C.AC.223 Develop 8 Data Access Discoverer 4/20/00 5/10/00 Disco
Reports
RISD Develop 20 Data Access Discoverer 4/20/00 6/15/00 District
Reports
C.AC.235.1 Develop Business Metadata for Data 6/16/00 6/20/00 OPM
Access
C.TAD.020. Define Capacity Plan [State=Final] 2/25/00 2/28/00 Arch[12%]
2
C.TAD.035. Construct Dev/Test Environment [State = 2/28/00 3/4/00 District

2 Final]
C.TAD.010. Define Architecture [State = Final] 3/2/00 3/8/00 Arch[20%]
3
C.TAD.080 Detail Recovery and Fallback Approach 3/9/00 3/10/00 District
C.TAD.090 Define Security and Control Approach 3/11/00 3/14/00 OPM[50%],District
C.TAD.110 Define Administration Model 3/15/00 3/18/00 District
Create Technical Architecture Document 3/21/00 3/25/00 OPM[50%]
C.TAD.120 Develop Administration Components 3/28/00 3/30/00 District
Milestone 6 Signoff on Technical Architecture 4/11/00 4/13/00 RPM
Document
C.DB.010 Create Logical Database Design 3/3/00 3/8/00
Finalize Dimension 3/3/00 3/4/00 Arch
Finalize Facts and derived fields business 3/7/00 3/8/00 Arch
rules
RISD Review Logical Data Model 3/9/00 3/10/00 OPM
C.DB.040.1 Create Physical Database Design [State 3/2/00 3/2/00 Arch
= Initial]
Milestone 4 Signoff on Logical Data Model 3/11/00 3/15/00 RPM
C.TE.027 Create Integration and Testing Plan 5/2/00 5/4/00 OPM
C.TE.028 Develop Component Test Checklists 5/5/00 5/6/00 OPM
C.TE.035 Develop Component Tests 5/9/00 5/13/00 OPM[75%]
C.TE.036 Create System Test Draft Document (ETL 5/16/00 5/20/00 OPM
& Reports)
C.TE.038 Assist RISD with User Acceptance Test 5/23/00 5/25/00 OPM[50%]
Approach
RISD ODS Populated with Historical Data 6/20/00 6/20/00 District
C.TE.070 Perform System Integration Test (ETL) 6/21/00 6/27/00 Arch
Correct issues from ETL System Test 6/28/00 6/30/00 Arch
Compile ETL test reports and update ETL 7/1/00 7/5/00 OPM[50%]
test Document
Perform System Test (Reports) 6/28/00 7/5/00 OPM
Correct Issues from Reports System Test 7/6/00 7/8/00 Arch

C.TE.100 Perform System Integration Test (user 7/14/00 7/20/00 Arch
Acceptance)
C.TE.101 Compile Report Test Results & Update 7/11/00 7/13/00 OPM
Reports System Test Document
Milestone 7 Signoff on ETL System Test Results 7/14/00 7/18/00 RPM
Milestone 8 Signoff on Report System Test Results 7/14/00 7/18/00 RPM
Transition 5/9/00 5/13/00
C.TS.030 Develop Installation Plan 5/9/00 5/13/00 OPM[15%],Arch[40%]
Adoption and Learning 5/20/00 6/22/00

C.AP.130 Conduct User Learning Needs Analysis 5/26/00 5/31/00 RPM
Provide technical support to Roy 5/20/00 6/17/00 Arch[25%]
Document Training Recommendation 6/20/00 6/22/00 OPM[75%]

PRODUCTION PHASE 2/24/00 8/4/00
Support final testing and Move Test 7/14/00 7/20/00 DBA
environment to production
D.DA.460 Perform Initial Load of Production 7/21/00 7/22/00 Arch
Databases
D.AC.235.2 Develop Business Metadata for Data 2/24/00 3/2/00 Arch[20%]
Access
D.AC.170.2 Develop User Role Access [State = Final] 4/20/00 4/21/00 Arch[25%]
D.DB.040.2 Create Physical Database Design [State 3/3/00 4/6/00 Arch[10%]
= Final]
Create Physical Design Document 4/7/00 4/11/00 OPM
Update Database Schema 4/7/00 4/8/00 Arch[25%]
Milestone 5 Signoff Physical Database Design 4/12/00 4/14/00 RPM
D.TE.117 Execute Final Data Validation & Data 7/25/00 7/26/00 District,Arch,OPM
Access Test
D.TE.119 Execute Pre-Production Validation 7/27/00 7/27/00 District,Arch[50%]
Document Production Readiness 7/27/00 7/27/00 OPM
Transition 7/27/00 7/27/00
D.TS.060 Go Production 7/27/00 7/27/00
Close out Adoption and Learning 7/28/00 8/1/00
D.AP.170 Conduct User Learning Events 7/28/00 7/29/00 OPM,Arch[50%],District
D.AP.180 Conduct Effectiveness Assessment 8/1/00 8/1/00
Support Process 7/28/00 8/4/00
D.SU.075 Solution Support 7/29/00 8/4/00 Arch[50%],District
Create Test Environment 7/28/00 8/3/00 Arch[50%]
Milestone 9 Signoff on Production Readiness 7/28/00 8/1/00 RPM

Appendix B - Roles and Responsibilities
The following roles were extracted from the Proposal accepted by RISD. In general, the
assigned persons will be responsible for tasks requiring specific skill sets. When the
District resources change, the District Project Manager will ensure that these project
team members provide the transition handover to ensure that there is no delay in the
project activities or productivity level and ensure that coverage exists for any outstanding
assignments. If resource changes occur within the Oracle staff, Oracle Project Manager
will use the same approach to maintain continuity and avoid unnecessary delays in
progress. Please note that not all roles are full time for the project and in some cases the
same person may fill multiple roles.
Some tasks will require representation from various District functional areas. The District
will provide all necessary resources to support these tasks.

Executive Sponsor – The District will provide an executive sponsor who will ensure
resources are made available as per the schedule. The executive sponsor will provide
project leadership and decide escalated issues.
Steering Committee – The District and Oracle Team will provide steering committee
members. Steering committee members will provide project leadership, decide scope
issues, and resolve escalated issues.
District Project Manager – The District will provide a project manager whose chief
responsibility will be to act as liaison between Oracle Team and the District.
District User Groups – These resources will represent the end user communities and
provide requirements and functional expertise. They will also participate in the user
acceptance testing of the system.
Oracle Project Manager – This resource will serve as on-site Oracle project Manager,
and monitor the team’s efforts in tracking to the project workplan.
Oracle Technical Lead/Architect – Oracle Technical Lead/Architect will provide

technical leadership and support the District in designing, building, and testing all
processes involving the Data Warehouse. The resource will also provide DBA technical
leadership and support the District in designing the logical and physical data models, and
in tuning the database performance.
Oracle OWB Specialist – The Oracle OWB Specialist will be supporting the designing,
building, and testing of all processes involving the transformation and loading of data.
District OWB Specialist – The District OWB Specialist will be supporting the designing,
building, and testing all processes involving the transformation and loading of data. This
resource will be peer mentored with the intent that they can develop and maintain the
system going forward.
District Source System Specialists – The District will be an “as needed” resource (full
time at certain key junctures) for the data residing in the source applications. This person
will provide the data, related format information and answer questions to Oracle technical
consultants, as well as participate in data mapping activities. The District Source System
Specialists will be responsible for developing any data extracts on the source system.
There must be a source system specialist for each source system to be incorporated into
the Data Warehouse

District DBA/Oracle Designer – The District resource will support the designing of the
logical and physical data models, and tune database objects comprising the reporting:
data stores, transformation/load processes, and all other objects developed by the
technical team. This recourse will be peer mentored with the intent that they can develop
and maintain the system going forward.
District Network Administrator – The District will provide on a limited basis technical
support relating to the District’s intranet and the network administration.
District System Administrator – The District will provide on a limited basis technical
support relating to the District’s systems administration, and core Oracle database duties
(startup, shutdown, backups, and any other requisite system administration functions).
Oracle Data Access Specialist – Oracle will provide technical leadership and support
the District in the designing and building the End User Layer (EUL) and limited number of
reports, using Discoverer.

District Data Access Specialist(s) – The District resource(s) will support the designing
and be the primarily developed of the end user data access(Reports), using Discoverer.
This recourse will need to be a skilled Discoverer resource. The resource will be peer
mentored with the use of Discover for Data Warehouses and Dashboards with the intent
that they can develop the majority of the reports and maintain the system going forward.
Campus EAI / District Portal Developer – Campus EAI / District will provide technical
leadership and support the District in the designing and building of the Enterprise portal.
Oracle Data Warehouse Portal Developer – Oracle will provide technical extensions to
the enterprise portal for the data warehouse in the area of security and Dashboard
integration.
District Portal Developer – The District resource will support the designing and building
the Data Warehouse portal using Oracle Portal. This resource will responsible for
developing and maintaining the system going forward.
District Training Specialist – The District resource will support the testing of the Data
Warehouse, and support the planning and developing of the training materials. The
District training specialists will receive coaching/mentoring from Oracle and they will be
responsible for training end users.

Attachment C - Change Request Form
CHANGE REQUEST FORM

Ref: ___/___/ CRF/ ___
Originator’s Name: Priority: Critical/High/Medium/Low (Circle one)

Functional Area: Date Raised:
Phase/Process: Assigned to:
Client Request?: YES/NO (Circle one) Date Resolution Required:
Status: Open/Assigned/Investigated/Resolved/Approved/Deferred/No Action (Circle one)
Change Details (description of proposed change, the reason for the proposed change, the
impact of the proposed change and the implications of not performing the proposed change):

Investigation:
Estimated Impact: Effort: Cost:
Schedule:
Possible Action (list changes):
Actual Impact: Effort: Cost:
Schedule:
Accepted (<Consultant>): Accepted (Client):
Date: Date:
Completion Verified By: Completion Date:
Associated Problem Report: Associated Risk and Issue Form:
Form 18/V2 Page __ of ___

RD.049 PORTAL SECURITY
REQUIREMENTS
M3 RISD_Security_Require_3.0.doc

Roy Independent School District
(RISD)
Data Warehouse System
Author: Oracle Services Industries
Last Updated:
Document Ref: RISD/DW/002
Version: 3.0
Approvals:
RISD
Oracle
RD.049 Portal Security Requirements Doc Ref: RISD/DW/002
Document Control
Change Record
3

Reviewers
Name Position
Distribution
1 Library Master Project Library

2
3
4
RIDS Data Warehouse Page ii

Contents
Document Control............................................................................................. ii
Change Record............................................................................................ ii
Reviewers.................................................................................................... ii
Distribution ................................................................................................. ii

Introduction........................................................................................................1
Purpose.........................................................................................................1
Background ..................................................................................................2
Related Documents ......................................................................................2
Executive Overview...........................................................................................3
Portal Security..............................................................................................3
Data ....................................................................................................................5
Source Data Requirements...........................................................................5
Data Access Requirements ................................................................................6
Reporting .....................................................................................................6
Aggregate versus Detail reports...................................................................6
Common Reporting Requirements ..............................................................6
Constraints and Assumptions.......................................................................7
Portal Requirements...........................................................................................8
Portal Security Requirements ......................................................................8
Functional Update and Data Access Process...............................................9
Portal Page Functionality...........................................................................10
Database Security Data Model ..................................................................12
Portal Security Interfaces with the Data Warehouse .................................13
Portal Implementation Approach...............................................................14
RIDS Data Warehouse Page iii

Introduction
This portal security requirement deliverable documents the Phase 1 Data Warehouse
(DW) report integration with Oracle Portal. Campus EAI will provide RISD with
assistance with the installation of Oracle 10g Application Server (10gAS) by providing a
repository of portal pages and portlets that will be used by the RISD portal development
team to support RISD requirements. Oracle Consulting will be responsible for the
content of the framework pages using the DW as inputs and the database security to
restrict data access by security group. The original scope of the baseline portal
implementation project plan is to provide data access to RISD employees, the BOT
(Board of Trustees), students, parents, and the general public. Campus EAI suggested a
phased approach where a subset of users will have access through portal before rolling
out access to all users.
The revised initial implementation approach will be to allow access to RISD employees
and the RISD board. All users in these groups will have access to summary assessment

information down to the campus (school) level. All users, except the BOT, will have
access to teacher and student information with restrictions by individual responsibility
and a “need to know.”
The system will be designed to allow student, parent, and the general public access in
future releases. Security will be defined for Phase 1 to allow RISD to add these security
groups independent of the post Phase 1 DW implementation schedule.
• The BOT (RISD Board) will have access to summary information down to the
campus level. If RISD limits BOT access, a special BOT report menu may need
to be developed.
• District administrators will have access to all data including student information
for both current and former students.
• Areas administrators will have access to all aggregate data but only access to
student information for students in their area (current and former students).
• Schools administrators will have access to aggregate data but only access to
students currently in their campus.
• Teachers will have access to all aggregate data but only access to student
information for students currently in their classes.
• Parents will have access to all aggregate data but only have access to their
child’s assessment information. For simplicity, a parent will have separate Ids if
they have multiple children in district schools.
• Students will have access to all aggregate data but only have access to their own
assessment information.
Purpose
This document clearly defines the data integration between Oracle Portal and Oracle
Discoverer report information. Since the data security will be assigned at the database
level, data security will apply when accessing standard reports via portal, direct data
access through standard SQL, and Oracle data access through Discoverer Plus.
The Data Warehouse Portal Security Design Document describes the functionality of the
portal pages required to access portal dashboards and Data Warehouse reports by user
security group. The look and feel, navigation colors and graphics and the like for the
portal are not part of these requirements; only the Data Warehouse page content, report
links and how roles and location defaults will operate are included.

Background
The Data Warehouse environment will provide decision makers throughout the District
with information to help improve student achievement. Users will access the system via
Windows based Internet-capable computers and workstations to accommodate the
needs of both computer novices and experts. Discoverer report data can be downloaded
into local applications where appropriate (for example, spreadsheets and PC databases)
to perform additional analysis or to integrate it with local data.
Individual data access will be restricted to information associated with the user’s
responsibilities, needs, and skills. The majority of end users will run parameter driven
reports from a predetermined menu. However, dimensions such as location can be
changed to view different levels of detail. For example, a user may start with a district
view for a report and then “drill” to lower levels of the hierarchy such as area and
campus.
Some power users may go directly to Discoverer Plus for added functionality and to

create and run ad hoc reports on an as needed basis. As noted, most users will have
access to parameter driven reports using Discoverer viewer with the menu of reports
being controlled by Oracle Portal. Data access security will apply to any type of data
access since security is controlled by Oracle’s Virtual Private Database (VPD) option.
Related Documents
• Milestone 1, RISD DW baseline Project Plan

• Oracle RISD Data Warehouse Proposal
• RISD Fixed Price DW Engagement Contract Order Form
• RISD DW Project Management Plan (PMP)
• Milestone 2, RISD Report Requirements
• Milestone 4, RISD DW Logical Data Model
• Milestone 5, RISD DW Physical Data Model
• Milestone 6, Technical Architecture
• Milestone 7, ETL test results
• Milestone 8,RISD DW Report test plan and results
• Milestone 9, Production Readiness
Please note that some information in this document originated in the documents
listed above. This deliverable is intended to be understood without referencing
multiple documents but there are references to other documents when additional
detail is available.

Executive Overview
This section summarizes the portal data security requirements for the RISD Phase 1
Data Warehouse implementation. All users of the RISD data warehouse are required to
login to the system through Oracle Portal with the exception of the general public who will
be limited through the menu selection to a subset of aggregate reports. The user ID and
password management will be implemented to meet standard RISD security
requirements.
Portal Security
Initially, only RISD employees will be permitted access to the RISD data warehouse
environment. All users will be required to have access to the RISD intranet environment
to ensure full security.
Note: Only the District Assessment team can view preliminary assessment information.
That is, occasionally, data will be loaded before student matching and data cleansing is

complete and the information is not ready for publication. In these cases, the data would
only be available to the District Assessment Team security group.
Security Group Student Student Detail Teacher Teacher Aggregate Campus Area District
Detail Description Aggregate Description Aggregat Aggregate Aggregate
e
Student and Yes Only the individual No N/A Yes Yes Yes
Parent Student
Teacher Yes Current students, Yes Aggregates for the Yes Yes Yes
all assessments individual teacher
Campus Admin Yes All students Yes All teachers on campus Yes Yes Yes
(includes currently on but restricted to students
assistant campus and in the administrator’s
principal, incoming class campus since teachers
advisors and can teach in multiple
so on) campuses)
Principal Yes All students Yes All teachers on campus Yes Yes Yes
currently on but restricted to students
campus and in the principal’s campus
incoming class since teachers can teach
in multiple campuses
Area Admin Yes All students Yes All teachers in the area Yes Yes Yes
currently in the but restricted to students
area and incoming in the administrator’s area
class since teachers might
teach in campuses that
cross areas
Area Yes All students Yes All teachers in the area Yes Yes Yes
Superintendent currently in the but restricted to students
Area in the area
superintendent’s area
since teachers might
teach in campuses that
cross areas
Central Admin Yes No Restrictions Yes No Restrictions Yes Yes Yes
Central Yes No Restrictions Yes No Restrictions Yes Yes Yes
Superintendent
School Board No N/A No N/A Yes Yes Yes
Public No N/A No N/A Yes Yes Yes

Security Group Student Student Detail Teacher Teacher Aggregate Campus Area District
Detail Description Aggregate Description Aggregat Aggregate Aggregate
e
District Yes No Restrictions Yes No Restrictions Yes Yes Yes
Assessment
Team

Data
The following information is based on the Project Management Plan (PMP).
Source Data Requirements

SIS Student Information
Student information will be updated daily in the data warehouse via RIMS information
updated daily in the Operational Data Store (ODS). PEIMS information will be updated
as available in the Operational Data Store (ODS) and the data warehouse. Data needed
to update the Data Warehouse will be accessed via a single database link to the ODS.
Please note that there is overlapping information in some of the source systems that may
be out of sync in the source systems, which is why RIMS was selected as the single
source for Phase 1. The intent of the ODS will be to develop business rules to have a

single data source for every target element in the Data Warehouse. The goal of the DW
is to have a “single version of the truth” sourced from the official SIS data with point in
time student profile information.
Assessment Information
Although the DW ETL process can accept data in flat file formats or from any Database
table, all data needed by the data warehouse will to be loaded into the Operational Data
Store. Business rules will be applied to cleanse key identifiers before the data is made
available to the Data Warehouse. Please note that student data provided by the
state in assessment data files must be maintained IN ADDITION to the SIS Student
data. In many cases Student demographic data provided in the assessment files will be
used for state reporting but in other cases when local or cross assessment test reporting
is required, SIS student demographic data will be used.
In some cases there are multiple administrations of a single test but even in cases where
there is only one administration, there are often supplementary assessment files of new
RISD students who took the test while in another district.
Please note that assessment files will be provided on an “as available” basis and
scheduled to update the database after a cleansing process has been performed. Since
dates assessment files become available vary greatly, all update process will need to be
scheduled. Dependencies will be noted in the documented production process. For
example, all students on an assessment file should already have a matching student
record. As noted earlier, a process to create a default student identifier is needed in the
ODS to ensure no assessment records are dropped. The DW ETL business rule will be
to add the record unless the student ID is invalid.

Data Access Requirements
Reporting
The Subject Areas and Information Sets in the warehouse will be organized into multiple
report areas for Phase I. Data at the Campus level and above in the location hierarchy is
available to all users. The general public will not have to obtain a user ID and password
to access aggregate level by location. However, these reports may only be a subset of
all the available reports and will be controlled via portal. Please see the reporting
requirements document for additional detail on report requirements and specific
information on the business rules necessary to create the reports.
Aggregate versus Detail reports

1. Aggregate reports will be summary reports that may allow drill down on one or more
dimensions. The possible dimensions are listed in the next section but specific report
requirements are listed in the report requirements document.
2. There will be aggregate reports at the student level. Only security groups with the ability
to access student level detail will be permitted to view student level information.
3. There will be aggregate reports at the teacher level. Only security groups with the ability
to access teacher information will be permitted to view teacher information. Please note
that teacher aggregates will be for all courses a teacher is responsible for even if they
cross campuses or areas. Course will not be carried in the data warehouse.
4. Detail reports will be available at the individual student level. A detailed student level
report is needed to provide information on a particular test for a student. Defining a
common detail report by assessment area across all grades will avoid creating a custom
report for each grade. In some cases, reports across test area will have the same
formats (for example, TAKS and TEKS). Some areas such as PSAT and SAT may not
have student detail reports since students are notified directly for their PSAT and SAT
results. Also, a student summary report of all assessment areas might also be needed.
Common Reporting Requirements
The following dimensions were identified for common reporting. Please note that all
dimensions will not be required in every report and some reports may require additional
dimensions. However, the general rule is that all of the below dimensions will be
permitted in every Discoverer report but some dimensions will be static and potentially
“hidden” from end users. That is, the dimensions would be available for analysis with no
changes to the report but might not be displayed since general end users would normally
use the default.
Type of report – State report using state supplied student demographic data or Local
report using RISD student information. At this time there are no requirements to
create a state and local version of the same report.
AEIS status (flag for accountability subset)
RISD Area – Part of organization hierarchy
RISD Campus Type – High School, JHS, Elementary
Campus – Part of organization hierarchy under area

Test Area – Subject area for an assessment, example Math (Assumption, teacher
can view multiple subject areas)
Teacher – Teachers are only allowed to view students who are currently in their
classes and teachers are not permitted to view data on former students.
Grade Level – Grade level of the assessment test
Economic Status
Limited English Proficient (LEP) status
Special Education Status
Ethnicity
Gender
Course number and course period will be needed to identify current teacher-student

relationships and to identify students taking specific RISD courses. Course and course
number will be used for student identification but course and course number will not be
carried in the data warehouse.
RISD currently has a different Tool or “system” to create reports in each test area. When
cross assessment reports are required, the assessment team physically combines data
into a single file for reporting. This will not be necessary in the integrated environment.
Elementary school principals can select report details by teacher by student. Secondary
campus Tools can currently select report detail on students by course, teacher, and
period but enrollment data (course and period) is not in scope for Phase 1.
Constraints and Assumptions
1. RISD is responsible for the overall portal design with the assistance of Campus EAI.
2. Oracle Consulting will assist with the high level portal design and develop the
interface requirements between portal and the Discoverer reports.
3. Oracle may be responsible for the content of some Discoverer reports that are used
in the portal dashboard (depending on what reports are selected). It is likely that
RISD will include reports not generated from the data warehouse to show more
volatile information such as school attendance. Since the Phase 1 release of the
data warehouse focuses on student assessments, this information may not be
available in the Data Warehouse.

Portal Requirements
Portal Security Requirements
The Oracle team will implement database level software security based on the following
user roles.
1. Public – Achievement Aggregate Data (no individual students identified). No sign-in

is necessary but the public may be limited to a selected subset of reports that will
appear on the initial login page. Report menu limitations will be controlled by portal.
Data limitations will be controlled through Virtual Private Databases (VPD) at the
database level.
2. School Board – Achievement Aggregate Data (no individual students identified). It is
likely that the school board will have access to all aggregate data but any report

menu limitations will be controlled by portal. Data limitations will be controlled
through Virtual Private Databases (VPD) at the database level.
3. District Level Assessment Team personnel – Access to all data in the Data
Warehouse with no restrictions and Discoverer Plus access. This group is the only
group that will have access to all student data as well as “preliminary” data.
Occasionally, data will be loaded into the DW before all corrections are applied to
obtain a preliminary view of the information. If an assessment file is loaded into the
DW with a preliminary status, only the district assessment team will have access to
the data.
4. Central Staff (Includes Superintendent, Central Administrators, Researchers) –
Superintendent, Central Administrators, and Researchers can see all aggregate and
all detail student data (current and former students) but only access to data that has
been marked as “final.” Some central staff may be limited by campus type.
5. Area Staff (Includes Area Superintendent & Area Administrators) – Area
Superintendent and Administrators can only see the current students of the area.
That is, this group will not be able to access former students of the area.
Assessment data must be marked as “final.” Some central staff may be limited by
campus type.
6. Campus Staff (Includes Principals & Campus Administrators) – Principal & Campus
Administrator can only see the current students of the campus (school). That is, this
group will not be able to access former students of the campus. Assessment data
must be marked as “final.”
7. Teachers – Teacher can only see his or her current students. That is, this group will
not be able to access former students. Assessment data must be marked as “final”
but there are no restrictions by test area. For example, an English teacher can see
assessment information in all test areas and not just English.
8. Students (Includes Parents & Students) – Student can only see his or her
information, Parents can only see his or her child. The business rules for allowing
parent access can be somewhat tricky due to custodial rights, divorce, and so on,
and will not be included in Phase 1. Assessment data must be marked as “final.”
Additionally, roles will be created for Application Developers and Discoverer

Administrators. RISD will provide interface files with the Employee to location
relationships, security group information, and the employee to student relationship for
teachers (course enrollment data). RISD will add new users to the OID directory for the
portal login based on the security relationships in the Data Warehouse.
An Oracle Form will be created to allow a RISD administrator to add a user to an existing
security group (listed above). For example, for small user groups such as central staff

with ad hoc capabilities and the board, it may be easier to add and delete users online
rather than develop an interface. The creation of new user groups is out of scope for
this project.
Functional Update and Data Access Process
RISD Functional DW Update Processing
Conversion Files
Assessments R10 RIMS PEIMS

Conversion Process
Production Inputs
Schedule Unmatched
Assessments ODS Corrections
Updates Student Detail
District District
Assessment Automatic
Periodic Updates Assessment Team
Team Monthly
& Summarizations
Snapshots
SIS
Data Discoverer Plus

Warehouse DW Access
Assessment Dashboard
Power User
Assessment Portal Links
General Area (Logo, messages, etc.
Home Page
Public or District
Employee

Portal Page Functionality
This section defines the functionality needed to support the RISD Portal Requirements
for Data Access. The design and the placement of data on the portal pages is the
responsibility of the RISD Internet project manager. The DW development team will be
responsible for supplying content for some portal pages and for creating the VPD users
groups to provide data warehouse data security.
Please note that the portal menus will control the report links for specific user groups to
determine the reports users are permitted to run. Data security can only restrict users
access at a data level and not at a report level.
Login Page
The RIDS Internet project group will create a URL similar to the one below to access the
initial login page:

dwaccess.risd.org
The login page will show RISD general information in addition to having a login portlet.
For security reasons, users may not be permitted to self-register. RISD will provide an
interface file to the DW group to assign users to security groups. Each user will be
assigned a password that is input into the Oracle Internet Directory (OID) by RISD
Internet personnel. The OID login uses the login user ID when accessing the DW to
internally set security.
Dashboard Page
After Validation of the Login Page, the user will go to the Dashboard Page. The generic
dashboard page will have up to 4 portlets that will dynamically show current information.
One of the four portlets will show the Assessment data that is available in descending
order with the most current assessment at the top of the list. That is, the most recently
processed file will appear at the top of the list since that is the file that will most likely be
of interest to users. In all, 12 assessment areas will be available. The information simply
shows the assessment area (TAKS, TEKS, K-2 Math, and so on) with the assessment
administration date, and the date of the last Data Warehouse update. The information for
the portlet will come from the Assessment Log file. Each time a new assessment file is
processed, a log file record is created that notes the assessment, assessment
administration date, the process date, and whether the update is preliminary of final. The
ODS will create the initial log record in order to trigger the DW update. The DW ETL
process will update the record to indicate the extract was run with the completion code.
Only final information with successful update codes will be displayed for general users.
The user can get to the assessment specific report menu page by clicking on the
assessment file listing in the dashboard portlet. Only the reports for the selected
assessment will appear on the Report Menu Page. AYP reports will be included with
TAKS.

Report Menu Page

The Report Menu Page will show all reports associated with the selected assessment
area. On the report menu page, the user will be required to select several parameters
that will be used in the selected report. When the user gets to the report menu page,
they will have already selected the assessment report type that they require. In order to
limit the amount of customization in the initial portal release, the user will make the
following high-level selections before running a report:
Assessment administration – This selection provides the Year and the administration with
the year if an assessment area has multiple administrations. The default for this value
will be the current assessment year and administration, the cumulative or summary
report for assessments having multiple administrations, or the single or “final”
administration for assessment only having one administration.

Assessment Area – Most assessment reports are for a specific test area (subject) but
some assessment reports allow for a summary across test areas. The test area will
default to summary if such as selection is permitted otherwise it will default to the first
assessment area in the database table since we cannot predict the test area a user
might want to review.
There are state reports that use state supplied student demographics and local reports
that use RISD student information. Most reports either use state supplied information or
local information but there may be some reports in the future that will allow the end user
to chose the state or local option.
There are many additional parameters that are allowed depending on the specific report
(see section on common reporting requirements). Rather than control the report
selections within portal, portal will pass control to the Discoverer reports that will allow
additional functionality. The functionality within each report is described in the report
requirement specifications. However, the default parameter will be based on the security
group for the location default.
Discoverer General Flow

Although report drill down and links will be report specific (see Report Requirements
specifications document), we would like to have common processes across reports to
ensure consistency and reduce maintenance. The diagram below shows the general
process. Please note that not all reports will have all links.

Portal Lists
Reports Available
for an Assessment
Select Report
And Parameters
Discoverer Control
Discoverer
Drill to Lower Drill down by
Assessment
Levels selected Hierarchy
Aggregate Report

Student
Link Link to Student
Aggregate Report
Student Aggregate
Link to Student
Report by
Aggregate Report
Assessment
Link to a specific
Student Assessment Summary
Student Link to a Student Detail on

Assessment specific selected
Results Summary Student Assessment
for Selected Year Assessment Report
Database Security Data Model
Virtual Private Databases (VPD) will be used to maintain security at the database level.
Every user will be assigned to a security group that will limit database access based on
the business needs of users assigned to the security group. RISD will assign users to a
security group and create a process to assign a password to each new user. The user
will be required to update the password with the initial sign on and update passwords on
a periodic basis as per RISD internal requirements. The diagram below shows the
security data model that is documented in Oracle Designer and part of the logical and
physical database design.

D ACCESS LEVEL TYPE PUBLIC TYPE CENTRAL SUPERINTENDENT TYPE AREA SUPERINTENDENT TYPE PRINCIPAL
# ID
* CODE
* DESCR TYPE SCHOOL BOARD TYPE CENTRAL ADMINISTRATORS TYPE AREA ADMINISTRATORS TYPE CAMPUS ADMINS
TYPE RESEARCHER TYPE GUIDANCE
TYPE DISTRICT ASSESSMENT TEAM TYPE TEACHER
granted to require
D TIME
SCHOOL YEAR SCHOOL SEMESTER
* YR ID
* ID
* YR SCHOOL YEAR
* CODE
...
...
for access duration require
D DISTRICT PEOPLE
D STUDENT # ID
accessible during
o EMPLOYEE ID
given during # ID
* RISD ID o LAST NAME
* PEIMS ID F STUDENT ACCESS o FIRST NAME
F STUDENT SCHEDULE o FIRST NAME on o MIDDLE NAME
o MIDDLE NAME
taken by * LAST NAME for
o ADDRESS
takes o CITY
o ZIPCODE
o BIRTH COUNTRY
o COUNT IN CLASS OF FLAG associated with
o DOB
taken by taughtgiven
by at o GRADE FIRST ENROLL
o GRADE MOST RECENT ENROLL

o US 1ST SCHOOL DATE viewed by next yearaccessible
location a by
given to o DISTRICT 1ST SCHOOL DATE
...
D CLASS granted to
# ID r
next year location focurrent year access to
* CODE D TEACHER
* ID
* NAME teaches * EMPLOYEE NUMBER
view D LOCATION
taught by o FIRST NAME # ID
o MIDDLE NAME
teach have
o LAST NAME D DISTRICT
occurs in for o HIRE DATE o DIST ID
o RISD YEARS o DISTRICT NAME
occurs during o TEACHING YEARS o DISTRICT DESCR
on
D AREA
D CLASS PERIOD D SUBJECT
o AREA ID
# ID D COURSE o NAME
* CODE # ID given for # ID
o DESCR
* CODE * CODE
o DESCR
* PERIOD NUM * DESCR taught in * NAME
D CAMPUS
o LEVEL o DESCR
o DEPARTMENT * CAMPUS ID
o AP IND o PEIMS CAMPUS N
* CAMPUS NUMBER
...
location for
Portal Security Interfaces with the Data Warehouse
The OID directory must interface with the database in order to associate Portal single
sign-in user IDs to the Oracle Database security groups. Oracle’s Virtual Private
Databases (VPD) feature ensures users within a security group only have access to data
as defined in the previous section. The diagram below shows the relationships between
the security portal and the Data Warehouse.

Process to Assign/
change User
Passwords
Process to assign
Default Password
to new users
OID
User, person Identifier, Employee

ODS RISD HR
And Password Feed

Data User, Person identifier,
Warehouse and Security Group
On Line Form To
add/Remove
Users from
Security Groups
Portal Implementation Approach
1. RISD creates the initial Login Screen using portal pages available in the Campus EAI
repository. This initial page is often referred to as the blackboard. Portal needs to
communicate the specific user to the database to ensure proper data security. The
portal software validates the user ID and password. We will set up a process where
RISD would set up a default user ID and password for all employees and the board
with a randomly created password set to expire immediately. When the user logs on
for the first time, the system would prompt them to change their password after
authenticating the user. The potential problem with this approach would be the
security associated with notifying employees of their new user ID and password. A
possible alternative would be to have employees and the board self register based
on knowing key employee information. Employees must be assigned by Oracle to
the proper security group via the HR employee interface file and students or parents
(in the future) will be in the student security group. Public users will not need to login
but will have access to the initial public page that would include the login portlet.
2. After login, the user would go to the Dashboard page where several portlets would
supply dynamic information. For example, one of the portlets would show the
assessment files that were available with the most recent updates first. Clicking on
one of the assessment areas would link the user to the page that lists all related
reports for that assessment area. Reports that compare results across multiple

assessment areas would appear in multiple assessment menus. For example, the
report that compares TEKS and TAKS results would appear in both the TEKS and
the TAKS menus. However, after selecting the time periods for report comparison,
the portal would only allow the report to run if BOTH data files were available for the
time period.
3. For login security groups, the initial Report Page shows all reports available for the
security group (the board might be restricted to a subset of aggregate reports). That
is, if the board only has access to a subset of reports, they would only see reports on
their menu that they were permitted to run. Only the district assessment group would
have access to “preliminary” assessment data for report creation. After the “final”
assessment numbers are loaded, all users will have access to the data.
4. The user must select the assessment test area. “SUM” (currently defined as ALL)
might be allowed if a report summary was available across subject areas. In some
cases like SAT reports, only a combined score report is available so selecting the
test area would not be necessary. However, if subject area reports were available in
the future, this prompt could be added. For consistency, this prompt would show for
all report options but in the case of SAT reports, only one option would show.
5. The default time is the latest test year that has “final” results but the user can change

the time (The ETL process will keep a log that portal could query to get the current
year by assessment area for “final” reports).
6. The next selection is the test administration. Most reports show cumulative results or
have a single administration (cumulative for multiple administrations or a single
administration is usually viewed). The selection would allow cumulative or a selected
administration. Longitudinal reports (year over year) or reports showing multiple
administrations separately would be special reports and would not have options
except time. For example, many longitudinal reports show 3 years of trends and the
user would select the beginning or ending year.
7. The security group determines the default Location. District level administrators, the
district superintendent, and the board default to District summary. Area
Administrators and area superintendent default to their area; principals and teachers
default to their campus. Once in Discoverer, everyone can change the default to a
higher or lower level but having the defaults preselected based on user group will
satisfy the majority of cases.
8. Grade is required in some reports (Sum [currently all] would mean a single
cumulative report would be created across all grades).
9. If the report was specific to Campus type like some of the TAKS reports, Discoverer
could prompt for the campus type to avoid an additional portal page. In other reports
like K-2 math, the campus type is clearly elementary.
10. Control would transfer to Discoverer and the report would run and show the
aggregate results based on selections.
11. The user would have the ability in Discoverer to change dimensions and rerun the
report without being reprompted in portal. This is similar to the functionality
principals and teachers have in the current spreadsheets but all reports would be
available through the web.
12. Once in Discoverer, the user would have the ability “drill” by location (district – area –
campus) or to link to teacher level aggregates (dependent on the report
requirements). If student level detail were needed, there would be a link to a student
level report. From a user standpoint the drill and link is the same, but drill down
reports simply use a hierarchy and no new reports are needed. Linked reports
require a new report since the linked report shows different information or does fit
nicely into the location hierarchy. The security group rules would limit the students
(and or teachers from a principal view) a user could view (in some cases, no student
view is allowed). For example, a teacher could only view his or her current students.

RA.100 RISD LOGICAL DATA
MODEL
M4_RISD_LDM_ Data Model_V3.0.doc

Data Warehouse Initiative
Author: Oracle Consulting

Creation Date:
Last Updated:
Version: 3.0
Approvals:
RISD Data Model
Document Control
Change Record
2

Reviewers
Name Position
Distribution
Copy No. Name Function
1 Library Master
2
3
4
i
RISD Confidential - For internal use only
RISD Data Model
Contents
Document Control ....................................................................................................................i

Change Record .................................................................................................................i
Reviewers ..........................................................................................................................i
Distribution .........................................................................................................................i
1.0 Introduction........................................................................................................................ 3
1.1 Background ................................................................................................................ 3

1.2 Purpose ...................................................................................................................... 3
1.3 Related Documents .................................................................................................. 4
2.0 The Data Model ................................................................................................................ 5
2.1 Data Model Analysis Conclusions .......................................................................... 5
2.2 Data Model Concepts ............................................................................................... 5
2.3 Entity Definitions........................................................................................................ 6
2.4 Entity Attribute List .................................................................................................... 6
2.5 Domain Definitions .................................................................................................... 7
3.0 Dimensional Data Model ......................................................................................... 8
3.1 - Dimensional Schema ............................................................................................. 8
3.2 - Fact Tables .............................................................................................................. 8
3.3 - Dimension Tables ................................................................................................... 8
3.4 Time Dimension......................................................................................................... 9
3.5 Hierarchical Dimensions .......................................................................................... 9
4.0 Logical Data Model (LDM)..................................................................................... 10
4.1 Student Model.......................................................................................................... 11
4.2 TAKS Assessment .................................................................................................. 12
4.3 TEKS Assessment .................................................................................................. 13
4.4 SDAA Assessment.................................................................................................. 14
4.5 RPTE Assessment ...................................................................................................... 15
4.6 AP Assessment ........................................................................................................... 16
4.7 ACT Assessment ........................................................................................................ 17
4.8 LDAA Assessment ..................................................................................................... 18
4.9 SAT Assessment......................................................................................................... 19
4.10 PSAT Assessment .................................................................................................... 20
4.11 K-2 Math Assessment............................................................................................... 21
4.12 ERWA/TPRI Assessment .................................................................................... 22
4.13 Tejas Lee Assessment......................................................................................... 23
5.0 Summary Tables..................................................................................................... 24
Appendix A – Additional Data Modeling Concepts .......................................................... 25

A.1 - Data Modeling Activities ...................................................................................... 26
A.2 - Building the Repository Environment ................................................................ 26
A.3 Collecting Metadata Assets................................................................................... 27
A.4 Metadata Analysis (Quality of Source Data)....................................................... 27
A.5 Capture Business Rules ........................................................................................ 27
ii
RISD Data Model
1.0 Introduction
1.1 Background
The RISD Data Warehouse environment will provide decision makers throughout the District with
information to help improve student achievement. Users will access the system via Windows
based Internet-capable computers to accommodate the needs of both computer novices and
experts. Data that is currently processed independently in multiple “applications” will be
integrated into a single environment to facilitate data reporting and analysis across test areas.
Discoverer report data will be available online and can be downloaded into local applications
where appropriate (for example, spreadsheets and PC databases) to perform additional analysis
or for integration with local data. Phase I will primarily focus on student assessment data.
User groups will be restricted to accessing information associated with their responsibilities,
needs, and skills. The majority of end users will run parameter driven reports to obtain multiple
views of the assessment data. Dashboard reports via Oracle Portal will provide summarized

tabular and/or graphical information to various user groups. The system is designed so RISD can
develop relevant reports as new data becomes available. Some power users will go directly to
Discoverer Plus to run reports and create ad hoc reports on an “as needed” basis while most
users will use Discoverer viewer to run the parameter driven reports and/or view existing
standard reports.
1.2 Purpose
The Data Model provides a definition and structure of all the data that RISD personnel will need
to satisfy their student achievement business requirements. The generic Logical Data Model
(LDM) created for use at K-12 applications was used as the starting point in creating the RISD
data model and the generic model is available to RISD in Oracle Designer and will be used to
add subject areas in future releases.
The RISD specific Logical Data Model representing the Phase 1 data the RISD assessment team
uses or generates is documented in a separate Designer Repository and the ERD can be found
in section 5.0. The model reflects information from the generic K-12 data model customized with
information provided by RISD. The Oracle team reviewed the business relationships with the
RISD Assessment team to ensure completeness. The RISD model contains all the information
that the RISD data warehouse is anticipated to need in Phase 1 to support assessment
requirements. This deliverable includes Entity Relationship Diagrams and standard Entity and
Attribute reports from Oracle Designer.
The Oracle Designer repository will be used in conjunction with Oracle Warehouse Builder
(OWB) in the implementation of Phase 1. The phased implementation approach adds subject
areas to the student assessment data warehouse in increments order to ensure the highest
priority business requirements are addressed in early releases.
3
RISD Data Model
1.3 Related Documents

The Definition and Analysis Phase of the RISD Data Warehouse project provides an opportunity
to clearly define the infrastructure needed to support the RISD Data Warehouse initiative. The
creation of the data model is a key deliverable in the RISD Phase 1 implementation process. It
documents the data requirements formulated in the reporting requirements document and
clarifies the data relationships that drive the creation of the architecture document. The following
related documents are associated with this initiative.
• Milestone 1, Project Management Plan – Baseline plan in Microsoft projects with

accompanying project management plan (PMP) document
• Milestone 2, RD.049 Report Requirements Document – Clearly defines the reporting
requirements in the 12 priority Assessment areas implemented for Phase 1
• Milestone 3, RD.049 Portal Security Requirements – The Data Warehouse Portal Security
Design Document describes the functionality of the Portal pages required to support the

highest priority Data Warehouse reports and Dashboards. The look and feel, navigation
colors, and graphics are not part of these requirements and only the Data Warehouse page
content, report links, and how roles determine geographic defaults are included.
• Milestone 5, MD.040 Physical Data Model – The Physical Data Model Design contains all the
tables, indexes, partitioning, and parameters needed to define the data warehouse objects.
Only the standard materialized views and indexes will be included in this document since the
physical design is an extension of the Logical Design.
• Milestone 6, TA.010 Technical Architecture Document – The Technical Architecture
Document describes all Development, Test and Production components, including the
hardware, platform, software versions, set up configurations and data base schemas and
development repositories. The capacity plan defines the system capacity requirements such
as performance, memory, storage, backup and recovery, network, upgrade potential, and
extensibility, needed to support RISD requirements.
4
RISD Data Model
2.0 The Data Model

The RISD Phase 1 data model is a structured representation of the information that supports
RISD assessment reporting requirements. The functional or business data model typically avoids
technological aspects and only depicts the business data. By identifying information by the
business names and providing definitions and descriptions, it provides a common, consistent
point of view that should be shared in an organization. The base of the data model is the Entity
Relationship Diagram (ERD) as it identifies the major pieces of information and their
relationships. Supporting the ERD are definitions that are a combination of narrative descriptions,
acceptable data types (numeric, text, and so on), and allowable values (called domains).
2.1 Data Model Analysis Conclusions

The foundation of the RISD data model is based on the requirements gathered during the
definition phase of the RISD Data Warehouse initiative. The RISD Logical Data Model (LDM)
uses a star schema data modeling approach based on Oracle’s previous K-12 experience. The

LDM will be used to create the physical Data Warehouse model. There will be fact tables
associated with each of the major assessment areas and summary fact tables (determined during
the physical design that will probably be materialized views) to facilitate reporting. Each fact table
will have dimensions defined in the LDM. When the physical model is created, some dimensions
may be collapsed or eliminated based on the number of attributes and potential usage. The RISD
star schema LDM satisfies the data requirements gathered, reviewed, distilled, and prioritized
during the requirements gathering process.
2.2 Data Model Concepts

If you are unfamiliar with Entity Relationship diagrams or are not familiar with the diagramming
conventions employed by Oracle, then this section provides a brief guide to acquaint you with the
concepts and conventions.
The three main concepts used in data modeling are the following:
Entity – Something of significance to the business about which information is held. It can be an
object, person, place, thing, activity, or concept that is important to the business. Every entity
should have a unique means of identification (unique business name or in physical terms, a
unique key) and one or more other characteristics (relationships or attributes) that are captured to
describe it.
Relationship – A named, significant association between two entities
Attribute – A characteristic or trait common to all occurrences of the entity
A Student is an example of an entity. In the diagram, entities are represented as boxes with
rounded corners. The size, color, and shape of the boxes are of no particular significance but
they are often used to assist with clarifying the diagram.
A line that joins two entity boxes together illustrates a relationship between the entities. There are
two relationship aspects that are depicted by the line: mandatory/optional associations and
cardinality.
Mandatory/optional associations: A solid line from an entity box means that an occurrence of that
entity must be associated with an occurrence of the entity at the other end of the line. A broken
line from an entity box means that an occurrence of the entity may be associated with an
occurrence of the entity at the other end of the line. Each end of the line is given a title that
describes the nature of the relationship for the entity at that end of the line.
5
RISD Data Model
Cardinality: A further convention is the use of a crow’s foot at the end of the line. This indicates
that the association is with one or more occurrences of the type of entity to which the crow’s foot
is attached. When the crow’s foot is absent it means that only one occurrence of the entity at that
end of the relationship is involved in each occurrence of the relationship.
For example, the following extract shows the relationship between a Student and the student
access facts.
D STUDENT
# ID
* RISD ID
* PEIMS ID F STUDENT ACCESS
o FIRST NAME
o MIDDLE NAME on
* LAST NAME
o ADDRESS for
o CITY
o ZIPCODE

o BIRTH COUNTRY
o COUNT IN CLASS OF FLAG
...
Following the relationship from left to right it says that:

Entity Mandatory /Optional Relationship Cardinality Related
Name Entity
Each Student May have Access One or Student
more access
facts
Sometimes occurrences of an entity will have relationships with other occurrences of the same
entity type. An entity may be divided into two or more subtypes. Two or more boxes within an
outer box show this. Subtyping is important when the characteristics (attributes or relationships)
between them are different. A subtype inherits the characteristics of the supertype. For example,
time has a subtype of school year and calendar date.
Attributes are qualitative, quantitative, narrative or descriptive (includes audio, video, image, and
so on) characteristics of an entity. Attributes should be consistent in meaning and have only a
single definition. (In physical design, considerations may be made to combine mutually exclusive
attributes into a single column, but this is not a recommended practice). Attributes can have a set
of predefined values (called domains) or other set of restrictions (range edits, cross-field edits)
that are constraints of the attribute.
2.3 Entity Definitions

A list of entities with their descriptions is stored in Designer. A separate spreadsheet with this
information is available in the system library.
2.4 Entity Attribute List

Data attributes are stored in Oracle Designer. A separate spreadsheet with this information is
available in the system library. This information is often referred to as a data dictionary.
6
RISD Data Model
2.5 Domain Definitions

A domain is a set of validation rules, format constraints and other properties that applies to a
group of attributes, columns, program-data constructs, parameters, or data structures. For
example, before entering attribute details, it is useful to define any domains that have been
identified, such as ethnicity. When an attribute has been defined, a domain can be specified that
will apply to it. Many domains only have two values like 0 and 1 or Yes and No. The following
table gives examples of domain definitions.
Domain Allowable Values
Ethnicity White, American Indian, Hispanic, African

American, Asian, Unknown
Gender Male, Female
7
RISD Data Model
3.0 Dimensional Data Model

There are fundamentally two types of data models: Normalized and Dimensional (Star schema).
The Dimensional model, commonly referred to as a star schema, is commonly used in data
warehouse designs. Oracle 10g Database Management Systems (DBMS) supports the star
schema design and the extended star schema design known as a snowflake. This section
defines some common dimensional modeling terms.
3.1 - Dimensional Schema
The concept of a Dimensional schema as represented by its popular rendition called the Star
schema or a variation, the Snowflake schema, is derived from multidimensional database design.
In this model, the Star has a central fact table radiating to several dimensional tables. Each star is
designed as a central, usually large table of facts typically recording a particular type of event.
Each event or fact occurs within the context of several dimensions. For example, when
considering transaction facts, you might note that each one of these facts occurred on a

particular day, for a particular location, and so on. Each of these different ways of identifying
transactions is called a dimension. In relational database terms, the fact table has a foreign-key
relationship to each of its dimension tables. That is, each row inserted into the fact table will have
values in the foreign key columns pointing to each of its relevant dimensions. The diagram in
section 4 shows a star schema by assessment area where a transaction fact table has many
dimensions. If some of the dimensions are further linked to look-up tables, the Star schema is
said to be ‘Snowflaked’.
3.2 - Fact Tables
Fact tables commonly hold the largest collection of data in the data warehouse. To facilitate an
efficient way of handling these large volumes of data, it is usually recommended that the fact
tables be partitioned. Partitioning will be determined in the Physical design.
As mentioned earlier, each row in a fact table has a column corresponding to the primary key of
each of the dimension tables in the star. In addition to these foreign key columns, the fact table
contains one or more columns that describe the volume, frequency, assessment score, or other
numeric measure that can be summed, averaged, or aggregated in a query. Except for the
foreign keys, virtually all attributes in a fact table turn out to be measurements that can be
meaningfully summed. Textual attributes are generally of little value in fact tables because they
cannot be arithmetically combined when a query seeks to retrieve many rows. In reality, not all
numeric data types are useful in the fact table.
In many cases, Fact Summary tables are created to help improve performance. The contents of
these fact summary tables are determined by the access (reporting) requirements.
3.3 - Dimension Tables
Dimension tables tend to be relatively small when compared to the fact tables. Dimensions may
hold from a dozen to a few thousand rows of data. The objective of the star schema is to be able
to efficiently select a subset of the total fact table by restricting the number of fact rows through
limiting conditions specified about the dimensions.
Dimension tables hold all the descriptive attributes in the star schema rather than the fact table.
For example, the assessment name that did not belong in the fact table will comfortably find a
home in the dimension table. The number of distinct values in a dimension table is critical to its
usefulness. A dimension with only a few values is not particularly selective. On the other hand, if
values in the dimension table approach the number of rows in the fact table, the dimension loses
its value. In the ideal situation, though one dimension may not be particularly selective, a
8
RISD Data Model
combination of criteria involving multiple dimensions can identify a useful subset of the fact table
for analysis. The dimension tables are not generally normalized. Disk space savings gained by
normalizing the dimension tables are trivial compared to the total size for the star schema.
Another crucial factor is determining the grain statement of the fact table. For example, the grain
may be student detail at the assessment test area.
There are dimensions where the information about them changes slowly over time. These
dimensions are called slowly changing dimensions. Since RISD has expressed a need to track
changes over time the Data Warehouse Team will create an additional record at the time of the
change with the new attribute values so that we can segment the data historically between the
old description and the new description.
3.4 Time Dimension
In a data warehouse environment, virtually all data in the fact tables is dimensioned by time.
Therefore, the granularity of the time dimension has significant implications on the way end users
slice and dice data in the fact tables. The time, therefore, merits a special, short discussion. The
time dimension needs to be defined in a way that takes into consideration end users’

requirements and how they intend to interrogate/query data in the fact tables.
3.5 Hierarchical Dimensions
There are some dimension tables that lend themselves to hierarchical representations and
definitions. These dimensions have levels where the top level has several layers below it. For
example, District, Area, Campus Type, and Campus would describe the location hierarchy. The
domain for Campus type would be High School, Junior High, and Elementary. Depending on the
kind of analysis being done, the data in the fact table can be rolled up into the higher levels to see
data that is summarized, or collapsed down to see data that is more detailed. It is natural and
quite common for a dimension to support multiple, independent hierarchies.
9
RISD Data Model
4.0 Logical Data Model (LDM)
The following sections show the high level Logical Data Model (LDM) relationships. Please refer
to the entity attribute listing for full list of attributes.
10
RISD Data Model
4.1 Student Model
The following diagram shows the student model.
D ACCESS LEVEL
TYPE PUBLIC TYPE CENTRAL SUPERINTEN TYPE AREA SUPERINTEND TYPE PRINCIPA
# ID
* CODE
* DESCR TYPE SCHOOL BOA TYPE CENTRAL ADMINISTRAT TYPE AREA ADMINISTRATO TYPE CAMPUS ADMIN
TYPE RESEARCH TYPE GUIDANCE
TYPE DISTRICT ASSESSMENT T TYPE TEACHE
granted t require
D TIME
SCHOOL YEAR
* YR ID
SCHOOL SEMESTE
* ID
* YR SCHOOL YEAR
* CODE
...
...
for access durati require

D DISTRICT PEOPLE
D STUDENT # ID
accessible durin
o EMPLOYEE ID
given durin # ID
* RISD ID o LAST NAME
* PEIMS ID F STUDENT ACCESS o FIRST NAME
F STUDENT SCHEDU o FIRST NAME on o MIDDLE NAME
o MIDDLE NAME
taken by * LAST NAME for
o ADDRESS
takes o CITY
o ZIPCODE
o BIRTH COUNTRY
o COUNT IN CLASS OF FLAG associated wit
o DOB
taken by taught
given
by at o GRADE FIRST ENROLL
o GRADE MOST RECENT ENR
o US 1ST SCHOOL DATE viewed by next year
accessible
locatio
given to o DISTRICT 1ST SCHOOL DAT
...
D CLASS granted t
# ID current year acces
next year location
* CODE D TEACHER
* ID
* NAME teaches * EMPLOYEE NUMBER
view D LOCATION
taught by o FIRST NAME # ID
o MIDDLE NAME
teach have
o LAST NAME D DISTRICT
occurs in for o HIRE DATE o DIST ID
o RISD YEARS o DISTRICT NAME
occurs durin o TEACHING YEARS o DISTRICT DESCR
on
D AREA
D CLASS PERIO D SUBJECT
o AREA ID
# ID D COURSE o NAME
* CODE # ID given for # ID
o DESCR
* CODE
o DESCR * CODE
* DESCR taught in * NAME
* PERIOD NUM
o DESCR D CAMPUS
o LEVEL * CAMPUS ID
o AP IND o DEPARTMENT
o PEIMS CAMPU
* CAMPUS NUM
...
location fo
11
RISD Data Model
4.2 TAKS Assessment
The following diagram shows the TAKS Assessment model.
D TIME
SCHOOL YEAR CALENDAR DATE RISD AYP TARGET VALUES
* YR ID * CAL ID o PATICIPATION LEVEL
ADMINISTRATION PERIOD * YR SCHOOL YEAR * CAL DATE
D ASSESSMENT * ADMIN PD ID * YR SCHOOL YEAR DESCR
# ID * CAL MONTH
* ADMIN PD * YR START DATE
* CODE ...
* ADMIN PD DESCR * YR END DATE
* DESCR * ADMIN MONTH * YR START YEAR
o ADMINISTRATION * ADMIN YEAR for
* YR END YEAR for
* PERIOD START DATE
of D TAKS EXIT LEVEL STANDARD * PERIOD END DATE SCHOOL SEMESTER
* ID
(DD?)
# ID taken on for ...
* CODE
for * DESCR for
D TEST AREA standard for

# ID D STUDENT TAKS
* ID
* CODE
o ESC_REGION_NUMBER
o NAME
o DISTRICT_CAMPUS_NUM
o PASSING SCALE SCORE on
o LAST_NAME FH STUDENT HISTORY D LOCATION
o PASSING RAW SCORE # ID
... # ID
o COMMENDED SCALE SCORE o DISTRICT START DATE
o COMMENDED RAW SCORE on taken during taken on
taken during o DISTRICT DEPARTURE DATE
o WRITTEN COMPOSITION PASS profile for o CAMPUS START DATE D DISTRICT
o WRITTEN COMPOSITION COM o DIST ID
F TAKS STUDENT RESULTS o CAMPUS DEPARTURE DATE
o DISTRICT NAME

# SEQ
o DISTRICT DESCR
* DISTRICT CNT
D GRADE * CAMPUS CNT
D STUDENT D AREA
for in # GROUP ID
profiled by o AREA ID
# ID
* GROUP CODE F TAKS STUDENT TEST AREA * RISD ID o NAME
* GROUP DESCR
D OBJECTIVE scored on RESULTS * PEIMS ID o DESCR
o TESTED CNT
# ID D TEST GRADE o RAW SCORE
o FIRST NAME
* CODE # ID for o MIDDLE NAME D CAMPUS
* DESCR o SCALE SCORE * LAST NAME * CAMPUS ID
* ASSESSMENT
o ITEM CNT for o MET STANDARD IND o ADDRESS o PEIMS CAMPUS NUMBE
* CODE for o NOT MET STANDARD IND level of
o MASTER OBJECTIVE SCORE * DESCR for o CITY * CAMPUS NUMBER
o RAW SCORE o COMMENDED PERFORMANCE IND o ZIPCODE * CAMPUS NAME
on o SORT SEQ on
in o MET TEXAS HIED STANDARD IND o BIRTH COUNTRY o CAMPUS DESCR
o MASTERED ALL OBJECTIVES IND ... o ADDRESS LINE
o SCORE CODE taken at o CITY
D TEST VERSION o SCORE CODE O o STATE
for accountable by for
in # ID o -- o ZIP CODE
* CODE
for o WRITTEN COMPOSITION SCORE 1 o PHONE NUMBER
* NAME o WRITTEN COMPOSITION SCORE 2 student at accountable for ...
OBJECTIVE ITEM in o WRITTEN COMPOSITION SCORE 3
# ID
for o WRITTEN COMPOSITION SCORE 4 for
* CODE o ANALYTIC CATEGORY 1
* DESCR on o ANALYTIC CATEGORY 2 for
o ITEM NUM
D STUDENT GROUP
o ANALYTIC CATEGORY 3 # ID
o CORRECT RESPONSE (KEY) o ANALYTIC CATEGORY 4
o TEKS CODE o ANALYTIC CATEGORY 5
grouped by o CODE
on o DESCR
o ANALYTIC CATEGORY 6
...
groupso for
ACCOUNTABLE FLAG
ETHNICITY GENDER SPECIAL ED

F TAKS STUDENT OBJ RESULT
S ECONOMIC DISADVANTAGED LEP
D ITEM RESPONSE GROUP o OBJECTIVE SCORE
# ID for o MASTERED OBJECTIVE IND
o CODE o NOT MASTERED OBJECTIVE IND ESL GANDT CITIZENSHIP BILINGUAL
o LABEL
o DESCR AT RISK TITLE 1 PART A CAREER TECH
groups for
for F TAKS STUDENT ITEM RESUL MIGRANT STUDENT IN TEXAS MIGRANT
S
* CORRECT RESPONSE IND
* ITEM RESPONSE
level of grouped by at during
FS OBJECTIVE ITEM
for o ITEM NUM
o CORRECT RESPONSE
level of o RESPONSE CNT
during
in
in
12
RISD Data Model
4.3 TEKS Assessment
The following diagram shows the TEKS Assessment model.
D TEKS CLASS
D TIME # ID
SCHOOL YEAR ADMINISTRATION PERIO

CALENDAR DATE * ADMIN PD ID TEKS TEACHER TEKS COURSE TEKS PERIOD
* YR ID * TEACHER NAME * COURSE NUMBER * PERIOD NUMBER
* CAL ID * ADMIN PD
... * COURSE NAME
... ...
for for for

D ASSESSMENT for
# ID
* CODE
...
D TEST VERSION D PERFORMANCE GRO
of # ID for (DD) D LOCATION
* CODE takentaken
on duringtaken during # ID # ID
for * NAME * CODE
* DESCR
on F TEKS STUDENT RESULTS for D DISTRICT
D TEST AREA * SEQ
# ID
* DISTRICT CNT
in o DIST ID
* CODE o DISTRICT NAME
* CAMPUS CNT
o NAME FH STUDENT HISTORY o DISTRICT DESCR
o PASSING SCALE SCORE for in # ID
F TEKS STUDENT TEST AREA o DISTRICT START DATE D AREA
o PASSING RAW SCORE D STUDENT TEKS o AREA ID
o COMMENDED SCALE SCORE on profile for RESULTS o DISTRICT DEPARTURE DATE
o COMMENDED RAW SCORE o TESTED CNT profiled by o CAMPUS START DATE o NAME
o DESCR
profile by o RAW SCORE o CAMPUS DEPARTURE DATE

o WRITTEN COMPOSITION PAS
o WRITTEN COMPOSITION COM o MET STANDARD IND profile for
o NOT MET STANDARD IND taken at for D CAMPUS
o COMMENDED PERFORMANCE IND * CAMPUS ID
for o MASTERED ALL OBJECTIVES IND o PEIMS CAMPUS N
in for o WRITTEN COMPOSITION SCORE D STUDENT * CAMPUS NUMBER
* CAMPUS NAME
D OBJECTIVE taken by # ID
* RISD ID o CAMPUS DESCR
# ID o ADDRESS LINE
takes * PEIMS ID
* CODE
F TEKS STUDENT OBJ RESUL o FIRST NAME o CITY
* DESCR o STATE
o OBJECTIVE SCORE grouped by o MIDDLE NAME
o ITEM CNT on o ZIP CODE
o MASTERED OBJECTIVE IND * LAST NAME
o MASTER OBJECTIVE SCORE o NOT MASTERED OBJECTIVE IND ...
o ADDRESS
o RAW SCORE for o CITY
o ZIPCODE
o BIRTH COUNTRY
o DOB for
for
in o GRADE FIRST ENROLL
F TEKS STUDENT ITEM RESUL o GRADE MOST RECENT ENRO
* CORRECT RESPONSE IND o US 1ST SCHOOL DATE
OBJECTIVE ITEM level for * ITEM RESPONSE ...
# ID on
* CODE
* DESCR D STUDENT GROUP
in # ID
o ITEM NUM for
o CORRECT RESPONSE (KEY) on o CODE
o TEKS CODE D GRADE o DESCR
FS OBJECTIVE ITEM # GROUP ID o ACCOUNTABLE FLAG
for o ITEM NUM * GROUP CODE
o CORRECT RESPONSE on
* GROUP DESCR ETHNICITY GENDER
o RESPONSE CNT group for
for D TEST GRADE ECONOMIC DISADVANTAGED

D ITEM RESPONSE GROUP in
# ID
# ID
level of for
* ASSESSMENT LEP SPECIAL ED
o CODE * CODE
o LABEL * DESCR
o DESCR o SORT SEQ
at grouped by
groups for
13
RISD Data Model
4.4 SDAA Assessment
The following diagram shows the SDAA Assessment model.
FS SDAA D TIME
* TESTED CNT
o MET EXPECTATION CNT CALENDAR DATE ADMINISTRATION PERIOD D SDAA SCORING DD
SCHOOL YEAR * ADMIN PD ID
o NOT MET EXPECTATION CNT * CAL ID * ID
* YR ID
o MET EXPECTATION PCT * CAL DATE * ADMIN PD * CODE
* YR SCHOOL YEAR
o NOT MET EXPECTATION PCT ... ... * DESCR
...
D SDAA ACHIEVEMENT DD
for for
for
for
D ARD DECISION RESOLVED DD level for
D ASSESSMENT taken during taken on taken during level for
# ID D STUDENT SDAA
o ESC_REGION_NUMBER D ARD DECISION GRIDDED DD
* CODE
o COUNTY_DISTRICT_CAMPUS F SDAA STUDENT RESULTS
* DESCR resolved level in
o LAST_NAME * SEQ level for
o ADMINISTRATION
o FIRST_NAME * DISTRICT CNT
o MIDDLE_INITIAL on gridded level in
* CAMPUS CNT
of o STUDENT_ID
F SDAA STUDENT TEST AREA achievement level in
on
... for RESULTS D LOCATION
for
o RAW SCORE at # ID
o SCALED SCORE
D TEST AREA o ACHIEVEMENT LEVEL accountable in for D DISTRICT
# ID o ARD DECISION GRIDDED o DIST ID
* CODE o ARD DECISION RESOLVED accountable for o DISTRICT NAME
o NAME o MET EXPECTATION IND for o DISTRICT DESCR
o PASSING SCALE SCORE o NOT MET EXPECTATION IND
on
o PASSING RAW SCORE o AT EXPECTATION IND D STUDENT D AREA

o COMMENDED SCALE SCORE o ABOVE EXPECTATION IND # ID o AREA ID
o COMMENDED RAW SCORE for
o ON GRADE LEVEL IND * RISD ID o NAME
o WRITTEN COMPOSITION PASSING SCORE o BASELINE * PEIMS ID o DESCR
o WRITTEN COMPOSITION COMMENDED SCO o DOCUMENT NUMBER o FIRST NAME
o SCORE CODE o MIDDLE NAME D CAMPUS
in o SCORE CODE O by * LAST NAME * CAMPUS ID
for o -- o ADDRESS o PEIMS CAMPUS NUMBER
o WRITTEN COMPOSITION SCORE 1 took o CITY * CAMPUS NUMBER
... o ZIPCODE * CAMPUS NAME
D OBJECTIVE o BIRTH COUNTRY o CAMPUS DESCR
# ID ...
o COUNT IN CLASS OF FLA
* CODE
on F SDAA STUDENT OBJ RESULTS o DOB
* DESCR
o OBJECTIVE SCORE o GRADE FIRST ENROLL
o ITEM CNT
o MASTER OBJECTIVE SCORE
for ...
o RAW SCORE grouped by
F SDAA STUDENT ITEM RESULTS

for * CORRECT RESPONSE IND
in * ITEM RESPONSE
level groups for
on
OBJECTIVE ITEM
# ID D STUDENT GROUP
* CODE for enrolled in profiled by
* DESCR FS OBJECTIVE ITEM at # ID
o ITEM NUM o CODE
o ITEM NUM on grouped by o DESCR
o CORRECT RESPONSE
o CORRECT RESPONSE (K o ETHNICITY FLAG GENDER
ACCOUNTABLE SPECIAL ED
o RESPONSE CNT
o TEKS CODE for profile for groups for
ECONOMIC DISADVANTAGED LEP
level of in FH STUDENT HISTORY
# ID
D ITEM RESPONSE GROUP for o DISTRICT START DATE AT RISK GANDT BILINGUAL ESL
# ID o DISTRICT DEPARTURE DATE
o CODE o CAMPUS START DATE MIGRANT STUDENT IN TEXAS MIGRANT
... o CAMPUS DEPARTURE DATE
D GRADE
# GROUP ID CAREER TECH TITLE 1 PART A
* GROUP CODE
for instructional
* GROUP DESCR
level for for
D TEST GRADE D ENROLLED GRADE

# ID # ID
* ASSESSMENT * CODE
* CODE o DESCR
... o SORT SEQ
14
RISD Data Model
4.5 RPTE Assessment
The following diagram shows the SDAA Assessment model.
D GRADE
# GROUP ID for
* GROUP CODE D RPTE
* GROUP DESCR D TIME PROFICIENCY
CALENDAR DATE ADMINISTRATION PERIOD RATING
D TEST GRADE SCHOOL YEAR * CAL ID * ADMIN PD ID * ID
# ID * YR ID * CAL DATE * ADMIN PD * CODE
for * ASSESSMENT ... ... ... * DESCR
* CODE
* DESCR for for for
o SORT SEQ
on on
D ASSESSMENT
# ID taken during taken on taken during level for
* CODE D YRS IN SCHOOL D LOCATION
for # ID # ID
* DESCR
o ADMINISTRATION F RPTE RESULTS * TYPE
# SEQ * CODE D DISTRICT
o DISTRICT CNT band years* oDESCR o DIST ID
for o CAMPUS CNT * LEVEL START
of for
o DISTRICT NAME
for * LEVEL END o DISTRICT DESCR
F RPTE STUDENT TEST AREA RESULTS at
o TESTED CNT
accountable in D AREA
D TEST AREA o RAW SCORE for o AREA ID

# ID on o SCALE SCORE accountable for o NAME
* CODE o SCORE CODE level forD STUDENT o DESCR
o NAME for o SCORE CODE O # ID
o PASSING SCALE SCORE on o --- on * RISD ID D CAMPUS
o PASSING RAW SCORE D TEST VERSION o PRIOR GRADE * PEIMS ID * CAMPUS ID
# ID
o COMMENDED SCALE SCORE
* CODE for for o PRIOR SCALE SCORE o FIRST NAME o PEIMS CAMPUS NUMBER
o COMMENDED RAW SCORE o PRIOR PROFICIENCY RATING o MIDDLE NAME * CAMPUS NUMBER
* NAME o PRIOR SCORE CODE
... * LAST NAME * CAMPUS NAME
o ADDRESS o CAMPUS DESCR
F RPTE STUDENT PROFICIENCY RESULT o CITY o ADDRESS LINE
for in D STUDENT RPTE o PROFICIENCY LEVEL SCORE o ZIPCODE o CITY
# ID on o BIRTH COUNTRY o STATE
o ESC_REGION_NUMBER o COUNT IN CLASS OF FLAG o ZIP CODE
D OBJECTIVE o DOB o PHONE NUMBER
# ID o CAMPUS_ID_OF_ENRO for
o GRADE FIRST ENROLL ...
* CODE on ... F RPTE STUDENT OBJ RESULTS
o GRADE MOST RECENT ENR
* DESCR o OBJECTIVE SCORE
o US 1ST SCHOOL DATE
o ITEM CNT for ...
o MASTER OBJECTIVE SCOR
o RAW SCORE profiled by
F RPTE STUDENT ITEM RESULTS FH STUDENT HISTORY
level for * CORRECT RESPONSE IND profile for # ID for
* ITEM RESPONSE
for o DISTRICT START DATE
in * PROFICIENCY LEVEL
o DISTRICT DEPARTURE DAT
o CAMPUS START DATE
for o CAMPUS DEPARTURE DATE
OBJECTIVE ITEM
# ID
on in
* CODE in D STUDENT GROUP
* DESCR # ID
o ITEM NUM on FS OBJECTIVE ITEM o CODE
o CORRECT RESPONSE o ITEM NUM o DESCR
o TEKS CODE for o CORRECT RESPONSE oETHNICITY GENDER
ACCOUNTABLE FLAG ECONOMIC DISADVANTAGED LEP SPECIAL ED
o RESPONSE CNT
D ITEM RESPONSE GROUP AT RISK BILINGUAL GANDT CAREER TECH TITLE 1 PART A ESL MIGRANT
# ID
o CODE for
o LABEL MIGRANT STUDENT IN TEXAS
o DESCR level of
in groups for
in
during
grouped
at by
15
RISD Data Model
4.6 AP Assessment
The following diagram shows the AP Assessment model.
FS AP
D TIME for o TESTED CNT
SCHOOL YEAR o TESTS TAKEN CNT
* YR ID taken during o AT OR ABOVE CNT
CALENDAR DAT * YR SCHOOL YEAR o AT OR ABOVE PCT
* CAL ID * YR SCHOOL YEAR D ADMINISTRATION PERIO for o MULTIPLE TEST CNT
* CAL DATE * YR START DATE * ADMIN PD ID o SCORE 1 CNT
* CAL MONTH * YR END DATE * ADMIN PD o SCORE 2 CNT
* ADMIN PD DESCR
taken during
* CAL YR * YR START YEAR o SCORE 3 CNT
* YEAR START DATE * YR END YEAR * ADMIN MONTH o SCORE 4 CNT
... ... o SCORE 5 CNT
o UNKNOWN SCORE CNT
for for o SCORE 1 PCT
for o SCORE 2 PCT
o SCORE 3 PCT
D LOCATION o SCORE 4 PCT
# ID
FH STUDENT HISTOR o SCORE 5 PCT
# ID o UNKNOWN SCORE PCT
o DISTRICT START DATE D DISTRICT for
profile for taken on o DIST ID
o DISTRICT DEPARTURE DA taken durin
o CAMPUS START DATE o DISTRICT NAME taken a
o CAMPUS DEPARTURE DAT o DISTRICT DESCR

F AP STUDENT RESULTS taken during
* EXAM GRADE D AREA
o IRREGULARITY CODE 1 o AREA ID
o IRREGULARITY CODE 2 o NAME
o EXAM SUPPRESSION CODE o DESCR taken in
profiled by o CLASS SECTION CODE taken a
D CAMPUS
D STUDENT * CAMPUS ID
# ID for
o PEIMS CAMPUS NUMB grouped by
* RISD ID * CAMPUS NUMBER
* PEIMS ID * CAMPUS NAME
o FIRST NAME
takes
o CAMPUS DESCR
o MIDDLE NAME o ADDRESS LINE
* LAST NAME taken by groups for
o CITY
o ADDRESS o STATE
o CITY ... D STUDENT GROUP
o ZIPCODE # ID
o BIRTH COUNTRY
o CODE
o DESCR
o DOB
D TEST AREA o ACCOUNTABLE FLAG
o GRADE FIRST ENROLL
profiled by # ID
o GRADE MOST RECENT ENRO taken in
* CODE subject of ECONOMIC DISADVANTAGED GENDER
...
o NAME
subject of SPECIAL ED LEP
o PASSING SCALE SCORE ETHNICITY
o PASSING RAW SCORE
D STUDENT AP o COMMENDED SCALE SCORE
* ID AT RISK BILINGUAL ESL GANDT
o COMMENDED RAW SCORE
* STUDENT ID grouped by o WRITTEN COMPOSITION PAS
o SCHOOL_CODE profile for o WRITTEN COMPOSITION COM CAREER TECH TITLE 1 PART A CITIZENSHIP
o LAST NAME
o FIRST NAME for have
for MIGRANT STUDENT IN TEXAS MIGRANT
o MIDDLE INITIAL of
o STREET_ADDRESS
o CITY D COURSE
o STATE D ASSESSMENT # ID
o COUNTRY_CODE # ID * CODE
o ZIP_CODE * CODE * DESCR
o DOB * DESCR o LEVEL
o SSN o ADMINISTRATION o AP IND
o EDUCATION LEVEL o OTHER IND ...
o US_CITIZEN
o RISD_STUDENT_NUMBE RISD AP TARGET SCORE
o RISD_CAMPUS_ID
group for
16
RISD Data Model
4.7 ACT Assessment
The following diagram shows the ACT Assessment model.

for
D TIME
SCHOOL YEAR
* YR ID
CALENDAR DATE ADMINISTRATION PERIOfor
* YR SCHOOL YEAR * ADMIN PD ID
* CAL ID * YR SCHOOL YEAR
* CAL DATE * ADMIN PD
* YR START DATE
* CAL MONTH * ADMIN PD DESCR
* YR END DATE
* CAL YR * ADMIN MONTH
* YR START YEAR
* ADMIN YEAR D ASSESSMENT
* YEAR START DATE * YR END YEAR # ID
... ...
* CODE
* DESCR
for for o ADMINISTRATION
test date fo
FH STUDENT HISTOR on
# ID D LOCATION
o DISTRICT START DATE # ID
DISTRICT DEPARTURE DA profile
on
o for taken taken
fo durin
o CAMPUS START DATE
o CAMPUS DEPARTURE DA D DISTRICT
o DIST ID
FS ACT
o DISTRICT NAME
taken on taken during taken duringfor o GRAD CNT

o DISTRICT DESCR o TESTED CNT
D AREA for o TESTED PCT
D STUDENT F ACT STUDENT RESULTS o AREA ID o AT OR ABOVE CNT
# ID # SEQ o NAME o AT OR ABOVE PCT
* RISD ID o REVISED SCORE o DESCR o MEAN ACT
* PEIMS ID o COMBINED EW SCORE D CAMPUS for o AGGREGATE ACT SCO
o FIRST NAME profiled by o WRITING SUBSCORE
taken at * CAMPUS ID
o MIDDLE NAME o WRITING NATIONAL NORMS o PEIMS CAMPUS NUMB taken a
* LAST NAME o WRITING SCORE DESC CD * CAMPUS NUMBER
o ENGLISH SCALE SCORE for * CAMPUS NAME
o ADDRESS
o CITY o MATH SCALE SCORE ...
o ZIPCODE o READING SCALE SCORE
o BIRTH COUNTRY o SCIENCE SCALE SCORE
take o COMPOSITE SCALE SCORE
o DOB o SUM SCALE SCORE
taken b o ENGLISH NATIONAL NORMS D STUDENT GROUP
o MATH NATIONAL NORMS # ID
o GRADE MOST RECENT ENRO
o US 1ST SCHOOL DATE o READING NATIONAL NORMS grouped b o CODE
o DISTRICT 1ST SCHOOL DATE o SCIENCE NATIONAL NORMS o DESCR ETHNICITY GENDER LEP
o DISTRICT CURRENT SCHOO o COMPOSITE NATIONAL NORMS groups for o ACCOUNTABLE FLAG
grouped b
...
ECONOMIC DISADVANTAGED SPECIAL ED
profiled by
AT RISK BILINGUAL GANDT CITIZENSHIP
grouped fo
RISD ACT TARGET SCOR test profile for
CAREER TECH ESL TITLE 1 PART A
D STUDENT ACT
# ID MIGRANT STUDENT IN TEXAS MIGRANT
o LAST_NAME
o FIRST_NAME
o MIDDLE_NAME
...
17
RISD Data Model
4.8 LDAA Assessment
The following diagram shows the LDAA Assessment model.
D TIME
ADMINISTRATION PERIOD CALENDAR DATE
SCHOOL YEAR * ADMIN PD ID * CAL ID
* YR ID * ADMIN PD * CAL DATE
* YR SCHOOL YEAR * ADMIN PD DESCR * CAL MONTH
... ... ...
D GRADE
# GROUP ID
* GROUP CODE
for D LOCATION
* GROUP DESCR
# ID
taken on
D TEST GRADE D ENROLLED GRADE D DISTRICT
# ID
# ID o DIST ID
* ASSESSMENT F LDAA STUDENT RESULTS
* CODE
* CODE on o DISTRICT NAME
o DESCR o SEQ o DISTRICT DESCR
* DESCR o READING TEST METHOD
o SORT SEQ for
o SORT SEQ o READING MET CRITERIA D AREA
o MATH TEST METHOD
taken at o AREA ID

o MATH MET CRITERIA o NAME
o WRITING TEST METHOD
D ASSESSMENT in for o DESCR
# ID o WRITING MET CRITERIA
o SCIENCE TEST METHOD
* CODE
for o SCIENCE MET CRITERIA
D CAMPUS
* DESCR * CAMPUS ID
o SOCIAL STUDIES TEST METHOD
o ADMINISTRATION o PEIMS CAMPUS NUMB
o SOCIAL STUDIES MET CRITERIA accountable in * CAMPUS NUMBER
* CAMPUS NAME
accountable for
o CAMPUS DESCR
o ADDRESS LINE
profiled by o CITY
o STATE
FH STUDENT HISTORY o ZIP CODE
...
# ID profile for
o DISTRICT START DATE taken by grouped by
o DISTRICT DEPARTURE DATE
o CAMPUS START DATE
o CAMPUS DEPARTURE DATE
groups for
D STUDENT D STUDENT GROUP

# ID
takes # ID
* RISD ID o CODE
* PEIMS ID o DESCR
o FIRST NAME o ACCOUNTABLE FLAG
o MIDDLE NAME
* LAST NAME
o ADDRESS ECONOMIC DISADVANTAGED GENDER
o CITY
o ZIPCODE LEP SPECIAL ED ETHNICITY
o BIRTH COUNTRY
o COUNT IN CLASS OF FLAG CAREER TECH
AT RISK ESL GANDT
o DOB
o GRADE MOST RECENT ENROLL MIGRANT STUDENT IN TEXAS MIGRANT
o DISTRICT 1ST SCHOOL DATE TITLE 1 PART A CITIZENSHIP BILINGUAL
o DISTRICT CURRENT SCHOOL DATE
...
18
RISD Data Model
4.9 SAT Assessment
The following diagram shows the SAT Assessment model.
D TIME
SCHOOL YEAR ADMINISTRATION CALENDAR DATE

* YR ID PERIOD * CAL ID
* YR SCHOOL YEAR * ADMIN PD ID * CAL DATE
D ASSESSMENT * YR SCHOOL YEAR D * CAL MONTH
* ADMIN PD
# ID * CAL YR
* CODE
* YR START DATE * ADMIN PD DESCR RISD SAT TARGET SCORE
* YR END DATE * ADMIN MONTH * YEAR START DATE * COMBINED TARGET SCORE
* DESCR ...
on ... ...
o ADMINISTRATION
on school yr for admin dt for
admin date for test date for
on
of D LOCATION
# ID
during school year given in date taken on
D DISTRICT
for o DIST ID
F SAT REASONING STUDENT RESULTS o DISTRICT NAME
# SEQ o DISTRICT DESCR
D TEST AREA o MATH SCORE
# ID
on
o VERBAL SCORE D AREA
* CODE o COMBINED SCORE o AREA ID
o NAME o WRITING SCORE
o PASSING SCALE SCORE reasoning scores for taken at o NAME

o ESSAY SUBSCORE o DESCR
o PASSING RAW SCORE o MC SUBSCORE
o COMMENDED SCALE SCORE for
o REVISED SCORE IND D CAMPUS
o COMMENDED RAW SCORE o VERBAL NATIONAL COLLEGE BOUND PERCENTILE
... * CAMPUS ID
o MATH NATIONAL COLLEGE BOUND PERCENTILE o PEIMS CAMPUS NUMBER
o WRITING NATIONAL COLLEGE BOUND PERCENTIL accountable in * CAMPUS NUMBER
o VERBAL STATE COLLEGE BOUND PERCENTILE on
* CAMPUS NAME
o MATH STATE COLLEGE BOUND PERCENTILE accountable for o CAMPUS DESCR
o WRITING STATE COLLEGE BOUND PER o ADDRESS LINE
D STUDENT SAT on o DISTRICT CNT o CITY
# ID o CAMPUS CNT grouped by o STATE
o SCHOOL_CODE for o LOCAL CNT o ZIP CODE
o LAST_NAME
o PHONE NUMBER
o FIRST_NAME
...
o MIDDLE_NAME
o SEX
for profiled by on
groups for
o DATE_OF_BIRTH
o SOCIAL_SECURITY have
o STREET_ADDRESS D STUDENT GROUP
o CITY # ID
o STATE D STUDENT o CODE
o ZIP_CODE # ID o DESCR
o COUNTY * RISD ID profile for o ACCOUNTABLE FLAG
o HS_GRADUATION_DATE * PEIMS ID
o FOREIGN_ADDRESS_IND o FIRST NAME
FH STUDENT HISTORY ETHNICITY GENDER
o RISD_STUDENT_NUMBER o MIDDLE NAME
# ID
o RISD_CAMPUS_ID * LAST NAME
o DISTRICT START DATE
o ADDRESS
ECONOMIC DISADVANTAGED
for o CITY
o CAMPUS START DATE
o ZIPCODE
on o BIRTH COUNTRY
o CAMPUS DEPARTURE DATE SPECIAL ED LEP
o DOB AT RISK GANDT BILINGUAL
o GRADE MOST RECENT ENROLL MIGRANT
CAREER TECH ESL
o DISTRICT 1ST SCHOOL DATE
o DISTRICT CURRENT SCHOOL DATE TITLE 1 PART A CITIZENSHIP
...
for for for at MIGRANT STUDENT IN TEXAS
on
FS SAT REASONING
o GRADS CNT grouped by
o TESTED CNT for for
o TESTED PCT group for for
o SAT TOTAL SCORE
o SAT MEAN SCORE FS STUDENT SAT HI SCORE
o AT OR ABOVE CNT o MATH SCORE
o AT OR ABOVE PCT o VERBAL SCORE
o WRITTEN SCORE
o ESSAY SUBSCORE
o MC SUBSCORE
o COMPOSITE SCORE
o HIGH SCORE SAT
o HIGHEST MATH SCORE
o HIGHEST MATH SAT
...
19
RISD Data Model
4.10 PSAT Assessment
The following diagram shows the PSAT Assessment model.
D TIME RISD PSAT TARGET
ADMINISTRATION PERIOD CALENDAR DATE

SCHOOL YEAR * ADMIN PD ID
* YR ID * CAL ID
* ADMIN PD * CAL DATE
* YR SCHOOL YEAR * ADMIN PD DESCR * CAL MONTH
* YR SCHOOL YEAR D ... ...
...
D STUDENT for for for

# ID
* RISD ID
* PEIMS ID D LOCATION
o FIRST NAME # ID
o MIDDLE NAME taken during
taken during taken on
* LAST NAME D DISTRICT
o ADDRESS taken at o DIST ID
o CITY takes F PSAT STUDENT RESULTS o DISTRICT NAME
o ZIPCODE o CRITICAL READING SCORE for o DISTRICT DESCR
o MATH SCORE
taken by

o BIRTH COUNTRY
o COUNT IN CLASS OF FLAG o WRITING SKILLS SCORE D AREA
o SELECTION INDEX o AREA ID
o DOB
o CRITICAL READING PERCENTILE o NAME
o GRADE MOST RECENT ENROL profile for o MATH PERCENTILE o DESCR
o WRITING SKILLS PERCENTILE
o SELECTION PERCENTILE D CAMPUS
o DISTRICT CURRENT SCHOOL profiled by * CAMPUS ID
... o PEIMS CAMPUS NUMBE
* CAMPUS NUMBER
profiled by for grouped by * CAMPUS NAME
o CAMPUS DESCR
o ADDRESS LINE
FH STUDENT HISTORY
# ID profile for on o CITY
o STATE
o DISTRICT START DATE
o ZIP CODE
D STUDENT PSAT D ASSESSMENT o PHONE NUMBER
o CAMPUS START DATE * ID # ID ...
o CAMPUS DEPARTURE DATE o SCHOOL_CODE * CODE
o STUDENT ID * DESCR groups for
o LAST NAME o ADMINISTRATION
o FIRST NAME
o MIDDLE INITIAL
D STUDENT GROUP
# ID
o STREET_ADDRESS
o CITY
o CODE ETHNICITY GENDER LEP
o DESCR
o STATE
o ACCOUNTABLE FLAG
o ZIP_CODE ECONOMIC DISADVANTAGED SPECIAL ED
o COUNTRY_CODE
o DOB
o YEAR ENTERING COLLEGE AT RISK BILINGUAL ESL TITLE 1 PART A GANDT
o SOCIAL_SECURITY
o US_CITIZEN
... MIGRANT STUDENT IN TEXAS CAREER TECH MIGRANT CITIZENSHIP
20
RISD Data Model
4.11 K-2 Math Assessment
The following diagram shows the K-2 Assessment model.
D TIME
CALENDAR DATE SCHOOL YEAR ADMINISTRATION PERIOD

...
for for for for
D ASSESSMENT D GRADE
# ID # GROUP ID
* CODE taken on taken during
* GROUP CODE
* DESCR * GROUP DESCR
o ADMINISTRATION
F K2MATH STUDENT taken during D LOCATION
D TEST GRADE D TEACHER # ID
RESULTS * ID
# ID for * SEQ * EMPLOYEE NUMBER
of * ASSESSMENT
* DISTRICT CNT o ADVISOR NUMBER
D DISTRICT
* CODE o DIST ID
for * CAMPUS CNT taught by o FIRST NAME
o DISTRICT NAME
* DESCR
o MIDDLE NAME
o SORT SEQ for F K2MATH STUDENT TEST teaches o LAST NAME
o DISTRICT DESCR
D TEST AREA AREA RESULTS o HIRE DATE D AREA

# ID o TESTED CNT ... o AREA ID
* CODE o RAW SCORE
in in o PASSED IND taken in
o NAME
o NAME o DESCR
o PASSING SCALE SCORE o NOT PASSED IND
for o COMMENDED PERFORMANCE IN for
o PASSING RAW SCORE D CAMPUS
D TEST VERSION o MASTERED ALL OBJECTIVES IND for
o COMMENDED SCALE SCOR
# ID for * CAMPUS ID

* CODE D STUDENT o PEIMS CAMPUS NUMBER
o WRITTEN COMPOSITION PA
* NAME given in # ID * CAMPUS NUMBER
o WRITTEN COMPOSITION CO F K2MATH STUDENT OBJ * RISD ID * CAMPUS NAME
RESULTS taken by * PEIMS ID o CAMPUS DESCR
o OBJECTIVE SCORE o FIRST NAME o ADDRESS LINE
in for o MET OBJECTIVE IND o MIDDLE NAME
takes o CITY
for in o NOT MET OBJECTIVE IND * LAST NAME o STATE
o MASTERED OBJECTIVE IND o ADDRESS o ZIP CODE
o NOT MASTERED OBJECTIVE IND o CITY ...
D OBJECTIVE o ZIPCODE
# ID for o BIRTH COUNTRY
* CODE F K2MATH STUDENT ITEM o COUNT IN CLASS OF FLAG
* DESCR RESULTS o DOB
o ITEM CNT * CORRECT RESPONSE IND o GRADE FIRST ENROLL
for
o MASTER OBJECTIVE SCORE * ITEM RESPONSE o GRADE MOST RECENT ENROLL
o RAW SCORE o US 1ST SCHOOL DATE
grouped by profiled by o DISTRICT CURRENT SCHOOL DATE
...
for profile for
in
FH STUDENT HISTORY
# ID
OBJECTIVE ITEM on o DISTRICT START DATE
# ID o DISTRICT DEPARTURE DATE
* CODE
in in during at o CAMPUS START DATE
* DESCR o CAMPUS DEPARTURE DATE
o ITEM NUM on FS OBJECTIVE ITEM
o CORRECT RESPONSE (K o ITEM NUM
groups for
o TEKS CODE for o CORRECT RESPONSE
o RESPONSE CNT D STUDENT GROUP ETHNICITY GENDER LEP
grouped by # ID
o CODE
D ITEM RESPONSE GROUP o DESCR
# ID groups for ECONOMIC DISADVANTAGED SPECIAL ED
o ACCOUNTABLE FLAG
o CODE for
o LABEL
o DESCR level of
21
RISD Data Model
4.12 ERWA/TPRI Assessment
The following diagram shows the ERWA/TPRI Assessment model.
D TIME
ADMINISTRATION PERIOD
* ADMIN PD ID RISD ERWA TARGET SCORE
SCHOOL YEAR ...
...
CALENDAR DATE
...
for
for for D LOCATION

taken on # ID
for
F ERWA STUDENT RESULTS D DISTRICT
o DIST ID
(TASK) o DISTRICT NAME
D GRADE * SEQ
o DISTRICT DESCR
o SCREENING 1
# GROUP ID
o SCREENING 2
at
* GROUP CODE D AREA
* GROUP DESCR o SCREENING 3
o SCREENING 4
on o AREA ID
o NAME
o WARMUP
D TEST GRADE o TASK 1 D STUDENT o DESCR
# ID for
o TASK 2 # ID
* ASSESSMENT
o TASK 3 * RISD ID D CAMPUS
* CODE for in * CAMPUS ID
o TASK 4 * PEIMS ID
* DESCR o PEIMS CAMPUS NUMBER
o TASK 5 o FIRST NAME
for o SORT SEQ * CAMPUS NUMBER
o TASK 6 o MIDDLE NAME
* CAMPUS NAME
o TASK 7 * LAST NAME
o CAMPUS DESCR
o TASK 8 o ADDRESS
o ADDRESS LINE
o TASK 9 o CITY

o CITY
o LISTENING COMP EXPLICIT taken by o ZIPCODE
o STATE
o LISTENING COMP IMPLICIT o BIRTH COUNTRY
o ZIP CODE
D TEST AREA o LISTENING COMP TOTAL take o COUNT IN CLASS OF FLAG
# ID o WORDLIST 1 o DOB
o PHONE NUMBER for
...
* CODE o STORY1 o GRADE FIRST ENROLL
o NAME o GRADE1 o GRADE MOST RECENT ENROLL
o PASSING SCALE SCORE on o READ LISTEN 1 o US 1ST SCHOOL DATE
o PASSING RAW SCORE o ACCURACY 1 o DISTRICT 1ST SCHOOL DATE
o COMMENDED SCALE SCORE for o FLUENCY WPM 1 o DISTRICT CURRENT SCHOOL DAT
o COMMENDED RAW SCORE o EXPLICIT COMP 1 ...
for o IMPLICIT COMP 1 has
o WRITTEN COMPOSITION PASSING S
o WRITTEN COMPOSITION COMMENDE o WORDLIST 2
o STORY2
profiled by FH STUDENT HISTORY
for for o GRADE2 # ID
o READ LISTEN 2 profile for o DISTRICT START DATE
o ACCURACY 2 o DISTRICT DEPARTURE DATE
o FLUENCY WPM 2 o CAMPUS START DATE
of o EXPLICIT COMP 2 grouped by o CAMPUS DEPARTURE DATE
o IMPLICIT COMP 2
D ASSESSMENT o IPT
# ID o DRA
* CODE ... grouping for
* DESCR
o ADMINISTRATION in class of
D STUDENT GROUP
# ID
test time teacher for o CODE
o DESCR ETHNICITY GENDER
o ACCOUNTABLE FLAG
D TEACHER
* ID SPECIAL ED LEP ECONOMIC DISADVANTAGED
* EMPLOYEE NUMBER
takenduring
at in of o FIRST NAME
o MIDDLE NAME AT RISK BILINGUAL GANDT ESL CAREER TECH CITIZENSHIP
for o LAST NAME
FS ERWA STUDENT RESULTS
o MET 1 OF 3 CNT o HIRE DATE
on ... MIGRANT STUDENT IN TEXAS TITLE 1 PART A MIGRANT
o MET 2 OF 3 CNT
o MET 3 OF 3 CNT for
groups for groups for
grouped by
in of in grouped by at
FS ERWA RESULTS
o TESTED CNT
o MET BENCHMARK DRA CNT
o MET BENCHMARK DRA PCT
o MET BENCHMARK TPRI CNT
o MET BENCHMARK TPRI PCT
o MET BENCHMARK WRITTEN CNT
o MET BENCHMARK WRITTEN PCT
o MET 1 OF 3 CNT
...
22
RISD Data Model
4.13 Tejas Lee Assessment
The following diagram shows the Tejas Lee Assessment model.
D TIME
ADMINISTRATION PERIOD RISD TEJAS LEE TARGET SCORE
* ADMIN PD ID
SCHOOL YEAR ...
...
CALENDAR DATE
for ...
D LOCATION
# ID
for for
D DISTRICT
for o DIST ID
taken on o DISTRICT NAME
D GRADE o DISTRICT DESCR
# GROUP ID
* GROUP CODE F TEJAS LEE STUDENT D AREA
* GROUP DESCR RESULTS at o AREA ID
* SEQ o NAME
D TEST GRADE * SECTION 1 on o DESCR
# ID for o SECTION 2
* ASSESSMENT
* CODE
o SECTION 2A D STUDENT D CAMPUS
in o SECTION 2B # ID * CAMPUS ID
* DESCR for o SECTION 3 * RISD ID o PEIMS CAMPUS NUMBER
o SORT SEQ
o SECTION 4 * PEIMS ID * CAMPUS NUMBER
for o SECTION 5 o FIRST NAME * CAMPUS NAME
o SECTION 6 o MIDDLE NAME o CAMPUS DESCR
o SECTION 6A * LAST NAME o ADDRESS LINE
o SECTION 6B o ADDRESS o CITY
o OBJ 5 o CITY o STATE
o SECTION 8 o ZIPCODE o ZIP CODE
D TEST AREA

o WORDLIST 1 o BIRTH COUNTRY o PHONE NUMBER for
# ID
o STORY1 taken by o COUNT IN CLASS OF FLAG o YEAR OPENED
* CODE
o GRADE1 o DOB o CAMPUS TYPE
o NAME
o READ LISTEN 1 takes o GRADE FIRST ENROLL
o PASSING SCALE SCORE
o ACCURACY 1 o GRADE MOST RECENT ENROLL
o PASSING RAW SCORE
o COMMENDED SCALE SCORE
on o FLUENCY WPM 1 o US 1ST SCHOOL DATE
o EXPLICIT COMP 1 ...
for for o IMPLICIT COMP 1 took
o WRITTEN COMPOSITION PASSING SC
o WORDLIST 2
for o WRITTEN COMPOSITION COMMENDE
o STORY2
o GRADE2
for o READ LISTEN 2 FH STUDENT HISTORY
o ACCURACY 2 profiled by # ID
o FLUENCY WPM 2 o DISTRICT START DATE
of o EXPLICIT COMP 2 profile for o DISTRICT DEPARTURE DATE
o IMPLICIT COMP 2 o CAMPUS START DATE
... o CAMPUS DEPARTURE DATE
D ASSESSMENT
# ID
* CODE
for grouped by
* DESCR
o ADMINISTRATION D STUDENT GROUP
# ID
o CODE
o DESCR ETHNICITY GENDER
D TEACHER grouping for o ACCOUNTABLE FLAG
* ID
SPECIAL ED LEP ECONOMIC DISADVANTAGED
* EMPLOYEE NUMBER
taken
in
taken in
at during o FIRST NAME
on
o MIDDLE NAME AT RISK BILINGUAL GANDT ESL CAREER TECH CITIZENSHIP
o LAST NAME
FS TEJAS LEE STUDENT o HIRE DATE
RESULTS ... MIGRANT STUDENT IN TEXAS TITLE 1 PART A MIGRANT
o MET 1 OF 3 IND
o MET 2 OF 3 IND has
taught by
o MET 3 OF 3 IND groups for groups for
taken by
grouped by
in in during grouped by taken at
FS TEJAS LEE RESULTS

o TESTED CNT
o MET BENCHMARK DRA CNT
o MET BENCHMARK DRA PCT
o MET BENCHMARK TPRI CNT
o MET BENCHMARK TPRI PCT
o MET BENCHMARK WRITTEN CNT
o MET BENCHMARK WRITTEN PCT
o MET 1 OF 3 CNT
...
23
RISD Data Model
5.0 Summary Tables
While reviewing the access requirements when creating the Logical Data Model, it often becomes
clear that summary tables will be needed. Summary tables and “views” of the data are associated
with the physical database design and are used to improve performance or simplify end user data
access. These “summary” tables may be implemented physically as materialized views but those
decisions will be made during the physical database design. Some summaries have been
identified and they can be identified in the entity list because they are prefixed with FS (Fact
summary).
Business rules for the creation of derived fields in the summary tables may continue to be added
after the physical design is approved but before implementation is complete. The intent is to
precalculate derived fields that will be used multiple times in reporting and analysis to ensure
consistency across reports. These business rules are documented in the report requirements and
included in the data model for base table calculations. Base tables are simply the lowest level
tables in the model. Some business rules will only apply to summary tables and these rules will

be added to the model to support the physical implementation.
24
RISD Data Model
Appendix A – Additional Data Modeling Concepts

The following section describes at a high level and introductory manner data modeling concepts.
The idea here is to give the reader a quick synopsis of the thought process brought to bear when
designing and building a data model.
Data Modeling is the process through which a logical structure is imposed upon the data
elements within a system. This logical structure standardizes the data, and thus becomes the
cornerstone of any information infrastructure. The data model provides a graphical representation
of how each piece of data relates to itself and others. This representation is known as an Entity
Relationship Diagram (ERD). The first step in creating the Data Model involves identifying and
defining attributes. Attributes are the lowest level of data that can be described, for example, last
name, badge number, building number. These attributes are grouped (using Information
Modeling techniques, such as Normalization) into entities. Usually, entities can be described as
nouns— employee, product, customer, sales-rep and so on. The next step would be to define the
relationships between and among the entities. Relationships are described as verb phrases, for
example, employees “work at” locations, customers “buy” products. There are several different

types of relationships. The most common ones are the following:
• 1 to 1: Where1 employee “works at” 1 and only one location

• Many to 1: Where zero or more employees “work at” 1 and only 1 location
• 1 to Many: Where 1 employee “works at” zero or more locations
• Many to Many: Where zero or more employees “work at” zero or more locations
Business rules refine and enforce the definition of these relationships. For example, a business
rule may state that an employee “works at” 1 and only 1 location. Although this relationship might
initially have been defined as a many to many relationship, the business rule will eliminate that
possibility, thereby enforcing the desired 1 to 1 relationship.
The compilation and integration of all of the entities, attributes, and relationships referenced by a
system is called the logical model. After completing the logical model, the next step is to create
the physical model. The physical model represents how the logical model will be represented. At
a basic level, each entity in the logical model becomes a table in the physical model, and each
attribute within an entity becomes a column within that respective table and each relationship
becomes a constraint between the tables.
Each table has a primary key associated with it. A primary key is a unique identifier for the table.
Remembering that a table is just the physical manifestation of an entity, a primary key allows us
to uniquely identify a particular instance or occurrence of this entity. For example, the STUDENT
ASSESSMENT table contains all Student assessment details. A primary key into the STUDENT
ASSESSMENT, such as student Identifier allows us to uniquely identify an individual student.
Where there are relationships between two tables, data must exist to “tie” them together.
Depending on the type of relationship, the primary key from the “one” side of a relationship may
be transferred to the “many” side of the relationship. This creates a parent/child relationship with
“one” side, being the parent and the “many” side being the child side. The transferred primary key
from the parent is called a ‘foreign key’ in the child entity. Sometimes, the foreign key becomes a
component of the primary key set of the child entity. Once all the entities and relationships have
been defined and diagramed (therefore, the name Entity Relationship Diagram [ERD]), the logical
model is complete.
The physical data model is developed/generated from the logical model. Information found in the
physical data model but not in the logical data model includes objects such as, tablespaces,
sizing within the tablespaces, growth rates for the tablespaces, partitioning schemes, indexes,
and so on. Foreign keys are good candidates on which to place indexes. In addition, any place in
the data warehouse where retrievals for the end users would limit the returning rows should have
an index defined and created on it.
25
RISD Data Model
All of these objects discussed (entities, attributes, relationships, business rules, logical models,
physical models, and so on) are known as metadata. Metadata is often called “data about data”,
and collectively it provides a documented understanding of the data in a system. For example,
the entity student is metadata that describes a specific instance of a student. Each instance of
student also contains a set of additional information (attributes). All of this metadata is stored
within the repository. A repository is a central location where all metadata is catalogued,
documented, and stored. Every piece of data represented in any model produced by the Data
Warehouse design team will have its metadata stored in this central repository.
A.1 - Data Modeling Activities
The data modeling activities involved in building the data warehouse can, and will be separated
into the following activities:
⇒ Building the repository environment
⇒ Conducting end-user interviews (Functional Specialists)
⇒ Collecting existing metadata assets
⇒ Metadata Analysis/Quality of the current data
⇒ Capturing the Business Rules

⇒ Development of the business Data Model
⇒ Developing the Logical Data Model
⇒ Developing the Physical Data Model
⇒ Mapping the data from Current Data Structures (in this case, the ODS) to the Data
Warehouse
⇒ Building the Metadata Repository
⇒ Creating the Business Semantic Layer (Discoverer End User Layer) for User Tools
After the completion of these tasks, the database designs, transformation logic, and end-user
definitions will be turned over to the data warehouse implementation team.
A.2 - Building the Repository Environment
In the creation of any data warehouse, metadata is one of the critical success factors. Metadata
comes in two flavors: technical metadata and business metadata. Technical metadata describes
the technical aspects of each piece of data—name, size, data type, valid values, and
transformation rules. Business metadata describes what each piece of data means (descriptions,
business rules, and calculations, computations, summarization, aggregations and so on).
Gathering and recording this metadata is of limited value, however, if there are no means to
dynamically maintain and reference it.
In order to provide a single place that describes the environment and all of its individual pieces, a
repository needs to be created and populated. Oracle Corporation will use Oracle Designer (part
of Oracle’s Internet Development Suite), to dynamically maintain and reference the RISD
metadata repository and the Oracle Warehouse Builder (OWB) repository. Collecting all of the
assets and storing them in a single repository will provide for a consistent environment for all
users, both business and technical, to ask questions about what data is available, where it was
obtained from, what manipulations, if any, it went through before it was put into the data
warehouse. Thus, the repository will serve as a tool to distinguish information from data. Data is
facts; information is the correlation of facts. Moreover, it is the understanding of the correlation,
as defined by the metadata, which makes data become information.
In a complex metadata environment with large modeling teams, model management and user
extensibility features become quite important. Oracle Designer’s repository helps in this regard
with access and version control, controlled sharing, object grouping, extract, load, merge, object
checkout, and check-in. It also has extensibility features through its application program interface
(API) and a facility to create new properties, objects and associations.
The architecture document describes in more detail how Oracle Designer will integrate with the
OWB Extract, Transform, and Load (ETL) tool.
26
RISD Data Model
A.3 Collecting Metadata Assets
The usability and usefulness of a data warehouse is completely dependent on the quality of the
data and information used during the design and build phases. Determining the current RISD
systems that constitute the most accurate data available helps us determine the “system of
record”. In the case of state assessment information, right or wrong, the information on the state
supplied input is considered the system of record. However, current or point-in-time student
demographic information may be more accurate for reporting “local” results. Gathering and
documenting the current data structures from the system of record that contains pieces of data
intended for the warehouse is critical. In our case, all data will be loaded into the Operational
Data Store (ODS) as the single source for the Data Warehouse. However, determining the data
sources and business rules needed to load data into the ODS, is critical to the success of the
Data Warehouse project.
A.4 Metadata Analysis (Quality of Source Data)

In this project, like most, the system of record consists of many disparate systems that may or
may not be related through individual data elements or records. In some instances, records from
related systems that might be considered identical (based on their metadata or definitions) may in
actual fact, house totally different values depending on the usage at the division. This is clearly
the case with assessment information having similar definitions but different values. In other
instances, the values may be identical, but the storage mechanism may differ, for example, a
student name stored in one system has a maximum allowed length of 20 characters but in a
second system has a maximum length of 25 characters. Because of these types of
discrepancies, the exact mapping between the sources and targets within the system of record
needs to be documented in order to understand how well the data is stored in the current system.
To resolve these anomalies, an evaluation of the current data is required. During the evaluation
phase, data will be analyzed for:
• Size
• Valid values
• Hierarchies that are implemented within the data correctly
• Other items (for example, dates stored as dates, text, and/or numeric values in different
systems)
A.5 Capture Business Rules
Business rules define the relationship between data and the processes through which these
relationships are created, maintained, and destroyed. In order to populate the repository and
create a data warehouse containing the most accurate data, the task of capturing business rules
will comprise reviewing data structures, current codes and the set of codified constraints placed
on the data by organizations/divisions from where the data originated. For the RISD Data
Warehouse, data will ultimately come from the ODS. Business rules for loading the ODS as well
as business rules for transforming ODS data into DW data should be documented.
27
ROY INDEPENDENT SCHOOL
DISTRICT

M5_RISD_PHYSICAL_DATABASE_DESIGN_V3.0.doc
MD.070 PHYSICAL DATABASE

DESIGN
RISD DATA WAREHOUSE

Creation Date:
Last Updated:
Version: 3.0
Approvals:
1 Document Control
1.1 Change Record
Date Author Version PVCS Change Reference

Version

1.2 Reviewers
Name Role Version Date
1.3 Distribution
Copy No. Name Function
1
2
3
4
Note to Holders:
If you receive an electronic copy of this document and print it out, please write
your name on the equivalent of the cover page, for document control
purposes.
If you receive a hard copy of this document, please write your name on the
front cover, for document control purposes.
RISD DW Physical Design Company Confidential - For internal use only ii

Table of Contents
1 DOCUMENT CONTROL ...................................................................................... II

1.1 Change Record ................................................................................................ ii
1.2 Reviewers ......................................................................................................... ii
1.3 Distribution ........................................................................................................ ii
2 INTRODUCTION......................................................................................................1
2.1 Purpose ..............................................................................................................1
2.2 Background........................................................................................................1
2.3 Related Documents ..........................................................................................2
3 BUSINESS DRIVERS .............................................................................................3

3.1 High Level Requirements ................................................................................3
3.2 Assumptions and Constraints .........................................................................3
4 DATA WAREHOUSE IMPLEMENTATION APPROACH.................................4
4.1 Single Database Production Instance ...........................................................4
4.2 Characteristics ...................................................................................................4
4.3 Physical Design Considerations .....................................................................5
5 DATABASE SCHEMAS .........................................................................................6
6 MATERIALIZED VIEWS.........................................................................................7
6.1 Discoverer End User Layer .............................................................................7
7 DATABASE OBJECTS ..........................................................................................8
7.1 Dimension Tables .............................................................................................8
7.2 Fact Tables ......................................................................................................12
7.3 Summary Tables .............................................................................................18
7.4 Other DW Tables ............................................................................................19
7.5 Sample DDL to Create Data Warehouse Indexes .....................................19
8 SAMPLE DATABASE DEFINITION LANGUAGE (DDL) ...............................21
RISD DW Physical Design Company Confidential - For internal use only iii
2 Introduction
2.1 Purpose
This Physical Database Design document defines how the Logical
Database Design approved by the RISD business community translates
to the physical environment required to support the RISD assessment
reporting requirements. The physical environment is designed to add
subject areas in subsequent phases of the DW project. The table
structures, indexes, partitioning schemas, and so on. are a subset of the

overall data architecture and the DW infrastructure outlined in the
architecture documents. Please note that the DW environment refers to
both the ODS and the Data Warehouse. This document addresses:
• Business Drivers
• Logical to Physical Design implementation approach
• Database Schemas
• Physical Database Environment
• Data Definition Language (DDL)
2.2 Background
The data warehouse team created the RISD Logical Data Model (LDM)
based on a generic data model created from similar K-12 organizations.
Specific RISD requirements and business rules provided by RISD
business users, technical users, and the District Assessment team
resulted in an enhanced model specific to RISD needs. The Phase 1
RISD logical data model has been designed to meet RISD initial
assessment reporting requirements but can be easily expanded to
include the additional subject areas included in the generic data model.
The requirements reflect current 2004 assessment inputs.
Enhancements to the generic K-12 model provided to RISD in phase 1

address the initial student assessment reporting requirements. Changes
will be added in subsequent phases to address reporting and analysis
requirements in additional subject areas. In addition to new subject
areas, the environment will grow from the initial three years of student
data at conversion to 13 years of student assessment history.
RISD DW Physical Design Company Confidential - For internal use only 1

1. Milestone 1, Project Management Plan – Baseline plan in Microsoft
projects with accompanying project management plan (PMP) document.
2. Milestone 2, RD.049 Report Requirements Document – Clearly defines
the reporting requirements in the 12 priority assessment areas
implemented for Phase 1.
3. Milestone 3, RD.049 Portal Security Requirements – Data Warehouse
Portal Security Design Document describes the functionality of the Portal
pages required to support the highest priority Data Warehouse
Discoverer and Dashboard reports. The Look and feel, navigation colors
and graphics are not part of these requirements and only the Data

Warehouse page content, report links and how roles determine
geographic defaults will be included.
4. Milestone 4, Logical Data Model – Logical Data Model Design contains all the
entities (facts, dimensions and measures) to deliver the report requirements. The
actual design will be contained in the Designer Repository but a separate
document outlining the design is also provided.
5. Milestone 6, TA.010 Technical Architecture Document – The Technical
Architecture (TA) Document describes all Development, Test and
Production components, including the hardware, platform, software
versions, set up configurations and data base schemas and
development repositories. The capacity plan defines the system
capacity requirements such as performance, memory, storage, backup
and recovery, network, upgrade potential, and extensibility needed to
support RISD requirements.

3 Business Drivers
RISD currently has independent processes that create reports across

multiple assessment areas. Although most processes use reusable
code, the process to create edited assessment files is very manual.
However, a primary issue with the approach is that data cannot be easily
shared across assessments and if updated student information is
required, the files must be reprocessed. An integrated data environment
will provide RISD with easy access to integrated quality data and allow
the assessment team more time to analyze results as opposed to
collecting results and processing data. In addition, Web access to real
time data will provide RISD personnel timely access to data. In the
future, the parents will have direct access to their child’s assessment and

enrollment information.
3.1 High Level Requirements

Report requirements are documented in Milestone 2 with the portal
security requirements documented in Milestone 3. Milestone 4, the
logical data model (LDM) was the primary input to the Physical data
mode since the report access requirements were integrated into the
LDM. Oracle Designer was used to create the LDM and the
corresponding Physical Data Model. The physical data model will
continue to evolve through the remainder of development and into
production. As additional reports are created, additional database views
may be needed to support new reporting requirements or to improve
data access performance. The initial physical data design has identified
the high level reporting requirements business rules and the primary
physical summary tables needed to satisfy those requirements.
3.2 Assumptions and Constraints
1. The applications architecture and configuration as currently defined

by RISD will support the system’s expansion to 13 years of student
assessment history. In addition, RAC technology will allow the
environment to scale to meet future data and processing needs.
2. Adding data elements in future phases to address reporting
requirements will not require architecture changes but will necessitate
changes to the front-end Discoverer environment and potentially the
addition of new tables and database views or summaries to ensure
performance requirements can be met.
3. Additional database views, summaries, and stored derived fields may
be added to the physical model as we enter the report development
and testing phases of the project to support performance
requirements.

4 Data Warehouse Implementation Approach
As noted in the technical architecture document, the RISD Data
Warehouse approach uses multiple Data Warehouse machines in a Real
Application Cluster (RAC) environment. This Approach will allow
expansion as additional processing power is needed in the future to
support additional subject areas.
4.1 Single Database Production Instance

A single database instance will be used in the production environment to
reduce maintenance. Given that there are finite machine resources in
any physical architecture, having one large instance allows RISD to load

balance resources against other applications running on the same
machine. This does not imply resources will always be available when
needed, but that a larger Oracle SGA and buffers will provide the
flexibility to better manage the environment and improve performance.
4.2 Characteristics
The database instance will have the following characteristics:
1. Since the DW size is relatively small we will initially create only two
tablespaces.
Tablespace for data (DWD)
Tablespace for indexes (DWI)
Note: Dev has the OWB Design Repository in OWBRTTAB for tables and
OWBRTIDX for indexes
2. OWB Tablespaces
OWB Design Repository – OWBTAB for tables and OWBTIDX
for indexes
OWB Runtime Repository – OWBRTTAB for tables and
OWBRTIDX for indexes
3. Tablespaces will be Oracle transportable tablespaces, which are
bitmapped, not dictionary managed.
4. Tablespaces can be spread across multiple mount points on the
physical array. This will ensure that there are no I/O problems
associated with mixing tables and indexes. This is not an issue in the
RISD hardware environment since each mount point is stripped
across multiple devices and multiple devices are used for each
tablespace. The concept of keeping tables and indexes in separate
tablespace grew out of the general need to provide additional I/O
capabilities. This was more important when disk striping and storage
array technology did not exist but is still considered best practice.
5. Production control processes will ensure data integrity and control
data warehouse processing logic.

6. A separate schema will be used to store front-end Discoverer
application code. This schema will contain all of the stored
procedures needed to run the front-end presentation layer
application. Since one schema will contain all the PL/SQL, a single
schema can be managed and backed up as required. This schema
can be exported and imported without concern since it will only
contain application code and control tables.
7. A separate schema will be used to maintain all back-end database
source code. This schema will contain all OWB generated code.
There will be two more schemas’ for the OWB Design and Runtime
repositories.
4.3 Physical Design Considerations

One of the most important aspects of database performance is the
interface to the disk I/O subsystem. When using Oracle databases, the
interface to the operating system is through read/write data files.
1. Disk I/O performance can be improved through a number of
techniques such as striping. Striping improves I/O performance by
spreading or balancing disk I/O across multiple physical devices.
2. Designing the physical disk layout properly ensures I/Os are spread
across all available devices and that read/write operations during
batch processing are separated.
3. Disk configurations that balance I/O’s across all available devices
optimize performance.
4. Partitioning will use school year and perhaps assessment. When the
time comes for rolling off or archiving data, it will be deleted by
school year or perhaps a combination of school year and
assessment. The number of records in a given school year is
relatively small but as more history is accumulated, we anticipate
more trend analysis over multiple years.

5 Database Schemas
The following database schemas will be created as part of the physical
design:
OWBREP (design repository)
DWRISD (DW target Schema)

6 Materialized Views
Materialized views may be created to support the performance
requirements and to ensure consistent business rules are applied across
RISD reports. Creating materialized views has some benefits over using
summary tables since end users would need to be aware of summary
files and specifically code for them. Of course, after a refresh of data,
the materialized view will need to be refreshed.
Materialized views will be automatically used through the query rewrite

process to improve performance. Implementation of materialized views
will eliminate the need for end users to be aware of summary tables.
There is some degradation in performance caused by the additional
query optimization time needed for query rewrites at run time since the

optimizer must determine if a materialized view exists, if the view is up to
date, and if it can be used to satisfy the query. However, the additional
time is minimal based on the benefits associated with performance and
the reduced end user training.
Summaries will be used in some cases to support security. That is, all
users will be allowed to view aggregate data but there will be restrictions
at the student level. Materialized view created from student detail would
have the access restriction carried to the higher levels.
6.1 Discoverer End User Layer

Discoverer allows for the creation on an End User Layer (EUL) that
‘hides’ the complexity of the physical environment from most end users.
When using Oracle Discoverer, business areas are created where data
elements needed by a business process are placed in one area.
Physically, the data may be stored in multiple tables that may require
logic to tie together. This logic is predefined and will be transparent to
the end user. Of course more sophisticated end users will have full SQL
access to the database. We have decided to create a “reports summary”
for the AYP report but that table will be part of the reporting design.
Although this table can be created as part of the Discoverer EUL, we will
create the table independent of Discoverer to allow straight SQL access
to the data.

7 Database Objects
The full data dictionary is maintained in Oracle Designer and is available

in an Excel spreadsheet for general use.
7.1 Dimension Tables

TABLE DESCRIPTION NOTES
1 D_ACCESS_LEVEL Access to Achievement Aggregate Data (no
individual students identified). No sign-in is
necessary but the public will be limited to a
selected subset of reports that will appear on the

initial login page. Report menu limitations will
be controlled by portal. Data limitations will be
controlled through Virtual Private Databases
(VPD) at the database level.
2 D_ADMINISTRATION_PERIOD A component of the Time dimension. It Not all periods are month/year types.
represents the Test Administrations periods. Some are beginning, middle and end
of year.
3 D_ASSESSMENT The Assessment Dimension contains the high In moving the assessment dimensions
level descriptive information for the from logical to physical consideration
Assessments. for access and loading was made.
Due to the nature of change to items,
objectives and test areas of an
assessment set, a level of snow flaking
has been left in the model for
implementation. Also, not all
assessments have all levels. However,
the individual tables have been
flattened and repeating groups held as
sequentially numbered columns.
example: D_OBJECTIVE_ITEM holds
all items for a particular objective.
Complete flattening the dimension was
considered, however, looking at TAKS
as an example: there are 5 test areas,
each test area can have up to 10
objects (but we would leave room for
15), each objective can have 20 items
(math has up to 60 items, reading has
up to 51 items). The row would be
extremely wide and although there are
reduced joins, fewer rows can be
retrieved.
4 D_CAMPUS The Location dimension holds the descriptive Handle assessments that have
details of the District's key Locations such as unknown (Non RISD) Districts and
Campus and Area. District is the highest level Campuses, by creating rows to handle
within the Location dimension. It Represents these states. A row for Unknown
the RISD school district. Area is a level within Campus and a Row for Unknown
the location dimension. It represents the Areas District should be created. Hierarchy
within the District. The Campus is a level in the combos: RISD, Unknown Campus;
Location dimension. It represents the district Unknown District, Unknown Campus.
schools. Relationships from Facts to Location
will indicate accountability. In addition
to the location supplied by the
assessment and the student’s location,
there will be one for Campus and
District accountability. Therefore, the
Location table will require rows to
handle nonaccountable relationships in

addition to RISD locations. For
nonaccountable Campuses a Campus
of 'Non Accountable' should be setup.
For nonaccountable Districts a District
row for 'Non Accountable' should be
set up. Hierarchy combos: RISD, Non
Accountable Campus; Non
Accountable District, Non Accountable
Campus..
5 D_CAMPUS_TYPE Contains the Campus Types in the school These types should be synchronized
district. (Elementary, Junior High, High, and so in/with Locations (Campuses) and
on) Grades/Grade Groupings.
6 D_CLASS_OF This dimension descriptive data for graduation

classes. A student will be in the 'Class of' year
where the year is the expected HS graduation
year of the student.

7 D_CLASS_PERIOD The Class Period table contains descriptions of
the periods in a school day. Examples: First
Period, Second Period, and so on.
8 D_COURSE The course table contains the courses offered Although not modeled specifically,
by the District for each subject. there will be a column for each special
indicator when transformed to physical.
9 D_DISTRICT_PEOPLE This table contains the types and particulars of Teacher may also reside in this table
the people associated with the District. The
person type will determine the level of access
the person has to the data.
10 D_ECONOMIC_DISADVANTAGED
11 D_EDUCATION_GRADE The Grade Hierarchy is the upper level of the Grade was initially modeled as two sub
grade dimension. It contains groupings such as entities: Test Grade and Enrolled
Pre-K, Grade. Analysis of values and
K-12, discussions with the Assessment
Post 12, and so on. Team, allows it to be created as a
K-12 is the grouping most focused for RISD single entity (table). To avoid a more
reports. complex structure for the user, a grade
The Grade dimension contains data regarding hierarchy (balanced) of three levels is
the type of grade groupings within the District for being created. Since reports looking at
which reporting will occur. Examples are: ALL grades deal with only K-12, the
ELEM = Elementary 'ALL' level of the hierarchy for report
JH = Junior High School purposes will be created as 'K12'.
HS = High School Additional top-level nodes will exist for
Grade Grouping may be considered Campus the other grade groupings.
(School) Type.
NOTE: SDAA requires slightly different
arrangement (structure?) for its representation of
instructional grade.
The School Grade dimension contains the
Student Grade levels offered by the District.
The Grade may correspond with an equivalent
Test Grade Level.
Examples:
K = Kindergarten,
1 = First Grade
...
12 = 12th Grade.
12 D_ETHNICITY
13 D_GENDER
14 D_ITEM_RESPONSE_GROUP Contains response groupings such as 'A/F',
'B/G', and so on
15 D_LEP

16 D_OBJECTIVE_ITEM This table contains the individual items that
make up an objective. The table contains
descriptive info for the item, as well as, the
item's correct response.
17 D_PEOPLE_LOCATION_ACCESS This table is the intersect of Access Level, A person may have a different role at
People and Locations. It provides guidance as different locations.
to which people have access to which student
assessment data.
18 D_PERFORMANCE_GROUP This table holds the performance groups for Applies to TEKS. Question if applies
student results. to TAKS or other assessments.
19 D_SCHOOL_YEAR A component of the Time dimension. Frames

events by school year.
20 D_SPECIAL_ED
21 D_STUDENT This is the base Student dimension table. It Source is primarily ODS
contains the core student information for which SIS_STUDENT. Rows are also loaded

only current view is required. for assessments having unmatched
The primary source of this table is the ODS students. The column values for these
SIS_STUDENT table. Rows are also loaded for rows are derived from the assessment
assessments having unmatched students. The supplied data. The Student ID that will
column values for these rows are derived from be loaded for the dummy student rows
the assessment supplied data. The Student ID will be derived for the assessment and
that will be loaded for the dummy student rows the ODS surrogate key. The
will be derived for the assessment and the ODS assessment will provide an alpha prefix
surrogate key. The assessment will provide an that is combined with the surrogate
alpha prefix that is combined with the surrogate key. Currently, there are 12
key.. assessments so we will apply the
prefix A-L accordingly:
A=ACT
B=AP
C=ERWA
D=K2 MATH
E=LDAA
F=PSAT
G=RPTE
H=SAT
I=SDAA
J=TAKS
K=TEJAS LEE
L=TEKS
22 D_STUDENT_ACT The Student Act table contains the dimensional

data acting as the student profile as provided by
the ACT feed.
23 D_STUDENT_AP Student demographics profile as provided by the

AP data. It synchronizes with the particular
Administration of the test.
24 D_STUDENT_GROUP The Student Group entity contains attributes by Currently a super-entity of student
which students are grouped. groups. Each primary subgroup may
be implemented as individual tables.
The super entity may also be
implemented for additional flexibility.
25 D_STUDENT_PSAT Student demographics profile as provided by the

PSAT data. It synchronizes with the particular
26 D_STUDENT_SAT Student demographics profile as provided by the

SAT data. It synchronizes with the particular
27 D_STUDENT_SDAA

28 D_STUDENT_TAKS Student demographics profile as provided by the
TAKS data. It synchronizes with the particular
29 D_STUDENT_TEKS Student demographics profile as provided by the

TEKS data. It synchronizes with the particular
30 D_STUDENT_TELPAS Student demographics profile as provided by the

RPTE data. It synchronizes with the particular
31 D_TAKS_EXIT_LEVEL_STANDARD Holds the codes for the Passing Standard Maybe physical as degenerative
applied to the student’s scores. The TAKS exit- dimension.
level standard in place at the time a student P = Panels’ Recommendation
begins Grade 10 is the standard that will be 1 = 1 SEM*
maintained throughout the student’s high school 2 = 2 SEM*
career * Standard Error of Measurement

.
32 D_TEACHER This table contains Teacher information. Teacher resides in the district people
table but is currently broken out as it
has a wider use. Can be implemented
as a materialized view or as a
dimension updated after and from
district people.
33 D_TEKS_STUDENT_SCHEDULE This table contains the combination of Teacher,
Course and Period that comprises a Class. This
services the TEKS Assessment.
34 D_TELPAS_PROFICIENCY_RATING The proficiency rating levels of the RPTE

assessment.
35 D_TEST_AREA The Assessment Test Area dimension contains Currently:

the descriptive information for the Test Areas ACT: Writing, English, Mathematics,
associated with an Assessment. The Test Reading, Science, Composite
Areas may represent Subjects of a particular AP : Exam codes contain the Test
test (ACT,AP, SAT) or Screenings (ERWA) or Area (Subject)
other subject-like objects. ERWA: Reading, Writing
K-2 Math: Mathematics
LDAA: Math, Reading, Science
PSAT: Mathematics, Critical Reading,
Writing
RPTE: Reading
SAT: Verbal, Math [Writing, Essay,
MC]
SDAA: Writing, Reading, Math
TAKS: Reading/Ela, Math, Writing,
Science, Social Studies, Reading
Tejas Lee: Reading, Writing
TEKS: Reading/Ela, Math, Writing,
Science, Social Studies, Reading
36 D_TEST_AREA_COURSE
37 D_TEST_VERSION The Test Version of a given Assessment
(English, Spanish)
38 D_TIME A component of the Time dimension. It

represents the calendar dates. The Time
dimension contains the various time
components and calendars used in the data
mart.
39 D_YRS_IN_SCHOOL This table contains the Band Levels for the
number of Refer to the SLC: RPTE Cohort
results by Grade for a sample usage. years a
student is in the RISD School system.

7.2 Fact Tables
The following is a list of fact and fact history base tables. As part of the
analysis for satisfying the security requirement for accessing preliminary
assessment data, preliminary fact tables were considered. Although the
ETL code is a little more complicated and updates will take a little
longer, it was decided to include an indicator in the fact tables to decide
if the record is preliminary or final. Maintaining multiple fact tables
would have increased DBA maintenance and would potentially impact
performance.

1 F_ACT_STUDENT_RESULTS The ACT Results fact table contains the detail

facts of the ACT assessment. It has the raw
scores for each student.
2 F_AP_STUDENT_RESULTS The F AP RESULTS fact table contains the

detailed test results for a student.
3 F_ERWA_STUDENT_RESULTS The F ERWA RESULTS fact table contains the Accountability may be identified
detailed test results for a student. through relationships with Location. 1
for campus, 1 for district.
4 F_K2M_STUDENT_ITEM_RESULTS The F K2MATH RESULTS fact table contains Accountability may be identified
the detailed test results for a student. through relationships with Location. 1
for campus, 1 for district. The
sequences in the K2 Math results
tables will be synchronized with each
other. K2M_SEQ provides the
sequence and will be consistent for a
source row across TA, OBJ and ITEM
results tables.
5 F_K2M_STUDENT_OBJ_RESULTS The F K2MATH RESULTS fact table contains Accountability may be identified
results tables
6 F_K2M_STUDENT_TA_RESULTS The F K2MATH RESULTS fact table contains Accountability may be identified
results tables.
7 F_LDAA_STUDENT_RESULTS The F LDAA STUDENT RESULTS fact table Data will also be taken from TAKS,
contains the detailed test results for a student. SDAA sources, in addition to the
LDAA administered locally.
Accountability will be identified through
relationships with Location. 1 for
campus, 1 for district. Decide time
relationships

8 F_PEIMS_LEAVERS Contains the Students that have left the district This table started out as a graduate’s
and the reason as to why they left. Graduates table (F PEIMS GRADUATES) but
are designated in the Graduate Cnt column evolved to the Leavers table. The
(1=graduated, 0=did not graduate). Reason(s) for Leaving will be carried
as individual columns in the fact table
(degenerative dimension style) as
opposed to a dimension. One reason
is carried initially. If more reasons are
required, add a column for each.
9 F_PSAT_STUDENT_RESULTS The F PSAT RESULTS fact table contains the

detailed test results for a student.
10 F_RPTE_STUDENT_ITEM_RESULTS The F RPTE RESULTS fact table contains the The RPTE Proficiency rating exists at
detailed test results for a student. each level within the entity structure.
It is listed as an attribute in the item

detail but may be also held as a
dimensional key.
11 F_RPTE_STUDENT_PROF_RESULTS The F RPTE RESULTS fact table contains the The RPTE Proficiency rating exists at
detailed test results for a student. Contains the each level within the entity structure.
items counts to which the student provided It is listed as an attribute in the item
correct answers within a proficiency rating level. detail but may be also held as a
dimensional key. The relationship is
also valid for the other subentities.
Objective results are currently not
used for reporting—decide whether to
retain or not for future use. The
actually scores are for
Objective/Proficiency rating.
campus, 1 for district. No reports have
been defined for Telpas as yet, and
the RPTE reports are no longer valid.
This table will lean towards a
renormalized state until the reports are
defined. There are currently (2004) 4
positions for objectives within each
proficiency level, the 4 objective
scores will be carried on each
proficiency row. Adjustments can be
made later when use is known. The
sequences in the RPTE and TELPAS
results tables will be synchronized with
each other. TELPAS_SEQ provides
the sequence and will be consistent
for a source row across TA, OBJ and
ITEM results tables
12 F_SAT_REASON_STUDENT_RESULTS This table contains Student scores for all SAT
tests. Business Rule(s): All SAT records with a
valid Student ID will be loaded to the data
warehouse after the ODS process has cleaned
up the records using SSN, Name and date of
birth to match and find student IDs. This
generally requires a manual process that often
needs visual inspection to find some of the
students. If the record has a valid student ID, it
will only be excluded if the all test data is
missing. There may be duplicate records, they
will all be loaded using a sequence number to
make record unique.
.
13 F_SDAA_STUDENT_ITEM_RESULTS Contains student’s results for particular Accountability will be identified through
administration of the SDAA. This Fact Table relationships with Location.
contains the Student's response to the Tested Grade will be derived from the
individual test items. source field/column Instructional

Level. Instructional Level maps to the

Students Enrolled Grade as such:
If the Instructional Level is less than
the student-enrolled grade, Tested
Grade is set to the max of the
Instructional Level range. The student
is 'above grade level'.
If the Instructional Level is greater
than the student Enrolled Grade,
Tested Grade is set to the min of the
is 'below grade level'.
If the student Enrolled Grade is in the
Instructional Level range the Tested
Grade is set to the Enrolled Grade.
The student is 'at grade level'.
Examples:

Instructional Level = '3,4' -- Enrolled
Grade = 2 -- Tested Grade = 3 (above
grade level);
Grade = 7 -- Tested Grade = 6 (below
grade level);
Instructional Level = 'K,1,2' -- Enrolled
Grade = 1 -- Tested Grade = 1 (at
grade level).
The sequences in the SDAA results
other. SDAA_SEQ provides the
results tables.
14 F_SDAA_STUDENT_OBJ_RESULTS Contains student’s results for particular Accountability will be identified through
administration of the SDAA. This Fact table relationships with Location.
contains the scores for the Student at the Tested Grade will be derived from the
Subject Area Objectives level. There is a score source field/column Instructional
for each objective of the Subject Area. Level. Instructional Level maps to the
Students Enrolled Grade as such:
Examples:
grade level);
grade level);
grade level).
For Writing there are two objective
score groupings: Writing Multiple
Choice and Writing Holistic objectives.
Each has 4 objectives (currently).
The have been modeled in the
Objectives fact for SDAA.


results tables.
.
15 F_SDAA_STUDENT_TA_RESULTS Contains student’s results for particular Accountability will be identified through
administration of the SDAA. This Fact table relationships with Location.
contains the scores for the Student at the Tested Grade will be derived from the
Subject Area level. Math and Reading have source field/column Instructional
similar score structure. Writing varies for the Level. Instructional Level maps to the
other two and has additional scoring columns. Students Enrolled Grade as such:

Examples:
grade level);
grade level);
grade level).
SDAA scoring columns are listed as
attributes in this table. They are also
shown as relationships to the SDAA
Scoring dimension. When moving
logical to physical, choice the way this
will really be configured.
results tables.
16 F_STUDENT_ACCESS An interset table that contains the access
criteria to a particular students test results. Part
of the security functionality.
17 F_STUDENT_SCHEDULE In addition to tracking the student class

load/schedule, the student class table will
function in determining the level of access to the
data mart's data.
18 F_TAKS_STUDENT_ITEM_RESULTS The TAKS STUDENT RESULTS fact table 1) District_Cnt and Campus_Cnt are
contains the detailed item test results for a determined by the Fall PEIMS
student. This table holds the students COUNTY-DISTRICT-CAMPUS
responses to individual assessment items. If NUMBER versus the Student's current
the response if correct it is flagged so. COUNTY-DISTRICT-CAMPUS
NUMBER.
2) Each subsequent item number
(ITEM 01, ITEM 02 ...) will contain
Item numbers that may or may not
correspond with the column number.

The numbers contained in consecutive

item number columns may not be
consecutive:
Example: ITEM 01 = 1, ITEM 02 = 2,
ITEM 03 = 5, ITEM 04 = 11, and so on
Modeled as a super-entity. Final
structure to be determined during
logical to physical phase.
Accountability is modeled through
relationships with Location.
Modeled as sub entity, but physical
may have implementation differing.
The sequences in the TAKS results
other. TAKS_SEQ provides the

results tables.
19 F_TAKS_STUDENT_OBJ_RESULTS The TAKS STUDENT RESULTS fact table 1) District_Cnt and Campus_Cnt are
student. Contains the student’s results at the COUNTY-DISTRICT-CAMPUS
objective level. NUMBER versus the Student's current
COUNTY-DISTRICT-CAMPUS
NUMBER.
consecutive:
results tables.
.
20 F_TAKS_STUDENT_TA_RESULTS The TAKS STUDENT RESULTS fact table 1) District_Cnt and Campus_Cnt are
student. This table contains student results at COUNTY-DISTRICT-CAMPUS
the TAKS Subject Area level NUMBER versus the Student's current
COUNTY-DISTRICT-CAMPUS
NUMBER.
consecutive:


2 years of TAKS (50k rows) in the
ODS consumes approximately 72MB,
a third year is estimated to require an
additional 36M. 13 years projects to
over 4M rows. Initial sizing will be
100M for this fact.
results tables.
21 F_TEJAS_LEE_STUDENT_RESULTS The Tejas Lee Student Results fact table Accountability can be identified
contains the detailed item test results for a through relationships with Location. 1
student. for campus, 1 for district.

22 F_TEKS_STUDENT_ITEM_RESULTS The F TEKS STUDENT RESULTS fact table Accountability will be identified through
contains the detailed item test results for a relationships with Location. 1 for
student. This table holds the students campus, 1 for district.
responses to individual assessment items. If
the response if correct it is flagged so.
23 F_TEKS_STUDENT_OBJ_RESULTS The F TEKS STUDENT RESULTS fact table Accountability will be identified through
student. Contains the student’s results at the campus, 1 for district. The sequences
objective level. in the TEKS results tables will be
synchronized with each other.
TEKS_SEQ provides the sequence
and will be consistent for a source row
across TA, OBJ and ITEM results
tables.
24 F_TEKS_STUDENT_TA_RESULTS The F TEKS STUDENT RESULTS fact table Accountability will be identified through
student. campus, 1 for district.
25 F_TELPAS_STUDENT_RESULTS The RPTE Proficiency rating exists at

The F RPTE RESULTS fact table contains the
each level within the entity structure.
detailed test results for a student. Contains the
It is listed as an attribute in the item
student results for the TELPAS assessment.
detail but may be also held as a
Additional results are found in the RPTE results
tables. dimensional key.
The relationship is also valid for the
other sub entities.
Objective results are currently not
used for reporting - decide whether to
retain or not for future use. The
actually scores are for
Objective/Proficiency rating.
campus, 1 for district.
The sequences in the TELPAS/RPTE
results tables will be synchronized with
each other. TELPAS_SEQ provides
the sequence and will be consistent
for a source row across TA, OBJ and
ITEM results tables.
26 FH_ASSESSMENT_ADMINISTRATION Contains the Administration Schedule for each If the accountable flag is set ('Y'), the
Assessment. It also notes the Assessment administration is used for
Administration that is designated the accountability reports. This may
Administration used to trigger accountability. require a maintenance for to enter new
assessment administrations. (can use
SQL) Although denoted as a fact table
this may also function as a dimension

28 FH_STUDENT_HISTORY The student history table acts as a slowly Since this table has dimensional
changing dimension for a particular student. functionality in the model, it will carry
This table tracks key changes of critical student it's own independent primary key
information used in district and campus (surrogate). A unique key consisting
reporting. of a subset of the foreign keys will be
selected (student/calendar date is the
current expectation).

7.3 Summary Tables
The following is a list of aggregate tables that will be implemented as
summaries or materialized views. Additional views and or summaries
will be created during development for performance reasons.
1 FS_ACT This is the ACT summary fact table/view. It

contains key measures (facts) that are calculated
at the Assessment level.
2 FS_AP This is the AP summary fact table/view. It contains

key measures (facts) that are calculated at the
Assessment level.
3 FS_ERWA_RESULTS This is the ERWA summary fact table/view. It

4 FS_OBJECTIVE_ITEM This table contains a summary of each test items

correct response and the count of students
answering correctly.
5 FS_SAT_REASONING This table contains single year summaries for the

year's monthly administrations. Contents
summarize the highest SAT score for Graduates.
6 FS_SDAA This is the SDAA summary fact table/view. It

7 FS_TEJAS_LEE_RESULTS

7.4 Other DW Tables
The following is a list of other table needed to support DW processing.
1 RISD_ACCOUNTABILITY_MIN_SIZE This table contains the minimum assessment

population required for accountability reports.
2 RISD_OP_PARMS Contains target scores used in calculating SAT The parameter type will determine
metrics. which value column is populated.
Contains target scores used in calculating AP
metrics.
Contains target scores used in calculating ACT

metrics.
Contains target scores used in calculating ERWA
metrics.
This table contains the operating parameters used
by the Assessment Warehouse for processing
data and running reports.
3 DW_CODES
4 DW_CODES_TRANSFORM
5 DW_ETL_CONTROL Audit table for ETL processes.
6 DW_ETL_PROCESS
7 DW_FACT_AUDIT Contains audit columns that will be included in

each fact row when moved to physical.
7.5 Sample DDL to Create Data Warehouse Indexes

The following is a sample list of the DDL generated from Oracle
Designer to create Data Warehouse indexes.
-- C:\Projects\Roy\dwcutX\DWRISD.ind
--
-- Generated for Oracle 10g on Mon May 02 17:02:04 2004 by Server
Generator 9.0.4.5.6
PROMPT Creating Index 'FA_LEP_FK_I'

CREATE BITMAP INDEX FA_LEP_FK_I ON FS_ACT
(LEP_ID)
PCTFREE 10
STORAGE

(
INITIAL 10K
NEXT 2K
)
TABLESPACE DWI
/
PROMPT Creating Index 'FA_AP_FK_I'

CREATE BITMAP INDEX FA_AP_FK_I ON FS_ACT
(ADMIN_PD_ID)
PCTFREE 10
STORAGE
(
INITIAL 10K
NEXT 2K
)
TABLESPACE DWI

/

8 Sample Database Definition Language (DDL)
The DDL to create DW base tables was created from Oracle Designer.
The DDL was used to create the data warehouse physical tables. The
data warehouse and ODS metadata was imported into Oracle
Warehouse Builder (OWB) for use in mapping source to target elements.
Importing the metadata saves times and avoids typing errors.
Below is sample DDL that has been included in this document for
illustration purposes.
-- C:\Projects\Roy\dwcutX\DWRISD.tab
--
-- Generated for Oracle 10g on Mon May 02 17:02:03 2004 by Server

Generator 9.0.4.5.6
PROMPT Creating Table 'FS_ACT'

CREATE TABLE FS_ACT
(ADMIN_PD_ID NUMBER NOT NULL
,ASMT_ID NUMBER NOT NULL
,CAMPUS_ID NUMBER NOT NULL
,ETH_ID NUMBER NOT NULL
,GENDER_ID NUMBER NOT NULL
,INTERVAL_ID NUMBER NOT NULL
,SED_ID NUMBER NOT NULL
,SES_ID NUMBER NOT NULL
,SG_ID NUMBER NOT NULL
,LEP_ID NUMBER
,GRAD_CNT NUMBER
,TESTED_CNT NUMBER
,TESTED_PCT NUMBER
,AT_OR_ABOVE_CNT NUMBER
,AT_OR_ABOVE_PCT NUMBER
,MEAN_ACT NUMBER
,AGGREGATE_ACT_SCORE NUMBER
,STATUS_CODE VARCHAR2(1)
,CREATE_DATE DATE NOT NULL
,CREATE_BY VARCHAR2(30) NOT NULL
,UPDATE_DATE DATE
,UPDATE_BY VARCHAR2(30)
)
PCTFREE 10
STORAGE
(
INITIAL 10K
NEXT 2K
)
TABLESPACE DWD
/
COMMENT ON COLUMN FS_ACT.ASMT_ID IS 'Assessment (Test) primary key

(surrogate).'
/
COMMENT ON COLUMN FS_ACT.ETH_ID IS 'Student Group ID. primary key'

/

COMMENT ON COLUMN FS_ACT.GENDER_ID IS 'Student Group ID. primary key'
/
COMMENT ON COLUMN FS_ACT.SED_ID IS 'Student Group ID. primary key'

/
COMMENT ON COLUMN FS_ACT.SES_ID IS 'Student Group ID. primary key'

/
COMMENT ON COLUMN FS_ACT.SG_ID IS 'Student Group ID. primary key'

/
COMMENT ON COLUMN FS_ACT.LEP_ID IS 'Student Group ID. primary key'

/

M6_RISD_DW_architecture_v3.0.doc
TA.010 RISD DATA WAREHOUSE

ARCHITECTURE

Data Warehouse Infrastructure
Authors: Oracle Consulting

Creation Date:
Last Updated:
Version: 3.0
Approvals:
RISD Technical Architecture
Document Control
I. Change Record

Version

II Reviewers
Name Role Version Date
III Distribution
1 Library Copy
2
Data Warehouse Infrastructure Page 2

Contents
Document Control...............................................................................2
I. Change Record............................................................................2
II Reviewers .....................................................................................2
III Distribution...................................................................................2

1.0 Introduction .....................................................................................5
1.1 Background................................................................................5
1.2 Purpose .....................................................................................5
1.3 Related Documents ...................................................................6
2.0 Technical Architecture Options .......................................................7
2.1 Low Cost Open Source Architecture..........................................7
2.2 Multi-Machine Data Warehouse Solution...................................7
2.3 Traditional Data Warehouse ......................................................7
2.4 Conclusion .................................................................................8
3.0 RISD Functional Architecture Approach........................................10
3.1 Data Modeling and Database Design ......................................12
3.2 Oracle Designer.......................................................................12
3.3 ETL Components.....................................................................13
3.3.1 Assessment Processing.................................................................................... 13
3.3.2 SIS Processing ................................................................................................. 13
3.3.3 Reference Table Processing ............................................................................. 13
4.0 Technical Requirements................................................................14

4.1 Oracle 10g Data Warehouse Features ....................................14
4.2 Oracle 10g Setup Tasks ..........................................................16
4.3 Oracle Instances......................................................................17
4.4 Development vs. Test vs. Production Environments................17
4.5 Source to Target data mapping ...............................................18
4.6 Capacity Plan (Data Storage) ..................................................18
4.7 Disaster Recovery ...................................................................18
5.0 Data Acquisition Approach ............................................................19
5.1 Oracle Warehouse Builder (OWB)...........................................19
5.2 Data Extraction ........................................................................19
5.3 Data Cleansing: .......................................................................20
5.4 Data Movement: ......................................................................20
5.5 Data Enrichment: .....................................................................20

6.0 Operations, Administration and Maintenance (OAM) ....................21

6.1 Job scheduling and monitoring ................................................21
6.2 Oracle Enterprise Manager (OEM) ..........................................21
6.3 Metadata Administration ..........................................................23
6.4 Oracle Designer.......................................................................23
6.5 Metadata Capture: ...................................................................23
6.6 Metadata Update: ....................................................................23
6.7 Metadata Sharing: ...................................................................24
6.8 Metadata Publishing: ...............................................................24
6.9 Security Administration ............................................................24
7.0 Changes and Updates to the Data Warehouse.............................25
8.0 Backup and Recovery ...................................................................27
9.0 Purge, Archival and Restore .........................................................28

Appendix A - ETL and Data Quality Overview.....................................29
Appendix B - Metadata Management Overview ..................................30
Appendix C – Data Acquisition Components - OWB Overview ...........33

1.0 Introduction
1.1 Background
The RISD Data Warehouse environment will provide decision makers throughout the District with
information to help improve student achievement. Users will access the system via Windows based
Internet-capable computers to accommodate the needs of both computer novices and experts. Data
that is currently processed independently in multiple “applications” will be integrated into a single
environment to facilitate data reporting and analysis across test areas.
Discoverer report data will be available online and can be downloaded into local applications where
appropriate (for example, spreadsheets and PC databases) to perform additional analysis or for
integration with local data. Phase I will primarily focus on student assessment data.
User groups will be restricted to accessing information associated with their responsibilities, needs,
and skills. The majority of end users will run parameter driven reports to obtain multiple views of the
assessment data. Dashboard reports will provide summarized tabular and/or graphical information to

various user groups. The system is designed so RISD can develop relevant reports as new data
becomes available. Some power users will go directly to Discoverer Plus to run reports and create
new reports on an “as needed” basis while most users will use Discoverer viewer to run the
parameter driven reports and/or view static standard reports
1.2 Purpose
The Technical Architecture Document describes all Development, Test and Production components,
including the hardware, platform, software versions, set up configurations and development
repositories. This document defines the RISD Data Warehouse architecture including the Extract,
Transform, and Load (ETL) tools needed to implement the defined architecture, along with the tools
needed to access and support the environment. The architecture must support requirements
gathered through interviews and work sessions with the technology staff and the review of existing
and proposed technical and infrastructure documentation. This analysis provides RISD with a clearly
defined guide to the data warehouse solution from both a business and technical standpoint that can
be incrementally implemented.


The technical architecture document provides an opportunity to clearly define the infrastructure
needed to support the RISD Business requirements using the Report Requirements, Portal Security
Requirements, and the Data Model documents that defines the Phase 1 project scope.
• Milestone 1, Project Management Plan – Baseline plan in Microsoft projects with accompanying
project management plan (PMP) document.
• Milestone 2, RD.049 Report Requirements Document – Clearly defines the reporting
requirements in the 12 priority Assessment areas implemented for Phase 1.
• Milestone 3, RD.049 Portal Security Requirements – Data Warehouse Portal Security Design
Document describes the functionality of the Portal pages required to support the highest priority
Data Warehouse reports and Dashboards. The look and feel, navigation colors and graphics are
not part of these requirements and only the Data Warehouse page content, report links and how
roles determine geographic defaults will be included.
• Milestone 4, Logical Data Model – Logical Data Model Design contains all the entities (facts,
dimensions and measures) to deliver the report requirements. The actual design will be

contained in the Designer Repository.
• Milestone 5, MD.040 Physical Data Model – The Physical Data Model Design contains all the
tables, indexes, partitioning, and parameters needed to define the data warehouse objects and is
documented in Oracle Designer.

2.0 Technical Architecture Options

Database read operations requirements drive the technical architecture in a data warehouse
environment. Of course, write operations, which usually occur only during the load process, must be
considered and some data access compromises might have to be made to accommodate database
availability and data integrity during the update window.
In this section, three alternative hardware configuration approaches are discussed. RISD uses HP
hardware and the hardware platform has been selected. However, this section is included for
general information.
1. Low Cost Solaris Open Source Multi-Machine Data Warehouse Solution - Multiple smaller
commodity machines using off-the-shelf Intel devices possibly connected to a Storage Area
Network (SAN)
2. Multi-Machine Data Warehouse Solution - Multiple smaller machines used in an Oracle 10g
Real Application Cluster (RAC) environment possibly connected to a Storage Area Network
(SAN)

3. Traditional Data Warehouse Solution - Standard data warehouse machine with multiple CPUs
and up to 16 GB memory connected to a dedicated storage array sub-system
Assumptions:
1. The Oracle DBMS 10g will be used.

2. Only RISD approved hardware and software may be used in any front-end access
architecture implemented and maintained by the RISD staff.
3. RISD is an Oracle shop and has a campus wide license.
4. RISD has selected Oracle Discoverer as the front-end data access tool.
2.1 Low Cost Open Source Architecture
A low cost Linux open source environment using Intel-based servers is one cost effective alternative
for back end database processing. Low cost commodity processors, memory, and components can
be used and are available in adequate volumes at reasonable prices from multiple vendors. Industry
analysis has shown that these environments can offer an initial savings over more traditional lower-
end and mid-range architectures.
Oracle Consulting has worked with multiple vendors including Dell and Compaq to certify standard
configurations. Oracle Hosting has most recently been using Dell hardware running under Linux
using Real Application Clusters (RAC) technology to reduce costs for clients who prefer to have
Oracle host their database applications.
2.2 Multi-Machine Data Warehouse Solution

Multiple smaller less costly machines can be combined using Oracle software to potentially reduce
the costs over purchasing a single larger machine. Currently, Oracle 64 bit version RAC is certified
on multiple platforms including HP.
2.3 Traditional Data Warehouse

The traditional data warehouse approach is used by many production data warehouse environments
and is the most conservative time tested approach. This is generally the most conservative but costly
approach.

2.4 Conclusion
The total cost of ownership, which includes maintenance and support, available resources, and the
need to incorporate additional applications in the future drove the RISD solution to select the multi-
machine data warehouse solution.
The following outlines the RISD production environment
Environment Description
Database Server • 2 HP DL 585 Processors at 2.6 GHZ
• 4 CPU per processor
• 16 GB of Memory
OID Server • 2 HP DL 385
• 2 CPU
• 2 GB Memory
Server Storage (shared testing • HP EVA 50002
and • 2 HPA (Fiber Channel Connections to HP
production SAN)

SAN EVA5000)
• 48 – 146 GB drives use for the databases
• 16 Two hundred fifty GB drives used for
snapshots, backups, and SQL loads
• 16 – 72 GB Drives – used for database
logs
Network • The RISD DW is an Internet-based
application and requires Internet
connectivity
Desktop • Intel Base Windows
• Microsoft Internet Explorer (IE)
• VPN Internet connection via LAN or
modem
Software • Oracle OID (10.1.2 with DBMS
10.1.0.3.1))
• Oracle AS10g (10.1.2)
• Oracle 10g DBMS (10.2.0.3)
• Discoverer 10g (10.1.2)
• OWB 10g (10.1.0.3)
• Designer 10g (9.0.4.5.6)
The remainder of the DW environment includes:
ODS – there will be three instances on the single ODS machine – Development, Test, and
Production. Currently, the ODS uses disk drives directly connected to the ODS machine. In the
future, ODS information may be moved to the common SAN devise. Edbert, the name of the ODS
server, has 3.06 GHz w/2,096,666 KB RAM and a 448 GB disk (330 GB of free space).
DW Development – The DW will have its development and test environment on a separate test
machine with attached storage.
• 4 - HP ProLiant DL360 G4 Servers
• All with dual P4 Xeon 3.6GHz/1MB cache processors
• The 2 App servers have 2GB RAM and 2 - 72GB 15k mirrored drives
• The 2 DB servers have 4GB RAM and 2 146GB 10k mirrored drives
Portal Server – The HB25 blade server will have eight slots available for load balancing access to the
new SIS and DW environment.

The following diagram shows a high level representation of the production environment.
Note: See Appendix D for more detail on the portal architecture.

3.0 RISD Functional Architecture Approach
This section describes the major components of the proposed Business Intelligence architecture
needed to support RISD business needs. The creation of the data model, which incorporates the data
access requirements, documented in the requirements document drive the physical database design.
The next step in the process identifies source elements and maps them into the data model elements
that will becomes rows in the data warehouse tables (see section 4, Technical Requirements). The
final step captures the Extract, Transform and Load (ETL) processes of the database update design.
The physical architecture needs to support both the backend database processing as well as front-
end access requirements with all associated network links. The final selection was based on several
factors including:
• Total cost of ownership.
• The ability to meet growth projections (Scalability).
• The ability to satisfy system requirements and constraints.

The diagram below outlines the functional flow.
RISD Functional DWUpdate Processing
Conversion Files
RIMS ACCESS
PEIMS EDSOFT HR
Database
Internal RISD~ Process

Schedule
Corrections
State & Unmatched
Assessments Periodic ODS Mark as ready
Local ` Student Detail
To load
Loads
District District
Assessment Periodic Updates Assessment Team
Team & Summarizations DW
Staging
objectives
Data Discoverer Plus

Warehouse DWAccess
Power User
Home Page
Public or District
Employee

3.1 Data Modeling and Database Design
Data modeling uses the outputs of the requirements gathering, documented in the requirements
document to answer the following fundamental questions:
• What data elements must be available in the warehouse?

• Where will the data elements come from (what is their source)?
• What do the data elements mean?
• How do the data elements relate to each other?
• How will the data elements identified in the source system move to the warehouse?
• How will the data elements be seen and interpreted by the end-users?
• At what level of detail/granularity will data in the data warehouse be maintained?
• How much history is needed in the data warehouse?
• How frequently will data in the data warehouse be added, updated, or refreshed?
The answers to these questions are formulated and encapsulated into a “Data model.” A data model
is an expression of the business objects needed to support priority business processes in graphical

and textual format. The data model identifies each significant business object within the context of
RISD business operations. The interrelationships between and among business objects are
documented by the fundamental business rules stored in the data model. Data warehousing
designers carefully apply dimensional modeling techniques to ensure the data warehouse design
reflects the way RISD employees need to access data to improve student development. This
provides RISD analysts with the ability to analyze of data to help improve student assessment
evaluations.
3.2 Oracle Designer
RISD has chosen Oracle Designer for data modeling since the generic K-12 data model was
available to RISD in a Designer repository. The following tasks were performed using Oracle
Designer:
• Update the functional data model to meet RISD requirements.

• Expand the Logical model to support RISD specific data warehouse needs.
• Create the Physical data model using the updated Logical Data Model (LDM).
• Create the Data Definition Language (DDL) scripts needed to create the data warehouse
physical database, including bitmap indexes and foreign keys in the fact table that point to
dimension tables.
• Create the constraints and surrogate keys.
• Facilitate repository administration of the data warehouse including the creation of users and
the issuance of privileges to access data warehouse objects.
The Oracle Data modeler used Oracle Designer and the inputs from the reporting and security
requirements to create the updated logical graphical entity-relationship diagram (see data model).
The functional model defines the data entities and establishes the relationships between and among
these entities. The updated functional model led to the creation of the Logical Data Model (LDM),
which shows how data from multiple entities can be accessed to provide the necessary data to high
priority reporting and analysis processes. The data modeler ensures that data needed by the
business processes can be accessed through the LDM. The final step is the creation of the Physical
data model where entities are collapsed or expanded into physical tables and foreign key
relationships and constraints are created as needed. The physical model expands the LDM
requirement of being able to access the data to ensure data is physically arranged in the best way to
satisfy the business requirements. The steps needed to create the physical model are important to
understand since the physical data model along with historical data requirements will drive the design
of the technical architecture.
The remainder of this section discusses how Oracle Designer was used to create the physical data
model. The Repository Object Navigator was used to create a new application with the Data
Warehouse Type Property set to ‘Yes’. The data warehouse flag on the application system indicates
to Oracle Designer that validation must be performed on the design to ensure that it conforms to a

star/snowflake model commonly used in a business intelligence design. This flag also ensures that
default values suitable for data warehouse designs are presented when elements are created in the
Repository.
Entities can only be created as either ‘fact’ or ‘dimension’ using the Data Warehouse Type property.
The Database Transformer uses this information to create corresponding fact or dimension tables in
the Repository. For each entity that is implemented as a fact table, the transformer creates a
BITMAP index for every Foreign Key pointing to a dimension table. For each logical model, a Server
Model Diagram is created. In the server model diagram, the tables that will be implemented and the
relationships between and among them are identified. All data objects defined in the RISD
Warehouse Architecture will be modeled in Designer before being physically implemented. This
allows changes to the physical model during the build process as constraints and more detailed
access needs are defined without impacting the overall architecture described in this document.
That is, we have enough information to create the business intelligence architecture without locking
into a final database design.
3.3 ETL Components

An Extract, Transform, and Load (ETL) tool that integrates well with the Oracle DBMS and Oracle
designer is Oracle Warehouse Builder (OWB). Detailed information associated with OWB is included
in the appendix.
The ETL process will have three major components:

• Assessment Processing
• Student Information System (SIS) Processing
• Reference Tables Updates
3.3.1 Assessment Processing
Assessments will be loaded into the Operational Data Store (ODS) as files become available. A
matching process will append the RISD student ID to all records. Records that do not match will be
sent to a correction file that will be used by the RISD assessment team to determine the proper
student id. Records that cannot be assigned a RISD id will be set to null.
The data warehouse will have an automated process that will run nightly to process any new
assessment files available in the ODS. The assessment team will also have the ability to initiate the
process immediately. The initial process will run in preliminary mode and only the assessment team
will have the ability to view the data and run reports.
When the assessment team is satisfied with the results, the assessment is set to final, and all users
will have access to the data and the reports.
3.3.2 SIS Processing
Student data will be updated nightly in the ODS from RIMS data. The data warehouse will run a
process that will update all records that have changed since the last DW update.
3.3.3 Reference Table Processing
Updating of reference tables will work in a similar manner as the assessment files. Data will be
checked nightly for changes but the assessment team will have the ability to run the process at any
time.

4.0 Technical Requirements

Along with the Physical Data Model, budget constraints, RISD standards, and total cost of ownership,
historical data requirements drive the creation of any technical architecture. For example, the
business benefit of maintaining a full thirteen years of student history versus less history could affect
hardware decisions. Of course anticipated growth is a major input to ensuring a scalable
architectural solution. In the case of RISD, with approximately 35,000 students, keeping history for
up to 13 years does not cause a major storage issue. Most reporting is done on the current year
student data with many reports showing 3-year trends. However, it is anticipated that trending
reports tracking students through their entire school life at RISD will be more common as additional
data is accumulated. The initial conversion will store up to 3 years of assessment data in the data
warehouse.
4.1 Oracle 10g Data Warehouse Features
Oracle 10g will be used as the database manager. Some Oracle 10g Self Managing features:
Built-in Intelligent Infrastructure

• Code instrumentation
• Workload repository
Automation of Routine Tasks

• Automatic disk-based Backup and Recovery
• Automatic optimizer statistics collection
• Automatic Memory Management
• Automatic Storage Management
Tools to empower the DBA

• Automatic Database Diagnostic Monitor
• Automatic Tuning Optimizer
This section documents some of the features that will be used in the implementation of the Oracle
database tables. Oracle9i and 10g has been optimized quite ostensibly for business intelligence
applications. By integrating technologies such as parallel queries, bit map indexes, parallel bit-
mapped star joins, materialized views, and transportable tablespaces into the database engine,
Oracle 10g provides the needed flexibility to meet RISD current and future needs. The choice of
Oracle 10g minimizes implementation risks since Oracle 10g is a fully tested, industrial strength
database engine used in over half of all Data Warehousing solutions.
Data Partitioning
Oracle’s dynamic partitioning provides parallelism for performance. Oracle’s partitioning option
enables data partitions based on clear business value ranges for administrative flexibility and
enhanced query performance through partition elimination. As an example of administrative
flexibility, consider the common data warehousing requirement for “rolling window” operations -
adding new data and removing old data based on time. Oracle’s partitioning will allow RISD to add a
new partition, load and index it in parallel and optionally remove the oldest partition, all without any
impact on existing data in other partitions and with uninterrupted access to that data. The
combination of dynamic parallelism and independent data partitioning will give RISD the ability to use
partitioning for efficient data management without dictating and limiting parallelism. Thus, the
administrative burden of managing partitions that can become unbalanced due to unanticipated
growth is avoided. Hash partitioning is also supported in Oracle and can be implemented in order to
spread data evenly based on a hash algorithm for performance. Hashing may be used in conjunction
with range partitions (composite partitioning) to maintain manageability while increasing performance.
Because of the initial relatively small volumes, data partitioning may not be used.

Complex Multi-table Join Processing

In addition to traditional nested loop and sort-merge joins, Oracle extends server functionality to
include star join optimization for complex star schemas using a unique bit-mapped indexing
technique, hash joins and anti-joins (queries containing a “not in” phrase). When combined with
Oracle’s parallel and partitioning capabilities, these join techniques allow certain complex queries to
experience very large performance improvements. Oracle’s cost-based optimizer takes into account
all of these features to provide the best performance across a broad range of schema designs and
queries. The RISD Warehouse Architecture will use the Cost-Based optimizer. After each controlled
data load into the data warehouse, statistical analysis will be run by the ETL process using the
“Analyze Table/Index” functions of Oracle 10g. The optimizer will use these statistics to create
efficient data access execution plans.
Bitmap Index Technology

Bitmap indexes are an indexing mechanism first introduced back in Oracle7. They are used for
specific e-business intelligence transactions and can result in dramatic performance acceleration for
low cardinality data. These indexes enjoy a tight integration in Oracle 10g core functionality with

traditional b-tree indexes. The bitmaps stay synchronized through INSERT, UPDATE and DELETE
operations.
Bitmap Pre-Join Index Technology

Bitmap pre-join indexes are an indexing mechanism first introduced back in Oracle 9iR2. They are
used for specific e-business intelligence transactions and can result in dramatic performance
acceleration for low cardinality data. These indexes enjoy a tight integration in Oracle9i and 10g core
functionality with traditional b-tree indexes. The bitmaps stay synchronized through INSERT,
UPDATE and DELETE operations. Pre-join indexes are suitable for data that does not change
frequently. This feature allows us to include the row ids from multiple tables in one index. When this
feature is used, it eliminates the time needed to join tables at execution time.
Oracle Managed PGA Technology

The Oracle managed PGA feature allows you to specify a large amount of memory as a percentage
of total system memory. All users’ connections to the system share this memory. This results in more
memory that can be used by an individual process and thus speeds up joins and sort operations. It
also minimizes the amount of time a DBA needs to spend tuning memory on a system.
Locally Managed Tables Spaces

Oracle 9i provided locally managed tablespace with Oracle 10g expanding this functionality. The
locally managed tablespace feature frees the DBA from having to pre-allocate and manage extents.
Locally managed tablespaces are more efficient than dictionary managed tablespace and can result
in a ten to fifteen percent improvement in insert performance.
Oracle Managed Temporary Space

Oracle 9i provided for system managed temporary space. The improvements made in Oracle 10g
results in better performance and less manual intervention by the DBA monitoring the free space
used to sort large objects.
Row Level Security

Oracle 9i introduced fine-grained access or Virtual Private Databases (VPD) security that has been
improved in Oracle 10g. This allows us to implement security at a row rather than an object or table
level. This security is implemented in the database and does not require applications code to be
written. Since it is implemented at the database level, all users will be secured, even those
bypassing the application layer.

Partition Elimination Feature

The partition elimination or partition pruning feature implemented by the Oracle optimizer enhances
performance by not accessing partitions that do not contain relevant data. This enhances
performance by eliminating unnecessary data access.
Direct Loading of Data from Disk

Oracle 9i and 10g provides the ability to access data on disk through a standard SQL or PL/SQL
interface. This eliminates the need to first load data into staging tables and improves performance by
eliminating a step in the ETL process. This can dramatically cut load times by eliminating up to half
the processing time.
Aggregation, summarizations, and materialized views

Oracle8i introduced the ability to generate materialized views for creation of summary tables and 9i
and 10g significantly increased materialized view effectiveness. The query optimizer can perform
query rewrites that access these summary tables instead of using base tables. That is, the end user

does not have to be aware of the summary tables to obtain better performance. This results in
dramatic increases in performance while the summary advisor provides guidance to the DBA on the
usage of existing tables and may recommend the creation of new materialized views.
Further aiding in the creation of such tables is the capability of creating dimensions and hierarchies
within Oracle 10g. These dimensions enable additional query rewrites for summaries and can be
used by OLAP tools. Also, CUBE and ROLLUP operators were added to Oracle8i and expanded in
Oracle 9i and 10g through Business Intelligence (BI) Beans to help reporting and analysis as well as
help developers perform OLAP style aggregation more efficiently.
4.2 Oracle 10g Setup Tasks
1. Determine Disk striping approach based on the Table space sizing information.
2. Confirm recommeneded mirroring approach of using Raid 0+1. (Raid 5 is an option but RISD will
use full mirroring)
3. Standard weekly full backups with daily incredmentals will be available.
4. Obtain and install all the Oracle patches needed for Oracle 10g.
5. Install Oracle instances based on the recommendation in this document.
6. Maintain naming convention standards.
7. Determine the capacity plan and rollback management strategy for the database.
• Determine partitioning strategy
• Compression: Oracle9i Release2 and higher compresses data by eliminating duplicate
values in a database block. Compressed data stored in a database block (a.k.a. disk page) is
self -contained. That is, all database features and functions that work on regular database
blocks also work on compressed database blocks
8. Determine the Oracle database parameters
9. Use Oracle’s Optimal Flexible Architecture (OFA) to setup the Oracle 10g Database layout.
Oracle Corporation recommends that the OFA standard be implemented when installing and
configuring Oracle 10g databases.

4.3 Oracle Instances
RISD will use a single instance for the production data warehouse on a production machine. The test
machine will support both a development and test instance using direct access disks or with a section
of the HP SAN allocated to the separate development, test, and production instances. Oracle
recommends creating a single instance since it is the easiest environment to maintain and the most
cost effective initial configuration.
Instances Pros Cons

One Single • Reduces the load on the server • Single point of failure
instance • Easier to manage backup & recovery • When doing patching or other
which lowers overall costs critical maintenance, the entire
• Reduces the overall patching time instance has to brought down so
since only one instance is no data is available to business
maintained. users
.

4.4 Development vs. Test vs. Production Environments
There are three independent environments that need to be maintained in the RISD data warehouse:
Development (DEV), Test (TEST), and Production (PROD). Each environment will have its own
directories, profiles and database instances. DEV and TEST will reside on a different box than
production while PROD resides on its own machine. There will also be a common place for storing
tools such as OWB and Oracle Enterprise Manager (OEM). The tools will be installed in an area
where DEV, TEST, and PROD can share a single set of tool repositories. However, Development,
Test, and Production will all have their own OWB repositories (one development and one run time
repository in each environment). An option is to create separate projects within the same OWB
repository.
During the life cycle of the RISD warehouse, these three independent environments can be tightly
coupled by sharing the OWB repository. All new developments and changes to the data warehouse
will be made in the DEV project and tested on the DEV environment first.
The key to maintaining the three environments is to propagate the changes in one environment to
another environment. As an example, when the DEV project is changed in OWB, the updated parts in
the DEV project will be exported to a file and then imported to the TEST project in OWB. Then the
TEST project will capture the changes and apply them to the TEST environment using OEM/CM
(Warehouse Upgrade).
All testing, such as any functional tests, stress tests, and user acceptance tests will be done in the
TEST environment, and errors and issues will be fed back to the DEV environment, where DEV
propagates a new version with the modification to TEST and so on. When the change is accepted in
test, the change is propagated from TEST to PROD.
Many versions of the OWB repository will be needed during the life cycle of RISD warehouse. Each
version will represent a static snap shot of the PROD environment OWB metadata prior to the
application of any modifications. Obviously, there must be a way to keep track of the versions and
restore any version if needed.
OWB uses its Project Archive/Restore Utility by using a file-based approach to store archival
information about the various projects defined within the ETL tool. The metadata in the OWB
repository is saved in the file system and restored from the file system when needed. Thus, the OWB
repository can be well protected by combining OWB and some file-based versioning control system
such as PVCS.

4.5 Source to Target data mapping

The success of the data warehouse depends largely on the ability to obtain valid and cleansed data
elements from the system of record. The data model outlines the data entities and elements needed
to support high priority reporting and analysis processes. The data model also defines the
relationships between and among these data entities. Data elements (or attributes) were assigned to
the data entities of common business data groupings. The next step in the design process identifies
the source system of data elements needed in the warehouse and map these elements into the data
warehouse elements. In our case, all data will be staged in the RISD Operational Data Store (ODS).
The mapping of ODS elements to DW elements includes any transformation needed to validate these
elements and ensure data integrity among the data warehouse elements.
The mapping will be documented in OWB while the business rules will be documented in Oracle
Designer.
4.6 Capacity Plan (Data Storage)
RISD has acquired up to 1.8 TB of usable storage to be shared between the new Student Information
System (SIS) and the Data Warehouse. There is additional space allocated for backups and system

log files.
4.7 Disaster Recovery

In case of disaster, the data warehouse would not have priority over operational systems. The data
warehouse is a reporting and analytical system and does not process transactions critical to RISD’s
short-term survival. Nevertheless, in the event of a power failure, hardware failure, fire, flood, or any
other system-interrupting disaster, the data warehouse will need to be recovered at some point. The
only way to ensure a relatively rapid recovery from a system failure or other disaster is to plan
carefully. Normal recovery time should be less than 24 hours while a true disaster like a destroyed
data center should be in the 7 to 14 day range (or longer). Regardless of the technology, there must
be a detailed plan with clearly defined procedures to deal with the event of a catastrophic failure.
Every enterprise should have a disaster recovery plan to protect its core business in case of a
catastrophe. The disaster recovery plan for the RISD data warehouse must be considered as a
component of the district’s disaster recovery plan.

5.0 Data Acquisition Approach

The Extraction, Transformation and Loading (ETL) functionality is core to any data warehouse
architecture. It is the most time and resource consuming part of any data warehouse initiative. ETL
tools can help developers accomplish this complex task. These tools have also evolved into a
significant storehouse of metadata. This section describes the ETL approach for the RISD
Warehouse Architecture.
5.1 Oracle Warehouse Builder (OWB)
The ETL approach recommended for the RISD Warehouse Architecture uses Oracle Warehouse
Builder (OWB) 10g. Oracle Pure*Integrate, included with OWB, may be used for matching if more
sophisticated match logic is required in the future. See Appendix C for an overview of OWB
functionality.

Oracle Warehouse Builder (OWB) Graphical User Interface (GUI) offers the power of a fully
functional ETL platform combined with mature metadata management capabilities. In the RISD
Warehouse Architecture OWB serves as the ETL tool as well as the central metadata management
tool providing capabilities such as:
• Wizard based Tools Integration through Common Warehouse Meta model Interchange
• Data Lineage and Impact Analysis Functions
• Metadata Updating
• Metadata Sharing
• Graphical Data Mapping
• Data Load Auditing and Monitoring
• Automatic ETL code, Load Script and Scheduling TCL script generation
5.2 Data Extraction

RISD has various data sources but the initial architecture will have only one approach for data
collection from the ODS. Of course this can be expanded in the future as OWB supports multiple
interface approaches with both Oracle and non-Oracle products. For Phase 1, source data needs to
be available in the Operational Data Store (ODS). The ODS metadata will be read by OWB and used
to map the ODS data elements into the data warehouse.

5.3 Data Cleansing:

Since the source data for the Data Warehouse will come from the ODS, most if not all data has been
validated in operational systems before it is loaded into the ODS. The initial goal of the warehouse is
to match the source systems but not to drop records if possible. Invalid student Ids will be dropped
but records with null student ids will be loaded as a default. All other records with “bad” data will be
defaulted to the equivalent of “unknown”. Of course some simple data editing like date reformatting
may be needed but it is unlikely full-blown standardization/validation issues will need to be
addressed.
5.4 Data Movement:

There will at least 2 different “areas” in which data will be stored in the RISD environment – the ODS
and the Data Warehouse. Data movement among these areas is controlled by the OWB repository
along with SQL*Loader, Oracle Workflow (OWF), and Oracle Enterprise Manager.
1. Source to ODS Area: Assessment data will be loaded into the ODS from state provided
assessment files and RISD student data from the RIMS system. Student data will be updated

daily and assessment data will be loaded as it is received.
2. ODS to Data Warehouse: The Data Warehouse will keep atomic detail and summary data that
will grow to 13 years. The warehouse will begin with approximately 3 years of assessment and
student data. The mapping and transformation will be defined in the OWB repository and the
corresponding PL/SQL packages will be generated. OWB can identify the location and the format
of ODS tables, map the fields in the ODS to the columns in the database and then generate the
necessary load scripts and control files for SQL*Loader.
5.5 Data Enrichment:

Data consolidation is the most common type of data enrichment that a data warehouse environment
offers. As the data comes into the Staging Area, it is matched, merged and consolidated to make it
easier to understand.
Another type of data enrichment creates derived data attributes and calculation transformations. The
data model has identified the need to carry pre-calculated fields because of their frequency of use.
All of these types of enrichments are performed to enhance query performance for the end user.

6.0 Operations, Administration and Maintenance (OAM)

After the data warehouse is built, administration and maintenance become the major tasks for
warehouse operations. There are mainly two stages in the data warehouse, the loading stage, or ETL
stage, where the data warehouse gets refreshed with new data, and data delivery stage where the
end users get data from the data warehouse. When the data warehouse gets refreshed, the new data
from the source systems gets extracted, transformed and loaded into the data warehouse. This ETL
stage involves a large number of processes, procedures and scripts that need to be managed,
monitored, and tuned. OWB interfaces with Oracle Workflow (OWF) and Oracle Enterprise Manager
(OEM) to provide a complete administration solution for the RISD Warehouse Architecture.
6.1 Job scheduling and monitoring
All the jobs for the data warehouse load will be defined within OWB with the execution of these jobs
being managed by Oracle Workflow (OWF) and Oracle Enterprise Manager (OEM).
Oracle Workflow is an Oracle application designed to manage complex process workflows consisting
of:

• Oracle Workflow Builder: A GUI tool to create, view, or modify a process flow.
• Workflow Engine: A component of the Oracle 10g database server that monitors workflow
status and coordinates the routing of activities for a process. Based on flexible workflow
rules, the Engine determines the activities that are eligible to run and then runs them.
• Workflow Definitions Loader loads process definitions into the OWF repository.
• Workflow Monitor: A queue manager to handle workflow Advanced Queue processing and to
monitor process execution.
Because of the complexity of ETL processes, OWF is introduced and integrated into OWB for
managing the dependency of data warehouse load processes.
6.2 Oracle Enterprise Manager (OEM)

OEM will perform job scheduling and database activity monitoring in the RISD Warehouse
Architecture. OEM is based upon a lightweight 3-tier database management architecture that offers
flexible deployment options to ensure reliability and scalability. These tiers include the:
• Centralized Console and Management Applications that presents the user interface to
administrators for their management tasks such as scheduling jobs, monitoring of database
performance and resource usage.
• Oracle Management Servers that control communication between the managed nodes and
the OEM management applications. It is also the place where the OEM repository resides.
• Managed Service and Autonomous Intelligence Agents that manage services or targets, such
as databases, application servers, web servers, nodes or applications. The intelligence
agent, a process that runs on each of the system nodes where the managed service resides,
functions as the executor of the jobs and events sent by the Oracle Management Server after
they are received from the consoles and the management applications. Management Server
communicates with the intelligence agents over Net8.
OWB has an interface to OEM for the job scheduling. The OWB jobs will be registered with the
control of OWF to the Oracle Management Servers from OWB instead of the OEM console. Then
intelligent agents on the managed node will perform the job execution and monitoring functions.
OEM is a very powerful tool for database management. Other than job scheduling, it can also be
used for performing other database management functions such as capacity planning, session
monitoring, performance tuning, and change management.
• Tuning Pack is a set of tools to help collect, evaluate and implement tuning changes that
impact database performance. The Tuning Pack helps identify and correct database and

application bottlenecks such as inefficient SQL, poor database structures, and improper use
of database resources. The Tuning Pack’s focus is on the highest impact performance areas
such as Application SQL, Indexing Strategies, Instance configuration, Object sizing,
placement and reorganization. The Oracle Tuning Pack contains the following applications
that will be used in the RISD Warehouse Architecture:
⇒ Oracle Expert which discovers tuning opportunities
⇒ Oracle Index Tuning Wizard which recommends index strategies
⇒ Oracle SQL Analyze which helps tune SQL statements
⇒ Oracle Tablespace Map which helps monitor tablespace usage
⇒ Oracle Reorg Wizard which helps correct space usage problems
• Diagnostics Pack is a set of tools to help the database administrator monitor database
activities and identify problems when something goes wrong in the database. The Oracle
Diagnostic Pack contains the following applications that will be used in the RISD Warehouse
Architecture:
⇒ Oracle Advanced Events for database event audit and alert
⇒ Oracle Performance Manager for showing performance data graphically
⇒ Oracle Capacity Planner for planning future capacity requirements

⇒ Oracle TopSessions for monitoring connected sessions
⇒ Oracle Trace for collecting statistics
• Change Management Pack is a set of tools for managing complex changes in the Oracle
Database Server. In the RISD Warehouse Architecture, the Change Management Pack will
monitor the differences between the OWB repository and the physical data warehouse
components and report the differences. Based on these reports, OWB can generate change
code and scripts, which can be applied to the data warehouse without affecting data and
table structures already in the database.
Together with the core OEM functionality, these “packs” will help the data warehouse DBA monitor
and manage the day-to-day operations of the RISD Data Warehouse.

6.3 Metadata Administration

As mentioned earlier, OWB is not only an ETL tool, but also a metadata storehouse. It follows the
metadata management technology of Oracle Common Warehouse Meta model (CWM) by defining a
common model that promotes metadata interoperability between Oracle and non-Oracle products.
This is done in Oracle’s CWM by using open Internet standards: Java as the programming language,
XML (eXtensible Mark-up Language) for import/export, and UML (Unified Modeling Language) as the
modeling language. In fact, Oracle CWM is defined using a complete UML model that describes all
the core classes. These core classes are divided into several packages (or sub-models), each
representing a specific aspect of data warehousing.
OWB and its sibling products share a common Meta model. Although each product has its own
repository, they are able to share each other’s metadata via the Object Management Group’s (OMG)
Common Warehouse Metadata Interchange (CWMI) specification. This specification establishes the
syntax for communication so that participating vendors can independently integrate their tools at the
metadata level. The CWMI defines a metadata model of generic data-warehouse architecture and
includes the rules for modeling data-warehouse instances.

Oracle has implemented the CWM as its repository standard for use by Oracle data warehousing,
decision support, and OLAP tools including Oracle Warehouse Builder, Oracle Designer, Oracle
Enterprise Manager and Discoverer. Wizards within the OWB allow the import and export of
metadata directly from and to these other tools. OWB will be the central place where the data
warehouse metadata resides, and the metadata will be interchanged with other tools such as Oracle
Designer.
6.4 Oracle Designer
There was already extensive discussion on how Oracle Designer was used as the logical modeling
tool to allow members of an application development staff to share the metadata repository.
Technical personnel who want to view how the data is logically related and then physically
implemented use Designer. For RISD Business Intelligence environment, Designer will be used for
designing and updating both logical and physical data models for all data warehouse storage
components.
However, Designer is also helpful in program development where analyst/programming teams can
generate and create applications in Oracle Forms, Oracle Reports and Oracle Web PL/SQL scripts.
All of these objects can be generated from Designer and then executed on Oracle’s Internet
Application Server (iAS) using dynamic HTML (DHTML) and JavaScript. This is not, in itself
applicable to the operation, administration and maintenance of the data warehouse but it may be
useful for the delivery of data.
6.5 Metadata Capture:
In the data warehouse, data is stored in different components such as the Staging Area, ODS, and
Target Data Warehouse. The models are designed by using Oracle Designer. OWB can use those
models as input, and generate transformations based on these database objects. OWB is able to
import the metadata from the Designer through a metadata bridge. OWB can also directly capture
metadata from the Oracle data dictionary and from other Non-Oracle environments if necessary. The
ability to obtain metadata directly from non-Oracle applications may be useful in the future.
6.6 Metadata Update:
Changes to the data warehouse will happen almost as soon as it is built. OWB and Designer are built
to allow changes to the DW structure. If an ETL process needs to change, then the metadata for this
process gets updated in the OWB tool first, and then OWB will generate new DDL, load scripts or the
PL/SQL packages as required. These replacement objects will then be propagated to the data
warehouse.
If a database table or column needs to be changed or added, the change or addition goes to the
Oracle Designer tool first and the change in Designer will be propagated into OWB repository via the

metadata bridge. OWB’s metadata reconciliation capability can analyze the metadata in Oracle
Designer and determine the difference with the earlier imported metadata and synchronize it.
6.7 Metadata Sharing:
The data warehouse architecture involves many different tools and each tool has its own metadata
and repository. Metadata sharing between tools is a feature offered by Oracle for keeping data
consistency and reducing work effort. As already stated, OWB can use Designer’s metadata, and
other Oracle tools such as Discoverer, Darwin, and OLAP server can also get the metadata from
OWB repository. Since each tool has its own repository, the metadata is exported from one tool, and
imported to another tool with the help of the metadata bridge.
6.8 Metadata Publishing:

The metadata in OWB repository needs to be viewed by DW developers and administrators. They
need to view database object definitions and monitor the status of the ETL processes. OWB
repository is published through Oracle Data Warehouse Portal; the OWB Portal can be configured as
a part of the Oracle WEB Portal and allows users to browse the OWB repository, set bookmarks,

register custom metadata reports and so on. This is possible because OWB 9i (and higher versions)
comes with a collection of Views built on the OWB repository. Besides the bundled Oracle Data
Warehouse Portal, these Views facilitate building custom metadata publishing solutions if required.
6.9 Security Administration

Database level security includes providing the necessary privileges to accomplish the ETL processes
and is implemented by managing schemas, roles, and synonyms. A well-designed security approach
can prevent errors in the data warehouse. Application layer security will be maintained by the
applications chosen for end-user information delivery and will be based on the data access
applications chosen in for the final architecture.

7.0 Changes and Updates to the Data Warehouse

Almost as soon as the data warehouse is put into production, enhancements will be requested by the
users or necessitated by changes dictated by the state. This section walks through the change
management process for the RISD Warehouse Architecture and introduces the data warehouse
upgrade features of OWB.
When, based on a change request made by the users, the warehouse development team needs to
drop, reconfigure, rename, and upgrade or otherwise modify the data objects within the data
warehouse. Changes usually begin with the logical data model using Designer. Then the metadata
changes in Designer will be propagated into the OWB repository using the metadata bridge.
Next the changes in the logical design will be applied to the physical database instances. There are
several ways to do this:
• In the traditional way, the DBA can manually create the scripts to CREATE/DROP/ALTER
objects, identify the affected objects, recompile the packages, grant the privileges and

recreate the synonyms.
• OWB10g provides data warehouse upgrade/drop functionality by integrating with the Change
Management Pack from the OEM.
OWB enables you to directly propagate incremental changes in your logical warehouse design to
your physical instances, without having to drop objects or lose existing data. For example, you may
have tables containing data in your physical instances. If you modify the definition of these tables in
OWB (by adding indexes, changing a constraint, or renaming a column), you can directly reconcile
these changes with the tables in your physical instances using the OWB upgrade feature. Changes
are applied in a manner that preserves the existing rows of data within the tables in the physical
instance.
OWB utilizes the Change Management Pack (CM) features in the Oracle Management Server of
OEM to analyze the existing contents of a target instance and synchronize them with changes in the
OWB repository. OWB uses OEM/CM to compare the code generated from the OWB metadata
against the physical objects in the target warehouse. This integrated technology then generates new
SQL, PL/SQL and DDL scripts to upgrade the target warehouse objects to match the metadata in the
OWB repository.

Before the new scripts get generated and executed, OEM/CM creates an Impact Analysis Report as
an upgrade plan. This plan outlines the detailed actions for the upgrade. After reviewing the Impact
Analysis Report, developers may choose to perform the upgrade and execute the scripts or continue
to change the OWB metadata.
Change Metadata in Designer Designer Repository
Migrate or Change Metadata to

OWB OWB Repository
Warehouse
Data Warehouse Metadata Analysis
Analyzed

Upgrade Plan Generated Impact Report
SQL and DDL scripts Generated Generate Code
Execute Upgrade Scripts Physical Data Warehouse

8.0 Backup and Recovery

In order to prevent loss of data, backup and recovery processes need to be developed for the data
warehouse environment. This section discusses some common strategies for data warehouse
backup and recovery.
A data warehouse needs to be backed up on a regular basis to prevent the loss of data and to
reduce the time for recovery should an error occur. The backup of the database is much more
complicated than flat files. Large data volumes usually translate to backup and recovery strategies
that are different from those of online transaction systems. Because the data in the data
warehouse is loaded from other operational source systems, developers often debate whether to
reload from those sources or instead, recover from back-ups when there is a problem. The issue
with reloading data from the source systems is that transactional and more importantly reference
data within the source systems often changes. This means that in these cases the data
warehouse would lose historical integrity if it did not have quality back-ups from which to recover
this lost data.

Oracle database recovery technology requires that, in order to perform a full recovery, the
database online redo logs be archived continuously. This may not be practical in real world data
warehousing since it is not unusual for the database archive log and re-do log to be turned off in
data warehouse environments. This is because there are mainly two kinds of database activities in
the data warehouse: data load/refresh and data delivery. During the data delivery phase, the
warehouse stays unchanged until the next refresh, thus eliminating the need for the re-do log.
During the warehouse refresh, in order to achieve better load performance, many operations will
bypass the redo log using the NOLOGGING option of the Oracle RDBMS and make the archive
log useless.
Without the database archive log, performing backups on a regular basis becomes very important.
Combining the latest data warehouse backups with reloads of source snapshots can satisfy
recovery requirements. If the database crashes, the latest backup needs to be restored and the
warehouse needs to be incrementally reloaded from the point of the last backup. The longer the
interval between backups, the longer the recovery takes. Unfortunately, sometimes not all
database activities that have occurred since the last backup can be recovered using this reload
approach. One option we have is to treat the initial load of the data warehouse and subsequent
incremental loads differently. Turn the archive log off for the initial load, fully backup the
warehouse after the initial load, and then turn the archive log on for incremental loads which
should be a much smaller volume of records and should not negatively impact performance.
While there are many tools in the market for database backup, Oracle’s Recovery Manager
(RMAN) is built into the Oracle 10g server. RMAN is a backup and recovery tool that automates
the backup and recovery procedures with high performance. It is also capable of performing
incremental backups (as long as the re-do and archive logs are turned on during database load
and modification), which backs up only those data blocks that have been changed since the
previous backup.

9.0 Purge, Archival and Restore

Historical data in the data warehouse is very important for business analysis. It is not, however, practical to keep
detailed data in a large data warehouse forever. The cost of storing and administering data goes up and the
performance of database access goes down as the volume of data grows. Fortunately, the value of historical data
diminishes as time passes. Eventually, old data needs to be archived and then removed from the data
warehouse based on the business needs of the end-users. The RISD data warehouse will contain historical data
for up to 13 years depending on component. Data older then this will be purged from the database.
Archive and restore of purged data will be done by the export/import utility in Oracle 10g. Old data sits on the
data warehouse server’s file system after being exported from the database and is then copied to tape or other
storage media. In general, “purge" deletes old data from current tables and "restore" inserts old data back to
current tables. Deletes and inserts can become very expensive as data volume grows in the data warehouse.
Many issues will have to be addressed, such as the need to maintain indexes, the need for large rollback
segments, the generation of tablespace fragmentation, the need to maintain statistics for the Cost Based
Optimizer, and so on.
Oracle 10g employs its range partitioning capabilities to respond to the foregoing issues. It divides a large table
into smaller partitions and limits operations (insert, delete, export, import) to these local partitions. Historical fact

tables, for example, are usually partitioned by time. Each partition holds the data that falls within the key
(monthly, weekly…). Whenever the data in a partition is out of the rolling window of data to be kept in the data
warehouse, that partition can be archived and then dropped from the warehouse. The partition’s data can be
exported to the file system first, and then the partition is dropped from the table.
However, the structure of the table for the partition being purged may change over time. Should a restore be
required in this case, the old data may have a different structure than the current table, so this data cannot be
imported into the current table directly. In order to overcome this issue, a standalone temporary table can be
used to help the archive and restore. During the purge, data in the partition to be purged is exchanged to a
standalone table, then exported and then archived to archive media from there. When restoring, the old data will
be imported into a standalone table. If the table structure is unchanged from when the restored data was
originally purged, the standalone table will be indexed, statistics will be analyzed, and then data will be
exchanged with an empty partition created on the partitioned table for holding the restored data.
If the restored structure has changed, and the changed data is important to the end-users, then the data may
have to be accessed from the standalone table in some ad hoc way. Also, since the old data is loaded into the
standalone table first when restoring, it provides us a chance to prepare the new partition without affecting the
partitioned table. This allows us to make some adjustments to the incoming data, as required, if the original table
structure has changed over time.

Appendix A - ETL and Data Quality Overview
ETL is the process of duplicating, cleansing, rationalizing and integrating data from one or more data
sources into the various components of the data warehouse. Obviously, because of the variety of
data sources and data formats that are often involved, this is where most of the effort and resources
are expended during any data warehousing development project.
Custom building ETL routines by hand using a procedural language like C or PL/SQL can be a very
complex and expensive proposition. Hand written ETL routines tend to hide metadata such as data
object definitions, transformations, and business rules in hard to understand programming code. As
in most large scale programming efforts, documentation is incomplete or lags far behind actual
changes to the code. As developers leave, knowledge of these ETL programs leaves with them. New
programmers have to catch-up as best they can with little or no accurate documentation to guide
them.
Instead, experience has shown that in most cases the ETL process can be greatly improved through

the use of tools to design and develop the extraction, transformation, load and cleansing modules for
the various data warehouse components. Oracle’s Warehouse Builder (OWB) can help the data
acquisition team to graphically design and develop the ETL processes. It also helps capture and
centralize the ETL logic and metadata in one place. OWB is self-documenting and comes with
interfaces to the Oracle 10g data dictionary and Designer 10g and a variety of business intelligence
tools like Oracle’s Discoverer. OWB can also help in resolving data quality issues through its ability to
audit and monitor data loads into the data warehouse.
Data quality is defined as an agreed upon level of “correctness” and “trust” for data elements within
data base repositories. A major goal of data integration/information management efforts is improving
the “Hygiene” of the data used to make decisions. This, of course, implies that RISD has processes
and procedures in place by which the various components of the organization can come to
agreement on what “quality” data” actually means. Data warehousing can help because, when done
correctly, errors in source systems found during the ETL/cleansing process can be fed back to those
source systems, thereby improving data Hygiene through out the information system data flow over
time. This process is referred to as “Closing the Loop” and is a major benefit of integrating and
managing data more effectively.

Appendix B - Metadata Management Overview

Proper management and dissemination of Metadata is essential to the success of any data
warehousing architecture. Metadata is often defined as “data about data”. However, It may be more
useful to think of Metadata as the information, documented in a variety of ways that improves both
business and technical understanding of data and the rules and processes that act upon that data.
There are multiple types of metadata. Some of the most common are:
• Data Object Metadata describes the physical data and is typically stored in a database
catalog. Developers and database administrators using database tools like SQL access it.
Some of the information categorized as Data Objects Metadata are:
⇒ Database Names
⇒ Table Names
⇒ Column Names
⇒ Object sizes
⇒ Object Data Types (Character, Integer, …)

• Data Model Metadata describes the logical design of the data and the mapping from the
logical design to physical design. Data model metadata can also include business rules,
entity relationships, and domain values. Data model metadata is typically found in data
modeling and CASE tools although some may still track this information in diagram and
spreadsheet tools. Some of the information categorized as Data Model Metadata are:
⇒ Data Model Names
⇒ Subject Areas
⇒ Entity Names
⇒ Attribute names
⇒ Relationships
⇒ Domain Values
⇒ Mappings from entities and tables, attributes and columns
• Data Movement Metadata describes the movement of data from source to target. Data
movement metadata includes information about the selection and extraction of data,
mapping, transformation, and loading of data. Data movement metadata can be found in ETL
or replication tools or in the logic of the code written to perform the data movement function.
Some of the information categorized as Data Movement Metadata is:
⇒ Source and Target data object definitions
⇒ Mappings between Source and Target objects
⇒ Transformation Rules
⇒ Transformation Restrictions
⇒ Derivation Rules for derived target objects
⇒ Data movement scheduling information
⇒ Data anomalies and resolutions
⇒ Process Dependencies
⇒ Versioning information
⇒ History of prior data movements
• Business Rule Metadata describes how the business operates through the use of its data.
Business Rule metadata describes entity relationships, cardinality, and domain rules that
define the use of data. Business Rule metadata typically exists in data modeling or CASE
tools, or in other forms of documentation maintained outside of a tool: a word processing
document or a spreadsheet. Some of the information categorized as Business Rule Metadata
are:
⇒ The relationship between two entities of data in the logical data model.
⇒ The cardinality between those same entities.
⇒ Valid values for Attributes

• Data Stewardship Metadata describes who in the organization defines the data and is
responsible for those systems or processes that create, maintain, and delete data, and who
consumes the data or directly uses the data or information to do their jobs. . Some of the
information categorized as Data Stewardship Metadata are:
⇒ Organization Information Policy
⇒ Data Security Policy and Rules
⇒ Person or Organization responsible for defining, creating, reading, updating, and
deleting the data
⇒ Data Access Policy and Rules
• System Metadata describes all objects of a system from data files or tables, to programs, to
scripts and jobs, to screens. System metadata is a cross-reference of all of the components
that make up the system and how the components are shared and re-used. Some of the
information categorized as System Metadata are:
⇒ Standard re-usable objects
⇒ Component Descriptions
⇒ Rules for re-use of system objects
⇒ Component test policies and rules

⇒ Component names and characteristics
⇒ Persons and organizations responsible for supporting and maintaining components
⇒ Component Update History
• Data Access / Reporting Metadata describes the data access methods and how data has
been defined to those access methods or tools. Data Access and Reporting metadata may
also describe the steps that must be taken to get authorization to read the data, the
description of how the data can be interpreted, available tools, and descriptions of reports.
Data Access and Reporting metadata typically is found within business intelligence tool
repositories and in traditional types of documentation (i.e. desktop databases, word
processing documents and spreadsheets). Some of the information categorized as Data
Access / Reporting Metadata are:
⇒ Names and descriptions of standard queries and reports
⇒ Queries used to obtain data for reports
⇒ Report-level security policies
⇒ Rules on data display
⇒ Description of data used on reports
⇒ Query or report change history
⇒ Query and report usage and performance statistics
⇒ Query and report scheduling information
• Rationalization Metadata describes standard "corporate agreed to and accepted" pieces of

information and how those pieces of information are represented or mapped to data captured
in the systems. The standard pieces of information can be a select list of data elements that
have accepted meanings, histories, and values and/or the standard pieces of information can
come from an enterprise data model. The Rationalization metadata can describe the degree
to which the data elements are the same piece of information and the differences. Some of
the information categorized as Rationalization Metadata are:
⇒ Standard names and definitions of data elements that exist in the organization
⇒ Policies and processes by which elements where rationalized
⇒ Description and rules defining how standard elements should be used
⇒ Standard rules for deriving business measures and dimensions
⇒ Standard rules for cleansing data elements
⇒ Standard reference data
• Data Quality Metadata describes the quality of the data. Data Quality metadata describes
the accuracy, confidence level, the change history of the data values and definitions. Some of
the information categorized as Data Quality Metadata are:
⇒ Change history of data objects
⇒ Validity Rules and Policies

⇒ Data Load metrics

⇒ Confidence Level metrics
⇒ Actions are taken when data is "bad", missing, duplicate, and so on
• Operational Metadata describes the operational activities surrounding the process of

gathering, storing and retrieving data. Some of the information categorized as Operational
Metadata are:
⇒ Data storage methods
⇒ Data Load processes and procedures
⇒ Server operations and availability
⇒ Scheduling dependencies
⇒ Error-handling procedures
⇒ Backup and restore procedures
⇒ Archival procedures
⇒ Operating systems’ logs
⇒ Database management system logs
This is by no means a complete listing of the metadata that exists, or should exist, within RISD. The

important point here is that the management and dissemination of metadata is essential to the
process of data integration and information management. End-users have to understand the
information on which they are basing decisions comes from so they can judge how much trust to
place in that information. A Metadata Repository, a database repository for storing both technical and
business “data about data”, will be an essential element in educating end-users about the contents of
the various data repositories within the Data Warehouse and how those contents got there. It will also
be vital in helping developers in their efforts to maintain and expand the data warehouse
environment.

Appendix C – Data Acquisition Components - OWB Overview

Oracle 10g Warehouse Builder is a tool to enable the design and deployment of Business Intelligence
data warehouses, data marts and e-Business intelligence applications. The tool is a component of
the Oracle 10g Development Suite and part of the overall Oracle tools offering. Warehouse Builder
allows users to design a Business Intelligence application from start to finish. Dimensional design,
ETL process design, extraction from disparate source systems, extensive metadata reporting and
integration with Oracle AS10g, Discoverer, Oracle Workflow and Oracle Enterprise Manager enable
an integrated Business Intelligence solution with Warehouse Builder at the core. This section covers
the main features delivered with Warehouse Builder. It gives a high level overview of the capabilities
of the tool and its features.
Oracle Warehouse Builder is not merely an ETL tool but it is a tool that allows users to design ETL
processes, and target warehouses and intermediate storage areas. Oracle Warehouse Builder is a
core component of Oracle's Data Warehouse strategy, tightly integrated with the entire stack of
products Oracle offers to customers. A summary of the characteristics and benefits:

• Warehouse Builder is a design tool for data warehousing that provides design and
deployment of data warehouse/mart schema's and source target mappings
• Fully leverages the Oracle database
• Contains life-cycle management capabilities
• Provides metadata sharing and reporting
KEY FEATURES
Integration
• Oracle 10g Database

• Oracle 10g Application Server
• Oracle Warehouse Builder Bridges
• Oracle Designer10g
• Oracle OLAP
• Oracle Discoverer
• OLAP Server
ETL Functionality
• Graphical ETL design

• Numerous operators to create ETL processes:
• Key lookup
• Union/Minus/Intersect
• Joiner
• Splitter
• Filter
• Aggregator
• In-line Expressions
• Transformations
• Surrogate key handling
• Pre and Post mapping processes
• External processes
Supported Targets
• Oracle 8i Release 3 (8.1.7)

• Oracle 9i
• Oracle 10g
• Flat files

Target Design Capabilities

• Wizard driven and highly graphical
• Data stores, marts and enterprise warehouses
• Relational models
• Multi-Dimensional models
Standards Conformance
• OMG CWM
• Open standard
• Utilizes XML Metadata Interchange (XMI)
• Powerful object model
• Spans spectrum related to ETL and analysis
Metadata Management
• Advanced validation framework
• Multiple-User Environment

• Advanced locking and name checking
• Archive and Restore mechanism
• Incremental code generation within the mapper
• Auto mapping between sources and targets
• SAP Integrator provides seamless extraction from SAP R/3 source system on any platform
• An XML tool kit is supplied with a set op OWB embedded transform functions
• Flat file integrator handling:
• Character delimited and fixed length
• Single or multiple record type files
• Graphical Expression builder
• Graphical Transformation Editor
• Transformation library to store and share transformations
Supported Sources
• SAP R/3 _ Oracle
• Flat Files
• ODBC
• DB2, Sybase, Informix, SQL Server (via Oracle Transparent Gateways)
• Mainframe (with Oracle Pure Extract) Reporting
• Support for multiple Portlets within the Warehouse Builder Browser component
• Metadata Impact Analysis Reporting
• Metadata Lineage Reporting
• Portlet based technology
• Secure framework
• Customizable environment
• Public views on both design time and runtime environment
Life-Cycle management
• Source metadata Reconcile:
• Re-import existing source objects
• Reconcile with current definitions
• Impact analysis
• Warehouse Upgrade
• Stand alone Change Management pack
• Create/Drop/Add/Rename Objects
• Impact Analysis report
• Generate upgrade scripts
• Store intermediate data if required for change

Appendix D – Portal Architecture Options

The following diagram shows a simplified portal architecture using one load balancer. Implementing this option will be
the least expensive alternative but there will be no redundancy.
Oracle Internet Directory and Portal share the same Metadata Repository (MR) database.
The MR database is a RAC database and two OID Instances.
A load balancer load balances LDAP requests from clients.
SSO and Discoverer are SSL-enabled, while Portal is not.
SSO, Portal and Discoverer middle-tiers reside in the DMZ, while OID and the RAC database is not.
HTTP(80)
SSL(443)
SSL (443)

SSO Middle Tier Portal Middle Tier Discoverer Middle Tier
Load Balancer
oidp.risd.org
OID Instance 1 OID Instance 2
Instance 1 Instance 2

The following diagram shows a fully redundant collocated portal architecture.

The MR database is a RAC database and it has two OID Instances.
SSO, Portal and Discoverer middle-tiers reside in the DMZ, while OID and the RAC database is not.
SSO and Portal are co-located (in different Oracle Homes), on the same Linux Server.
Load Balancer
HTTP(80) HTTP(80) SSL(443) SSL(443)

SSL (443) SSL (443)

SSO Middle Tier Portal Middle Tier SSO Middle Tier Portal Middle Tier Discoverer Middle Tier Discoverer Middle Tier
Load Balancer
oidp.risd.org

Fully redundant
The MR database is a RAC database and it has two OID Instances.
A load balancer load balances LDAPrequests from clients.
SSO, Portal and Discoverer middle-tiers reside in the DMZ, while OID and the RAC database reside behind
the firewall.
Load Balancer
HTTP(80) HTTP(80) SSL(443) SSL(443)

SSL (443) SSL (443)

SSO Middle Tier Portal Middle Tier SSO Middle Tier Portal Middle Tier Discoverer Middle Tier Discoverer Middle Tier
Load Balancer
oidp.risd.org

DISTRICT

M7_RISD_Final_ETL_Test_Results_V1.doc
TE.100 - ETL TEST RESULTS

RISD DATA WAREHOUSE
Creation Date:
Last Updated:
Version: 1.0
Approvals:
RISD ETL Test Results
1 Document Control
1.1 Change Record

Version

1.2 Reviewers
Name Position
1.3 Distribution
Name Position
System Library
RISD ETL Test District Confidential - For internal use only ii

Contents
1.1 Change Record ................................................................................................ ii
1.2 Reviewers ......................................................................................................... ii
1.3 Distribution ........................................................................................................ ii
2 INTRODUCTION......................................................................................................1
2.1 Background........................................................................................................1
2.2 Purpose ..............................................................................................................1
3 TEST CASE SCENARIO........................................................................................3

3.1 Test Approach ...................................................................................................4
3.2 Test Execution – Conversion ..........................................................................5
3.3 Test Execution – Student Information System (SIS) Incremental Load ...9
3.4 Test Execution – TAKS Assessment Load Checklist ................................10
3.5 Test Execution – TEKS Assessment Load Checklist ................................11
3.6 Test Execution – SDAA II Assessment Load Checklist ............................12
3.7 Test Execution - Standards and Internal DW Tables ................................14
4 OPEN AND CLOSED ISSUES............................................................................15
4.1 Open Issues.....................................................................................................15
4.2 Closed Issues ..................................................................................................15
RISD ETL Test District Confidential - For internal use only iii
2 Introduction
2.1 Background
The RISD Data Warehouse environment will provide decision makers throughout the District with information to help improve
student achievement. Users will access the system via Windows based Internet-capable computers to accommodate the needs of
both computer novices and experts. Data that is currently processed independently in multiple “applications” will be integrated into
a single environment to facilitate data reporting and analysis across test areas. All data in the data warehouse will be sourced
from the Operational Data Store (ODS) including assessment information, assessment standards, and student information.
Discoverer report data will be available online and can be downloaded into local applications where appropriate (for example,
spreadsheets and PC databases) to perform additional analysis or for integration with local data. Phase I will primarily focus on
student assessment data.
User groups will be restricted to accessing information associated with their responsibilities, needs, and skills. The majority of end
users will run parameter driven reports to obtain multiple views of the assessment data. Dashboard reports will provide
summarized tabular and/or graphical information to various user groups. The system is designed so RISD can develop relevant
reports as new data becomes available. Some power users will go directly to Discoverer Plus to run reports and create new
reports on an “as needed” basis while most users will use Discoverer viewer or a restricted version of Discoverer Plus to run the
parameter driven reports and/or view static standard reports.
2.2 Purpose
This document defines the Extract, Transform, and Load (ETL) test plan and shows the expected and actual results if different
from the expected results. All data will be sourced from the RISD Operational Data Store. The system and user acceptance test
will use actual data from the ODS. To ensure thorough testing, some unit tests will include conditions that must be coded for but
may not appear in the live data. For example, the unit test will include a test for a RISD student ID on the assessment file that
does not have a corresponding student record. While this condition theoretically cannot happen, it must be tested.
This document is used to gain confirmation that the ETL process is working as expected. Please note this document validates
ETL functionality. See the production readiness document for information on production procedures.
RISD ETL Test District Confidential - For internal use only 1


• Milestone 1, Project Management Plan – Baseline plan in Microsoft projects with accompanying project management plan
(PMP) document.
• Milestone 2, RD.049 Report Requirements Document – Clearly defines the reporting requirements in the 12 priority
Assessment areas implemented for Phase 1.
• Milestone 3, RD.049 Portal Security Requirements – Data Warehouse Portal Security Design Document describes the
functionality of the Portal pages required to support the highest priority Data Warehouse reports and Dashboards. The Look
and feel, navigation colors and graphics are not part of these requirements and only the Data Warehouse page content,
report links and how roles determine geographic defaults will be included.
• Milestone 4, Logical Data Model – Logical Data Model Design contains all the entities (facts, dimensions and measures) to deliver the
report requirements. The actual design will be contained in the Designer Repository.
• Milestone 5, MD.040 Physical Data Model – The Physical Data Model Design contains all the tables, indexes, partitioning,
and parameters needed to define the data warehouse objects and is documented in Oracle Designer.
• Milestone 6, RISD Architecture document
• Milestone 7, Report test results
• Milestone 9 – Production Readiness/Operational Guide

3 Test Case Scenario

TEST CASE OVERVIEW
Scope and Objectives The Following Assessment Areas will be loaded into the Data Warehouse Environment.
1. TAKS
2. TEKS (K-2 Math merged into TEKS)
3. SDAA II (replaces SDAA)
4. TELPAS (Replaces RPTE)
5. SAT
6. PSAT
7. ACT
8. LDAA (pieces from TAKS, SDAA, and local data feed)
9. Tejas Lee
10. ERWA/TPRI
11. AP
The ETL process will populate data warehouse tables using data stored in the RISD Operational Data Store (ODS).
Step 1 – Assessment data is loaded into the ODS.
Step 2 – An automated ODS match process appends the RISD student IDS. Students not having a valid student ID will have a null value.
Step 3 – A list of unmatched students will be given to the Assessment team for correction in the ODS.
Step 4 – After correction, the OD assessment file will available for loading into the DW.
Step 5 – Data Definition Language (DDL) was created to create DW tables.
Step 6 – All tables initialized.
Student Data
Student data will be updated nightly from the ODS Student Information System (SIS) tables. All data changed since the last update will be
updated in the DW.
Other reference, Assessment Standard data, and employee security data
Employee updates will be included in the daily update process. Every night an automated process will run against the ODS and the employee
table will be reloaded.

Test Run Test case execution will be evaluated using the following pre-determined acceptance criteria:
Acceptance • All the tests have been fully executed; if steps were not executed, they are identified and the reason of non-execution is
clear and approved by the reviewer.
• All the conclusions conform to the expected results. If not, deviations have been referenced in the test case (column
«actual results») and, if applicable, corrective actions have been initiated and documented.
Execution • Live data for up to three years of testing will be used to ensure most if not all test conditions will be available.
Instructions • Special condition testing will occur during unit testing. That is, conditions not expected in “live” data will be contrived in the
unit test environment to ensure the process works correctly.
• For each expected result, the conclusion is either “Pass” or “Fail”; nothing else is expected.
3.1 Test Approach
TEST ENVIRONMENT CONFIGURATION
There are three phases to the testing process: Unit test, system test, and integrated (user acceptance) test. The unit test will start with a snapshot of data
provided in the ODS. A snapshot of ODS data will be copied to the DW machine and used for unit testing. Some conditions will need to be added to the
“live” data to ensure all scenarios are addressed. For example, some records will be changed to have invalid RISD student IDS to make sure the record
causes the process to abend (referential integrity check).
SYSTEM AND INTEGRATION TEST DATA
System will obtain test data from the ODS test environment. For the system test, the data warehouse will begin with empty tables and all ODS data will
be loaded into the DW environment. RISD student information will be updated daily in the production environment and the mechanized daily update
process will be tested during the integrated system test. NOTE – Final acceptance part of production readiness

TEST PRE-REQUISITES Verified

(Yes/No)
• The ETL test assumes that all Oracle tables have been defined and initialized in the DW test environment. YES
• The tester must have access to the ODS and the DW in order to validate results.
• For unit test, the tester must have write access to the ODS tables on DWDEV in order to force test conditions.
3.2 Test Execution – Conversion
Step N° Condition Expected Results Actual Results Conclusion Tester’s Comments

1 Run Table Execution Script All tables are initialized Mike Hennessy. Loaded Pass This is a one time
(Data Definition Language – tables. Fail process. Development
DDL) structures copied to
production.
2 Load TAKS data - All Fact data is loaded from the Data verified for 2004 by Pass School Calendar in ODS
Administrations as final. TAKS data and new dimension Jiangang. Luo and supported Fail must show full 12 month
data is created for the facts. by report test results. calendar by campus to
Objectives and objective items set admin year correctly.
are loaded into staging tables Added calendars for
before the final load. dummy campuses and
145. Dependent on
objective item keys being
correct in the ODS.
3 Load TEKS data - All Fact data is loaded from the Data verified by M. Pass Dependent on objective
Administrations as final. TEKS data and new dimension Hennessy. Need to check Fail and objective item keys
data is created for the facts. final load when keys are being correct in the ODS
Objectives and objective items ready.
are loaded into staging tables
before the final load.


4 Load SDAA II data - All Fact data is loaded from the Data verified for Test Area by Pass Dependent on objective
Administrations as final. SDAA data and new dimension J. Luo supported by SDAA Fail and objective item keys
data is created for the facts. report test. Mike Hennessy being correct in the ODS
Objectives and objective items Verified objectives and
are loaded into staging tables objectives items.
before the final load.
5 TELPAS (Replaces RPTE) data Fact data is loaded from the Data verified by J. Luo and Pass Objective and objective
- All Administrations as final. TELPAS data and new dimension Jean Liu and supported by Fail Item keys not used
data is created for the facts. TELPAS report test results.
6 Load SAT data - All Fact data is loaded from the SAT Data verified by Jean Liu and Pass Exact duplicates found in
Administrations as final. data and new dimension data is supported by download of Fail input files are eliminated
created for the facts data to Jennifer Busse for in the materialized views.
validation. Jennifer confirmed
records for previous tests
can be in current files
which causes duplicates
across administrations.
7 Load PSAT data - All Fact data is loaded from the Data verified by Jean Liu Pass
Administrations as final. PSAT data and new dimension Fail
data is created for the facts
8 Load ACT data - All Fact data is loaded from the ACT Data verified by Jean Liu and Pass Duplicates possible in a
Administrations as final. data and new dimension data is supported by download of Fail batch since multiple
created for the facts data to Jennifer Busse for administrations are in a
validation batch. Materialized view
provides link to
graduates.
9 Load LDAA data - All Fact data is loaded from the Data to be verified by Pass LDAA report only uses
Administrations as final. LDAA data and new dimension Jennifer Busse. Fail data provided by the
data is created for the facts. assessment team. LDAA
Additional data is loaded from data available from TAKS
SDAA and TAKS records and SDAA files used in
containing LDAA information. AYP summaries.


10 Load Tejas Lee data - All Fact data is loaded from the Data verified by Jean Liu Pass Indicators for passing are
Administrations as final. Tejas Lee data and new Fail missing because the
dimension data is created for the information was not
facts provided. Assessment
team opted to defer this
since the reports will not
be used in 2005 -2006
school year.
11 Load ERWA/TPRI data - All Fact data is loaded from the Data verified by Jean Liu Pass Indicators for passing are
Administrations as final. ERWA/TPRI data and new Fail missing because the
dimension data is created for the information was not
facts provided. Assessment
team opted to defer this
since the reports will not
be used in 2005 -2006
school year.
12 Load AP data - All Fact data is loaded from the AP Data verified by Jean Liu but Pass Course information
Administrations as final. data and new dimension data is AP and Pre AP flags not set. Fail carries type of course as
created for the facts AP or pre AP was
corrected
13 Load Daily SIS Dimension data All Data is loaded into the DW. Data verified by Jiangang Pass Dummy student records
– initial load Note – “Dummy” student Ids are Luo and reviewed by RISD. are added from State
Fail
created for students having null Assessments. Two types
student ids in the input files. of unknown possible –
Unknown District and
Unknown Campus, RISD
District and Unknown
Campus. Summary file
created for reports.


14 Load Daily SIS Fact data – initial All Data is loaded into the DW. Data verified by Jiangang Pass Dummy student records
load Note – “Dummy” student Ids are Luo and reviewed by RISD. can be added from State
Fail
created for students having null Assessments. Some
student ids in the input files. enrollment information is
available for RISD
students.
15 Load Daily Employee data Full replacement of old data. Data verified by Jiangang Pass Used in security. See
Luo and reviewed by RISD. Fail production readiness

3.3 Test Execution – Student Information System (SIS) Incremental Load

Step N° Condition Expected Results Actual Results if Different Conclusion Tester’s Comments
than Expected Results
1 Data verified by Jiangang Luo Pass D_SCHOOL_YEAR is
Load Standard Dimension Tables properly updated and verified in reports. set by campus since
Fail
Tables some schools have
D_ACCESS_LEVEL
D_ADMINISTRATION_PERIOD different calendars. For
D_ASSESSMENT test administration,
D_CAMPUS school year is considered
D_CAMPUS_TYPE August – July. Calendars
D_CLASS_OF for unknown school years
D_CLASS_PERIOD were added and missing
D_COURSE calendar for campus 145
D_DISTRICT_PEOPLE added.
D_ECONOMIC_DISADVANTAG
ED
D_EDUCATION_GRADE
D_ETHNICITY
D_GENDER
D_ITEM_RESPONSE_GROUP
D_LEP
D_PEOPLE_LOCATION_ACCE
SS
D_PERFORMANCE_GROUP
D_SCHOOL_YEAR
D_SPECIAL_ED
D_STUDENT
2 Load Fact Tables Tables properly updated Data verified by Jiangang Luo. Pass
F_STUDENT_ACCESS
Fail
F_STUDENT_SCHEDULE
FH_ASSESSMENT_ADMINIST
RATION
FH_STUDENT_HISTORY

3.4 Test Execution – TAKS Assessment Load Checklist
1 ODS input assessment has a Process abends (unit test forces Abend verified during unit Pass
RISD Student ID for a student a bad record, this condition testing – part of production Fail
that is not in the DW student should not occur in production readiness
tables and is a fatal error)
2 ODS input assessment has a RISD student is added to the Verified in multiple files Pass
RISD student ID with a null DW with a default student ID and Fail
value assessment record is added to
the assessment tables and the
corresponding assessment
dimensions.
3 ODS assessment file has valid Assessment record is added to Verified in multiple files Pass
RISD student IDS that have the DW with corresponding Fail
student records in the DW assessment dimensions.
4 The assessment file has All records with invalid data are Verified in multiple files Pass Data in the ODS is
invalid values for data fields added to the data warehouse but Fail loaded “as is”. Data that
that are not key fields invalid values are defaulted to is suspect is added as
unknown. varchar
5 Load TAKS data as final - Fact data is loaded from the Tested in all loads Pass
Select a year and TAKS data into the fact tables Fail
administration.
6 Load Dimensions associated Load properly populates Tested in all loads Pass D_OBJECTIVE
with Assessment Dimension Tables Fail D_OBJECTIVE_ITEM
D_STUDENT_TAKS
7 Load Load properly populates item Tested in all loads Pass Dependent on objective
F_TAKS_STUDENT_ITEM_ fact tables Fail and objective item keys
RESULTS being correct in the ODS

8 Load Load properly populates Tested in all loads Pass Dependent on objective
F_TAKS_STUDENT_OBJ_R objective fact tables Fail and objective item keys
ESULTS being correct in the ODS
9 Load Load properly populates test Tested in all loads Pass
F_TAKS_STUDENT_TA_RE area fact tables Fail
SULTS
3.5 Test Execution – TEKS Assessment Load Checklist
Step N° Execution Steps Expected Results Actual Results if Different Conclusion Tester’s Comments
that is not in the DW student should not occur in production) readiness
tables
dimensions.

4 The assessment file has invalid All records with invalid data are Verified in multiple files Pass
values for data fields that are not added to the data warehouse but
Fail
key fields invalid values are defaulted to
unknown.
5 Load Load properly populates fact Tested in all loads Pass Dependent on objective
F_TEKS_STUDENT_ITEM_ tables Fail and objective item keys
F_TEKS_STUDENT_OBJ_R tables Fail and objective item keys
7 Load Load properly populates fact Tested in all loads Pass
F_TEKS_STUDENT_TA_RE tables Fail
SULTS
D_STUDENT_TEKS
3.6 Test Execution – SDAA II Assessment Load Checklist
that is not in the DW student should not occur in production) readiness
tables

dimensions.
4 The assessment file has invalid All records with invalid data are Verified in multiple files Pass
values for data fields that are not added to the data warehouse but
Fail
key fields invalid values are defaulted to
unknown.
F_DSAA_STUDENT_ITEM_ tables Fail and objective item keys
F_SDAA_STUDENT_OBJ_R tables Fail and objective item keys
7 Load Load properly populates fact Tested in all loads Pass Used is SDAA II report
F_SDAA_STUDENT_TA_RE tables Fail
SULTS
D_STUDENT_SDAA

3.7 Test Execution - Standards and Internal DW Tables
1 DW_ASMT_BATCH Internal DW table loaded Tables used in Processing Pass Part of production
Fail readiness
2 DW_CODES Internal DW table loaded Tables used in Processing Pass Part of production
Fail readiness
3 DW_CODES_TRANSFORM Internal DW table loaded Tables used in Processing Pass Part of production
Fail readiness
4 DW_ETL_CONTROL Internal DW table loaded Tables used in Processing Pass Part of production
Fail readiness
5 DW_ETL_PROCESS Internal DW table loaded Tables used in Processing Pass Part of production
Fail readiness
6 DW_FACT_AUDIT Internal DW table loaded Tables used in Processing Pass Part of production
Fail readiness
7 RISD_ACCOUNTABILITY_M Minimum size for accountability Tables used in Processing Pass Part of production
IN_SIZE populated readiness
Fail
8 RISD_OP_PARMS Report Metrics are properly Tables used in Processing Pass Part of production
loaded Fail readiness

4 Open and Closed Issues
4.1 Open Issues
ID Issue Resolution Responsibility Target Impact Date

Date
1. Objective and objective items Manually corrected during testing but an update process will
keys in the ODS match tests be created by RISD. Lead to delays in verifying results
2. Mechanization of manual ODS Data manually verified during conversion. RISD should
processes. mechanize update process as opposed to loading
spreadsheet directly into the ODS
4.2 Closed Issues

ID Issue Resolution Responsibility Closed Date
1 SAT assessments contain When matching RISD graduates, only one record with the
duplicate records highest score is considered in the materialized view
2 Dummy campuses need Added dummy campuses for (RISD defined district but unknown
calendars to set school year campus) and (Unknown District but unknown campus ) Added
when loading assessments. campus 145 to calendar
3 School calendar does not For assessments, school year is considered August – July for
address July and August conversion. Calendar must be updated in the ODS to reflect the
full year.
4 ERWA and Tejas Lee passing Assessment team decided that the information is not critical
indicators are not set because since the tests will not be used going forward. Raw data from the
test benchmarks are not assessment file is available.
available

DISTRICT

M8_RISD_Reports_Final_Test_Results_V1.1.doc
TE.100 - REPORT TEST RESULTS

RISD DATA WAREHOUSE
Creation Date:
Last Updated:
Version: 1.1
Approvals:
RISD Discoverer Test Results
1 Document Control
1.1 Change Record

Version

1.2 Reviewers
Name Position
1.3 Distribution
Name Position
System Library
Note To Holders:
If you receive an electronic copy of this document and print it out, please write
your name on the equivalent of the cover page, for document control
purposes.
If you receive a hard copy of this document, please write your name on the
front cover, for document control purposes.
RISD ETL Test Version 1.1 District Confidential - For internal use only ii
Contents
1.1 Change Record ................................................................................................ ii
1.2 Reviewers ......................................................................................................... ii
1.3 Distribution ........................................................................................................ ii
2 INTRODUCTION......................................................................................................1
2.1 Background........................................................................................................1
2.2 Purpose ..............................................................................................................1
3 TEST CASE SCENARIO........................................................................................3

3.1 Test Approach ...................................................................................................4
3.2 TAKS Objective Summary...............................................................................5
3.3 TAKS Summary by Test Area (Counts and Percentage) ...........................6
3.4 TAKS Item Analysis..........................................................................................7
3.5 TAKS Objective Summary by Student...........................................................8
3.6 SDAA II Expectation by Student Group (counts and percentages) ..........9
3.7 TELPAS Results by Grade Summary and Proficiency Rating (two
reports) ....................................................................................................................10
3.8 AYP Report ......................................................................................................12
4 OPEN AND CLOSED ISSUES............................................................................13
4.1 Open Issues.....................................................................................................13
4.2 Closed Issues ..................................................................................................13
RISD ETL Test Version 1.1 District Confidential - For internal use only iii
2 Introduction
2.1 Background
The RISD Data Warehouse environment will provide decision makers throughout the District with information to help improve
student achievement. Users will access the system via Windows based Internet-capable computers to accommodate the needs of
both computer novices and experts. Data that is currently processed independently in multiple “applications” will be integrated into
a single environment to facilitate data reporting and analysis across test areas. All data in the data warehouse will be sourced
from the Operational Data Store (ODS) that will include assessment information, assessment standards, and student information.
Report data created in Discoverer will be available online and can be downloaded into local applications where appropriate (for
example, spreadsheets and PC databases) to perform additional analysis or for integration with local data. Phase I will primarily
focus on student assessment data.
User groups will be restricted to accessing information associated with their responsibilities, needs, and skills. The majority of end
users will run parameter driven reports to obtain multiple views of the assessment data. Dashboard reports will provide
summarized tabular and/or graphical information to various user groups. The system is designed so RISD can develop relevant
reports as new data becomes available. Some power users will go directly to Discoverer Plus to run reports and create new
reports on an “as needed” basis while most users will use Discoverer viewer or a restricted version of Discoverer Plus to run the
parameter driven reports and/or view static standard reports.
2.2 Purpose
This document defines the Test Results for the Discoverer reports created by Oracle Consulting. The TAKS Objective Summary
by student will be used to test the Virtual Private Database (VPD) security requirements and will be included in the operational
readiness document. All data available in the Data Warehouse will be sourced from the RISD Operational Data Store. Testing will
validate that data is accurately extracted from the data warehouse but does not check whether data was correctly loaded into the
DW. The system and user acceptance test will use actual data from the ODS.
RISD ETL Test Version 1.1 District Confidential - For internal use only 1
This document is used to gain confirmation that the reporting process is working as expected.

• Milestone 1, Project Management Plan – Baseline plan in Microsoft Project with accompanying project management plan
(PMP) document.
• Milestone 2, RD.049 Report Requirements Document – Clearly defines the reporting requirements in the 12 priority
Assessment areas implemented for Phase 1.
• Milestone 3, RD.049 Portal Security Requirements – Data Warehouse Portal Security Design Document describes the
functionality of the Portal pages required to support the highest priority Data Warehouse reports and Dashboards. The Look
and feel, navigation colors and graphics are not part of these requirements and only the Data Warehouse page content,
report links and how roles determine geographic defaults will be included.
• Milestone 4, Logical Data Model – Logical Data Model Design contains all the entities (facts, dimensions and measures) to deliver the
report requirements. The actual design will be contained in the Designer Repository.
• Milestone 5, MD.040 Physical Data Model – The Physical Data Model Design contains all the tables, indexes, partitioning,
and parameters needed to define the data warehouse objects and is documented in Oracle Designer.
• Milestone 6, RISD Architecture document
• Milestone 7 – ETL test results
• Milestone 9 – Production Readiness/Operational Guide
Note: Reports data must match what is in the database. If the data does not mach expected results, the ETL process must be
reviewed for inconsistencies or to determine why historical reports do not match historical data.
3 Test Case Scenario

TEST CASE OVERVIEW
Scope and Objectives The Following Assessment Areas was loaded into the Data Warehouse Environment.
1. TAKS
2. TEKS (K-2 Math Added to TEKS checks)
3. SDAA II (Replaces SDAA)
4. TELPAS (Replaces RPTE)
5. SAT
6. PSAT
7. ACT
8. LDAA
9. Tejas Lee
10. ERWA/TPRI
11. AP
The ETL process will populate data warehouse tables using data stored in the RISD Operational Data Store (ODS).
Student data will be updated nightly from the ODS Student Information System (SIS) tables. Reference, Assessment Standard data, and
employee security data will be loaded into the Data Warehouse. Since all reports are based on student data associated with the assessment,
once assessments are marked as final, report data will not change. Changes in the SIS data will not affect the assessment report results.
Test Run Test case execution will be evaluated using the following predetermined acceptance criteria:
Acceptance • All the tests have been fully executed; if steps were not executed, they are identified and the reason of nonexecution is
clear and approved by the reviewer.
• All the conclusions conform to the expected results. If not, deviations have been referenced in the test case (column
«actual results») and, if applicable, corrective actions have been initiated and documented.
Execution • For each expected result, the conclusion is either “Pass” or “Fail”; nothing else is expected.
Instructions
3.1 Test Approach
TEST ENVIRONMENT CONFIGURATION
The purpose of the system testing of reports is to ensure that the report is extracting data from the data mart according to report specifications and that
the data is presented in the defined report format (within the potential limitations of Oracle Discoverer). The quality of the data matching the input source
system is addressed in the Extract, Transform, and Load (ETL) update process.
This test case execution will be evaluated using the following predetermined acceptance criteria:
• All the tests have been fully executed; if steps were not executed, they are identified and the reason of nonexecution is clear and approved by the
reviewer.
• All the conclusions conform to the expected results. If not, deviations have been referenced in the test case (column «actual results») and, if
applicable, corrective actions have been initiated and documented.
• All the printing generated during the script execution must reference the test case ID/step ID/test run, the test date and the tester initials.
• For each expected result, the conclusion is either “Pass” or “Fail”; nothing else is expected.
SYSTEM AND INTEGRATION TEST DATA
System and integration testing will obtain test data from the ODS test environment. For the system test, the data warehouse will begin with empty tables
and all ODS data will be loaded into the DW environment with live conversion data. All data will be static during the system test. RISD student
information will be updated daily but that is part of the integration test with the ODS. NOTE – Final acceptance part of production readiness
TEST PRE-REQUISITES Verified
(Yes/No)
• The report testing assumes that all Oracle tables have been defined and loaded in the test environment. YES
• The tester must have access to the DW in order to validate results (proper loading of data into the DW is tested during ETL
testing.
3.2 TAKS Objective Summary
Step N° Condition Expected Results Actual Results if Different than Conclusion Tester’s Comments
Expected Results
1.0 1. D_SCHOOL_YEAR - 2004 Selected Parameters Issue with School calendar Pass Training required as
2. D_ADMIN_PERIOD - 0404 display at the top of the corrected in reload to Prod. Added some selections are not
3. D_TEST_AREA - Math Fail
report calendars for dummy campuses logical
4. D_CAMPUS (Location) - All
5. D_TEST_VERSION (TAKS
Version) - All
6. D_EDUCATION_GRAD
E – HS (Tested Grade
Group) - 4
7. D_LEP - all
8. D_ETHICITY - all
9. D_ECONOMIC_DISADV
ANTAGE - all
10. D_SPECIAL_ED - all
11. D_GENDER all
2.0 Verify Total counts Total Count adds up to Pass Match SLC counts for
mastered plus not mastered Fail 2004
3.0 Verify # mastered counts Matches database counts Pass Match SLC counts
for mastered Fail
4.0 Verify # non mastered counts Matches database counts Pass Match SLC counts
for not mastered Fail
5.0 Vary report parameters and Numbers change as per the Note – a special report version is Pass A version of the report
check results as above selection criteria needed when multiple test Fail that accumulates results
administrations are combined and across a school year
the highest individual student score similar to the way SAT
must be taken. results are accumulated
across all administrations
is needed for yearly
results.
3.3 TAKS Summary by Test Area (Counts and Percentage)

Expected Results
1.0 1. D_SCHOOL_YEAR - 2004 Selected Parameters Counts for third and fifth grade Pass Training required as
2. D_ADMIN_PERIOD - 0404l display at the top of the cumulative reports across multiple some selections are not
3. D_CAMPUS (Location) - all Fail
report. All report areas administrations need a special logical
4. D_TEST_VERSION (TAKS
Version) - All show for a given grade. version of the since “all” in
5. D_EDUCATION_GRAD Third grade has reading Discoverer has a special meaning.
E (Tested Grade) - 4 and math. 10th grade has
6. D_LEP - all ELA, Math, Science, and
7. D_ETHICITY - all Social Studies.
ANTAGE - all
10. D_GENDER - all
2.0 Check counts for the Total equals sum of Test Area was dropping records for Pass Match SLC counts
selected criteria meeting, not meeting 2004 with results of “?”. Code Fail
adjusted to populate with zero to
ensure failure (state defined all “?”
results as failure until an update is
provided by the state with actual
results
3.0 Verify # meeting counts Matches database counts Pass Match SLC counts
for meeting Fail
4.0 Verify # non meeting Matches database counts Pass Match SLC counts
Expected Results
5.0 Vary the parameters Counts change and match Note – a special report version is Pass A version of the report
database counts needed when multiple test Fail that accumulates results
administrations are combined and across a school year
the highest score for each similar to the way SAT
individual most be taken for the results are accumulated
year. across all administrations
is needed for yearly
results.
3.4 TAKS Item Analysis

Expected Results
1.0 1. D_SCHOOL_YEAR - 2004 Selected Parameters Column with a percentage over Pass Training required as
2. D_ADMIN_PERIOD - 0404 display at the top of the 50% is highlighted in yellow. some selections are not
3. D_TEST_AREA - ELA Fail
report. Correct answer cannot be logical
4. D_CAMPUS (Location) - all
5. D_TEST_VERSION (TAKS highlighted in green in Discoverer.
Version) - all
6. D_EDUCATION_GRAD
E (Tested Grade Group) -
10
7. D_LEP - all
8. D_ETHICITY - all
ANTAGE - all
11. D_GENDER - all
2.0 Check counts for the Total equals sum of Pass Match SLC counts
selected criteria meeting, not meeting and Fail
commended.
Expected Results
3.0 Verify # meeting counts Matches database counts Pass Match SLC counts
for meeting Fail
4.0 Verify # non meeting Matches database counts Pass Match SLC counts
5.0 Verify Number Commended Matches database counts Pass Match SLC counts
6.0 Vary the parameters Counts change and match Pass May need summary table
database counts Fail for performance when all
locations are selected
3.5 TAKS Objective Summary by Student
Step Condition Expected Results Actual Results if Different than Conclusion Tester’s Comments
Expected Results
1.0 1. D_SCHOOL_YEAR - 2004 Selected Parameters Pass Training required as
2. D_ADMIN_PERIOD - 0405l display at the top of the some selections are not
3. D_TEST_AREA - Mathematics Fail
report. logical – Security restricts
4. D_CAMPUS (Location)
5. D_TEST_VERSION (TAKS access to individual
Version) students in production.
6. D_EDUCATION_GRADE -
7
7. D_LEP - all
8. D_ETHICITY - all
9. D_ECONOMIC_DISADVA
NTAGE - all
11. D_GENDER - all
12. D_TEACHER - all
Step Condition Expected Results Actual Results if Different than Conclusion Tester’s Comments
Expected Results
2.0 Vary Parameters (full access) Only students for selected Pass Order groups of students
parameters are on the Fail by number of correct
report answers.
3.6 SDAA II Expectation by Student Group (counts and percentages)

Step N° Execution Steps Expected Results Actual Results if Different than Conclusion Tester’s Comments
Expected Results
1.0 1. D_SCHOOL_YEAR – 2004 One box each for There was an invalid school year of Pass Final verification in
2. D_ADMIN_PERIOD - All Reading/ELA, Math, and 04/02 and data that was converted Production Readiness
3. D_TEST_AREA - All Fail
Writing with description in SDAA to SDAA II format for 2003 –
5. D_EDUCATION_GRAD the top box with a one line 2004 should not be loaded as
E (Tested Grade Group) – summary at the end of the results are not accurate because of
High School report missing fields.
6. D_GENDER - all
2.0 1. D_SCHOOL_YEAR – 2004 One report for math that Pass Verified all loaded
2. D_ADMIN_PERIOD - 0405 matches the results for the records were accounted
3. D_TEST_AREA - Math Fail
math section of the report for in the report
5. D_EDUCATION_GRAD when all is selected.
E (Tested Grade Group) –
10
6. D_GENDER – all
3.0 Check counts for the Total equals sum of Pass
selected criteria meeting, not meeting Fail
4.0 Verify # meeting counts Matches database counts Pass
for meeting Fail
5.0 Verify # non meeting Matches database counts Pass
Step N° Execution Steps Expected Results Actual Results if Different than Conclusion Tester’s Comments
Expected Results
6.0 Vary the parameters Counts change and mach Pass
database counts Fail
3.7 TELPAS Results by Grade Summary and Proficiency Rating (two reports)
Step N° Execution Steps Expected Results Actual Results if Different than Conclusion Tester’s Signature /
Expected Results Date
1.0 1. D_SCHOOL_YEAR - 2004 Parameters display at the Discoverer cannot create a Pass Counts match 2004
2. D_ADMIN_PERIOD - all top of the page formatted two-page report. The report created by
3. D_CAMPUS (Location) - all Fail
two-page report is separated into assessment team. Issue
4. D_EDUCATION_GRAD
two separate reports. Oracle with Christie McAuliffe
Tested Grade Group -
Elementary reports would need to be used for school not included in a
5. D_ECONOMIC_DISAD specific formatting. separate count explained
VANTAGE - all since the home school
6. D_SPECIAL_ED - all and not current school
7. D_GENDER - all was used in the report.
1. # Students Rated
2.0 Check counts for selected Minor issue with K/1 objectives Pass Counts reflect database
2. % Tested Beginning
parameters 3. % Tested Intermediate needing definitions. Counts.
Fail
4. % Tested Advanced
5. % Tested Advanced High
(new metric)
6. # Student by grade with
Comprehension score
7. Average comprehension
score by grade (Calculation)
8. # Students with Composite
rating
9. % Tested Beginning by
Grade
10. % Tested Intermediate by
Grade
11. % Tested Advanced by
Grade
12. % Tested Advanced High
13. # Students with Prior year
TELPAS record
14. # Progressing one proficiency
level
15. % Progressing one
proficiency level
16. # Progressing two proficiency
level
17. % Progressing two
proficiency level
18. # Progressing three
proficiency level
19. % Progressing three
proficiency level
20. # Progressing at least one
proficiency level
21. % Progressing at least one
proficiency level
3.0 Vary the parameters Counts change and mach Pass Counts reflect data on
database counts Fail the assessment file
3.8 AYP Report

1.0 1. School Year - 2004 Data included in summary A summary table creating the Pass The assessment team
2. Location District file to create report information required from the four will create the actual
Fail
3. Tested Grade Group – files by student was created for use reports. This check was
10th Grade by the assessment team. A single moved to production
student record is created following Readiness.
the business rules for matching
students across tests and
combining tests when multiple
records need to combined due to
rd th
retesting (for example, 3 and 5
grade TAKS).
4 Open and Closed Issues
4.1 Open Issues
ID Issue Resolution Responsibility Target Impact Date

Date
4.2 Closed Issues

ID Issue Resolution Responsibility Closed Date
1 Some SLC reports had incorrect Obtained correct numbers and verified results
counts
2 Combined results across Need special report using cumulative yearly results. Version of
administrations for TAKS existing report.
reporting where incorrect
3 Administration for July and Corrected logic to include July and August in the school year
August were reported as
unknown
4 No school year for unknown Added school years for campus 145 and unknown campuses in
campuses and campus 145 order to set Year for reporting.
5 No Campus code for graduates When creating the materialized view for SAT and ACT, used last
campus when current campus was null
6 AYP Report Requirements Proposed creation of summary AYP table containing all data
have changed. needed to create the AYP report.
Data Integration and Standardization
M9_RISD DW Operations Guide_V1.2.doc
MD.120 PRODUCTION READINESS

APPLICATION OPERATIONS HANDBOOK

RISD DATA WAREHOUSE
UPDATE AND REPORTING PROCESSES
Phase: Production
Module: Operation
Version: 1.2
Last Update:
Author(s)
Name(s) and Title(s) Signature(s) Date
Document Review
Document Approval
Version 1.2 RISD DW Application Operations Guide Page 1/40

Distribution list
Name(s) and Title(s) As an active par- For information
ticipant
X X
X X

X X

TABLE OF CONTENTS
1. INTRODUCTION............................................................................................................................ 6
2. BUSINESS ENVIRONMENT ......................................................................................................... 6
2.1 FUNCTIONALITY........................................................................................................................... 6
2.2 TEXAS MANDATED CONSTRAINTS ........................................................................................... 7
2.3 SERVICE LEVELS ......................................................................................................................... 7
3. ARCHITECTURE ........................................................................................................................... 8

3.1 FUNCTIONAL ARCHITECTURE ................................................................................................... 8
3.1.1 TECHNICAL ARCHITECTURE.................................................................................................... 10
3.1.2 SCHEMA DESIGN ....................................................................................................................... 10
3.1.3 TABLESPACE.............................................................................................................................. 10
3.1.4 PRODUCTION MACHINE DESCRIPTION.................................................................................. 11
3.1.5 SUPPLEMENTARY HARDWARE AND SOFTWARE ................................................................. 13
3.1.6 ORACLE 10g SETUP TASKS...................................................................................................... 13
3.1.7 DISTRIBUTION OF THE APPLICATIONS AND DATA ............................................................... 14
3.1.8 CONNECTIVITY........................................................................................................................... 14
3.1.9 CLIENT END USER SECURITY GROUPS................................................................................. 14
3.2 SECURITY APPROACH.............................................................................................................. 15
3.3 PORTAL – DW INTERFACES ..................................................................................................... 16

3.3.1 FUNCTIONAL PROCESS FLOW ................................................................................................ 18
3.3.2 USER ID PROVISIONING PROCESS......................................................................................... 19
3.3.3 ADD AND DELETE SECURITY ACCESS FOR EXISTING EMPLOYEES ................................. 19
4. PRODUCTION READINESS ....................................................................................................... 20
4.1 PRODUCTION CONTROLS ........................................................................................................ 20
4.2 WORKFLOW................................................................................................................................ 20
5. OPERATIONS.............................................................................................................................. 26
5.1 CONVERSION APPROACH........................................................................................................ 26
5.2 PHYSICAL ENVIRONMENT........................................................................................................ 29
5.3 RECURRING OPERATIONS....................................................................................................... 30

5.3.1 YEARLY MAINTENANCE............................................................................................................ 30
5.3.2 MONITORING .............................................................................................................................. 31
5.3.3 START UP AND SHUT DOWN PROCEDURES ......................................................................... 32
5.3.4 PREPARING ASSESSMENT FILES FOR LOADING ................................................................. 32
5.3.5 LOADING STUDENT DATA ........................................................................................................ 32
5.4 PROBLEM RESOLUTION ........................................................................................................... 32

5.4.1 ABEND PROCEDURES .............................................................................................................. 33
5.4.2 WARNING MESSAGES............................................................................................................... 33
5.4.3 GROUPS INVOLVED................................................................................................................... 33
5.4.4 DATABASE ADMINISTRATION SUPPORT................................................................................ 33
5.5 CHANGE MANAGEMENT ........................................................................................................... 33

5.5.1 OPERATIONS CONTROLLED THROUGH CHANGE MANAGEMENT ..................................... 34
5.5.2 GROUPS INVOLVED................................................................................................................... 34
5.5.3 DATABASE ADMINISTRATION SUPPORT................................................................................ 34
5.6 CHANGE MANAGEMENT ........................................................................................................... 34

5.6.1 OPERATIONS CONTROLLED THROUGH CHANGE MANAGEMENT ..................................... 35
5.6.2 PROCEDURES ............................................................................................................................ 35
5.7 BACKUP AND RECOVERY......................................................................................................... 36
6. ETL SCRIPTS .............................................................................................................................. 38
7. PRODUCTION READINESS CHECKLIST ................................................................................. 39

DOCUMENT’S HISTORY
Reference
Number of the Date Change Description Changed by
document
1.0 Draft June 16, 2004 Initial Draft
1.1 Draft June 27, 2004 Updates based on feedback
Added production readiness test list

1.2 Draft July 5, 2004
extracted from test conditions
1.0 July 12, 2004 Added Security Details

1.1 July 27, 2004 First release
1.2 August 5, 2004 Updated release

1. INTRODUCTION
This document contains summary information on the RISD Data Warehouse Application. It includes a
description of the environment, the configuration, the security policy, the operational procedures, and
RISD responsibilities.
Note: Please review the data dictionary maintained in Oracle Designer. There are special scripts writ-
ten to extract data into an Excel Spreadsheet for better formatting and easy distribution of the data dic-
tionary.
2. BUSINESS ENVIRONMENT
2.1 FUNCTIONALITY
The Data Warehouse reporting and analysis environment assists Roy Independent School District

(RISD) employees at all levels to run standard reports and perform analysis associated with student
assessments during Phase 1 of the Data Warehouse implementation. There is a history of changes for
student demographics from the RISD Student Information system along with some enrollment informa-
tion that is updated nightly. Student demographic information associated with individual assessment
tests remain static and is stored in the test area (TA) fact tables. In some cases, student demographics
are input at test time (for example, SAT) but in other cases (for example, TAKS), RISD provides pre-
coded information sheets to the state. Of course there are always some students who need to manu-
ally enter in demographics even on pre-coded tests. Local demographics are obtained from the SIS
data provided to the state (original source RIMS) and loaded with the assessment at load time. All data
is sourced from the Operational Data Store (ODS).
Primary information areas include:
1. ODS source data from state assessment CDs, RIMS, RISD Oracle HR, assessment team
spreadsheets, PEIMS data mart, EDSOFT, and the ACCESS database.
2. DW staging area for objectives and objective items for TAKS, TEKS, and SDAA II.
3. Student Assessment Information (Data Warehouse “facts” associated with the test such as test
score and pass/fail indicator).
4. DW Student Demographic Information (Information such as campus, gender, and ethnicity,
and so on)
5. Teacher – course – period – students relationships will be available as part of the enrollment
information enhancement immediately following Phase 1. DW tables have been defined in
phase 1.
6. Location hierarchies – District – Area (Cluster) – Campus Type – Campus
7. Security using Oracle’s Virtual Private Databases (VPD)
8. Supplementary tables such as PEIMS leaves and the PEIMS October submission to the state.

2.2 TEXAS MANDATED CONSTRAINTS
The Data Warehouse has stringent rules related to compliance of RISD created assessment reports
matching counts of summary reports distributed by the state. Therefore, in addition to tracking RISD
student information history from the Student Information System (SIS – currently from RIMS), RISD
student attributes associated with a state assessment are also tracked with the state assessment.
RISD provides the state with pre-coded forms for students anticipated to take the assessment. If a
RISD student taking the state assessment does not have a pre-coded form, the student will input the
data at test time. This information is all kept together in “fact” assessment tables for easy report ac-
cess. Student profiles will be kept at the local level with some key attributes such as LEP having attrib-
ute history. Items such as gender will not have history since changes to gender would normally be
considered a correction.
2.3 SERVICE LEVELS

This section defines the service commitments on the application as agreed to between the RISD end
users and the information system and infrastructure project team. Objectives include:

1. Users (employees) generally need access to the environment Monday through Friday 8 AM to
5 PM Central standard time. Most data access will be conducted Monday to Friday but as stu-
dents and parents gain access to the system, off-hour access to the report information is ex-
pected to rise. Some RISD employees will need late evening and weekend access during
heavy processing times and before the Summer Leadership Conference (SLC) in July. Parent
and student system use is expected to be heaviest immediately following the release of state
testing results.
2. Special arrangements must be made for continued Sunday access since hardware and soft-
ware maintenance is usually scheduled during the weekend, mostly on Sundays. A schedule of
anticipated down time should be available from the RISD portal. In addition, current system
update status will be available through portal.
3. All data in the Data Warehouse is sourced from the Operational Data Store (ODS). Updates of
student demographic information occur nightly with data extracted from the Student Informa-
tion System (SIS)) and stored in the ODS (initially student data will come from the RIMS sys-
tem but RIMS will be replaced in 2005 with the new student information system). Employee
and teacher updates occur nightly and associated single sign on ids are updated nightly.
Therefore, employee additions or changes in the HR system will not appear in the data ware-
house security tables until the next day unless a special update process were run manually.
Student assessment results will be available from one to eight times per year depending on
whether or not the tests have multiple administrations. An administration calendar will be avail-
able. Please note that an “administration” refers to a single local file or state provided CD and
may contain multiple test dates. Original requirements assumed each assessment would have
at least one preliminary update before a “final” assessment update ran. During development it
was determined that only one “final” update will occur. That is, data will not be loaded until all
RISD student IDS have been appended. Each update will have a DW batch id to audit records
added during a single runs that are associated with a specific administration date. Production
controls will not allow multiple updates but a manual process can be run to delete all updates
from a “batch” and the batch can be rerun (Please note that the POST_FLG in the data ware-
house DW_ASMT_BATCH file must be set to “N” and all records from the batch run removed).
After the final submission, no updates will be allowed unless the district assessment team
makes special arrangements with the production support team. Special care must be taken
when processing an assessment file that has already been marked as “final”.
4. Heavy reporting and analysis activity is expected immediately following the loading of assess-
ment files.
5. There is no formal disaster recovery plan although backups should be shipped off site for re-
covery in the event of a data center disaster.

3. ARCHITECTURE
3.1 FUNCTIONAL ARCHITECTURE

The RISD data warehouse has a single source for input data - the ODS database which stores up to 1
year of history (initially 3 years for conversion of assessment files). The RISD Data Warehouse ETL
(Extract, Transform, Load) process obtains data from the ODS using Oracle Warehouse Builder (OWB)
as the mechanized tool (documentation is also stored in OWB). These processes may call special SQL
or PL/SQL packages for preprocessing, post processing, or for special processing. For example, some
preprocessing to load DW staging tables is written in PL/SQL. The database logical and physical de-
sign is documented in Oracle Designer. The ODS system prepares the assessment data for loading
into the DW by ensuring all assessment records have a valid student ID. Records that cannot find a
student match are left null by the ODS pre-processor. The assessment team tries to assign a valid
RISD ID to all default student IDs by using an online update process. The ODS does some minor trans-
lations such as removing dashes from the social security numbers but for the most part simply acts as
a holding area for data that will be loaded into the DW. The DW load processes will maintain referential

integrity between and among tables and will drop records that do have valid student ID relationships
(this will cause an ABEND and immediate action must be taken). In order to ensure all records in each
assessment file are properly loaded, the DW processing will create “dummy” student IDs if necessary.
The District Assessment team will correct dummy student ids by selecting student Ids from a list of po-
tential matches provided by the ODS process in the event an exact match cannot be made. In the
event no match is possible, a dummy student id will be assigned by the DW update process to ensure
all assessment records are accounted for. Assessment records cannot be dropped because total
counts must match counts on the state provided reports. When as many records as possible are
matched through the correction process, a “final” DW assessment process will extract data from the
ODS, data will be loaded into the DW, and reports will be available to the general user community.
(Note – there will be only one update process). Any associated reference tables must be available in
the ODS to ensure proper descriptions are available for DW processing. For example, Objective de-
scriptions may change over time and must be updated annually. Also, processing tables such as
benchmarks for the number of correct items answered to obtain master or commended status for TAKS
reports are needed by the DW and must be updated annually. In general, these reference tables are
updated manually as needed but usually a single assessment does not change for the school year.
The process will allow them to be updated at any time before the assessment is loaded (it is common
that the new standards will only be known right before RISD receives the results). Therefore, these
reference tables will be updated in the ODS on an “as needed” basis and will not be on a set schedule
but need to be updated before the assessment for the new school year is loaded. Changing the ODS
status of a file AFTER the DW load process begins will not change data in the DW.
Assessment report creation is dependent on current ODS reference tables to be available when load-
ing assessment files and it is the responsibility of the district assessment team to schedule ODS up-
dates. The DW ETL control process will access an ODS log file (ASMT_STATS_VIEW) to determine
when a DW process needs to run. For example, a daily “cron” job can run that will read the ODS log file
that may trigger specific ETL processes. All files marked as READY_TO_LOAD in the ODS will be as-
signed a “batch ID” when run in the DW environment. The DW ETL process will update the DW and
mark the assessment file as loaded but it is the responsibility of the district assessment team to review
error logs for warnings or errors from the update processes. Some critical errors will cause the update
process to ‘abend’. In most cases, there will only be “warning” messages and the ETL process will
complete successfully. The Oracle Database manager will only allow numeric values to be placed in
numeric fields and in order to load the record with invalid data, the field with potentially “bad” data must
be defaulted to character. An alpha value in the SAT score that is used in calculations would be de-
faulted to zero. In other cases where there is a finite domain for a specific field, values not in the do-
main of values will be defaulted to unknown. Please note that the update process has no control over
the quality of the data and cannot make value judgments to correct the data.
Functional diagram of the RISD Data Warehouse process

RISDFunctional DWUpdate Processing
Conversion and Update Files
RIMS ACCESS
PEIMS EDSOFT HR
Database

Schedule
1. Corrections
State & Unmatched
Assessments Periodic ODS 2. Mark as ready
Local Student Detail
To load
Loads
District District
Staging
objectives
Post ETL Data Discoverer Plus

Processing Warehouse DWAccess
Power User
Home Page
Admin Portlet for

RISDDashboard Assessment Team
(Future)
Public or District
Employee

3.1.1 TECHNICAL ARCHITECTURE
This section describes the technical solution of the application and the related infrastructure. The fol-
lowing depicts some design considerations
1. Use of Database Compression – Database compression was discussed but since storage is not an
issue, compression will not be used. In some processes such as large table scans, compression
can help read performance but could increase write update times.
2. Use of RAID5 versus RAID 0+1 was discussed but RISD has decided to stay with RAID5 since it
has had no issues in the past. With the relatively small volumes, there should be minimal issues
initially.
3.1.2 SCHEMA DESIGN

The following database schemas will be created as part of the physical design:
OWBREP (Design Repository)
DWRISD (DW Target Schema)

RISD_DISCO_EUL (Discoverer End User Layer)
RISD_PUB (Database public connection)
3.1.3 TABLESPACE
Segment GB
Extent Man- Manage- Re-
Tablespace Description agement ment Status quired
DISCOIDX Discoverer Metadata Indexes PERMANENT LOCAL AUTO 0.5
DISCOTAB Discoverer Metadata Tables PERMANENT LOCAL AUTO 0.5
DSGNIDX Designer Indexes PERMANENT LOCAL AUTO 1
DSGNTAB Designer Tables PERMANENT LOCAL AUTO 1
DSGNTEMP Designer Temporary Space TEMPORARY LOCAL MANUAL 0.5
DWD Data Warehouse Data PERMANENT LOCAL AUTO 16
DWI Data Warehouse Indexes PERMANENT LOCAL AUTO 16
OWBIDX Oracle OWB indexes PERMANENT LOCAL AUTO 0.625
OWBRTIDX Oracle OWB runtime indexes PERMANENT LOCAL AUTO 0.625
OWBRTTAB Oracle OWB runtime tables PERMANENT LOCAL AUTO 0.5
OWBTAB OWB Tables PERMANENT LOCAL AUTO 0.5
Auxiliary space (required by
SYSAUX 10g) PERMANENT LOCAL AUTO 0.5
SYSTEM System tables PERMANENT LOCAL MANUAL 1
TEMP Temporary space TEMPORARY LOCAL MANUAL 25
UNDOTBS1 System area UNDO LOCAL MANUAL 10
USERS User area PERMANENT LOCAL AUTO 0.5

3.1.4 PRODUCTION MACHINE DESCRIPTION
The total cost of ownership, which includes maintenance and support, available information system
technical resources, and the need to incorporate additional applications in the future drove the RISD
technical team to select the multi-machine data warehouse solution using Real Application Cluster
(RAC) technology.
• 2 DL585 Processors with 4 CPU at 2.6 GHZ
• 16 GB of Memory
• 2 HPA (Fiber Channel Connections to HP SAN EVA5000)
• 2 IP connections on 2 separate cards, 2 Gigabit
• 3.5 TB disk mirrored with about 1.8 TB of usable space.
• The following outlines the RISD production environment
• Environment • Description
• Database Server • 2 HP DL 585 Processors
• 4 CPU per processor
• OID Server • 2 HP DL 385

• 2 CPU
• 2 GB Memory
• Server Storage (shared • HP EVA 5000
testing and production • 48 – 146 GB drives use for the databases
SAN) • 16 Two hundred fifty GB drives used for snapshots,
backups, and SQL loads
• 16 – 72 GB Drives – used for database logs
• Network • The RISD DW is an Internet-based application and re-
quires Internet connectivity
• Desktop • Intel Base Windows
• Microsoft Internet Explorer (IE)
• VPN Internet connection via LAN or modem
• Software • Oracle 10g AS
• Oracle 10g DBMS (10.1.0.3)
• Discoverer 10g (9.0.4.5.6)
• OWB 10g (10.1.0.2)
• Designer 10g (9.0.4.5.6)

Cisco Load Balancer
Blade Server (8 slots)

HP BL25 – 2 CPU 4 GB Memory Each

Database Servers (One DB Instance) 2 OID Instances
HP DL 585 HP DL 585 HP DL 385 HP DL 385

4 CPU 4 CPU 2 CPU 2 CPU
2.6 GHZ 2.6 GHZ 2.6 GHZ 2.6 GHZ
Processors Processors Processors Processors
16 GB Memory 16 GB Memory 2 GB Memory 2 GB Memory
RAC RAC
Fiber Channel Fiber Channel
HP EVA 5000 – Raw Data

48 – 146 GB Drives (Data)
16 – 72 GB Drives (Logs)
16 – 250 GB Drives (Snapshots, SQL Loader)

3.1.5 SUPPLEMENTARY HARDWARE AND SOFTWARE
The remainder of the DW environment includes:

ODS – there will be two instances on the single ODS machine – Development/Test, and Production.
Currently, the ODS uses disk drives directly connected to the ODS machine. In the future, ODS infor-
mation may be moved to the common SAN devise. Edbert, the name of the ODS server, has 3.06Ghz
w/2,096,666 KB ram and a 448 GB disk (330 GB of free space).
DW Development and Production – the DW will have its development/ test environment on a separate
test machine with attached storage.
Note: Initially both the ODS and DW will have a combined development/test environment. Therefore,
only two instances will need to be maintained.
Portal Server – The HB25 blade server will have 8 slots available for load balancing access to applica-

tion environment.
Software Requirements
• HP-UX 11 64-bit versions
• Oracle 10.1.2 64-bit version
• HP Software to partition the HP boxes.
• Software for Load balancing.
Other potential Software
• Veritas Software for disk striping and mirroring (Database addition with OMS Oracle Managed
Files, support)
• RMAN API to backup software is a separately purchased product provided by the tape vendor.
Some vendor support is provided. Legato Network driver may be provided as part of your standard
contract.
• Oracle Partitioning to partition large tables.
• Java tool – JDK 1.3.1 (Freeware, Required for installing Oracle 10i, available at the HP site)
• OS patches – TBD
3.1.6 ORACLE 10g SETUP TASKS
1. Determine Disk striping approach based on the Table space sizing information.
2. Confirm recommeneded mirroring approach of using Raid 0+1. (Raid 5 will be used by RISD
instead of mirroring.)
3. Install RAC.
4. Standard weekly full backups with daily incredmentals (or potentially full daily backups) will be
available. Because of low volumes of updates, it may be acceptable to perform a weekly cold
backup and rerun updates to restore the data warehouse.
5. Obtain and install all the Oracle patches needed for Oracle 10g.
6. Install Oracle instances based on the recommendation in this document.
7. Maintain naming convention standards.
8. Determine the capacity plan and rollback management strategy for the database.
Determine partitioning strategy (school year will be used)
Compression: Oracle9i Release2 and higher compresses data by eliminating duplicate values
in a database block. Compressed data stored in a database block (a.k.a. disk page) is self-
contained. That is, all database features and functions that work on regular database blocks
also work on compressed database blocks.
9. Determine the Oracle database parameters.
10. Use Oracle’s Optimal Flexible Architecture (OFA) to setup the Oracle 10g Database layout. Oracle
Corporation recommends that the OFA standard be implemented when installing and configuring
Oracle 10g databases.

3.1.7 DISTRIBUTION OF THE APPLICATIONS AND DATA
The plan calls for migrating additional applications to the RAC environment to reduce maintenance
costs. Initially, only the Data Warehouse and the new Student Information System (SIS) will run in the
new production environment. The SAN may need to be expanded, as more space is needed as appli-
cations migrate to the new environment.
3.1.8 CONNECTIVITY
See RISD network infrastructure for more information.
3.1.9 CLIENT END USER SECURITY GROUPS

The following table outlines the security groups set up for access to student information. All groups are
permitted to view aggregate information at the campus, areas, or district level.
Security Group Student Student Detail Description Notes

Detail
Student and Parent (future) Yes Only the individual Student Identified in the DW by RISD
student ID. Need relationship
between student and parent
in the ODS and map the rela-
tionship for use in security
Teacher Yes Current students, all as- Identified in the DW by the
sessments. . employee ID and linked to the
SIS teacher ID by social secu-
rity number. Uses RIMS
teacher – course – period re-
lationship to obtain students
Campus Admin (includes assis- Yes All students currently on Identified in the employee file
tant principal, advisors, and so on) campus and incoming by employee ID to obtain and
class. role and campus.
Principal Yes All students currently on Identified in the employee file

campus and incoming by employee ID to obtain and
class. role and campus
Area (Cluster) Admin (Note – after Yes All students currently in the Identified in the employee file
design, area was replaced by area and incoming class. by employee ID to obtain and
cluster which is a collection of Needs mapping of campus role and area.
campuses. to cluster.
Area Superintendent Yes All students currently in the Identified in the employee file
Area. by employee ID to obtain and
role and area.
Central Admin Yes No Restrictions. Identified in the employee file
by employee ID and role
Central Superintendent Yes No Restrictions. Identified in the employee file
by employee ID and role
School Board No N/A Summary assessment data
marked as final.
Public (future) No N/A Summary assessment data
marked as final
District Assessment Team Yes No Restrictions Identified through employee
ID and role entered through a
mechanized update process
Please note that role based security and VPD will be used. The DBA must be familiar with the security
design. VPD security will be at the student dimension level. Any aggregate data associated with stu-
dent dimension that needs to be available to all users will need to be stored in summary tables (Exam-
ple, portal student summary reports). Please note that the assessment fact tables only contain a surro-
gate key and individual students cannot be identified. Therefore, materialized views can be used
against the assessment fact tables. Please note that security MUST be applied against any tables con-
taining information that can specifically identify a student (including materialized view). Regular views
against a student level table with carry the security features over to the view. It is important to identify
database objects using the suffix _V or _MV to easily identify objects that are straight views versus
objects that are materialized views since materialized views must be considered when changing the
security policy or when new objects are added to the database. Any student level report trying to ac-
cess specific student data will only return data for which the user has access authority. Role based se-
curity will ensure that users will need to access the database via Discoverer Viewer or Discoverer plus.
The District assessment team (including developers) will have full access to the database.
The ODS maintains the following tables for security

RISD_PORTAL_RESPONSIBILITIES
RISD_DW_USER_RESP_GROUPS
SIS_SCHEDULE (future)

RISD_EMPLOYEES
SIS_TEACHERS
The data warehouse uses the following tables for security

D_ACCESS_LEVEL
D_PEOPLE_LOCATION_ACCESS
D_DISTRICT_PEOPLE
F_STUDENT_ACCESS
FS_STUDENT_SECURITY
3.2 SECURITY APPROACH
Assumptions:
1. There is at least two Oracle Discoverer Ids available from portal (RISD_PUB and
RISD_DISCO_EUL). There will also be a minimum number of required Ids for direct type connec-
tions (SQL*Plus, toad, and so on) for the Assessment Team and Development.
2. Portal connections will provide the SSO name to the database.
3. The SSO name will be assigned to a RISD employee (or “dummy” employee) and carried in the
employee table.
4. Matching between teachers in the teacher’s table and the employee table will be done via social
security number.
5. Each employee will be assigned one or more Access Level codes. Upon login, the highest level of
access to which an employee is assigned will be selected as that employee’s access privilege. For
example, if a teacher also has campus administrator rights, the employee would be given the
higher campus administrator rights.
6. Users may have multiple records in the employee table if they have access to multiple campuses
and/or have multiple responsibilities. For example, a campus administrator may have responsibili-
ties at multiple campuses.
7. Assessment team, Central employees (Administrators and Superintendent), Developers, and the
Discoverer Administrator will be exempt from additional student security.
8. Access to individual students is provided by a student access list created during the ETL process.
9. Portal will control database access through Discoverer but the added security will ensure no user
who can somehow gain direct access can view unauthorized student data.
Access from Portal - The SSO Name will be looked up in the DISTRICT_PEOPLE table to obtain the
PERSON_ID. The highest Access Level will be selected and assigned to the person. The VPD predi-
cate will be set.
Direct Database Access - The user’s roles are checked for Access Levels. If the user has a role that
corresponds to an Access Level then it is assumed that the user has access to all students (only
selected folks will have direct database access as most users will use Discoverer access). The Roles
then determine the remaining access to the DB.
1. Create Access Levels (code – alter4scty.txt)

2. Coordinate access levels with ods/portal responsibilities
3. Create DB Roles based on access levels (code – scty_cre8_roles.sql)
4. Create DB Users
5. Grant Roles to DB Users
6. Process
a. Truncate:
i. f_student_security;
ii. f_student_access;
iii. d_people_location_access;
b. Run daily ETL
c. Load d_people_location_access
d. Load f_student_security
General:

As noted, there are two access paths to the RISD Data Warehouse, access via Portal employing SSO
and direct access to the database using Oracle user names.
People granted access to data via Portal will be identified using SSO and must be in the District People
table. They must also be assigned Access Levels. During connection, the person will be confirmed as
an authorized user by checking the SSO name in the District People table. If the person exists he/she
will be granted access to any tables where an individual student cannot be identified. That is, tables
using surrogate keys will not have security applied to them. The user’s access levels will determine the
student data the user has permission to view.
Direct access users may connect to the database using various tools (SQL*PLUS, TOAD, and so on).
These users require Oracle database login IDs. For access to RISD data, they are required to be
granted an access role. These roles determine the user data access levels. Currently, direct access
with an access role is assumed to be exempt from access restrictions and may see any data in the sys-
tem. Should this change in the future and varying levels of access are required, the user must be en-
tered into the District People table with the SSO_NAME column being set to the user login. In addition,
the user will require a location (campus or area). When the user connects, the user’s roles determine
the data access level permitted. If the user has a valid role, the access level then defaults to the Stu-
dent detail level.
Notes:
1. Access levels must be synchronized with responsibilities in the “risd_portal_responsibilities”
table.
2. Access levels (code) must have a role created for direct access with restrictions.
3.3 PORTAL – DW INTERFACES
Hardware options were provided in the architecture document. It is likely that the option to have a sin-
gle load balancer will be used to help reduce initial costs. RISD has decided to use a single load bal-
ancer. Implementing this option will be the least expensive alternative but there will be no redundancy.
The MR database is a RAC database with two OID Instances.
SSO, Portal and Discoverer middle-tiers reside in the DMZ, while OID and the RAC database is
not.

Single Sign on
There will be a single sign-on process where one of the portlet options will be to go to the data ware-
house portal. The original idea to use tabs was modified but it is likely tabs will be used in some form.
There will initially be a dashboard report that is updated daily that displays student enrollment informa-
tion. Please note that at some point an administration portlet that provides users in the assessment
team security group with the ability to review the data warehouse update logs to ensure all data was
properly loaded will be added.
It is critical that objectives and objective items keys provided by the assessment team match the actual
objectives and objective items provided on the assessments for TAKS, TEKS, and SDAA II. See sec-
tion 4.2 Workflow.
Note: It is highly recommended that RISD create a process in the ODS environment to ensure the ob-
jective and objective item keys created by the assessment team and loaded into the ODS match the
actual keys on the assessments for TAKS, TEKS, and SDAA II. A more comprehensive alternative
would be to extract all objectives and objective items from the assessments and create an update

process to add additional mapping information. This would ensure the keys would match data on the
assessment file. RISD plans on implementing an Oracle form that will control the input process since
many manual input errors were detected and corrected during the testing process.

3.3.1 FUNCTIONAL PROCESS FLOW
RISD Functional DW Update Processing
Conversion and Update Files
RIMS ACCESS
PEIMS EDSOFT HR
Database

Schedule
1. Corrections
State & Unmatched
Assessments Periodic ODS 2. Mark as ready
Local Student Detail
To load
Loads
District District
Staging
objectives
Post ETL Data Discoverer Plus

Processing Warehouse DW Access
Power User
Home Page
Admin Portlet for

RISD Dashboard Assessment Team
(Future)
Public or District
Employee

3.3.2 USER ID PROVISIONING PROCESS
1. Self Service signup will be used – Sample code was provided to RISD by Oracle Consulting.
2. Initially, only employees in the HR employee table will be allowed to self-register. However, non-
employees such as consults will be assigned “dummy” employee Ids that will allow them to self-
register.
3. The user ID will be populated in the ODS employee table via a predetermined algorithm. Employee
information is sourced from RISD HR.
4. The process to populate the employee table with the user ID will also map the HR job description
to the Data Warehouse security group. The employee table will be updated daily in both the ODS
and DW.
5. The self-service sign up process will access the ODS table by employee id or user ID. The self-
service sign up process will activate the user ID in the employee table if the person is able to an-
swer selected questions such as date of birth and perhaps social security number.
6. The user ID and password will be maintained in the Oracle Internet directory (OID).
7. RISD must develop a process to change passwords and deactivate user IDs. In addition, a process
to inactivate user IDs for inactive employees must be developed as part of the ODS update proc-

ess.
8. In some cases the security level cannot be determined from the HR job description. All employees
in the HR employee file not having a specific mapping will default to public security access. (Note,
many employees such as teachers and principals will have a mapping)
9. Some employees may belong to multiple security groups but HR only allows one job description.
10. RISD will develop a process to allow an employee to belong to more than one security group. For
example, Jennifer Busse, Daniel Long, and Elvia Noriega will be given District Assessment Team
security access in addition to public access.
Maintaining the Security Table in the ODS

1. The ODS receives a daily input file of employees from HR which is loaded into a temporary staging
table.
2. The temporary table is merged with the ODS employee table (empty initially). New employee re-
cords are added (user ID and security group created), existing employee records are replaced
(only the ones marked as HR records but the user ID remains the same to avoid confusion for re-
turning employees registering via portal), and employee records no longer in the HR employee ta-
ble are deleted from the ODS (all records including supplementary records – they may be logically
deleted since employees can be rehired.)
3. Employees can be added to the employee table provided by HR as “dummy” employee ids to set
up Ids for non-employees such as consultants and the RISD school board.
4. An Oracle form will be created to add or delete supplementary security groups for an employee. A
process to merge the HR daily employee file with the existing security table must be developed to
ensure security records added through the Oracle form are not overwritten.
3.3.3 ADD AND DELETE SECURITY ACCESS FOR EXISTING EMPLOYEES
1. Screen prompts for employee ID.

2. If a match is found, employee information is displayed.
3. The security administrator is prompted to confirm the employee information is correct in order to
continue.
4. Screen prompts for ADD or DELETE (and perhaps update depending on design).
5. If the ADD option is selected, the screen displays the security groups available (a process to add
“dummy” employee Ids may be considered).
6. The security admin selects the group or groups to be added.
7. The system confirms the selection and user selects continue if correct.
8. ADD function is run and the new employee security access is displayed.
9. If the DELETE option is selected, the screen displays the security groups that the employee cur-
rently has.
10. The security admin selects the group or groups to be deleted (primary group from HR excluded).
11. The system confirms the selection and user selects continue.
12. DELETE function is run and the new employee security access is displayed.
4. PRODUCTION READINESS
This section depicts the ETL process and shows the technical components that need to be checked
after each release of ensure changes can be moved to production.
4.1 PRODUCTION CONTROLS
The daily DW processes checks the ODS ASMT_STATS_VIEW that accesses the following informa-
tion. Only assessments with the READY_TO_LOAD indicator set to “Y” will be considered.
TEST_CODE

Domain is (TAKS, TEKS, SDAA, TELPAS, SAT, PSAT, AP, ACT, LDAA)
Note: ERWA and Tejas Lee (TLEE) will only be loaded for conversion and are not in the normal update
files.
DSET
This code the ODS uses in its processing and provides a unique identifier to all records in a particular
file. The DW processing create a batch ID for the DW using this field
READY_TO_LOAD
Domain is (Y or N). When the assessment team finishes appending RISD student IDs, this field should
be set to Y. When the nightly DW process runs, the DW will pick up all records in the designated as-
sessment area with the source dates that have the indicator set to Y. After the update in the DW, the
DW control file DW_ASMT_BATCH will note that the file has been processed. Once a file is processed,
it cannot be reprocessed without special manual intervention from the RISD technical staff.
The DW_ASMT_BATCH table controls the update process for assessments.
ASMT_CODE - Domain is (TAKS, TEKS, SDAA, TELPAS, SAT, PSAT, ERWA, AP, ACT, TLEE,
LDAA)
DSET - The code the ODS uses in its processing and provides a unique identifier to all records in a
particular file.
BATCH_ID – The internal DW batch identifier that indicates a single assessment load for the data
warehouse.
STATUS_CODE – Code is set to “F” for final after the update process completes.
LAST_POST_DATE – This field represents the posting date for when the process completes.
POST_FLAG – Set to N for new when process begins, set to P for prepped when process after
student Ids are validated. Set to “Y” when the process completes
4.2 WORKFLOW
Overview
1. Student updates must occur first during the nightly run. This ensures all RISD students poten-
tially on the assessment tables are available even though it is unlikely a student will be added
the day an assessment file is ready for processing.
2. All employee tables must be loaded daily into the DW.
3. PKS_PRELOADS_MAIN – Updates the FH_ASSESSMENT_ADMINISTRATION table.

4. PKG_RISD_COMMON – Checks that all matched students in the assessment file are in the
D_STUDENT dimension table. If missing, process abends and the flow is terminated.
5. PROCEDURE_STUDENT_ASMT_DIM_LOAD – Loads default students to the D_STUDENT
dimension and the FH_STUDENT_HISTORY.
6. PROCEDURE_ASMT_LOAD – Loads data into the appropriate fact tables based on the as-
sessment. When the load completes, sets the STATUS_CODE to “F” for final.
Oracle workflow will manage the update processes. Below are the high level processes that will be
controlled from a single master process.
1. Daily student update process – Controls updating Student information from the SIS tables updated
in the ODS on a daily basis. Also updates the employee security table daily. Please not that some
smaller tables are complete reloads to simply the RISD maintenance processes.
2. Periodic update of assessment data – There is a single process that controls the updating of all
assessment and other periodic data updates that will run daily. The process checks the ODS for
assessment files that are “READY to RUN” that have not been processed in the data warehouse.
There will only be one update process for each assessment and upon completion the posting flag

will be set to ‘Y’ (YES). Please note that this process needs several standards and objective map-
ping tables in the ODS. These files are currently updated manually. This includes the periodic
PEIMS update. If a process is run before the lookup data is updated, records will be dropped. It is
the responsibility of the ETL support person to review the update logs to ensure all data is loaded
until the mechanized review from portal is available. The following diagram shows the TAKS as-
sessment update process. The SDAA II process has the same process flow. Please note that the
RISD_ASSESSMENT_TARGET table is updated into the data warehouse RISD_OPS_PARMS.
The following diagram shows the SIS and HR daily data interfaces.
F_STUDENT_ACCESS
F_STUDENT_SCHEDULE
SIS Tables in the ODS
FH_STUDENT_HISTORY
MULTIPLE STUDENT DIMENSIONS
RISD_EMPLOYEES
D_DISTRICT_PEOPLE

The following diagram shows the TAKS update process.
(A). RISD_ASMT_TEST Keys Must Match
Assessment Keys 2. D_OBJECTIVE
RISD_ASMT_PASSING_STANDARD
RISD_ASMT_OBJECTIVE_KEYS
RISD_ASMT_ITEM_KEYS D_OBJECTIVE_ITEM
ODS
2. STG_TAKS_HDR
STG_TAKS_READ 3.
STG_TAKS_ITEM
STG_TAKS_ELA
RISD_TAKS_TEST STG_TAKS_MATH
ODS STG_TAKS_SOCSTUDY
STG_TAKS_OBJECTIVE
STG_TAKS_SCIENCE

STG_TAKS_WRITE
1. ASMT_STATS_VIEW
STG_TAKS_LDAA
(ODS) 4.
F_TAKS_STUDENT_OBJ_RESULTS
F_TAKS_STUDENT_TA_RESULTS
F_TAKS_STUDENT_ITEM_RESULTS
LDAAUpdate
Process
1. DW_ASMT_BATCH
DW_ASSESSMENT_ADMINISTRATION
1. An automated process runs and reads the ASMT_STATS_VIEW to determine if any assessment
administration files are ready for processing. There is a simple READY_TO_LOAD indicator that is
set to “Y” by the assessment team when the assessment file is ready to load into the DW. If the in-
dicator is set and the DW process has not run the process yet, the process updates the
DW_ASMT_BATCH and DW_ASSESSMENT_ADMINISTRATION with the ASMT_STATS_VIEW
information and information from the RISD_TAKS_TEST to monitor the DW process.
2. RISD_TAKS_TEST data is staged to multiple files. The STG_TAKS_LDAA table is used in the
LDAA update process. The remaining staging tables are specific to test areas (subjects).
RISD_TAKS_TEST and several ODS standards tables (A) are used to update D_OBJECTIVE and
D_OBJECTIVE_ITEM.
3. To simplify the update process, the staging tables in (2) are further separated into staging tables
for objectives and objective items (STG_TAKS_OBJECTIVE and STG_TAKS_ITEM).
4. The staging tables in (3) are used to update the actual student objective and item fact result tables
(F_TAKS_STUDENT_OBJ_RESULTS and F_TAKS_STUDENT_ITEM_RESULTS).
The following diagram shows the SDAA load. Note that there is no test area for social studies or sci-
ence in SDAA.

(A). RISD_ASMT_TEST Keys Must Match 2.
RISD_ASMT_PASSING_STANDARD Assessment Keys D_OBJECTIVE
ODS
2. STG_SDAA_HDR
STG_SDAA_READ 3.
STG_SDAA_ITEM
STG_SDAA_ELA
RISD_SDAA_TEST STG_SDAA_MATH
ODS STG_SDAA_WRITE
STG_SDAA_OBJECTIVE

1. ASMT_STATS_VIEW
(ODS) 4.
F_SDAA_STUDENT_OBJ_RESULTS
F_SDAA_STUDENT_TA_RESULTS
F_SDAA_STUDENT_ITEM_RESULTS
1. DW_ASMT_BATCH

The following diagram shows the TEKS load.
(A). RISD_ASMT_TEST Keys Must Match 2.

RISD_ASMT_PASSING_STANDARD Assessment Keys D_OBJECTIVE
ODS
RISD_TEKS_TEST 2. STG_TEKS_TEST
3. STG_TEKS_ITEM
ODS

1. ASMT_STATS_VIEW
(ODS) 4.
F_TEKS_STUDENT_OBJ_RESULTS
F_TEKS_STUDENT_TA_RESULTS
F_TEKS_STUDENT_ITEM_RESULTS
1. DW_ASMT_BATCH
The following diagram shows the remainder of the assessment update that do not use staging tables
since they do not have objectives and objective items associated with them (TELPAS, SAT, PSAT, AP,
ERWA, Tejas Lee, ACT). The example shows the SAT update. Please note that some processes in-
clude a post process to create summary files and/or database views to simplify reporting.
2. (A). RISD_ASMT_TEST
ODS
2. RISD_SAT_TEST
2. F_SAT_STUDENT_TA_RESULTS
ODS
1. ASMT_STATS_VIEW 1. DW_ASMT_BATCH
(ODS) DW_ASSESSMENT_ADMINISTRATION

The following diagram shows the LDAA flow. Please note that there are two pieces to the LDAA update
process. One comes from the LDAA section within the TAKS assessment and the second comes from
a spreadsheet provided by the assessment team. The TAKS process will trigger the LDAA portion of
TAKS and the spreadsheet process will be triggered independently when the ODS spreadsheet infor-
mation is available.
2. (A). RISD_ASMT_TEST
ODS
2.STAGE_TAKS_LDAA

2.STAGE_SDAA_LDAA 2. F_LDAA_STUDENT_TA_RESULTS
2. RISD_LDAA_TEST
ODS
1. ASMT_STATS_VIEW 1. DW_ASMT_BATCH
(ODS) DW_ASSESSMENT_ADMINISTRATION
The following diagram shows the PEIMS interface.
RISD_PEIMS_GRADUATES F_PEIMS-LEAVERS
RISD_PEIMS_FALL_SUBMISSION F_AYP_BASE
The following DW tables are updated manually and are not expected to change.
1. D_ACCESS_LEVEL
2. D_CAMPUS_TYPE
3. D_EDUCATION_GRADE

The following diagram shows the annual Update process
RISD_ASSESSMENT_TARGETS RISD_OP_PARMS
D_ASSESSMENT
RISD_LOOKUP_CODES D_CAMPUS
D_ASMT_PASSING_STANDARS
RISD_ASMT_CALENDAR D_ASMT_CALENDAR

RISD_SCHOOL_CALENDAR D_SCHOOL_YEAR
Summaries and materialized Views
Many processes will have post processes to create fields to make reporting easier or to improve per-
formance. The following are some examples.
ACT
FS_ACT_STUDENT_RESULTS - lowest level

FS_ACT_RESULTS -intermediate
FS_ACT_SUMMARY -high level - year totals (only conversion years available)
SAT
FS_SAT_STUDENT_RESULTS - lowest level

FS_SAT_RESULTS -intermediate
FS_SAT_SUMMARY -high level - year totals (only conversion years available)
5. OPERATIONS
This section defines all the operations that may be carried out for the application.
5.1 CONVERSION APPROACH

The Operational data store will be the source for all Data Warehouse information. Some spreadsheets
currently used by the assessment team have been manually loaded into the data warehouse. At some
point, an Oracle form will be created to update information such as the assessment standards for as-
sessment metrics such as passing and commended. The controls to load this information must be
added to the ODS log file. For the conversion process, all assessment administrations needed for con-
version will have the READY_TO_LOAD indicator set to “Y”. The student update process (from RIMS)
and the employee update process (from HR to add security responsibilities process) that normally runs
nightly, will add all student records and employee records during the initial run. Note that the PEIMS
file is also loaded manually. Updates of lookup tables in the ODS will to be run manually until the
mechanized Oracle form is developed. For conversion, the ETL process will be reviewed as part of the
development effort. Ongoing review is part of the ongoing RISD operational responsibilities.

The following documents the conversion process used to load the ODS.
State Assessments
1. TAKS
2. SAT
3. PSAT
4. ACT
5. AP
6. TELPAS
7. SDAA II
RPTE was loaded into the ODS but not into the DW since TELPAS will replace RPTE and TELPAS
has an RPTE section. SDAA was converted into SDAA II format for years prior to 2004 but many new
SDAA II fields were defaulted. Only 2004 SDAA II data will be loaded at conversion.

TAKS load into the ODS:
1. Flat files from Assessment Team

2. Save the file to flat file folder c:\datastore\flat_files\taks\2004\taks0304 Eng.txt
3. Copied the file from the above directory to c:\datastore\fileload\taks0304 Eng.txt
4. Change loader file: change infile name in the control file with the name of the text file.
Source_date with the text file name. source_date is a constant
5. Check log file. C:\datastore\risd_taks.log to make sure all the records are successfully loaded.
If not, you can do either way: delete the whole batch by using the source_date and re-load or
check the .bad file and fix the bad file and re-load.
6. Select * from risd_taks_test where source_date = ‘taks0304 Eng.txt’; quickly check every col-
umn to make sure the batch looks correctly.
7. Select count(*) from risd_taks_test where source_date = ‘taks0304 Eng.txt’;
8. Document this loading with date, filename, total number loaded.
9. Manually run automated match process to append RISD Student Id.
10. Run on-line process to select correct RISD Id from multiple near matches.
11. Manually set the READY_TO_LOAD indicator to “Y”
Note:
The above process was automated to load the data directly from a CD provided by the state in a true
production environment. A central on-line ODS process loads the data and automatically runs the
match process to append the RISD student Id. The on-line process also allows the assessment team to
run the follow up process to select the correct student Id for closely matched records. The final func-
tionality in the on-line process allows the assessment team to set the READY_TO_LAOD indicator to
“Y”.
Edsoft Local Assessment Extracts for ERWA & TEJAS LEE:
1. File is in .csv format, extracted from EdSoft. Last column is usually unpredictably long. You
have to adjust the substr function in loader script to make sure that every row can be loaded.
There are three loader scripts for the three grades.
2. Save the file in the flat file directory c:\datastore\flat_files\erwa\2004\ 2004 ERWA KN
MOY.xls
3. Change loader script: change infile name with the .csv file name and source_date with the in-
coming file name.
4. Run loader script at MS-DOS promp cd datastore\loader\erwa(tejaslee)\ risd_erwa_kn.ctl
5. Check log file to make sure every record is loaded c:\datastore\risd_erwa_kn.log
Access Database Local Assessment - TEKS
TEKS: K2Math was converted to TEKS format and merged into the TEKS ODS table. Future
K2Math data will be included in the TEKS file.

1. Log in to Access DB and join table_number_key to 2003-2004 TEKS tool data (MS Access
Database Administrator separates TEKS data from TAKS so that the process of filtering TAKS
from the data set can be eliminated in production). Export the file in .txt file format. Save in
c:\datastore\flat_files\TEKS\teks_file.txt.
2. Copy the file to fileload directory. C:\datastore\fileload\teks_file.txt
3. Check the loader script and change the infile name
4. Run loader script at MS-DOS prompt like other files.
5. Check the log file to make sure every single record is loaded to the table.
Loader script names:
risd_act.ctl
risd_ap.ctl
risd_erwa1.ctl
risd_erwa2.ctl
risd_erwa_kn.ctl
risd_k2_math.ctl

risd_ldaa.ctl
risd_psat.ctl
risd_rpte.ctl
risd_sat.ctl
risd_sdaa2.ctl
risd_taks.ctl
risd_tejas_kn.ctl
risd_tejas_grd1.ctl
risd_tejas_grd2.ctl
risd_teks.ctl
risd_telpas.ctl
RISD HR employees: (RISD_EMPLOYEES)
PL/SQL procedure is scheduled to run every night in ERP concurrent manager. ODS update employee
program needs to be automated to update employee file in ODS.
PEIMS Leaver File (RISD_PEIMS_GRADUATES)
PEIMS data can be retrieved via DB link and needs to be automated.
Supplementary Files
RISD_ASMT_TEST – Manually loaded from Assessment team spreadsheet into the ODS.
RISD_ASMT_OBJECTIVE_KEYS – Manually loaded from Assessment team spreadsheet into the
ODS for TAKS, TEKS, and SDAA II.
RISD_ASMT_ITEM_KEYS – Manually loaded from Assessment team spreadsheet into the ODS for
TAKS, TEKS, and SDAA II.
RISD_ASSESSMENT_PASSING_STANDARD – Manually loaded from Assessment team spreadsheet

into the ODS.
RISD_LOOKUP_CODES – Descriptions for codes consolidated from multiple sources into a single ta-
ble.
RISD_ASSESSMENT_TARGETS – Manually created table with targets for ACT, SAT, and AP.
RISD_SCHOOL_CALENDAR – Created from the PEIMS 3 submission and used to obtain total school
days by campus to determine student mobility..
RISD_ASMT_CALENDAR – manually loaded from a spreadsheet provided by the assessment team.

5.2 PHYSICAL ENVIRONMENT
Please refer to the installation guides for the physical machine environment created by the infrastruc-
ture group. Please refer to the Data Architecture and Physical Design document as a reference point
for the set-up of the application architecture and the physical database environment.

5.3 RECURRING OPERATIONS
This section describes the recurring operations that ensure a good working order. The high level func-
tional processes are documented in section 3.1. As noted, most processes are automated and will run
on a daily basis. In addition, members of the assessment team may trigger assessment updates that
need to be run in real time. For example, after correcting student Ids for a specific assessment admini-
stration, it is likely the assessment group will load the assessment immediately.
Note: Occasionally, a student on an assessment will be identified after the process is loaded. Since the
student will be loaded into the D_STUDENT table under a dummy ID, the student ID can be updated
with the actual student ID at any time. Since surrogate keys are used, all existing relationships would
continue to exist and the student would be reported properly. A simple form could be developed by
RISD to address this special situation. Of course, a manual update is an option if this is a rare occur-
rence.
The following first letters in the student ID can identify “Dummy” student Ids.

ACT A
AP - B
ERWA C (Conversion files only)
K-2 MATH D (K-2 Math merged with TEKS)
LDAA E
PSAT F
RPTE G (Replaced by TELPAS)
SAT H
SDAAII I
TAKS J
TEJAS LEE K (Conversion files only)
TEKS L
5.3.1 YEARLY MAINTENANCE

The items in this section refer to normal annual maintenance of assessment standards. Changes to
database inputs or enhancements to the Data Warehouse environment are addressed in the change
management section.
State Assessments – State assessment are provided on CD. Changes to the format will cause
changes to the ODS and DW processes. Please note that the manual conversion process was auto-
mated.
TAKS
SDAA
TELPAS
AP
ACT
SAT
PSAT
Local Assessments From EDSOFT – Changes to the format of input records will cause changes to
the ODS and DW processes. Conversion process needs to be automated. Note – the two files below
will have raw data loaded into the DW from conversion files but no benchmark results have been
loaded since these assessments have been discontinued.
ERWA / TPRI
Tejas Lee

Local Assessments From ACCESS Database – Changes to the format of input records will cause
changes to the ODS and DW processes. Conversion process needs to be automated.
TEKS
Excel Spreadsheet from Assessment group – Conversion process needs to be automated
LDAA spreadsheet manually created by the assessment team and loaded into the ODS manually.
This is a once a year process so a manual load may not be worth mechanizing but great care must
be taken to ensure the quality of the data before loading. Please note that additional LDAA data is
provided by the TAKS and SDAA II assessment feeds and are loaded separately in the DW stag-
ing process and loaded into the LDAA assessment area. The SDAA II and TAKS LDAA information
is needed to create the AYP summary tables used to create the AYP reports.
Local Student information – SIS data obtained through a daily interface with RIMS. This process will
be updated in the ODS to obtain student information from the new SIS environment in the 2006 – 2007
school year.

Employee information – Data is obtained from the HR system with an on-line update process to add
security responsibilities for existing employees. A separate process must be developed to add student
and parents responsibilities in the future. DW employee updates will run as part of the daily DW update
process.
PEIMS Leaver information (RISD_PEIMS_GRADUATES) – The PEIMS leaver file is primarily used to
identify graduates but all students who leave the district with a reason code are available. This file is
updated manually but the update should be automated.
Supplementary Tables – Many supplementary processes are needed to update standard and lookup
information needed by the DW process. These ODS tables are needed by the update processes
documented in an earlier section but do not have stand-alone update processes.
RISD_ASMT_TEST – Manually loaded from Assessment team spreadsheet into the ODS.
RISD_ASMT_OBJECTIVE_KEYS – Manually loaded from Assessment team spreadsheet into the
ODS for TAKS, TEKS, and SDAA II.
RISD_ASMT_ITEM_KEYS – Manually loaded from Assessment team spreadsheet into the ODS for
TAKS, TEKS, and SDAA II.
RISD_ASSESSMENT_PASSING_STANDARD – Manually loaded from Assessment team spreadsheet

into the ODS.
RISD_LOOKUP_CODES – Descriptions for codes consolidated from multiple sources into a single ta-
ble.
RISD_ASSESSMENT_TARGETS – Manually created table with targets for ACT, SAT, and AP.
RISD_SCHOOL_CALENDAR – Manually loaded from a spreadsheet provided by the assessment
team.
RISD_ASMT_CALENDAR – manually loaded from a spreadsheet provided by the assessment team.
Add additional detail on manual processes here.
5.3.2 MONITORING
All DW update jobs are scheduled nightly. The ODS log file will be checked to determine what, if any,
assessment updates are needed. Student updates from RIMS and employee updates from HR occur
nightly in the ODS. The DW update process can be dependent on the ODS process or simplify sched-
uled after the ODS process. The DW updates are dependent on new files being available in the ODS.
Student updates are reviewed on a daily basis to keep the ODS and DW in sync.

5.3.3 START UP AND SHUT DOWN PROCEDURES
The application should always to available except during hardware maintenance that usually occurs on
Sundays. “Cold” full database backups occur nightly. All documented operational procedures must be
followed before taking the database off line. The database instance must be taken off line for mainte-
nance. After hardware maintenance is complete, the database is brought back online using standard
DBA functions. Since there is potentially a 7-day a week schedule, down time is usually scheduled for
a Sunday since it will have the least impact on end users. However, as public access is permitted,
there is the likelihood of increased weekend and night activity. In addition, the instance must be re-
started when changes are made to the environment.
5.3.4 PREPARING ASSESSMENT FILES FOR LOADING

Assessment data must be loaded into the Operational Data Store (ODS) and the process to append
the RISD student ID must be run. The process begins with the RISD Assessment team receiving the
Assessment CD. Assessments will be loaded into the Operational Data Store (ODS) as files become
available. A matching process will append the RISD student ID to all records. Records that do not

match will be sent to a correction file that will be used by the RISD assessment team to determine the
proper student id. Records that cannot be assigned a RISD id will be set to null.
The data warehouse will have a process that can be automated to run nightly to process any new as-
sessment files available in the ODS. The assessment team will also have the ability to initiate the proc-
ess immediately.
The assessment team assigns student Ids to assessment records and when the assessment team is
satisfied with the results, the assessment is set to READY_TO_LOAD and the assessment is loaded
into the DW and set to final. All users will have access to the data and the reports.
1. Assessment team member begins the on-line process to load the Assessment information when
the assessment CD is available (or the local assessment data is available).
2. Data is loaded into the ODS from the CD (or from a flat file for local assessments) and the auto-
mated match process runs to append the RISD student id.
3. The assessment team reviews the results from the match process and runs the RISD student ID
correction process. Each student id that cannot be fully matched is presented on-line to the as-
sessment team member with multiple potential matches. The assessment team member selects
one of the potential matches, inputs an override student id, or leaves the student Id as unknown
(null values are expected by the DW process for unknown students).
4. After the student Id correction process is complete, the assessment team member can mark the
ODS file as READY_TO_LOAD.
5. Each night, a DW update process will check the ODS log file to see if there are any update proc-
esses to run. The assessment team member also has the ability to run the DW process immedi-
ately. When the assessment process runs, a DW batch ID is assigned to the assessment and ad-
ministration.
6. DW control will not permit the updating of a file marked as final in its control file. If someone
changes the update indicator manually in the ODS file, the DW process will not apply the update
since the internal DW process has the update marked as final.
5.3.5 LOADING STUDENT DATA

The process to update student data will run nightly and no intervention is needed. However, please
review the next section on investigating operational problems.
5.4 PROBLEM RESOLUTION

The assessment team is responsible for reviewing the update results of all DW load processes. A fu-
ture portlet will be available in portal that provides assigned users access to statistics provided in the
OWB runtime repository.

5.4.1 ABEND PROCEDURES
1. The ETL support person is responsible to resolve abends.
2. A simple report can be written where the assessment team could verify results and contact the
ETL support person in case of errors.
5.4.2 WARNING MESSAGES

Warning messages are provided in many cases when fields with errors are detected during the load
process. These warning should be reviewed as data could be corrected in the source system to avoid
future errors.
5.4.3 GROUPS INVOLVED
Scope Name Phone Email

ODS Issues Norma Comer
Data Warehouse Issues Norma Comer
Discoverer Report Issues Jean Liu
5.4.4 DATABASE ADMINISTRATION SUPPORT

There is a DBA that supports both development and production. The development DBA is responsible
for the logical design and the test environment while the production DBA is responsible for the physical
design and the physical environment.
5.5 CHANGE MANAGEMENT

This section defines the change management process for the application.
There are two independent environments that need to be maintained in the RISD data warehouse: De-
velopment/Test and Production (PROD). Each environment will have its own directories, profiles and
database instances. DEV/TEST will reside on a different box than production while PROD resides on
its own machine. There will also be a common place for storing tools such as OWB and Oracle Enter-
prise Manager (OEM). The tools will be installed in an area where DEV/TEST and PROD can share a
single set of tool repositories. However, Development/Test, and Production will all have their own OWB
repositories (one development/test and one run time repository in each environment). An option is to
create separate projects within the same OWB repository.
During the life cycle of the RISD warehouse, these two independent environments can be tightly cou-
pled by sharing the OWB repository. All new developments and changes to the data warehouse will be
made in the DEV/test project and tested on the DEV/test environment first.
The key to maintaining the multiple environments is to propagate the changes in one environment to
another environment. As an example, when the DEV/test project is changed in OWB, the updated
parts in the DEV/test project. Then the DEV/TEST project will capture the changes and apply them to
the Prod environment using OEM/CM (Warehouse Upgrade).
All testing, such as any functional tests, stress tests, and user acceptance tests will be done in the
DEV/TEST environment. When the change is accepted in dev/test, the change is propagated from
DEV/TEST to PROD.
Many versions of the OWB repository will be needed during the life cycle of RISD warehouse. Each
version will represent a static snap shot of the PROD environment OWB metadata prior to the applica-
tion of any modifications. Obviously, there must be a way to keep track of the versions and restore any
version if needed.
OWB uses its Project Archive/Restore Utility by using a file-based approach to store archival informa-
tion about the various projects defined within the ETL tool. The metadata in the OWB repository is

saved in the file system and restored from the file system when needed. Thus, the OWB repository can
be well protected by combining OWB and some file-based versioning control system such as PVCS.
5.5.1 OPERATIONS CONTROLLED THROUGH CHANGE MANAGEMENT

This section defines the scope of the change management. The main rule is:
• Any change should be controlled and approved through a well-documented change control
procedure. The project manager must approve and document any exceptions.
5.5.2 GROUPS INVOLVED
Scope Name Phone Manager

Data Warehouse Environment Pro- Norma Comer 469-593-0704

ject Manager
RIMS Student Information System Susan Abreu 469-593-0708
Programmer/Analyst
Discoverer Applications Developer Jean Liu 469-593-0707 Norma Comer
Development DBA – Logical Raj Vaiyur 469-593-0228 Norma Comer
DB design and developing all
DB objects
Production DBA – Physical Raj Vaiyur 469-593-0228 Norma Comer
DB design and developing all
DB objects. Responsible for
Moving all tested DB objects
From test to production.
ODS Extracts and OWB Raj Vaiyur 469-593-0612 Norma Comer
Portal Internet Project Manager Steve Huntress 469-593-0229 Norma Comer
Operations Support – Responsible Raj Vaiyur 469-593-0228 Norma Comer
For moving code from test to
Production.
5.5.3 DATABASE ADMINISTRATION SUPPORT

As noted, the development DBA is responsible for the logical design, which would include maintaining
the model in Designer. The production DBA would be responsible for the physical database design. If
these functions are assigned to the same person, a review process for QA must be incorporated into
the procedures. Current procedures will continue.
5.6 CHANGE MANAGEMENT

Changes to an application generally fall into three categories:
1. Fixes of problems: recognition and correction of problems.
2. Enhancements to add functionality: Implementation of new business requirements.
3. Enhancements to improve production flow: enhancements to improve operations such effi-
ciency changes.

5.6.1 OPERATIONS CONTROLLED THROUGH CHANGE MANAGEMENT
This defines the scope of the change management. The main rule is:
1. Any change should be controlled and approved through a well-documented change control
procedure, except those mentioned in this section. The project manager must approve any ex-
ceptions.
5.6.2 PROCEDURES
General Procedures
1. Creating a Request. Written confirmation of the business need. In the case of a production
problem, an email to the application support person will suffice.
2. Approving the Request Fixes to production problems only needs approval from the applica-
tion manager as the change usually needs to be done immediately. This approval can be post
implementation in the event of an emergency.
3. Analysis of the Request. The application support person or the developer must determine the

scope of the needed change and the impacted applications (for example, a new assessment
process requires changes to the ODS, DW logical and physical design changes, ETL changes,
and the development of new reports.) The assessment analyst usually creates the functional
specifications for new reports and provides input to the logical design.
4. Approval of the request. The requestor needs to sign off and approve the functional specifi-
cation.
5. Schedule the implementation. Production fixes are immediate.
6. Create the physical design specifications based on the functional specifications. Update
appropriate data models.
7. Obtain affected software from the production library. For the most part changes will impact
Oracle Designer and OWB.
8. Implement the Change – Create updated code and reports. Unit test the change on the de-
velopment/test database from a user directory.
9. Test the change – After the software changes have been tested from the user directory, move
the software to the appropriate directory on the test machine. System test the change against
the test database environment obtaining inputs from the ODS test machine.
10. Approve the change – The requestor needs to sign off on the test results.
Move the change from the test libraries to the Production libraries – migrate the changes
from test to production
The last step is to update all system documentation, including this application Operations guide (most
changes will be documented in the design tools but new documents may be required.)

5.7 BACKUP AND RECOVERY
“Hot” (or cold) backups are performed nightly and full “cold backups” are sent off site periodically. This document
describes the strategy for backing up this data and recovering it in the event any data is destroyed or corrupted.
Data Base Backup Strategy
The following fully automated database backup processing is performed for the production database:
A full Oracle hot (online) or cold (offline) database backup is performed nightly. This backup is per-
formed under the control of the Oracle Recovery Manager (RMAN) and scheduled via the standard
UNIX scheduler (cron). As data is copied from the database, it is passed to a Legato backup server
running Legato backup software where it is written to tape. Backup tapes are retained for at least 60
days.
Archive logs will not be used.

Media Failure Recovery
If data is physically destroyed (via disk media failure), RMAN is invoked to recover it. First, the dam-
aged database files are restored from the most recent full online database backup. The data is then
recovered to the state it was in the last backup.
Data Corruption Recovery
The primary options for recovering corrupted input data are:

1. Execute programs or processes to recreate data and reload into the DW
2. Repair data with SQL
3. Recover corrupted tables to a point in time before the corruption occurred.
4. Recover the database to a point in time before the corruption occurred.
The options in the above list are not necessarily listed in order of most desirable to least desirable.
Note that none of these options guarantee full database recovery in all cases but because of the low
volumes, using option 4 and recovering to point in time and rerunning update processes has the lowest
risk.
Executing an application program or process (option 1) is usually the preferred method for recovering
corrupted data because it reduces risk by executing an established procedure for changing records in
database tables. For example, executing a portion of the ODS extract, transform, and load (ETL) proc-
ess may be the best way to recover corrupted data. In particular, data warehouse processes that per-
form full table refreshes of ODS data should normally be used to recover corrupted data. However, for
data corruption problems when the ETL processes uses an incremental change strategy requires a
special run of the DW update process to ensure all corrupt entries are deleted and replaced during a
rerun for the period in question.
Option 2, SQL insert, update, and delete statements may be used to repair data. Query flashback may
be helpful since it can select table data as it existed at a previous point in time. This method requires a
complete understanding of rows affected, correct column values, and inter table relationships.
Recovery of individual corrupted tables (option 3) can be accomplished via individual table point-in-
time recovery. This method requires:
• Identifying when the data was corrupted
• Recovering the production database on the test data warehouse server to a specified point in
time before the corruption occurred
• Exporting all the rows in the recovered corrupted tables and potentially all related tables on the
test server

•Truncating the corrupted production tables and importing data from the files created during the
above export into these tables.
• Recreating data that was added to the corrupted tables after the “recover to” time (where pos-
sible).
This method is time consuming and impacts the availability of the test environment.
Recovery of the entire database to a point in time (option 4) is also possible. This method does not re-
quire use of the test database server as in option 3, and the point-in-time recovery step can be accom-
plished with only a few simple RMAN commands. However, it resets all of the tables managed by to
the same point in time and all process run in the interim would have to be reset and rerun. However,
since the RISD database is relatively small and the data needed to catch up several weeks or even
months is available in the ODS, this might be the best alternative in many cases.
See the backup and recovery documentation maintained by the Infrastructure group.
Disaster Recovery

In case of disaster, the data warehouse would not have priority over operational systems. The data
warehouse is a reporting and analytical system and does not process transactions critical to RISD’s
short-term survival. Nevertheless, in the event of a power failure, hardware failure, fire, flood, or any
other system-interrupting disaster, the data warehouse will need to be recovered at some point. The
only way to ensure a relatively rapid recovery from a system failure or other disaster is to plan carefully.
Normal recovery time should be less than 24 hours while a true disaster like a destroyed data center
could be in the 7 to 14 day range (or longer). There must be a detailed plan with clearly defined proce-
dures to deal with the event of a catastrophic failure.
Every enterprise should have a disaster recovery plan to protect its core business in case of a catas-
trophe. The disaster recovery plan for the RISD data warehouse must be considered as a component
of the district’s disaster recovery plan.

6. ETL SCRIPTS
The Extract, Transform, and Load (ETL) process is the primary interface between the ODS and the
Data Warehouse. Daily and On Request updates are monitored and controlled by the DW audit proc-
ess. The following matrices provide more detail about the ETL process.
Item Functional Area Script Name Notes
0 One time Initialization Multiple scripts for the

Script was created to initialize all DW
one time process tables.
1 Daily Updates OWB Process to update student and em-
ployee information
2 Pre Load Assessment PKS_PRELOADS_MAIN Set DW_ASSMT_BATCH status con-
ditions
3 Pre Load Referential integrity PKG_RISD_COMMON Calls FNC_CHECK_STUDENT as

part of PKG_RISD_COMMON to en-
sure all RISD Ids on the assessment
are in the DW student dimension ta-
bles
4 TAKS Process OWB control calls
PKG_TAKS_LOAD
5 SDAA II Process OWB control calls
PKG_SDAA_LOAD
6 TEKS Process OWB control calls
PKG_TEKS_LOAD
7 SAT OWB
8 ACT OWB
9 PSAT OWB
10 PEIMS OWB
11 LDAA OWB
12 TELPAS OWB
13 AP OWB
14 ERWA OWB Only used for one time conversion
15 Tejas Lee OWB Only used for one time conversion
Note: Please review OWB documentation for details as many OWB processes contain pre and post
ETL update processing.

7. PRODUCTION READINESS CHECKLIST
Item Condition Expected Results

1 Add new role for existing employee to Role is added for employee. (This is part of the
employee security table ODS update and will be reflected after the daily
run in the DW)
2 Delete role for existing employee Role is deleted. (This is part of the ODS update)
3 Try to add a role for an employee that Adds new “employee” as a dummy and sets role.
does not exist.
4 Try to add a role for an employee al- Process rejects record. (This
ready having the role. is part of the ODS update)

5 Set several assessment files in the The data warehouse only loads the files marked
ODS log file as ready to run. for update
6 Back out a run for a test administration All records for the selected
batch id are deleted
7 Log in as a Teacher and run student Teacher can only view their current students for
report the criteria selected.
8 Log in as Campus Admin (includes as- Campus Admin can only view current students in
sistant principal, advisors, and so on) the school and students in the incoming class.
Use same defaults as above
9 Log in as Principal Principal can only view current students in the
school and students in the incoming class.
10 Log in as Area (Cluster) Admin Area Admin can only view current students and
teachers in the area (cluster).
11 Log in as Area Superintendent Area superintendent can only view current stu-
dents and teachers in the area.
12 Log in as Central Admin No restrictions
13 Log in as Central Superintendent No restrictions
14 Log in as District Assessment Team No restrictions.
15 Validate all new or changed summary Summaries are added for se-
tables and materialized view match the curity and or improve re-
base details sponse time
16 The ETL process is set up to run nightly
but can be started manually. A process
is needed to run the process in real
time.

As of 7/15/05 TAKS Disco Spec Version 4.0 TAKS_Disco_1_2_3_spec_V4.doc
Info Set Title: Texas Assessments of Knowledge and Skills (TAKS) for State Accountability
Info Set Description:

The goal of the Texas student assessment program is to measure and support student progress toward achieving
academic success. The program provides an accurate measure of student achievement in reading, writing, mathematics,
social studies, and science with Test performance results being a gauge for institutional accountability. TAKS is the
primary state-mandated assessment, first administered in spring 2003. TAKS is given to students in mathematics at
Grades 3–10 and at the exit level; in reading at Grades 3–9; in writing at Grades 4 and 7; in English language arts
(ELA) at Grade 10 and at the exit level; in science at Grades 5 and 10 and at the exit level; and in social studies at
Grades 8 and 10 and at the exit level. Spanish versions of TAKS are available at Grades 3–6. The TAKS assessment
information is used for both State Assessment reports and for Local reports. The State Assessment reports must match
state reports published by Texas Education Agency (TEA). The Local reports integrate the TAKS assessment
information with the RISD Student Information System (SIS) information to provide more accurate student
demographic information. TAKS is designed to be more comprehensive than its predecessors and encompass more of
the state managed curriculum that is tested via the Texas Essential Knowledge and Skills (TEKS). TEKS reporting
requirements are similar to TAKS reporting but TEKS reports monitor subsets of the TAKS testing objectives that are
given in approximate 6-week intervals to test the curriculum tested during that period. That is TEKS, is an early
warning barometer of TAKS performance. The Student Success Initiative (SSI) mandates that satisfactory
performance on the Grade 3 reading assessment, the Grade 5 reading and mathematics assessments, and (beginning in
2008) the Grade 8 reading and mathematics assessments are a promotion requirement for Texas students.
On each TAKS test, the critical knowledge and skills are measured by a series of test objectives. These objectives are
not found verbatim in the TEKS curriculum but the objectives are umbrella statements that serve as headings under
which student expectations from the TEKS can be meaningfully grouped. Objectives are broad statements that break up
knowledge and skills to be tested into meaningful subsets around which a test can be organized into reporting units.
These reporting units help RISD employees, parents, and the general public better understand the performance of
students, teachers, and schools as the school year progresses. Test objectives are not intended to be rewordings of the
TEKS but the objectives are designed to be identical across grade levels rather than grade specific. Generally, the test
objectives are the same for third grade through eighth grade (an elementary/middle school system) and for ninth grade
through eleventh grade (a high school system).
Page 1
Table of Contents
Info Set Title: Texas Assessments of Knowledge and Skills (TAKS) for State Accountability............................ 1
Info Set Description: ..............................................................................................................................................................1
Table of Contents ...................................................................................................................................................................2
1.0 Aggregate Report Name: TAKS Objectives Summary Report – Report 1A.............................................................4
Report Mockup / Layout: TAKS District Objectives Summary by Student Groups Report - Elementary Example .................... 4
Report Measures & Dimensions: TAKS District Objectives Summary Report – Elementary Example........................................ 5
Dimension Hierarchies for: Report Name: TAKS District Objectives Summary Report – Elementary Example........................ 8
2.0 TAKS Passed, MAO and Commended Detail Report – Report 1B............................................................................9
Report Mockup / Layout: TAKS Passed, MAO and Commended by Detailed Dimensions Report - Elementary Example......... 9
Report Measures & Dimensions: TAKS Passed, MAO and Commended Detail Report - Elementary Example........................ 10
Dimension Hierarchies for: TAKS Passed, MAO and Commended Detail Report - Elementary Example................................. 12
3.0 Aggregate Report Name: TAKS Aggregate Item Analysis Report (Report 2) – Elementary Example ..............13
Report Mockup / Layout: TAKS Item Analysis Report – Report 2 .................................................................................................. 13
Report Measures & Dimensions: TAKS Aggregate Item Analysis Report – Elementary Example.............................................. 14
Dimension Hierarchies for: Report Name: TAKS Item Analysis Report – Elementary Example ................................................ 16
Page 2
4.0 Detail Report Name: TAKS Objective Summary by Student – Report 3...............................................................17
Report Mockup / Layout: TAKS Performance Level by Student (State Accountability) – Elementary Example ....................... 17
Dimension Hierarchies for: Report Name: TAKS Objective Summary by Student (State Accountability.................................. 19
Base Level Fact Name: F_TAKS_ASSESSMENT .............................................................................................................20
Business Rules: .....................................................................................................................................................................20
Open Issues ...........................................................................................................................................................................28
Page 3
1.0 Aggregate Report Name: TAKS Objectives Summary Report – Report 1A
Report Mockup / Layout: TAKS District Objectives Summary by Student Groups Report - Elementary Example
Page Dimensions
School Year and Administration Test Area Location
Test Version Grade LEP
Ethnicity Economic Disadvantage Special Ed
180
# % # Not % Not
Total Mastered Mastered Mastered Mastered 160
140
99 71% 116
Obj 1 215 29%
120
98 68% 117 100
Obj 2 215 32%
80
Obj 3 215 97 71% 118 29% 60
Number of Students
40
Obj 4 215 97 72% 118 28%
20
Obj 5 215 154 73% 72 27% 0
Obj 1 Obj 2 Obj 3 Obj 4 Obj 5 Obj 6 Obj 8
Obj 6 215 101 67% 114 33%
Mastered Not Mastered
Obj 8 215 140 78% 75 22%
Note: Clicking on highlighted areas, Total, # Mastered, or Number not Master will link to the detail objectives report by student (4.0)
Page 4
Report Measures & Dimensions: TAKS District Objectives Summary Report – Elementary Example
Report Measures Dimensions Time Notes/Issues

Aggregate 1. # Mastered Objective 1 1. D_SCHOOL_YEAR
2. % Mastered Objective 1 D_ADMIN_PERIOD There are multiple Measures:
3. # Mastered Objective 2 2. D_TEST_AREA reporting administrations All Measures can aggregate except for
4. % Mastered Objective 2 for each year. In some percentages that must be recalculated based on
4. D_TEST_VERSION (TAKS Version)
5. # Mastered Objective 3 grades there is only a single summaries.
5. D_EDUCATION_GRADE
6. % Mastered Objective 3 6. (Tested Grade Group)
administration but in other Note: All standard measures will be stored in a
7. # Mastered Objective 4 7. D_LEP grades and test areas, benchmark table. Standards provided by the
8. % Mastered Objective 4 8. D_ETHICITY retests are permitted when state will be obtained from the assessment input
9. # Mastered Objective 5 9. D_ECONOMIC_DISADVANTAGE the test is used for file while standards set by RISD, not TEA must
10. % Mastered Objective 5 10. D_SPECIAL_ED
graduation or promotion. be manually entered into the benchmark table.
11. # Mastered Objective 6 11. D_GENDER Cumulative will be the
12. % Mastered Objective 6 default. When creating a # Tested (Not shown but used for calculations) -
… cumulative report for a The number of students with valid test. The
Up to the number of objectives for the given year, if a student has number tested is defined at the Test Area
test multiple records across (Subject) and Tested Level (Grade). The same
13. # Not Mastered Objective 1 administrations, the most numbers of students are tested on every
14. % Not Mastered Objective 1 recent record will be used objective.
15. # Not Mastered Objective 2 regardless of score.
16. % Not Mastered Objective 2 # Mastered Objective 1= the number of students
17. # Not Mastered Objective 3 that mastered objective 1. Mastered is reported
18. % Not Mastered Objective 3 by the Test Area (Subject) and Tested Level
19. # Not Mastered Objective 4 (Grade). The standard for mastering an
20. % Not Mastered Objective 4 objective on TAKS is ~ 70% of the items correct
21. # Not Mastered Objective 5 within an objective. This standard has been set
22. % Not Mastered Objective 5 by RISD, not TEA. Note that all benchmarks
23. # Not Mastered Objective 6 and standards will be available in the benchmark
24. % Not Mastered Objective 6 table.
% Mastered Objective 1= the percentage of

students that mastered objective 1. % Mastered
Objective 1 is calculated as follows: #
Mastered Objective 1 / # Tested
# Mastered Objective 2= the number of students

that mastered objective 2. Mastered is reported
Page 5

by the Test Area (Subject) and Tested Level
(Grade). The standard for mastering an
objective on TAKS is ~ 70% of the items correct
within an objective. This standard has been set
by RISD, not TEA.

# Mastered Objective 10= the number of

students that mastered objective 10. Mastered is
reported by the Test Area (Subject) and Tested
Level (Grade). The standard for mastering an
objective on TAKS is ~ 70% of the items correct
within an objective. This standard has been set
by RISD, not TEA.

# Not Mastered Objective 1 = the number of

students that did not master objective 1.
% Not Mastered Objective 1 = the percentage of

students that did not master objective 1. %
Mastered Objective 1 is calculated as follows:
# Not Mastered Objective 1 / # Tested

% Not Mastered Objective 2 = the percentage of

students that did not master objective 2. %
Page 6

% Not Mastered Objective 10 = the percentage

of students that did not master objective 10. %
Note: Test Areas Tested Grade combinations

have up to 10 Objectives. Not all Test Areas
Tested Grade combinations have 10 Objectives.
The Objective will be Null if the Test Areas
Tested Grade combination doesn’t include the
Objective.
Linkages (s):
You may link to report 4.0 by clicking on Total,
# mastered, and # Not Mastered.
Page 7
Dimension Hierarchies for: Report Name: TAKS District Objectives Summary Report – Elementary Example
Dimensions Hierarchies shown in the dimension Specific Values, Special Sort Order *,
Notes, Etc.
D_SCHOOL_YEAR and Administration <School Year> Note – Cumulative reports are possible for areas that allow
D_ADMIN_PERIOD (Time) retests although most grade test areas only have one
administration
D_TEST_AREA All (default) – MUST SELECT TEST AREA – Test Areas vary by Administration and include:
ALL MEANS all Reports Reading
ELA/Reading
Mathematics
Writing
Science
Social Studies
D_CAMPUS (Location) All (includes RISD and non RISD campuses)
District (includes unknown RISD campuses)
Area
Campus
D_TEST_VERSION (TAKS Version) Spanish or English
D_EDUCATION_GRADE All Grades limited to 3-6 for Elementary Schools
(Tested Grade Group) Campus Type 3-11 for all (for example, Elementary, Jr. & Senior High)
Grade
D_LEP All
Y/N
D_ETHICITY All
Native American
Asian
African American
Hispanic
White
Other
D_ECONOMIC_DISADVANTAGE All
Y/N
D_SPECIAL_ED All
In Special Ed / Not in Special Ed
D_GENDER All
Male/Female
Page 8
2.0 TAKS Passed, MAO and Commended Detail Report – Report 1B
Report Mockup / Layout: TAKS Passed, MAO and Commended by Detailed Dimensions Report - Elementary Example
Page Dimensions
School Year Administration Location
# # % # Not % Not
Total Meeting Meeting Meeting Meeting #
Standard Standard Standard Standard # MAO % MAO CMND % CMND
ELA 120 99 92% 99 99 116 93% 99 92%
Writing 122 20 98% 99 99 23 99% 20 98%
Math 123 30 71% 99 99 33 75% 30 71%
Science 125 30 71% 99 99 33 75% 30 71%
Note: Test there are 4 test areas at each level. Elementary – Reading, Math, Writing, and Science. JH – Reading, Math, Writing, and Social Studies.
HS – ELA, Math, Science, and Social Studies.
Page 9
Report Measures & Dimensions: TAKS Passed, MAO and Commended Detail Report - Elementary Example

Aggregate 1. # Passed 1. D_SCHOOL_YEAR
2. % Passed 2. D_ADMIN_PERIOD There are multiple Measures:
3. # MAO 3. D_CAMPUS (Location) reporting administrations All Measures can aggregate except percentages.
4. % MAO 4. D_TEST_VERSION (TAKS for each year. In some
5. # Commended Version) grades there is only a single # Tested (Not shown but used for calculations) -
6. % Commended 5. D_EDUCATION_GRADE (Tested administration but in other The number of students with valid test. The
Grade Group) grades and test areas, number tested is defined at the Test Area
6. D_LEP retests are permitted when (Subject) and Tested Level (Grade). The same
7. D_ETHICITY the test is used for numbers of students are tested on every
8. D_ECONOMIC_DISADVANTAGE graduation or promotion. objective. This is a count of all ‘S’ (Scored)
9. D_SPECIAL_ED In some cases make up code evaluation records
10. D_GENDER tests are permitted but do
not have to be # Passed = The number of Students Passing. #
differentiated with records Passed is defined at the Test Area level not the
in the same year and Objective Level. A student passing is based on
administration the total number correct at the test area level as
determined by the state.
% Passed = The percentage of Passing. %

Passing is defined at the Test Area level not the
Objective Level. % Passing is calculated as
follows: # Passing / # Tested
# MAO- the number of students who mastered

all objectives. # MAO is defined at the Test
Area level not the Objective level. Each
objective has a minimum score. The student is
counted if they meet or exceed the count for
mastery in each objective area
% MAO- the percentage (%) of students who

mastered all objectives. % MAO is defined at
the Test Area level not the Objective level %
Page 10

MAO is calculated as follows: # of Students
mastering all objectives / # Tested
# Commended = The number of Students with

Commended level of performance. #
Commended is defined at the Test Area level not
the Objective Level. Commended are a number
of correct answers provided by RISD that that is
higher than the passing number to show above
average scores.
% Commended = The percentage of students

with Commended level of performance. %
Commended is defined at the Test Area level not
the Objective Level. % Commended is
calculated as follows: # Commended / # Tested
Note: Test Areas Tested Grade combinations

have up to 10 Objectives. Not all Test Areas
Tested Grade combinations have 10 Objectives
(up to 15 will be allowed for future growth).
The Objective will be Null if the Test Areas
Tested Grade combination doesn’t include the
Objective. Null values should not be printed.
Notes:
Met standards plus not met standards counts
add up to the total students taking the test.
Page 11
Dimension Hierarchies for: TAKS Passed, MAO and Commended Detail Report - Elementary Example
Dimensions Hierarchies shown in the dimension Specific Values,

Special Sort Order *,
Notes, Etc.
administration
D_TEST_AREA All (default) Test Areas vary by Administration and include:
Reading
ELA/Reading
Mathematics
Writing
Science
Social Studies
Area
Campus
Grade
D_LEP All
Y/N
D_ETHICITY All
Native American
Asian
African American
Hispanic
White
Other
Y/N
D_SPECIAL_ED All
D_GENDER All
Male/Female
Page 12
3.0 Aggregate Report Name: TAKS Aggregate Item Analysis Report (Report 2) – Elementary Example
Report Mockup / Layout: TAKS Item Analysis Report – Report 2
Page Dimensions
Objective Item TEKS Key % A/F % B/G % C/H % D/J % E/K

1 Item02 5.9B F 73.7% 5.3% 10.5% 10.5% 0.0%
Item04 5.10F F 60.5% 15.8% 10.5% 13.2% 0.0%
Item06 5.10F G 7.9% 76.3% 10.5% 5.3% 0.0%
Item14 5.10G G 13.2% 65.8% 2.6% 18.4% 0.0%
Item15 5.10F C 2.6% 7.9% 76.3% 13.2% 0.0%
Item23 5.10G D 7.9% 7.9% 5.3% 78.9% 0.0%
Item27 5.10F D 7.9% 2.6% 18.4% 71.1% 0.0%
Item31 5.10F B 5.3% 71.1% 7.9% 15.8% 0.0%
Item33 5.10F C 13.2% 13.2% 60.5% 13.2% 0.0%
Item34 5.9B F 71.1% 10.5% 7.9% 10.5% 0.0%
Item35 5.10G C 5.3% 26.3% 63.2% 5.3% 0.0%
Item36 5.9B F 71.1% 10.5% 10.5% 7.9% 0.0%
Item39 5.10F D 7.9% 18.4% 10.5% 63.2% 0.0%
2 Item08 5.12H F 63.2% 7.9% 10.5% 18.4% 0.0%
Item09 5.12H C 7.9% 10.5% 78.9% 2.6% 0.0%
Item11 5.12H B 2.6% 84.2% 2.6% 10.5% 0.0%
Item21 5.12H D 2.6% 10.5% 13.2% 73.7% 0.0%
Item22 5.12I F 68.4% 13.2% 10.5% 7.9% 0.0%
Item26 5.12I G 5.3% 60.5% 10.5% 23.7% 0.0%
Item29 5.12I B 10.5% 73.7% 10.5% 5.3% 0.0%
Item32 5.12H H 5.3% 5.3% 86.8% 2.6% 0.0%
3 Item01 5.12C C 10.5% 5.3% 78.9% 5.3% 0.0%
Item10 5.12A G 0.0% 89.5% 2.6% 7.9% 0.0%
Item13 5.10E B 10.5% 73.7% 13.2% 2.6% 0.0%
Item17 5.10L D 2.6% 10.5% 18.4% 68.4% 0.0%
Item20 5.10I F 68.4% 13.2% 13.2% 5.3% 0.0%
Item30 5.10E F 71.1% 5.3% 7.9% 15.8% 0.0%
Item41 5.10L B 10.5% 84.2% 0.0% 5.3% 0.0%
Item42 5.10E G 10.5% 81.6% 2.6% 5.3% 0.0%
4 Item03 5.10H B 7.9% 76.3% 5.3% 10.5% 0.0%
Item05 5.10H B 7.9% 71.1% 15.8% 5.3% 0.0%
Item07 5.10H C 10.5% 7.9% 71.1% 10.5% 0.0%
Item12 5.11C J 2.6% 5.3% 7.9% 84.2% 0.0%
Item16 5.11C G 10.5% 76.3% 7.9% 5.3% 0.0%
Item18 5.10H F 63.2% 10.5% 13.2% 13.2% 0.0%
Item19 5.11D A 63.2% 10.5% 10.5% 15.8% 0.0%
Item24 5.10H G 13.2% 52.6% 21.1% 13.2% 0.0%
Item25 5.10H C 15.8% 7.9% 60.5% 15.8% 0.0%
Item28 5.11C J 10.5% 7.9% 7.9% 73.7% 0.0%
Item37 5.10H D 7.9% 13.2% 7.9% 71.1% 0.0%
Item38 5.10H G 13.2% 65.8% 7.9% 13.2% 0.0%
Item40 5.11C J 13.2% 5.3% 7.9% 73.7% 0.0%
Page 13
Report Measures & Dimensions: TAKS Aggregate Item Analysis Report – Elementary Example

Aggregate 1. Objective 1. D_SCHOOL_YEAR
2. TEKS 2. D_ADMIN_PERIOD Measures:
3. Key 3. D_TEST_AREA
4. % Students with Answer A/F # Tested – The number of students tested.
5. % Students with Answer B/G
6. D_EDUCATION_GRADE (Tested
6. % Students with Answer C/H Grade Group)
TEKS – The TEKS content item tested.
7. % Students with Answer D/J 7. D_LEP
8. % Students with Answer E/K 8. D_ETHICITY KEY - The correct answer for the item.
9. D_ECONOMIC_DISADVANTAGE
The correct answer should be shown 10. D_SPECIAL_ED
% Students with Answer A/F – The percentage of
with yellow highlighting ( – Not sure if 11. D_GENDER students tested selecting A or F. % Students with
this can be automated). Answer A/F is calculated as follows: # Students
with Answer A/F / # Tested
Sorted by Objectives and then Item #
% Students with Answer B/G – The percentage of
students tested selecting B or G. % Students with
Answer A/F is calculated as follows: # Students
with Answer B/G / # Tested
% Students with Answer C/H – The percentage of

students tested selecting C or H. % Students with
Answer C/H is calculated as follows: # Students
with Answer C/H / # Tested
% Students with Answer D/J – The percentage of

students tested selecting D or J. % Students with
Answer D/J is calculated as follows: # Students
with Answer D/J / # Tested
% Students with Answer E/K – The percentage of

students tested selecting E or K. % Students with
Answer E/K is calculated as follows: # Students
with Answer E/K / # Tested
Page 14
Linkages (s):
Specify the linkages between this report and
others.
Notes:
All Measures other than Objective and TEKS can
aggregate
Correct answer is the same at all levels but it

varies by administration
Page 15
Dimension Hierarchies for: Report Name: TAKS Item Analysis Report – Elementary Example
Notes, Etc.
administration
Reading
ELA/Reading
Mathematics
Writing
Science
Social Studies
Area
Campus
D_TEST_VERSION (TAKS Version) Spanish or English or All
Grade
D_LEP All
Y/N
D_ETHICITY All
Native American
Asian
African American
Hispanic
White
Other
Y/N
D_SPECIAL_ED All
D_GENDER All
Male/Female
Page 16
4.0 Detail Report Name: TAKS Objective Summary by Student – Report 3
Report Mockup / Layout: TAKS Performance Level by Student (State Accountability) – Elementary Example
Page Dimensions
Teacher Course - enhancement Period - enhancement
Parameters are set from Linked Report. Can set a % correct range to filter the students and call this report directly from portal if desired.
Report Measures & Dimensions: TAKS Objective Summary by Student (State Accountability) – Elementary Example
Order
Campus Test Raw Score Score Score Score Score %
Code Level StudID Student Name Score Obj. 1 Obj. 2 Obj. 3 Obj. 4 Obj. 5 Correct
1 BSE 3 ID 10001 Student 1 36 15 7 6 8 15 100.0%
2 NPR 3 ID 10002 Student 2 36 15 7 6 8 15 100.0%
3 STR 3 ID 10003 Student 3 36 15 7 6 8 15 100.0%
4 BSE 3 ID 10004 Student 4 29 12 7 6 4 12 80.6%
5 NPR 3 ID 10005 Student 5 31 15 6 6 4 15 86.1%
6 STR 3 ID 10006 Student 6 24 10 4 3 7 10 66.7%
7 BSE 3 ID 10007 Student 7 29 11 7 5 6 11 80.6%
8 NPR 3 ID 10008 Student 8 26 11 5 4 6 11 72.2%
9 STR 3 ID 10009 Student 9 25 12 4 4 5 12 69.4%
10 BSE 3 ID 10010 Student 10 21 10 2 5 4 10 58.3%
11 NPR 3 ID 10011 Student 11 22 8 5 3 6 8 61.1%
12 STR 3 ID 10012 Student 12 21 7 4 5 5 7 58.3%
13 STR 3 ID 10013 Student 13 24 10 5 3 6 10 66.7%
Page 17
Measures / Attributes (Content) Dimensions & Parameters Time Notes/Issues

Column Headings: in display order Dimensions set from the drill There are 4 test- Raw Score –
1. Location 1. D_SCHOOL_YEAR reporting
2. Test Level- (Grade) 2. D_ADMIN_PERIOD administrations for Objective 1-
3. Student ID 3. D_TEST_AREA each year.
4. Student Name Objective 2 –
5. Raw Score March <School Year>
6. D_EDUCATION_GRADE (Tested
6. # Correct Objective 1 Grade Group)
April <School Year> Objective 3 –
7. # Correct Objective 2 7. D_LEP May <School Year> …
8. # Correct Objective 3 8. D_ETHICITY June <School Year> Objective 10 –
9. … 9. D_ECONOMIC_DISADVANTAGE
10. # Correct Objective 10 10. D_SPECIAL_ED % Correct – % of total items answered correctly. %
11. % Correct 11. D_GENDER Correct is calculated as follows: Score / # Items
12. Did not pass – Shown via formatting the Total Possible points.
text
13. Did not achieve mastery – Shown via Linkages (s):
highlighting the text
This report can be linked from report 4.0 or called
Sort by location, Test Level and Student directly from portal.
Name.
Notes:
Note: Test Areas Tested Grade combinations have
up to 10 Objectives. Not all Test Areas Tested
Grade combinations have 10 Objectives. The
Objective will be Null if the Test Areas Tested
Grade combination doesn’t include the Objective.
Page 18
Dimension Hierarchies for: Report Name: TAKS Objective Summary by Student (State Accountability
Notes, Etc.
administration
Reading
ELA/Reading
Mathematics
Writing
Science
Social Studies
Area
Campus
Grade
D_LEP All
Y/N
D_ETHICITY All
Native American
Asian
African American
Hispanic
White
Other
Y/N
D_SPECIAL_ED All
D_GENDER All
Male/Female
Page 19
Base Level Fact Name: F_TAKS_ASSESSMENT
See Database data dictionary for final formats.

Business Rules:
# Business Rule – Informational only (business rules handled in ETL process)

ETL AGGR DETAIL
01 x x x The TAKS assessment information may be used for both State Assessment reports and for Local reports. The
State Assessment reports must match state reports published by Texas Education Agency (TEA). The Local
reports integrate the TAKS assessment information with the RISD SIS information to provide more
accurate/current information. The data warehouse will need to capture the student demographics at assessment
time from both the data file returned by the State and the RISD SIS. All SIS data changes (except corrections)
will be captured to enable point in time local reporting.
02 x x x State Accountability – Location & District
Note the accountability indicator will be at the student level. Each student will have district accountability and
a campus accountability indicator.
Business rule logic

Start with Students TAKS record if the student doesn’t have a record in PEIMS – Don’t include the record flag
as an error.
If (TAKS Location = PEIMS Location) All nine CDS columns match (district_campus_no in ODS) - District
and campus accountable)
If (TAKS District = PEIMS District) First 6 CDS columns match – Set location = Unknown (No campus is
accountable for the student but the District is)
If the Test Area has multiple administrations (Reading Grade 3 & 5, Math Grade 5) the student records in
multiple administrations must match values for all administrations match (use rules above).
03 x x x Local Reporting - Location & District
Report a student at the location where the student was enrolled when the TAKS test was administered - Tested
Location. Recaptured students, will be reported from “Other District Location”.
04 x x x State Accountability / Local Reporting
Page 20

ETL AGGR DETAIL
All State Accountability Reports must match exactly what is done by the TEA. This means all student
demographics are, as returned by the State and that all calculations and data must come from a specific set of
State files (records or documents not including exit retests past June).
Local Reporting may use, students excluded from State Accountability reports because they transferred into or
out of the District, local (SIS) demographics, local data (SIS Enrollments) and exit retests past June.
For SLC the objectives are to provide RISD leadership with a "preview" of what the State Federal (NCLB)
Accountability reports will be and to provide more detailed diagnostic information for proactive management.
How this is implemented, is to use the State Accountability sources, demographics and calculations with one
primary addition "# Eligible for TAKS" that comes from SIS enrollment counts on the day of testing. The "#
Eligible for TAKS" is used as the denominator in many of the percentages; % absent, % LEP Exempt, etc. For
State Accountability they use for "# Eligible for the number of unique state test documents submitted. Use the
demographics reported on the specific Test Area record provided by the state to ensure the results match the
State reports. Note: A student could have different demographics on different Test Areas, for example, Male on
ELA female on Math. If the Test Area has multiple administrations (Reading Grade 3 & 5, Math Grade 5) use
the values for last administration since that will be the one the student passes or it will be the last one counted
towards the report if they fail. Only failing students have multiple records.
05 x x x State Accountability - Multiple Scan Sheets – for example, Duplicates
Basic Rule for Writing, Science and Math and Reading with only a single administration. If the student has
more than one record for the Test Area, Tested Grade and year add a sequence number to make it unique and
load. Must include all records. When loading records, create an exception report showing duplicates.
For Test Areas and Tested Grades which have multiple administrations (Reading Grade 3 & 5, Math Grade 5)
Load all records with Score Code = S
For the first administration report only Score Code = S records from that administration
For the second administration report Score Code = S records from the second administration and Score Code =
S records from the first administration if there isn’t a Score Code = S record in the second administration for the
Page 21

ETL AGGR DETAIL
student, Test Area, Tested Grade.
06 x Mastering Objectives – The minimum or standard for mastering an objective on TAKS is 70% of the items
correct within an objective. This standard has been set by RISD, not TEA. The 2004 TAKS Mastery levels
are defined below - Source SLC data dictionary. The Minimum for Mastery & Total Possible Points vary by,
Test Area, Tested Grade and Year. Note – This information must be entered into the Assessment benchmark
table. The information below is examples.
Minimum for Mastery / Total Possible Points

Grade Obj. 1 Obj. 2 Obj. 3 Obj. 4 Obj. 5 Obj. 6 Obj. 7 Obj. 8 Obj. 9 Obj. 10
3rd 11/15 5/7 4/6 6/8 - - - - - -
Spring
4th 11/15 6/8 5/7 7/10 - - - - - -
2004:
Reading 5th 9/13 6/8 6/8 9/13 - - - - - -
(Eng. & 6th 9/13 6/8 6/8 9/13 - - - - - -
Span.) 7th 8/12 7/10 7/10 11/16 - - - - - -
8th 8/12 7/10 7/10 11/16 - - - - - -
9th 6/9 11/15 13/18 - - - - - - -
07 x It was noted that raw score = the number of items correct except for writing where some responses are weighed.
08 x There is a Locally Developed Alternative Assessment (LDAA) section on a TAKS record. Students with
LDAA values indicate the students are being given a LDAA assessment and will not have TAKS information
for that subject area.
09 There is an English and Spanish version of TAKS reports. Students may take the English version in one test
area and the Spanish version in another test area.
10 It was noted that for tested grades 3, 5, and in the future 8, students may take a test area more than once since it
is a criteria for passing but other testing grades only take the test annually.
11 x Test Areas Tested Grade combinations have up to 10 Objectives but we will allow up to 15. Not all Test Areas
Tested Grade combinations have 10 Objectives. The Objective will be set to Null if the Test Areas Tested
Grade combination doesn’t include the Objective.
12 x x The State Accountability State Test Reporting Administrations are summarized below for information purposes
Page 22

ETL AGGR DETAIL
only. The ODS production loading of data will control how data is loaded and made available to the Data
Warehouse Times are approximates.
March - TAKS Tests are administered in February and are returned in March, to allow time to retest students
for promotion to the next grade and before the final accountability results are determined. Includes
TAKS Reading – Grade 3 & 5.
April - TAKS Tests are administered in early April and are returned in late April, to allow time to retest
students for promotion to the next grade before the final accountability results are determined. Includes:
TAKS Math Grade 5.
May – This includes tests administered in several different months but all returned in early May. Includes:
TAKS Reading – Grade 3 & 5 Which is a combination of the Tests administered in Feb and the April
retests.
SDAA Reading – Grade 3 & 5 administered in April
TAKS Reading – Grade 4 & 6-8 administered in April
SDAA Reading – Grade 4 & 6-8 administered in April
TAKS Reading – Grade 9 administered in February
SDAA Reading – Grade 9 administered in February
TAKS ELA – Grade 10 & 11 administered in February
SDAA ELA – Grade 10 administered in February
TAKS Writing – Grade 4 & 7 administered in February
SDAA Writing – Grade 4 & 7 administered in February
RPTE/TELPAS – Grades 3-12 administered in March/April
TAKS Math – Grades 3, 4 & 6-11 administered in April
SDAA Math – Grades 3, 4 & 6-11 administered in April
TAKS Science – Grades 5, 10 &11 administered in April
SDAA Science – Grades 5, 10 &11 administered in April
TAKS Social Studies – Grades 8, 10 &11 administered in April
SDAA Social Studies – Grades 8, 10 &11 administered in April
Page 23

ETL AGGR DETAIL
LDAA All Test Areas - All Grades administered in February to April
June - This includes all the results that will be used by the state to determine accountability ratings. This is a
combination of the tests administered in several different months and reported in March, April, May and the
following retests:
TAKS Math Grade 5 administered in May
– grade 3,5 Final test (does not count towards accountability only promotion), Grade 5 Math
October<School Year>
Feb-March <School Year>
April <School Year>
May <School Year>
July <School Year>
13 x x The following provides additional background on the reporting administrations.
March - TAKS Tests are administered in February and are returned in March, to allow time to retest students
for promotion to the next grade and before the final accountability results are determined. Includes
TAKS Reading – Grade 3 & 5.
April - TAKS Tests are administered in early April and are returned in late April, to allow time to retest
students for promotion to the next grade before the final accountability results are determined. Includes:
TAKS Math Grade 5.
May – This includes tests administered in several different months but all returned in early May. Includes:
TAKS Reading – Grade 3 & 5 Which is a combination of the Tests administered in Feb and the April
retests.
SDAA Reading – Grade 3 & 5 administered in April
TAKS Reading – Grade 4 & 6-8 administered in April
Page 24

ETL AGGR DETAIL
SDAA Reading – Grade 4 & 6-8 administered in April

TAKS Reading – Grade 9 administered in February
SDAA Reading – Grade 9 administered in February
TAKS ELA – Grade 10 & 11 administered in February
SDAA ELA – Grade 10 administered in February
TAKS Writing – Grade 4 & 7 administered in February
SDAA Writing – Grade 4 & 7 administered in February
RPTE/TELPAS – Grades 3-12 administered in March/April
TAKS Math – Grades 3, 4 & 6-11 administered in April
SDAA Math – Grades 3, 4 & 6-11 administered in April
TAKS Science – Grades 5, 10 &11 administered in April
SDAA Science – Grades 5, 10 &11 administered in April
TAKS Social Studies – Grades 8, 10 &11 administered in April
SDAA Social Studies – Grades 8, 10 &11 administered in April
LDAA All Test Areas - All Grades administered in February to April
June - This includes all the results that will be used by the state to determine accountability ratings. This is a
combination of the tests administered in several different months and reported in March, April, May and the
following retests:
TAKS Math Grade 5 administered in May
July – TAKS Retests are administered in July and returned in August for 3 & 5 Graders as a last test after
summer school to allow the students to be promoted to the next grade level.
TAKS Reading – Grade 3 & 5
TAKS Math – Grade 5
July – TAKS Exit tests (special case of retest) are administered in August and returned in August for 11th
Graders to have a chance after summer school to pass the exit test for graduation.
TAKS ELA – Grade 11
Page 25

ETL AGGR DETAIL
TAKS Science – Grades 11

TAKS Social Studies- Grade 11
Recaptured - In ~ Sept/Oct of the next year the District gets TAKS results for new students to the District who
took TAKS in another District. Recaptured students are not included in the District’s State Accountability
results or reports. The recaptured data is used for local reporting. They are associated with the location where
the student is enrolled in the district. They are primarily used for measuring student progress over time.
Next Oct – TAKS Exit tests (special case of retest) are administered in October and returned in October for 12
Graders who have not passed, as another chance to pass the exit test for graduation after finishing High School.
Next Jan – TAKS Exit tests (special case of retest) are administered in January and returned in January for 12th
Graders who have not passed, as another chance to pass the exit test for graduation.
14 X x x It takes some time to completely resolve all data issues for each test administration. The preliminary results
need to be published to a limited subset of users until the data is finalized. Once the data is finalized, the
reports can be published for regular use.
15 x x Retests
Students must pass (Meet Standards) portions of the TAKS test for their Tested Grade to move on at various
points in the academic career. For these TAKS tests the students are allowed to retest. They are defined as
follows:
Passing Grade 3 Reading is required to promote to the fourth grade.
Page 26

ETL AGGR DETAIL
Passing Grade 5 Reading and Math is required to promote to the sixth grade.
Passing all Grade 11 Test Areas(ELA, Math, Science and Social Science) is required to Graduate High
School. The Grade 11 tests are called the Exit Level.
Exit tests begin in 11th grade, and students who fail continue to be tested through 12th grade for graduation. If
a student does not pass all Test Areas of TAKS before leaving school, he/she is considered a dropout. The
“dropout” can continue to take the TAKS test as many times as necessary until they pass. Students who have
left school (13th grade) are not longer counted in the RISD totals since they have left school.
16 X X X For each Test Area, Tested Grade and Administration the following are sample code evaluations for 2004
TAKS:
A = Absent
X = Student is ARD exempt, do not score (exit level)
L = Student is LEP exempt, do not score (Grades 3 – 10)
P = Previously Met Standard (Grades 3 and 5 and exit level retest administrations)
O = Other (for example, illness, cheating, and so on)
Y = Student did not take the English-version reading test, do not score (Grades 4 and 6 April and Grade 5 June)
Z = Student did not take the Spanish-version reading test, do not score (Grades 4 and 6 April and Grade 5 June)
Q = Student did not take the TAKS reading test, do not score (Grades 3 and 5 February and Grades 4, 6, 7, and 8 April)
S = Score
C = Student did not take the paper-version reading test and an online-version reading test for this student could not be matched to the
student’s paper-version record (Grade 8 and June exit level retest)
W = Parental Waiver: Parent or guardian requested that a student not participate in the third TAKS reading test opportunity (Grades 3
and 5 June administration)
R = ARD Committee has determined after the April test administration that TAKS reading is not appropriate for the student (Grades 3
and 5 June administration)
T = A state-approved alternate assessment was administered instead of TAKS reading (Grades 3 and 5 June administration)
D = No document processed for this subject (Grades 3, 4, 5, 7, 8, 9, 10, and exit level)
Page 27
Open Issues
This section can be used to track issues during the requirements gathering phase. Perhaps further clarification is required from a Test Area
Matter Expert (SME) and a meeting needs to be called, etc.
Expected
Number Point of Resolution Issue Description Resolution
Contact Date
1 How is Met Standard defined? Based on Objectives, Met Standards is based on a scaled
Scores or?? Does it just very by Test Area score threshold which varies by Test
(Reading/ELA/Mathematics) or does it vary by Objective Area and Year. The State
and Tested Grade As well? Just a flag on the student’s determines this and sets the Met
record by Test Area? Standards Flag for the Test Area on
the students record.
2 How is Commended Performance defined? Based on Commended Performance is based

Objectives, Scores or?? Does it just very by Test on a scaled score threshold which
(Reading/ELA/Mathematics) or does it vary by Objective varies by Test Area and Year.
and Tested Grade As well? Just a flag on the student’s
record by Test Area? The State determines this and sets
the Commended Performance Flag
for the Test Area on the students
record.
3 Need a table of historical 2002-2003, 2003-2004 and the The DW team will create a format
current year 2004-2005 Mastery levels and # of Items by for the table that can be loaded from
Test Area, Tested Grade and Objective. data input into an Excel spreadsheet
4 Need a table of historical 2002-2003, 2003-2004 and the The DW team will create a format
current year 2004-2005 correct item response by Test for the table that can be loaded from
Area, Tested Grade, Objective, and Item. data input into an Excel spreadsheet
Page 28
5 What is the authoritative source for locations? Do Schools may close and new schools
locations ever change? Add new ones, drop old ones or may open. If a school changes type
switch configuration, for example, change from a Jr. High (it can’t physically be relocated) we
to an Elementary School? will assume the old one will close
and the “new” one will have a new
name
6 How does Economic Status match up with Economically Economically Disadvantaged is one
Disadvantaged? Are they the same? Economically of the two values in the Economics
disadvantaged students qualify for free or reduced meal Status dimension.
services based upon their family's income.
7 Define the users who may view the preliminary reports. Only the Assessment team and they
have a separate security group.
8 What are the requirements to track students who have left None at this time.
the district (Grade 13) (Graduated or obtained an
certificate of completion,….)
9 Determine if we can link the Teacher dimension to Teacher can be linked to multiple
Location Dimension. The idea is that the available campuses (the lowest level in the
teachers would only show teachers at the location not all location hierarchy). Part of security
teachers in the district. model.
Page 29

D56261GC10 sg3 PDF

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

D56261GC10 sg3 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D56261GC10 sg3 PDF

Uploaded by

Copyright:

Available Formats

Oracle Internal & Oracle Academy Use Only

Oracle Database 11g:

Volume III • Student Guide

Lauran K. Serhal Disclaimer

This document contains proprietary information and is protected by copyright and

Oracle Internal & Oracle Academy Use Only

Project Management Plan

RD.049 Portal Security Requirements

Oracle Internal & Oracle Academy Use Only

MD.070 Physical Database Design

TA.010 RISD Data Warehouse Architecture

TE.100 - ETL Test Results RISD Data Warehouse

TE.100 - Report Test Results RISD Data Warehouse

MD.120 Production Readiness Application Operations Handbook

TAKS Disco Spec Version 4.0

Project Start: Mon

Oracle Internal & Oracle Academy Use Only

Define Requirements OPM[25%],Director

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Define Data Access

Oracle Internal & Oracle Academy Use Only

Signoff on Logical Data

Oracle Internal & Oracle Academy Use Only

Provide technical support

Oracle Internal & Oracle Academy Use Only

170 Support Process 6 days Tue 7/27/04 Tue 8/3/04 0%

Oracle Internal & Oracle Academy Use Only

ID Name Group Max Units Peak Units

Oracle Internal & Oracle Academy Use Only

M1_RISD_Baseline_Project_Plan_ks.htm (10 of 16)

Working Sessions with

Oracle Internal & Oracle Academy Use Only

M1_RISD_Baseline_Project_Plan_ks.htm (11 of 16)

Oracle Internal & Oracle Academy Use Only

M1_RISD_Baseline_Project_Plan_ks.htm (12 of 16)

Deploy Database Standards

Oracle Internal & Oracle Academy Use Only

M1_RISD_Baseline_Project_Plan_ks.htm (13 of 16)

Create Security updates from

Oracle Internal & Oracle Academy Use Only

M1_RISD_Baseline_Project_Plan_ks.htm (14 of 16)

Develop Component Test

Oracle Internal & Oracle Academy Use Only

M1_RISD_Baseline_Project_Plan_ks.htm (15 of 16)

Create Physical Design

Oracle Internal & Oracle Academy Use Only

Microsoft Home Page

M1_RISD_Baseline_Project_Plan_ks.htm (16 of 16)

Oracle Internal & Oracle Academy Use Only

Author: Oracle Services Industries

Last Updated: February, 2000

Date Author Version Change Reference

Oracle Internal & Oracle Academy Use Only

Copy No. Name Location