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

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

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.

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.

User Profile

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.

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

Budget Item Description Real Cost My Cost TOTALS $47,486.00 Server Provided by CBT $ 5,000.00 $0.00 Windows Server 2003 - 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)

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.

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).

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.

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

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

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

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

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

Questions? Questions?