Martes, Jueves y Viernes 18:30 22:30 Gustavo Carren Gmez gcarreong@hotmail.

com

TEMARIO Fundamentos DB2 Utilidades para Administracin Store Procedure Administracin Tunning SQL Programacin Avanzada y Java para DB2 TOTAL

HORAS 5 5 25 5 20 30 90

The DB2 database application development environment is composed of several software elements:  operating system;  DB2 Client;  database application programming interface (API);  programming language;  transaction manager; and  development tools.

For each of these elements, choosing which software to use depends on a variety of factors: what is supported; For example: DB2 supports a finite number of operating systems, and database APIs; and for each API, there is a finite list of supported programming languages. ease of use; There are some integrated development environments that make developing database applications much easier. the nature of the database application you are developing; A web-based application has particular needs that other applications don t have. strengths of the particular software. For example: static,embedded SQL might perform better than dynamic SQL in some circumstances

DB2 database application development is supported on the following operating systems:  AIX  HP-UX  Linux  Solaris  Windows

There are restrictions about when you can use available 32-bit or 64-bit architectures:  With Linux on x86 and 32-bit Windows operating systems, only 32-bit DB2 database instances are supported. On all other operating systems, only 64-bit db2; database instances are supported.  32-bit database applications can be run with either a 32-bit or 64-bit DB2 client, and developed with either a 32-bit or 64-bit DB2 Client.  There are differences for building applications in 32-bit and 64-bit environments in most cases on these operating systems.

The following application programming interfaces can be used to access a DB2 database:        CLI or ODBC embedded SQL JDBC or SQLJ OLE DB Perl DBI PHP ADO .Net  OLE DB .Net  ODBC .Net  DB2 .Net

DB2 database application development is supported in the following languages:  C v C++  COBOL  Fortran  Java  Perl  PHP  .Net languages

IBM integrated database application development environments The Developer Workbench Rational Application Developer Database application plug-ins for integrated development environments IBM DB2 Development Add-In for Visual Studio Eclipse DB2 Plug-In Tools for developing SQL Statements Toad for DB2 SQL Assist SQL Builder SQL Editor Command line processor Database application monitoring and performance tuning tools Event Monitor CLI/ODBC/JDBC Static Profiling

The supported operating systems for Linux include:  Red Hat Enterprise Linux 4 (RHEL4) Update 2  SUSE Linux Enterprise Server 9 (SLES9) Service Pack 2

To install a DB2 client or server product, the following operating system, software, and hardware prerequisites must be met:

Once you have launched the Control Center, you can verify that your database was created by finding it in the Object Tree that fills the left side of the Control Center window.

EMPLOYEE and DEPARTMENT are entities which store Employee and Department information in the tables. Consider few statements as below Employee Id of an employee cannot be NULL or duplicate. Every employee must belong to a Department

1. All information in the database must be stored as values in a table 2. All database information must be accessible through the combination of a table name, primary key and column name. 3. The database must use NULL values to indicate missing or unknown information 4. The database schema must be described using the relational database syntax 5. The database may support multiple languages, but it must support at least one language that provides full database functionality (e.g. SQL) 6. The system must be able to update all updatable views 7. The database must provide single-operation insert, update and delete functionality

8. Changes to the physical structure of the database must be transparent to applications and users. 9. Changes to the logical structure of the database must be transparent to applications and users. 10. The database must natively support integrity constraints. 11. Changes to the distribution of the database (centralized vs. distributed) must be transparent to applications and users.

An entity is a person, place, object or concept about which the organization wishes to maintain some data (e.g., STUDENT). Attributes are certain properties of an entity that is of relevance to the firm (e.g. Student_ID). Relationships are associations between the instances of one or more of the entities. e.g. Student TAKES Courses where Student and Courses are two entities and "TAKES" is the relationship between them. Cardinality of Relationships Relationship between the entities (tables) can exist in three forms as listed below. a. One-to-one relationship Two entities are related by a single relationship. For example, a Manager can manage one and only one Department.

b. One-to-many relationship An entity can share multiple relationships with the other entity. For example, a Department can contain multiple Employees. c. Many-to-many relationship Two entities can share multiple relationship with each other. For example, a Master Part can contain several Parts, while a Part can be used in multiple Master Parts. Primary Key It is a column in the table which carries a unique and definite value throughout the table. Foreign Key It is a column in the Child table which always points to an attribute value in its Parent table.

 First Normal Form  Second Normal Form  Third Normal Form  Boyce Codd Normal Form  Fourth Normal Form  Fifth Normal Form

Moving repetitive attributes in a table to a separate entity. Consider the below example of ORDER data for a day for a given Customer. Note that a Customer Id 100 orders 3 items in the day. In non-normalized state, all attribute values are stored in the same record. Note the iteration of the NAME, QTY, and POS attributes. In normalized state, the repeating attributes are segregated in separate records

Once the data passes the 1NF, the attributes which are same in multiple rows can be moved to separate tables. 2NF talks about creating relationship between the two tables where one table contains the primary key data, while the other one contains the repetitive data for each key value. Consider an example where Customer data needs to be normalized. A record contains Customer Id as key, its details and Item details. Since items and customer share a relationship, they logically appear in multiple records. But, customer details, which do not share any relation with items, unnecessarily repeat in the records. They can be maintained in separate table.

Once the data passes through 1NF and 2NF, it is eligible for 3NF. It refers to the removal of non key attributes. The attributes which are not dependent on the primary key of the table must be grouped as a separate entity. In the below example, Customer and Items share relationship. The entity Item contains non key attributes like Item Mfg date and Item Prod date, which are not dependent on the Order Number Key. Instead, they describe a property of an Item.

Multi-valued dependencies are broken down into separate entities. This implies that the attributes which are not dependent on the primary key can be segregated into different tables. In the example, the table records the Marks obtained by a student in Term and Final exams in three subjects. Since Term and Final attributes are mutually exclusive and key column dependent, they can be treated as separate entities.

It is also called projection-join Normal form. A data satisfies 5NF if a unique pair is formed by the combination of one or more candidate keys. This implies that a set of data can be represented in more than one small entity

DML vs DDL Sentencias de Insercin Sentencias de Actualizacin Sentencias de Borrado Sentencias de Seleccin Select Distinct Joins Sum, count, Max, Min, Avg, etc Subquerys

Easy to understand Eases the physical design from Logical design

employee

The ER model is focused on Data and not on process or methodology.

The database design process can be divided into six steps:  Requirements Analysis  Conceptual Database Design  Logical Database Design  Schema Refinement  Physical Database Design  Security Design

The very first step in designing a database application is to understand what data is to be stored in the database, what applications must be built on top of it, and what operations are most frequent and subject to performance requirements. In other words, we must find out what the users want from the database This is usually an informal process that involves discussions with user groups, a study of the current operating environment and how it is expected to change, analysis of any available documentation on existing applications that are expected to be replaced or complemented by the database, and so on. Several methodologies have been proposed for organizing and presenting the information gathered in this step, and some automated tools have been developed to support this process.

The information gathered in the requirements analysis step is used to develop a high-level description of the data to be stored in the database, along with the constraints that are known to hold over this data. This step is often carried out using the ER model, or a similar high-level data model.

We must choose a DBMS to implement our database design, and convert the conceptual database design into a database schema in the data model of the chosen DBMS. We will only consider relational DBMSs, and therefore, the task in the logical design step is to convert an ER schema into a relational database schema. The result is a conceptual schema, sometimes called the logical schema, in the relational data model

The fourth step in database design is to analyze the collection of relations in our relational database schema to identify potential problems, and to refine it. In contrast to the design requirements which analysis are and

conceptual

steps,

essentially

subjective, schema refinement can be guided by some elegant and powerful theory. We discuss the theory of normalizing relations

In this step we must consider typical expected workloads that our database must support and further refine the database design to ensure that it meets desired performance criteria. This step may simply involve building indexes on some tables and clustering some tables, or it may involve a substantial redesign of parts of the database schema obtained from the earlier design steps.

In this step, we identify different user groups and different roles played by various users (e.g., the development team for a product, the customer support representatives, the product manager). For each role and user group, we must identify the parts of the database that they must be able to access and the parts of the database that they should not be allowed to access, and take steps to ensure that they can access only the necessary parts. A DBMS provides several mechanisms to assist in this step