1. Cincinnati Bell Telephone INsideOUT Database Redesign
Senior Design III
Final Presentation
Vernon Chamberlain

2. Overview Statement of Problem Solution Description User Profile
Timeline
Technical Elements
Budget
Deliverables
Proof of Design
Conclusion

3. Statement of Problem Support terminated for Informix database
INsideOUT Database
Business functions served:
Work Orders / Service Orders
Job Costing
Material Reporting
Time Reporting
Vendor Billing
Applications are managing the data.

4. Solution Description Structure Naming Conventions Security Tier
Efficient Use of Database Storage
Minimizing Redundancy
Centralizing Common Processes
The redesign of the INsideOUT database focused on structure, naming conventions, security, efficient use of database storage, and minimizing redundancy. The redesign also included incorporating common processes into stored procedures and triggers instead of in the external software code. The structure and naming conventions of each table was analyzed to verify if it required normalization. If so, the table was updated for consistency and efficiency as required. Normalizing the database resolved duplication issues, eliminated the existence of virtually unused columns, and separated unrelated data that was contained in the same entity.

5. User Profile

6. Timeline Senior Design I Accomplishments – Fall 2007
Researched and Analyzed Database
Began Database Redesign
Wrote, submitted, and presented the Proposed Project
Senior Design II Accomplishments – Winter 2008
Created new entities
Researched and Analyzed Application Code
Wrote, submitted, and presented the Design Freeze
Senior Design III Accomplishments – Spring 2008
Created Stored Procedures, Triggers and Views
Tested the entire project
Wrote, submitted, and presented final project at Tech Expo
Present final project June 9th 2008
Once I receive feedback, I will update, finalize and submit my Senior Design Proposal.
Then I will continue my Research and Analysis of the INsideOUT database, and the code of the applications and functions that access its data.
During winter break, I will start the first step of Phase 1, designing the Normalization concept.

7. Technical Elements Hardware Software Database Server
Portable Hard Drive
Software
Windows Server 2003 Standard Edition
Oracle Database 10g
Toad for Oracle Freeware
PL/SQL Developer (all around automations)
Microsoft Visual Studio .NET 2005
Microsoft Visual Source Safe

8. Budget Item Description Real Cost My Cost TOTALS $47,486.00 Server
Provided by CBT
$ 5,000.00
$0.00
Windows Server Std Ed
999.00
0.00
Oracle Database - Enterprise
40,000.00
Visual Studio .NET 2005
799.00
Visual Source Safe
549.00
Toad for Oracle, Freeware
DBA Freeware
Portable Hard Drive
Mine – Store Project
139.00
TOTALS
$47,486.00
Figure 3 Proposed Budget, Sources: (2, 6, 11, 15)

9. Deliverables Structure New tables that adhere to industry standards
Efficient use of database storage
Naming Convention
Standardized Column and Entity names to create a higher degree of manageability and consistency
Application Functionality as Stored Procedures and Triggers
Centralization of current code in the database. This creates a single point of accountability and simplifies updating much of the code.
Incorporation of common processes into stored procedures, triggers and functions using PL/SQL
Added Security Tier
Redundant in-line SQL statements are being created as stored procedures, functions, and triggers as deemed necessary.
By implementing the code within the database, the overall system will have an added tier of security.
Minimize Redundancy
The redesign minimizes redundancy that currently occurs within the database. Tables such as JOB and WOFRONTPAGE carry much of the same data.

10. Proof of Design Structure:
New tables were created to hold data specific to the table itself. The data from the old JOB table was transferred to these new tables, minimizing empty fields in the database.
Database storage is now more efficient due to breaking down larger tables into small tables, allowing for the data to be more atomic. This process frees up space, helps with processing efforts, and makes the database structure more logical. When accessing data, the database no longer needs to scan through all the rows and columns of one large, somewhat empty table. The database can now search for data in a smaller more fully-utilized tables (See Appendices A and B).

11. Proof of Design Naming Convention:
The naming convention was standardized. Tables were named so that like entities would stay in close proximity to one another, allowing for easier management by the administrators (e.g. JOB_BUDGET next to JOB).
The column names holding the same information are now named the same thing throughout the database. Columns that were once named JOB_JOB_NO in the JOB table, ESTIMATE_NO in the MYHR_IMPORT table, and CURR_WORKORDER in WOFRONTPAGE, to name a few, are now named WO throughout the database.
Work order name, now represented in the WO columns throughout the database, is known redundant data that is stored in multiple tables. This redundancy is a requirement request made by the administrator of the INsideOUT database, and is deemed an acceptable redundancy due to the added benefit of manageability.

12. Summary Application Functionality as Procedures and Triggers
The stored procedures for this project centralize the code in the database. New application functionality specific to the database is now contained in stored procedures and triggers. This change in the overall system has proved efficient and manageable. Centralizing code that was repeated in a variety of applications provides a great sense of control and assurance that all applications are being updated appropriately during future code changes. Moving application functionality was, of course, a learning experience, but PL/SQL is much stronger and more effective than once perceived. Examples of new SQL statements that were moved into the database can be seen in Figures 7 and 8.
In-line SQL Statements in Visual Basic 6 Code

13. Summary Application Functionality as Procedures and Triggers
The stored procedures for this project centralize the code in the database. New application functionality specific to the database is now contained in stored procedures and triggers. This change in the overall system has proved efficient and manageable. Centralizing code that was repeated in a variety of applications provides a great sense of control and assurance that all applications are being updated appropriately during future code changes. Moving application functionality was, of course, a learning experience, but PL/SQL is much stronger and more effective than once perceived. Examples of new SQL statements that were moved into the database can be seen in Figures 7 and 8.
PL/SQL Code created inside the Database as a Stored Procedure

14. Proof of Design Added Security Tier:
The centralization of code pulled in the various in-line SQL statements, which makes the database more secure by putting statements behind a security tier of the overall multi-tier programming. This allows the applications to simply call the stored procedure and pass the necessary variables. The variable names are then mapped to the actual column names in the table, keeping the table structure secure as seen in Figure 9.
New Stored Procedure for COSTING table information

15. Proof of Design Minimizing Redundancy:
Through the process of researching the INsideOUT database redundant data became evident. Two tables specifically were the worst culprits: JOB and WOFRONTPAGE. These two tables were more closely analyzed. It was decided that WOFRONTPAGE would be minimized and JOB would store what was previously redundant data. WOFRONTPAGE was disassembled; redundant columns that were also found in JOB were deleted from WOFRONTPAGE. A new table JOB_FRONTPAGE now holds the data that remained from JOB (See Figure 1).
The JOB table and its subsequent redesign is a prototype of this project’s potential. It also adds efficiency by effectively querying in a shorter amount of time, making multiple calls to the database quicker. This efficiency is magnified when there are over 200 potential users accessing the database.
This centralization positively affects the overall system and its manageability in two ways. First, the centralization creates a single point of execution, rather than having the function duplicated in many different areas of the multiple applications’ code. Secondly, the application will call the stored procedure and send its variables. The stored procedure will then process the request and send the results back to the application. This improvement takes the process requirement away from the local machine and the application, speeding up the end user experience.
Table Comparison of Same Data in Different Columns

16. Conclusion INsideOUT Database was in a state of disrepair
INsideOUT needed normalization, stored procedures, and triggers
INsideOUT is now more efficiency and manageable, and now has a higher level of security

17. Questions?
Questions?