FUNDAMENTOS DE BASE DE DATOS

SISTEMA ADMINISTRACIN DE BASE DE DATOS

Introduccin
En 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.
Dato
Definicin de dato encontrada en un diccionario: Dato: Antecedente que permite llegar mas
fcilmente al conocimiento de una cosa. Pequeo Larousse
El 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).
Informacin
Informacin: 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 Datos
Una 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 Datos
DBMS 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

Escalabilidad
Capacidad 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.
Rendimiento

Caractersticas 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.

Portabilidad
Caracterstica 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.
Universalidad
Se 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 Horizontal
Capacidad 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 Vertical
Capacidad para incrementar el tamao y/o la potencia del servidor y as obtener mejoras con mismo
producto.

Tres Niveles de Arquitectura de Datos

El Nivel Externo
Tambin 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 Conceptual
Tambin 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 Interno

Tambin 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/Servidor
Es 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 Archivos
El 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 Datos
El 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 Transacciones
El 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.

Groupware
Este 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 Objetos
Las 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 Web
Los clientes se comunican a travs de protocolo HTTP para que el servidor provea los
requerimientos correspondientes (un documento HTML por ejemplo).

Tipos de aplicaciones
Las 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 (frontend), 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/Servidor
No 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 distribuida
La 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 Distribuidas
Modelo 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 Distribuidos
Solo 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/Servidor

EL CLIENTE
En 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 SERVIDOR
El 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 MIDDLEWARE
El 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 transporte
Provee 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 red
Aunque 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 especficos
Tambin 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 RELACIN

INTRODUCCIN
A 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 informacin
Las 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 datos
El 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 empleados
4. 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-Relacin
En 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.
ENTIDAD
Las entidades representan cosas u objetos (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 (objeto fsico): informacin de los trabajadores.
Cargo del empleado (cosa abstracta): informacin de la funcin del empleado.

Estas entidades se representan en un diagrama con unos rectngulos, como los siguientes.

Coche
ATRIBUTO

Empleado

Cargo del
Empleado

Los 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, DNI del

propietario, marca, modelo y 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.

RELACIN
Es 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 CARDINALIDAD
Podemos 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 cuantos objetos o cosas (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 varios o varios 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).
CLAVES
Es 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 externa o clave 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 BBDD sin la necesidad de crear un gran diagrama, sino usando notas ms
simples
MODELO RELACIONAL
El 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.
NOMBRE
Jhon Smith

EDAD
19

SEXO
Varn

Sally Boyce

23

Mujer

Tony Stark

18

Varn

Bill Ballucci

34

Varn

Tina Graver

19

Mujer

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.

tPedido
codiPedi

fechaPedi

codiArti

cantiArti

21608

10/20/201

AT94

11

0
10/20/201

DR93

21613

0
10/21/201

DW11
KL62

1
4

21614

0
10/21/201

KT03

0
10/23/201

BV06

21619

0
10/23/201

CD52
DR93

4
1

21623

0
10/23/201

KV29

21610

21617

0
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/201

AT94

11

21610

0
10/20/201

DR93

21610

0
10/20/201

DW11

21613

0
10/21/201

KL62

21614

0
10/21/201

KT03

21617

0
10/23/201

BV06

21617

0
10/23/201

CD52

21619

0
10/23/201

DR93

21623

0
10/23/201

KV29

0
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:
tPedido
codiPedi

fechaPedi

codiArti

descripArti

cantiArti

precioCoArti

21608
21610
21610
21613
21614
21617
21617

10/20/2010
10/20/2010
10/20/2010
10/21/2010
10/21/2010
10/23/2010
10/23/2010

AT94
DR93
DW11
KL62
KT03
BV06
CD52

Iron
Gas Range
Washer
Dryer
Dishwasher
Home Gym
Microwave

11
1
1
4
2
2
4

$21.95
$495.00
$399.99
$329.95
$595.00
$12.95
$150.00

21619
21623

Oven
10/23/2010 DR93
Gas Range
1
10/23/2010 KV29
Treadmill
2
Figura 2.9. Ejemplo de tabla tPedido.

$495.00
$325.99

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.
tPedido
codiPedi

fechaPedi

codiArti

descripArti

cantiArti

precioCoArti

21608
21610
21610
21613
21614
21617
21617

10/20/2010
10/20/2010
10/20/2010
10/21/2010
10/21/2010
10/23/2010
10/23/2010

AT94
DR93
DW11
KL62
KT03
BV06
CD52

Iron
Gas Range
Washer
Dryer
Dishwasher
Home Gym
Microwave

11
1
1
4
2
2
4

$21.95
$495.00
$399.99
$329.95
$595.00
$12.95
$150.00

21619
21623

10/23/2010 DR93
10/23/2010 KV29

Oven
Gas Range
Treadmill

1
2

$495.00
$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.
tCliente
codi

nombreClien

direcClien

Clie

ciudad

balan

limiCre

codi

ape

nombre

Clien

Clien

Clien

Vende Vende Vende

Fillmore

$6550.00

$7500.00

20

$10000.00 35
$7500.00 65

n
148

Als

282
356

Sport
Brookings Direct
Fergusons

Greenway
3827 Devon
382

Grove
Northfiel

$431.50
$5785.00

408
462
524

The Everything Shop

Bargains Galore
Klines

Wildwood
1828 Raven
3829 Central
838

d
Crystal
Grove
Fillmore

$5285.25 $5000.00 35
$3412.00 $10000.00 65
$12762.00 $15000.00 20

Hull
Richard
Perez Juan
Kaiser Valerie

608

Johnsons

Ridgeland
372 Oxford

Sheldon

$2106.00

$10000.00 65

Perez

Juan

687

Department Store
Lees
Sport
and 282

Altonville

$2851.00

$5000.00

35

Hull

Richard

725

Appliance
Deerfields

Sheldon

$248.00

$7500.00

35

Hull

Richard

842

Seasons
All Season

Columbia
28 Lakeview Grove
$8221.00 $7500.00
Figura 2.11. Ejemplo de la tabla tCliente

20

Kaiser Valerie

Appliance

and 2837

Evergreen
Four 282

Kaiser Valerie
Hull
Perez

Richard
Juan

La 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
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.
nicos determinantes que contiene son claves candidatas.
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

nombreClien

direcClien

Clien

ciudad

balan

limiCre

codi

ape

nombre

Clien

Clien

Clien

Vend

Vend

Vende

e
Kaise

Valerie
Richar

Fillmore

$6550.00

$7500.00

e
20

Greenway
3827 Devon

Grove

$431.50

$10000.0

35

r
Hull

Fergusons

382

Northfiel

$5785.00

0
$7500.00

65

d
Perez Juan

408

The Everything Shop

Wildwood
1828 Raven

d
Crystal

$5285.25

$5000.00

35

Hull

462

Bargains Galore

3829

Grove

$3412.00

$10000.0

65

d
Perez Juan

524

Klines

Central
838

Fillmore

$12762.0

0
$15000.0

20

Kaise

608

Ridgeland
Johnsons Department 372 Oxford

Sheldon

0
$2106.00

0
$10000.0

65

r
Perez Juan

687

Store
Lees

Altonville $2851.00

0
$5000.00

35

Hull

Richar

725

Appliance
Deerfields

Sheldon

$7500.00

35

Hull

d
Richar

842

Seasons
All Season

Kaise

d
Valerie

148

Als

Appliance

282

Sport
Brookings Direct

356

Sport

and 2837

and 282
Evergreen
Four 282

Columbia
28 Lakeview Grove

$248.00
$8221.00

$7500.00

20

r
codiVende apeVende nombreVende
20

Kaiser

Valerie

Richar

Valerie

35
65

Hull
Richard
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 DATOS

SQL Server
SQL 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 Server

Cada 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 SQL
El 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 de registros y 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 Datos
Algunos 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.

Optimizacin
Como 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 como FSQL (Fuzzy SQL, SQL difuso) que permite el acceso
a bases de datos difusas, usando la lgica 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 ingls Data Definition Language, o DDL), 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 | CREAR
Este comando permite crear objetos de datos, como nuevas bases de datos, tablas, vistas
y procedimientos almacenados.
Ejemplo (crear una tabla)
CREATE TABLE 'CUSTOMERS';
ALTER | MODIFICAR
Este

comando

permite

modificar

la

estructura

de

una

tabla

objeto.

Se

pueden

agregar/quitar campos a una tabla, modificar el tipo de un campo, agregar/quitar ndices a una tabla,
modificar un trigger, etc.
Ejemplo (agregar columna a una tabla)
ALTER TABLE 'ALUMNOS' ADD EDAD INT UNSIGNED;
DROP | ELIMINAR
Este 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 TABLA
Este 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)

Definicin
Un lenguaje de manipulacin de datos (Data Manipulation Language, o DML en 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 | SELECCIONAR
La sentencia SELECT nos permite consultar los datos almacenados en una tabla de la base de datos.
FORMA BSICA
SELECT [ALL | DISTINCT ]
<nombre_campo> [{,<nombre_campo>}]
FROM <nombre_tabla>|<nombre_vista>
[{,<nombre_tabla>|<nombre_vista>}]
[WHERE <condicin> [{ AND|OR <condicin>}]]
[GROUP BY <nombre_campo> [{,<nombre_campo >}]]
[HAVING <condicin>[{ AND|OR <condicin>}]]
[ORDER BY <nombre_campo>|<indice_campo> [ASC | DESC]
[{,<nombre_campo>|<indice_campo> [ASC | DESC ]}]]
SELECT
ALL

Palabra clave que indica que la sentencia de SQL que queremos ejecutar es de seleccin.
Indica que queremos seleccionar todos los valores.Es el valor por defecto y no suele

especificarse casi nunca.

DISTINCT Indica que queremos seleccionar slo los valores distintos.
Indica la tabla (o tablas) desde la que queremos recuperar los datos. En el caso de que
FROM

WHERE

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
clusula WHERE.
Especifica una condicin que debe cumplirse para que los datos sean devueltos por la

GROUP

consulta. Admite los operadores lgicos AND y OR.

Especifica la agrupacin que se da a los datos. Se usa siempre en combinacin con

BY
HAVING

funciones agregadas.
Especifica una condicin que debe cumplirse para que los datos sean devueltos por la

consulta. Su funcionamiento es similar al de WHERE pero aplicado al conjunto de

resultados devueltos por la consulta. Debe aplicarse siempre junto a GROUP BY y la

ORDER
BY

condicin debe estar referida a los campos contenidos en ella.

Presenta el resultado ordenado por las columnas indicadas. El orden puede expresarse
con ASC (orden ascendente) y DESC (orden descendente). El valor predeterminado
es ASC.

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
clave FROM indica 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 WHERE
La clusula WHERE es la instruccin que nos permite filtrar el resultado de una sentencia SELECT.
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 clusula WHERE filtra 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
clusula WHERE. Esta clusula especifica una o varias condiciones que deben cumplirse para que la
sentencia SELECT devuelva 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 matrcula MF-234-ZD o

bien la matrcula FK-938-ZL . Se puede utilizar la clusula WHERE solamente, 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 Matrcula MF-234-ZD .

SELECT matricula,marca, modelo, color, numero_kilometros, num_plazas

FROM coches
WHERE NOT matricula = 'MF-234-ZD';

La Siguiente consulta utiliza la condicional DISTINCT, la cual nos devolver todos los valores distintos
formados por los Campos Marca y Modelo. De la tabla coches.

SELECT DISTINCT marca, modelo FROM coches;

Clusula ORDER BY
La clusula ORDER BY es 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 clave ASC y DESC. 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:
SELECT matricula,
marca,
modelo,
color,

numero_kilometros,
num_plazas
FROM coches
ORDER BY marca ASC,modelo DESC; 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

coches

ORDER BY 2;
Este ejemplo, selecciona todos los campos matrcula, marca, modelo, color, numero_kilometros y
num_plazas de la tabla coches, ordenndolos por el campo marca, ya que aparece en segundo lugar
dentro de la lista de campos que componen la SELECT.
INSERT | INSERTAR
Una sentencia INSERT de 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

sentencia INSERT debern satisfacer todas las restricciones aplicables. Si ocurre un error de sintaxis
o si alguna de las restricciones es violada, no se agrega la fila y 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'

'nmero'

'agenda_telefonica'):

INSERT INTO agenda_telefonica

VALUES ('Jhonny Aguiar', 080473968);
Formas avanzadas

son

las

nicas

columnas

de

la

tabla

Una caracterstica de SQL (desde SQL-92) es el uso de constructores de filas para insertar mltiples
filas a la vez, con una sola sentencia SQL:

INSERT INTO ''tabla'' (''columna1'', [''columna2,... ''])

VALUES (''valor1a'', [''valor1b,...'']),
(''value2a'', [''value2b,...'']),...;
UPDATE
Una sentencia UPDATE de SQL es utilizada para modificar los valores de un conjunto de registros
existentes en una tabla.
Ejemplo

UPDATE My_table SET field1 = 'updated value asd' WHERE field2 = 'N';
DELETE
Una sentencia DELETE de SQL borra uno o ms registros existentes en una tabla.
Forma bsica

DELETE FROM tabla WHERE columna1 = 'valor1'

Ejemplo

DELETE FROM My_table WHERE field2 = 'N';

GESTIN DE USUARIOS Y ESQUEMAS DE SEGURIDAD

AUTENTICACIN
Un 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 Server
Cuando 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 Windows
Cuando 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. (Los roles son como los grupos del 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 SERVIDOR
En la tabla siguiente se muestran los roles fijos de nivel de servidor y sus capacidades.
Rol
de

fijo

Descripcin

nivel

de
servidor
sysadmi

Los miembros del rol fijo de servidor sysadmin pueden realizar cualquier actividad en

n
serverad

el servidor.
Los miembros del rol fijo de servidor serveradmin pueden cambiar las opciones de

min
securitya

configuracin del servidor y apagarlo.

Los miembros del rol fijo de servidor securityadmin administran los inicios de sesin y

dmin

sus

propiedades. Administran

los

permisos

de

servidor

GRANT,

DENY

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 perm
la mayora de los permisos de servidor. El rol securityadmin se debe tratar como equivalente al rol
processa

Los miembros del rol fijo de servidor processadmin pueden finalizar los procesos que

dmin
setupad

se ejecuten en una instancia de SQL Server.

Los miembros del rol fijo de servidor setupadmin pueden agregar y quitar servidores

min

vinculados mediante instrucciones Transact-SQL. (Se necesita la pertenencia a

bulkadmi

sysadmin cuando se utiliza Management Studio).

Los miembros del rol fijo de servidor bulkadmin pueden ejecutar la instruccin BULK

n
diskadmi

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

n
dbcreato

Los miembros del rol fijo de servidor dbcreator pueden crear, modificar, quitar y

r
public

restaurar cualquier base de datos.

Cada 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

PERMISOS DE NIVEL DE SERVIDOR

Solo 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-SQL
SELECT * FROM sys.fn_builtin_permissions('SERVER') ORDER BY permission_name;
Para obtener ms informacin acerca de los permisos, vea Permisos (motor de base de
datos) y sys.fn_builtin_permissions (Transact-SQL).
Trabajar con roles de nivel de servidor
En la tabla siguiente se explican los comandos, las vistas y las funciones que se pueden utilizar para
trabajar con roles de nivel de servidor.
Caracterstica
sp_helpsrvrole

(Transact-

Tipo
Descripcin
Metadatos
Devuelve una lista de roles de nivel de servidor.

SQL)
sp_helpsrvrolemember

Metadatos

Devuelve informacin acerca de los miembros de

(Transact-SQL)
sp_srvrolepermission

Metadatos

un rol de nivel de servidor.

Muestra los permisos de un rol de nivel de servidor.

(Transact-SQL)

IS_SRVROLEMEMBER

Metadatos

Indica si un inicio de sesin de SQL Server es

(Transact-SQL)
sys.server_role_members

Metadatos

miembro del rol de nivel de servidor especificado.

Devuelve una fila por cada miembro de cada rol de

(Transact-SQL)
sp_addsrvrolemember

Comando

nivel de servidor.
Agrega un inicio de sesin como miembro de un rol

(Transact-SQL)

de

sp_dropsrvrolemember

Comando

(Transact-SQL)

nivel

de

servidor. Desusado. Utilice ALTER

SERVER ROLE en su lugar.

Quita un inicio de sesin de SQL Server o un
usuario o grupo de Windows de un rol de nivel de
servidor. Desusado. Utilice

CREATE

SERVER

(Transact-SQL)
ALTER
SERVER

SERVER

(Transact-SQL)
IS_SRVROLEMEMBER

SERVER

ROLE

Comando

ROLE en su lugar.
Crea un rol de servidor definido por el usuario.

ROLE

Comando

Cambia la pertenencia de un rol de servidor o

(Transact-SQL)
DROP

ALTER

cambia el nombre de un rol de servidor definido por

ROLE

Comando

el usuario.
Quita un rol de servidor definido por el usuario.

Funcin

Determina la pertenencia del rol de servidor.

(Transact-SQL)

GESTIN DE COPIAS DE SEGURIDAD

Tener 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 adicionales
Si 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 Backup
Para 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 opcin Backup... desde las
tareas:

Especifique que el backup se realice completo (modo FULL).

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 en OK cuando la operacin se haya completado:

Importante
Ntese 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 modo Full backup.
Por ejemplo, los backups automticos que toma Bizagi los realiza de esta manera.

GESTIN DE PROCEDIMIENTOS ALMACENADOS Y

DISPARADORES
PROCEDIMIENTOS ALMACENADOS
Un procedimiento es un programa dentro de la base de datos que ejecuta una accin o conjunto de
acciones especficas.
Un procedimiento tiene un nombre, un conjunto de parmetros (opcional) y un bloque de cdigo.
En Transact SQL los procedimientos almacenados pueden devolver valores (numerico entero) o
conjuntos de resultados.
Para crear un procedimiento almacenado debemos emplear la sentencia CREATE PROCEDURE.
CREATE PROCEDURE <nombre_procedure> [@param1 <tipo>, ...]
AS
-- Sentencias del procedure
Para modificar un procedimiento almacenado debemos emplear la sentencia ALTER PROCEDURE.

ALTER PROCEDURE <nombre_procedure> [@param1 <tipo>, ...]

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 datetime
AS
INSERT INTO CLIENTES
(nombre, apellido1, apellido2, nifcif, fxnacimiento) VALUES

(@nombre, @apellido1, @apellido2, @nifCif, @fxNaciento)

Para la ejecutar un procedimiento almacenado debemos utilizar la sentencia EXEC. Cuando la

ejecucin del procedimiento almacenado es la primera instruccin del lote, podemos omitir el uso
de EXEC.
El siguiente ejemplo muestra la ejecucin del procedimiento almacenado anterior.

DECLARE @fecha_nacimiento datetime

set @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 bloque TRY CATCH y
controlados por una transaccin.

ALTER PROCEDURE spu_addCliente @nombre varchar(100),

@apellido1 varchar(100),
@apellido2 varchar(100),
@nifCif varchar(20),
@fxNaciento datetime
AS
BEGIN TRY
BEGIN TRAN
INSERT INTO CLIENTES
(nombre, apellido1, apellido2, nifcif, fxnacimiento) VALUES
(@nombre, @apellido1, @apellido2, @nifCif, @fxNaciento)
COMMIT
END TRY
BEGIN CATCH

ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
Si queremos que los parmetros de un procedimiento almacenado sean de entrada-salida debemos
especificarlo a travs de la palabra clave OUTPUT, 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
AS
BEGIN
SELECT @saldo = SALDO
FROM CUENTAS
WHERE NUMCUENTA = @numCuenta
END

Y para ejecutar este procedure:

DECLARE @saldo decimal(10,2)

EXEC spu_ObtenerSaldoCuenta '200700000001', @saldo output
PRINT @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)

AS
BEGIN
IF (SELECT SALDO FROM CUENTAS
WHERE NUMCUENTA = @numCuenta) < 0
BEGIN
RETURN 1
END
ELSE
RETURN 0
END
El siguiente ejemplo muestra como ejecutar el procedure y obtener el valor devuelto.

DECLARE @rv int

EXEC @rv = spu_EstaEnNumerosRojos '200700000001'
PRINT @rv
Otra caracterstica muy interesante de los procedimientos almacenados en Transact SQL es
que pueden devolver uno o varios conjuntos de resultados.
El siguiente ejemplo muestra un procedimiento almacenado que devuelve un conjunto de resultados.

CREATE PROCEDURE spu_MovimientosCuenta @numCuenta varchar(20)

AS
BEGIN
SELECT @numCuenta,
SALDO_ANTERIOR,
SALDO_POSTERIOR,
IMPORTE,
FXMOVIMIENTO

FROM MOVIMIENTOS
INNER JOIN CUENTAS ON MOVIMIENTOS.IDCUENTA = CUENTAS.IDCUENTA
WHERE NUMCUENTA = @numCuenta
ORDER BY FXMOVIMIENTO DESC
END
La ejecucin del procedimiento se realiza normalmente.

EXEC spu_MovimientosCuenta '200700000001'

El resultado de la ejecucin ...
NUMCUENTASALDO_ANTERIORSALDO_POSTERIORIMPORTEFXMOVIMIENTO

20070000000150.99100.9950.0020070825
16:18:36.490
2007000000010.9950.9950.0020070823
16:20:41.183
20070000000150.990.9950.0020070823
16:16:29.840
2007000000010.9950.9950.0020070823
16:14:05.900

TRIGGERS
Un 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 <Trigger_Name, sysname, Trigger_Name>

ON <Table_Name, sysname, Table_Name>
AFTER <Data_Modification_Statements, , INSERT,DELETE,UPDATE>
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for trigger here
END

Antes de ver un ejemplo es necesario conocer las tablas inserted y deleted.

Las instrucciones de triggers DML utilizan dos tablas especiales denominadas inserted y deleted. SQL
Server

2005

crea

administra

automticamente

ambas

tablas.

La

estructura

de

las

tablas inserted y deleted es la misma que tiene la tabla que ha desencadenado la ejecucin del
trigger.
La primera tabla (inserted) solo est disponible en las operaciones INSERT y UPDATE y en ella estn
los

valores

resultantes

despues

de

la

insercin o

actualizacin.

Es

decir,

los

datos

insertados. Inserted estar vacia en una operacin DELETE.

En la segunda (deleted), disponible en las operaciones UPDATE y DELETE, estn los valores
anteriores

a la

ejecucin

de

la

actualizacin

borrado.

Es

decir,

los

datos

que

sern borrados. Deleted estar 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 que inserted y deleted tienen
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_CUENTAS
ON CUENTAS
AFTER UPDATE
AS

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 INSERTED
END
La siguiente instruccin provocar que el trigger se ejecute:

UPDATE CUENTAS
SET SALDO = SALDO + 10
WHERE IDCUENTA = 1
Una consideracin a tener en cuenta es que el trigger se ejecutar aunque la instruccion DML
(UPDATE,

INSERT

DELETE

no

haya

afectado

caso inserted y deleted devolveran un conjunto de datos vacio.

Podemos especificar a que columnas de la tabla debe afectar el trigger.

ALTER TRIGGER TR_CUENTAS

ON CUENTAS
AFTER UPDATE
AS
BEGIN
-- SET NOCOUNT ON impide que se generen mensajes de texto
-- con cada instruccin
SET NOCOUNT ON;

ninguna

fila.

En

este

IF UPDATE(SALDO) -- Solo si se actualiza SALDO

BEGIN
INSERT INTO HCO_SALDOS
(IDCUENTA, SALDO, FXSALDO)
SELECT IDCUENTA, SALDO, getdate()
FROM INSERTED
END
END
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_CUENTAS

ON CUENTAS
AFTER UPDATE
AS
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 INSERTED

ROLLBACK
END
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_CUENTAS

DISABLE TRIGGER TR_CUENTAS ON CUENTAS
GO
-- activa el trigger TR_CUENTAS
ENABLE TRIGGER TR_CUENTAS ON CUENTAS
GO
-- Desactiva todos los trigger de la tabla CUENTAS
ALTER TABLE CUENTAS DISABLE TRIGGER ALL
GO
-- Activa todos los trigger de la tabla CUENTAS
ALTER TABLE CUENTAS ENABLE TRIGGER ALL

Trigger DDL
Los 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 <trigger_name, sysname, table_alter_drop_safety>
ON DATABASE
FOR <data_definition_statements, , DROP_TABLE, ALTER_TABLE>

AS
BEGIN
...
END
La siguiente instruccin impide 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
BEGIN
RAISERROR ('No est permitido borrar ni modificar tablas !' , 16, 1)
ROLLBACK TRANSACTION
END