UC BERKELEY EXTENSION

UC BERKELEY EXTENSION Database/Application/Programming Courses Instructor: Michael Kremer, Ph.D. Course Title: SQL Database Programming Course Subtitle: Oracle PL/SQL and SQL Server T-SQL

Instructor: Michael Kremer, Ph.D. E-mail: dbprogramming@ucb-access.org Web Site: http://www.ucb-access.org Copyright 2015 All rights reserved. This publication, or any part thereof, may not be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, storing, or otherwise without expressed permission. 4 th Edition I C O N K E Y Note Example Warning

TABLE OF CONTENT CLASS 1... 1 1. INTRODUCTION TO ORACLE/SQL SERVER DATABASE PROGRAMMING... 1 1.1 SQL and Database Programming... 1 1.2 Structure of Database Programs... 3 1.3 Differences between Oracle and SQL Server... 5 Versions and Editions... 5 Instances and Databases/Tablespaces... 6 Instance Names vs. SIDs... 10 System Databases and System Tablespaces... 11 1.4 Graphical Database Management Tools... 13 SQL Server Management Studio (SSMS)... 13 Oracle SQL Developer... 18 CLASS 2... 21 2. LANGUAGE FUNDAMENTALS OF PL/SQL AND T-SQL... 21 2.1 Structure of Programming Code... 21 2.2 Basic Language Components... 25 Literal Values... 25 Delimiters... 25 Comments... 26 Identifier... 26 Reserved Words... 27 2.3 Datatypes... 28 Numeric Data Types... 28 Character Data Types... 30 Temporal Data Types... 31 Miscellaneous Data Types... 34 2.4 Datatype Conversion... 35 Number Conversions... 36 Date/Time Conversion... 39 2.5 Built-In Functions, System Functions... 43 CLASS 3... 53 3. DECLARING VARIABLES/CONSTANTS... 53 3.1 Variable Declaration Statement... 53 3.2 Variable Assignment Statement... 54 3.3 Constants, Default Values, NOT NULL constraint... 55

4. FLOW CONTROL STRUCTURES... 56 4.1 Decision Structures... 56 The IF Statement... 56 Short-Circuit IF Processing... 60 CASE Statement... 63 Simple CASE... 63 Searched CASE... 65 Order-Dependent Logic... 65 4.2 Loop Structures... 67 Simple Loop... 67 For Loop... 68 While Loop... 69 5. EXCEPTION HANDLING... 72 5.1 Introduction to Exception Handling... 72 5.2 Basic Exception Handling... 73 5.3 Programmer-Defined Exceptions... 80 5.4 Built-In Error Functions... 84 CLASS 4... 89 6. STORED FUNCTIONS... 89 6.1 Introduction to Functions... 89 6.2 Writing Basic Functions... 91 Create Function Statement... 91 Return/Returns Datatype... 95 Function Parameters... 98 6.3 Integration of Functions and SQL... 101 6.4 Advanced Functions... 107 CLASS 5... 113 7. STORED PROCEDURES... 113 7.1 Introduction to Stored Procedures... 113 7.2 Basic Stored Procedures... 114 7.3 Parameters... 122 IN Mode... 124 OUT Mode... 125 IN OUT Mode... 126 Parameter Association... 130 7.4 Overloading Procedures... 136 CLASS 6... 141 8. USING DECLARATIVE SQL IN PROCEDURAL SQL... 141

8.1 DML In Procedural SQL... 141 Insert Statement... 141 Update Statement... 142 Delete Statement... 142 Other DML Statements... 143 Attributes for DML Statements... 143 Returning Information from DML Statements... 146 8.2 Transaction Management... 152 Transactions... 152 Commit Statement... 155 Rollback Statement... 155 SAVEPOINT/SAVE statement... 156 8.3 Autonomous Transactions... 161 CLASS 7... 167 9. DATABASE TRIGGERS... 167 9.1 Overview of Triggers... 167 9.2 DML Trigger Concepts... 168 9.3 Basic DML Triggers... 170 9.4 Advanced DML Triggers... 180 Mutating Table Error... 180 Status Transition Rules... 185 Simple Audit Example... 189 9.5 INSTEAD OF Triggers... 193 CLASS 8... 197 10. CURSORS... 197 10.1 Cursor Basics... 197 Declaring Cursors... 199 Opening Cursors... 202 Fetching Cursors... 203 Closing Cursors... 205 Cursor Optimization Tips... 208 10.2 Cursor Parameters... 209 10.3 Cursor Variables... 213 10.4 Data Updates using Cursors... 219 FOR UPDATE Clause... 219 CURRENT OF Clause... 220 11. DYNAMIC SQL... 225 11.1 Overview of Dynamic SQL... 225 11.2 Basic Dynamic SQL... 227 CLASS 9... 233

12. ADVANCED DYNAMIC SQL... 233 12.1 Parameterized Dynamic SQL... 233 12.2 Dynamic Data Pivoting... 237 12.3 SQL Injection... 242 13. ADVANCED EXCEPTION HANDLING... 252 13.1 Unhandled Exceptions... 252 13.2 Continue Past Exceptions... 253 13.3 Exceptions and Transactions... 257 CLASS 10... 263 14. ADVANCED TOPICS... 263 14.1 Optimistic/Pessimistic Concurrency Models... 263 Concurrency Issues... 263 Single/Multi- Version Databases... 265 Read Uncommited Isolation... 267 Read Committed Isolation... 268 Repeatable Read Isolation... 269 Serializable Isolation... 270 Multi-Version Database, Snapshot Isolation... 271 Conflict Detection... 272 Multi-Version Database, Read Committed Snapshot... 273 14.2 Sending E-mail... 281 14.3 Other Advanced Topics... 281

CLASS 1 1. Introduction to Oracle/SQL Server Database Programming In this first chapter we will cover the basics of structured database programming languages. The standard non-procedural language SQL is supplemented with a procedural framework on most database platforms. Unfortunately, the procedural database language is not standardized at this point. Therefore, every database platform is different in terms of how the procedural framework is implemented and its syntax. 1.1 SQL and Database Programming The non-procedural SQL language has its limitations to meet the various and complex business needs of today s organizations. Since SQL was standardized fairly early on (1980 s and 90 s) and the need for procedural database processing became more evident later on, database vendors added their own procedural framework to interact with non-procedural SQL. Several major RDBMS vendors support a procedural dialect of SQL that adds looping, branching, and flow of control statements. The non-procedural SQL language is set based. A set based approach is actually an approach which lets you specify "what to do", but does not let you specify "how to do". That is, you just specify your requirement for a processed result that has to be obtained from a "set of data" (be it a simple table/view, or joins of tables/views), filtered by optional condition(s). Sometimes, the specification of the "sets" you like to retrieve data from may be obtained by using complex joins/subqueries/conditional case statements, but in the end, there is a set of data from which the resultant set has to be obtained. You never have to specify "how" the data retrieval operation has to be implemented internally. You never have to specify how to implement the "joining operation" internally either. Also, you do not have to specify how to apply a filter condition against the rows. The database engine determines the best possible algorithms or processing logic to do these. On the other hand, procedural SQL programming works differently. Simply speaking, a procedural approach is actually the "programmatic approach" that we are used to working with in our daily programming life. In this approach, we tell the system "what to do" along with "how to do" it. We query the database to obtain a result set and we write the data operational and manipulation logic using loops, conditions, and processing statements to produce the final result. The runtime does whatever we want it to do, however we want it to do. 1. Introduction to Oracle/SQL Server Database Programming 1 1.1 SQL and Database Programming

Using a cursor that executes on a result set row by row is a procedural approach. For example, if you are querying your database to obtain a result set and using a cursor to navigate the result set to do further processing row by row, you are using a procedural approach. Also, if you are using a function in your SQL for processing each row in the result set to calculate a scalar output, you are using a procedural approach. The internal execution engines of databases are designed and optimized for taking "set based instructions" as input (SQL) and executing these instructions in the best possible way (that varies based on a lot of criteria) to produce an output. That is why "Set based approaches" are almost always the better option. When SQL written in a "Set based approach" is issued against the database, the query optimizer generates an execution plan first, and then the execution engine executes the plan to retrieve data from the physical storage and processes the output in an efficient manner. That is, there is a single execution plan tree for each single SQL statement, be it simple or complex. Executing that single execution plan tree is generally a faster operation. But, when we specify our own way of processing a result set (that is obtained by executing a SQL statement) using another SQL statement that works on a row-by-row manner in the result set, the database engine has to execute an execution plan for each and every row, even after obtaining the result set by executing an execution plan. Imagine a row-by-row operation that is executed for a result set containing 1 million rows. In this case, the initial data retrieval operation would require an execution plan to be executed, and later, another execution plan has to be repeated 1 million times for each row processed. That is what happens when a function is executed for each row in a result set. An additional overhead of using functions is the amount of stack I/O that takes place for invoking the function. On the other hand, if you use a Cursor to process a result set row-by-row, while executing, the cursor locks the rows in the corresponding table, and unlocks the rows when processing is done. This involves lots of resource usage on the server, and in the case of large result sets, severely slows down performance. The underlying message here is that you want to minimize the amount of procedural SQL for performance reasons. Many procedural SQL code can be rewritten into non-procedural SQL statements using subqueries and other sophisticated, new SQL commands such as the With clause. 1. Introduction to Oracle/SQL Server Database Programming 2 1.1 SQL and Database Programming

1.2 Structure of Database Programs The structure of procedural database programs is very similar to many other programming languages. Each program has a distinct name, you may pass arguments into the program, and the program can also return values back to the calling environment. This part is called the header section. The structure itself consists of a declaration section where mostly variables are declared and the actual executable section. And last, but not least, there can be an exception section where errors are handled in a customized manner. Leaving the exception section out will trigger the default error handling of the environment. In Oracle as well as in SQL Server the structure of the database programs are equal, they just differ by the implementation or the syntax as shown in Figure 1 below. Oracle PL/SQL SQL Server T-SQL Header Header IS AS Declaration Begin Try Begin Execution Execution Exception End Try Begin Catch Exception Exception End Catch End; Figure 1: Program Structure Syntax Oracle vs. SQL Server 1. Introduction to Oracle/SQL Server Database Programming 3 1.2 Structure of Database Programs

In Oracle only, you can also divide your program into smaller, manageable components by using nested procedures. A nested procedure is a sub program embedded in the main program that can only be called or referenced by the main program. Note: You can always create additional procedures that can be called from each other. The only difference is that they are stand-alone, individual programs. A nested program resides within the main program and belongs to the main program. Oracle PL/SQL Header IS Declaration Main Program IS Begin End; Begin Header Declaration Execution Sub Program Execution End; Figure 2: Nested Program Structure in Oracle 1. Introduction to Oracle/SQL Server Database Programming 4 1.2 Structure of Database Programs

1.3 Differences between Oracle and SQL Server At this point in time, MS SQL Server runs only on the Windows platform whereas Oracle runs on Windows, Linux, and the various varieties of UNIX flavored platforms (Solaris, HP-UX, AIX). Versions and Editions The current version of SQL Server (as of time of this writing) is 2014. Past SQL Server versions include version 2000, 2005, 2008, 2012. Many companies are still running 2005, this was a major release compared to version 2000. Oracle s current version is 12c R1. Oracle has come a long way. The version number 12 actually represents the number of versions the Oracle database has evolved. Many companies are still running Oracle versions 9i at this time. SQL Server 2012 comes with the following versions: Enterprise Editon: The Enterprise Edition is for mission critical applications and data warehousing. Business Intelligence Edition (new): The Business Intelligence Edition is for premium corporate and self-service Business Intelligence capabilities. Standard Edition: The Standard Editions is for basic database capabilities, reporting and analytics. Express Edition: A small footprint, embedded SQL Server engine that can be used for local data storage and small scale system development. The Express Edition is free to download and can be freely redistributed with a software. Developer Edition: Every feature of the Enterprise is available in the Developer Edition. However, it is licensed for use by one user at a time and is meant to be used for development and testing purposes. Note: SQL Version 2008 contained additional editions, such as Premium, Web, Compact, and Workgroup editions. In version 2012, the number of editions has been reduced to basically three (besides Express and Developer editions) to simplify the selection for customers. 1. Introduction to Oracle/SQL Server Database Programming 5 1.3 Differences between Oracle and SQL Server

For the current version of Oracle, the following editions are available: Enterprise Edition: This edition offers top performance for top money. Like the SQL counterpart, every feature and capability of the product is enabled in this edition. Standard Edition: Much like the SQL Server Business Intelligence Edition, the Oracle Standard Edition has major features of the product enabled and is suitable for most business applications. Standard Edition One: This edition is designed for small workgroups and licensed for minimum of 5 users. Express Edition: This is a low footprint, small-scale, starter database for development purposes and is licensed for free redistributions. The Express Edition is still in version 11. Oracle Database Personal Edition: Oracle Database Personal Edition supports single-user development and deployment environments that require full compatibility with Oracle Database Standard Edition One, Oracle Database Standard Edition, and Oracle Database Enterprise Edition. The table below shows the different editions of both products and how they compare: SQL Server 2012 Enterprise Edition Business Intelligence Edition Standard Edition Express Edition Developer Edition Oracle 12c R1 Enterprise Edition Standard Edition Standard Edition One Express Edition Personal Edition Table 1: Edition Comparisons SQL Server vs. Oracle Instances and Databases/Tablespaces The first architecture level difference between SQL Server and Oracle is in the concept of instances and databases. An instance in SQL Server terms means a self-contained application service that involves operating system files, memory structures, background processes and registry information. An instance is represented by a service in Windows and can be either in a running or stopped state. When running, an instance occupies a portion of the server s memory and also spawns a number of background processes. 1. Introduction to Oracle/SQL Server Database Programming 6 1.3 Differences between Oracle and SQL Server

Central to a SQL Server instance are its databases. A SQL Server database is the repository of data and the program code for manipulating that data. If an instance is not running, databases within it cannot be accessed. There are two types of SQL Server databases: system databases and user databases. When a SQL Server instance is first installed, five system databases are created: master, model, msdb, tempdb and resource. If there is more than one SQL Server instance running in a machine, each instance will have its own dedicated set of system databases. An instance cannot start if any of its system databases except msdb is inaccessible or corrupted. User databases on the other hand are created by DBAs and developers after the instance has been installed and the system databases have started. These are the databases that store an organization s business information. In short, a SQL Server instance will always include databases (even if it is only the system ones) and a database will always be associated with one (and only one) instance. At the physical level, a SQL Server database is represented by a set of operating system files residing in the server s disk system. There are two types of database files: the data file and the transaction log file. At the very minimum, a database will have one data file and one transaction log file. A data file is the main repository of information in a SQL database. A transaction log file on the other hand records the changes that have been applied to the data. This file is required by SQL Server for system recovery. A data or log file will always belong to a particular database: no two databases can share the same data or log file. If the database is large, it can have multiple data files. Multiple data files in a database can be logically grouped into structures known as filegroups. With Oracle, it works in somewhat reverse direction. When Oracle starts, it works just like SQL Server in that a portion of the server s memory is allocated for its operation. This memory area, known as the System Global Area (SGA), is divided into a number of distinct structures. Along with the memory space, a number of background processes are also started that interact with the SGA. Together, the memory space and the processes constitute an Oracle instance. Note that the Oracle database is still not in the picture. In fact an Oracle instance could be running perfectly okay without its database even being online or accessible. When installing Oracle, there is an option to install only the software and to create the database later. A database in Oracle is a collection of operating system files. Unlike SQL Server, an Oracle database does not represent the logical grouping of objects; rather it is a single, collective term for a number of files on the disk that primarily hold data. The files that make up an Oracle database can be classified into three types: data file, redo log file and the control file. Data files are where all the data resides. There can be any number of data files in an Oracle database. Redo log files are like SQL Server transaction logs in that they record every change made to the data and is used for system recovery. Control files are a special kind of file that contains small but vital pieces of information about the database. Without 1. Introduction to Oracle/SQL Server Database Programming 7 1.3 Differences between Oracle and SQL Server

this file, the instance will not be able to open the database. Apart from data, redo log and control files, the database will also contain a parameter file, password file and optionally, archive log files. Logical Physical Oracle: Tablespaces SQL Server: Databases Oracle: Data Files SQL Server: DB Files Oracle: Segments SQL Server: N/A Oracle: Extents SQL Server: Extents Oracle: Data Blocks SQL Server: Pages OS Block Figure 3: Logical and Physical Structure of SQL Server/Oracle When an Oracle system starts, at first the instance is created in the memory. The instance then connects to the database residing on disk and finally opens the database for user interaction. When the system is shut down, the instance is erased from memory: all the memory structures and the processes are gone, but the database will still exist in the disk, albeit in a closed state. As said previously, it is possible to have the Oracle instance running without opening the database this is a major difference from SQL Server where an instance cannot start without its systems databases being online first. However, just like SQL Server, it is impossible to connect to an Oracle database if the instance has not started. 1. Introduction to Oracle/SQL Server Database Programming 8 1.3 Differences between Oracle and SQL Server

Generally the relationship between an Oracle instance and its database is one-to-one. An instance will have one database associated with it. A database on the other hand can have one or more instances accessing it. A standalone Oracle installation will comprise of a single instance accessing a single database. Oracle installations configured as RAC (Real Application Cluster) will have multiple instances running in different machines accessing the same database in a shared disk. So where does the logical grouping of database objects lie within Oracle? In SQL Server, this logical grouping is done by the database itself. For Oracle, it is done through something called tablespaces. An Oracle tablespace is a logical structure that groups together tables, views, indexes and other database objects. For example, your production Oracle database may have one tablespace dedicated for the HR application and another tablespace for payroll. Each tablespace is physically represented by one or more data files on disk and form a part of the database. The database is logically made up of a number of tablespaces and the tablespaces in turn are physically made up of one or more data files. So Oracle s equivalent to a SQL Server database is a tablespace. And since they are so similar in their functions, the process of creating a database in SQL Server is quite similar to creating a tablespace in Oracle. Whether creating a database or a tablespace, the DBA needs to specify a name first. The DBA then assigns one or more data files to the database or tablespace and specifies the initial size and growth increments for each file. Just like a SQL Server user database can be made offline or read-only, so can be an Oracle user tablespace. And just like one or more data files in a SQL Server user database can be made read-only, one or more data files in an Oracle user tablespace can be marked offline. However, databases and tablespaces do differ in the following areas: In SQL Server, database files can be logically grouped into filegroups. Oracle tablespaces do not have this concept. In SQL Server databases, each database will have its own transaction log and the log file properties will need to be specified during database creation. For Oracle, transactions for the whole database (that means for every tablespace) are recorded in one redo log. Consequently, there is no provision to create individual log files for tablespaces. For SQL Server, the database can be created with simple recovery mode. Simple recovery mode means the inactive portion of the database log will be truncated after each checkpoint. Oracle has a similar concept, but it is not possible to configure that property for individual tablespaces. 1. Introduction to Oracle/SQL Server Database Programming 9 1.3 Differences between Oracle and SQL Server

Instance Names vs. SIDs Both SQL Server and Oracle allow multiple instances of the server software to run concurrently on the same machine. These multiple execution contexts are completely independent of each other: as far as one database engine is concerned, it does not know or care if another is running on the same box. In SQL Server, this mechanism is enabled through the concept of instances. SQL Server can run either as a named or a default instance. The default instance has the same name as the Windows server hosting it. Obviously, there can be only one default instance per host, but it is possible to run multiple named instances on that same machine. A named instance is identified in the form of HOSTNAMEINSTANCE_NAME, where each INSTANCE_NAME running on the host has to be unique. Each instance will have its own set of binaries with some common components shared between all. SQL Server Host Oracle Host Instance: Self-contained application service involving os files, memory, processes. Instance: Only memory allocation and processes. Schema: Logical grouping of database objects, owner and user of objects Database: Collection of OS files. Database: System databaes(needed for instance to run) and user databases. Tablespace: Logical structure for grouping db objects. Figure 4: SQL Server/Oracle Server Architecture For Oracle, it works the same way. When installing Oracle, the DBA needs to specify a Global Database Name and a System Identifier (SID). Instance and databases are completely separate entities in Oracle. A global database name uniquely identifies a database in the network where it is hosted and can have a fully qualified name in the form of database_name.network_domain_name. A SID on the other hand identifies the instance associated with the database. 1. Introduction to Oracle/SQL Server Database Programming 10 1.3 Differences between Oracle and SQL Server

In most cases where a single instance is associated with a single database, the SID and the database name will be the same. Oracle Real Application Cluster (RAC) environments are an exception: RAC allows multiple instances to access the same database hosted in a shared storage; the instance names are different from the database name in such cases. However, just like a SQL Server machine, an Oracle database server cannot have two instances running with the same SID. Another area of similarity is that once specified during setup, a SQL Server instance name or an Oracle SID cannot be changed later. A SQL Server DBA can run the following query to know the name of the instance he is currently logged on to: SELECT @@SERVERNAME An Oracle DBA will run queries like the following to get the instance and database name: SELECT INSTANCE_NAME, HOST_NAME, VERSION, DATABASE_STATUS FROM V$INSTANCE; SELECT NAME, DATABASE_ROLE, CREATED FROM V$DATABASE; System Databases and System Tablespaces A SQL Server instances will have five system databases (four for versions before 2005) present: master, model, msdb, tempdb and resource. An Oracle database will need a minimum of three system tablespaces for its operation: SYSTEM, SYSAUX and TEMP. The master and the resource databases are the central repositories of all the information SQL Server needs to manage itself. Among many other things, it contains the system configuration settings, list of databases and the location of their files, end-points, linked servers and user accounts (or logins ). System level objects are stored in a read-only database known as the resource database where this information comes from. For Oracle, SYSTEM tablespace is the equivalent of the master database. SYSTEM tablespace contains the data dictionary, which is Oracle s metadata about itself. The data dictionary can be compared to SQL s resource database. And probably you have already guessed: Oracle will not start if the SYSTEM tablespace is unavailable or corrupted. For a SQL Server instance, the model database is the template that is used for every new database created in that instance. You can make a change to the model database and the change will be reflected to every new database created afterwards. For Oracle, there is no such template, but when you create a tablespace, you can specify whether it will be a permanent tablespace or of any other type like a TEMP or an UNDO tablespace. Permanent tablespaces are the ones that hold user data. 1. Introduction to Oracle/SQL Server Database Programming 11 1.3 Differences between Oracle and SQL Server

SQL Server s tempdb is used as a scratch pad for the whole instance. Tempdb is created every time the instance is restarted and destroyed every time the instance is shut down. Oracle s TEMP tablespace does pretty much the same task: it is used to hold large scale sort operation results. However, SQL s tempdb can also be used for row versioning. When enabled for a database, row versioning ensures the database engine keeps track of each version of a data row as it is modified. The pre-modification copy of the row is copied to a version store in the tempdb database. Queries requesting the data row will get the latest committed version. When a read operation uses an isolation level based on row versioning, it does not block other transactions trying to modify the same data. This is because the read query is not placing a shared lock on the data rows. However, this behavior needs to be explicitly enabled for each database. Oracle uses the same concept with a different type of tablespace known as the UNDO tablespace. An undo tablespace holds read-consistent copy of data that is currently being updated by a DML statement. As a user starts making changes to data, a pre-update version of that data is stored in the UNDO tablespace. If another user wants to query those same rows of data, s/he will get the pre-update version from the UNDO tablespace. Unlike SQL s version store, this feature does not have to be explicitly enabled it is part of Oracle s concurrent data access mechanism. Finally, SQL Server s msdb database is required for its Agent service s operation. SQL Server Agent is responsible for scheduled jobs, alerts, replication and log shipping among many other things. Without the msdb database, the Agent service will not be running. There is no clear equivalent of msdb in an Oracle. The SYSAUX tablespace is a system tablespace, created during the installation process. It holds information such as Oracle s Automatic Workload Repository (AWR), spatial and multimedia data, XML database etc. 1. Introduction to Oracle/SQL Server Database Programming 12 1.3 Differences between Oracle and SQL Server

1.4 Graphical Database Management Tools We will be using the following tools to access and manipulate the database: Oracle SQL Developer SQL Server Management Studio (SSMS) The installation instructions can be found on my web site. In this chapter we will be simply covering the basics of how to use these tools. SQL Server Management Studio (SSMS) After you launch SSMS you will see the Connect to Server dialog box as shown in.once you are connected to the database server (SQL Express/LocalDB) you are presented with the following UI: Figure 5: SQL Server Management Studio 1. Introduction to Oracle/SQL Server Database Programming 13 1.4 Graphical Database Management Tools

The hierarchical structure of the SQL Server database contains the following main nodes: Databases: The Databases node is the first node in SQL Server Management Studio. Within the Databases node are one or more subnodes. The first subnode is System Databases. There are additional subnodes for each database contained on the server. Security: To manage users, roles and credentials for the database. Using the Security Node, you can work with logins, add to and remove people from server roles, and create credentials. Server Objects: Server Objects refer to a set of objects used at the server level (not at the database level). These objects include Backup Devices, Linked Servers, and Server Triggers. Replication: To manage database replication. (Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency.) Management: This section includes policy management, SQL Server logs, and legacy services such Data Transformation Services (DTS), in version 2008 they are called SQL Server Integration Services (SSIS). The most important and the most frequently used node is the database node. This node lists all the databases contained in the current server. Figure 6 shows the hierarchy structure under the database node. Database Node Programmability Node Figure 6: Database & Programmability Node For the scope of this course, we will use the Tables, Views, and the Programmability folder. In particular, the Programmability folder is an important folder for this course since it contains the database objects where procedural SQL code is stored. 1. Introduction to Oracle/SQL Server Database Programming 14 1.4 Graphical Database Management Tools

Example 1-1: Create SQL Server HR Database 1. First using Windows Explorer, navigate to c:\temp and create a folder named ProceduralDB. 2. Open SQL Server Management Studio (SSMS). Log in using Windows Authentication mode. 3. Right-click on the Databases Folder and select New Database. 4. Type ProcDB as Right-click on Database Node a name for the database. 5. In the Database files section, scroll to the right and select c:\temp\proceduraldb in the Path section. 6. Click on OK 1. Introduction to Oracle/SQL Server Database Programming 15 1.4 Graphical Database Management Tools

Example 1-1(continued): Create SQL Server HR Database 7. Under the Databases node, the database folder ProcDB is now displayed. In the toolbar, click on the New Query button or right-click on the ProcDB database folder and select New Query. If you clicked the New Query button in the toolbar, make sure to select the ProcDB database from the drop-down list below. 8. A new pane is displayed on the right side. 9. Copy and paste the instructor provided sql script to create the database into this pane. 10.Now click on the Execute button in the toolbar or right-click inside the script and select Execute to run this script. 1. Introduction to Oracle/SQL Server Database Programming 16 1.4 Graphical Database Management Tools

Example 1-1(continued): Create SQL Server HR Database 11.Verify in the output window at the bottom that no errors have occurred. 12.Click on the plus sign next to the Tables folder under the ProcDB Database to view all the database tables. 1. Introduction to Oracle/SQL Server Database Programming 17 1.4 Graphical Database Management Tools

Oracle SQL Developer We will first install SQL Developer into the c:\temp\proceduraldb folder. Since this software is completely JAVA based, the installation does not require any registry entries or other windows installation requirements. Example 1-2: Install Oracle SQL Developer 1. Copy the instructor provided zip file into c:\temp\proceduraldb. 2. Double-click on this zip file and then drag the folder into C:\Temp\ProceduralDB. 3. After the extraction is complete, a folder named sqldeveloper is created under the ProceduralDB folder. 4. In this folder, you find an executable file named sqldeveloper.exe. 5. Double-click on this file to run SQL developer. 6. Create a new connection (green plus sign) and type the following information: Password will be provided by the instructor 7. Click on connect. 1. Introduction to Oracle/SQL Server Database Programming 18 1.4 Graphical Database Management Tools

Example 1-2 (continued): Install Oracle SQL Developer 8. Copy and paste an instructor provided script into the right pane, the so-called SQL worksheet. Click on the Run Script button to create the ProcDB user/schema account. Check the Script Output at the bottom for potential errors, unfortunately there is no overall message whether the script has been successfully executed. 9. Create a new connection using ProcDB as Connection Name and Username, use password hr. 10.Click on the plus sign next to ProcDB to open the object tree. 1. Introduction to Oracle/SQL Server Database Programming 19 1.4 Graphical Database Management Tools

As you can see, the organization of the database is completely different than in SQL Server. There are no subnodes like in SQL Server to provide further grouping. The important objects we will use in this course are of course tables. Besides tables, we will place database code in Packages, Procedures, Functions, and Triggers. Figure 7 shows the object tree in SQL Developer. Figure 7: Oracle SQL Developer 1. Introduction to Oracle/SQL Server Database Programming 20 1.4 Graphical Database Management Tools