FACULTAD DE CIENCIAS Y TECNOLOGA

RED NACIONAL UNIVERSITARIA UNIDAD ACADMICA DE ORURO

Facultad de Ingenieria Ingeniera de Sistemas

CUARTO SEMESTRE
SYLLABUS BASES DE DATOS
Syllabus elaborado por: Ing. Alejandro Guzmn M.

Gestin Acadmica I/2011

N I V E R S

I D A

D E 1

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

UDABOL
UNIVERSIDAD DE AQUINO BOLIVIA Acreditada como PLENA mediante R. M. 288/01

VISION DE LA UNIVERSIDAD Ser la Universidad lder en calidad educativa. MISION DE LA UNIVERSIDAD Desarrollar la Educacin Superior Universitaria con calidad y competitividad al servicio de la sociedad.

Estimado(a) estudiante: El syllabus que ponemos en tus manos es el fruto del trabajo intelectual de tus docentes, quienes han puesto sus mejores empeos en la planificacin de los procesos de enseanza para brindarte una educacin de la ms alta calidad. Este documento te servir de gua para que organices mejor tus procesos de aprendizaje y los hagas mucho ms productivos. Esperamos que sepas apreciarlo y cuidarlo.

N I V E R S

I D A

D E 2

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

I. SYLLABUS Asignatura: Cdigo: Requisito: Carga Horaria: Horas tericas Horas prcticas Crditos: II. OBJETIVOS GENERALES DE LA ASIGNATURA. Fundamentar y valorar la importancia de las Bases de Datos dando a conocer los conocimientos fundamentales, tericos y prcticos; necesarios para comprender el funcionamiento, diseo e implementacin de una base de datos. Aplicar el lenguaje SQL para efectuar consultas, actualizar y crear vistas con bases de datos en la implementacin de sistemas. Definir el esquema de seguridad SQL que impide el acceso no autorizado a los datos en un sistema a ser implementado. III. PROGRAMA ANALTICO DE LA ASIGNATURA. 1. FUNDAMENTOS DE BASES DE DATOS 1.1. Definicin de Bases de Datos. 1.1.1. Dato. 1.1.2. Informacin. 1.1.3. Tablas-Terminologa 1.1.4. Bases de Datos Sistemas de Gestin de Bases de Datos 1.1.5. Esquema de Bases de Datos. 1.1.6. Administrador de Bases de Datos. 1.2. Objetivos de los Sistemas de Bases de Datos. 1.2.1. Introduccin. 1.2.2. Objetivos de los Sistemas de Bases de Datos. 1.3. Abstraccin de la informacin. 1.3.1. Nivel Fsico. 1.3.2. Nivel Conceptual. 1.3.3. Nivel de Visin. 1.4. Modelos de Datos. 1.4.1. Modelo. 1.4.2. Tipos de Modelos de Datos. 1.4.2.1. Modelos lgicos basados en objetos. 1.4.2.1.1. Modelo Entidad Relacin. 1.4.2.2. Modelos lgicos Basados en registros. 1.4.2.2.1. Modelo Relacional. 1.4.2.3. Modelos Fsicos de Datos. 1.5. Lenguaje de Bases de Datos. 1.5.1. Lenguaje de Definicin de Datos.
U N I V E R S I D A D D E 3 A Q U I N O B O L I V I A

Base de Datos CMP 228 CMP 216 80 horas 60 20 4

FACULTAD DE CIENCIAS Y TECNOLOGA

2.

3.

4.

5.

6.

1.5.2. Lenguaje de Manipulacin de Datos. 1.6. Sistema Manejador de Bases de Datos. 1.6.1. Manejador de Bases de Datos. 1.6.2. Administrador de Bases de Datos. 1.6.3. Usuarios de las bases de Datos. MODELO ENTIDAD RELACION 2.1. Conceptos Bsicos. 2.1.1. Entidades y conjunto de entidades. 2.1.2. Conjuntos de Relaciones. 2.1.3. Limitantes de Mapeo. 2.1.4. Llave primaria. 2.1.5. Diagrama Entidad Relacin. 2.1.6. Generalizacin y especializacin. 2.1.7. Diagrama de Clases Persistentes (UML) MODELO RELACIONAL 3.1. Introduccin. 3.2. Estructura del modelo relacional. 3.3. El modelo relacional y la arquitectura ANSI. 3.4. Los valores nulos en el modelo relacional. 3.5. Dinmica del Modelo relacional. NORMALIZACION 4.1. Conceptos Bsicos. 4.2. Dependencias Funcionales. 4.3. Formas Normales. 4.3.1. Primera Forma Normal 4.3.2. Segunda Forma Normal. 4.3.3. Tercera forma Normal. 4.3.4. Forma Normal de B. Cood. LENGUAJE DE CONSULTAS SQL 5.1. Introduccin. 5.2. Componentes del SQL 5.3. Consultas de Seleccin. 5.4. Criterios de Seleccin. 5.5. Agrupar Registros 5.6. Consultas de Accin. SISTEMAS DE BASES DE DATOS 6.1. Datawarehouse 6.2. Datamart 6.3. Modelo Cliente-Servidor 6.4. Bases de datos distribuidas

IV. SISTEMA DE EVALUACIN DE APRENDIZAJES El sistema de evaluacin hace hincapi en varios tipos de calificacin: Diagnstica: es la evaluacin de los saberes o conocimientos previos de los y las estudiantes, as como de sus ritmos y estilos de aprendizaje y sus tipos de inteligencia, que sirve al docente como punto de partida para, el desarrollo curricular, para la mejor organizacin y estructuracin de las secuencias de aprendizaje, de modo que estas tengan en cuenta no slo el punto de partida del grupo con el que trabajar durante el semestre sino adems las diferencias y especificidades de cada estudiante para que los aprendizajes resulten ms efectivos y permitan el ptimo desarrollo integral de cada uno(a).
U N I V E R S I D A D D E 4 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Procesual o de desempeo o formativa: En esta forma de evaluacin se valora el avance del o de la estudiante de su nivel de desarrollo real (detectado mediante la evaluacin diagnstica) a su nivel de desarrollo potencial (detectado mediante diversas actividades o tareas). Esta forma de evaluacin, por su naturaleza, es eminentemente cualitativa aunque puede ser valorada cuantitativamente mediante un sistema de puntaje que permita apreciar los avances del o de la estudiante en su zona de desarrollo prximo (zdp) (o, incluso, fuera de ella, en el caso de que el proceso de aprendizaje rebase la misma y d lugar a nuevas zdp). La materia de Bases de Datos dentro la evaluacin procesual contempla la realizacin de cuestionarios, prcticas de clases, trabajos de investigacin, Seminarios por parte de expertos en el rea (Congresos), evaluacin diaria, desarrollo de Work Paper, Difs, aula abierta (Brigadas) y trabajo final de curso (proyecto). De resultados del proceso de aprendizaje: es la valoracin de los resultados de los procesos de aprendizaje del o de la, estudiante durante el semestre. Esta forma de evaluacin es tanto cualitativa como cuantitativa, por su naturaleza y por la funcin que cumple dentro de la evaluacin. La evaluacin de resultados en la asignatura especfica se llevar a cabo de forma terica, prctica y de laboratorio, adems es sobre 50 % de la calificacin del primer y segundo parcial, en el caso de la evaluacin final es de 100%, que por disposiciones actuales esta dividido en 50% como prueba final y 50% procesual (desarrollo, presentacin y defensa del trabajo final de curso), las evaluaciones se reflejan a continuacin: EVALUACION PARCIAL 1 PARCIAL 2 FINAL PROCESUAL 50% 50% 50% DE RESULTADO 50% 50% 50% TOTAL 100% 100% 100% 100%

EVALUACION FINAL PROMEDIO PARCIAL 1, 2 Y FINAL V. BIBLIOGRAFA: BIBLIOGRAFA BSICA

Korth, Silberschatz: Fundamentos de Bases de Datos, Editorial McGrawHill, Interamericana Espaa, 2002. C.J. Date: Introduccin a sistemas de base de datos, Editorial Feliz Varela.

BIBLIOGRAFA COMPLEMENTARIA Adoracin de Miguel, Paloma Martnez: Diseo de base de datos, Alfaomega, 2001. James R. Groff Pul N. Weinberg: Aplique SQL, Ed. Mc Graw Hill, ao 1999. Martn, James: Organizacin de Bases de Datos, Ed. Prentice Hall.

VI. CONTROL DE EVALUACIONES

FACULTAD DE CIENCIAS Y TECNOLOGA

1 evaluacin parcial Fecha Nota 2 evaluacin parcial Fecha Nota Examen final Fecha Nota APUNTES

N I V E R S

I D A

D E 6

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

VII. PLAN CALENDARIO

DEL

AL

ACTIVIDADES

OBSERVACIONES

1ra. 2da. 3ra. 4ta. 5ta. 6ta. 7ma. 8va. 9na. 10ma. 11ra. 12da. 13ra. 14ta. 15ta. 16ta. 17ma. 18va. 19na. 20va. 21ra.

09-Mar 14-Mar 21-Mar 28-Mar 04-Abr 11-Abr 18-Abr 25-Abr 02-May 09-May 16-May 23-May 30-May 06-Jun 13-Jun 20-Jun 27-Jun 04-Jul 11-Jul 18-Jul 25-Jul

12-Mar 19-Mar 26-Mar 02-Abr 09-Abr 16-Abr 23-Abr 30-Abr 07-May 14-May 21-May 28-May 04-Jun 11-Jun 18-Jun 25-Jun 02-Jul 09-Jul 16-Jul 23-Jul 26-Jul

Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia Avance de materia

FUNDAMENTOS DE BASES DE DATOS FUNDAMENTOS DE BASES DE DATOS MODELO ENTIDAD RELACION MODELO ENTIDAD RELACION MODELO RELACIONAL
Inicio Primera Evaluacin Parcial Conclusin Primera Evaluacin Parcial

Presentacin de Notas Presentacin de Notas

MODELO RELACIONAL NORMALIZACION NORMALIZACION LENGUAJE DE CONSULTAS SQL

Presentacin de Notas Presentacin de Notas

LENGUAJE DE CONSULTAS SQL LENGUAJE DE CONSULTAS SQL SISTEMAS DE BASE DE DATOS SISTEMAS DE BASE DE DATOS
Inicio Evaluacin Final
Conclusin Evaluacin Final Evaluacin del segundo turno Cierre de Gestin

Presentacin de Notas Transcripcin de Notas Transcripcin de Notas

N I V E R S

I D A

D E 7

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

WORK PAPER # 1

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO : APRO 07 No. DE HOJAS : 5

ELABOR : Ing. Alejandro Guzmn Molina TTULO DEL WORK PAPER : FUNDAMENTOS DE BASES DE DATOS DPTO.: Facultad de Ingeniera DESTINADO A: DOCENTES ALUMNOS X ADMINIST.

CDIGO : CMP 228

OTROS

OBSERVACIONES: Carrera : Ingeniera de Sistemas, Asignatura: BASES DE DATOS, Tema 1

FECHA DE DIFUSIN : Marzo 2011

FECHA DE ENTREGA : Marzo 2011

N I V E R S

I D A

D E 8

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

FUNDAMENTOS DE BASES DE DATOS 1.1. Definicin de Bases de Datos. 1.1.1. Dato El dato (del latn datum), es una representacin simblica (numrica, alfabtica, etc.), atributo o caracterstica de una entidad. El dato no tiene valor semntico (sentido) en s mismo, pero convenientemente tratado (procesado) se puede utilizar en la realizacin de clculos o toma de decisiones. Es de empleo muy comn en el mbito informtico. Un dato por s mismo no constituye informacin, es el procesado de los datos lo que nos proporciona informacin 1.1.2. Informacin En sentido general, la informacin es un conjunto organizado de datos, que constituyen un mensaje sobre un determinado ente o fenmeno. Existe una relacin indisoluble entre los datos, la informacin, el conocimiento, el pensamiento y el lenguaje, por lo que una mejor comprensin de los conceptos sobre informacin redundar en un aumento del conocimiento, ampliando as las posibilidades del pensamiento humano, que tambin emplea el lenguaje -oral, escrito, gesticular, etc.-, y un sistema de seales y smbolos interrelacionados. 1.1.3. Tablas y Vistas Tabla Tabla en las bases de datos, se refiere al tipo de modelamiento de datos, donde se guardan los datos recolectados por un programa. Su estructura general se asemeja a la vista general de un programa de Hoja de clculo. Las tablas se componen de dos estructuras:

Campo: Corresponde al nombre de la columna. Debe ser nico y adems de tener un tipo de dato asociado. Registro: Corresponde a cada fila que compone la tabla. All se componen los datos y los registros. Eventualmente pueden ser nulos en su almacenamientos.

En la definicin de cada campo, debe existir un nombre nico, con su tipo de dato correspondiente. Esto es til a la hora de manejar varios campos en la tabla, ya que cada nombre de campo debe ser distinto entre s. A los campos se les puede asignar, adems, propiedades especiales que afectan a los registros insertados. El campo puede ser definido como ndice o autoincrementable, lo cual permite que los datos de ese campo cambien solos o sean el principal indicar a la hora de ordenar los datos contenidos. Cada tabla creada debe tener un nombre nico en la cada Base de Datos, hacindola accesible mediante su nombre o su sinnimo
U N I V E R S I D A D D E 9 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

(dependiendo del tipo de base de datos elegida). La estructura de las tablas viene dado por la forma de un archivo plano, los cuales en un inicio se componan de un modo similar. Vistas Una vista de base de datos es un resultado de una consulta SQL de una o varias tablas; tambin se le puede considerar una tabla virtual. Las vistas tienen la misma estructura que una tabla: filas y columnas. La nica diferencia es que slo se almacena de ellas la definicin, no los datos. Los datos que se recuperan mediante una consulta a una vista se presentarn igual que los de una tabla. De hecho, si no se sabe que se est trabajando con una vista, nada hace suponer que es as. Al igual que sucede con una tabla, se pueden insertar, actualizar, borrar y seleccionar datos en una vista. Aunque siempre es posible seleccionar datos de una vista, en algunas condiciones existen restricciones para realizar el resto de las operaciones sobre vistas. Una vista se especifica a travs de una expresin de consulta (una sentencia SELECT) que la calcula y que puede realizarse sobre una o ms tablas. Sobre un conjunto de tablas relacionales se puede trabajar con un nmero cualquiera de vistas. La mayora de los DBMS soportan la creacin y manipulacin de vistas. 1.1.4. Bases de Datos y Sistemas de gestin de Bases de Datos Base de datos Una base de datos o banco de datos es un conjunto de datos que pertenecen al mismo contexto almacenados sistemticamente para su posterior uso. Sistemas de gestin de Bases de Datos En informtica existen los sistemas gestores de bases de datos (SGBD), que permiten almacenar y posteriormente acceder a los datos de forma rpida y estructurada. Los Sistemas de gestin de base de datos son un tipo de software muy especfico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Se compone de un lenguaje de definicin de datos, de un lenguaje de manipulacin de datos y de un lenguaje de consulta. En los textos que tratan este tema, o temas relacionados, se mencionan los trminos SGBD y DBMS, siendo ambos equivalentes, y acrnimos, respectivamente, de Sistema Gestor de Bases de Datos y DataBase Management System, su expresin inglesa. 1.1.5. Esquema de Bases de Datos. Es la descripcin lgica de la base de datos, proporciona los nombres de las entidades y sus atributos especificando las relaciones que existen entre ellos. Es un banco en el que se inscriben los valores que irn formando cada uno de los atributos.
U N I V E R S I D A D D E 10 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

El esquema no cambia los que varan son los datos y con esto tenemos una nueva instancia. Se llama instancia al estado que presenta una base de datos en un tiempo dado. Vemoslo como una fotografa que tomamos de la base de datos en un tiempo t, despus de que transcurre el tiempo t la base de datos ya no es la misma. Ejemplo: Esquema: { Vendedor : Nombre, Puesto, Salario } Instancia: Juan Gmez 1.2. Abstraccin de la informacin Los SGBD ahorran a los usuarios detalles acerca del almacenamiento fsico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. As, se definen varios niveles de abstraccin o capas. Obrero 850

1.2.1. Nivel Fsico Es la representacin del nivel ms bajo de abstraccin, en ste se describe en detalle la forma en como de almacenan los datos en los dispositivos de almacenamiento (por ejemplo, mediante sealadores o ndices para el acceso aleatorio a los datos) Es el nivel real de los datos almacenados. Es decir como se almacenan los datos, ya sea en registros, o como sea. Este nivel es usado por muy pocas personas que deben estar cualificadas para ello. Este nivel lleva asociada una representacin de los
U N I V E R S I D A D D E 11 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

datos, que es lo que denominamos Esquema Fsico. 1.2.2. Nivel Conceptual. El siguiente nivel un poco ms alto de abstraccin, describe que datos son almacenados realmente en la base de datos y las relaciones que existen entre los mismos, describe la base de datos completa en trminos de su estructura de diseo. El nivel conceptual de abstraccin lo usan los administradores de bases de datos, quienes deben decidir qu informacin se va a guardar en la base de datos. Es el correspondiente a una visin de la base de datos desde el punto de visto del mundo real. Es decir tratamos con la entidad u objeto representado, sin importarnos como est representado o almacenado. Este nivel lleva asociado el Esquema Conceptual. 1.2.3. Nivel de Visin. Nivel ms alto de abstraccin, es lo que el usuario final puede visualizar del sistema terminado, describe slo una parte de la base de datos al usuario acreditado para verla. El sistema puede proporcionar muchas visiones para la misma base de datos. Son partes del esquema conceptual. El nivel conceptual presenta toda la base de datos, mientras que los usuarios por lo general slo tienen acceso a pequeas parcelas de sta. El nivel visin es el encargado de dividir estas parcelas. Un ejemplo sera el caso del empleado que no tiene porqu tener acceso al sueldo de sus compaeros o de sus superiores. El esquema asociado a ste nivel es el Esquema de Visin. Los 3 niveles vistos, componen lo que conocemos como arquitectura de base de datos a 3 niveles. A menudo el nivel fsico no es facilitado por muchos DBMS, esto es, no permiten al usuario elegir como se almacenan sus datos y vienen con una forma estndar de almacenamiento y manipulacin de los datos. 1.3. Modelos de Datos. 1.3.1. Modelo. Se utiliza para representar el mundo real a travs de esquemas conceptuales. El proceso de representar una base de datos y sus respectivas tablas, a travs de modelos, se llama modelizacin. 1.3.2. Tipos de Modelos de Datos. 1.3.2.1. Modelos lgicos basados en objetos Son aquellos que nos permiten una definicin clara y concisa de los esquemas conceptuales y de visin. Su caracterstica principal es que permiten definir en forma detallada las limitantes de los datos. Modelo Entidad Relacin. Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de entidades, que son objetos que existen y que se distinguen de otros por sus caractersticas, por ejemplo: un alumno se distingue de otro por sus caractersticas particulares como lo es el nombre, o el numero de control asignado al entrar a una institucin educativa, as mismo, un empleado, una materia, etc.
U N I V E R S I D A D D E 12 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

1.3.2.2.

Modelos lgicos Basados en registros

Operan sobre niveles conceptual y de visin. Sus caractersticas principales son que permiten una descripcin ms amplia de la implantacin, pero no son capaces de especificar con claridad las limitantes de los datos. Modelo Relacional. Representa al mundo real mediante tablas relacionadas entre s por columnas comunes. Ex.: Num_empleado 33 34 1.3.2.3. Nombre Seccin Pepe Juan 25 25

Modelos Fsicos de Datos

Describen los datos en el nivel ms bajo y permiten identificar algunos detalles de implantacin para el manejo del hardware de almacenamiento. 1.4. Lenguaje de Bases de Datos. 1.4.1. Lenguaje de Definicin de Datos Un lenguaje de definicin de datos (DDL, Data Definition Language) es un lenguaje proporcionado por el sistema de gestin de base de datos que permite a los usuarios de la misma llevar a cabo las tareas de definicin de las estructuras que almacenarn los datos as como de los procedimientos o funciones que permitan consultarlos. El lenguaje de programacin SQL, el ms difundido entre los gestores de bases de datos, admite las siguientes sentencias de definicin: CREATE, DROP y ALTER, cada una de las cuales se puede aplicar a las tablas, vistas, procedimientos almacenados y triggers de la base de datos. Otras que se incluyen dentro del DDL, pero que su existencia depende de la implementacin del estndar SQL que lleve a cabo el gestor de base de datos son GRANT y REVOKE, los cuales sirven para otorgar permisos o quitarlos, ya sea a usuarios especficos o a un rol creado dentro de la base de datos. 1.4.2. Lenguaje de Manipulacin de Datos La manipulacin de datos se refiere a las operaciones de insertar, recuperar, eliminar o modificar datos; dichas operaciones son realizadas a travs del lenguaje de manipulacin de datos (DML, Data Manipulation Language), que es quin permite el acceso de los usuarios a los datos. Existen bsicamente 2 tipos de lenguajes de manipulacin de datos:

Procedimentales: Los LMD requieren que el usuario especifique que datos se necesitan y cmo obtenerlos.
N I V E R S I D A D D E 13 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

No procedimentales: Los LMD requieren que el usuario especifique que datos se necesitan y sin especificar cmo obtenerlos.

1.5. Sistema Manejador de Bases de Datos. 1.5.1. Manejador de Bases de Datos El sistema manejador de bases de datos es la porcin ms importante del software de un sistema de base de datos. Un DBMS es una coleccin de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de alguna tarea especfica. Las funciones principales de un DBMS son: Crear y organizar la Base de datos. Establecer y mantener las trayectorias de acceso a la base de datos de tal forma que los datos puedan ser accesados rpidamente. Manejar los datos de acuerdo a las peticiones de los usuarios. Registrar el uso de las bases de datos. Interaccin con el manejador de archivos.

Esto a travs de las sentencias en DML al comando del sistema de archivos. As el Manejador de base de datos es el responsable del verdadero almacenamiento de los datos. a) Respaldo y recuperacin. Consiste en contar con mecanismos implantados que permitan la recuperacin fcilmente de los datos en caso de ocurrir fallas en el sistema de base de datos. b) Control de concurrencia. Consiste en controlar la interaccin entre los usuarios concurrentes para no afectar la inconsistencia de los datos. c) Seguridad e integridad. Consiste en contar con mecanismos que permitan el control de la consistencia de los datos evitando que estos se vean perjudicados por cambios no autorizados o previstos. El DBMS es conocido tambin como Gestor de Base de datos. 1.5.2. Administrador de Bases de Datos Un RDBMS es un Sistema Administrador de Bases de Datos Relacionales. RDBMS viene del acrnimo en ingls Relational Data Base Management System. Los RDBMS proporcionan el ambiente adecuado para gestionar una base de datos. 1.5.3. Sistema de Base de datos Un sistema de base de datos se encuentra dividido en mdulos cada uno de
U N I V E R S I D A D D E 14 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

los cuales controla una parte de la responsabilidad total de sistema. En la mayora de los casos, el sistema operativo proporciona nicamente los servicios ms bsicos y el sistema de la base de datos debe partir de esa base y controlar adems el manejo correcto de los datos. As el diseo de un sistema de base de datos debe incluir la interfaz entre el sistema de base de datos y el sistema operativo. Los componentes funcionales de un sistema de base de datos, son: Gestor de archivos. Gestiona la asignacin de espacio en la memoria del disco y de las estructuras de datos usadas para representar informacin. Manejador de base de datos. Sirve de interfaz entre los datos y los programas de aplicacin. Procesador de consultas. Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Adems convierte la solicitud del usuario en una forma ms eficiente. Compilador de DDL. Convierte las proposiciones DDL en un conjunto de tablas que contienen metadatos, estas se almacenan en el diccionario de datos. Archivo de datos. En l se encuentran almacenados fsicamente los datos de una organizacin. Diccionario de datos. Contiene la informacin referente a la estructura de la base de datos. ndices. Permiten un rpido acceso a registros que contienen valores especficos. 1.5.4. Usuarios de las bases de Datos Podemos definir a los usuarios como toda persona que tenga todo tipo de contacto con el sistema de base de datos desde que este se disea, elabora, termina y se usa. Los usuarios que accesan una base de datos pueden clasificarse como: Programadores de aplicaciones. Los profesionales en computacin que interactan con el sistema por medio de llamadas en DML (Lenguaje de Manipulacin de Datos), las cuales estn incorporadas en un programa escrito en un lenguaje de programacin (Por ejemplo, COBOL, PL/I, Pascal, C, etc.) Usuarios sofisticados Los usuarios sofisticados interactan con el sistema sin escribir programas. En cambio escriben sus preguntas en un lenguaje de consultas de base de datos. Usuarios especializados Algunos usuarios sofisticados escriben aplicaciones de base de datos especializadas que no encajan en el marco tradicional de procesamiento de
U N I V E R S I D A D D E 15 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

datos. Usuarios ingenuos Los usuarios no sofisticados interactan con el sistema invocando a uno de los programas de aplicacin permanentes que se han escrito anteriormente en el sistema de base de datos, podemos mencionar al usuario ingenuo como el usuario final que utiliza el sistema de base de datos sin saber nada del diseo interno del mismo por ejemplo: un cajero.

N I V E R S

I D A

D E 16

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

WORK PAPER # 2

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO : APRO 07 No. DE HOJAS : 5

ELABOR : Ing. Alejandro Guzmn Molina TTULO DEL WORK PAPER : MODELO ENTIDAD RELACIN DPTO.: Facultad de Ciencias y Tecnologa UDABOL ORURO DESTINADO A: DOCENTES ALUMNOS X ADMINIST.

CDIGO : CMP 228

OTROS

OBSERVACIONES: Carrera : Ingeniera de Sistemas, Asignatura : BASES DE DATOS, Tema 2

FECHA DE DIFUSIN : Marzo 2011

FECHA DE ENTREGA : Abril 2011

MODELO ENTIDAD - RELACIN MODELO ENTIDAD - RELACIN 6.5. Concepto. Los diagramas o modelos entidad-relacin (a veces denominado por su siglas, E-R "Entity relationship") son una herramienta para el modelado de datos de un sistema de informacin. Estos modelos expresan entidades relevantes para un sistema de informacin, sus inter-relaciones y propiedades.

N I V E R S

I D A

D E 17

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

El modelado entidad-relacin es una tcnica para el modelado de datos utilizando diagramas entidad relacin. No es la nica tcnica pero s la ms utilizada. Brevemente consiste en los siguientes pasos: 1. Se parte de una descripcin textual del problema o sistema de informacin a automatizar (los requisitos). 2. Se hace una lista de los sustantivos y verbos que aparecen. 3. Los sustantivos son posibles entidades o atributos. 4. Los verbos son posibles relaciones. 5. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. 6. Se elabora el diagrama (o diagramas) entidad-relacin. 7. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. 6.6. Entidades y conjunto de entidades. Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus caractersticas llamadas atributos. Las entidades pueden ser concretas como una persona o abstractas como una fecha. Un conjunto de entidades es un grupo de entidades del mismo tipo. Por ejemplo el conjunto de entidades CUENTA, podra representar al conjunto de cuentas de un banco X, o ALUMNO representa a un conjunto de entidades de todos los alumnos que existen en una institucin. Una entidad se caracteriza y distingue de otra por los atributos, en ocasiones llamadas propiedades, que representan las caractersticas de una entidad. Los atributos de una entidad pueden tomar un conjunto de valores permitidos al que se le conoce como dominio del atributo. As cada entidad se describe por medio de un conjunto de parejas formadas por el atributo y el valor de dato. Habr una pareja para cada atributo del conjunto de entidades. Ejemplo: Hacer una descripcin en pareja para la entidad alumno con los atributos No_control, Nombre y Especialidad. Nombre_atributo No_control Nombre Esp Nombre_atributo RFC Nombre Salario Valor 96310418 Snchez Osuna Ana LI Valor COMD741101YHR Daniel Coln Morales 3000

O considerando el ejemplo del Vendedor cuyos atributos son: RFC, Nombre, Salario.

6.7. Conjuntos de relaciones

FACULTAD DE CIENCIAS Y TECNOLOGA

Una relacin es la asociacin que existe entre dos a ms entidades. Un conjunto de relaciones es un grupo de relaciones del mismo tipo. La cantidad de entidades en una relacin determina el grado de la relacin, por ejemplo la relacin ALUMNO-MATERIA es de grado 2, ya que intervienen la entidad ALUMNO y la entidad MATERIA, la relacin PADRES, puede ser de grado 3, ya que involucra las entidades PADRE, MADRE e HIJO. Aunque el modelo E-R permite relaciones de cualquier grado, la mayora de las aplicaciones del modelo slo consideran relaciones del grado 2. Cuando son de tal tipo, se denominan relaciones binarias. La funcin que tiene una relacin se llama papel, generalmente no se especifican los papeles o roles, a menos que se quiera aclarar el significado de una relacin. Diagrama E-R (sin considerar los atributos, slo las entidades) para los modelos ejemplificados: 6.8. Limitantes de Mapeo Existen 4 tipos de relaciones que pueden establecerse entre entidades, las cuales establecen con cuantas entidades de tipo B se pueden relacionar una entidad de tipo A: Tipos de relaciones: Relacin uno a uno. Se presenta cuando existe una relacin como su nombre lo indica uno a uno, denominado tambin relacin de matrimonio. Una entidad del tipo A solo se puede relacionar con una entidad del tipo B, y viceversa; Relacin uno a muchos. Significa que una entidad del tipo A puede relacionarse con cualquier cantidad de entidades del tipo B, y una entidad del tipo B solo puede estar relacionada con una entidad del tipo A. Muchos a uno. Indica que una entidad del tipo B puede relacionarse con cualquier cantidad de entidades del tipo A, mientras que cada entidad del tipo A solo puede relacionarse con solo una entidad del tipo B. Muchas a muchas. Establece que cualquier cantidad de entidades del tipo A pueden estar relacionados con cualquier cantidad de entidades del tipo B. A los tipos de relaciones antes descritos, tambin se le conoce como cardinalidad. La cardinalidad nos especifica los tipos de relaciones que existen entre las entidades en el modelo E-R y establecer con esto las validaciones necesarias para conseguir que los datos de la instancia (valor nico en un momento dado de una base de datos) correspondan con la realidad. Algunos ejemplos de cardinalidades de la vida comn pueden ser: Uno a uno.

N I V E R S

I D A

D E 19

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

El noviazgo, el RFC de cada persona, El CURP personal, El acta de nacimiento, ya que solo existe un solo documento de este tipo para cada una de las diferentes personas. Uno a muchos. Cliente Cuenta en un banco, Padre-Hijos, Camin-Pasajeros, zoolgicoanimales, rbol hojas. Muchos a muchos. Arquitecto proyectos, fiesta personas, estudiante materias. Cabe mencionar que la cardinalidad para cada conjunto de entidades depende del punto de vista que se le de al modelo en estudio, claro esta, sujetndose a la realidad. Otra clase de limitantes lo constituye la dependencia de existencia. Refirindonos a las mismas entidades A y B, decimos que si la entidad A depende de la existencia de la entidad B, entonces A es dependiente de existencia por B, si eliminamos a B tendramos que eliminar por consecuente la entidad A, en este caso B es la entidad Dominante y A es la entidad subordinada. 6.9. Llave primaria Como ya se ha mencionado anteriormente, la distincin de una entidad entre otra se debe a sus atributos, lo cual lo hacen nico. Una llave primaria es aquel atributo el cual consideramos clave para la identificacin de los dems atributos que describen a la entidad. Por ejemplo, si consideramos la entidad ALUMNO del Instituto Tecnolgico de La Paz, podramos tener los siguientes atributos: Nombre, Semestre, Especialidad, Direccin, Telfono, Nmero de control, de todos estos atributos el que podremos designar como llave primaria es el nmero de control, ya que es diferente para cada alumno y este nos identifica en la institucin. Claro que puede haber ms de un atributo que pueda identificarse como llave primaria en este caso se selecciona la que consideremos ms importante, los dems atributos son denominados llaves secundarias. Una clave o llave primaria es indicada grficamente en el modelo E-R con una lnea debajo del nombre del atributo. 6.10. Diagrama Entidad - Relacin Los diagramas E-R son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen la informacin que trata un sistema de informacin y el software que lo automatiza. Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de un esquema grfico empleando los terminologa de entidades, que son objetos que existen y son los elementos principales que se identifican en el problema a resolver con el diagramado y se distinguen de otros por sus caractersticas particulares denominadas atributos, el enlace que rige la unin de las entidades esta representada por la relacin del modelo.
U N I V E R S I D A D D E 20 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Recordemos que un rectngulo nos representa a las entidades; una elipse a los atributos de las entidades, y una etiqueta dentro de un rombo nos indica la relacin que existe entre las entidades, destacando con lneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que se encuentra subrayado. Para su representacin grfica se utilizan los siguientes smbolos:

Descripcin de sus elementos Entidades Una entidad es cualquier "objeto" discreto sobre el que se tiene informacin. Se representa mediante un rectngulo o "caja" etiquetada en su interior mediante un nombre. Ejemplos de entidades habituales en los sistemas de informacin son: factura, persona, empleado, etc. Cada ejemplar de una entidad se denomina instancia.Por ejemplo,"carlos ch y doris ar" pueden ser dos instancias distintas de la entidad "persona". Las instancias no se representan en el diagrama. No obstante, se pueden documentar aparte porque son tiles para inicializar la base de datos resultante. Por ejemplo, los departamentos existentes de una empresa pueden ser relevantes como datos iniciales de la entidad "departamento". Relaciones Una relacin describe cierta interdependencia (de cualquier tipo) entre entidades. Se representa mediante un rombo etiquetado en su interior mediante un verbo. Adems, dicho rombo debe unirse mediante lneas con las entidades que relaciona (es decir, los rectngulos). Una relacin no tiene sentido sin las entidades que relaciona. Por ejemplo: una persona (entidad) trabaja (relacin) para un departamento (entidad). Atributos Los atributos son propiedades relevantes propias de una entidad y/o relacin. Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.
U N I V E R S I D A D D E 21 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relacin, sino que se describen textualmente en otros documentos adjuntos. Los atributos describen informacin til sobre las entidades. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un empleado de otro es su nmero de la Seguridad Social. Ejemplos de atributos de la entidad "persona":

Documento Nacional de Identidad (identificativo). Nombre. Apellidos. Direccin. Cdigo postal.

Diagramas extendidos DER extendido Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje: Entidades fuertes y dbiles Cuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin, es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que, esta ultima, se pueda identificar. Las entidades dbiles se representan mediante un doble rectngulo, es decir, un rectngulo con doble lnea. Cardinalidad de las relaciones Las relaciones, en principio binarias, pueden involucrar a un nmero distinto de instancias de cada entidad. As, son posibles tres tipos de cardinalidades:

Relaciones de uno a uno: una instancia de la entidad A se relaciona con una y solamente una de la entidad B. Relaciones de uno a muchos: cada instancia de la entidad A se relaciona con varias instancias de la entidad B. Relaciones de muchos a muchos: cualquier instancia de la entidad A se relaciona con cualquier instancia de la entidad B.

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de

N I V E R S

I D A

D E 22

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin:

"0" si la entidad no est obligada a participar en la relacin. "1" si la entidad est obligada a participar en la relacin y, adems, cada instancia solamente participa una vez. "N" , "M", "*" si la entidad no est obligada a participar en la relacin y cada instancia puede participar cualquier nmero de veces. Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios artculos (entidad) y un artculo puede ser comprado por varios clientes distintos. Es una relacin N:M.

Ejemplos de relaciones que expresan cardinalidad:

Atributos en relaciones Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite". Herencia La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo. 6.11. Generalizacin, Especializacin y Agregacin

Generalizacin Es el resultado de la unin de 2 o ms conjuntos de entidades (de bajo nivel) para producir un conjunto de entidades de ms alto nivel. La generalizacin se usa para hacer resaltar los parecidos entre tipos de entidades de nivel ms bajo y ocultar sus diferencias. La generalizacin consiste en identificar todos aquellos atributos iguales de un conjunto de entidades para formar una entidad(es) global(es) con dichos atributos semejantes, dicha entidad(es) global(es) quedara a un nivel ms alto al de las entidades origen. Especializacin Es el resultado de tomar un subconjunto de entidades de alto nivel para formar un conjunto de entidades de ms bajo nivel.
U N I V E R S I D A D D E 23 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

En la generalizacin cada entidad de alto nivel debe ser tambin una entidad de bajo nivel. La especializacin no tiene este limitante. Se representa por medio de un tringulo denominado con la etiqueta "ISA", se distingue de la generalizacin por el grosor de las lneas que conectan al tringulo con las entidades. La especializacin denota la diferencia entre los conjuntos de entidades de alto y bajo nivel.

Agregacin La agregacin surge de la limitacin que existe en el modelado de E-R, al no permitir expresar las relaciones entre relaciones de un modelo E-R en el caso de que una relacin X se quiera unir con una entidad cualquiera para formar otra relacin. La Generalizacin consiste en agrupar por medio de un rectngulo a la relacin (representada por un rombo) junto con las entidades y atributos involucrados en ella, para formar un grupo que es considerado una entidad y ahora s podemos relacionarla con otra entidad.

N I V E R S

I D A

D E 24

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

WORK PAPER # 3

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO : APRO 07 No. DE HOJAS : 5

ELABOR : Ing. Alejandro Guzmn Molina TTULO DEL WORK PAPER : MODELO RELACIONAL DPTO.: Facultad de Ciencias y Tecnologa UDABOL ORURO DESTINADO A: DOCENTES ALUMNOS X ADMINIST.

CDIGO : CMP 228

OTROS

OBSERVACIONES: Carrera : Ingeniera de Sistemas, Asignatura : BASES DE DATOS, Tema 2

FECHA DE DIFUSIN : Abril 2011

FECHA DE ENTREGA : Abril 2011

MODELO RELACIONAL Modelo relacional El modelo relacional para la gestin de una base de datos es un modelo de datos basado en la lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos

N I V E R S

I D A

D E 25

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

(California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como si fuese una tabla que est compuesta por registros (cada fila de la tabla sera un registro o tupla), y columnas (tambin llamadas campos). Descripcin En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que estos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin. Este modelo considera la base de datos como una coleccin de relaciones. De manera simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver. El lenguaje ms comn para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estndar implementado por los principales motores o sistemas de gestin de bases de datos relacionales. Esquema Un esquema es la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y que tipo de informacin podr ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relacin. Todo esquema constar de:

Nombre de la relacin (su identificador). Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

Instancias Una instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos. En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento dado, pero tambin es valido referirnos a una instancia cuando trabajamos o mostramos nicamente un subconjunto de la informacin contenida en una relacin o tabla, como por ejemplo:

Ciertos caracteres y nmeros (una sola columna de una sola fila).

FACULTAD DE CIENCIAS Y TECNOLOGA

Algunas o todas las filas con todas o algunas columnas

Cada fila es una tupla. El nmero de filas es llamado cardinalidad. El nmero de columnas es llamado aridad o grado. Base de datos relacional

Una base de datos relacional es un conjunto de una o ms tablas estructuradas en registros (lneas) y campos (columnas), que se vinculan entre s por un campo en comn, en ambos casos posee las mismas caractersticas como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el trmino se refiere a una coleccin especfica de datos pero a menudo se le usa, en forma errnea como sinnimo del software usado para gestionar esa coleccin de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del ingls relational database management system). Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera ptima. Entre las ventajas de este modelo estn: 1. Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves. 2. Garantiza la integridad referencial: As al eliminar un registro elimina todos los registros relacionados dependientes. 3. Favorece la normalizacin por ser ms comprensible y aplicable.

N I V E R S

I D A

D E 27

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

WORK PAPER # 4

PROGRAMA DE CONTROL DE CALIDAD No. DE PROCEDIMIENTO : APRO 07 No. DE HOJAS : 5

ELABOR : Ing. Alejandro Guzmn Molina TTULO DEL WORK PAPER : LENGUAJE SQL DPTO.: Facultad de Ciencias y Tecnologa UDABOL ORURO DESTINADO A: DOCENTES ALUMNOS X ADMINIST.

CDIGO : CMP 228

OTROS

OBSERVACIONES: Carrera : Ingeniera de Sistemas, Asignatura : BASES DE DATOS, Tema 2

FECHA DE DIFUSIN : Mayo 2011

FECHA DE ENTREGA : Mayo 2011

INTRODUCCION AL SQL En vista del auge que toma cada vez la tecnologa, es preciso saber hacer de todo lo relacionado son software, pero no podemos olvidar que tambin existe la parte de cmo manejar datos e informacin. Para ello existe afortunadamente formas o maneras de cmo poder guarda informacin necesaria y de vital importancia para nuestras empresas o compaas. Es por tal motivo, es preciso conocer hacer muy de fondo las diferentes plataformas o manejadores de bases de datos para poder optar por la msadecuada para ser implanta, si es necesario, en nuestras compaas o empresas,como lo son SQL, ORACLE y INFORMIX.
U N I V E R S I D A D D E 28 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Informix es uno de los cuatro grandes de las bases de datos junto DB2 de IBM, SQL Server de Microsoft y Oracle. Aunque en muchos aspectos es mejor que Oracle, no se ha sabido mover en el terreno del marketing. Oracle captur la mayor parte del mercado y Informix no se recuper de las perdidas econmicas. DB2 y SQL Server tenan grandes compaas detrs con otros negocios que les permiti aguantar la poltica agresiva deOracle. Recientemente IBM adquiri Informix con lo que el mercado de las bases de datos comerciales en UNIX (Linux) qued entre IBM y Oracle. Puedes encontrar una infinidad de informacin sobre Oracle sobre Linux en Internet, pero muy poca sobre Informix. La poca informacin es debido a la poca comunidad Internet que tiene Informix, al menos comparada con la de Oracle. Y es que, hoy en da, las documentaciones oficiales, de tan sencillas que quierenser, cada vez son ms confusas e incompletas. Sin duda, el mejor soporte tcnico que hay para un producto es su comunidad de usuarios en Internet. Informix por desgracia no ha sabido crearla. Una bsqueda de "oracle linux" enGoogle devuelve unas 972.000 pginas, mientras que "informix linux"143.000. SQL (Standar Query Lenguaje) es un lenguaje estandarizado de base de datos, el cual nos permite realizar tablas y obtener datos de ella de manera muy sencilla. Para exponer mas claramente los conceptos se realizaran ejemplo sobre relaciones que se crearan aqu para entender mejor como funciona SQL. Tambin se puede decir, SQL es un lenguaje bastante sencillo, principalmente orientado a bases de datos y, sobre todo, al manejo de consultas. Visual Basic incorpora esta extensin junto a nuestras bases de datos, obteniendo potentes resultados. De hecho, las consultas que se realizan en Access, estn desarrolladas o basadas en este lenguaje, por lo que su implementacin en Visual Basic no es complicada. El objetivo principal de SQL es la realizacin de consultas y clculos con los datos de una o varias tablas. Consejos Para Escribir Mandatos En SQL He aqu una serie de consejos (a veces normas), que hay que tener en cuenta a la hora de escribir mandatos SQL en nuestras aplicaciones en Visual Basic: 1. Un mandato en SQL se expresa en una cadena de caracteres o String. 2. Dicho mandato se puede escribir en la propiedad RecordSource de un control Data (ms adelante, podremos prescindir del control Data para realizar nuestras consultas), con el fin de crear una consulta en la interfaz. 3. Los nombres de los campos especificados (y de las tablas),que contengan ms de una palabra, han de encerrarse entre corchetes ([nombre]).Como norma general, se suelen escribir siempre entre corchetes. 4. Para especificar un determinado campo de una determinada tabla, se ha de escribir primero el nombre de la tabla, un punto y, a continuacin, el nombre del campo (nombre_tabla.nombre_campo). 5. Al especificar una expresin de bsqueda, si sta se refiere a unaexpresin de caracteres, stos han de encerrarse entre comillas simples('expresin_a_buscar'). 6. Para especificar una fecha en una bsqueda, sta debe encerrarse entre signos numeral (#fecha#) en Access, Dbase X, etc., y entre comillas simples ('fecha') para bases Sql Server, Informix, etc. 7. Si se utiliza la propiedad RecordSource del control Data, para crear nuestras consultas en SQL, tras introducir el mandato SQL (siempre como una expresin de cadena) es necesario refrescar el control Data(control_data.Refresh). Mandato Sql Estndar El lenguaje SQL est compuesto por una serie de sentencias y de clusulas muy reducidas en nmero, pero muy potentes en efectividad. De entre todas las palabras, existen cuatro que son las ms utilizadas, estando compuestas por una sentencia y por tres clusulas: SELECT lista_campos FROM lista_tablas [WHERE criterios [ORDER BY lista_campos]] Breve Historia de SQL La historia de SQL (que se pronuncia deletreando en ingls las letras que lo componen, es decir "ese-cu-ele" y no "siquel" como se oye a menudo) empieza en 1974 con la definicin, por parte de Donald Chamberlin y de otras personas que trabajaban en los laboratorios de investigacin de IBM, de un lenguaje para la especificacin de las caractersticas de las bases de datos que adoptaban el modelo relacional. Este lenguaje se llamaba SEQUEL
U N I V E R S I D A D D E 29 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

(Structured English Query Language) y se implement en un prototipo llamado SEQUEL-XRM entre 1974 y 1975. Las experimentaciones con ese prototipo condujeron, entre 1976 y 1977, a una revisin del lenguaje (SEQUEL/2), que a partir de ese momento cambi de nombre por motivos legales, convirtindose en SQL. El prototipo (System R), basado en este lenguaje, se adopt y utiliz internamente en IBM y lo adoptaron algunos de sus clientes elegidos. Gracias al xito de este sistema, que no estaba todava comercializado, tambin otras compaas empezaron a desarrollar sus productos relacionales basados en SQL. A partir de 1981, IBM comenz a entregar sus productos relacionales y en 1983 empez a vender DB2. En el curso de los aos ochenta, numerosas compaas (por ejemplo Oracle y Sybase, slo por citar algunos) comercializaron productos basados en SQL, que se convierte en el estndar industrial de hecho por lo que respecta a las bases de datos relacionales. En 1986, el ANSI adopt SQL (sustancialmente adopt el dialecto SQL de IBM)como estndar para los lenguajes relacionales y en 1987 se transfom en estndar ISO. Esta versin del estndar va con el nombre de SQL/86. En los aos siguientes, ste ha sufrido diversas revisiones que han conducido primero a la versin SQL/89 y, posteriormente, a la actual SQL/92. El hecho de tener un estndar definido por un lenguaje para bases de datos relacionales abre potencialmente el camino a la intercomunicabilidad entre todos los productos que se basan en l. Desde el punto de vista prctico, pordesgracia las cosas fueron de otro modo. Efectivamente, en general cada productor adopta e implementa en la propia base de datos slo el corazn dellenguaje SQL (el as llamado Entry level o al mximo el Intermediate level), extendindolo de manera individual segn la propia visin que cada cual tenga del mundo de las bases de datos.

Qu es SQL
Las aplicaciones en red son cada da ms numerosas y verstiles. En muchos casos, el esquema bsico de operacin es una serie de scripts que rigen el comportamiento de una base de datos. Debido a la diversidad de lenguajes y de bases de datos existentes, la manera de comunicar entre unos y otras sera realmente complicada a gestionar de no ser por la existencia de estndares que nos permiten el realizar las operaciones bsicas de una forma universal. Es de eso de lo que trata el Structured Query Language que no es mas que un lenguaje estndar de comunicacin con bases de datos. Hablamos por tanto de un lenguaje normalizado que nos permite trabajar con cualquier tipo de lenguaje (ASP o PHP) en combinacin con cualquier tipo de base de datos (MS Access, SQL Server, MySQL...). El hecho de que sea estndar no quiere decir que sea idntico para cada base de datos. En efecto, determinadas bases de datos implementan funciones especficas que no tienen necesariamente que funcionar en otras. Aparte de esta universalidad, el SQL posee otras dos caractersticas muy apreciadas. Por una parte, presenta una potencia y versatilidad notables que contrasta, por otra, con su accesibilidad de aprendizaje. El manual de SQL de desarroioweb pretende dar a conocer las operaciones bsicas que se pueden realizar con SQL y que tienen una aplicacin directa con la creacin de aplicaciones en red sin profundizar ms de lo estrictamente necesario. Buscamos con ello ofrecer al webmaster un manual de referencia prctico y aplicado.

Tipos de campo

Como sabemos una base de datos esta compuesta de tablas donde almacenamos registros catalogados en funcin de distintos campos (caractersticas). Un aspecto previo a considerar es la naturaleza de los valores que introducimos en esos campos. Dado que una base de datos trabaja con todo tipo de informaciones, es importante especificarle qu tipo de valor le estamos introduciendo de manera a, por un lado, facilitar la bsqueda posteriormente y por otro, optimizar los recursos de memoria. Cada base de datos introduce tipos de valores de campo que no necesariamente estn presentes en otras. Sin embargo, existe un conjunto de tipos que estn representados en la totalidad de estas bases. Estos tipos comunes son los siguientes: Alfanumricos Contienen cifras y letras. Presentan una longitud limitada (255 caracteres)

N I V E R S

I D A

D E 30

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Numricos Booleanos Fechas

Existen de varios tipos, principalmente, enteros (sin decimales) y reales (con decimales). Poseen dos formas: Verdadero y falso (S o No) Almacenan fechas facilitando posteriormente su explotacin. Almacenar fechas de esta forma posibilita ordenar los registros por fechas o calcular los das entre una fecha y otra... Son campos alfanumricos de longitud ilimitada. Presentan el inconveniente de no poder ser indexados (veremos ms adelante lo que esto quiere decir). Son campos numricos enteros que incrementan en una unidad su valor para cada registro incorporado. Su utilidad resulta ms que evidente: Servir de identificador ya que resultan exclusivos de un registro.

Memos

Autoincrementables

Nota: Si deseamos practicar con una base de datos que est vaca primero debemos crear las tablas que vamos a llenar. Las tablas tambin se crean con sentencias SQL y aprendemos a hacerlo en el ltimo captulo. Aunque, de todos modos, puede que sea ms cmodo utilizar un programa con interfaz grfica, como Access, que nos puede servir para crear las tablas en bases de datos del propio Access o por ODBC a otras bases de datos como SQL Server o MySQL por poner

Aadir un nuevo registro

Los registros pueden ser introducidos a partir de sentencias que emplean la instruccin Insert. La sintaxis utilizada es la siguiente: Insert Into nombre_tabla (nombre_campo1, nombre_campo2,...) Values (valor_campo1, valor_campo2...) Un ejemplo sencillo a partir de nuestra tabla modelo es la introduccin de un nuevo cliente lo cual se hara con una instruccin de este tipo: Insert Into clientes (nombre, apellidos, direccion, poblacion, codigopostal, email, pedidos) Values ('Perico', 'Palotes', 'Percebe n13', 'Lepe', '123456', '[email protected]', 33) Como puede verse, los campos no numricos o booleanos van delimitados por apostrofes: '. Tambin resulta interesante ver que el cdigo postal lo hemos guardado como un campo no numrico. Esto es debido a que en determinados paises (Inglaterra,como no) los codigos postales contienen tambin letras. Por supuesto, no es imprescindible rellenar todos los campos del registro. Eso s, puede ser que determinados campos sean necesarios. Estos campos necesarios pueden ser definidos cuando construimos nuestra tabla mediante la base de datos. Nota: Si no insertamos uno de los campos en la base de datos se inicializar con el valor por defecto que hayamos definido a la hora de crear la tabla. Si no hay valor por defecto, probablemente se inicialice como NULL (vaco), en caso de que este campo permita valores nulos. Si ese campo no permite valores nulos (eso se define tambin al crear la tabla) lo ms seguro es que la ejecucin de la sentenca SQL nos de un error. Resulta muy interesante, ya veremos ms adelante el por qu, el introducir durante la creacin de nuestra tabla un campo autoincrementable que nos permita asignar un nico nmero a cada uno de los registros. De este modo, nuestra tabla clientes presentara para cada registro un nmero exclusivo del cliente el cual nos ser muy util cuando consultemos varias tablas simultneamente. Para borrar un registro nos servimos de la instruccin Delete. En este caso debemos especificar cual o cuales son los registros que queremos borrar. Es por ello necesario establecer una seleccin que se llevara a cabo mediante la clusula Where. La forma de seleccionar se ver detalladamente en captulos posteriores. Por ahora nos contentaremos de mostrar cul es el tipo de sintaxis utilizado para efectuar estas supresiones: Delete From nombre_tabla Where condiciones_de_seleccin Nota: Si deseamos practicar con una base de datos que est vaca primero debemos crear las tablas que
U N I V E R S I D A D D E 31 A Q U I N O B O L I V I A

Borrar un registro

FACULTAD DE CIENCIAS Y TECNOLOGA

vamos a llenar. Las tablas tambin se crean con sentencias SQL y aprendemos a hacerlo en el ltimo captulo. Si queremos por ejemplo borrar todos los registros de los clientes que se llamen Perico lo haramos del siguiente modo: Delete From clientes Where nombre='Perico' Hay que tener cuidado con esta instruccin ya que si no especificamos una condicin con Where, lo que estamos haciendo es borrar toda la tabla: Delete From clientes

Actualizar un registro

Update es la instruccin que nos sirve para modificar nuestros registros. Como para el caso de Delete, necesitamos especificar por medio de Where cules son los registros en los que queremos hacer efectivas nuestras modificaciones. Adems, obviamente, tendremos que especificar cules son los nuevos valores de los campos que deseamos actualizar. La sintaxis es de este tipo: Update nombre_tabla Set nombre_campo1 = valor_campo1, nombre_campo2 = valor_campo2,... Where condiciones_de_seleccin Un ejemplo aplicado: Update clientes Set nombre='Jos' Where nombre='Pepe' Mediante esta sentencia cambiamos el nombre Pepe por el de Jos en todos los registros cuyo nombre sea Pepe. Aqu tambin hay que ser cuidadoso de no olvidarse de usar Where, de lo contrario, modificaramos todos los registros de nuestra tabla. La seleccin total o parcial de una tabla se lleva a cabo mediante la instruccin Select. En dicha seleccin hay que especificar: -Los campos que queremos seleccionar -La tabla en la que hacemos la seleccin En nuestra tabla modelo de clientes podramos hacer por ejemplo una seleccin del nombre y direccin de los clientes con una instruccin de este tipo: Select nombre, direccin From clientes Si quisisemos seleccionar todos los campos, es decir, toda la tabla, podramos utilizar el comodn * del siguiente modo: Select * From clientes Resulta tambin muy til el filtrar los registros mediante condiciones que vienen expresadas despus de la clusula Where. Si quisisemos mostrar los clientes de una determinada ciudad usaramos una expresin como esta: Select * From clientes Where poblacion Like 'Madrid' Adems, podramos ordenar los resultados en funcin de uno o varios de sus campos. Para este ultimo ejemplo los podramos ordenar por nombre as: Select * From clientes Where poblacion Like 'Madrid' Order By nombre Teniendo en cuenta que puede haber ms de un cliente con el mismo nombre, podramos dar un segundo criterio que podra ser el apellido: Select * From clientes Where poblacion Like 'Madrid' Order By nombre, apellido Si invirtisemos el orden nombre,apellido por apellido, nombre , el resultado sera distinto. Tendramos los clientes ordenados por apellido y aquellos que tuviesen apellidos idnticos se subclasificaran por el nombre. Es posible tambin clasificar por orden inverso. Si por ejemplo quisisemos ver nuestros clientes por orden de pedidos realizados teniendo a los mayores en primer lugar escribiramos algo as: Select * From clientes Order By pedidos Desc Una opcin interesante es la de efectuar selecciones sin coincidencia. Si por ejemplo buscsemos el saber en qu ciudades se encuentran nuestros clientes sin necesidad de que para ello aparezca varias veces la misma ciudad usaramos una sentencia de esta clase: Select Distinct poblacion From clientes Order By poblacion As evitaramos ver repetido Madrid tantas veces como clientes tengamos en esa poblacin.

Seleccin de tablas I

Seleccin de tablas II

Hemos querido compilar a modo de tabla ciertos operadores que pueden resultar tiles en determinados casos. Estos operadores sern utilizados despus de la clusula Where y pueden ser combinados hbilmente mediante parntesis para optimizar nuestra seleccin a muy altos niveles.

N I V E R S

I D A

D E 32

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Operadores matemticos: > < = <= <> = Mayor que Menor que Mayor o igual que Menor o igual que Distinto I g u a l

Operadores logicos Not, and, or, xor Otros operadores Like In y Not In Is Null y Is Not Null Between...And Distinct D e s c Selecciona los registros cuyo valor de campo se asemeje, no teniendo en cuenta maysculas y minsculas. Da un conjunto de valores para un campo para los cuales la condicin de seleccin es (o no) valida Selecciona aquellos registros donde el campo especificado esta (o no) vaco. Selecciona los registros comprendidos en un intervalo Selecciona los registros no coincidentes Clasifica los registros por orden inverso

Veamos a continuacin aplicaciones practicas de estos operadores. En esta sentencia seleccionamos todos los clientes de Madrid cuyo nombre no es Pepe. Como puede verse, empleamos Like en lugar de = simplemente para evitar inconvenientes debido al empleo o no de maysculas. Select * From clientes Where poblacion Like 'madrid' And Not nombre Like 'Pepe' Si quisiramos recoger en una seleccin a los clientes de nuestra tabla cuyo apellido comienza por A y cuyo nmero de pedidos esta comprendido entre 20 y 40: Select * From clientes Where apellidos like 'A%' And pedidos Between 20 And 40 El operador In, lo veremos ms adelante, es muy prctico para consultas en varias tablas. Para casos en una sola tabla es empleado del siguiente modo: Select * From clientes Where poblacion In ('Madrid','Barcelona','Valencia') De esta forma seleccionamos aquellos clientes que vivan en esas tres ciudades.

Seleccin de tablas III

Una base de datos puede ser considerada como un conjunto de tablas. Estas tablas en muchos casos estn relacionadas entre ellas y se complementan unas con otras. Refirindonos a nuestro clsico ejemplo de una base de datos para una aplicacin de e-comercio, la tabla clientes de la que hemos estado hablando puede estar perfectamente coordinada con una tabla donde almacenamos los pedidos realizados por cada cliente. Esta tabla de pedidos puede a su vez estar conectada con una tabla donde almacenamos los datos correspondientes a cada artculo del inventario. De este modo podramos fcilmente obtener informaciones contenidas en esas tres tablas como puede ser la designacin del artculo ms popular en una determinada regin donde la designacin del artculo sera obtenida de la tabla de artculos, la popularidad (cantidad de veces que ese artculo ha sido vendido) vendra de la tabla de pedidos y la regin
U N I V E R S I D A D D E 33 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

estara comprendida obviamente en la tabla clientes. Este tipo de organizacin basada en mltiples tablas conectadas nos permite trabajar con tablas mucho ms manejables a la vez que nos evita copiar el mismo campo en varios sitios ya que podemos acceder a l a partir de una simple llamada a la tabla que lo contiene. En este captulo veremos como, sirvindonos de lo aprendido hasta ahora, podemos realizar fcilmente selecciones sobre varias tablas. Definamos antes de nada las diferentes tablas y campos que vamos a utilizar en nuestros ejemplos: Tabla de clientes Nombre campo id_cliente nombre apellidos direccion poblacion codigopostal telefono email Tabla de pedidos Nombre campo id_pedido id_cliente id_articulo fecha cantidad Tipo campo Numrico entero Numrico entero Numrico entero Fecha Numrico entero Tabla de artculos Nombre campo id_articulo titulo autor editorial pre ci o Tipo campo Numrico entero Alfanumrico Alfanumrico Alfanumrico Numrico real Tipo campo Numrico entero Texto Texto Texto Texto Texto Numrico entero Texto

Estas tablas pueden ser utilizadas simultneamente para extraer informaciones de todo tipo. Supongamos que queremos
U N I V E R S I D A D D E 34 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

enviar un mailing a todos aquellos que hayan realizado un pedido ese mismo da. Podramos escribir algo as: Select clientes.apellidos, clientes.email From clientes,pedidos Where pedidos.fecha like '25/02/00' And pedidos.id_cliente= clientes.id_cliente Como puede verse esta vez, despus de la clusula From, introducimos el nombre de las dos tablas de donde sacamos las informaciones. Adems, el nombre de cada campo va precedido de la tabla de provenencia separados ambos por un punto. En los campos que poseen un nombre que solo aparece en una de las tablas, no es necesario especificar su origen aunque a la hora de leer la sentencia puede resultar ms claro el precisarlo. En este caso el campo fecha podra haber sido designado como "fecha" en lugar de "pedidos.fecha". Veamos otro ejemplo ms para consolidar estos nuevos conceptos. Esta vez queremos ver el ttulo del libro correspondiente a cada uno de los pedidos realizados: Select pedidos.id_pedido, articulos.titulo From pedidos, articulos Where pedidos.id_articulo=articulos.id_articulo En realidad la filosofa continua siendo la misma que para la consulta de una nica tabla. funciones, aunque bsicas, pueden ayudarnos en algunos momentos a expresar nuestra seleccin de una manera ms simple sin tener que recurrir a operaciones adicionales por parte del script que estemos ejecutando. Algunas de estas funciones son representadas en la tabla siguiente : Funcin Sum(campo) Avg(Campo) Count(*) Max(Campo) Min(Campo) Descripcin Calcula la suma de los registros del campo especificado Calcula la media de los registros del campo especificado Nos proporciona el valor del numero de registros que han sido seleccionados Nos indica cual es el valor mximo del campo Nos indica cual es el valor mnimo del campo

Seleccin de tablas IV

Dado que el campo de la funcin no existe en la base de datos, sino que lo estamos generando virtualmente, esto puede crear inconvenientes cuando estamos trabajando con nuestros scripts a la hora de tratar su valor y su nombre de campo. Es por ello que el valor de la funcin ha de ser recuperada a partir de un alias que nosotros especificaremos en la sentencia SQL a partir de la instruccin AS. La cosa podra quedar as: Select Sum(total) As suma_pedidos From pedidos A partir de esta sentencia calculamos la suma de los valores de todos los pedidos realizados y almacenamos ese valor en un campo virtual llamado suma_pedidos que podr ser utilizado como cualquier otro campo por nuestras paginas dinmicas. Por supuesto, todo lo visto hasta ahora puede ser aplicado en este tipo de funciones de modo que, por ejemplo, podemos establecer condiciones con la clusula Where construyendo sentencias como esta: Select Sum(cantidad) as suma_articulos From pedidos Where id_articulo=6 Esto nos proporcionara la cantidad de ejemplares de un determinado libro que han sido vendidos. Otra propiedad interesante de estas funciones es que permiten realizar operaciones con varios campos dentro de un mismo parntesis: Select Avg(total/cantidad) From pedidos Esta sentencia da como resultado el precio medio al que se estn vendiendo los libros. Este resultado no tiene por qu coincidir con el del precio medio de los libros presentes en el inventario, ya que, puede ser que la gente tenga tendencia a comprar los libros caros o los baratos: Select Avg(precio) as precio_venta From articulos Una clusula interesante en el uso de funciones es Group By. Esta clusula nos permite agrupar registros a los cuales vamos a aplicar la funcin. Podemos por ejemplo calcular el dinero gastado por cada cliente: Select id_cliente, Sum(total) as suma_pedidos From pedidos Group By id_cliente O saber el numero de pedidos que han realizado: Select id_cliente, Count(*) as numero_pedidos From pedidos Group By id_cliente Las posibilidades como vemos son numerosas y pueden resultar prcticas. Todo queda ahora a disposicin de nuestras
U N I V E R S I D A D D E 35 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

ocurrencias e imaginacin.

Las bases de datos (BD) cuanto ms extensas requieren una mayor atencin a la hora de organizar sus contenidos. Cuando se trabaja con tablas de miles o decenas de miles de registros la bsqueda de un determinado dato puede resultar un proceso largo que ralentiza enormemente la creacin de nuestra pgina. Es por ello importante tener en cuenta una serie de aspectos indispensables para el mejor funcionamiento de la base. Gestin y eleccin de los ndices Los ndices son campos elegidos arbitrariamente por el constructor de la BD que permiten la bsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo, esta ventaja se ve contrarrestada por el hecho de ocupar mucha ms memoria (el doble ms o menos) y de requerir para su insercin y actualizacin un tiempo de proceso superior. Evidentemente, no podemos indexar todos los campos de una tabla extensa ya que doblamos el tamao de la BD. Igualmente, tampoco sirve de mucho el indexar todos los campos en una tabla pequea ya que las selecciones pueden efectuarse rpidamente de todos modos. Un caso en el que los ndices pueden resultar muy tiles es cuando realizamos peticiones simultneas sobre varias tablas. En este caso, el proceso de seleccin puede acelerarse sensiblemente si indexamos los campos que sirven de nexo entre las dos tablas. En el ejemplo de nuestra librera virtual estos campos seran id_cliente e id_articulo. Los ndices pueden resultar contraproducentes si los introducimos sobre campos triviales a partir de los cuales no se realiza ningn tipo de peticin ya que, adems del problema de memoria ya mencionado, estamos ralentizando otras tareas de la base de datos como son la edicin, insercin y borrado. Es por ello que vale la pena pensarselo dos veces antes de indexar un campo que no sirve de criterio para bsquedas de los internautas y que es usado con muy poca frecuencia por razones de mantenimiento. Gestin de los nexos entre tablas El enlace entre tablas es uno de los puntos ms peliagudos y que puede llevar a la absoluta ralentizacin de la base de datos a causa "pequeos" detalles que resultan ser fatales. Imaginemos que trabajamos con una pequea BD constituida por dos tablas de 1000 registros cada una. Imaginemos ahora una seleccin simultnea en la que imponemos la condicin de que el valor un campo de la primera sea igual a de una segunda, algo que se realiza con mucha frecuencia. En este tipo de casos, la BD leer y comparar cada valor de campo de una con cada valor de campo de la otra. Esto representara un milln de lecturas. Este hecho podra agravarse si consultamos una tercera tabla al mismo tiempo y podra llegar a ser catastrfico si tenemos en cuenta que la BD esta siendo consultada por varios internautas al mismo tiempo. Para evitar situaciones de colapso, es necesario indexar cada uno de los campos que sirven de enlace entre esas tablas. En el ejemplo de nuestra librera virtual, ya lo hemos dicho, estos campos seran id_cliente e id_articulo. Adems, resulta tambin de vital importancia el definir esos campos de una forma estrictamente idntica en cada una de las tablas, es decir, el campo ha de ser de la misma naturaleza y caractersticas. No vale definirlo como real en una tabla y entero en otra o cambiar la longitud mxima para los alfanumricos o que en una tabla sea de longitud constante y en otra variable... El gestionar inteligentemente estos aspectos puede solucionarnos muchos quebraderos de cabeza y permitir a los internautas navegar ms agradablemente por nuestro sitio. Gestion de los campos Ya hemos comentado por encima los diferentes tipos de campo existentes en una base de datos. La eleccin del tipo de campo apropiado para cada caso puede ayudarnos tambin a optimizar el tamao y rapidez de nuestra base de datos. La preguntas que hay que hacerse a la hora de elegir la naturaleza y dimensiones del campo son: -Qu tipo de dato voy a almacenar en el campo? Nmeros, texto, fechas... -Cul es el tamao mximo que espero que pueda alcanzar alguno de los registros del campo? Hay que tener en cuenta que cuanto ms margen le demos al valor mximo del campo, ms aumentar el tamao de nuestra base de datos y ms tiempo tardara en realizar las consultas. Adems, el factor tamao puede verse agravado si estamos definiendo un campo indexado, para los cuales, el espacio ocupado es aproximadamente del doble. Un consejo prctico es que las fechas sean almacenadas en formato de fecha ya que ello nos permite reducir el espacio que ocupan en memoria de ms del doble y por otro lado, podremos aprovechar las prestaciones que SQL y nuestro lenguaje de servidor nos ofrecen. Podremos calcular la diferencia de das entre dos fechas, ordenar los registros por fecha, mostrar los registros comprendidos en un intervalo de tiempo... Existe la posibilidad para los campos de texto de fijar una cierta longitud para el campo o dejar que cada registro tenga una longitud variable en funcin del nmero de carcteres que posea. Elegir campos de longitud variable nos puede ayudar a optimizar los recursos de memoria de la BD, no obstante, es un arma de doble filo ya que las consultas se realizan ms lentamente puesto que obligamos a la tabla a establecer cul es el tamao de cada registro que se est comparando en lugar
U N I V E R S I D A D D E 36 A Q U I N O B O L I V I A

Optimizar prestaciones I

Optimizar prestaciones II

FACULTAD DE CIENCIAS Y TECNOLOGA

de saberlo de antemano. Es por tanto aconsejable, para los campos indexados de pequeo tamao, atribuirles una longitud fija. Eliminar llamadas a bases de datos En pginas tipo portal en las que a los lados se encuentran enlaces que son impresos a partir de bases de datos (distintas secciones, servicios,...) existe siempre un efecto ralentizador debido a que se trata de pginas altamente visitadas que efectan mltiples llamadas a BD sistemticamente en cada una de sus pginas. Una forma de agilizar la visualizacin de estas pginas es textualizando estos enlaces a partir de scripts internos. Pongamos el ejemplo de Desarrolloweb: Como puede verse, a los lados hay secciones como "Vuestras pginas", "Cosecha del 2000", "Manuales" cuyos enlaces estn almacenados en bases de datos. Sin embargo, los enlaces que se visualizan en la pgina no han sido obtenidos por llamadas a bases de datos sino que, cada vez que un nuevo elemento de la seccin es aadido, esto actualiza automticamente, por medio de un script, un archivo texto en el que el nuevo enlace es incluido y l ms antiguo es eliminado. Es, de hecho, este archivo texto el que es insertado en el cdigo fuente de la pgina. De este modo evitamos media docena de llamadas a bases de datos cada vez que una pgina es vista lo cual permite optimizar recursos de servidor de una manera significativa. Eliminar palabras cortas y repeticiones En situaciones en la que nuestra base de datos tiene que almacenar campos de texto extremadamente largos y dichos campos son requeridos para realizar selecciones del tipo LIKE '%algo%', los recursos de la BD pueden verse sensiblemente mermados. Una forma de ayudar a gestionar este tipo bsquedas es incluyendo un campo adicional. Este campo adicional puede ser creado automticamente por medio de scripts y en l incluiramos el texto original, del cual habremos eliminado palabras triviales como artculos, preposiciones o posesivos. Nos encargaremos adems de eliminar las palabras que estn repetidas. De esta forma podremos disminuir sensiblemente el tamao del campo que va a ser realmente consultado. Hemos comentado en otros captulos que los campos texto de mas de 255 caracteres denominados memo no pueden ser indexados. Si an despus de esta primera filtracin nuestro campo continua siendo demasiado largo para ser indexado, lo que se puede hacer es cortarlo en trozos de 255 caracteres de manera a que lo almacenemos en distintos campos que podrn ser indexados y por tanto consultados con mayor rapidez. En general, la mayora de las bases de datos poseen potentes editores de bases que permiten la creacin rpida y sencilla de cualquier tipo de tabla con cualquier tipo de formato. Sin embargo, una vez la base de datos est alojada en el servidor, puede darse el caso de que queramos introducir una nueva tabla ya sea con carcter temporal (para gestionar un carrito de compra por ejemplo) o bien permanente por necesidades concretas de nuestra aplicacin. En estos casos, podemos, a partir de una sentencia SQL, crear la tabla con el formato que deseemos lo cual nos puede ahorrar ms de un quebradero de cabeza. Este tipo de sentencias son especialmente tiles para bases de datos como Mysql, las cuales trabajan directamente con comandos SQL y no por medio de editores. Para crear una tabla debemos especificar diversos datos: El nombre que le queremos asignar, los nombres de los campos y sus caractersticas. Adems, puede ser necesario especificar cules de estos campos van a ser ndices y de qu tipo van a serlo. La sintaxis de creacin puede variar ligeramente de una base de datos a otra ya que los tipos de campo aceptados no estn completamente estandarizados. A continuacin os explicamos someramente la sintaxis de esta sentencia y os proponemos una serie de ejemplos prcticos: Create Table nombre_tabla ( nombre_campo_1 tipo_1 nombre_campo_2 tipo_2 nombre_campo_n tipo_n Key(campo_x,...) ) Pongamos ahora como ejemplo la creacin de la tabla pedidos que hemos empleado en captulos previos: Create Table pedidos ( id_pedido INT(4) NOT NULL AUTO_INCREMENT,
U N I V E R S I D A D D E 37 A Q U I N O B O L I V I A

Algunos trucos prcticos

Creacin de tablas

FACULTAD DE CIENCIAS Y TECNOLOGA

id_cliente INT(4) NOT NULL, id_articulo INT(4)NOT NULL, fecha DATE, cantidad INT(4), total INT(4), KEY(id_pedido,id_cliente,id_articulo) ) En este caso creamos los campos id los cuales son considerados de tipo entero de una longitud especificada por el nmero entre parntesis. Para id_pedido requerimos que dicho campo se incremente automticamente (AUTO_INCREMENT) de una unidad a cada introduccin de un nuevo registro para, de esta forma, automatizar su creacin. Por otra parte, para evitar un mensaje de error, es necesario requerir que los campos que van a ser definidos como ndices no puedan ser nulos (NOT NULL). El campo fecha es almacenado con formato de fecha (DATE) para permitir su correcta explotacin a partir de las funciones previstas a tal efecto. Finalmente, definimos los ndices enumerndolos entre parntesis precedidos de la palabra KEY o INDEX. Del mismo modo podramos crear la tabla de artculos con una sentencia como sta: Create Table articulos ( id_articulo INT(4) NOT NULL AUTO_INCREMENT, titulo VARCHAR(50), autor VARCHAR(25), editorial VARCHAR(25), precio REAL, KEY(id_articulo) ) En este caso puede verse que los campos alfanumricos son introducidos de la misma forma que los numricos. Volvemos a recordar que en tablas que tienen campos comunes es de vital importancia definir estos campos de la misma forma para el buen funcionamiento de la base. Muchas son las opciones que se ofrecen al generar tablas. No vamos a tratarlas detalladamente pues sale de lo estrictamente prctico. Tan slo mostraremos algunos de los tipos de campos que pueden ser empleados en la creacin de tablas con sus caractersticas: Tipo INT o INTEGER DOUBLE o REAL CHAR VARCHAR DATE BLOB BIT o Bytes 4 8 1/caracter Descripcin Nmeros enteros. Existen otros tipos de mayor o menor longitud especficos de cada base de datos. Nmeros reales (grandes y con decimales). Permiten almacenar todo tipo de nmero no entero. Alfanumricos de longitud fija predefinida Fechas, existen multiples formatos especficos de cada base de datos

1/caracter+1 Alfanumricos de longitud variable 3

1/caracter+2 Grandes textos no indexables BOOLEAN _______ Almacenan un bit de informacin (verdadero o falso) 1

N I V E R S

I D A

D E 38

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

PROGRAMA DE CALIDAD UDABOL DIF 001 Consejos para disear una base de datos Disear una base de datos no es algo sencillo y s muy importante, ya que un mal diseo conlleva dificultades para desarrollar la aplicacin o una aplicacin compleja. Unos consejos que realmente son muy necesarios y muchas veces no se llevan a cabo. 1. Mal diseo: el diseo es lo fundamental, primero hay que saber qu es lo que se necesita mostrar para luego disear correctamente la base de datos. Yo personalmente me he encontrado con diseos iniciales muy bsicos que luego han ido parcheando y haciendo modificaciones drsticas para ajustarlas a un modelo que era el mismo desde el inicio de la aplicacin. 2. Ignorar la normalizacin: la normalizacin es fundamental para un buen rendimiento y una sencilla programacin. 3. Nomenclatura no estndar: los nombres deben significar algo para que sea sencillo de comprender a simple vista. A parte, la nomenclatura debe ser constante en todo el diseo. 4. Falta de documentacin: esto es una constante en todo el mundo de la programacin, y en las bases de datos no va a ser menos. Que tu sepas que significa una tabla o un campo, no quiere decir que otra persona que entre en el proyecto vaya a saberlo con la misma facilidad que t. 5. Una tabla que agrupa a muchas: un error normal es pensar que un diseo con muchas tablas es ms complejo, y que es mejor meterlo todo en una nica tabla. 6. Usar un identificador como nica clave primaria: no siempre es correcto usar nicamente un identificador numrico secuencial como clave primaria nica. 7. No usar las caractersticas de SQL para proteger la integridad de los datos: hay que tener en cuenta las reglas de campos nulos, tamaos de los campos y claves secundarias en el diseo para obtener una mejor integridad de datos. 8. No usar procedimientos almacenados para obtener los datos: es una forma de separar la capa de la base de datos de la capa del usuario. Aportan seguridad, encapsulamiento, mantenibilidad y rapidez. Yo tambin aadira el uso de vistas. 9. Falta de pruebas: algo para m muy importante es hacer pruebas de estres, para saber si la base de datos va a aguantar el volumen de datos que necesitar la aplicacin. Comprobar el tiempo de ejecucin de las sentencias para aadir ndices, etc...

N I V E R S

I D A

D E 39

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

PROGRAMA DE CALIDAD UDABOL DIF 002 Problemas en el diseo de Bases de Datos Relacionales Antes, de hablar de formas normales y dependencias de datos es conveniente considerar los defectos que pueden tener una base de datos mal diseada. Supongamos las siguientes relaciones: PERSONA (DNI, NOMBRE, APELLIDOS) COCHE (MATRICULA, MARCA. TIPO, POTENCIA, COLOR) TENER (DNI, MATRICULA, FECHA, PRECIO) Si en lugar de las anteriores relaciones que componen la BD, optsemos por una nica relacin, formada por los atributos de las tres, sta tendra los siguientes defectos: - En primer lugar, algunos datos sern redundantes; en general en esta relacin una persona aparecer tantas veces como coches posea. - Esta redundancia conlleva unos riesgos de incoherencia durante las actualizaciones: por ejemplo, si resulta que el nombre de Lpez no es Pedro sino Juan, hay que tener cuidado y actualizar todas las tuplas en las que aparece Lpez. - Es preciso admitir la presencia de valores nulos en una relacin de este tipo para poder mantener en la base, coches sin propietarios o personas que no tienen coches. Si muchos de los atributos no se aplican a todas las tuplas de la relacin, acabaremos con un gran nmero de nulos en esas tuplas. Esto puede originar un considerable desperdicio de espacio de almacenamiento Ej: Si slo el 10% de los empleados tiene oficinas. individuales, no se justificar incluir un atributo NUM_OFIC en la relacin EMPLEADO; ms bien, podramos crear una relacin OFICINAS_EMPL (DNIEMP, NUM_OFIC) contenga exclusivamente tuplas para los empleados con oficinas individuales). Por lo tanto adems de hacerse ms complicada la actualizacin (insercin, eliminacin y modificacin), se desperdicia espacio.Uno de los objetivos en el diseo de esquemas es minimizar el espacio de almacenamiento que ocupan las relaciones base (archivos). La agrupacin de atributos en esquemas de relacin tiene un efecto significativo sobre el espacio de almacenamiento, se requiere ms analisis. Recoleccin y anlisis de requerimientos: Los diseadores entrevistan a los futuros usuarios de la base de datos para recoger y documentar sus necesidades de informacin. En paralelo, conviene definir los requerimientos funcionales que consisten en operaciones (transacciones) que se aplicarn a la base de datos, e incluyen la obtencin de datos y la actualizacin. Diseo conceptual: Una vez recogidos todos los requerimientos, el siguiente paso es crear un esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel. El esquema conceptual contiene una descripcin detallada de los requerimientos de informacin de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones. Nosotros utilizaremos para el diseo de esquemas conceptuales el modelo E-R (entidad-relacin), que describe los datos cono entidades, vnculos (relaciones) y atributos. Diseo lgico de la base de datos (transformacin de modelo de datos): El siguiente paso en el proceso de diseo consiste en implementar de hecho la base de datos con un S.G.B.D. comercial, transformando el modelo conceptual al modelo de datos empleados por el S.G.B.D. (jerrquico, red o relacional). En nuestro caso haremos la implementacin con un S.G.B.D. relacional, por ser el modelo ms utilizado por las empresas en la actualidad. Diseo fsico de la base de datos: En este paso se especifican las estructuras de almacenamiento internas y la organizacin de los archivos de la base de datos. MODELO ENTIDAD RELACION E-R CONCEPTOS DEL MODELO E-R
U N I V E R S I D A D D E 40 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Presentacin e historia del modelo: El modelo E-R fue propuesto por Peter P. Chen entre los aos 1976-1977. Posteriormente otros muchos autores han investigado y escrito sobre el modelo, proporcionando importantes aportaciones, por lo que realmente no se puede considerar que exista un nico modelo E-R. El modelo E-R describe los datos como entidades, relaciones (vnculos) y atributos y permite representar el esquema conceptual de una base de datos de forma grfica mediante los diagramas E-R. Entidades y atributos: El objeto bsico que se representa en el modelo E-R es la entidad que es "cualquier objeto del mundo real con existencia propia, sobre el cual queremos tener informacin en una base de datos. Una entidad puede ser un objeto con existencia fsica (una cierta persona, una casa, un empleado, un coche,..) o un objeto con existencia conceptual (una empresa, un puesto de trabajo, un curso universitario,...). Conjunto de entidades es la totalidad de las entidades del mismo tipo que comparten las mismas propiedades o atributos. En los diagramas E-R se representan mediante un rectngulo y dentro del mismo se pone el nombre. Por ejemplo: CLIENTE, PROVEEDOR, ARTICULO, COCHE, etc. Debemos elegir nombres que comuniquen, hasta donde sea posible, el significado de cada entidad. Normalmente se utilizan nombres en singular y no en plural. EMPLEADO Tipos de entidades: a) Fuertes (o regulares), que son aquellas que tienen existencia por si mismas (Por ejemplo, EMPLEADO). Las entidades fuertes se representan como se ha dicho con un rectngulo con trazo simple. EMPLEADO DEPARTAMENTO

b) Dbiles, cuya existencia depende de otro tipo de entidad (Por ejemplo, FAMILIAR depende de EMPLEADO. La desaparicin de un empleado de la base de datos hace que desaparezcan tambin todos los familiares del mismo). Estos tipos de entidades se representan normalmente con un rectngulo con lneas de doble trazo. Estas entidades normalmente no tienen suficientes atributos para formar una clave primaria. FAMILIAR

Cada entidad tiene propiedades especificas, llamadas atributos, que la describen. Por ejemplo, una entidad PROVEEDOR puede describirse por su C.I.F., su nombre, su telfono, etc. Los atributos se representan por elipses que estn conectadas a su entidad o relacin mediante una lnea recta. PROVEEDOR CIF nombre tfno

N I V E R S

I D A

D E 41

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Al conjunto de valores que puede tomar un atributo se le llama dominio del atributo. Toda entidad debe tener al menos un atributo que permita diferenciar unas entidades particulares de otras, es decir que no toman nunca el mismo valor para dos entidades particulares diferentes. A estos atributos se les llaman claves. En el diagrama E-R los atributos clave deben aparecer destacados; por ejemplo, subrayando su nombre (por ejemplo, cif de la entidad PROVEEDOR). PROVEEDOR CIF nombre tfno

N I V E R S

I D A

D E 42

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

PROGRAMA DE CALIDAD UDABOL DIF 003 CASO DE ESTUDIO MUNICIPIO DE CHALLAPATA APLICACIN DE UN SISTEMA GESTIONADOR DE BASES DE DATOS Viendo las necesidades con el transcurso de los aos los municipios se vieron con la necesidad de contar con un sistema de red para lograr el control de su sistema de ingresos y egresos. La Honorable Alcalda Municipal de Challapata tena bastantes limitaciones en cuanto a las inversiones producto de sus propios recursos, ya que las inversiones provenan de la Prefectura, la Corporacin de Desarrollo de Oruro y el Servicio de Caminos. A la Alcalda no se la tomaba en cuenta ni para la elaboracin de los planes, ni en las inversiones para el desarrollo de la regin de Challapata. Con la Ley de Participacin Popular No. 1551 toda la Administracin de estos recursos pasa a las Alcaldas, es por esta razn que los ingresos del Municipio de Challapata aumentan y llegan a obtener mayores posibilidades para el progreso de la regin. Con este propsito de organizar y dar avance a estos territorios de la provincia Avaroa, y por ende puedan todas las organizaciones sociales beneficiarse con los servicios de salud, educacin e infraestructura bsica. Por el excesivo volumen de documentos que se procesan manualmente y la falta de automatizacin de estos procesos, necesitando contar con informacin oportuna que le permita satisfacer su necesidad de manera objetiva para crear proyecciones futuras de acuerdo al capital y fondos que posee logrando invertir en programas que beneficien al municipio, viendo las necesidades que afronta este Municipio en cuanto al manejo de todos sus ingresos y egresos de la comunidad, no existe un Sistema mediante el cual se pueda acceder o compartir la informacin en cuanto ala cuentas manejadas, a los deudores, a los contribuyentes, a las contribuciones, a la elaboracin de planilla, y otros. La honorable Alcalda Municipal de Challapata cuenta con los siguientes departamentos descritos a continuacin en el siguiente Organigrama.

N I V E R S

I D A

D E 43

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

ORGANIGRAMA DEL GOBIERNO MUNICIPAL DE CHALLAPATA

HONORABLE CONSEJO MUNICIPAL

HONORABLE ALCALDE MUNICIPAL ASESORIA LEGAL OFICIALIA MAYOR ADMINISTRATIVA CHOFER SECRETARIA SECRETARIA GENERAL

DEPARTAMENTO TECNICO

DEPARTAMENTO FINANCIERO

DEPARTAMENTO DE CULTURA

INGENIERO AGRONOMO

AUXILIAR DE FINANZAS

CONTABILIDAD

TESORERIA-CAJA IMPUESTOS

ENCARGADO DE ANTENA DE TELEVISION

AUXILIAR TECNICO

INTENDENCIA

AUXILIAR DE TELEVISION
COMISARIO

AGENTES

SERENOS

N I V E R S

I D A

D E 44

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

FLUJO DE INFORMACION DEL MUNICIPIO DE CHALLAPATA El flujo de informacin con que cuenta el Gobierno Municipal de Challapata es el siguiente:

Contribuyente
Pago de impuestos, patentes Y centjajes

Informe de Contribuciones

Tesorera-Caja

Informe de liquidaciones

Finanzas

Solicitud Informe

Oficial Mayor Administrativo

Sistema Gobierno Municipal

Informe personal

Honorable
Informe de contabilidad y liquidacin de beneficios Solicitud de apoyo

Oficial Mayor Administrativo

Cultura

Gobierno Municipal

DEPARTAMENTO DE FINANZAS Administra los recursos humanos y fortalecimiento Institucional; adquisicin de bienes y servicios, contratacin de obras, distribucin y control de material, inventarios, organizar y supervisar la ejecucin de actividades de contabilidad y presupuestos. Asimismo, realiza la elaboracin, ejecucin y control de presupuesto; recepcin, pagos y tributaciones, tambin los desembolsos con destino especfico, prepara un Balance General y emitir informes y reportes actualizados de ingresos y egresos de la Alcalda. Dentro de este departamento se maneja el siguiente flujo de informacin: Formularios: Ingresos, traspasos y egresos Facturacin Plan de cuentas Libro Mayor Libro Diario Cheques Cuentas Planillas: adicionales, sueldos, dietas Activos Fijos Presupuesto Actual Estado Financiero: Balance General, Estado de Resultados
U N I V E R S I D A D D E 45 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Dentro de los desembolsos se considera el desembolso Madre-Nio DEPARTAMENTO DE TESORERIA-CAJA (Control de Impuestos) La tesorera, directamente subordinada a la Divisin de Finanzas, es la unidad encargada de recepcionar todos los ingresos tributarios y no tributarios de la Alcalda. Asimismo, es responsable por todos los pagos efectuados por la Alcalda Municipal. Dirige las actividades de recepcin de los valores por concepto de impuestos, tasas, patentes y centajes o cualquier otro ingreso al Tesoro Municipal. El flujo de informacin es el siguiente: Patentes (comprende: negocios, tiendas, sastreras, etc.) Impuestos (comprende: vehculos, bienes inmuebles) Centajes (comprende: cobranzas generales, autorizacin de sepultura, aprobacin de planos, autorizacin de construccin, lnea nivel, ingresos por publicidad, televisin, ingreso alquileres por prstamo de coliseo, etc.) DEPARTAMENTO DE PERSONAL Y LIQUIDACION Realiza la coordinacin y supervisin de las actividades de planificacin, comunicacin social, servicios tcnicos y otros. Formula las polticas de reclutamiento, seleccin y contratacin de personal, promover la realizacin de programas de entrenamiento del personal, promover y supervisar la elaboracin de la planilla de sueldos del personal, procesa planillas generales y boletas de cancelacin de sueldos individuales, procesar los files del personal para realizar consultas y liquidacin de beneficios. RECUERDE : Los DIFs deben ser ledos con mucho detenimiento para entrar en la discusin. Es recomendable que la discusin sobre este DIFs de la Aplicacin de las definiciones de Sistemas Gestionadores de Bases de datos al Municipio de Challapata, se hace necesario realizar un amplio anlisis para cuestionar la influencia de las Bases de Datos a travs de los Sistema de Gestin de Bases de Datos.

N I V E R S

I D A

D E 46

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

PROGRAMA DE CALIDAD UDABOL DIF 004 CASO DE ESTUDIO CONSIDERACIONES DE DISEO DATAWAREHOUSE El diseo de un DW debe estar orientado a optimizar las consultas relacionadas con los aspectos del negocio que se desean estudiar. Tal y como se plante anteriormente, esto conduce a una estructura en estrella en la que el centro es la tabla "fact" o "hecho" que representa al factor principal por el que se desea analizar la base de datos. Alrededor de esta tabla aparecen las tablas "dimensin", que representan los diferentes aspectos relacionados con el principal y que influyen en el estudio. Dado que lo habitual no es disear el DW a partir de cero, sino que se suelen comenzar desde el diseo de las bases de datos operacionales de las que se dispone, el aspecto final del diagrama no es realmente el de una estrella sino que presenta "flecos" (lo que da el nombre de "starflake" o "snowflake" al diagrama resultante) que pueden "descentrar" a la tabla de hechos. As, si la tabla de hechos se refiriese a las ventas y una de las tablas de dimensin fuese la de productos, y otra la de empleados que realizan la venta, es posible que se arrastrase al diagrama parte del modelo que proviene del Entidad/Relacin inicial por lo que podra presentar un "desequilibrio" hacia los proveedores de dichos productos:

Empleado

Venta

Producto

Sumin

Proveedor

Cliente

Empresa

Es de

Dara como resultado al pasarlo al diseo del DW:

Vendedores

Tabla Ventas

Productos

Sumin

Proveedor

Empresa

Es de

Clientes

N I V E R S

I D A

D E 47

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

que, como se puede ver, no aparece centrado, sino que presenta "flecos" por arrastrar la parte del Entidad/Relacin correspondiente a los proveedores, a pesar de que no van a ser, a priori, aspectos por los cuales se van a estudiar las ventas. Entre los aspectos a tener en cuenta al afrontar el diseo de un DW hay que tener especial cuidado al: Identificar las tablas de hechos, ya que es posible tener ms de una. Por cada aspecto del negocio que interese estudiar debe aparecer una tabla de hechos. Identificar las tablas de dimensin (esto es, decidir cules son los parmetros por los que interesa realizar el estudio). Comprobar que ninguna de las tablas de hechos oculta tablas de dimensiones. Al heredar la estructura de las bases de datos operacionales, esto ocurre muy a menudo al encontrarnos que no se han eliminado atributos que ya no interesan. Comprobar que ninguna de las tablas de dimensin oculta una tabla de hechos. Esto conducira a la tabla a un crecimiento anormal muy por encima de los lmites aceptables para este tipo de tablas (por otra parte, este sntoma ayuda a identificar el error cometido en el diseo). Las tablas de dimensin no presentan una participacin importante a efectos de alterar el rendimiento del sistema por cuanto, en general, el peor de los casos nos lleva a que nos encontremos con tablas de ms que no se utilizan, pero que, dado el escaso crecimiento, no afectan al rendimiento. Por otra parte, las tablas de hechos s son fundamentales y, como se ha planteado anteriormente, provienen, en general, de las tablas de las relaciones del modelo Entidad/Relacin. A pesar de esto, s es importante tener en cuenta que puede haber tablas que unas veces participen en el diseo del DW como tablas de dimensin y otras veces como tablas de hechos. As es posible que en el ejemplo anterior, el primer diseo interesante sea el ya planteado, con la tabla de ventas como tabla de hechos, pero tambin es posible que interese un estudio pormenorizado de los clientes y su naturaleza de acuerdo con los productos, etc. ... Tabla Cliente

Vendedores

Productos

En general, una tabla ser de hechos si representa a alguno de los aspectos de negocio que se desean estudiar, mientras que lo ser de dimensin si representa a uno de los factores por los cuales se desean estudiar los anteriores aspectos. Otro punto importante a tener en cuenta a la hora de acometer el diseo de un DW es el de los atributos incluidos en las tablas. Estos atributos deberan cumplir una serie de caractersticas como son: No deben aparecer atributos que no interesen. Esto representa un serio problema de compromiso a la hora de elegir los atributos que se deben incluir en las tablas de hechos, ya que no se deben incluir atributos "por si son necesarios algn da" porque se incrementa el tamao de la tabla de una manera espectacular con su lgica repercusin en la eficiencia. Sin embargo, por otro lado, la falta de atributos en estas tablas pueden llevarnos a disponer de un DW cuyo anlisis no es vlido al no aparecer toda la informacin significativa. Se deben elegir los tamaos adecuados para cada uno de los atributos. Una de las costumbres en el modelo relacional es la de incrementar el tamao necesario de un atributo "por si se necesitase" (por ejemplo, no se considera importante s a un nombre se le reserva un tamao de 25 o de 30 caracteres). En este caso, dado

N I V E R S

I D A

D E 48

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

el volumen de datos que trata, el ahorro de unos pocos bytes en cada una de las ocurrencias nos lleva a un gran ahorro en el tamao global del DW. En contra de lo habitual, la discusin sobre la eleccin de "claves inteligentes/no inteligentes" en la tabla de hechos, se decanta, en este caso, por la segunda opcin. Se deben incluir claves artificiales que no guarden ninguna relacin con su significado semntico. Es cierto que esto conlleva la obligacin de realizar operaciones de "join" con las tablas de dimensin para poder interpretar dicho significado, pero evita la incoherencia que se producira si el contenido de las claves variase algn da y, por una parte hubiera que actualizarlo en todo el contenido de la tabla de hecho, y por otra, se perdiera informacin al encontrarse parte de ella ya almacenada en forma de resultados agregados/resumidos y su actualizacin resultase imposible. Como caso especial de atributo, existe una variante fundamental respecto del modelo relacional: el tratamiento que de la fecha se hace. La importancia que adquiere en un DW la fecha es enorme, ya que los anlisis de los datos se suelen referir a intervalos temporales muy definidos. Por tanto, lo primero es que la fecha debe estar almacenada como tal en la tabla de hechos y no con un cdigo artificial. Un aspecto fundamental es el de cmo se almacena dicha fecha. Las diferentes opciones presentan ventajas e inconvenientes: almacenar la fecha completa evita la necesidad de clculos pero ocupa ms espacio; almacenar nicamente el "offset temporal" producido desde la fecha por la cual se ha realizado la particin ahorra espacio, pero afecta al rendimiento al necesitar de clculos adicionales a la hora de mostrar una fecha completa; y por ltimo, almacenar intervalos es una posicin intermedia que sin afectar gravemente al rendimiento, tampoco ocupa tanto espacio. Lo habitual, sin embargo, es proceder al almacenaje de la fecha completa. Como ltima consideracin en cuanto al diseo de las tablas de hechos est el problema asociado a la particin. Hay que volver a destacar que stas tablas siempre se particionan, presentando nicamente como duda el criterio a seguir para dicha particin. Tal y como ya se ha planteado, el criterio que mejor se adapta a las necesidades de "no variacin" de un DW es el de particionar por fecha. Sin embargo esto puede plantear problemas con los diferentes tamaos generados, dado que es posible que el nmero de ocurrencias no presente una distribucin homognea a lo largo del tiempo (por ejemplo, las ventas en poca de rebaja son mayores que en otras pocas). Por esto, es comn la utilizacin de polticas acumulativas como la expuesta anteriormente (agregar datos a lo largo del tiempo, teniendo, por ejemplo, una tabla para cada da de la presente semana, una tabla para las cuatro ltimas semanas y una tabla para cada uno de los doce meses del ao, de tal manera que en cada plazo se agreguen los datos a las tablas correspondientes). En caso de que los datos que se manejen hagan que la particin por fechas no sea vlida (por ejemplo: el manejo de informacin de la bolsa, que es demasiado dependiente del momento) se pueden usar otros posibles criterios como las particiones de igual tamao (cuando una particin excede un lmite se acude a almacenar datos en la siguiente); particiones correspondientes a distribuciones geogrficas del negocio (una particin por sucursal o departamento), etc. El problema bsico de usar otros criterios es el de la localizacin de informacin correspondiente a otros momentos ("dnde est la informacin de hace tres meses?"). En cuanto a las tablas de dimensin, presentan como caractersticas fundamentales que no tienen tamaos muy grandes (siempre en proporcin al tamao de la tabla de hechos), y que no van a incrementar ostensiblemente dicho tamao a lo largo del tiempo (s lo hacen, probablemente habremos cometido algn error de diseo y ocultan alguna tabla de hechos).

N I V E R S

I D A

D E 49

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

El contenido de estas tablas se importa casi directamente del modelo de datos del Entidad/Relacin pero con la particularizacin de que si aparecen "flecos" en el modelo, se debe tender a "desnormalizar" las tablas que presenten relaciones de cardinalidad 1:N, de tal forma que se incorpore toda la informacin que se necesite en la tabla correspondiente: Tabla Ventas
(1,N) (1,1) Sumin

Vendedores

Productos

Proveedor

Clientes

Atributos

Es evidente que, en este ejemplo, la "desnormalizacin" de los datos procedentes de los proveedores, pasando dichos datos con la clave, a la tabla de productos, mejora sensiblemente la eficiencia de las consultas dado que evita hacer los correspondientes join con la tabla de proveedores. Otro factor a tener en cuenta es el hecho de intentar evitar que las tablas de dimensin presenten intersecciones no vacas con las tablas de hechos (posible dado que puede haber una entidad que participe como tabla de dimensin en un "star" pero que sea el aspecto de negocio a estudiar en otro). El gestor, al ejecutar las consultas, podra elegir la tabla de hechos para hacer el join en vez de la tabla de dimensin, lo que dara lugar a un tiempo de proceso enorme. Por otra parte, los anlisis y estudios que se realizan de los datos de un DW incluyen consultas del estilo de "Cmo se vieron afectadas las ventas durante esta promocin?" o "Se ha vendido ms por la maana o por la tarde?" o "Se ve afectado el volumen de ventas por el da de la semana?". Este tipo de consultas incluye, en un entorno relacional tradicional, operaciones tpicas en los atributos que hacen referencias a fechas con clculos de "que da de la semana ha sido una determinada fecha", etc., que, de aplicarse a cada una de las ocurrencias de un DW, afectaran gravemente a la eficiencia. Por tanto, probablemente convenga realizar un diseo "a medida" para cada uno de los casos, que contemple la estructura de la fecha ms conveniente. As, por ejemplo, si quisiramos calcular el da de la semana, sera lgico pensar en que se podra tener una tabla con todos los das del ao y el da de la semana que ha sido, ya que su tamao es pequeo en proporcin al DW (como mximo 365 tuplas por ao) y ahorra muchsimo tiempo de clculo. Esto podra llevarnos a tener unas tablas de dimensin que presentasen una jerarqua de atributos respecto de las fechas que sera implanteable en el modelo relacional aplicable a gestin tradicional (bien podra ser el modelo necesario para el estudio del comportamiento de las audiencias televisivas por franjas horarias a lo largo del ao):
fecha da semana mes ao

semestre

promocin

N I V E R S

I D A

D E 50

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Otro aspecto importante en el diseo de un DW es la inclusin de tablas que contengan los datos ya agregados, dado que ese ser el tipo de consulta ms comn. Esto nos lleva a la inclusin de tablas de hechos ms reducidas en cuanto a su tamao. Para hacer esto se pueden plantear dos filosofas: a) la tabla incluye en su nombre la dimensin por la que se agrega (lo que hace que se pierda una dimensin) y contiene los datos agregados. En este caso es posible que se puedan eliminar otras dimensiones que no tengan sentido o inters. b) la tabla contiene una consulta sobre la tabla de hechos, de tal forma que es un filtro y se consigue una generalizacin en cuanto a que no presenta los posibles problemas de actualizacin de la primera solucin. En cualquier caso, el gestor de consultas debe "monitorizar" las tablas de agregados de tal forma que detecte la utilizacin que de ellas se hace para eliminarlas cuando no se usen o proponer la creacin de alguna ms si detecta que mejorara la eficiencia global del sistema. Por otra parte, en estas tablas s que es recomendable la utilizacin de los cdigos y claves con significado semntico dado que su vigencia es absolutamente temporal. Como ltimo aspecto de este tema cabe destacar la gran importancia que presenta la existencia de un buen diccionario de datos que pueda ser usado de forma "inteligente" por los diferentes mdulos y en especial por el gestor de almacenamiento y el gestor de consultas. Para ello debera presentar un mnimo de datos: De cada tabla fuente de datos: Nombre. Atributos, nombre y momento en que se carga cada uno. Para cada tabla del DW que contenga datos Raw (detalle): Significado de cada uno de los atributos. De que atributos proviene en las bases de datos operacionales Mtodos utilizados en su transformacin. Nombre del proceso que lleva a cabo la transformacin. Condiciones para la ejecucin de los procesos anteriores. Polticas de particionamiento en la tabla. Vigencia de los datos

Para cada tabla de agregados: Consulta que la crea De qu tablas proviene (momento de actualizacin) Para cada usuario: Perfil/permisos Para cada consulta: Almacenar su ejecucin, momentos, estadstica, etc. RECUERDE : Los DIFs deben ser ledos con mucho detenimiento para entrar en la discusin.

N I V E R S

I D A

D E 51

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Es recomendable que la discusin sobre este DIFs de las Consideraciones de diseo de un Datawarehouse, se hace necesario realizar un amplio anlisis para cuestionar la influencia de la Bases de datos a travs del Datawarehouse.

N I V E R S

I D A

D E 52

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

PROGRAMA DE CALIDAD UDABOL DIF 005 CASO DE ESTUDIO FARMACIA_XXXY En el caso de estudio FARMACIA_XXXY establecer las tablas que representan el siguiente modelo Entidad Relacin y tambin crear las relaciones del modelo respectivo.
cod_prov nombre

direccion

Proveedores
telefono cantidad

Consideraciones: Cualquier fecha es tipo fecha/hora Cualquier cantidad es de tipo numrica entera Todo lo dems es de tipo texto

Pedidos
fecha_ped cod_cli cod_med descripcion categoria cantidad
presentacion

pat

mat

precio_unitario clasificacion nom

Medicamentos

Ventas

Clientes

nit

laboratorio

cantidad

fecha_venta

Pertenece

Clasificacin Antibitico Antiviral Antialrgico

Categoria Virus Bacteria Parsito Hongo

Presentacion Crema Jarabe Tableta Inyectable Supositorio Ovulo Cpsulas

Almacenes

cantidad_total

RECUERDE : Los DIFs deben ser ledos con mucho detenimiento para entrar en la discusin. Es recomendable que la discusin sobre este DIFs de Diseo de una base de datos, se hace necesario realizar un amplio anlisis para cuestionar la influencia del Modelado de Bases de datos a travs de las relaciones respectivas.

N I V E R S

I D A

D E 53

A Q U

I N

B O L I V

I A

FACULTAD DE CIENCIAS Y TECNOLOGA

PROGRAMA DE CALIDAD UDABOL DIF 005 FUNCIONES Y SEGURIDAD DE LAS BASES DE DATOS Para migrar correctamente las aplicaciones de Oracle a Microsoft SQL Server 2000, debe saber cmo implementa SQL Server las funciones y la seguridad de las bases de datos. Cifrado de archivos de bases de datos Microsoft Windows 2000 permite a los usuarios cifrar archivos a travs del Sistema de archivos de cifrado (EFS). SQL Server 2000 puede hacer uso de EFS. Los archivos de las bases de datos pueden cifrarse; de esta forma, se evita que los usuarios muevan, copien o visualicen su contenido. Este cifrado se lleva a cabo en el sistema operativo, no en la base de datos lgica. Una vez que SQL Server abre el archivo cifrado, los datos contenidos en dicho archivo se muestran como no cifrados. Seguridad de la red Microsoft SQL Server 2000 permite utilizar SSL (nivel de sockets seguro) para cifrar las comunicaciones de red que tienen lugar entre el propio sistema y los clientes. Este cifrado se aplica a todos los protocolos utilizados entre los equipos que admite SQL Server 2000 y puede ser de 40 o 128 bits en funcin de la versin del sistema operativo Microsoft Windows que SQL Server est ejecutando. Para obtener ms informacin, consulte "Cifrado de la biblioteca de red" en los Libros en pantalla de SQL Server. Cuentas de inicio de sesin Una cuenta de inicio de sesin permite el acceso a los datos y a las opciones de administracin de SQL Server a los usuarios. Con una cuenta de inicio de sesin de invitado se puede tener acceso a SQL Server y consultar slo las bases de datos que admitan el acceso de invitados. (La cuenta guest (invitado) no se configura de forma predeterminada y es necesario crearla.) La cuenta de inicio de sesin permite a los usuarios administrar o tener acceso a los datos en una instancia de SQL Server 2000. SQL Server 2000 utiliza dos mtodos diferentes para autenticar inicios de sesin: Autenticacin de Windows Un administrador de bases de datos (DBA) especifica las cuentas de inicio de sesin de Windows que pueden utilizarse para conectarse a una instancia de SQL Server 2000. Los usuarios que hayan iniciado la sesin en Windows y utilicen estas cuentas pueden conectarse a SQL Server 2000 sin necesidad de especificar una contrasea y un identificador de inicio de sesin de base de datos diferentes. Cuando se utiliza Autenticacin de Windows, SQL Server 2000 hace uso de los mecanismos de seguridad de Windows NT 4.0 o Windows 2000 para validar las conexiones de inicio de sesin y se basa en las credenciales de seguridad del usuario de Windows. En SQL Server 2000, los usuarios no tienen que escribir sus identificadores ni sus contraseas de inicio de sesin puesto que esta informacin se obtiene directamente de la conexin de red de confianza. Su funcionamiento es el mismo que el de la opcin IDENTIFIED EXTERNALLY asociada a las cuentas de usuario de Oracle. Autenticacin de SQL Server Un administrador de bases de datos establece una cuenta de inicio de sesin de base de datos diferente. El usuario debe especificar dicha cuenta de inicio de sesin y su contrasea cuando intente conectarse a SQL Server 2000. El inicio de sesin de la base de datos no est relacionado con el inicio de sesin del usuario de Windows; funciona como la opcin IDENTIFIED BY PASSWORD asociada a las cuentas de usuario de Oracle. Cada instancia de SQL Server 2000 se ejecuta en uno de los dos modos de autenticacin:
U N I V E R S I D A D D E 54 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Modo de autenticacin de Windows (conocido como seguridad integrada en anteriores versiones de SQL Server). En este modo, SQL Server 2000 slo permite conexiones que utilicen Autenticacin de Windows. Modo mixto. En este modo, las conexiones pueden realizarse con Autenticacin de Windows o con Autenticacin de SQL Server. Para obtener ms informacin acerca de los mecanismos de seguridad citados, consulte los Libros en pantalla de SQL Server. Grupos, funciones y permisos SQL Server y Oracle utilizan permisos para reforzar la seguridad de las bases de datos. Los permisos en las instrucciones de SQL Server se utilizan para restringir la posibilidad de crear objetos de base de datos (comparable a los permisos del sistema de Oracle). SQL Server utiliza tambin permisos de objeto. Al igual que en Oracle, la pertenencia del nivel de los objetos se asigna a su creador y es intransferible. Para que los usuarios de otras bases de datos puedan tener acceso a los objetos, deben poseer permisos en los objetos. Los miembros de la funcin fija de servidor sysadmin y de las funciones fijas de base de datos db_owner y db_securityadmin, tambin pueden conceder los permisos de los objetos de un usuario a otros usuarios. Los permisos en las instrucciones y en los objetos de SQL Server pueden concederse directamente a cuentas de usuario de base de datos. No obstante, suele ser ms sencillo administrar los permisos de las funciones de bases de datos. Las funciones de SQL Server se utilizan para conceder y revocar privilegios a grupos de usuarios de bases de datos (muy parecido a las funciones de Oracle). Las funciones son objetos de base de datos asociados a bases de datos concretas. Cada instalacin lleva asociado un nmero especfico de funciones fijas de servidor, que sirven para todas las bases de datos. Un ejemplo de funcin fija de servidor es sysadmin. Los grupos de Windows y los usuarios de bases de datos tambin pueden agregarse como inicios de sesin de SQL Server. Los permisos se conceden al grupo o al usuario de Windows. Una base de datos puede tener un nmero ilimitado de funciones o de grupos de Windows. La funcin predeterminada public se encuentra en todas las bases de datos y no puede quitarse. Las funciones public actan de forma muy parecida a como lo hace la cuenta PUBLIC en Oracle. Todos los usuarios de bases de datos son siempre miembros de la funcin public. Un usuario de base de datos puede pertenecer a cualquier nmero de funciones, adems de a la funcin public. Los grupos y usuarios de Windows pueden pertenecer tambin a otras funciones y son siempre miembros de la funcin public. Grupos, funciones y permisos Microsoft SQL Server y Oracle utilizan permisos para reforzar la seguridad de las bases de datos. Los permisos en las instrucciones de SQL Server se utilizan para restringir la posibilidad de crear objetos de base de datos (comparable a los permisos del sistema de Oracle). SQL Server utiliza tambin permisos de objeto. Al igual que en Oracle, la pertenencia del nivel de los objetos se asigna a su creador y es intransferible. Para que los usuarios de otras bases de datos puedan tener acceso a los objetos, deben poseer permisos en los objetos. Los miembros de la funcin fija de servidor sysadmin y de las funciones fijas de base de datos db_owner y db_securityadmin, tambin pueden conceder los permisos de los objetos de un usuario a otros usuarios. Los permisos en las instrucciones y en los objetos de SQL Server pueden concederse directamente a cuentas de usuario de base de datos. No obstante, suele ser ms sencillo administrar los permisos de las funciones de bases de datos. Las funciones de SQL Server se utilizan para conceder y revocar privilegios a grupos de usuarios de bases de datos (muy parecido a las funciones de Oracle). Las funciones son objetos de base de datos asociados a bases de datos concretas. Cada instalacin lleva asociado un nmero especfico de funciones fijas de servidor, que sirven para todas las bases de datos. Un ejemplo de funcin fija de servidor es sysadmin. Los grupos de
U N I V E R S I D A D D E 55 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Windows NT y los usuarios de bases de datos tambin pueden agregarse como inicios de sesin de SQL Server. Los permisos se conceden al grupo o al usuario de Windows NT. Una base de datos puede tener un nmero ilimitado de funciones o de grupos de Windows NT. La funcin predeterminada public se encuentra en todas las bases de datos y no puede quitarse. Las funciones public actan de forma muy parecida a como lo hace la cuenta PUBLIC en Oracle. Todos los usuarios de bases de datos son siempre miembros de la funcin public. Un usuario de base de datos puede pertenecer a cualquier nmero de funciones, adems de a la funcin public. Los grupos y usuarios de Windows NT pueden pertenecer tambin a otras funciones y son siempre miembros de la funcin public. Usuarios de bases de datos y cuenta de invitado En Microsoft SQL Server, es preciso autorizar una cuenta de inicio de sesin de usuario para utilizar una base de datos y sus objetos. Para tener acceso a una base de datos, la cuenta de inicio de sesin puede utilizar uno de los siguientes mtodos: Especificar la cuenta de inicio de sesin como usuario de la base de datos. La cuenta de inicio de sesin puede utilizar una cuenta de invitado de la base de datos. El inicio de sesin de un grupo de Windows NT puede asignarse a una funcin de la base de datos. Las cuentas individuales de Windows NT que sean miembros del grupo indicado pueden conectarse a la base de datos. Los miembros de las funciones db_owner o db_accessadmin, o de la funcin fija de servidor sysadmin, pueden crear las funciones de las cuentas de usuario de base de datos. Una cuenta puede incluir varios parmetros: el identificador de inicio de sesin de SQL, el nombre de usuario de base de datos (opcional) y hasta un nombre de funcin (opcional). El nombre de usuario de base de datos no tiene que ser el mismo que el identificador de usuario de inicio de sesin. Si no se indica el nombre de usuario, ser igual al identificador de inicio de sesin. Si no se suministra un nombre de funcin, el usuario de la base de datos slo ser miembro de la funcin public. Despus de crear el usuario de base de datos, puede asignarlo a las funciones que desee. Los miembros de las funciones db_owner y db_accessadmin tambin pueden crear cuentas de invitado guest . La cuenta de invitado permite a cualquier cuenta de inicio de sesin vlida de SQL Server tener acceso a una base de datos sin necesidad de utilizar una cuenta de usuario. De forma predeterminada, la cuenta de invitado hereda los privilegios que tiene asignados la funcin public, aunque posteriormente podrn modificarse. Puede conceder derechos de acceso a una base de datos a cuentas de grupos y de usuarios de Windows NT, del mismo modo que en SQL Server. Cuando un usuario de Windows NT miembro de un grupo se conecta a una base de datos, recibe los permisos que tiene asignados el grupo de Windows NT. Si es miembro de varios grupos de Windows NT con derechos de acceso a la base de datos, el usuario obtiene los derechos combinados de todos los grupos a los que pertenece. Funcin sysadmin Los permisos de los miembros de la funcin fija de servidor sysadmin de Microsoft SQL Server son similares a los de un administrador de bases de datos de Oracle. En SQL Server, la cuenta de inicio de sesin sa del modo de autenticacin de SQL Server es miembro de esta funcin de forma predeterminada, al igual que los miembros del grupo local Administradores cuando se instala SQL Server en un equipo con Windows 2000. Un miembro de la funcin sysadmin puede agregar y quitar usuarios y grupos de Windows, y cuentas de inicio de sesin de SQL Server. Los miembros de esta funcin tienen generalmente las siguientes responsabilidades: Instalar SQL Server. Configurar servidores y clientes. Crear bases de datos.* Establecer derechos de inicio de sesin y permisos.* Transferir datos entre bases de datos de SQL Server.*
U N I V E R S I D A D D E 56 A Q U I N O B O L I V I A

FACULTAD DE CIENCIAS Y TECNOLOGA

Realizar copias de seguridad y restaurar bases de datos.* Implementar y mantener la duplicacin. Programar operaciones desatendidas.* Supervisar y optimizar el rendimiento de SQL Server.* Diagnosticar problemas del sistema. Las tareas que llevan un asterisco (*) se pueden delegar a otras funciones de seguridad o usuarios. Un miembro de la funcin fija de servidor sysadmin puede tener acceso a cualquier base de datos y a todos sus objetos, incluidos los datos, de una instancia concreta de SQL Server. De la misma forma que para los administradores de bases de datos de Oracle, hay varios comandos y procedimientos del sistema que slo pueden ejecutar los miembros de la funcin sysadmin. Funcin db_owner Aunque la funcionalidad de las bases de datos de Microsoft SQL Server y las tablas de Oracle es parecida, se administran de forma diferente. Las bases de datos de SQL Server son en s mismas dominios administrativos. Cada base de datos es asignada a un propietario (dbo). Este usuario es siempre miembro de la funcin fija de base de datos db_owner. Otros usuarios tambin pueden ser miembros de la funcin db_owner. Cualquier usuario miembro de esta funcin puede realizar las tareas administrativas relacionadas con la base de datos, al contrario que en Oracle, donde es el administrador de base de datos quien realiza las tareas administrativas de todas las tablas. Entre estas tareas administrativas se incluyen: Administrar el acceso a las bases de datos. Modificar opciones de bases de datos (slo lectura, usuario individual, etc.). Realizar copias de seguridad y restaurar el contenido de las bases de datos. Conceder y revocar permisos de base de datos. Crear y eliminar objetos de base de datos. Los miembros de la funcin db_owner tienen permisos para llevar a cabo cualquier tarea en su base de datos. La mayor parte de los derechos asignados a esta funcin estn divididos en varias funciones fijas de base de datos o pueden concederse a usuarios de bases de datos. No son necesarios privilegios sysadmin en todo el servidor para tener privilegios db_owner en una base de datos. Conclusin Microsoft SQL Server 2000 ofrece un valor a las empresas basado en un bajo costo total de propiedad, facilidad de uso (asistentes, herramientas de optimizacin y funciones de optimizacin automticas) y capacidades integradas de almacenamiento de datos. SQL Server 2000 ha recibido los mayores elogios y obtenido los mejores premios de manos de los crticos del sector; asimismo, ha demostrado su capacidad para satisfacer las necesidades de las empresas y sitios de comercio electrnico ms importantes del mundo. En este documento se analizan muchas de las diferencias existentes entre la arquitectura de Oracle y la de Microsoft SQL Server; tambin se explican algunas de las diferencias que existen entre la terminologa utilizada para describir Oracle y la utilizada para describir SQL Server. Si se familiarizo con SQL Server y lo disea correctamente, podr migrar su aplicacin desde Oracle y comenzar a disfrutar de las ventajas de SQL Server 2000.

N I V E R S

I D A

D E 57

A Q U

I N

B O L I V

I A