administracion de base de datos sql server 2012

INSTITUTO SUPERIOR TECNOLOGICO PRIVADO SAN PEDRO

SILABO DE ADMINISTRACIN DE BASE DE DATOS

DATOS GENERALES:1.1. Carrera Profesional : Computacin e Informtica1.2. Curso: Administracin de Base de Datos1.3. Total Horas: 1.4. Semestre Acadmico: 5 Semestre1.6. Perodo Lectivo: 2015 - I1.7. Docente: Himbher Lutgher LAZO SAAVEDRA1.8. E-mail: himblutgher@gmail.com rehgtul@hotmail.com

II. SUMILLA:

En este curso se tratara los fundamentos de la Administracin de Base de Datos en Access y SQL Server 2012, con la capacidad de analizar, disear y seguridad de una base de datos.

III. COMPETENCIA GENERAL DE LA CARRERA:

El profesional de la carrera de Computacin e Informtica estar en la capacidad de administrar aplicaciones para el desarrollo de programas, redes y dirigir proyectos de soluciones de problemas con la implementacin de Tecnologas de la Informacin.

IV. COMPETENCIA GENERAL DE LA ASIGNATURA

El alumno estar en la capacidad de analizar, disear, implementar y brindar seguridad a las base de datos, donde tendr un conocimiento solido de la asignatura, tener conocimientos sobre las normalizaciones de que debe de tener una base de datos, diseo e implementacin de la base de datos con la realizacin de consultas SQL TRANSACT y polticas de seguridad.

V. ORGANIZACIN DE ACTIVIDADES Y CONTENIDO BASICOSSemana

CAPACIDADACTIVIDADES DE APRENDIZAJECONTENIDO BASICOS

1Entender los Fundamentos y Diseo de Base de Datos.Fundamentos de Base de Datos y Modelo de Entidad Relacin Sistema de Administracin de Base de Datos.

2 Caractersticas y funciones.

3 Niveles de Arquitectura.

4 Ciclo de Vida de un Sistema de Informacin.

5

6Entender las fases de Normalizacin de una base de datosNormalizacin Formas normales de bases de datos.

7 Conjunto de operaciones en relaciones.

8 Modificacin de Base de Datos.

9

10Crear y gestionar las polticas de Usuarios.Gestin de Usuarios y esquemas de Seguridad Autenticacin.

11 Roles y funciones.

12 Validacin d Permisos.

13 Gestin de copias de seguridad.

14

15Crear y modificar los procedimientos almacenadosGestin de Procedimientos Almacenados y Disparadores Procedimientos Almacenados.

16 Uso de Parmetros.

17 Restaurar base de datos.

18

VI. METODOLOGIA

La metodologa ser en el aula de una forma audio visual, con ejemplos y casos de base de datos que podra situarse en el campo real, ser tanto practico como terico.

VII. EVALUACION

La evaluacin ser constante, cada da se evaluara para entender el nivel de aprendizaje de los alumnos.

VIII. RECURSOS BIBLIOGRAFICOS Microsoft SQL Server 2008 Step by Step Programacin y Administracin de Base de Datos. URL: http://msdn.microsoft.com/es-es/library/hh231622.aspx http://www.microsoftvirtualacademy.com/training-courses/sql-server-2008-r2

Huancayo, 02 Enero de 2015

..Eco. Juan Bautista Privat GmezDIRECTOR

Ing. Patricia Quispe VillanesDIRECTORA ACADEMICA

....

DOCENTE

ADMINISTRACIN DE BASE DE DATOS

FUNDAMENTOS DE BASE DE DATOSSISTEMA ADMINISTRACIN DE BASE DE DATOSIntroduccinEn la poca actual, la informacin y su tratamiento automatizado no solo son necesaria para el eficiente funcionamiento de toda organizacin, sino que se ha convertido en uno de los principales elementos de competitividad. En este contexto, el almacenamiento de la informacin (en forma de datos) y su disponibilidad para las aplicaciones de negocio se hace indispensable para la normal operacin y funcionamiento de cualquier empresa. El personal que opera las diferentes aplicaciones rutinarias interacta con la Base de Datos.La gerencia, que evala y controla la eficiencia de estas operaciones tambin requerir de informacin, de manera de planificar nuevas tareas y/o corregir aquellas que no vayan con la estrategia de negocio planteada. A su vez, las personas que decidan las estrategias de negocio (nuevos mercados, nuevas lneas de negocio, simple supervivencia, etc.) tambin requieren informacin para toma de decisiones. Se dice que el principal activo de una organizacin es su persona.Entonces podra decirse que el segundo en importancia seria su informacin, aunque probablemente y en muchos casos esta ltima sea ms difcil de reemplazar que le primero.Ya sea que la base de datos sea usada para apoyar alguno de los niveles organizacionales comentados o todos, debe elegirse la tecnologa adecuada que garantice su permanente y eficiente disponibilidad, as como que facilite el desarrollo de aplicaciones y la administracin de la base de datos misma por parte del personal de aplicaciones del rea de sistemas de la organizacin.DatoDefinicin de dato encontrada en un diccionario: Dato: Antecedente que permite llegar mas fcilmente al conocimiento de una cosa. Pequeo LarousseEl dato es la representacin de un mensaje.Entonces la definicin se da de un contexto donde existe comunicacin: Entre persona. Entre un objeto y persona(s). Entre objetos.El dato, al ser una representacin (que tendr que ser interpretada) contiene caractersticas de objetividad. En el caso de ser personas las que interpreten un dato, existir la posibilidad de subjetividad al momento de la interpretacin (conclusin de la informacin).InformacinInformacin: significado percibido al recibir un mensaje. La percepcin humana es, por naturaleza, subjetiva. Por lo tanto la informacin referida a un mismo dato tendr la posibilidad de ser resultado de varias interpretaciones.Si se tienen varias persona que interpretaran un mismo dato o conjunto de datos, deber existir un acuerdo para la forma de interpretarlos (obtener el significado o informacin). Para la obtencin de informacin es necesario un proceso: El proceso mental de interpretacin o un proceso automatizado que de forma y significado a los datos accedidos en algn medio. Otro aspecto importante es que muchas veces el hecho de contar con ms datos o con datos colaterales al estrictamente requerido permite un mejor proceso para la obtencin de informacin. Otra definicin: Informacin, es el grado de disminucin de la incertidumbre sobre algo.Base de DatosUna base de datos es un conjunto de datos organizados de tal manera que pueda extraerse informacin.En esta definicin general no se hace mencin al medo donde residirn los datos ni la forma o tecnologa de acceso a los mismos.Muchas veces el solo hecho de cambiar de medio de almacenamiento (como en el ejemplo mostrado) obliga a un mnimo de organizacin. La organizacin de los datos persigue el objetivo que estos puedan ser compartidos por varios usuarios.Sistema de Administracin de Base de DatosDBMS por sus siglas en Ingles (DataBase Management System). Software que administra el acceso a los datos, permitiendo su almacenamiento, consulta y actualizacin. Tiene la capacidad de responder a mltiples usuarios accediendo en forma concurrente a los dato. Provee facilidades para la administracin del conjunto como toma de respaldos y recuperacin.El DBMS permite tener los datos de toda la organizacin (incluida la informacin de sus principales entidades) de forma integrada, de manera que estos se encuentren disponibles a consultas o actualizaciones de transacciones realizadas por el personal de la empresa, clientes de la misma, a travs de aplicaciones de un sistema de informacin o directamente a travs de un lenguaje que sea comprendido por el DBMS.Este lenguaje, en el caso de bases de datos relacionales (RBDMS) es el SQL, que se vera mas adelante. El lenguaje no solo debe de permitir la comunicacin para acceder los datos, sino par definirlos. Actualmente los software RBDMS se encuentran en diversas plataformas, aunque son desarrollados para arquitecturas tanto mainframe como cliente/servidor (tema tocado mas adelante) corriendo en el back end (host o servidor) usando la infraestructura de red disponible para la comunicacin con los usuarios.

CARACTERISTICAS Y FUNCIONES RELACIONADAS DE LOS DBMSs

EscalabilidadCapacidad de mejorar con el incremento de recursos invertidos (generalmente los recursos pueden medirse en dinero). Un DBMS debe de permitir inversin de recursos de medida que se requiera mayores y/o mejores servicios de la base de datos. Esta situacin generalmente se presenta para un mejor aprovechamiento de los sistemas de informacin, por crecimiento del negocio/organizacin, u otros factores.

RendimientoCaractersticas de realizar las tareas involucradas como de recuperacin de datos, actualizacin, respuesta a la concurrencia de muchos usuarios, etc., de una manera eficiente. Sin embargo el rendimiento de un DBMS depende de otros factores como la plataforma donde corre.

PortabilidadCaracterstica de permitir transportar de una manera transparente o fcil un producto de una plataforma a otra. En el caso de los DBMS, no solo es la consideracin de portabilidad del producto (el software mismo) sino los datos que la base de datos administra.

UniversalidadSe refiere a los mltiples tipos de datos que puede manejar un DBMS, los que actualmente se denominan datos multimedia.

Disponibilidad (Permanente e ininterrumpida)Actualmente es uno de los factores cruciales, pues el servicio de base de datos apoya a las aplicaciones crticas de la operativa de los negocios.

Escalabilidad HorizontalCapacidad de incrementar la cantidad de usuarios de la base de datos o la cantidad de estaciones con conexin a base de datos. Una de las diferencias entre los gestores de base de datos para microcomputadora y DBMS para servidores es precisamente la capacidad de los segundos para escalar horizontalmente. Generalmente el costo de licencia de un DBMS est relacionado con la cantidad de usuarios concurrentes. Es as que si bien un producto particular puede proveer esta facilidad, existir un costo asociado.

Escalabilidad VerticalCapacidad para incrementar el tamao y/o la potencia del servidor y as obtener mejoras con mismo producto.Tres Niveles de Arquitectura de DatosEl Nivel ExternoTambin llamado nivel de visin o subesquemas (segn Martin) es el nivel ms cercano al usuario final, o sea es la forma como estos perciben los datos. Generalmente a un usuario le interesa solo una parte de toda la base de datos y no le interesa los aspectos tcnicos deseando solo indicar QUE datos son los que requiere.El Nivel ConceptualTambin llamado Esquema (J. Martin) describe la totalidad de los datos de la base de datos. En este nivel interesa CUALES son los datos necesarios, as como las relaciones entre estos. Este nivel es visible a usuarios profesionales de S.I., desarrolladores y por supuesto al DA.Nivel InternoTambin llamado nivel fsico, describe CMO son almacenados los datos en la base de datos. Una parte de este nivel debe de ser visible el DBA y totalmente visible a quienes desarrollan software del tipo DBMSs. En este nivel es importante el conocimiento (visibilidad) del ambiente operativo donde correr el software BDMS.Cliente/ServidorEs la actual arquitectura para sistemas con bases de datos basada en la distribucin de aplicaciones y/o datos en una red de computadoras, conocido por sus siglas C/S, tambin es sinnimo de computacin abierta que permite utilizacin de hardware variado, sin dependencia de un solo proveedor.Tipos de Servidores Servidor de ArchivosEl cliente (tpicamente una PC) requiere archivos a travs de la red. Se requier mucho intercambio de mensajes. De utilidad para repositorios de diferentes tipos de archivos como documentos, imgenes, etc. Servidor de Base de DatosEl cliente enva requerimientos en SQL, la consulta u operacin asociada es ejecutada por el software (DBMS) que corre el servidor devolviendo los resultados y/o cdigo de error correspondientes. Es en el mismo equipo servidor donde se encuentran almacenados los datos. Monitor de TransaccionesEl cliente invoca procedimientos (mdulos) almacenados en el servidor, que se componen de varias sentencias SQL todas las cuales sern exitosas o fracasaran como una sola unidad (transaccin). Esta funcionalidad (de procedimientos almacenados) es provista por productos DBMS modernos (como por ejemplo el DB2 y IBM) sin embargo para la funcin del control minucioso de transacciones en ambientes fuertemente concurrentes (sistemas OLTP), existe software especializado denominado monitores de transacciones. GroupwareEste tipo de servidores manejan informacin semi estructurada como texto, imgenes, correo boletines y el flujo de trabajos (workflow). Lotus Notes es el lder mundial en este tipo de software. Servidor de ObjetosLas aplicaciones son escritas como un conjunto de objetos que se comunican. Los objetos del cliente se comunican con los del servidor a travs de ORBs (Object Request Brokers). Servidor WebLos clientes se comunican a travs de protocolo HTTP para que el servidor provea los requerimientos correspondientes (un documento HTML por ejemplo).Tipos de aplicacionesLas aplicaciones cliente/servidor tambin pueden ser clasificadas (diferenciadas) de acuerdo a como es distribuido el proceso entre el cliente y el servidor. El cliente ligero (o servidor pesado) distribuye ms funciones en el lado del servidor. Bajo este esquema se trata de minimizar el trfico entre el cliente y servidor (trfico en la red) creando ms abstractos de servicios. El cliente pesado (o servidor ligero) distribuye ms funciones en el lado del cliente.En los casos de servidores de archivos o servidores de bases de datos sin uso de procedimientos almacenados, el trabajo de la aplicacin es concentrado en el cliente (front-end), donde no solo se realizaran las funciones de interaccin y presentando (interfaz al usuario) sino el procesamiento de los datos que son extrados del servidor).Modelos de Distribucin Cliente/ServidorNo existe una regla para dividir una aplicacin, sin embargo es razonable situar las funciones y datos cerca posibles para la operativa de la organizacin. Esto sin embargo tiene su contra, pues es mejor el enfoque centralizado, desde el punto de vista de la administracin de los datos. Si bien puede hacer una amplia gana de combinaciones para distribuir la lgica de una aplicacin, puede simplificarse la explicacin a tres:

Presentacin distribuidaLa lgica de presentacin de los datos es remota respecto a la (lgica) de negocio y datos. En su forma ms simple la lgica de presentacin es solo la interfaz al usuario que accede a procedimientos transaccionales ya existentes en el servidor. La lgica de presentacin pueda ir engordando con funciones de consistencia de datos, iniciacin de lgica de negocio, etc.

Funciones DistribuidasModelo que proporciona gran flexibilidad y permite un control donde situar las funciones en la red. Un proceso cliente invoca a otro proceso en el servidor (en el mismo equipo u otro remoto), este servidor (de aplicaciones) puede invocar a su vez los servicios de otro servidor, hasta el proceso de los datos requeridos y su evolucin a la cadena de clientes que fuera formndose.Datos DistribuidosSolo los resultados son devueltos al proceso cliente que invoco al servidor de base de datos. Los servidores de bases de datos son la base fundamental de los sistemas de soporte a decisiones que requieren preguntas no planificadas e informes flexibles.Compontes de la Arquitectura Cliente/ServidorEL CLIENTEEn el cliente corre la parte de la aplicacin correspondiente. Lo hace en el sistema operativo, que a su vez provee la interfaz usuario (U.I) hace ya buen tiempo grafica (GUI) u orientada a objetos (OOUI) y puede acceder diferentes servicios distribuidos.Para acceder a servicios distribuidos lo hace a travs del componente middleware, quien maneja los servicios que no son locales. En el cliente tambin corre un componente del middleware de administracin de sistemas distribuidos (DSM).

EL SERVIDOREl componente de aplicacin en el servidor generalmente corre sobre un software para la correspondiente plataforma (del servidor): un DBMS con SQL, un monitor de transacciones, groupware, servidores de objetos y el web. Depende del S.O. para interfazar con el componente middleware que hace los requerimientos de servicios. Tambin corre un componente del DSM.

EL MIDDLEWAREEl componente middleware corre tanto en el cliente como el servidor. Se puede clasificar en tres categoras de middleware:1. El software (o mejor dicho los protocolos) de transporteProvee comunicacin a travs de WANs y LANs y por supuesto la necesaria combinacin LAN/WAN/LAN. Estos protocolos vienen como drivers en los sistemas operativos modernos, los que proveen interfaces muy bien definidas entre componentes de manera de llegar desde las aplicaciones hasta los adaptadores de red.2. El sistema operativo de redAunque el trmino de red ya prcticamente quedo en el pasado, pues los sistemas operativos ofrecen la funcionalidad son usadas en un ambiente cliente servidor tales como servicios de directorio, comparticin de recursos, seguridad, etc. Facilidades para internet/intranet son proporcionadas tambin por los sistemas operativos.3. Servicios especficosTambin deben de correr en ambos lados, cliente y servidor, de manera de proveer la funcionalidad necesaria como por ejemplo acceso y recuperacin de datos de una base de datos, correo electrnico, brokers de objetos y otros.

MODELO DE ENTIDAD RELACININTRODUCCINA finales de la dcada de 1960, cuando las bases de datos entraron por primera vez en el mercado de software, los diseadores de software actuaban como artesanos, con herramientas muy primitivas: diagramas de bloques y estructuras de registros y el diseo de Base de Datos se confunda frecuentemente con la implantacin de la base de datos. Dicha situacin ahora ha cambiado: los mtodos y los modelos del diseo de batos han evolucionado paralelamente con el progreso de la tecnologa en los sistemas de base de datos. Asimismo el diseo de la Base de Datos es una actividad esencial en el desarrollo de Sistemas de Informacin.EL diseo de la base de datos en el ciclo de vida de los sistemas de informacinLas bases de Datos son solo uno de los componentes de los sistemas de informacin, que tambin incluyen programas de aplicacin, interfaces para usuarios y otro tipo de paquetes de software. Sin embargo, las bases de datos son esenciales para la supervivencia de cualquier organizacin, porque los datos estructurados constituyen un recurso esencial para todas las organizaciones.El tpico ciclo de vida de un sistema de informacin consiste en:1. Estudio de Factibilidad: Trata de determinar la rentabilidad de las distintas alternativas de diseo de sistemas de informacin y las prioridades de los diversos componentes del sistema.2. Recoleccin y anlisis de requerimientos: Se ocupa de la misin del sistema de informacin, es decir las reas de aplicacin del sistema dentro de una empresa y los problemas a resolver. Los usuarios describen sus necesidades a los diseadores y esas descripciones se le conoce como especificando de requerimientos.3. Diseo: Se ocupa de la especificacin de la estructura del sistema de Informacin. Se distingue el diseo de la base de datos (estructura de la BD) y el diseo de las aplicaciones (programas de aplicacin).4. Creacin de Prototipos: El prototipo permite a los usuarios verificar si el sistema de informacin satisface las necesidades.5. Implantacin: Se refiere a la programacin de la versin final y operativa del sistema de informacin.6. Validacin y Prueba: Procedimiento mediante el cual se garantiza que cada fase del desarrollo es de calidad aceptable.7. Operacin: Se empieza con la carga inicial de los datos y termina cuando el sistema se vuelve obsoleto y tiene que ser reemplazado, adems se necesita mantenimiento para mejorarlo.Fase del diseo de la base de datosEl diseo de la Base de Datos se descompone en diseo conceptual, diseo lgico y diseo fsico como muestra la figura:

1. Recoleccin y anlisis de Requerimiento: Los diseadores entrevistan a los futuros usuarios de la base de datos para recoger y documentar sus necesidades de informacin.2. Diseo Conceptual: Parte de la especificacin de todos los requerimientos, el siguiente paso es crear el 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 (informacin de la base de datos), y contiene descripciones de los usuarios (informacin de la base de datos), y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones. Para el curso utilizaremos diseo de esquemas conceptuales el modelo E-R (Entidad Relacin), que describe los datos como entidades, vnculos (relaciones) y atributos.3. 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 los datos empleados4. Diseo fsico de la base de datos: Parte del esquema lgico y produce como resultado el esquema fsico. El esquema fsico especifica las estructuras de almacenamiento internas y los mtodos usados para tener un acceso efectivo a los datos. Por esta razn el diseo fsico se adapta a un sistema DBMS especfico.El Modelo Entidad-RelacinEn 1976 Peter Chen publica The Entity Relationship Model to Ward a unified view of data. Este modelo diferencia a los objetos, de quienes representamos datos, en entidades y relaciones, aadiendo semntica y sencillez grfica. Para disear y planificar bases de datos, el modelo Entidad Relacin es el que ha tenido mayor xito en la industria de la Ingeniera de Software. La mayora de herramientas que apoyan la Ingeniera de Software y el desarrollo de sistemas de informacin (CASEs) han adoptado algn modelo.

ENTIDADLas entidades representancosasuobjetos(ya sean reales o abstractos), que se diferencian claramente entre s.Para poder seguir un ejemplo durante el artculo aadir ejemplos sobre un taller mecnico, donde se podra crear las siguientes entidades: Coches(objeto fsico): contiene la informacin de cada taller. Empleado(objetofsico): informacin de los trabajadores. Cargo del empleado(cosaabstracta): informacin de la funcin del empleado.Estas entidades se representan en un diagrama con unos rectngulos, como los siguientes.Cargo del EmpleadoEmpleadoCoche

ATRIBUTOLos atributos definen o identifican las caractersticas de entidad (es el contenido de esta entidad). Cada entidad contiene distintos atributos, que dan informacin sobre esta entidad. Estos atributos pueden ser de distintos tipos (numricos, texto, fecha).Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad Coches, que nos darn informacin sobre los coches de nuestro supuesto taller.Unos posibles atributos seran los siguientes:nmero de chasis,matrcula,DNIdel propietario,marca, modeloy muchos otros que complementen la informacin de cada coche.Los atributos se representan como crculos que descienden de una entidad, y no es necesario representarlos todos, sino los ms significativos, como a continuacin.

RELACINEs un vnculo que nos permite definir una dependencia entre varias entidades, es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma indispensable.Por ejemplo, los empleados del taller (de la entidad Empleados) tienen un cargo (segn la entidad Cargo del empleado). Es decir, un atributo de la entidad Empleados especificar que cargo tiene en el taller, y tiene que ser idntico al que ya existe en la entidad Cargo del empleado.Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante lneas.RELACIONES DE CARDINALIDADPodemos encontrar distintos tipos de relaciones segn como participen en ellas las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir varios empleados.Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada extremo de la relacin que especifica cuantosobjetosocosas(de cada entidad) pueden intervenir en esa relacin.Uno a uno: Una entidad se relaciona nicamente con otra y viceversa. Por ejemplo, si tuvisemos una entidad con distintos chasis y otra con matrculas deberamos de determinar que cada chasis solo puede tener una matrcula (y cada matrcula un chasis, ni ms en ningn caso).

Uno a variosovarios a uno: determina que un registro de una entidad puede estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior del trabajador del taller.

Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecnicos distintos y esos mecnicos pueden reparar varios coches distintos.

Los indicadores numricos indican el primero el nmero mnimo de registros en una relacin y posteriormente el mximo (si no hay lmite se representa con una n).CLAVESEs el atributo de una entidad, al que le aplicamos una restriccin que lo distingue de los dems registros (no permitiendo que el atributo especfico se repita en la entidad) o le aplica un vnculo (exactamente como comentbamos en las relaciones). Estos son los distintos tipos:Superclave: aplica una clave o restriccin a varios atributos de la entidad, para as asegurarse que en su conjunto no se repitan varias veces y as no poder entrar en dudas al querer identificar un registro.Clave primaria: identifica inequvocamente un solo atributo no permitiendo que se repita en la misma entidad. Como sera la matrcula o el nmero de chasis de un coche (no puede existir dos veces el mismo).Clave externaoclave fornea: este campo tiene que estar estrictamente relacionado con la clave primaria de otra entidad, para as exigir que exista previamente ese clave. Anteriormente hemos hablado de ello cuando comentbamos que un empleado indispensablemente tiene que tener un cargo (que lo hemos representado numricamente), por lo cual si intentsemos darle un cargo inexistente el gestor de bases de datos nos devolvera un error.Nuestro gestor de BBDDsin la necesidad de crear un gran diagrama, sino usando notas ms simplesMODELO RELACIONALEl Modelo Relacional fue propuesto por E.Codd en 1970 ( E. Codd era entonces un investigador del Centro de IBM en San Jos (California ) y public su propuesta en un artculo fundamental que obtuvo el ACM Award correspondiente al Congreso VLDB de 1970 ) .La estructura subyacente bsica es la relacin, entendida en su acepcin matemtica bsica: Un subconjunto de un producto cartesiano de conjuntos. Cuando se pretende describir una parcela de la realidad mediante el formalismo relacional, el primer paso es discernir los atributos presentes en el problema. Un atributo es un tem elemental de informacin, en el sentido de no poder desglosarse en componentes ms simples. Los atributos son los nombres que damos a las propiedades de los objetos acerca de los cuales se va a guardar informacin.

NOMBREEDADSEXO

Jhon SmithSally BoyceTony StarkBill BallucciTina Graver1923183419VarnMujerVarnVarnMujer

En la relacin Estudiante tiene tres atributos (NOMBRE, EDAD, SEXO) y cinco tuplas, cada una representando nombre, edad y sexo de un estudiante. Por tanto el grado y la cardinalidad de ESTUDIANTE son tres y cinco, respectivamente: las definiciones matemticas de las relaciones se desarrolla empezando por la nocin de dominios. Un dominio es una coleccin de valores. Dados varios atributos, A1, A2,, An, con subdominios D1, D2, , Dn un caso de relacin de grado n es simplemente un sub conjunto del producto cartesiano D1 x D2 Dn. Esta definicin destaca una importante propiedad de las relaciones, a saber, que son conjuntos de tuplas en el sentido matemtico: una relacin en ningn momento puede tener tuplas duplicadas. Sin embargo, la mayora de los sistemas relacionales no imponen una restriccin, ya que en diversas situaciones pueden ocurrir duplicados y puede ser til mantenerlos.Claves Primarias y Forneas (externas) Llave Principal: Columna(s) que contendr(n) valores para identificar de manera nica al objeto representado por la tupla. El valor de la llave primaria en cada fila identifica al objeto particular representado por cada fila dentro de la clase de objetos que representa esa relacin. Llave Fornea: Columna(s) que contiene(n) los valores de un dominio que sirven al mismo de la llave primaria en otra(s) tabla(s) para identificar al mismo objeto. Una caracterstica fundamental del modelo relacional es que la representacin de las relaciones entre objetos del mundo real se hace por comparacin entre valores, sirvan estos para identificar a los objetos o para describir atributos de los mismos. Las relaciones entre clases de objetos (conjuntos de objetos del mismo tipo) estn expresadas en trminos de los atributos comunes de las instancias de las clases relacionadas (no solo con el mismo dominio, sino con el mismo significado). En el modelo relacional, el concepto de clave est definido de una manera muy similar al concepto de identificador ene l modelo ER; una clave de una relacin es un conjunto de atributos de la relacin que identifica de manera nica cada tupla de cada expresin de esa relacin. As, la nica diferencia entre nuestro uso de identificadores y claves es que en el modelo relacional solo se acepta la identificacin interna.

NORMALIZACIN

INTRODUCCIN

Una vez creada el diseo de la base de datos, debemos analizarla para asegurarnos de que carece de problemas potenciales. Para ello, seguiremos un proceso llamado normalizacin, en el que identificamos la existencia de problemas potenciales como duplicacin y redundancia de datos, e implantaremos maneras de corregir esos problemas.

El objetivo de la normalizacin es convertir las relaciones no normalizadas (tablas que satisfacen la definicin de una relacin pero que pueden contener grupos repetidos) en varios tipos de formas normalizadas. Una tabla de una forma normalizada en concreto posee un determinado y deseable conjunto de propiedades. Aunque hay varias formas normalizadas, las ms comunes son la primera forma normalizada, la segunda forma normalizada y la tercera forma normalizada. La normalizacin es un proceso en el que una tabla que est en primera forma normalizada, es mejor que una tabla que no est en primera forma normalizada, una tabla en segunda forma normalizada es mejor que otra que est en primera forma normalizada, y as sucesivamente. El objetivo de este proceso es permitirnos obtener una tabla o conjunto de tablas y producir un nuevo conjunto de tablas que representa la misma informacin pero que carece de problemas.

PRIMERA FORMA NORMALIZADA

De acuerdo con la definicin de una relacin, una relacin (tabla) no puede contener un grupo repetido en el que existan mltiples entradas en una sola fila. Sin embargo, en el proceso de diseo de base de datos, podemos crear una tabla que tenga todo el resto de propiedades de una relacin, pero que contiene un grupo repetido. Eliminar grupos repetidos es el punto de partida para convertir un conjunto de datos no normalizados en una tabla que est en primera forma normalizada. Una tabla (relacin) est en primera forma normalizada (1NF) cuando no contiene un grupo repetido.

Por ejemplo, en el proceso de diseo, podemos crear la siguiente tabla tPedido, en la que hay un grupo repetido que consiste en codiArti y cantiArti. La formulacin para esta tabla es as: tPedido (codiPedi, fechaPedi, (codiArti, cantiArti))

esta formulacin describe una tabla llamada tPedido que consiste en una clave principal, codiPedi, y una columna llamada fechaPedi. El parntesis interior indica un grupo repetido que contiene dos columnas: codiArti y cantiArti. Esta tabla contiene una fila por pedido con valores en las columnas codiArti y cantiArti para cada pedido con el cdigo codiPedi y situado en fechaPedi. En la figura 2.7 vemos un pedido sencillo con mltiples combinaciones de cdigo de artculo y el correspondiente nmero de unidades pedidas. tPedidocodiPedi fechaPedi codiArti cantiArti

21608 10/20/2010 AT94 11

21610 10/20/2010 DR93 DW11 1 1

21613 10/21/2010 KL62 4

21614 10/21/2010 KT03 2

21617 10/23/2010 BV06 CD52 2 4

21619 10/23/2010 DR93 1

21623 10/23/2010 KV29 2

Figura 2.7. Datos de pedido no normalizado.Para convertir la tabla en primera forma normalizada, eliminamos el grupo repetido de esta manera: tPedido (codiPedi, fechaPedi, codiArti, cantiArti)

En la figura 2.8 vemos la tabla en primera forma normalizada. En la figura 2.7, la segunda fila indica que el artculo DR93 y el artculo DW11 estn incluidos en el pedido 21610. En la figura 2.8 esta informacin est representada por dos filas, la segunda y la tercera. La clave principal en la tabla tPedido no normalizada era la columna codiPedi solamente. La clave principal de la tabla normalizada es ahora la combinacin de las columnas codiPedi y codiArti.

Cuando convertimos una tabla no normalizada en una tabla en primera forma normalizada, la clave principal de la tabla en primera forma normalizada es normalmente la clave principal de la tabla no normalizada concatenada con la clave del grupo repetido, que es la columna del grupo repetido que diferencia una aparicin del grupo repetido de otra dentro de una fila determinada de la tabla. En la tabla tPedido, codiArti era la clave del grupo repetido y codiPedi la clave principal de la tabla. Al convertir los datos no normalizados en primera forma normalizada, la clave principal es ahora la concatenacin de las columnas codiPedi y codiArti. tPedido codiPedi fechaPedi codiArti cantiArti

21608 10/20/2010 AT94 11

21610 10/20/2010 DR93 1

21610 10/20/2010 DW11 1

21613 10/21/2010 KL62 4

21614 10/21/2010 KT03 2

21617 10/23/2010 BV06 2

21617 10/23/2010 CD52 4

21619 10/23/2010 DR93 1

21623 10/23/2010 KV29 2

Figura 2.8. Datos del pedido convertidos en primera forma normalizada.SEGUNDA FORMA NORMALIZADA La siguiente tabla tPedido est en primera forma normalizada, porque no contiene ningn grupo repetido. tPedido (codiPedi, fechaPedi, codiArti, descripArti, cantiArti, precioCoArti) La tabla contiene las siguientes dependencias funcionales: codiPedi fechaPedi codiArti descripArti codiPedi, codiArti cantiArti, precioCoArti Esta formulacin indica que codiPedi por s misma determina fechaPedi, y codiArti por s misma determina descripArti, pero necesita tanto un codiPedi como un codiArti para determinar la cantiArti o bien el precioCoArti. Considere el ejemplo de esta tabla que vemos en la figura 2.9. Aunque la tabla tPedido est en primera forma normalizada (porque no contiene grupos repetidos), existen problemas en ella que hacen necesario su reestructuracin. La descripcin de un artculo especfico, por ejemplo DR93, aparece dos veces en la tabla. Esta duplicacin (formalmente llamada redundancia) provoca varios problemas. Ocupa espacio intilmente, pero esto no es el problema ms grave. Los otros problemas se denominan anomalas de actualizacin, y se dividen en cuatro categoras: tPedidocodiPedi fechaPedi codiArti descripArti cantiArti precioCoArti

21608 10/20/2010 AT94 Iron 11 $21.95

21610 10/20/2010 DR93 Gas Range 1 $495.00

21610 10/20/2010 DW11 Washer 1 $399.99

21613 10/21/2010 KL62 Dryer 4 $329.95

21614 10/21/2010 KT03 Dishwasher 2 $595.00

21617 10/23/2010 BV06 Home Gym 2 $12.95

21617 10/23/2010 CD52 Microwave Oven 4 $150.00

21619 10/23/2010 DR93 Gas Range 1 $495.00

21623 10/23/2010 KV29 Treadmill 2 $325.99

Figura 2.9. Ejemplo de tabla tPedido.1. Actualizaciones: Si tenemos que cambiar la descripcin del artculo DR93, tenemos que hacerlo dos veces: una vez en cada una de las filas en que aparece el artculo DR93. Actualizar la descripcin del artculo ms de una vez hace que el proceso de actualizacin sea mucho ms pesado y lleve ms tiempo. 2. Datos inconsistentes: No hay nada en el diseo que impida que el artculo DR93 tenga dos descripciones diferentes en la base de datos. De hecho, si el artculo DR93 aparece en 20 filas de la tabla, este artculo puede llegar a tener 20 descripciones diferentes en la base de datos. 3. Adiciones: Cuando intentamos aadir un artculo nuevo y su descripcin a la base de datos, nos encontramos con un grave problema. Como la clave principal de la tabla tPedido consiste tanto en codiPedi como en codiArti, necesitamos valores para ambas columnas para aadir una fila nueva a la tabla. Si aadimos un artculo a la tabla que an no tenga ningn pedido, Qu ponemos como codiPedi? La nica solucin es crear un codiPedi ficticio y despus sustituirlo por el codiPedi real una vez se reciba realmente un pedido para este artculo. Esto no es una solucin aceptable. 4. Eliminaciones: Si eliminamos el pedido 21608 de la base de datos y es el nico pedido que contiene el artculo AT94, al eliminar el pedido tambin se elimina toda la informacin sobre el artculo AT94. Por ejemplo, ya no podramos saber que el artculo AT94 es una plancha.

Estos problemas aparecen porque tenemos una columna, descripArti, dependiente de solo una parte de la clave principal, codiArti, y no de toda la clave principal. Esta situacin lleva a la definicin de la segunda forma normalizada. La segunda forma normalizada representa una mejora sobre la primera forma normalizada porque elimina las anomalas de actualizacin en estas situaciones. Una tabla (relacin) est en segunda forma normalizada (2NF) cuando est en primera forma normalizada y no hay ninguna columna no-clave (es decir, una columna que no sea parte de la clave principal) que dependa de slo una parte de la clave principal.

Nota: Cuando la clave principal de una tabla contiene una sola columna, la tabla est automticamente en segunda forma normalizada.

Podemos identificar el problema fundamental con la tabla tPedido: no est en segunda forma normalizada. Aunque es importante identificar el problema, lo que necesitamos realmente es un mtodo para corregirlo, tenemos que poder convertir tablas en segunda forma normalizada. En primer lugar, tome el subconjunto del conjunto de columnas que conforman la clave principal y comience una nueva tabla con este subconjunto como su clave principal. Para la tabla tPedido, el nuevo diseo es: (codiPedi, (codiArti, (codiPedi, codiArti,

En segundo lugar, site cada una de las otras columnas con la clave principal adecuada, es decir, site cada una con el mnimo conjunto de columnas de que depende. Para la tabla tPedido, aada las nuevas columnas de esta manera:

(codiPedi, fechaPedi) (codiArti, descripArti) (codiPedi, codiArti, cantiArti, precioCoArti)

A cada una de estas nuevas tablas se le asigna un nombre descriptivo basado en el significado y contenido de la tabla, como tPedido, tArticulo y tDetallePedido. En la figura 2.10 vemos ejemplos de estas tablas. En la figura 2.10, al convertir la tabla original tPedido en una tabla tPedido, una tabla tArticulo y una tabla tDetallePedido elimina las anomalas de actualizacin. Slo aparece una descripcin una vez para cada artculo, por tanto no tenemos la redundancia que exista en el diseo original de la tabla. Al cambiar la descripcin del artculo DR93 de Gas Range a por ejemplo, Deluxe Range, ahora es un proceso muy sencillo que implica un solo cambio. Como la descripcin de un artculo aparece en un solo lugar, no es posible tener varias descripciones para un solo artculo en la base de datos al mismo tiempo. Para aadir un nuevo artculo y su descripcin, creamos una nueva fila en la tabla tArticulo, independientemente de si ese artculo tiene pedidos pendientes o actuales o no. Adems, al borrar el pedido 21680 no se borra el cdigo de artculo AT94 de la base de datos porque sigue existiendo en la tabla tArticulo. Por ltimo, no hemos perdido ninguna informacin al convertir la tabla tPedido en segunda forma normalizada. Podemos reconstruir los datos en la tabla original a partir de los datos de las nuevas tablas. tPedidocodiPedi fechaPedi codiArti descripArti cantiArti precioCoArti

21608 10/20/2010 AT94 Iron 11 $21.95

21610 10/20/2010 DR93 Gas Range 1 $495.00

21610 10/20/2010 DW11 Washer 1 $399.99

21613 10/21/2010 KL62 Dryer 4 $329.95

21614 10/21/2010 KT03 Dishwasher 2 $595.00

21617 10/23/2010 BV06 Home Gym 2 $12.95

21617 10/23/2010 CD52 Microwave Oven 4 $150.00

21619 10/23/2010 DR93 Gas Range 1 $495.00

21623 10/23/2010 KV29 Treadmill 2 $325.99

TERCERA FORMA NORMALIZADA

Pero an pueden surgir problemas en la segunda forma normalizada. Por ejemplo, imagine que crea la siguiente tabla tCliente:

tCliente (codiClien, nombreClien, balanClien, limiCreClien, codiVende, apeVende, nombreVende) Esta tabla tiene las siguientes dependencias funcionales:

codiClien nombreClien, balanClien, limiCreClien, codiVende, apeVende, nombreVende codiVende apeVende, nombreVende

codiClien determina a todo el resto de columnas. Adems, codiVende determina a apeVende y nombreVende. Cuando la clave principal de una tabla es una sola columna, la tabla est automticamente en segunda forma normalizada. (Si la tabla no estuviera en segunda forma normalizada, alguna columna sera dependiente de slo una parte de la clave principal, lo que es imposible cuando la clave principal es slo una columna.) As, la tabla tCliente est en segunda forma normalizada. Aunque esta tabla est en segunda forma normalizada, la figura 2.11 muestra que sigue padeciendo problemas de actualizacin similares a los identificados en la tabla tPedido de la figura 2.9. En la figura 2.11, el nombre del vendedor aparece muchas veces en la tabla. tClientecodi Clien nombreClien direcClien ciudad Clien balan Clien limiCre Clien codi Vende ape Vende nombre Vende

148 Als Appliance and Sport 2837 Greenway Fillmore $6550.00 $7500.00 20 Kaiser Valerie

282 Brookings Direct 3827 Devon Grove $431.50 $10000.00 35 Hull Richard

356 Fergusons 382 Wildwood Northfield $5785.00 $7500.00 65 Perez Juan

408 The Everything Shop 1828 Raven Crystal $5285.25 $5000.00 35 Hull Richard

462 Bargains Galore 3829 Central Grove $3412.00 $10000.00 65 Perez Juan

524 Klines 838 Ridgeland Fillmore $12762.00 $15000.00 20 Kaiser Valerie

608 Johnsons Department Store 372 Oxford Sheldon $2106.00 $10000.00 65 Perez Juan

687 Lees Sport and Appliance 282 Evergreen Altonville $2851.00 $5000.00 35 Hull Richard

725 Deerfields Four Seasons 282 Columbia Sheldon $248.00 $7500.00 35 Hull Richard

842 All Season 28 Lakeview Grove $8221.00 $7500.00 20 Kaiser Valerie

Figura 2.11. Ejemplo de la tabla tClienteLa redundancia de incluir un cdigo y nombre de vendedor en la tabla tCliente resulta en el mismo conjunto de problemas que existan en la tabla tPedido. Adems el problema del espacio, tenemos las siguientes anomalas de actualizacin. Actualizaciones: Cambiar el nombre de vendedor implica cambios en mltiples filas de la tabla. Datos inconsistentes: El diseo no impide mltiples repeticiones de nombres de vendedor en la base de datos. Por ejemplo, un vendedor podra representar a 20 clientes y su nombre podra estar metido de 20 maneras diferentes en la tabla. Adiciones: Para aadir el vendedor 87 (Emily Daniels) a la base de datos, debe representar al menos a un cliente. Si Emiliy an no representa a ningn cliente, no podemos registrar el hecho de que su nombre sea Emily Daniels o bien tenemos que crear un cliente ficticio para que ella lo represente, hasta que represente a un cliente real. Ninguna de esas soluciones es deseable. Eliminaciones: Si eliminamos a todos los clientes del vendedor 35 de la base de datos, tambin perderemos toda la informacin sobre el vendedor 35. Estas anomalas de actualizacin son debidas al hecho de que codiVende determina a apeVende y nombreVende, pero codiVende no es la clave principal. Como resultado, puede aparecer en muchas filas diferentes el mismo codiVende y en consecuencia el mismo apeVende y nombreVende. Hemos visto que las tablas en segunda forma normalizada representa una mejora sobre las tablas en primera forma normalizada, pero para eliminar problemas con las tablas en segunda forma normalizada, necesitamos una estrategia an mejor para crear tablas. La tercera forma normalizada proporciona esa estrategia. Sin embargo, antes de adelantarnos en la tercera forma normalizada, tenemos que familiarizarnos con el nombre especial que se da a cualquier columna que determina a otra columna (como codiVende en la tabla tCliente). Cualquier columna (o conjunto de columnas) que determina a otra columna se llama determinante. La clave principal de una tabla es un determinante. De hecho, por definicin, cualquier clave candidata es un determinante. (Recuerde que una clave candidata es una columna o conjunto de columnas que podran funcionar como clave principal.) En la figura 2.11, codiVende es un determinante, pero no es una clave candidata, y se es el problema. Una tabla est en tercera forma normalizada (3NF) cuando est en segunda forma normalizada y los nicos determinantes que contiene son claves candidatas. Nota: Esta definicin de la tercera forma normalizada no es la definicin original. Esta definicin ms reciente, que es preferible a la original, se suelo conocer como BCNF (Boyce-Codd Normal Form) cuando es importante hacer una distincin entre esta definicin y la original. En este text no hacemos tal distincin pero tomamos esta como la definicin de la tercera forma normalizada.

Ahora ya hemos identificado el problema con la tabla tCliente: no est en tercera forma normalizada. Hay varios pasos para convertir tablas en tercera forma normalizada. En primer lugar, para cada determinante que no es una clave candidata, elimine de la tabla las columnas que dependen de este determinante (pero no elimine el determinante). Despus, cree una nueva tabla con todas las columnas a partir de la tabla original que dependen de este determinante. Por ltimo, haga del determinante la clave principal de esta nueva tabla. Por ejemplo, en la tabla tCliente, elimine apeVende y nombreVende porque dependen del determinante codiVende, que no es una clave candidata. Se ha formado una nueva tabla, que consiste en codiVende como clave principal y las columnas apeVende y nombreVende, de esta manera: tCliente (codiClien, nombreClien, balanClien, limiCreClien, codiVende) y tVendedor (codiVende, apeVende, nombreVende) En la figura 2.12 vemos la tabla original tCliente y las tablas creadas al convertir la tabla original a tercera forma normalizada. Ha corregido este nuevo diseo de la tabla tCliente todos los problemas previamente identificados? El nombre del vendedor aparece solo una vez, con lo que se evita la redundancia y se simplifica el proceso de cambiar el nombre de un vendedor. En este diseo no se permite que un vendedor tenga nombre diferentes en una base de datos. Para aadir un nuevo vendedor a la base de datos; aadiremos una fila a la tabla tVendedor, no es necesario que un nuevo vendedor represente a algn cliente. Por ltimo, eliminar a todos los clientes de un vendedor determinado no eliminar el registro del vendedor de la tabla tVendedor, sino que su nombre se mantendr en la base de datos. Podemos reconstruir todos los datos en la tabla original a partir de los datos del nuevo conjunto de tablas. Todos los problemas mencionados anteriormente ya se han resuelto. tCliente codi Clien nombreClien direcClien ciudad Clien balan Clien limiCre Clien codi Vende ape Vende nombre Vende

148 Als Appliance and Sport 2837 Greenway Fillmore $6550.00 $7500.00 20 Kaiser Valerie

282 Brookings Direct 3827 Devon Grove $431.50 $10000.00 35 Hull Richard

356 Fergusons 382 Wildwood Northfield $5785.00 $7500.00 65 Perez Juan

408 The Everything Shop 1828 Raven Crystal $5285.25 $5000.00 35 Hull Richard

462 Bargains Galore 3829 Central Grove $3412.00 $10000.00 65 Perez Juan

524 Klines 838 Ridgeland Fillmore $12762.00 $15000.00 20 Kaiser Valerie

608 Johnsons Department Store 372 Oxford Sheldon $2106.00 $10000.00 65 Perez Juan

687 Lees Sport and Appliance 282 Evergreen Altonville $2851.00 $5000.00 35 Hull Richard

725 Deerfields Four Seasons 282 Columbia Sheldon $248.00 $7500.00 35 Hull Richard

842 All Season 28 Lakeview Grove $8221.00 $7500.00 20 Kaiser Valerie

codiVende apeVende nombreVende

20 Kaiser Valerie

35 Hull Richard

65 Perez Juan

Figura 2.12. La tabla tCliente convertida en tercera forma normalizada.

Preguntas y Respuestas Pregunta: Convierta la siguiente tabla en tercera forma normalizada. En esta tabla, codiAlum determina a nombreAlum, numeCredi, codiTutor y nombreTutor. codiTutor determina a nombreTutor. codiCurso determina a descripCurso.

La combinacin de un codiAlum y de un codiCurso determina una notaCurso. tAlumno (codiAlum, nombreAlum, numeCredi, codiTutor, nombreTutor, (codiCurso, descripCurso, notaCurso)) Respuesta: Complete los siguientes pasos:

Paso 1: Elimine el grupo repetido para convertir la tabla en primera forma normalizada de esta manera: tAlumno (codiAlum, nombreAlum, numeCredi, codiTutor, nombreTutor, codiCurso, descripCurso, notaCurso) La tabla tAlumno est ahora en primera forma normalizada porque no tiene grupos repetidos. Sin embargo no est en segunda forma normalizada porque nombreAlum depende solo de codiAlum, que es solo una parte de la clave principal. Paso 2: Convierta la tabla tAlumno en segunda forma normalizada. En primer lugar, para cada parte de la clave principal, empiece una tabla con esa parte como una clave dejando lo siguiente: (codiAlum, (codiCurso, (codiAlum, codiCurso, Despus, site el resto de columnas con el conjunto de columnas ms pequeo de las que dependen, as: tAlumno (codiAlum, nombreAlum, numeCredi, codiTutor, nombreTutor) tCurso (codiCurso, descripCurso) tAlumnoCurso (codiAlum, codiCurso, notaCurso) Ahora estas tablas estn en segunda forma normalizada, y las tablas tCurso y tAlumnoCurso tambin estn en tercera forma normalizada. Sin embargo, la tabla tAlumno no est en tercera forma normalizada, porque contiene un determinante (codiTutor) que no es una clave candidata. Paso 3: Convierta la tabla tAlumno en tercera forma normalizada eliminando la columna que depende del determinante codiTutor y situndola en una tabla aparte, de esta manera: (codiAlum, nombreAlum, numeCredi, codiTutor) (codiTutor, nombreTutor) Paso 4: Nombre todas las tablas y agrupe todo el conjunto as: tAlumno (codiAlum, nombreAlum, numeCredi, codiTutor) tTutor (codiTutor, nombreTutor) tCurso (codiCurso, descripCurso) tAlumnoCurso (codiAlum, codiCurso, notaCurso)

IMPLEMENTACION DE BASES DE DATOSSQL ServerSQL server es un sistema administrador para Bases de Datos relacionales basadas en la arquitectura Cliente/Servidor (RDBMS) que usa Transact SQL para mandar peticiones un cliente y el SQL Server.SQL Server usa la arquitectura Cliente/Servidor para separar la carga de trabajo en tareas que corran en computadoras tipo Servidor y tareas que corran en computadoras tipo Cliente: El cliente es responsable de la parte lgica y de presentar la informacin al usuario. Generalmente, el cliente corre en una o ms computadoras Cliente, aunque tambin puede correr en una computadora Servidor con SQL Server. SQL Server administra Bases de Datos y Distribuye los recursos disponibles del Servidor (tales como memoria, operaciones de disco, etc.) entre las mltiples peticiones.Bases de Datos SQL ServerCada SQL Server tiene dos tipos de Bases de Datos: Bases de Datos del Sistema y Bases de Datos del Usuario. Las Bases de Datos del sistema almacenan informacin acerca de SQL Server como un total. SQL Server usa la Base de Datos del sistema para operar y administrar al sistema. Las Bases de Datos de usuarios, son Bases de Datos creadas por los usuarios. Una copia del SQL Server puede administrar una o ms Bases de Datos de usuario.Caractersticas generales del SQLEl SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y potencia de los sistemas relacionales y permite as gran variedad de operaciones.Es un lenguaje declarativo de "alto nivel" o "de no procedimiento" que, gracias a su fuerte base terica y su orientacin al manejo de conjuntos deregistrosy no a registros individuales permite una alta productividad en codificacin y la orientacin a objetos. De esta forma, una sola sentencia puede equivaler a uno o ms programas que se utilizaran en un lenguaje de bajo nivel orientado a registros. SQL tambin tiene las siguientes caractersticas: Lenguaje de definicin de datos: El LDD de SQL proporciona comandos para la definicin de esquemas de relacin, borrado de relaciones y modificaciones de los esquemas de relacin. Lenguaje interactivo de manipulacin de datos: El LMD de SQL incluye lenguajes de consultas basado tanto en lgebra relacional como en clculo relacional de tuplas. Integridad: El LDD de SQL incluye comandos para especificar las restricciones de integridad que deben cumplir los datos almacenados en la base de datos. Definicin de vistas: El LDD incluye comandos para definir las vistas. Control de transacciones: SQL tiene comandos para especificar el comienzo y el final de una transaccin. SQL incorporado y dinmico: Esto quiere decir que se pueden incorporar instrucciones de SQL en lenguajes de programacin como: C++, C, Java, PHP, Cobol, Pascal y Fortran. Autorizacin: El LDD incluye comandos para especificar los derechos de acceso a las relaciones y a las vistas.Tipos de DatosAlgunos de los tipos de datos bsicos de SQL son: Date: una fecha de calendario que contiene el ao (de cuatro cifras), el mes y el da. Time: La hora del da en horas minutos segundos (el valor predeterminado es 0). Timestamp: la combinacin de Date y Time.OptimizacinComo ya se dijo antes, y suele ser comn en los lenguajes de acceso a bases de datos de alto nivel, el SQL es un lenguaje declarativo. O sea, que especifica qu es lo que se quiere y no cmo conseguirlo, por lo que una sentencia no establece explcitamente un orden de ejecucin.El orden de ejecucin interno de una sentencia puede afectar seriamente a la eficiencia del SGBD, por lo que se hace necesario que ste lleve a cabo una optimizacin antes de su ejecucin. Muchas veces, el uso de ndices acelera una instruccin de consulta, pero ralentiza la actualizacin de los datos. Dependiendo del uso de la aplicacin, se priorizar el acceso indexado o una rpida actualizacin de la informacin. La optimizacin difiere sensiblemente en cada motor de base de datos y depende de muchos factores.Existe una ampliacin de SQL conocida comoFSQL(Fuzzy SQL, SQL difuso) que permite el acceso abases de datosdifusas, usando lalgica difusa. Este lenguaje ha sido implementado a nivel experimental y est evolucionando rpidamente.Lenguaje de definicin de datos (DDL)El lenguaje de definicin de datos (en inglsData Definition Language, oDDL), es el que se encarga de la modificacin de la estructura de los objetos de la base de datos. Incluye rdenes para modificar, borrar o definir las tablas en las que se almacenan los datos de la base de datos. Existen cuatro operaciones bsicas: CREATE, ALTER, DROP y TRUNCATE.CREATE | CREAREste comando permite crear objetos de datos, como nuevas bases de datos, tablas, vistas yprocedimientos almacenados.Ejemplo (crear una tabla)CREATE TABLE 'CUSTOMERS';ALTER | MODIFICAREste comando permite modificar la estructura de una tabla u objeto. Se pueden agregar/quitarcamposa una tabla, modificar el tipo de un campo, agregar/quitar ndices a una tabla, modificar untrigger, etc.Ejemplo (agregar columna a una tabla)ALTER TABLE 'ALUMNOS' ADD EDAD INT UNSIGNED;DROP | ELIMINAREste comando elimina un objeto de la base de datos. Puede ser una tabla,vista,ndice,trigger, funcin, procedimiento o cualquier objeto que el motor de la base de datos soporte. Se puede combinar con la sentencia ALTER.Ejemplo DROP TABLE 'ALUMNOS';.TRUNCATE | BORRAR TABLAEste comando trunca todo el contenido de una tabla. La ventaja sobre el comando DROP, es que si se quiere borrar todo el contenido de la tabla, es mucho ms rpido, especialmente si la tabla es muy grande. La desventaja es que TRUNCATE slo sirve cuando se quiere eliminar absolutamente todos los registros, ya que no se permite la clusula WHERE. Si bien, en un principio, esta sentencia parecera ser DML (Lenguaje de Manipulacin de Datos), es en realidad una DDL, ya que internamente, el comando TRUNCATE borra la tabla y la vuelve a crear y no ejecuta ninguna transaccin.Ejemplo TRUNCATE TABLE 'NOMBRE_TABLA';Lenguaje de manipulacin de datos DML (Data Manipulation Language)DefinicinUn lenguaje de manipulacin de datos (Data Manipulation Language, oDMLen ingls) es un lenguaje proporcionado por el sistema de gestin de base de datos que permite a los usuarios llevar a cabo las tareas de consulta o manipulacin de los datos, organizados por el modelo de datos adecuado.El lenguaje de manipulacin de datos ms popular hoy da es SQL, usado para recuperar y manipular datos en una base de datos relacional.SELECT | SELECCIONARLa sentenciaSELECTnos permite consultar los datos almacenados en una tabla de la base de datos.FORMA BSICASELECT [ALL | DISTINCT ] [{,}]FROM | [{,|}][WHERE [{ AND|OR }]][GROUP BY [{,}]][HAVING [{ AND|OR }]][ORDER BY | [ASC | DESC] [{,| [ASC | DESC ]}]] SELECTPalabra clave que indica que la sentencia de SQL que queremos ejecutar es de seleccin.

ALLIndica que queremos seleccionar todos los valores.Es el valor por defecto y no suele especificarse casi nunca.

DISTINCTIndica que queremos seleccionar slo los valores distintos.

FROMIndica la tabla (o tablas) desde la que queremos recuperar los datos. En el caso de que exista ms de una tabla se denomina a la consulta "consulta combinada" o "join". En las consultas combinadas es necesario aplicar una condicin de combinacin a travs de una clusulaWHERE.

WHEREEspecifica una condicin que debe cumplirse para que los datos sean devueltos por la consulta. Admite los operadores lgicosANDyOR.

GROUP BYEspecifica la agrupacin que se da a los datos. Se usa siempre en combinacin con funciones agregadas.

HAVINGEspecifica una condicin que debe cumplirse para que los datos sean devueltos por la consulta. Su funcionamiento es similar al deWHEREpero aplicado al conjunto de resultados devueltos por la consulta. Debe aplicarse siempre junto aGROUP BYy la condicin debe estar referida a los campos contenidos en ella.

ORDER BYPresenta el resultado ordenado por las columnas indicadas. El orden puede expresarse conASC(orden ascendente) yDESC(orden descendente). El valor predeterminado esASC.

Ejemplo:Para formular una consulta a la tabla Coches y recuperar los campos matricula, marca, modelo, color, numero_kilometros, num_plazas debemos ejecutar la siguiente consulta. Los datos sern devueltos ordenados por marca y por modelo en orden ascendente, de menor a mayor. La palabra claveFROMindica que los datos sern recuperados de la tabla Coches. SELECT matricula, marca, modelo, color, numero_kilometros, num_plazas FROM Coches ORDER BY marca,modelo;Ejemplo de Consulta simplificada a travs de un comodn de Campos (*):El uso del asterisco indica que queremos que la consulta devuelva todos los campos que existen en la tabla y los datos sern devueltos ordenados por marca y por modelo. SELECT * FROM Coches ORDER BY marca, modelo;Clusula WHERELa clusulaWHEREes la instruccin que nos permite filtrar el resultado de una sentenciaSELECT. Habitualmente no deseamos obtener toda la informacin existente en la tabla, sino que queremos obtener slo la informacin que nos resulte til en ese momento. La clusulaWHEREfiltra los datos antes de ser devueltos por la consulta. Cuando en la Clusula WHERE queremos incluir un tipo texto, debemos incluir el valor entre comillas simples.Ejemplos:En nuestro ejemplo, se desea consultar un coche en concreto, para esto se agreg una clusulaWHERE. Esta clusula especifica una o varias condiciones que deben cumplirse para que la sentenciaSELECTdevuelva los datos. En este caso la consulta devolver slo los datos del coche con matrcula para que la consulta devuelva slo los datos del coche con matrculaMF-234-ZDo bien la matrculaFK-938-ZL. Se puede utilizar la clusulaWHEREsolamente, en combinacin con tantas condiciones como queramos. SELECT matricula, marca, modelo, color, numero_kilometros, num_plazas FROM Coches WHERE matricula = 'MF-234-ZD' OR matricula = 'FK-938-ZL' ;

Una Condicin WHERE puede ser negada a travs del Operador Lgico NOT. La Siguiente consulta devolver todos los datos de la tabla Coches, menos el que tenga la MatrculaMF-234-ZD. SELECT matricula,marca, modelo, color, numero_kilometros, num_plazas FROM coches WHERE NOT matricula = 'MF-234-ZD';La Siguiente consulta utiliza la condicionalDISTINCT, la cual nos devolver todos los valores distintos formados por los CamposMarca y Modelo. De la tablacoches. SELECT DISTINCT marca, modelo FROM coches;Clusula ORDER BYLa clusulaORDER BYes la instruccin que nos permite especificar el orden en el que sern devueltos los datos. Podemos especificar la ordenacin ascendente o descendente a travs de las palabras claveASCyDESC. La ordenacin depende del tipo de datos que est definido en la columna, de forma que un campo numrico ser ordenado como tal, y un alfanumrico se ordenar de la A a la Z, aunque su contenido sea numrico. El valor predeterminado es ASC si no se especifica al hacer la consulta.Ejemplos:SELECTmatricula,marca,modelo,color,numero_kilometros,num_plazasFROMcochesORDER BYmarcaASC,modeloDESC; Este ejemplo, selecciona todos los campos matricula, marca, modelo, color, numero_kilometros y num_plazas de la tabla coches, ordenndolos por los campos marca y modelo, marca en forma ascendente y modelo en forma descendente.SELECT matricula, marca, modelo, color, numero_kilometros, num_plazas FROM cochesORDER BY 2; Este ejemplo, selecciona todos los campos matrcula, marca, modelo, color, numero_kilometros y num_plazas de la tabla coches, ordenndolos por el campomarca, ya que aparece en segundo lugar dentro de la lista de campos que componen laSELECT.INSERT | INSERTARUna sentenciaINSERTde SQL agrega uno o ms registros a una (y slo una) tabla en una base de datos relacional.Forma bsica INSERT INTO 'tablatura' ('columna1',['columna2,... ']) VALUES ('valor1', ['valor2,...'])

Las cantidades de columnas y valores deben ser iguales. Si una columna no se especifica, le ser asignado el valor por omisin. Los valores especificados (o implcitos) por la sentenciaINSERTdebern satisfacer todas las restricciones aplicables. Si ocurre un error de sintaxis o si alguna de las restricciones es violada, no se agrega lafilay se devuelve un error.Ejemplo INSERT INTO agenda_telefonica (nombre, numero) VALUES ('Roberto Jeldrez', 4886850);Cuando se especifican todos los valores de una tabla, se puede utilizar la sentencia acortada: INSERT INTO nombreTabla VALUES ('valor1', ['valor2,...'])Ejemplo (asumiendo que 'nombre' y 'nmero' son las nicas columnas de la tabla 'agenda_telefonica'): INSERT INTO agenda_telefonica VALUES ('Jhonny Aguiar', 080473968);Formas avanzadasUna caracterstica de SQL (desde SQL-92) es el uso deconstructores de filaspara insertar mltiples filas a la vez, con una sola sentencia SQL:INSERT INTO ''tabla'' (''columna1'', [''columna2,... '']) VALUES (''valor1a'', [''valor1b,...'']), (''value2a'', [''value2b,...'']),...;UPDATEUna sentenciaUPDATEde SQL es utilizada para modificar los valores de un conjunto de registros existentes en una tabla.EjemploUPDATE My_table SET field1 = 'updated value asd' WHERE field2 = 'N';DELETEUna sentenciaDELETEde SQL borra uno o ms registros existentes en una tabla.Forma bsicaDELETE FROM tabla WHERE columna1 = 'valor1'EjemploDELETE FROM My_table WHERE field2 = 'N';

GESTIN DE USUARIOS Y ESQUEMAS DE SEGURIDADAUTENTICACINUn usuario debe de tener una cuenta para conectarse al SQL Server. Este reconoce 2 mecanismos de Autentificacin de SQL Server y de Windows. Cada uno tiene diferente tipo de cuenta.

Autentificacin de SQL ServerCuando se usa un administrador del Sistema SQL Server, define una cuenta y un password SQL Server. Los usuarios deben de suministrar tanto el login como el password cuando se conectan.

Autentificacin WindowsCuando se usa el usuario no necesita de una cuenta SQL Server, para conectarse. Un administrador del sistema debe definir ya sean cuentas de Windows o grupos de Windows como cuentas validas de SQL Server.

EL Inicio de Sesion sa (System Administration)Administrador del Sistema (sa) es una cuenta especial. De forma predeterminada, esta asignada a la funcin fija de servidor sysadmin y no es posible cambiarla. Se incluye por compatibilidad con versiones anteriores de Microsoft SQL Server. Aunque sa es una cuenta de administrador integrada, no debe de utilizarse habitualmente. En su lugar, los administradores deben de pertenecer a la funcin fija de servidor sysadmin y conectarse con sus propios nombres de inicio de sesin. Solo debe de usarse sa cuando no haya otro modo de iniciar sesin en SQL Server; por ejemplo, cuando los dems administradores del sistema no estn disponibles o cuando hayan olvidado sus contraseas.

ROLES Y FUNCIONES

SQL Server proporciona roles de nivel de servidor para ayudarle a administrar los permisos de un servidor.Estos roles son entidades de seguridad que agrupan otras entidades de seguridad.Los roles de nivel de servidor se aplican a todo el servidor en lo que respecta a su mbito de permisos.(Losrolesson como losgruposdel sistema operativo Windows.)Los roles fijos de servidor se proporcionan por comodidad y compatibilidad con versiones anteriores.Siempre que sea posible, asigne permisos ms especficos.SQL Server proporciona nueve roles fijos de servidor.Los permisos que se conceden a los roles fijos de servidor no se pueden modificar.A partir de SQL Server 2012, puede crear roles de servidor definidos por el usuario y agregarles permisos de nivel de servidor.Puede agregar entidades de seguridad a nivel de servidor (inicios de sesin de SQL Server, cuentas de Windows y grupos de Windows) a los roles de nivel de servidor.Cada miembro de un rol fijo de servidor puede agregar otros inicios de sesin a ese mismo rol.Los miembros de roles de servidor definidos por el usuario no pueden agregar otras entidades de seguridad de servidor al rol.ROLES FIJOS DE NIVEL DE SERVIDOREn la tabla siguiente se muestran los roles fijos de nivel de servidor y sus capacidades.Rol fijo de nivel de servidorDescripcin

sysadminLos miembros del rol fijo de servidor sysadmin pueden realizar cualquier actividad en el servidor.

serveradminLos miembros del rol fijo de servidor serveradmin pueden cambiar las opciones de configuracin del servidor y apagarlo.

securityadminLos miembros del rol fijo de servidor securityadmin administran los inicios de sesin y sus propiedades.Administran los permisos de servidor GRANT, DENY y REVOKE.Tambin pueden administrar los permisos de nivel de base de datos GRANT, DENY y REVOKE si tienen acceso a una base de datos.Asimismo, pueden restablecer las contraseas para los inicios de sesin de SQL Server.Nota de seguridad

La capacidad de conceder acceso a Motor de base de datos y configurar los permisos de usuario permite que el administrador de seguridad asigne la mayora de los permisos de servidor.El rolsecurityadminse debe tratar como equivalente al rolsysadmin.

processadminLos miembros del rol fijo de servidor processadmin pueden finalizar los procesos que se ejecuten en una instancia de SQL Server.

setupadminLos miembros del rol fijo de servidor setupadmin pueden agregar y quitar servidores vinculados mediante instrucciones Transact-SQL.(Se necesita la pertenencia a sysadmin cuando se utiliza Management Studio).

bulkadminLos miembros del rol fijo de servidor bulkadmin pueden ejecutar la instruccin BULK INSERT.

diskadminEl rol fijo de servidor diskadmin se usa para administrar archivos de disco.

dbcreatorLos miembros del rol fijo de servidor dbcreator pueden crear, modificar, quitar y restaurar cualquier base de datos.

publicCada inicio de sesin de SQL Server pertenece al rol de servidor public.Cuando a una entidad de seguridad de servidor no se le han concedido ni denegado permisos especficos para un objeto protegible, el usuario hereda los permisos concedidos al rol public para ese objeto.Solo asigne permisos pblicos en cualquier objeto cuando desee que el objeto est disponible para todos los usuarios.No puede cambiar la pertenencia en public.Nota

public se implementa de manera diferente que otros roles.Sin embargo, se pueden conceder, denegar o revocar permisos desde public.

PERMISOS DE NIVEL DE SERVIDORSolo se pueden agregar a los roles de servidor definidos por el usuario los permisos de nivel de servidor.Para enumerar los permisos de nivel de servidor, ejecute la instruccin siguiente. Los permisos de nivel de servidor son:Transact-SQLSELECT * FROM sys.fn_builtin_permissions('SERVER') ORDER BY permission_name;Para obtener ms informacin acerca de los permisos, veaPermisos (motor de base de datos)ysys.fn_builtin_permissions (Transact-SQL).Trabajar con roles de nivel de servidorEn la tabla siguiente se explican los comandos, las vistas y las funciones que se pueden utilizar para trabajar con roles de nivel de servidor.

CaractersticaTipoDescripcin

sp_helpsrvrole (Transact-SQL)MetadatosDevuelve una lista de roles de nivel de servidor.

sp_helpsrvrolemember (Transact-SQL)MetadatosDevuelve informacin acerca de los miembros de un rol de nivel de servidor.

sp_srvrolepermission (Transact-SQL)MetadatosMuestra los permisos de un rol de nivel de servidor.

IS_SRVROLEMEMBER (Transact-SQL)MetadatosIndica si un inicio de sesin de SQL Server es miembro del rol de nivel de servidor especificado.

sys.server_role_members (Transact-SQL)MetadatosDevuelve una fila por cada miembro de cada rol de nivel de servidor.

sp_addsrvrolemember (Transact-SQL)ComandoAgrega un inicio de sesin como miembro de un rol de nivel de servidor.Desusado.UtiliceALTER SERVER ROLEen su lugar.

sp_dropsrvrolemember (Transact-SQL)ComandoQuita un inicio de sesin de SQL Server o un usuario o grupo de Windows de un rol de nivel de servidor.Desusado.Utilice ALTER SERVER ROLEen su lugar.

CREATE SERVER ROLE (Transact-SQL)ComandoCrea un rol de servidor definido por el usuario.

ALTER SERVER ROLE (Transact-SQL)ComandoCambia la pertenencia de un rol de servidor o cambia el nombre de un rol de servidor definido por el usuario.

DROP SERVER ROLE (Transact-SQL)ComandoQuita un rol de servidor definido por el usuario.

IS_SRVROLEMEMBER (Transact-SQL)FuncinDetermina la pertenencia del rol de servidor.

GESTIN DE COPIAS DE SEGURIDADTener instalado Microsoft SQL Server Management Studio para la conexin a la instancia de Base de datos (segn sea 2012, 2008 R2, 2008, 2005).Tener instalada una misma versin e intercalacin (collation) de SQL en los Servidores involucrados (donde se va a restaurar el backup y de donde se obtuvo el backup).

Consideraciones adicionalesSi usted est moviendo un proyecto que se encuentra en fases de automatizacin (ambiente de desarrollo), hacia un servidor diferente (pero igual de desarrollo) y desea conservar las instancias de Proceso (casos), tenga en cuenta que los adjuntos de estos casos no estarn dentro de la informacin del backup.Por lo tanto en el hipottico escenario en el que desee trasladar los casos de un ambiente de desarrollo, deber considerar mover tambin la ubicacin de stos (sea el Servidor BPM, un Servidor diferente de archivos, o un ECM).Crear un BackupPara crear un backup de su Base de datos:Autentquese en su instancia de SQL Server (login) a travs de SQL Server Management Studio.

Ubique la Base de datos y d clic derecho sobre sta. Seleccione la opcinBackup...desde las tareas:

Especifique que el backup se realice completo (modoFULL).

Ntese que debe seleccionar una ruta vlidar para almacenar el archivo resultante (.bak).Si no desea utilizar la ruta por defecto, puede navegar y seleccionar otro directorio. Si utiliza otro directorio, asegrese de contar con los permisos de escritura sobre l.

Haga clic enOKcuando la operacin se haya completado:

ImportanteNtese que podr crear 2 tipos bsicos de Backups:Full Backup: Esta opcin crea un backup completo (de toda la Base de datos). Con esta opcin se limpian las transacciones almacenadas en el log de transacciones.

Differential Backup: Es un backup diferencial, donde se almacena la parte que ha cambiado con respecto al ltimo backup completo (Full Backup). El log de transacciones tambin es truncado.

Para restaurar un proyecto de Bizagi a su ltimo estado por medio de un backup, se recomienda crear y utilizar los backups en modoFull backup.Por ejemplo, los backups automticos que toma Bizagi los realiza de esta manera.

GESTIN DE PROCEDIMIENTOS ALMACENADOS Y DISPARADORESPROCEDIMIENTOS ALMACENADOSUn procedimiento es un programa dentro de la base de datos que ejecuta una accin o conjunto de accionesespecficas.Un procedimiento tiene un nombre, un conjunto de parmetros (opcional) y un bloque de cdigo.EnTransact SQLlos procedimientos almacenados pueden devolver valores (numerico entero) o conjuntos de resultados.Paracrear un procedimiento almacenado debemos emplear la sentenciaCREATE PROCEDURE.CREATE PROCEDURE [@param1 , ...]AS-- Sentencias del procedure

Para modificar un procedimiento almacenado debemos emplear la sentenciaALTER PROCEDURE.ALTER PROCEDURE [@param1 , ...]AS-- Sentencias del procedure

El siguiente ejemplo muestra un procedimiento almacenado,denominado spu_addCliente que inserta un registro en la tabla"CLIENTES".CREATE PROCEDURE spu_addCliente @nombre varchar(100),@apellido1 varchar(100),@apellido2 varchar(100),@nifCif varchar(20),@fxNaciento datetimeASINSERT INTO CLIENTES(nombre, apellido1, apellido2, nifcif, fxnacimiento) VALUES(@nombre, @apellido1, @apellido2, @nifCif, @fxNaciento)

Para la ejecutar un procedimiento almacenado debemos utilizar la sentenciaEXEC. Cuando la ejecucin del procedimiento almacenado es la primera instruccin del lote, podemos omitir el uso deEXEC.El siguiente ejemplo muestra la ejecucin del procedimiento almacenado anterior.DECLARE @fecha_nacimiento datetimeset @fecha_nacimiento = convert(datetime, '13/05/1975', 103)EXEC spu_addCliente 'Pedro', 'Herrarte', 'Sanchez', '00000002323', @fecha_nacimiento

Siempre es deseable que las instrucciones del procedure estn dentro de un bloqueTRY CATCHy controlados por una transaccin.ALTER PROCEDURE spu_addCliente @nombre varchar(100),@apellido1 varchar(100),@apellido2 varchar(100),@nifCif varchar(20),@fxNaciento datetimeASBEGIN TRYBEGIN TRAN INSERT INTO CLIENTES(nombre, apellido1, apellido2, nifcif, fxnacimiento) VALUES(@nombre, @apellido1, @apellido2, @nifCif, @fxNaciento) COMMITEND TRYBEGIN CATCHROLLBACKPRINT ERROR_MESSAGE()END CATCH

Si queremos que los parmetros de un procedimiento almacenado sean de entrada-salida debemos especificarlo a travs de la palabra claveOUTPUT, tanto en la definicin del procedure como en la ejecucin.El siguiente ejemplo muestra la definicin de un procedure con parmetros de salida.CREATE PROCEDURE spu_ObtenerSaldoCuenta @numCuenta varchar(20), @saldo decimal(10,2) output ASBEGINSELECT @saldo = SALDO FROM CUENTASWHERE NUMCUENTA = @numCuentaEND

Y para ejecutar este procedure:DECLARE @saldo decimal(10,2)EXEC spu_ObtenerSaldoCuenta '200700000001', @saldo outputPRINT @saldo

Un procedimiento almacenado puede devolver valores numricos enteros a travs de la instruccin RETURN. Normalmente debemos utilizar los valores de retorno para determinar si la ejecucin del procedimiento ha sido correcta o no. Si queremos obtener valores se recomienda utilizar parmetros de salida o funciones escalares (se vern ms adelante en este tutorial).El siguiente ejemplo muestra un procedimiento almacenado que devuelve valores.CREATE PROCEDURE spu_EstaEnNumerosRojos @numCuenta varchar(20)ASBEGINIF (SELECT SALDO FROM CUENTAS WHERE NUMCUENTA = @numCuenta) < 0BEGINRETURN 1ENDELSERETURN 0END

El siguiente ejemplo muestra como ejecutar el procedure y obtener el valor devuelto.DECLARE @rv intEXEC @rv = spu_EstaEnNumerosRojos '200700000001'PRINT @rv

Otra caracterstica muy interesante de los procedimientos almacenados en Transact SQL es quepueden devolver uno o varios conjuntos de resultados.El siguiente ejemplo muestra unprocedimiento almacenado que devuelve un conjunto de resultados.CREATE PROCEDURE spu_MovimientosCuenta @numCuenta varchar(20)ASBEGINSELECT @numCuenta, SALDO_ANTERIOR, SALDO_POSTERIOR, IMPORTE, FXMOVIMIENTO FROM MOVIMIENTOSINNER JOIN CUENTAS ON MOVIMIENTOS.IDCUENTA = CUENTAS.IDCUENTAWHERE NUMCUENTA = @numCuentaORDER BY FXMOVIMIENTO DESCEND

La ejecucin del procedimiento se realiza normalmente.EXEC spu_MovimientosCuenta '200700000001'

Elresultadode la ejecucin ...NUMCUENTA SALDO_ANTERIOR SALDO_POSTERIOR IMPORTE FXMOVIMIENTO------------ -------------- ---------------- ------- -----------------------200700000001 50.99 100.99 50.00 2007-08-25 16:18:36.490200700000001 0.99 50.99 50.00 2007-08-23 16:20:41.183200700000001 50.99 0.99 50.00 2007-08-23 16:16:29.840200700000001 0.99 50.99 50.00 2007-08-23 16:14:05.900TRIGGERSUn trigger( o desencadenador) es una clase especial de procedimiento almacenado que se ejecuta automticamente cuando se produce un evento en el servidor de bases de datos.SQL Server proporciona los siguientes tipos de triggers: Trigger DML, se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de manipulacin de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o vista. Trigger DDL, se ejecutan en respuesta a una variedad de eventos de lenguaje de definicin de datos (DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL, y a determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL.Trigger DML.Los trigger DML se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de manipulacin de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o vista.La sintaxis general de un trigger es la siguiente.CREATE TRIGGER ON AFTER AS BEGIN-- SET NOCOUNT ON added to prevent extra result sets from-- interfering with SELECT statements.SET NOCOUNT ON;-- Insert statements for trigger hereEND

Antes de ver un ejemplo es necesario conocer las tablasinsertedydeleted.Las instrucciones de triggers DML utilizan dos tablas especiales denominadasinsertedydeleted. SQL Server 2005 crea y administra automticamente ambas tablas. La estructura de las tablasinsertedydeletedes la misma que tiene la tabla que ha desencadenado la ejecucindel trigger.La primera tabla (inserted) solo est disponible en las operaciones INSERT y UPDATE y en ella estn los valores resultantes despues de la insercino actualizacin. Es decir, los datos insertados.Insertedestar vacia en una operacin DELETE.En la segunda (deleted), disponible en las operaciones UPDATE y DELETE, estn los valores anteriores ala ejecucin de la actualizacin o borrado. Es decir, los datos que sernborrados.Deletedestar vacia en una operacion INSERT.No existe una tabla UPDATED? No, hacer una actualizacin es lo mismo que borrar (deleted) e insertar los nuevos (inserted). La sentencia UPDATE es la nica en la queinsertedydeletedtienen datos simultneamente.No se puede modificar directamente los datos de estas tablas.El siguiente ejemplo, graba un histrico de saldos cada vez que se modifica un saldo de la tabla cuentas.CREATE TRIGGER TR_CUENTASON CUENTASAFTER UPDATEAS BEGIN-- SET NOCOUNT ON impide que se generen mensajes de texto -- con cada instruccin SET NOCOUNT ON;INSERT INTO HCO_SALDOS(IDCUENTA, SALDO, FXSALDO)SELECT IDCUENTA, SALDO, getdate()FROM INSERTEDEND

La siguiente instruccin provocar que el trigger se ejecute:UPDATE CUENTASSET SALDO = SALDO + 10WHERE IDCUENTA = 1

Una consideracin a tener en cuenta es que el trigger se ejecutar aunque la instruccion DML (UPDATE, INSERT o DELETE ) no haya afectado a ninguna fila. En este casoinsertedydeleteddevolveran un conjunto de datos vacio.Podemos especificar a que columnas de la tabla debe afectar el trigger.ALTER TRIGGER TR_CUENTASON CUENTASAFTER UPDATEAS BEGIN-- SET NOCOUNT ON impide que se generen mensajes de texto -- con cada instruccin SET NOCOUNT ON;IF UPDATE(SALDO) -- Solo si se actualiza SALDOBEGIN INSERT INTO HCO_SALDOS(IDCUENTA, SALDO, FXSALDO)SELECT IDCUENTA, SALDO, getdate()FROM INSERTEDENDEND

Los trigger estn dentro de la transaccin original (Insert, Delete o Update) por lo cual si dentro de nuestro trigger hacemos un RollBack Tran, no solo estaremos echando atrs nuestro trigger sino tambin toda la transaccin; en otras palabras si en un trigger ponemos un RollBack Tran, la transaccin de Insert, Delete o Update volver toda hacia atrs.ALTER TRIGGER TR_CUENTASON CUENTASAFTER UPDATEAS BEGIN-- SET NOCOUNT ON impide que se generen mensajes de texto -- con cada instruccin SET NOCOUNT ON;INSERT INTO HCO_SALDOS(IDCUENTA, SALDO, FXSALDO)SELECT IDCUENTA, SALDO, getdate()FROM INSERTEDROLLBACKEND

En este caso obtendremos el siguiente mensaje de error:La transaccin termin en el desencadenador. Se anul el lote.Podemos activar y desactivar Triggers a travs de las siguientes instrucciones.-- Desactiva el trigger TR_CUENTASDISABLE TRIGGER TR_CUENTAS ON CUENTASGO-- activa el trigger TR_CUENTASENABLE TRIGGER TR_CUENTAS ON CUENTASGO-- Desactiva todos los trigger de la tabla CUENTASALTER TABLE CUENTAS DISABLE TRIGGER ALLGO-- Activa todos los trigger de la tabla CUENTASALTER TABLE CUENTAS ENABLE TRIGGER ALL

Trigger DDLLos trigger DDL se ejecutan en respuesta a una variedad de eventos de lenguaje de definicin de datos (DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL, y a determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL.La sintaxis general de un trigger es la siguiente.CREATE TRIGGER ON DATABASE FOR AS BEGIN...END

La siguiente instruccinimpide que se ejecuten sentencias DROP TABLE y ALTER TABLE en la base de datos.CREATE TRIGGER TR_SEGURIDAD ON DATABASE FOR DROP_TABLE, ALTER_TABLE AS BEGINRAISERROR ('No est permitido borrar ni modificar tablas !' , 16, 1)ROLLBACK TRANSACTION END