Oracle & SQL Server Project Portfolio Jennifer R.

Williams Ferris State University

Oracle --Creating the MISM610_student Table Create table MISM610_student ( StudentId varchar2(20), FName varchar2(20), LName varchar2(20), Comments varchar2(250) ) --This command inserts a row of information into table insert into MISM610_student (StudentId, FName, LName,Comments) values ('01', 'Dr', 'G', 'this is the first record in the table') --Results: 1 row(s) inserted. --This command pulls all records from the table Select * from MISM610_student --Results: STUDENTID 1 FNAME Dr LNAME G COMMENTS this is the first record in the table

--This command shows an update of a row in the table update MISM610_student set Comments = 'This is my updated comment' where studentid = '01'

--Results: 1 Dr G This is my updated comment

--Inserting row information into new table insert into jenniferwilliams (Job,Age,Gender,EmployeeId,LName) values ('Chiropractor','33','F','02','Sandman') insert into jenniferwilliams (Job,Age,Gender,EmployeeId,LName) values ('Fireman','25','M','03','Purple') insert into jenniferwilliams (Job,Age,Gender,EmployeeId,LName) values ('Doctor','40','F','04','Redkin') --Select all from new table select * from jenniferwilliams Results: Nurse Fireman Nurse Therapist Doctor Chiropractor 37 25 37 33 40 33 F M F M F F 3 2 4 2 Purple Sandman Redkin Sandman

--Find job for all Females

select job from jenniferwilliams where gender = 'F' --Results: JOB Nurse Nurse Doctor Chiropractor --Find EmployeeId for Males select employeeId from jenniferwilliams where gender = 'M' --Results: EMPLOYEEID 3 2 --Order by employee Id command select job, employeeId from jenniferwilliams order by employeeId Results: JOB Therapist Chiropractor Fireman Doctor EMPLOYEEID 1 2 3 4

Nurse

--Example of describe command desc jenniferwilliams Results: Data Type Varchar2 Varchar2 Varchar2 Number Varchar2 Lengt h 20 3 1 20 Precisio n Scal e Primary Key Nullabl e Defaul t Commen t 1-5 --Example of three table join select patient.LName, patient.FName, Admission.AdmissionDate, Disposition.Disposition from patient, admission, disposition where patient.patientId = Admission.patientId and Disposition.DispositionId = Admission.DispositionId order by LName, FName, AdmissionDate, Disposition Result: LNAME Brown Davis Johnson FNAME John Linda James ADMISSIONDATE 16-JUN-11 12-JUL-11 15-MAY-11 DISPOSITION ECF Hospital Home

Table JENNIFERWILLIAM S

Column JOB AGE GENDER EMPLOYEEI D LNAME

Jones Miller Moore Smith Williams Wilson

Elisebeth Micheal Barbara Mary Patricia William

11-JUN-11 16-JUL-11 30-AUG-11 10-MAY-11 20-MAY-11 23-AUG-11

ECF AFC Home Home Home ECF

--Patient table prior to insert & delete Select * from Patient Result: PATIENTID 145678 156789 114567 123456 178912 134567 167891 189123 191234 101345 FNAME Patricia Elisebeth Jennifer Mary Linda James John Micheal William Barbara LNAME Williams Jones Taylor Smith Davis Johnson Brown Miller Wilson Moore ADDRESS 432 Centinal Lane 987 Capital Street 982 Praline Lane 123 Townline Road 678 Alabama Street 231 Blueberry Street 100 Larabee Avenue 556 Timber Lane 974 Maple Avenue 371 James Street AREACODE 231 231 616 231 231 231 616 231 231 989 PHONE 5554678 5551121 5556621 5557958 5552179 5552589 5558963 5554682 5557963 5557843

--Example insert row insert into patient (patientId, FName,LName, Address, areacode, phone) values (125862,'Sally','Shephard','425 Golff Road',616,5558911)

Result: 1 row(s) inserted. --Proof of Result select * from patient where FName = 'Sally' PATIENTID 125862 --Delete example Delete from patient where patientId = 125862 --Proof of delete select * from patient where patientId = 125862 Result: no data found --Creating an Index CREATE INDEX Patient_LName ON Patient(LName) Result: Index created. FNAME Sally LNAME Shephard ADDRESS 425 Golff Road AREACODE 616 PHONE 5558911

--Describe Index DESCRIBE Patient_LName

Result: Object Type INDEX Object PATIENT_LNAME --This command allows for a high risk, risk, or low risk identification of each patient. Case Logic is utilized here. select PatientId, CASE DispositionId WHEN 2 THEN 'The patient is High Risk' WHEN 1 THEN 'The patient is Risk' ELSE 'The patient is Low Risk' END from ADMISSION Result: PATIEN TID 134567 156789 101345 178912 123456 145678 167891 189123 191234 CASEDISPOSITIONIDWHEN2THEN'THEPATIENTISHIGHRISK'WHEN1THEN'THEPATIENTISRISK'ELS E'THEPATIENTISLOWRISK'END The patient is High Risk The patient is Low Risk The patient is High Risk The patient is Low Risk The patient is Risk The patient is Low Risk The patient is Low Risk The patient is Low Risk The patient is Low Risk

--Though a way was not identified to utilize this example in the current database; heer is and example of command to increase employee salary. This uses variables, a loop and IF logic. DECLARE sales NUMBER(8,2) := 10100 quota NUMBER(8,2) := 10000 bonus NUMBER(6,2); emp_id NUMBER(6) := 120 BEGIN IF sales > (quota + 200) THEN bonus := (sales - quota)/4 UPDATE employees SET salary = salary + bonus WHERE employee_id = emp_id END IF END My Oracle Experience This portion of the assignment was both exciting and nerve racking. What I had learned from the SQL server assignment was definitely evident; however there were new components that were incorporated into this assignment. Even though there was a learning curve involved, I now feel that I have a better grasp on both Oracle and SQL server commands. There does seem to be some brain storming needed on my end when I get into the increasingly complicated tasks, however thus far I have been able to contemplate the needed variables to make the commands successful. My current comfort level is average with both Oracle and SQL server; my knowledge level is definitely higher than prior to attending this class. I must say that surprisingly I am excited to continue on learning about database creation and utilization in the future.

Description of Concepts: Instance - An object of a particular class. In programs written in the Java(TM) programming language, an instance of a class is created using the new operator followed by the class name. Database A database is an organized collection of data for one or more purposes, in digital form. Scheme - A scheme is a collection of logical structures of data, or scheme objects. A scheme is owned by a database user and has the same name as that user. Each user owns a single scheme. Tablespace - Tablespaces are the bridge between certain physical and logical components of the Oracle database. Tablespaces are where you store Oracle database objects such as tables, indexes and rollback segments. Roles - Roles can be used for most system and object privileges. Privileges granted through a role cannot be used for creating an object (views, packages, procedures, and functions). You need to grant privileges directly to the user for this. User A user can be created to allow someone to create, update, insert, delete etc. in a database. Profile - Profiles are a means to limit resources a user can use. Before profiles can be assigned, they must be created with create profile. Jobs - The job queue is used extensively by Oracle replication facilities, and was originally developed for the purpose of refreshing Oracle snapshots. Redo Logs - The redo log makes it possible to replay SQL statements. Before Oracle changes data in a datafile it writes these changes to the redo log. If something happens to one of the datafiles, a backed up datafile can be restored and the redo that was written since replied, which brings the datafile to the state it had before it became unavailable. Policies - policies are a list of user groups and the resources with which users in the group are to be provisioned or de-provisioned. Access policies are defined using the Access Policies menu item in the Oracle Identity Manager Administrative and User Console.

Patient Database Information & Diagram Database Management & Administration Jennifer R. Williams Database Definition & Purpose This database example is created in a relational architecture. This type of database utilizes relationships between tables to allow retraction of data from multiple tables within the same database. The relational database is guided by the normalization concept. This concept basically identifies the need to keep the relationships simple and to not repeat data where it is not needed. In addition, data within this type of database is dependent on the appropriate key. This particular database diagram was formed to track admissions that are related to a specified high risk diagnoses (CHF, COPD, Pneumonia, MI and Stroke). This database will be set up to monitor admission length, diagnosis, patient disposition and identified referrals. Standards Camel case text is the standard text in this database. Multiple datatypes were utilized and listed with the correlating field in this database outline (i.e.: varchar, char, int & datetime). The table names were kept as short as possible for utilization purposes. Names are characterized as varchar (30) while the address is varchar (50); these remain standard throughout the database. Null was utilized in the phone number fields to show an example of information that is not required. Diagnosis, referral & disposition were standardized at varchar (25); these fields will most likely be in look up format. Keys/Index The primary keys are identified in each table. Foreign keys were utilized in both of the bridge tables as well as the admission table. In this database diagram Id connections are also shown with both primary and foreign keys and identifies connect patient information to needed tables. Each line indicates the connection of primary and foreign keys and the need for that connection to compile the data. The Patient table shows an example of a primary key that is an index. A cluster index was also utilized as a secondary index in this table to allow patient search by name. This would be helpful in a case where the PatientId number or AdmissionId number were not available to the searcher. Each primary key within the tables were chosen to maintain referential integrity; allowing each table to be connected to other when searching for correlating data. Identified Tables & Bridges A patient information table was provided to track the patient identity. The diagnosis table will track the five listed diagnosis and whether the diagnosis is new to the patient. The admission table will track the length of each admission. The referral table will track whether the patient received an out-patient referral for diagnosis support. Finally, the disposition table will track where the patient was discharged to (Home, ECF, and AFC etc.).

Database Diagram
Patient Index Primary Key Index PatientId (int) FName (varchar (30)) LName (varchar (30)) PatientName (varchar (50)) Address (varchar (50)) Address (varchar (50)) AreaCode (varchar (3)) null Phone (varchar (7)) null Primary Key Not Automic Not Necessary Primary Key Diagnosis DiagnosisId (int) Diagnosis (varchar (25)) NewDiagnosis (char (1))

Admission Primary Key Foreign Key Foreign Key PatientDiagnosis PatientId (int) DiagnosisId (int) Foreign Key Foreign Key Referral Primary Key ReferralId (int) Referral (varchar (25)) Description (varchar (100)) Foreign Key Foreign Key AdmissionReferral AdmissionId (int) ReferralId (int) AdmissionId (int) AdmitDate (datetime) FName (varchar (30)) LName (varchar (30)) DischargeDate (datetime) PatientId (int) DispositionId (int) Not Necessary

Primary Key

Disposition DispositionId (int) Disposition (varchar (25)) Description (varchar (100))

Patient Database Dictionary Database Management & Administration Jennifer R. Williams Project Overview This database has been created to track patients with the specific diagnoses of CHF, MI, COPD and Pneumonia. Patients with one or more of these designated diagnoses will be tracked along with their length of stay, disposition and any resources that may have been needed at discharge. Length of stay will consist of the number of days from admission to discharge. Disposition will track whether the patient is discharged to home, ECF, AFC or transferred to another acute care hospital. Resources will include but not be limited to: home care, DME, CMH, private care, hospice, or DHS. The purpose of monitoring this information is to determine whether length of stay, disposition or any utilized resources may have an effect on patient readmission rates. This information will be tracked and reviewed monthly to identify high risk patients that my need additional resources or have a possible need for a different disposition at discharge. High risk patients will be classified by diagnosis, length of hospitalization, and multiple hospitalizations. Other factors that will be monitored include whether the admitting diagnosis was new to the patient and whether there is one or more diagnosis present. Data will be tracked and utilized to determine the possibility for standardized discharge planning in relation to these frequent hospitalization diagnoses. Though federal standards have already been put in place for these diagnoses, there is no concrete evidence that suggests that outside resources like disposition or resources have an effect on re-admission. Current research only touches on in-patient treatment and education. The purpose of this database will be to identify the possible need for the inclusion of outside resources into these federal standards. This database is relational and includes the following tables: Patient Table, Diagnosis Table, Admission Table, Referral Table, Disposition Table, PatientDiagnosis Table and AdmissionReferral Table. Each table is connected to the necessary information with both primary and foreign keys. An additional index was created for FName & LName to allow for searches of patients when the PatientId is not available. Please refer to the attached diagram of the proposed database as well as the provided database dictionary for additional information on how this database will be created and utilized.

Patient Database
Patient Index Primary Key Index PatientId (int) FName (varchar (30)) LName (varchar (30)) PatientName (varchar (50)) Address (varchar (50)) Address (varchar (50)) AreaCode (varchar (3)) null Phone (varchar (7)) null Primary Key Not Automic Not Necessary Primary Key Diagnosis DiagnosisId (int) Diagnosis (varchar (25)) NewDiagnosis (char (1))

Admission Primary Key Foreign Key Foreign Key PatientDiagnosis PatientId (int) DiagnosisId (int) Foreign Key Foreign Key Referral Primary Key ReferralId (int) Referral (varchar (25)) Description (varchar (100)) Foreign Key Foreign Key AdmissionReferral AdmissionId (int) ReferralId (int) AdmissionId (int) AdmitDate (datetime) FName (varchar (30)) LName (varchar (30)) DischargeDate (datetime) PatientId (int) DispositionId (int) Not Necessary

Primary Key

Disposition DispositionId (int) Disposition (varchar (25)) Description (varchar (100))

Data Dictionary Table Descriptions/Definitions Patient Table PatientId FName Lname AreaCode PhoneNumber Contains information about the patient Random integer that identifies the patient Patients first name Patients last name Patients area code Patients phone number Datatype integer varchar (30) varchar (30) varchar (3) varchar (7) null/not null not null not null not null null null Key/Index Primary Key/Index Index Index

Diagnosis Table DiagnosisId Diagnosis NewDiagnosis

Identifies the patient diagnosis Datatype Unique integer to identify diagnosis integer Name of patients diagnosis (drop down) varchar (25) Y/N answer: identifies if diagnosis is new or not char (1)

null/not null not null not null not null

Key/Index Primary Key

Admission Table AdmissionId AdmissionDate DischargeDate PatientId DispositionId

Tracks admission dates Unique integer that identifies each admission Date patient was admitted Date patient was discharged Relationship to PatientId from Patient Table Relationship to Disposition Table

Datatype integer datetime datetime integer integer

null/not null not null not null not null

Key/Index Primary Key

foreign key foreign key

Referral Table ReferralId

Referral Description

Identifies any referral that the patient may Datatype receive at discharge Unique number that identifies specific integer admission referrals Type of referral patient received (drop down) varchar (25) Description of the referrals utilized varchar (100)

null/not null not null

Key/Index Primary Key

not null not null

Disposition Table DispositionId Disposition Description

Identifies the location that patient was discharged to Unique integer that links patient discharge disposition to the patient admission Actual disposition of patient (drop down) Description of disposition

Datatype integer varchar (25) varchar (100)

null/not null not null not null not null

Key/Index Primary Key

PatientDiagnosis Table PatientId DiagnosisId

Bridge table that links the patient diagnosis Datatype with the patient Identifies the patient integer Identifies the diagnosis for a specific admission integer

null/not null not null not null

Key/Index Foreign Key Foreign Key

AdmissionRefferral Bridge table that links the admission to the Datatype referral AdmssionId Identifies the patient admission integer Identifies the referral for a specific ReferralId admission integer Standards

null/not null not null not null

Key/Index Foreign Key Foreign Key

Naming standards will consist of utilization of Camel Case characters with a 20 character limit. No abbreviations will be used as none of the names exceed the 20 character limit. The database name will be consistent with its purpose Patient Database. The tables will be named according to their purpose: Patient Table, Admission Table, Disposition Table etc. Bridge table names will be a combination of the table names; abbreviations will be utilized and defined as need to prevent surpassing the 20 character limit. Table names will be kept as short as possible for utilization purposes. Names are characterized as varchar (30) while the address is varchar (50); this is to remain standard throughout the database. Phone information will be characterized as null; this information is not required to track length of stay, resources or disposition of patients. Diagnosis, referral & disposition will be established as drop down text and will be updated as needed.

Datatype standards will include numerical information stored as integers. Alphanumeric information will be stored a varchar. Dates will be stored as datetime datatypes. Char (1) will be utilized for y/n questions. Each table will have a primary key excluding the bridge tables. There will only be one index for processing speed: FName & LName. The patient number will be defined as a key and index. Foreign keys will be utilized to maintain relationships with needed tables. This structure will keep the process of monitoring information as simple as possible. Examples of impropriate key use, redundant and repeating data are demonstrated in the database diagram and will be removed from the database as indicated. Software will be maintained by IT. All computers are HP brand and include a minimum of Microsoft Windows 7 software. Oracle 9i will be used to maintain the SQL databases that will be created. This database and any that need to be created in relation to this one will follow both relational and normalization guidelines in order to prevent redundant and repeating data. Physical Security Computers containing access to patient information will be monitored by security cameras located throughout the building. Camera maintenance will be reviewed and maintained by the maintenance department. The building is staffed at night; however for added security for both patients and database systems, there is a lockdown of each entrance after the hour of 5 P.M. until 6 A.M. with the exception of the emergency entrance which will remain open until 9 P.M. After this time, doorbell access will need to be utilized. There will be assigned security at the emergency door after 7 P.M. Door security will be evaluated every two hours by security until 6 A.M. Any breech will be directed to the needed entities to review any issues that may have resulted. The IT department as always is locked at the end of the day (5 P.M.) by the domain administrator. As IT is in basement, the elevators will lock out of this area past 5 P.M. Network/Database security A combination of both network and database security will be utilized to secure database information. Each department already has access to the network related to needs of that specific area. The domain administrator is currently assigned to the security administrator position in the IT department. This individual will be in charge of assigning both the database log in and password information. Network and database access will be assigned according to need. These decisions will be overseen by the IT administrator and the database administrator. The database administrator for this project will be one designated discharge planner. This individual will enter information as patients are discharged from the hospital. Other planners as well as additional needed personnel will have access to pulling information of viewing only depending on need. This need will be communicated to the IT department by the designated discharge planner and will be reviewed prior to access being allowed. As individuals are assigned new positions, promotion, reassignment or termination, security information will be reviewed, changed and terminated as needed. Each employee will be trained to sign off of the database prior to leaving their station. In the case of non-compliance with this policy, an unattended or utilized screen will automatically lock after 2 minutes without activity. Log in/Password Test systems will only be accessed during database education hours; a temporary user name and password will be created prior to each education group to prevent unwanted access in test prior to the implementation of the actual database. A log in and password will be assigned to the database administrator as well as other planners and personnel that are deemed necessary to have access to the database information (DON, Clinical Leaders etc.). Each assigned log in name will include the first initial of the first name followed by the first four letters of the last name. Each password will be

assigned randomly with a combination of 1 special character, 1 number and 1 capitalized letter with an 8 character minimum. The user will be required/prompted to change his/her password upon the first use of the temporary password. The same combination of 1 special character, 1 number, 1capital letter and a minimum of 8 characters will be required of the user. The user will be prompted to change their password every 90 days to maintain security. Summary My project overview includes the purpose of the database as well as the reasoning behind it. I can definitely see how this project could continue to grow into multiple databases and additional tracking of information related to the goal of the proposed project. The creation of this database has been an eye opening experience regarding the thought process, set up, creation and implementation of a database. I have been involved in many projects that utilize a database setting. I have incorporated my ideas of the information needed for a database; however I have never actually had to assist in the creation and thought process behind a database. This assignment has helped me realize the needed relationships within a database that allows information to be tracked accordingly and without excess. Creating the data dictionary was difficult at first, although fell into place when I realized that I was just explaining my purpose for utilizing the information that I am creating. Identifying the standards and security needs of the database assisted me in the realization that database information needs to be protected and is not necessarily the simplest process. The reasoning for the data dictionary is now evident; others will need to be apprised of the definitions and reasoning for utilizing certain standards within the database. Though I have been previously frustrated with the IT department/data administrator at work for not allowing me access to certain areas that I may have needed, I now see the purpose in keeping track of who has access to certain types of information. As I was writing the security section of this assignment, I was also surprised to note that the physical security at the hospital in which I work is not necessarily the best planned or implemented process. In summary, I have learned a great deal about database standards, purpose and security within the process of this assignment.

SQL Server Project Jennifer R. Williams Ferris State University

Rowcount is a way to determine the number of rows in a table; the execution statement identifies that the patient table has 10.

An unqualified select retrieves information from each row available in the table. This example shows three columns in the ten rows of the patient table.

A qualified select retrieves information from specified rows of the table that has a specified item. In this example only the patients with an area code 231 were identified in the execution.

This is an example of a selected address prior to an update command.

This query allows a specific field to be altered by requesting an update of that field. This example shows that the update was successful with 1 row being affected.

Here is the final execution statement showing that the address has now changed.

Delete allows us to remove a row from a table. This example shows one row affected by the delete query.

The truncate query allows us to delete all of the information from a specified table. This example shows that the command was completed successfully, deleting all rows in the Referral Table.

This example shows that there are now no available rows in the Referral table; again confirming the truncate command.

Insert allows us to input information into a specified row of a table. A value is the actual information that is to be inserted. This example shows the success of one row affected.

This example shows that the insert command was successful by showing the three new fields of patient information.

The create table query allows the creation of new tables. This example shows the attempt to create a table with multiple columns. It is shown that the command to create a Patient2 table was completed successfully in the execution.

This example shows how to insert new rows into the new table. There were three rows completed. The final row is shown in red with a successful completion identified by 1 row affected in the execution statement.

The command select * was utilized in his example to show that the new rows were added to the new Patient2 table.

Rowcount allows us to retrieve a certain number of rows from a table with only certain information; in this case LName, FName & Address. The order by command was utilized in this query to show that rows can be placed in order by a certain column. Note that the results are ordered by LName as requested in the query.

This query identifies how tables can be connected and information retrieved from each by utilizing the Id connections. In this case patient FName, LName, AdmisionDate & Disposition were able to be identified in one execution.

This query shows at the top how to use a substring command to pull information from multiple tables. In this case patient tables are connected to patient Ids. The results show the connection between patient names and diagnosis. The additional portion of this query shows the use of MIN, MAX, SUM and AVR. This command is utilized with number fields.

A group by statement allows us to query information and group it by a certain column. In this case the results were grouped by LName. Results are shown in alphabetical order.

This query shows an example of a successful stored command that can be utilized to insert information into a table automatically; in this case, PatientId, LName & FName.

My SQL Server Experience The creation of this database with the use of the SQL server was an enlightening experience. I have always been interested in computers; however have never really seen this side of the process. There have been many instances where I have utilized Excel and other spreadsheet programs to create spreadsheets. Database is defiantly a completely different computer environment than I am used to. It has also been very interesting seeing how a database is created and managed. Importing table information with Excel as well as inserting tables through text in SQL was both equally interesting. In this process I have learned how a database can be set up to be a useful tool in storing and finding information, especially in the healthcare field. As I continued on with the assignment and deciphering each step within the queries, I found that the process did become easier to understand. Navigating through the SQL program helpful as well; I found myself exploring and trying new things just to see if they would work. I will have to say that initially I did not think I would enjoy database so much. Now that all of the information has come together, a light has come on and assisted in my knowledge of this process. I can now see the need of creating tables with keys, indexes, foreign keys and the needed relationships. The different commands like Select, When, Where, Insert, Group by etc. now make perfect sense and I assume that stored procedure can only make this all simpler. The table join and substring queries were a little confusing at first, although now are seen as useful ways to retrieve needed information. I now look forward to continuing with experimentation in database and improving my knowledge on the process.