1-146

MANUAL DE SQL SERVER 2000

2-146

Mdulo I: Diseo de una base de datosTema 1:Teora de sistemas de base de datos relacionalConceptos bsicos Que es un sistema de base de datos? El modelo Relacional Terminologa relacional

Tema 2: Introduccin al diseo de bases de datosComponentes de una base de datos SQL Server Normalizar un diseo de base de datos . Lograr una base de datos bien diseada Relaciones entre entidades . Relaciones entre tablas uno-a-uno . Relaciones entre tablas uno-a-muchos . Relacin entre tablas muchos-a-muchos

Tema 3: Elementos adicionales para el diseo una base de datos SQL ServerArchivos y Grupos de archivos . Reglas para disear Archivos y Grupos de archivos . Grupos de archivos predefinido . Recomendaciones Registros de transacciones Ambiente . Estimar el Tamao de una base de datos . Diseo fsico de la base de datos Algunas consideraciones sobre instalacin de SQL Server . Seguridad . Planificar la Seguridad . Niveles de seguridad . Modos de autenticacin

Tema 4: Identificar los requerimientos de diseoEl Proceso Identificar Identificar Identificar Identificar de Identificar los Requerimientos de diseo las Metas del Sistema la Cantidad y Tipos de Datos Cmo se usarn los Datos las Reglas Comerciales del Sistema

Tema 5: Desarrollar un modelo lgico de base de datosIdentificar Entidades y Sus Atributos Identificando Relaciones Entre las Entidades Identificar Restricciones sobre los Datos

Ejercicios Prcticos

Mdulo II: Implementar una base de datos y sus tablasTema 1: Crear y administrar una base de datos SQLServerMtodos para crear una base de datos SQLServer . El comando CREATE DATABASE . Usar el Enterprise Manager . El asistente Create Database Administrar una base de datos SQL Server . Ver informacin referida a la base de datos Modificar una base de datos . Configurar opciones de la base de datos Borrar una base de datos SQL Server

Tema 2: Identificar Tipos de DatosTipos de datos provistos por el sistema Tipos de datos definidos por el usuario

Tema 3: Crear y administrar tablas en SQL ServerCrear tablas en una base de datos SQL-Server . Determinar la anulabilidad de las columnas . Definir valores por defecto . Auto numeracin y columnas de identificacin Crear columnas de identificacin Propiedad IDENTITY

3-146Identificadores globalmente nicos . Mtodos para crear tablas Comando CREATE TABLE Enterprise Manager Database Designer (Diseador de base de datos) Administrar tablas de una base de datos SQL Server . Consultar informacin sobre tablas . Modificar tablas de una base de datos SQL Server . Borrar tablas de una base de datos SQL Server

Tema 4: Implementar la integridad de los datosIntroduccin a la integridad de los datos . Asegurar la integridad de los datos . Tipos de Dato . Definiciones NOT NULL . Definiciones DEFAULT . Propiedades IDENTITY . Restricciones (constraints) . Reglas (rules) . Desencadenadores . Indices Tipos de Integridad de datos . Integridad de entidad . Integridad de dominio . Integridad referencial . Integridad definida por el usuario Implementar restricciones de integridad . Introduccin a las restricciones de integridad . Restricciones PRIMARY KEY Crear restricciones PRIMARY KEY . Restricciones UNIQUE Crear restricciones UNIQUE . Restricciones FOREIGN KEY Crear restricciones FOREIGN KEY Deshabilitar restricciones FOREIGN KEY . Restricciones CHECK Crear restricciones CHECK Deshabilitar restricciones CHECK

Tema 5: Implementar ndicesIntroduccin Arquitectura de los ndices . Propsito y estructura . Tipos de ndices . ndices agrupados . ndices no agrupados . Caractersticas de los ndices Unicidad ndices compuestos Factor de llenado Sentido de ordenamiento . Informacin sobre ndices . Indexado Full-Text Crear y administrar ndices . Crear ndices Usar interfase grfica Usar comandos Transact-SQL . Administrar ndices Eliminar un ndice Reconstruir un ndice Renombrar un ndice . Elegir un ndice ndices agrupados ndices no agrupados . Recubrimiento de ndice . ndices compuesto frente a ndices mltiples

Mdulo III: Consultar y modificar datosTema 1: Principios de lgebra relacionalOperaciones relacionales . Restriccin . Proyeccin

4-146. Producto . Unin . Interseccin . Diferencia . Reunin . Divisin Clculo relacional . Listas objetivo . Expresiones

Tema 2: Consultar a los datos en una base de datos SQL ServerLos fundamentos del comando SELECT El comando SELECT . Usar clusulas en la lista de seleccin La clusula DISTINCT La clusula TOP n La clusula AS Tipos de informacin en la lista de seleccin La clusula INTO La clusula FROM Las clusulas WHERE, GROUP BY, y HAVING . La clusula GROUP BY . Procesar las clusulas WHERE, GROUP BY , y HAVING La clusula ORDER BY

Tema 3: Usar tcnicas de consulta avanzadas para acceder a los datosUsar combinaciones para recuperar datos . Combinaciones INNER . Combinaciones OUTER Usar LEFT OUTER JOIN Usar RIGHT OUTER JOIN Usar FULL OUTER JOIN . Definir subconsutas dentro del comando SELECT . Tipos de Subconsultas Subconsultas que son usadas con IN y NOT IN Subconsultas que son usadas con operadores de comparacin Subconsultas que son usadas con EXISTS y NOT EXISTS Resumir datos . Usar el operador CUBE para resumir datos . Usar el operador ROLLUP para resumir datos

Tema 4: Modificar datos en una base de datos SQL ServerInsertar datos en un base de datos SQL Server . Usar el comando INSERT para agregar datos Usar el comando INSERT...VALUES para agregar datos Usar una subconsulta SELECT para agregar datos . Usar un comando SELECT...INTO para agregar datos . Agregar texto o imgenes a filas ya insertadas Modificar datos en una base de datos SQL Server . Usar el comando UPDATE para modificar datos Usar la clusula SET para modificar datos Usar la clusula WHERE para modificar datos Usar la clusula FROM para modificar datos Modificar textos o imgenes Borrar datos de una base de datos SQL Server . Usar el comando DELETE para borrar datos . Usar el comando TRUNCATE TABLE para borrar datos

Mdulo IV: Implementar procedimientos almacenadosTema 1: Introduccin a los procedimientos almacenadosPropsitos y ventajas de los Procedimientos Almacenados . Rendimiento Marco de programacin Seguridad Categoras de procedimientos almacenados . Procedimientos almacenados del sistema . Procedimientos almacenados locales . Procedimientos almacenados temporarios . Procedimientos almacenados extendidos . Procedimientos almacenados remotos

5-146 Tema 2: Crear, ejecutar, modificar y borrar procedimientos almacenadosCmo se almacena un procedimiento Mtodos para crear procedimientos almacenados . El comando CREATE PROCEDURE Proveer a un procedimiento almacenado de un contexto Crear procedimientos almacenado temporarios Agrupar, levantar y encriptar procedimientos almacenados Enterprise Manager El asistente para crear de procedimientos almacenados Crear y agregar procedimientos almacenados Extendidos Diferir la resolucin de nombres Ejecutar un procedimiento almacenado . Llamar un procedimiento almacenado para ejecutarlo . Especificar parmeros y sus valores . Ejecutar prcedimientos almacenados cuando SQL Server arranca Modificar procedimientos almacenados Borrar procedimientos almacenados

Tema 3: Programar procedimientos almacenadosParmetros y variables El comando RETURN y el manejo de errores Valores por defecto y parmetros NULL Comprobar errores del Server Procedimientos asidados Cursores Mtodos para recuperar datos

Mdulo V: Conectarse a un SQL ServerTema 1: Comenzando con ADO - ActiveX Data Objects Tema 2: Modelo de objetos de ADO Tema 3: Objetos ADO Tema 4: Propiedades ADO

6-146

MODULO I Tema 1: Teora de Sistema de Base de Datos RelacionalLo que aprender: Al terminar este tema usted podr: Entender los principales conceptos de la teora de base de datos relacionales Que es un sistema de base de datos? Un sistema de Base de Datos es bsicamente un sistema para archivar en computador; o sea, es un sistema computarizado cuyo propsito general es mantener informacin y hacer que est disponible cuando se solicite. La informacin en cuestin puede ser cualquier cosa que se considere importante para el individuo o la organizacin a la cual debe servir el sistema; dicho de otro modo, cualquier cosa necesaria para apoyar el proceso general de atender los asuntos de esa organizacin. Pero es fundamental para el xito de su proyecto limitar el sistema de base de datos, que Ud. quiere disear, a un especfico y bien definido conjunto de objetos e interacciones; lo que le permitir definir el alcance del sistema. Como veremos mas adelante no se trata de modelizar "todo" el mundo sino solo la parte "importante" y "pertinente" para alcanzar los objetivos funcionales del sistema. Esa parte del mundo que nos interesa la llamaremos el espacio del problema. El trmino modelo de datos se utilizar se utilizar para significar una descripcin conceptual del espacio del problema, esto incluye la definicin de sus entidades, que son clases de objetos que comparten determinadas caractersticas (por ejemplo un "cliente" es una entidad), dichas caractersticas se las denomina atributos (por ejemplo el "nombre" del cliente es un atributo de un cliente). El modelo de datos incluye la descripcin de las interrelaciones entre las entidades y las restricciones sobre dichas relaciones (por ej: las "facturas de venta" se emiten a nombre de un "cliente" y esta relacin no puede faltar, es decir , no puede haber una factura que no tenga asignada un cliente. La capa fsica o esquema fsico del diseo, est constituida por las tablas y vistas que sern implementadas, y constituye la traslacin del modelo conceptual en una representacin fsica que pueda ser implementada utilizando el Sistema de Gestin de Bases de Datos Relacional (SGBDR) a ser empleado, a los fines del presente Kit, el MS-SQL Server 2000. Este esquema no es mas que la representacin del modelo conceptual o lgico expresado en trminos que puedan ser usados para describirlo al SGBDR. A medida que Ud. le vaya explicando al SGBDR como quiere que almacene los datos, el SGBDR crear los objetos necesarios para gestionarlos (tablas, vistas, ndices, relaciones, etc). Lo que dar origen a la estructura la base de datos. Por ltimo, llamaremos base de datos a la combinacin de los datos y su estructura. La base de datos incluye, entonces, a los datos mas las tablas, vistas, procedimientos almacenados, consultas, y a las reglas que el motor de base datos utilizar para asegurar el resguardo de los datos. El trmino base de datos no incluye a la aplicacin la cual consiste de los formularios y los reportes con los que interactuarn los usuarios, ni incluye la piezas de cdigo usadas para unir las partes de la aplicacin. En un modelo de tres capas, la aplicacin que accede a los datos almacenados en una base de datos y que a la vez interacta con el usuario se divide en dos partes: la llamada capa intermedia que contiene todas las validaciones y las reglas del negocio y es la que interacta con la base de datos y el front end que es la que contiene los formularios y realiza la presentacin de los reportes, interactuando con el usuario final (ver figura 1.1).

7-146

El modelo Relacional El modelo relacional est basado en una coleccin de principios matemticos desarrollado inicialmente sobre un conjunto de conceptos tericos y predicados lgicos. Esto principios fueron aplicados al campo de los modelos de datos a finales de los aos 60 por el Dr. E. F. Codd, investigador de IBM, y publicados por primera vez en 1970.

8-146 El modelo relacional define el modo en que los datos van a ser representados (estructura de datos), la forma en que van ser protegidos (integridad de los datos) y las operaciones que pueden ser aplicadas sobre ellos (manipulacin de datos). El MS-SQLServer 2000 implementa un modelo relacional de base de datos. En trminos generales un sistema de base de datos relacional tiene las siguientes caractersticas: Todos los datos estn conceptualmente representados como un arreglo ordenado de datos en filas y columnas, llamado relacin. Todos los valores son escalares, esto es, que dada cualquier posicin fila/columa dentro de la relacin hay uno y solo un valor. Todas las relaciones son realizadas sobre la relacin completa y dan como resultado otra relacin, concepto conocido como clausura . A los fines prcticos una relacin puede ser considerada como una tabla, an cuando al momento de formularse la teora intencionalmente se excluy el trmino tabla por tener connotaciones de ordenamiento que no se deben aplicar al concepto de relacin que es mas un conjunto, que una tabla ordenada. De todos modos y a los fines del presente Kit utilizaremos en forma indistinta la denominacin de relacin o de tabla. Es importante destacar que el concepto de clausura permite que el resultado de una operacin sobre un relacin sea el dato para otra operacin. Por lo que como veremos mas adelante al resultado de una orden select se le puede aplicar otro select. Terminologa relacional La Figura 1.2 muestra una relacin con los nombres formales de sus componentes principales

La estructura de la figura constituye una relacin, donde cada fila constituye una tupla. La cantidad de tuplas en una relacin indica la cardinalidad de la relacin. Cada columna en la relacin es un atributo, y la cantidad de atributos indica el grado de la relacin. La relacin se divide en dos secciones el encabezado y el cuerpo, donde el encabezado contiene la etiquetas de los atributos. Estas etiquetas constan de dos parte separadas por dos puntos ":" la parte izquierda es la denominacin propiamente dicha del atributo, mientras que la parte derecha configura el dominio del atributo, que es el conjunto de todos los valores posibles y legales que puede tomar el atributo en las tuplas (por ej: el primer atributo de la relacin de la figura tiene como dominio a todas las compaas que existen, mientras que solo algunas son valores efectivamente incorporados a la relacin). El cuerpo consiste en un conjunto desordenado de cero o ms tuplas, esto indica que las tuplas no tienen un orden intrnseco, el nmero de registro no es tenido en cuenta en el modelo relacional. Por otro lado las relaciones sin tuplas siguen siendo relaciones. Por ltimo las relaciones son conjuntos donde cualquier elemento puede ser inequvocamente identificado, por lo que la relacin no permite tuplas duplicadas. En cuanto a la terminologa, en esta parte se utiliz una lenguaje formal para la definicin de los elementos abordados, a partir de ahora se utilizarn las siguientes equivalencias de significado: Una relacin puede ser una tabla, o un recordset o un result set. Una tupla puede ser una fila (row) o un registro (record)

9-146 Un atributo puede ser una columna (column) o un campo (field). Dichas equivalencias se generan porque al instanciar en la implementacin fsica el modelo conceptual, se utilizan trminos que corresponden precisamente al modelo fsico de implementacin en el SGBDR, en este caso el MS-SQLServer 2000, que utiliza la terminologa Microsoft.

MODULO I Tema 2: Introduccin al diseo de bases de datosLo que aprender: Al terminar este tema usted podr: Describir los componentes principales de una base de datos relacional. Describir el proceso de normalizacin y normalizar tablas en un diseo de bases de datos. Identificar las relaciones que existen entre las entidades. Antes de que usted pueda desarrollar un modelo lgico de datos, y subsecuentemente crear una base de datos y los objetos que esta contiene, usted debe comprender los conceptos fundamentales del diseo de bases de datos. Adems, deber estar familiarizado con los componentes bsicos de una base de datos y cmo esos componentes trabajan juntos para proporcionar un almacenamiento eficaz de los datos y acceso a aquellos que requieren tipos especficos de datos, en formatos especficos, desde la base de datos. Este tema presenta los componentes bsicos de una base de datos y la terminologa que describe esos componentes. Se discute la normalizacin y el concepto de relaciones entre entidades, dos conceptos que deben integrarse para entender el diseo de bases de datos relacionales. Componentes de una base de datos SQL Server Una base de datos SQL Server consiste en una coleccin de tablas que guardan conjuntos especficos de datos estructurados. Una tabla (entidad) contiene una coleccin de filas (tuplas) y columnas (atributos). Cada columna en la tabla se disea para guardar un cierto tipo de informacin (por ejemplo, fechas, nombres, montos, o nmeros). Las tablas tienen varios tipos de controles (restricciones, reglas, desencadenadores, valores por defecto, y tipos de datos de usuario) que aseguran la validez de los datos. Las tablas pueden tener ndices (similar a los de los libros) que permiten encontrar las filas rpidamente. Usted puede agregar restricciones de integridad referencial a las tablas para asegurar la consistencia entre los datos interrelacionados en tablas diferentes. Una base de datos tambin puede utilizar procedimientos almacenados que usan Transact-SQL programando cdigo para realizar operaciones con los datos en la base de datos, como guardar vistas que proporcionan acceso personalizado a los datos de la tabla. Por ejemplo, suponga que se crea una base de datos llamada MiCoBD para manejar los datos en su compaa. En la base de datos MiCoBD, crea una tabla llamada Empleados para guardar informacin sobre cada empleado, y la tabla contiene las columnas EmpID, Apellido, Nombre, Dept, y Cargo. Para asegurar que nunca dos empleados tengan el mismo EmpID y que la columna de Dept contiene nmeros slo vlidos para las secciones en su compaa, usted debe agregar restricciones a la tabla. Si usted quisiera realizar bsquedas rpidas para encontrar los datos de un empleado basado en el ID del empleado, usted definira ndices. Por cada empleado, se agrega una fila de datos a la tabla Empleados, para esto usted crea que un procedimiento almacenado llamado AgregarEmp que se personaliza para aceptar los valores de los datos por un nuevo empleado y que realiza la operacin de agregar la fila a la tabla Empleados. Se podra necesitar un resumen departamental de empleados, por lo que usted define una vista llamada

10-146 EmpsDept que combina datos de las tablas Secciones y Empleados. Figura 2.1 muestra las partes de la base de datos MiCoBD.

Figura 2.1 La base de datos MiCoBD, la tabla Empleados, y la vista EmpsDept

Normalizar un diseo de base de datos A continuacin se ver el tema de normalizacin desde un punto vista prctico, resaltando aquellos conceptos tiles y comentando las limitaciones que deben tenerse en cuenta en el proceso de normalizado de una base de datos. Perfeccionar un diseo de base de datos incluye el proceso de normalizacin. Normalizar un diseo lgico de base de datos involucra usar mtodos formales para separar los datos en mltiples tablas relacionadas. Tener un nmero mayor de tablas con pocas columnas es caracterstico de una base de datos normalizada; mientras que tener pocas tablas con ms columnas cada una es caracterstico de una base de datos no-normalizada. Una normalizacin razonable mejora a menudo el comportamiento general del sistema. Cuando se utilizan los ndices, el SQL Server 2000 Query Optimizer (Optimizador de Consultas de SQL Server) es muy eficiente al seleccionar interrelaciones entre las tablas. Un aumento de la normalizacin produce una mayor cantidad y complejidad de combinaciones entre las tablas requeridas para recuperar los datos. Demasiadas combinaciones complejas entre varias tablas puede deteriorar el rendimiento en las consultas. Una normalizacin razonable debera incluir la mnima cantidad de consultas habituales posible que involucren ms de cuatro tablas relacionadas.

11-146 Una base de datos que se usa principalmente para soporte de decisin (al revs de una base de datos operacional que realiza tareas de actualizacin de datos) podra no tener actualizaciones redundantes y podra ser ms entendible y eficaz para las consultas si el diseo no se normaliza totalmente. No obstante, tener datos no-normalizados es el error de diseo ms comn en aplicaciones de base de datos ms que tener datos demasiado normalizados. Empezar con un diseo completamente normalizado y a partir de all desnormalizar selectivamente algunas tablas por razones especficas de rendimiento de las consultas es una buena estrategia. A veces el diseo de la base de datos lgico ya est definido, tal el caso de una base de datos existente, y el rediseo total no es factible. Pero an entonces, podra ser posible normalizar una tabla grande selectivamente en varias tablas ms pequeas. Si la base de datos es accedida a travs de los procedimientos almacenados, este cambio del esquema podra tener lugar sin afectar las aplicaciones. Si no, podra ser posible crear una vista que esconde de las aplicaciones el cambio del esquema. Lograr una base de datos bien diseada En la teora de diseo de base de datos relacionales, las reglas de normalizacin identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseada. Estas reglas pueden ponerse bastante complicadas y pueden ir ms all del alcance del presente. De todos modos, hay algunas reglas que pueden ayudarlo a lograr un diseo de la base de datos correcto. Una tabla debe tener un identificador, debe guardar datos para slo un solo tipo de entidad, debera evitar columnas que acepten valores nulos, y no debe tener valores o columnas repetidas. Una Tabla debe Tener un Identificador La regla fundamental de la teora del diseo de base de datos es que cada tabla debe tener un identificador de las filas, que es una columna o un conjunto de columnas que toman valores nicos para cada registro de la tabla. Cada tabla debe tener una columna de ID, y ningn registro puede compartir el mismo valor de ID con otro. La columna (o columnas) que sirve como identificador nico de la fila para una tabla constituye la clave primaria de la tabla. En la Figura 2.2, la tabla Empleados no incluye una columna que identifica unvocamente cada fila dentro de la tabla. Fjese que el nombre de David Mendlen aparece dos veces. Al no haber ningn identificador nico en esta tabla, no hay ninguna manera de distinguir fcilmente una fila de otra. Esta situacin podra ser un problema, ms an, si ambos empleados trabajaron en la misma seccin y tienen el mismo tipo de trabajo.

Figura 2.2 Una tabla que no tiene ningn identificador nico. Usted puede normalizar la tabla agregando una columna que singularmente identifique cada fila, como se muestra en la Figura 2.3. Fjese que cada instancia de David Mendlen tiene un nico valor de EmpID.

12-146

Figura 2.3 Una tabla normalizada con un identificador nico. Una Tabla debe Guardar Datos para un Solo Tipo de Entidad Intentar guardar demasiada informacin en una tabla puede afectar la administracin eficaz y fiable de los datos en la tabla. Por ejemplo, en la Figura 2.4, la tabla Libros incluye informacin sobre cada editor de libros.

Figura 2.4 Una tabla de libros que incluye ttulo e informacin del editor. Aunque es posible tener columnas que contienen informacin para el libro y su editor en la misma tabla, este diseo lleva a varios problemas. La informacin del editor debe agregarse y debe guardarse redundantemente para cada libro publicado por un editor dado. Esta informacin usa espacio extra de almacenamiento en la base de datos. Si la direccin del editor cambia, el cambio debe realizarse en todos los registros de libros de ese editor. Adems, si el ltimo libro de un editor es eliminado de la tabla Libros, la informacin de ese editor se pierde. En una base de datos normalizada, se guardara la informacin sobre los libros y editores en por lo menos dos tablas: una para los libros y una para los editores (como se muestra en Figura 2.5).

Figure 2.5 Un diseo de la base de datos normalizado incluye una tabla para los libros y una tabla para informacin sobre el editor.

13-146 La informacin sobre el editor tiene que ser grabada slo una vez y quedar vinculada a cada libro de ese editor. Si la informacin del editor cambia, debe cambiarse en slo un lugar, y la informacin del editor estar all an cuando el editor no tenga ningn libro en la base de datos. Una Tabla debe Evitar Columnas que acepten valores nulos Las tablas pueden tener columnas definidas para permitir valores nulos. Un valor nulo indica que el registro no tiene valor por ese atributo. Aunque puede ser til permitir valores nulos en casos aislados, es mejor usarlos muy poco porque ellos requieren un manejo especial con el consiguiente aumento de la complejidad de las operaciones de datos. Si tiene una tabla que tiene varias columnas que permiten valores nulos y varias de las filas tienen valores nulos en dichas columnas, debera considerar poner estas columnas en otra tabla vinculada a la tabla primaria. Guardar los datos en dos tablas separadas permite que la tabla primaria sea simple en su diseo pero a la vez mantener la capacidad de almacenar informacin ocasional. Una Tabla no Debe tener Valores o Columnas Repetidas Una tabla no debe contener una lista de valores para un pedazo especfico de informacin. Por ejemplo, suponga que usted quiere consultar los ttulos de libros y sus autores. Aunque la mayora de los libros podran tener slo un autor, muchos de ellos podran tener dos o ms. Si hay slo una columna en la tabla Libros para el nombre del autor, esta situacin presenta un problema. Una solucin es guardar el nombre de ambos autores en una columna, pero mostrar una lista de autores individuales sera entonces difcil. Otra solucin es cambiar la estructura de la tabla para agregar otra columna para el nombre del segundo autor, pero esta solucin guarda slo dos autores. Debera agregarse otra columna si algn libro tiene tres autores.

Figure 2.6 Dos modos de estructurar la tabla Libros Si usted encuentra que necesita guardar una lista de valores en una sola columna o si tiene columnas mltiples para una sola pieza de datos (Autor1, Autor2, y as sucesivamente), debe considerar poner los datos duplicados en otra tabla con un vnculo a la tabla primaria. En el caso de la tabla Libros, usted podra crear una tabla primaria adicional para los autores y luego crear una tercera tabla que vincule los libros a sus autores y almacene los valores repetidos, como se muestra en la Figura 2.7. Este diseo habilita cualquier nmero de autores para un libro sin modificar la definicin de la tabla y no desperdicia espacio libre para almacenar libros que tienen un solo autor.

14-146

Figura 2.7 Tres tablas que guardan informacin sobre los libros y sus autores. Relaciones entre entidades En una base de datos relacional, las relaciones entre entidades ayudan a prevenir datos redundantes. Una relacin entre entidades trabaja vinculando datos de dos tablas a travs de columnas clave, que generalmente tienen el mismo nombre en ambas tablas. En la mayora de los casos, la relacin entre entidades vincula la clave primaria de una tabla que proporciona a un identificador nico para cada fila con una entrada en la clave fornea de la otra tabla. Se discuten claves primarias y las claves forneas en ms detalle en Tema 5, "Llevando a cabo Integridad de los Datos." Hay tres tipos de relaciones entre las tablas: uno-a-uno, uno-a-muchos, y muchos-a-muchos. El tipo de relacin depende de cmo se definen las columnas relacionadas. Relaciones entre tablas uno-a-uno En una relacin uno-a-uno, una fila en tabla A no tiene ms de una fila vinculada en tabla B (y viceversa). Una referencia uno-a-uno se crea si las dos columnas relacionadas son claves primarias o tienen restriccin de unicidad. Este tipo de referencia no es comn, sin embargo, porque la informacin relacionada de esta manera normalmente estara en una sola tabla. Relaciones entre tablas uno-a-muchos Una relacin uno-a-muchos es el tipo ms comn de relacin entre entidades. En este tipo de relacin, una fila en la tabla A tiene muchas filas vinculadas en la tabla B, pero una fila en la tabla B tiene una nica fila vinculada en la tabla A. Por ejemplo, las tablas Editores y Ttulo mencionadas previamente tienen una relacin uno-a-muchos. Cada editor produce muchos ttulos, pero cada ttulo tiene un solo editor. Una relacin uno-a-muchos se crea si solo una de las columnas relacionadas es una clave primaria o tiene una restriccin de unicidad. Relacin entre tablas muchos-a-muchos

15-146 En una relacin muchos-a-muchos, una fila en tabla A tiene muchas filas vinculadas en tabla B (y viceversa). Se puede crear tal relacin definiendo una tercera tabla, llamada tabla de unin cuya clave primaria consiste en las claves forneas de ambas tablas A y B. En las Figuras 2.6 y 2.7, usted vio cmo la informacin del autor puede separarse en otra tabla. La tabla Libros y la tabla Autores tienen una relacin muchos-a-muchos. Cada una de estas tablas tiene una relacin uno-a-muchos con la tabla de LibrosAutores que sirve como la tabla de la unin entre las dos tablas primarias. Ejercicio 1: Explorando los Conceptos Bsicos de Diseo de la base de datos En este ejercicio, usted ver los objetos primarios que estn contenidos en una base datos SQL Server. Usted aplicar los principios de normalizacin a un diseo de la base de datos e identificar las relaciones que existen entre las entidades dentro de una base de datos. Resumen del tema Una base de datos SQL Server consiste en una coleccin de tablas que guardan un conjunto especfico de datos estructurados. Una tabla contiene una coleccin de filas y columnas. Cada columna en la tabla se disea para guardar un cierto tipo de informacin (por ejemplo, fechas, nombres, montos, o nmeros). El diseo lgico de la base de datos, incluyendo las tablas y las relaciones entre ellas, es el corazn de una base de datos relacional optimizada. Perfeccionar un diseo de base de datos incluye el proceso de normalizacin. Normalizar un diseo lgico de base de datos lgico involucra usar mtodos formales para separar los datos en mltiples tablas relacionadas. A medida que la normalizacin aumenta, incrementa el nmero y la complejidad de los vnculos que son necesarios para recuperar los datos. Las reglas de normalizacin identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseada. Las tablas en una base de datos normalizada deben tener un identificador, deben guardar slo datos para un solo tipo de entidad, deben evitar columnas que acepten valores nulos, y no deben tener valores o columnas repetidos. Usted puede crear relaciones entre sus tablas en un diagrama de la base de datos y mostrar cmo se vinculan las columnas en una tabla a las columnas de otra tabla. En una base de datos relacional, las relaciones ayudan a prevenir datos redundantes. Una relacin trabaja vinculando datos de las columnas, generalmente columnas clave que tienen el mismo nombre en ambas tablas. Hay tres tipos de relaciones entre las tablas: uno-a-uno, uno-a-muchos, y muchos-a-muchos. El tipo de relacin entre tablas depende de cmo usted define las columnas relacionadas.

MODULO I Tema 3: Elementos adicionales para el diseo una base de datos SQL ServerLo que aprender: Al terminar este tema usted podr: Describir los factores que se deben tener en cuenta al disear una base de datos SQL Server. Al disear una base de datos SQL Server, se deben tener en cuenta varios factores, que incluyen los archivos de la base de datos y grupos de archivos, registros de transacciones, la instalacin del SQL Server y su ambiente operativo, y la seguridad. Esta leccin discute cada uno de estos temas. Archivos y Grupos de archivos Para definir una base de datos, SQL Server 2000 usa un conjunto de archivos del sistema operativo. Todos los datos y objetos de la base de datos, como tablas, procedimientos almacenados, desencadenadores, y vistas, se guardan dentro de los siguientes tipos de archivos del sistema operativo:

16-146 Archivo Primario. Este archivo contiene la informacin de arranque para la base de datos y es usado para almacenar datos. Cada base de datos tiene un archivo de los datos primario. Archivo Secundario. Estos archivos mantienen todos los datos que no caben en el archivo de los datos primario. Si el archivo primario puede almacenar todos los datos da la base de datos, las bases de datos no necesitan tener archivos de los datos secundarios. Algunas bases de datos podran ser lo suficientemente grandes para necesitar archivos de datos secundarios mltiples o usar archivos secundarios en unidades de disco separadas para distribuir datos en mltiples discos o para mejorar el rendimiento de la base de datos. Registros de transacciones. Estos archivos mantienen la informacin del registro que se usa para recuperar la base de datos. Debe haber por lo menos un archivo de registro para cada base de datos. Una base de datos simple puede crearse con un archivo primario que contiene todos los datos y objetos y un archivo de registro que contiene la informacin del registro de transacciones. Alternativamente, una base de datos ms compleja puede crearse con un archivo primario y cinco archivos secundarios. Los datos y objetos de la base de datos son distribuidos por los seis archivos, y cuatro archivos de registro adicionales contienen la informacin del registro de transacciones. Los grupos de archivos agrupan archivos para propsitos administrativos y de ubicacin de datos. Por ejemplo, tres archivos (Data1.ndf, Data2.ndf, y Data3.ndf) pueden crearse en tres unidades de disco y pueden asignarse al grupo de archivos fgroup1. Una tabla puede crearse entonces especficamente en el grupo de archivos fgroup1. Las consultas sobre los datos de la tabla se extendern por los tres discos y se mejorar el rendimiento. La misma mejora de rendimiento puede lograrse con un solo archivo creado sobre un arreglo redundante de discos independientes (RAID). Los archivos y grupos de archivos, sin embargo, ayudan a agregar nuevos archivos fcilmente a los nuevos discos. Adicionalmente, si su base de datos excede el tamao del mximo para un solo archivo Windows NT, usted puede usar un archivo de datos secundario para permitir el crecimiento de su base de datos. Reglas para disear Archivos y Grupos de archivos Cuando usted disea archivos y grupos de archivos, debe adherir a las reglas siguientes: Un archivo o grupo de archivos no puede ser usado por ms de una base de datos. Por ejemplo, los archivos que ventas.mdf y ventas.ndf que contienen datos y objetos de la base de datos de ventas no pueden ser usados por cualquier otra base de datos. Un archivo puede ser un miembro de slo un grupo de archivos. Los datos y la informacin de registro de transaccin no pueden ser parte del mismo archivo o grupo de archivos. Los archivos de registro de transacciones nunca son parte de un grupo de archivos. Grupos de archivos predefinidos Una base de datos comprende un grupo de archivos primario y varios grupos de archivo definidos por el usuario. El grupo de archivos que contiene el archivo primario es el grupo de archivos primario. Cuando una base de datos se crea, el grupo de archivos primario contiene el archivo de datos primario y cualquier otro archivo que no se pone en otro grupo de archivos. Todas las tablas del sistema se asignan en el grupo de archivos primario. Si el grupo de archivos primario se queda sin espacio, ninguna informacin nueva del catlogo puede agregarse a las tablas del sistema. El grupo de archivos primario slo se llenar si la bandera de configuracin "autogrow" est apagada o si todos los discos que estn sosteniendo los archivos en el grupo de archivos primario se quedaron sin espacio. Si sucede esto, se deber encender la bandera de configuracin "autogrow" o mover archivos a un nuevo almacenamiento para liberar mas espacio. Los grupos de archivos definidos por el usuario son cualquier grupo de archivos que son especficamente creados por el usuario cuando l o ella estn inicialmente creando o posteriormente alterando la base de

17-146 datos. Si un grupo de archivos definido por el usuario se llena, se afectarn slo las tablas de los usuarios especficamente asignadas a ese grupo de archivos. En cualquier momento, un grupo de archivos puede ser designado como el grupo de archivos predefinido. Cuando se crean objetos en la base de datos sin especificar a que grupo de archivos pertenecen, se asignan al grupo de archivos predefinido. Los grupos de archivos predefinidos deben ser suficiente grandes para almacenar cualquier objeto no asignado a un grupo de archivos definido por el usuario. Inicialmente, el grupo de archivos primario es el grupo de archivos predefinido. Los grupos de archivos predefinidos pueden ser cambiados usando la sentencia ALTER DATABASE. Cuando usted cambia el grupo de archivos predefinido, cualquier objeto que no tiene un grupo de archivos especificado se asigna a los archivos de los datos en el nuevo grupo de archivos predefinido cuando se crea. La asignacin para los objetos y tablas del sistema, sin embargo, se mantiene en el grupo de archivos primario y no en el nuevo grupo de archivos predefinido. Cambiar el grupo de archivos predefinido previene que objetos del usuario que no se crean especficamente en un grupo de archivos definidos por el deban competir con los objetos y tablas del sistema para el espacio de los datos. Recomendaciones Al implementar una base de datos, usted debe intentar adherir a las pautas siguientes para usar archivos y grupos de archivos: La mayora de las bases de datos trabajar bien con un solo archivo del datos y un solo archivo de registro de transacciones. Si usted usa archivos mltiples, cree un segundo grupo de archivos para los archivos adicionales y configrelo como el grupo de archivos predefinido. De esta manera, el archivo primario contendr slo tablas y objetos del sistema. Para maximizar rendimiento, usted puede crear archivos o grupos de archivos en tantos discos fsicos locales disponibles como sea posible, y ubicar grandes objetos que compiten por espacio en grupos de archivos diferentes. Use grupos de archivos para habilitar la colocacin de objetos en discos fsicos especficos. Ubique las diferentes tablas que se usan para una misma consulta en grupos de archivos diferente. Este procedimiento mejorar el rendimiento al tomar ventaja del procesamiento paralelo de input/output del disco (I/O) al buscar datos vinculados. Ponga las tablas fuertemente accedidas y los ndices no-agrupados que pertenecen a esas tablas en grupos de archivos diferentes. Este procedimiento mejorar el rendimiento debido al I/O paralelo si los archivos se localizan en discos fsicos diferentes. No ponga el archivo de registro de transacciones en el mismo disco fsico con los otros archivos y grupos de archivos. Registros de transacciones Una base de datos en SQL Server 2000 tiene por lo menos un archivo de datos y un archivo de registro de transacciones. Los datos y la informacin del registro de transacciones nunca es mezclada en el mismo archivo, y archivos individuales son slo por una nica base de datos. El SQL Server usa el registro de transacciones de cada base de datos para recuperar transacciones. El registro de transacciones es un registro serial de todas las modificaciones que han ocurrido en la base de datos as como de las transacciones que realizaron dichas modificaciones. El archivo de registro de transacciones graba el comienzo de cada transaccin y archiva los cambios producidos en los datos. Este registro tiene bastante informacin para deshacer las modificaciones (si es necesario) que hizo durante cada transaccin. Para algunas operaciones pesadas, como CREATE INDEX, el registro de transacciones registra, en cambio, los hechos a los que la operacin dio lugar. El registro crece continuamente tanto como operaciones ocurran en la base de datos. El registro de transacciones graba la asignacin y liberacin de las pginas y la grabacin definitiva (commit) o la vuelta atrs (rollback) de cada transaccin. Este capacidad permite al SQL Server rehacer (Rollup) o deshacer (Rollback) cada transaccin de las siguientes maneras:

18-146 Una transaccin es rehecha cuando se aplica un registro de transacciones. El SQL Server copia la imagen posterior a cada modificacin de la base de datos o vuelve a ejecutar sentencias como CREATE INDEX. Estas acciones se aplican en el mismo orden en la que ellas ocurrieron originalmente. Al final de este proceso, la base de datos est en el mismo estado que estaba en el momento en que el registro de transacciones fue copiado. Una transaccin se deshace cuando una transaccin queda incompleta por alguna causa. El SQL Server copia la imagen previa de todas las modificaciones a la base de datos desde el BEGIN TRANSACTION. Si encuentra archivos de registro de transacciones que indican que un CREATE INDEX fue ejecutado, realiza operaciones que lgicamente invierten la sentencia. stos imgenes previas Ye inversiones del comando CREATE INDEX son aplicados en orden inverso a la secuencia original. A un punto de salvaguarda, el SQL Server asegura que se han grabado en el disco todos los archivos de registro de transacciones y las pginas de la base de datos que se modificaron. Durante cada proceso de recuperacin de base de datos, que ocurre cuando el SQL Server se reinicia, una transaccin necesita ser rehecha slo si no se conoce si todas las modificaciones de datos de la transaccin fueron realmente transferidas desde el cach de SQL Server al disco. Debido a que en un punto de salvaguarda se obliga a que todas las pginas modificadas sean efectivamente grabadas en el disco, este representa el punto que se toma como punto de inicio para el comienzo de las operaciones de recuperacin. Dado que para todas las pginas modificadas antes del punto de salvaguarda se garantiza que estn en el disco, no hay ninguna necesidad de rehacer algo que se hizo antes del punto de salvaguarda. Las copias de respaldo del registro de transacciones le permiten a usted que recupere la base de datos al momento de un punto especfico (por ejemplo, previo a entrar en datos no deseados) o a un punto de falla. Las copias de respaldo del registro de transacciones deben ser tenidas muy en cuenta dentro de su estrategia de recuperacin de bases de datos. Ambiente Generalmente, cuanto ms grande es la base de datos, mayores son los requisitos de hardware. El diseo de la base de datos siempre debe tomar en cuenta la velocidad del procesador, el tamao de la memoria, y el espacio del disco duro y su configuracin. Hay otros factores determinantes, sin embargo: el nmero de usuarios o sesiones coexistentes, el registro de transacciones, y los tipos de operaciones a realizar sobre la base de datos. Por ejemplo, una base de datos que contiene datos de la biblioteca escolar con escasos niveles de actualizacin generalmente tendr requisitos de hardware ms bajos que un almacn de datos de un-terabyte que contiene ventas, productos, e informaciones de los clientes frecuentemente analizados, para una gran corporacin. Aparte de los requisitos de almacenamiento de disco, se necesitar ms memoria y procesadores ms rpidos para levantar en memoria grandes volmenes de datos del almacn de datos y procesar mas rpidamente las consultas. Estimar el Tamao de una base de datos Al disear una base de datos, usted podra necesitar estimar cun grande ser la base de datos cuando este llena de informacin. Estimar el tamao de la base de datos puede ayudarle a determinar la configuracin del hardware que usted necesitar para alcanzar los siguientes requisitos: Lograr el rendimiento requerido por sus aplicaciones Asegurar la cantidad fsica apropiada de espacio en disco para guardar los datos y ndices Estimar el tamao de una base de datos tambin puede llevarlo a determinar si el diseo de la base de datos necesita mayor refinamiento. Por ejemplo, usted podra determinar que el tamao estimado de la base de datos es demasiado grande para ser implementada en su organizacin y que requiere mayor normalizacin. Recprocamente, el tamao estimado podra ser ms pequeo que el esperado, permitiendo denormalizar en cierto grado la base de datos para mejorar el rendimiento de las consultas. Para estimar el tamao de una base de datos, estime el tamao de cada tabla individualmente y sume dichos valores. El tamao de una tabla depende si la tabla tiene o no ndices y, en este caso, qu tipo de ndices.

19-146 Diseo fsico de la base de datos El subsistema de entrada/salida (motor de almacenamiento) es un componente importante de cualquier base de datos relacional. Una aplicacin de base de datos exitosa normalmente requiere una planificacin cuidadosa en las fases tempranas de su proyecto. El motor de almacenamiento de una base de datos relacional requiere de esta planificacin que incluye a lo siguiente: Qu tipo de hardware de disco ser utilizado Cmo distribuye sus datos en los discos Qu diseo de ndices se va a utilizar para mejorar el rendimiento de las consultas. Cmo se van a configurar apropiadamente todos los parmetros de configuracin para que la base de datos funcione correctamente. Instalacin de SQL Server Aunque la instalacin de SQL Server est ms all del alcance de este Kit de Entrenamiento, usted siempre debe tener en cuenta lo siguiente antes de realizar una instalacin: Est seguro que la computadora rene los requisitos de sistema para SQL Server 2000. Haga copias de respaldo de su instalacin actual de Microsoft SQL Server si usted est instalando SQL Server 2000 en la misma computadora. Si usted est instalando un failover cluster, desactive el NetBIOS en todas las tarjetas de la red privada antes de ejecutar el instalador de SQL Server. Repase todas las opciones de instalacin de SQL Server y este preparado para hacer las selecciones apropiadas cuando ejecute el instalador. Si usted est usando un sistema operativo que tiene configuraciones regionales diferentes a ingls (Estados Unidos), o si usted est personalizando el juego de caracteres o la configuracin del ordenamiento de los caracteres, revise los temas referidos a la configuracin de colecciones. Antes de ejecutar el instalador de SQL Server 2000, cree uno o ms cuentas de usuario del dominio si usted est instalando SQL Server 2000 en una computadora con Windows NT o Windows 2000 y quiere que SQL Server 2000 se comunique con otros clientes y servidores. Usted debe iniciar el sistema operativo bajo una cuenta de usuario que tiene permisos locales de administrador; por otra parte, usted debe asignar los permisos apropiados a la cuenta de usuario de dominio. Est seguro de cerrar todos los servicios dependientes sobre SQL Server (incluso cualquier servicio que usa ODBC, como el Internet Information Server, o IIS). Adems, cierre al Windows NT Event Viewer y a los visualizadores de la registry (Regedit.exe o Regedt32.exe). Seguridad Una base de datos debe tener un sistema de seguridad slido para controlar las actividades que pueden realizarse y determinar qu informacin puede verse y cul puede modificarse. Un sistema de seguridad slido asegura la proteccin de datos, sin tener en cuenta cmo los usuarios obtienen el acceso a la base de datos. Planificar la Seguridad Un plan de seguridad identifica qu usuarios pueden ver qu datos y qu actividades pueden realizar en la base de datos. Usted debe seguir siguientes los pasos para desarrollar un plan de seguridad: Liste todas los items y actividades en la base de datos que debe controlarse a travs de la seguridad. Identifique los individuos y grupos en la compaa. Combine las dos listas para identificar qu usuarios pueden ver qu conjuntos de datos y qu actividades pueden realizar sobre la base de datos. Niveles de seguridad Un usuario atraviesa dos fases de seguridad al trabajar en SQL Server: la autenticacin y autorizacin (aprobacin de los permisos). La fase de la autenticacin identifica al usuario que est usando una cuenta

20-146 de inicio de sesin y verifica slo su capacidad para conectarse a un instancia de SQL Server. Si la autenticacin tiene xito, el usuario se conecta a una instancia de SQL Server. El usuario necesita entonces permisos para acceder a las bases de datos en el servidor, lo que se obtiene concediendo acceso a una cuenta en cada base de datos (asociadas al inicio de sesin del usuario). La validacin de los permisos permite controlar las actividades que el usuario puede realizar en la base de datos SQL Server. Modos de autenticacin El SQL Server puede operar en uno de dos modos de seguridad (autenticacin): la Autenticacin de Windows y el modo Mixto. El modo de Autenticacin de Windows le permite a un usuario que se conecte a travs de una cuenta de usuario Windows NT 4.0 o Windows 2000. El modo mixto (Autenticacin de Windows y Autenticacin de SQL) le permite a los usuarios que conecten a una instancia de SQL Server usando Autenticacin de Windows o Autenticacin de SQL Server. Los usuarios que se conectan a travs de una cuenta del usuario Windows NT 4.0 o Windows 2000 pueden hacer uso de conexiones de confianza en el modo de Autenticacin de Windows o en el modo mixto. Resumen del tema Al disear una base de datos SQL Server, se deben tener en cuenta varios factores, que incluyen los archivos de la base de datos y grupos de archivos, registros de transacciones, la instalacin del SQL Server y su ambiente operativo, y la seguridad. Todos los datos y objetos de la base de datos, como tablas, procedimientos almacenados, desencadenadores, y vistas, se guardan dentro de los archivos primario, secundarios, dentro del registro de transacciones. Los grupos de archivos agrupan archivos para propsitos administrativos y de ubicacin de los datos. El grupo de archivos que contiene el archivo primario es el grupo de archivos primario. Una base de datos en SQL Server 2000 tiene al menos un archivo de datos y un archivo de registro de transacciones. Datos y la informacin del registro de transacciones nunca se mezclan en el mismo archivo, y los archivos individuales son utilizados por solo una base de datos. El SQL Server usa el registro de transacciones de cada base de datos para recuperar transacciones. El diseo de la base de datos siempre debe tomar en consideracin la velocidad de procesador, la memoria, y el espacio del disco duro y su configuracin. Hay otros factores determinantes, sin embargo: el nmero de usuarios o sesiones coexistentes, el registro de transacciones, y los tipos de operaciones a realizar sobre la base de datos Al disear una base de datos, usted podra necesitar estimar cun grande ser la base de datos cuando este llena de informacin. Al instalar SQL Server, usted debe tener en cuenta varios problemas. Una base de datos debe tener un sistema de seguridad slido para controlar las actividades que pueden o no realizarse y determinar qu informacin puede verse y cul puede modificarse. Un diseo de seguridad identifica qu usuarios pueden ver qu datos y qu actividades pueden realizar sobre la base de datos.

MODULO I Tema 4: Identificar los requerimientos de diseoLo que aprender: Al terminar este tema usted podr: Identificar las metas y el alcance de un proyecto de base de datos. Identificar los tipos de datos que manejar la base de datos, la cantidad actual de datos, el crecimiento esperado, y cmo se usan actualmente. Identificar cmo se usarn los datos en la nueva base de datos. Identificar cualquier regla comercial que se utilizar en el sistema.

21-146 El Proceso de Identificar los Requerimientos de diseo El proceso de identificar los requerimientos del sistema incluye una variedad de pasos. El nmero de pasos incluidos en este proceso, cmo estos pasos se definen, y la forma en que ellos se definen puede variar grandemente de recurso a recurso (sin que un mtodo sea necesariamente es el ms correcto). Segn el propsito de este kit de entrenamiento, este proceso ha sido dividido en cuatro tareas primarias: Identificar la metas del sistema Identificar la cantidad y los tipos de datos Identificar cmo se usarn los datos Identificar las reglas comerciales Usted necesariamente no tiene que realizar esta una tarea por vez. Por ejemplo, mientras identifica la cantidad y los tipos de datos, usted podra determinar cmo se usarn los datos y qu restricciones deben asociarse a dichos datos. La Figura 4.1 ilustra el proceso de identificar los requerimientos de diseo.

Figure 4.1 Identificar los requerimientos del sistema. Identificar las Metas del Sistema Disear una base de datos requiere de un entendiendo de las funciones comerciales que usted quiere soportar. Tanto como sea posible, su diseo de la base de datos debe modelar el negocio con precisin. Es significativamente costoso en tiempo tratar de cambiar el diseo de una base de datos una vez que se ha implementado. Una base de datos bien diseada obtiene el mayor rendimiento. Al disear una base de datos, usted debe considerar el propsito de la base de datos y cmo este afecta el diseo. En otras palabras, usted debe determinar las metas del nuevo sistema. Por qu est creando usted esta base de datos? Las metas del sistema son las razones por las qu usted est implementando la nueva base de datos. Para crear un diseo de base de datos eficaz, usted debe tener conocimiento completo y profundo del trabajo que se espera que la base de datos haga. Sin esta comprensin, usted no puede tomar decisiones informadas sobre cmo la base de datos debe ser diseada. Determinar las metas del sistema no siempre es un proceso directo. La mayora de los proyectos de desarrollo de bases de datos tienen muchas metas (tangibles e intangibles), y intentar descubrirlos puede tomar a menudo una cantidad importante de trabajo de investigacin. Por ejemplo, una compaa industrial podra decidir automatizar su proceso de administracin de inventario. Uno de las metas declaradas de la compaa para el proyecto es "para hacer mas fcil manejar el inventario."

22-146 Su trabajo es tomar esta meta intangible y intentar determinar la meta tangible subyacente. Quiere la compaa acelerar el proceso de administracin del inventario? Quiere rastrear inventario ms con precisin? Quiere reducir costos? La meta intangible de "hacindolo ms fcil" podra incluir todos stas metas ms tangibles y algunas otras. Aunque estas metas son ms tangibles, ellas todava son vagas. Las metas vagas tienden a ser declaradas trminos generales, como "aumento de productividad" o "mejora del rendimiento" Cuando usted pasa por el proceso de identificar metas, usted debe determinar el grado al que estas metas deben lograrse. Si la meta es aumentar productividad, usted debe intentar determinar el grado en que esas metas deben lograrse. Siempre que sea posible, sus metas deben ser directamente mensurables. Usted debe ser consciente, sin embargo, de los peligros que se presentan al medir ciertas metas. A menudo para determinar una meta mensurable, usted debe poder establecer una medida inicial. Por ejemplo, si una meta de la base de datos de inventario es mejorar la exactitud, podra consumir muchos recursos estudiar cunta inexactitud existe en el proceso actual. Un estudio de esta clase podra abarcar aos de historia del inventario y quizs podra costar ms que disear e implementar cabo la base de datos. En casos como stos, podra ser mejor hablar primero con gerentes y tenedores de libros para lograr un sentido general de donde estn los problemas y lo que puede hacerse para resolverlos. Al determinar que hasta que punto una medida base debe ser estudiada, usted debe tener presente la balanza del proyecto y su aplicacin prctica manteniendo siempre un sentido de proporcin. A veces, las metas intangibles pueden ser difciles de traducir en metas ms tangibles. Esta situacin es particularmente cierta para metas que adoptan la jerga del mercadeo popular. Por ejemplo, la meta declarada podra ser algo que no parece tener ningn significado o relevancia: "Nosotros queremos el nuevo sistema para mostrar a nuestros clientes que estamos pensando de manera innovadora y siguiendo la tendencia de ellos, para as mejorar el posicionamiento del producto." En estos casos, usted debe trabajar estrechamente con la organizacin para definir eso claramente que significan las metas declaradas. Despus de que usted ha definido las metas iniciales para la nueva base de datos, usted puede continuar determinando el tipo y la cantidad de datos que el sistema soportar. Sin embargo, cuando usted avance con el proceso de diseo de la base de datos, deber estar preparado para reevaluar estas metas. Cuando los proyectos avanzan, la direccin cambia, los requerimientos comerciales cambian, y se revisan las expectativas de la compaa. Como resultado, las metas evolucionan, lo cual significa que el diseo de la base de datos podra necesitar ser modificado. Usted tambin podra descubrir, cuando usted excava ms profundamente en el proyecto, que algunas metas son inalcanzables o impropias. Dado que surgen nuevas comprensiones y nueva informacin a ser administrada, usted debe prepararse a actuar de acuerdo con esto. Identificar la Cantidad y Tipos de Datos La cantidad y tipos de datos que su base de datos guardar pueden afectar el rendimiento de la base de datos y debe tenerse en cuenta al crear su base de datos. La cantidad de datos, por supuesto, afecta el tamao de su base de datos, y los tipos de datos son un factor que determina los tipos de restricciones que se incorporarn al diseo de la base de datos. En muchos casos, determinar la cantidad y tipos de datos es un proceso directo porque un sistema antiguo ya se encuentra funcionando y usted simplemente est actualizando o reemplazando ese sistema. En estas situaciones, usted puede examinar el cuerpo de datos que ya existen. En los casos en los que usted est llevando a cabo un nuevo sistema, o uno que radicalmente altera el trabajo, su labor podra ser un poco ms difcil porque podra tener que gastar una importante cantidad de tiempo en determina qu tipos de datos se guardarn y cunto datos habr. Usted podra necesitar entrevistar a los participantes importantes y coleccionar copias de documentos pertinentes y formas, como facturas de venta, los listados de inventario, los informes de direccin, y cualquier otro documento que est usndose actualmente.

23-146 Usted debe determinar el volumen de datos que el sistema manejar. Cuando examine el volumen de datos, debe identificar la cantidad actual de datos y su modelo de crecimiento. Por ejemplo, un almacn podra llevar slo unos mil artculos actualmente, pero podra estar planeando agregar varios centenar al da durante los prximos aos para aumentar la artculos disponibles en el stock. Otro almacn podra llevar millones de artculos pero podra planear agregar slo unos nuevos artculos al da y nunca permitir que el inventario vaya mucho ms all de su capacidad actual. Los modelos de crecimiento para estos dos sistemas son muy diferentes, y como resultado, el diseo variar. Al mirar los tipos de datos, usted est bsicamente intentando conseguir un sentido general de las categoras de informacin que usted estar guardando y qu detalles sobre las categoras son necesarios guardar. Este proceso lo preparar por exponer las entidades y atributos que usted incorporar en su diseo de la base de datos. Por ejemplo, si usted est desarrollando una base de datos para un minorista de la ropa, los tipos de datos podran incluir informacin sobre clientes que compran productos de la tienda. La informacin del cliente podra incluir nombres, direcciones, nmeros de telfono, y incluso las preferencias de estilo. A estas alturas en el proceso del diseo, usted no tiene que ponerse demasiado especfico sobre cmo deben categorizarse los datos o deben agruparse. Usted est intentando ganar un sentido general de los tipos de datos involucrados y creando una lista centralizada para esos tipos de datos. Cuando usted empiece a identificar realmente los objetos de la base de datos, usted tomar la informacin que recogi aqu y la usar para desarrollar un modelo de datos. Identificar Cmo se usarn los Datos Cuando usted recoge los requerimientos del sistema, usted debe determinar cmo se usar la informacin en su base de datos. El propsito de este paso es identificar quin estar usando los datos, el nmero de usuarios que estarn accediendo a los datos, y las tareas que ellos estarn realizando cuando accedan ese datos. Al determinar quin estar usando los datos, usted debe pensar en trminos de categoras de usuarios. Por ejemplo, una categora de usuarios podra ser el pblico general (quin accede a los datos a travs del Internet). Usted tambin podra tener otra categora de usuarios que acceden datos a travs del intranet de la compaa. Algunas organizaciones podran tener slo un tipo de usuario, mientras otras organizaciones podran tener muchos tipos. No hay ningn mnimo fijo o nmero del mximo de usuarios que cada categora debe contener. Las nicas limitaciones son aquellas dictadas por configuraciones del hardware y diseo de la base de datos. Una categora podra contener a slo un usuario, mientras otra categora podra contener a 100.000 usuarios. Cuando usted determina quin estar usando los datos, usted tambin debe identificar cuntos usuarios en cada categora estarn accediendo a los datos. Esta estimacin no slo debe incluir los nmeros actuales pero los valores proyectados, tambin. Adems, usted tendr que definir la concurrencia de los usuarios. Usted debe saber que cuntas personas se conectarn a la vez a la base de datos y cuntos podra estar intentando actualizar simultneamente la base de datos. Una vez que ha definido quines y cuntos son sus usuarios, usted debe identificar las tareas que ellos estarn realizando cuando acceden a la base de datos. Por ejemplo, suponga que una compaa industrial incluye una categora de usuarios que toman rdenes de clientes. Este grupo de tomadores de ordenes deben poder acceder y actualizar informacin del cliente. Adems, deben poder ver los datos del inventario para hacer los pedidos. La compaa tambin podra incluir una categora de usuarios de recursos humanos. El grupo de recursos humano debe poder ver y actualizar informacin del empleado. Identificando estas tareas, usted puede determinar cmo ser accedida la base de datos y cmo se vern y manipularn los datos. Cuando usted combina esta informacin con el nmero y tipo de usuarios, usted podr llevar a cabo un diseo de la base de datos que satisface las necesidades de todos en la organizacin. Identificar las Reglas Comerciales del Sistema

24-146 Al identificar las reglas comerciales, usted est determinando las restricciones que gobiernan cmo deben manejarse y protegerse los datos y el sistema. Estas restricciones se refieren van ms all que la integridad individual de los atributos de la entidad. Las reglas comerciales son mucho ms amplias e incorporan todas las restricciones del sistema, incluidas la integridad de los datos y la seguridad del sistema. En otras palabras, usted est definiendo lo que cada categora de usuarios puede o no puede hacer. Volviendo al ejemplo de la compaa industrial, el grupo de tomadores de rdenes pueden acceder y actualizar registros de los clientes y ver los datos de inventario. Sin embargo, usted podra determinar que estos usuarios no deben poder actualizar datos del inventario y no deben poder ver datos de los empleados. Usted tambin podra determinar que ningn archivo del cliente puede crearse sin que se complete la direccin de envo y el nmero de telfono. Otra restriccin podra ser que cualquier artculo agregado a un orden del cliente debe quitarse del inventario. Las reglas comerciales pueden incluir un amplio espectro de restricciones, algunas que pertenecen en conjunto al sistema y otras que pertenecen a los tipos especficos de datos. Resumen del tema Antes de que usted pueda desarrollar a un modelo del datos, usted debe identificar las metas de su proyecto de base de datos, el tipo y cantidad de datos con los que usted estar trabajando, cmo se usarn esos datos, y cualquier restriccin comercial que deber existir sobre los datos. Usted debe considerar el propsito de la base de datos y cmo afecta el diseo. Usted debe tener una comprensin clara de por qu usted est creando esta base de datos. Otra rea de preocupacin cuando se estn identificando los requerimientos del sistema es la cantidad y tipo de datos que su base de datos almacenar. Cualquier sea el sistema actual, usted debe determinar el volumen de datos que el sistema manejar. Cuando examina el volumen de los datos, usted debe determinar la cantidad real de datos y su modelo de crecimiento. Al mirar los tipos de datos, usted est intentando conseguir un sentido general de las categoras de informacin que bsicamente se estarn guardando y qu detalles sobre las categoras son necesarios guardar. Cuando usted recoge requerimientos del sistema, usted debe identificar quin estar usando los datos, el nmero de usuarios que estarn accediendo a los datos, y las tareas que ellos estarn realizando sobre esos datos. Al identificar las restricciones sobre los datos, usted estar determinando las reglas comerciales que gobiernan cmo deben manejarse y protegerse los datos. Las reglas comerciales incluyen tanto la integridad de los datos as como la seguridad del sistema. Ellos le permiten definir lo que cada categora de usuarios puede y no puede hacer.

MODULO I Tema 5: Desarrollar el Modelo Lgico de DatosLo que aprender: Al terminar este tema usted podr: Identificar entidades y sus atributos. Identificar relaciones entre las entidades. Definir restricciones en los datos. Identificar Entidades y Sus Atributos Cuando se recogen los requisitos del sistema para al diseo de la base de datos, uno de los pasos que se realizan es el de definir los tipos de datos que contendr la base de datos. Pueden separarse estos tipos de datos en categoras que representan una divisin lgica de informacin. En la mayora de los casos, cada categora de tipo de dato se traduce en un objeto tabla dentro de la base de datos. Hay normalmente, un conjunto de objetos primarios, y despus de que ellos son identificados, surgen los objetos relacionados.

25-146 Por ejemplo, en la base de datos Editores, uno de los objetos primarios es la tabla Titulos. Uno de los objetos relacionado a la tabla Ttulos es la tabla de RoyAgenda que proporciona informacin sobre la agenda de royalties asociada con cada libro. Otro objeto es la tabla TituloAutor que vincula a los autores con los libros. Usando las categoras de datos definidas en los requisitos del sistema, se puede empezar a crear un mapa del objeto tabla dentro de la nueva base de datos. Por ejemplo, suponga que usted est diseando una base de datos para el sistema de reservaciones de un hotel. Durante el proceso de recoleccin de requisitos de sistema, identifica varias categoras de datos, incluido los cuartos, huspedes, y reservaciones. Como resultado, agrega tablas a su diseo de la base de datos que representan a cada una de estas categoras, como se muestra en la Figura 5.1.

Figura 5.1 Los objetos primarios en un diseo de la base de datos: la tabla Habitaciones, la tabla Reservas, y la tabla Huespedes. Al identificar las reglas comerciales para este sistema, usted determin que el hotel tiene ocho tipos de cuartos y que los huspedes regulares prefieren un cierto tipo de cuarto. Como resultado, tanto la tabla Habitaciones como la tabla Huespedes debern incluir un atributo de tipo de cuarto. Usted decide crear una tabla para los tipos del cuarto, como se muestra en Figura 5.2.

Figura 5.2 La base de datos de reservaciones del hotel que incluye la tabla de TipoHab. Ahora, la tabla Habitaciones y la tabla Huespedes referencian a la tabla TipoHab sin tener que repetir una descripcin del cuarto para cada cuarto y cada husped. Adems, ante un cambio en los tipos de cuarto, usted puede actualizar la informacin en un solo lugar, en lugar de tener que actualizar mltiples tablas y archivos. Antes de que usted pueda completar el proceso de definir objetos de la tabla dentro de la base de datos, debe definir las relaciones entre las tablas. Siempre que identifique una relacin muchos-a-muchos, tendr que agregar una tabla de unin. Se discuten relaciones con ms detalle adelante en este tema. Despus de que usted ha definido todas las tablas que puede definir a estas alturas, puede definir las columnas (atributos) para esas tablas. De nuevo, usted estar tomando esta informacin directamente de los requisitos del sistema en los que identific qu tipos de datos deben ser incluidos en cada categora de informacin.

26-146 Usando el ejemplo de base de datos del hotel, suponga que determin durante el proceso de recoleccin de requisitos del sistema que la categora Huespedes debe incluir informacin la siguiente informacin sobre los huspedes: nombre, apellido, direccin, nmero de telfono, y preferencias del cuarto. Como resultado, usted planea agregar columnas a la tabla de los Huespedes para cada uno de estos tipos de informacin. Usted tambin planea agregar un identificador nico para cada husped, tal como con cualquier entidad normalizada. La Figura 5.3 muestra la tabla Huespedes con todas las columnas que contendr la tabla.

Figura 5.3 La tabla Huespedes y sus atributos. Identificar Relaciones Entre las Entidades Despus de que ha definido las tablas y sus columnas, usted debe definir las relaciones entre las tablas. A travs de este proceso, podra descubrir que necesita modificar el diseo que ha creado. Empiece escogiendo una de las tablas primarias y seleccionando las entidades que tienen relaciones con esa tabla. Siguiendo con el ejemplo del hotel, asuma que los requisitos del sistema indican que todas las reservaciones deben incluir cuarto e informacin del husped. Los cuartos, huspedes, y reservaciones son las categoras de datos. Como resultado, usted puede deducir que una relacin existe entre los cuartos y reservaciones y entre los huspedes y reservaciones. La Figura 5.4 muestras las relaciones entre estos objetos. Una lnea que conecta las dos tablas significa una relacin. Advierta que una relacin tambin existe entre la tabla Habitaciones y la tabla TipoHab y entre la tabla Huespedes y la tabla TipoHab.

Figura 5.4 Las relaciones que existen entre las tablas en la base de datos de las reservaciones del hotel.

27-146 Una vez que establece que una relacin existe entre las tablas, usted debe definir el tipo de relacin. En la Figura 5.4, cada relacin (lnea) es marcada a cada extremo (donde conecta a una tabla) con el nmero 1 o con un smbolo de infinito (8). El 1 se refiere al lado uno de una relacin, y el smbolo de infinito se refiere al lado muchos de una relacin uno-a-muchos. Algunos autores tambin las llaman relaciones 1:N. Para determinar los tipos de relaciones que existen entre las tablas, usted debe mirar los tipos de datos que cada tabla contiene y los tipos de conexiones entre ellos. Por ejemplo, una relacin existe entre la tabla Huespedes y la tabla Reservas. La relacin existe porque los huspedes son parte de la informacin que se recaba cuando se registra una reservacin. Segn las reglas comerciales, un husped puede hacer una o ms reservaciones, pero cada reservacin grabada puede incluir solo el nombre de un husped, normalmente la persona que est haciendo la reservacin. Como resultado, una relacin uno-a-muchos existe entre las dos tablas: un husped, una o muchas reservaciones. Una relacin tambin existe entre la tabla Reservas y la tabla Habitaciones. Segn las reglas comerciales, una reservacin puede solicitar uno o ms cuartos, y un cuarto puede ser incluido en una o ms reservaciones (en fechas diferentes). En este caso, existe una relacin muchos-a-muchos: muchas reservaciones a muchos cuartos. En un diseo de base de datos normalizado, sin embargo, relaciones muchos-a-muchos deben ser modificadas agregando una tabla de unin y creando una relacin uno-amuchos entre cada tabla original y la tabla de unin, como se muestra en la Figura 5.5.

Figura 5.5 La tabla de HabReservas como tabla de unin entre la tabla Habitaciones y la tabla Reservas. Identificar Restricciones sobre los Datos A estas alturas del proceso de diseo de la base de datos, usted debera tener definidas las entidades, sus atributos, y las relaciones entre entidades. Ahora, usted debe identificar las restricciones sobre los datos que se guardarn en las tablas. El mayor trabajo ya fue completado cuando usted identific las reglas comerciales al momento de recoger los requisitos del sistema. Como se vio, las reglas comerciales incluyen todo las restricciones en un sistema, incluida la integridad de los datos y la seguridad del sistema. Para esta fase del proceso de diseo, su enfoque se centrar en las restricciones sobre los datos. Usted tomar las reglas comerciales relacionadas a los datos y las refinar y organizar. Debe intentar organizar las restricciones en base a los objetos que cre en la base de datos, y formularlas de modo que se refieran a ellos. Volviendo al diseo de la base de datos de la Figura 5.5, suponga que una de las reglas comerciales indica: "Un registro de husped puede, pero no es obligatorio, incluir una preferencia por uno de los tipos de cuarto predefinidos pero no puede incluir ninguna otra preferencia de tipo de cuarto." Al definir las

28-146 restricciones sobre los datos, usted debe referenciar las tablas y columnas pertinentes y dividir la regla comercial de modo que cada restriccin est contenida en una instruccin simple: La columna de TipoHabID en la tabla Huespedes no requiere un valor. Todo valor distinto de NULL en la columna de TipoHabID en la tabla Huespedes debe ser un valor incluido en la columna de TipoHabID en la tabla de TipoHab. Una fila en la tabla de los Huespedes puede incluir slo un valor en la columna de TipoHabID. En cuanto sea posible, usted debe organizar las restricciones sobre los datos segn las tablas y sus columnas. En algunos casos, una restriccin se aplica al conjunto de una tabla, a ms de una tabla, a una relacin entre las tablas, o a la seguridad de los datos. En estos casos, intente organizar las restricciones de modo que sea lgica y ms pertinente al proyecto. La meta de identificar las restricciones sobre los datos es tener un mapa claro del camino para cuando se creen los objetos de la base de datos y sus relaciones que fuerce la integridad de los datos

MODULO I Ejercicio 2: Desarrolle un Modelo Lgico de DatosEn este ejercicio, usted se entrenar en los pasos necesarios para crear un modelo lgico de datos. Este ejercicio involucra dibujar las tablas, entidades, y relaciones entre entidades que constituyen la base de datos. Aunque usted puede usar un programa del dibujo como Visio para crear estos objetos; papel y un lpiz es todo que usted realmente necesita. Si lo desea, usted puede transferir luego su modelo a un programa del dibujo. Adems, usted necesitar papel y un lpiz para escribir las restricciones a los datos. Tambin puede escribirlos directamente en un documento de un procesador de palabras. Cualquiera que sea el mtodo que usted escoja, deber guardar el resultado para los ejercicios subsecuentes. Para realizar este ejercicio, usted usar el caso de la tienda de libros de Ejercicio 1 del Tema 4 de este mdulo. Para identificar qu tablas agregar a una base de datos 1. Refirase a los requisitos de diseo que usted desarroll para el caso de la tienda de libros y apunte las categoras de datos. Cada categora representa uno de los objetos tabla primarios en su diseo de la base de datos. 2. Dibuje una tabla para cada categora de datos. Las tablas deben ser lo suficientemente grandes para que usted pueda agregar los nombres de las columnas. Ponga las tablas en un modo que le permita dibujar las relaciones entre las tablas. Usted agregar los nombres de la columna y definir las relaciones mas adelante en este ejercicio. Su dibujo debera incluir cinco tablas. 3. Etiquete cada tabla con el nombre de cada una de las categoras. Para consistencia, use las etiquetas siguientes para los nombres de las tablas: Libros, Autores, Empleados, Clientes, y Ordenes. Su prximo paso ser identificar cualquier tabla relacionada. A estas alturas, disear una base de datos se pone un poco ms complicado. Una buena fuente para determinar las relaciones entre tablas es la lista de reglas comerciales que usted identific cuando usted recogi los requisitos de diseo. Esencialmente, usted est buscando subcategoras de informacin o reglas de negocio que lo llevan a creer que son necesarias tablas adicionales. Recuerde, usted puede modificar el diseo de la base de datos cuando usted identifica relaciones entre tablas y restricciones sobre los datos. 4. Refirase a las reglas comerciales en los requisitos de diseo. Fjese que hay cuatro subcategoras de informacin: la condicin de un libro, la posicin del empleado, la forma de pago, y el estado de la orden.

29-146 5. Dibuje las cuatro tablas relacionadas para soportar las tablas primarias. Para consistencia, use los nombres siguientes para sus nuevas tablas: EstadoOrden, FormaDePago, Posiciones, y CondicionLibro. 6. Refirase a las reglas comerciales en los requisitos de diseo. Fjese que una orden puede contener ms de un libro. 7. Agregue una tabla ms (OrdenLibros) para rastrear los libros pedidos y las rdenes tomadas a los clientes. Usted ahora debera tener 10 tablas. Para identificar qu columnas agregar a las tablas 1. Refirase a los requisitos de diseo que usted desarroll para el caso de la tienda de libro. Para cada categora de datos, usted defini qu informacin debe ser incluida en cada categora. Esta informacin constituye sus columnas. 2. Agregue nombres a las columnas de cada tabla. Tambin recuerde que cada fila en una tabla debe ser singularmente identificable, por lo que algunas tablas podran necesitar un identificador. Adems, en donde los nombres de las columnas se refirieran a informacin en una tabla relacionada, usted normalmente slo necesitar la columna del identificador de la tabla relacionada. Por ejemplo, la tabla Ordenes incluira una columna de EstadoID que la referencia a la tabla de EstadoOrden. Para consistencia, use las etiquetas siguientes para los nombres de las columnas: Tabla Libros LibrosEstado Autores Empleados Posiciones Clientes Ordenes EstadoOrden FormaDePago LibrosOrdenes Columnas LibroID, Titulo, AutorID, Editor, FechaEd, Costo, CondicioID, Vendido CondicionID, NombreCond, Descripcion AutorID, Apellido, Nombre, AoNac, AoMuerte, Descripcion EmpleadosID, Nombre, Apellido, Dir1, Dir2, Ciudad, Estado, CP, FechaIng, PosicionID PosicionID, Cargo, Descripcion ClienteID, Nombre, Apellido, Telefono, Dir1, Dir2, Ciudad, Estado, CP OrdenID, ClienteID, EmpleadoID, Monto, FechaOrden, FechaEnvio, PagoID, EstadoID EstadoID, EstadoDescrip PagoID, PagoDescrip OrdenID, LibroID

Fjese que la tabla Clientes no incluye una columna para los libros comprados y fecha de compra. Dado que cada cliente puede comprar ms de un libro, usted no incluir esta informacin aqu. Usted podra crear una tabla para guardar esta informacin, pero sera innecesario porque reproducira informacin que ya existe en la base de datos (informacin que puede derivarse a travs de vistas o consultas). Para identificar relaciones entre las entidades 1. Determine qu relaciones existen entre la tabla Libros y otras tablas en la base de datos. Si necesita, refirase al caso de la tienda de libro y a los requisitos de diseo que lo ayudarn a determinar qu relaciones existen entre los objetos.

30-146 Usted est buscando relaciones directas. Por ejemplo, la tabla Libros tiene una relacin directa con la tabla LibrosEstado. Los datos de LibrosEstado aplica directamente a los datos de Libros. Adems, los datos de Autores se relacionan directamente con los datos de Libros (los autores escriben libros). Hay tambin una relacin directa entre los datos de Libros y los datos LibrosOrdenes (los rdenes incluyen los libros que se venden). Fjese, que no hay ninguna relacin directa entre las tablas Libros y la tabla Ordenes. La relacin entre las dos tablas es indirecta y se expresa a travs de la tabla de LibrosOrdenes. 2. Para cada tabla, trace una lnea desde esa tabla a cualquier otra tabla con la que exista una relacin. Usted podra encontrar que necesita mover algunas de sus tablas para mostrar esas relaciones ms claramente. Su diseo de la base de datos debe parecer similar al esquema en Figura 5.6.

Figura 5.6 Identificar las relaciones entre las tablas en el modelo de lgico datos.

31-146 3. Determine si cada relacin es uno-a-uno, uno-a-muchos, o muchos-a-muchos. Escriba el nmero 1 en el extremo "uno" de la relacin, y escriba el smbolo infinito (8) en el extremo "muchos" de la relacin. Para determinar el tipo de relacin, piense en los trminos de los datos asociados con cada objeto. Por ejemplo, existe una relacin entre los empleados y los rdenes que ellos generan. Un empleado puede crear muchos rdenes, pero una orden es creada por slo un empleado. Por consiguiente, una relacin uno-a-muchos existe entre la tabla Ordenes y la tabla Empleados (un empleado puede crear muchas rdenes). La tabla Empleados est en el lado "uno" de la relacin, y la tabla Ordenes en el lado "muchos". Su base de datos debe parecer similar ahora al esquema en Figura 5.7.

Figura 5.7 Identificar los tipos de relaciones entre las tablas en el modelo de los datos lgico. 4. Identifique las relaciones muchos-a-muchas en el diseo de la base de datos. Qu relaciones son muchos-a-muchos?

32-146 5. Cree que una tabla de la unin llamada LibrosAutores. La tabla debe incluir la columna de AutorID y la columna de LibroID. 6. Anule la relacin entre la tabla Libros y la tabla Autores, entonces anule la columna de AutorID en la tabla Libros. Usted est anulando la relacin entre las dos tablas porque una relacin directa ya no existe. En cambio, una relacin indirecta se crea a travs de la tabla de LibrosAutores. Adems, la columna AutorID no es mas un requisito en la tabla Libros porque la relacin libro/autor se expresa en la tabla LibrosAutores. 7. Dibuje la relacin entre los Autores y tablas LibrosAutores y la relacin entre los Libros y tablas LibrosAutores. 8. Determine los tipos de relaciones que existen con la tabla LibrosAutores. Su diseo de la base de datos debe parecer similar ahora al esquema en Figura 5.8.

33-146 Figura 5.8 Agregar la tabla de LibrosAutores al modelo de datos lgico. Para identificar restricciones en los datos 1. En una hoja de papel, apunte los nombres de cada tabla en su diseo de base de datos. Deje espacio suficiente entre cada nombre de la tabla para escribir las restricciones de los datos. 2. Repase la regla comercial que declara que informacin del libro se debe incluir: ttulo, autor, costo, precio sugerido, evaluacin, y ID nico. 3. Identifique el objeto al que esta regla de negocio se aplica. A qu objecto/s aplica esta regla de negocio? 4. Bajo los nombre de la tabla Libros y de la tabla LibrosAutores, escriba las restricciones a los datos que se pueden derivar de la regla comercial. Cules son las restricciones a los datos? 5. Para cada regla comercial, defina las restriccin a los datos. Donde sea aplicable, escriba las restricciones bajo el nombre de la tabla. Si una restriccin no es aplicable especficamente a una tabla, escrbalo en otro espacio en su papel. Cules son las restricciones a los datos para su diseo de la base de datos? 6. Repase las restricciones a los datos que usted cre para asegurarse que cada tabla y cada columna dentro de esas tablas tienen alguna clase de regla asociada con l.

MODULO II: Implementar una base de datos y sus tablas Tema 1: Crear y administrar una base de datos SQLServerEl primer paso para implementar fsicamente una base de datos es crear los objetos de la base de datos. Usando la informacin que obtuvo cuando se determinaron los requerimientos de diseo, y los detalles que identific en el diseo lgico de la base de datos, Ud. puede crear los objetos de la base de datos y definir sus caractersticas. Podr modificar estas caractersticas despus que haya creado los objetos de la base de datos. Cuando cree una base de datos, deber primero definir su nombre, su tamao, y los archivos y grupos de archivos usados para soportarla. Deber considerar varios factores antes de crear la base de datos: Por defecto solo tienen permiso para crear bases de datos los miembros de los roles sysadmin y dbcreator, Ud. podra no tener asignados ninguno de dichos roles pero an contar con la autorizacin para crear bases de datos en caso que el administrador se los hubiera otorgado. El usuario que crea una base de datos se convierte en el dueo de la base de datos Un mximo de 32.767 bases de datos pueden ser creadas sobre un servidor. El nombre de la base de datos debe seguir las reglas de los identificadores.

34-146 Como ya indicamos, se usan tres tipos de archivos para almacenar una base de datos: archivos primarios, que contienen la informacin de arranque para la base de datos; archivos secundarios, que hospedan a todos los datos que no caben en el archivo primario; y registro de transacciones, que contienen la informacin de la transacciones, usadas para recuperar la base de datos. Toda base de datos tiene al menos dos archivos: un archivo primario y un registro de transacciones. Cuando se crea una base de datos, los archivos se llenan de ceros para sobrescribir cualquier otro dato que archivos que han sido borrados puedan haber dejado en el disco. Aunque esto significa que los archivos pueden tardar en ser creados, esta accin evita al sistema operativo tener que llenar con cero los archivos al momento de la efectiva grabacin de los datos durante la normal operacin de la base de datos, mejorando la performance operacional de cada da. Cuando Ud. crea una base de datos, deber especificar el tamao mximo que un archivo tiene autorizado a alcanzar. Esto previene que el archivo crezca, cuando los datos son ingresados, hasta que el espacio en disco se termine. SQLServer implementa una nueva base de datos en dos pasos: SQLServer usa una copia de la base de datos Model para inicializar la nueva base de datos y sus metadatos. SQLServer luego llena el resto de la base de datos con pginas vacas (excepto aquellas pginas que tienen grabados datos internos como el espacio usado)

Cualquier objeto definido por el usuario en la base de datos Model es copiado a todas las bases de datos que sean creadas. Se pueden agregar objetos a la base de datos Model, tales como tablas, vistas, procedimientos almacenados, tipos de datos, etc. que sern incluidos en las nuevas bases de datos. Adems, cada nueva base de datos hereda la configuracin de la opciones de la base de datos Model.

Mtodos para crear una base de datos SQLServerSQLServer provee muchos mtodos que se pueden utilizar para crear bases de datos: el comando Transact-SQL CREATE DATABASE, el rbol de la consola del Enterprise Manager, y el asistente Create Database , al cual puede acceder a travs del SQL Server Enterprise Manager. El comando CREATE DATABASE Se puede usar el comando CREATE DATABASE para crear una base de datos y los archivos almacenados en una base de datos. El comando CREATE DATABASE le permitir especificar una serie de parmetros que definirn las caractersticas de la base de datos. Por ejemplo, se puede especificar el mximo tamao que puede alcanzar un archivo o el incremento que puede experimentar dicho archivo. Si slo utiliza CREATE DATABASE nombre_de_la_base_de_datos la base de datos es creada del mismo tamao de la base de datos Model. El comando puede ser ejecutado desde el SQL Query Analizer. El siguiente ejemplo crea una base de datos llamadas Productos y especifica que se usar un solo archivo. El archivo especificado ser el archivo primario, y un archivo de registro de 1Mb se crea automticamente. Dado que ni megabytes (Mb) ni kilobytes (Kb) son especificados en el parmetro SIZE para el archivo primario, el archivo ser generado en megabytes. Adems, al no consignarse una especificacin de archivo para para el archivo de transacciones, el archivo de transacciones no tendr un tamao mximo (MAXSIZE) y podr crecer hasta ocupar todo el espacio en el disco.

35-146 USE master GO CREATE DATABASE Productos ON ( NAME = prods.dat, FILENAME = c:\program files\Microsoft SQL server\mssql\data\prods.mdf, SIZE = 4, MAXSIZE = 10, FILEGROWTH = 1 ) GO Usar el Enterprise Manager Se puede crear una base de datos directamente utilizando la herramienta SQL Server Enterprise Manager. Para crear una base de datos en el Enterprise Manager, expanda la consola del rbol de su servidor, haga clic derecho en el nodo Database, y haga clic en New Database. Cuando el cuadro de propiedades aparezca, modifique los valores por defecto como sea necesario en orden a crear la nueva base de datos. La figura muestra el cuadro de dilogo Database Properties cuando este se abre por primera vez. El asistente Create Database El asistente Create Database lo lleva a travs de una serie de pasos necesarios para para crear una nueva base de datos. Se accede al asistente seleccionando Wizards desde el men Tools. Desde all se debern completar los pasos que presenta el asistente. En la Figura se muestran varias opciones que pueden ser modificadas cuando se ejecuta el asistente.

36-146

Figura 1: La pestaa General del cuadro de dilogo Database Properties para una nueva base de datos

Administrar una base de datos SQL Server Una vez que se ha creado la nueva base de datos, Ud. podr ver informacin acerca de dicha base de datos, modificar sus caractersticas o eliminar la base de datos. Ver informacin referida a la base de datos Se puede ver la definicin de la base de datos y sus opciones de configuracin en casos de problemas de funcionamiento o cuando se considere necesario realizar cambios en la base de datos. SQL Server provee diferentes mtodos que se pueden utilizar para ver informacin acerca de la base de datos: el procedimiento almacenado sp_helpd