You are on page 1of 153

CTEDRA

DATOS
CATEDRTICO :
ESTUDIANTES:

ADMINISTRACIN DE BASE DE

Lic. Adm. MARTNEZ BRAVO, Fermn


CERRN PIAS, Talita
HUAMN ROMERO, Nidia

SEMESTRE:
TURNO :

VI
Tarde

Agradecemos al docente
de la ctedra, por su constante
exigencia, orientacin, enseanzas y
consejos para forjar en nosotros
buenos profesionales.

Introduccin
En la poca actual, la informacin y su tratamiento automatizado no slo
esnecesaria 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 deciden 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 personal.

Entonces podra decirse que el segundo en importancia sera su informacin,


aunque probablemente y en muchos casos sta ltima sea ms difcil de
reemplazar que el 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 del rea de sistemas de la organizacin.

Las alumnas

CAPITULO I

DISEO DE SISTEMAS DE DATOS


1.1.

Fundamentos del diseo de sistemas de datos


1.1.1. Dato

Definicin de datos encontrada en un diccionario: "Dato: Antecedente que


permite llegar ms fcilmente al conocimiento de una cosa". Pequeo Larousse
El dato es la representacin de un mensaje.
Entonces la definicin se da en un contexto donde existe comunicacin:
- Entre personas
- 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).

1.1.2. 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 personas que interpretarn 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.

1.1.3. 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 medio donde residirn los
datos ni a la forma o tecnologa de acceso a los mismos.
Muchas veces el slo 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.
1.1.4. Medio y Representacin

a. Medio de Almacenamiento
El medio es el objeto real, mecanismo o tecnologa disponible para que los
datos (representaciones abstractas de informacin) permanezcan, sean
registrados, accedidos, modificados o eliminados. En el contexto de bases de
datos almacenadas y accedidas en forma mecnica (con uso de computadoras,
por ejemplo), actualmente los medios ms usados son:
- Medio Magntico
- Medio ptico

b. Representacin
La representacin, al ms bajo nivel puede ser:
- Analgica o contina
- Digital o discreta.

En la historia de la telemtica la evolucin (y avances) ha sido desde la


tecnologa analgica a la digital.

1.1.5. Sistema de administracin de base de datos

DBMS por sus siglas en ingls (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 datos. Provee facilidades para la administracin del conjunto
como toma de respaldos, 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 (RDBMS) es el SQL,
que se ver ms adelante.
El lenguaje no slo debe permitir la comunicacin para acceder los datos sino
para definirlos.
Actualmente los software RDBMS se encuentran en diversas plataformas,
aunque

son

desarrollados

para

arquitecturas

tanto

mainframe

como

cliente/servidor (tema tocado ms adelante) corriendo en el "back-end" (host o


servidor) usando la infraestructura de red disponible para la comunicacin con
los usuarios.

1.1.6. Caractersticas y Funciones relacionadas de los


DBMSs

a. Escalabilidad
Capacidad de mejorar con el incremento de recursos invertidos (generalmente
los recursos pueden medirse en dinero). Un DBMS debe permitir inversin de
recursos a 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.

b. Rendimiento
Caracterstica 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.

c. 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 slo es la consideracin de portabilidad del
producto (el software mismo) sino los datos que la base de datos administra.

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

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

f. Escalabilidad Horizontal
Capacidad de incrementar la cantidad de usuarios de la base de datos o la
cantidad de estaciones con conexin a la 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.
Una caracterstica que est relacionada con la escalabilidad es la "apertura" o
caracterstica de sistema abierto que posea el DBMS : cunto "middleware" es
necesario para la conectividad entre cliente y servidor (o host) y si es necesario
tener corriendo una versin "RUN-TIME" siempre en el front-end.
Si la aplicacin y la base de datos son instaladas en una misma computadora
se dice que es un "cliente local".
En caso que la aplicacin se instale en otro equipo diferente al del servidor de
base de datos, se dice que es un "cliente remoto".
g. Escalabilidad Vertical
Capacidad para incrementar el tamao y/o la potencia del servidor y as
obtener mejoras con un mismo producto.
1.1.7. Responsabilidades del Departamento de Sistemas
Reconocida la importancia de la informacin en las organizaciones, existen
cargos y funciones dentro del departamento de sistemas que persiguen el
objetivo de garantizar el correcto manejo y control de este recurso (los datos).
El administrador de datos (DA) es la persona que conoce los datos de la
organizacin, las necesidades de informacin y su uso, de manera que es un
apoyo a nivel gerencial para la direccin de la organizacin. El DA es quien
sabe qu datos comunes son usados por diferentes reas de la organizacin,
aunque en ocasiones un mismo dato tenga varias denominaciones.
Decide qu datos merecen pertenecer a la base de datos de la organizacin y
cules otros pueden mantenerse como "departamentales". Entonces debe
mantener un constante contacto con los usuarios finales de la informacin,
tanto para mantenerse actualizado en nuevas necesidades y requerimientos,
como para mantenerlos actualizados sobre nuevas aplicaciones y facilidades
de informacin desarrolladas. El DA tambin establece las polticas para la
administracin de los datos una vez almacenados y las coordina con el
Administrador de la base de datos. Si bien el DA no es necesariamente un

tcnico especialista en bases de datos, debe por lo menos conocer las


posibilidades y alternativas tecnolgicas para el caso. El Administrador de la
base de datos (DBA) si es un profesional en informtica que tiene la
responsabilidad de aplicar la tecnologa disponible para la implementacin y
mantenimiento de la base de datos de la organizacin. Define y crea las
estructuras de datos. Se responsabiliza por la integridad y respaldo de la
informacin, definiendo los procedimientos correspondientes y haciendo uso de
las facilidades que para tal efecto le proporciona el software DBMS.
El DBA es quien garantiza el adecuado nivel de funcionamiento (a veces
llamado
"nivel de servicio") as como la disponibilidad de los datos en el cronograma y
horario establecido para la operativa del negocio/empresa/institucin.

1.1.8. Los tres niveles de la arquitectura de datos

a. El nivel Externo
Tambin llamado nivel de visin o "subesquemas" (segn J.Martin) es el nivel
ms cercano al usuario final, o sea es la forma cmo estos perciben los datos.
Generalmente a un usuario le interesa slo una parte de toda la base de datos
y no le interesa los aspectos "tcnicos" deseando slo indicar QUE datos son
los que requiere.

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

c. El nivel Interno
Tambin llamado nivel fsico, describe CMO son almacenados los datos en la
base de datos.
Una parte de este nivel debe ser visible al 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 DBMS.

1.1.9. Independencia de datos


Es la capacidad de modificar la definicin de un nivel sin afectar la de los
niveles superiores.

a. Independencia fsica de los datos


Un DBMS proporciona independencia fsica de los datos pues los usuarios de
la base de datos y las aplicaciones no dependen de la estructura fsica de la
base de datos almacenada (C.J.Date).

b. Independencia Lgica de datos


Un DBMS proporciona independencia lgica de los datos si los usuarios de la
base de datos y las aplicaciones no dependen de la estructura lgica de la
base de datos, la que puede presentar dos aspectos:

Crecimiento

Como expansin de los datos referidos a informacin que ya exista o nuevos


datos referidos a informacin que no se almacenaba en la base de datos

Reestructuracin

En algunas ocasiones es necesario modificar la estructura lgica de la base de


datos, para efectos de - por ejemplo - disponibilidad. Estos casos no deben
afectar a los usuarios de la base de datos.

1.1.10.

Modelos de datos

Vehculo para describir la realidad (Batini/Ceri/Navathe).


Coleccin de herramientas conceptuales para describir datos, relaciones entre
estos, semntica asociada y restricciones de consistencia (Korth/Silberschatz).
Un modelo de datos es la representacin de informacin relevante a una
realidad (una organizacin por ejemplo) para que pueda ser manejada por
otras personas, diferentes a quienes confeccionaron el modelo.
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.
Ms an, la mayora de herramientas que apoyan la ingeniera de software y el
desarrollo de sistemas de informacin (CASEs) han adoptado algn "sabor" del
modelo Entidad-Relacin original (Peter Chen).
Los modelos para diseo/planificacin permiten describir los niveles conceptual
(de esquema) y externo (de subesquema).
Los modelos para implementar software de administracin de base de datos,
deben permitir cubrir todos los niveles de la arquitectura de datos.
Hasta hace algn tiempo, todava tenan cierta vigencia los modelos jerrquicos
y "de red" para DBMS sin embargo actualmente es indiscutible la total vigencia
de losRDBMS (relacionales) para ambientes transaccionales.

1.1.11.

Los modelos de datos para DBMS

Se describen mediante:
a. Una estructura:
Cmo son diferenciados los datos, as como agrupados de manera que reflejen
significado (informacin).
b. Un conjunto de Operaciones:
Las operaciones deben permitir manejar tanto los datos individuales como las
estructuras (agrupaciones de datos).

c. Definiciones de integridad:
Reglas y/o lmites para la existencia y los valores de los datos, que hagan a
estos vlidos y coherentes para el significado en conjunto.

1.1.12.

Cliente/Servidor

Es la actual arquitectura para sistemas con bases de datos. Cliente/Servidor


:distribucin de aplicaciones y/o datos en una red de computadoras.
Cliente/Servidor, conocido por sus siglas C/S, tambin es sinnimo de
computacin abierta que permite utilizacin de hardware y software variado, sin
dependencia de un slo proveedor.

a. Tipos de Servidores

Servidor de Archivos

El cliente (tpicamente una PC) requiere archivos a travs de la red. Se


requiere mucho intercambio de mensajes. De utilidad para repositorios de
diferentes tipos de archivos como documentos, imgenes, etc.

Servidor de base de datos (DBMS)

El cliente enva requerimientos en SQL, la consulta u operacin asociada es


ejecutada por el software (DBMS) que corre en 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
fracasarn como una sola unidad (transaccin).
Esta funcionalidad (de procedimientos almacenados) es provista por productos
DBMS modernos (como por ejemplo el DB2 de 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 del protocolo HTTP para que el servidor
provea los requerimientos correspondientes (un documento HTML por
ejemplo).

1.1.13.
Las

aplicaciones

Tipos de aplicaciones
cliente/servidor

tambin

pueden

ser

clasificadas

(diferenciadas) de acuerdo a cmo es distribuido el proceso entre el cliente y el


servidor.
a. El cliente ligero (o servidor pesado) distribuye ms funciones en el lado
delservidor. Bajo este esquema se trata de minimizar el trfico entre
cliente y servidor (trfico en la red) creando niveles ms abstractos de
servicios.
b. 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 slo se realizarn las funciones de
interaccin y presentacin (interfaz al usuario) sino el procesamiento de los
datos que son extrados del servidor).

1.1.14.

Modelos de Distribucin Cliente/Servidor

No existe una regla para dividir una aplicacin, sin embargo es razonable situar
las funciones y datos ms cerca posible para la operativa de la organizacin.
Esto sin embargo y datos.
En su forma ms simple la lgica de presentacin es slo la interfaz al usuario
que accede a procedimientos transaccionales ya existentes en el servidor. La
lgica de presentacin puede 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 sobre dnde
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 llegar al proceso de los datos requeridos y su
evolucin a la cadena de clientes que fuera formndose.

Datos Distribuidos
Slo los resultados son devueltos al proceso cliente que invoc 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.

1.1.15.

Aplicaciones distribuidas en tres niveles (versus

2 niveles)

Esta distribucin se basa prcticamente en el mismo concepto de divisin de la


aplicacin - ya visto en tipos de aplicaciones.
Al existir bsicamente tres tipos de lgica en una aplicacin (de presentacin,
de negocio y de datos), estas pueden ser distribuidas en mnimo 2 (para hablar
de cliente/servidor) o ms computadoras.

Al tener ms de 2 equipos dnde distribuir los procesos de negocio, pueden


existir servidores de aplicacin o de transacciones que ejecuten funciones
accesibles por muchos procesos cliente con distintas formas posibles de
interaccin con el usuario.
Los servidores de aplicacin se desarrollan como funciones "encapsuladas",
reutilizables, con una funcin e interfaz exactamente definidas.
Algunos DBMSs, al ofrecer procedimientos almacenados que sirven para
desarrollar lgica de negocio en el servidor, afirman que esto es
funcionalmente equivalente a una arquitectura de tres niveles, sin embargo
esto no es tan cierto pues todos los desarrollos estn ligados al software
DBMS.
Cliente/servidor de tres niveles, ms conocido por 3-tier ha sido usado en
muchos contextos:

Primero se us para describir la particin fsica de una


aplicacin a travs dePCs (tier-1), servidores departamentales
(tier-2) y servidor principal o host (tier-3).

Luego se us para describir el particionamiento entre la PC


(tier-1), la base de datos local en la misma estacin PC (tier-2)
y la base de datos empresarial (tier-3).

Actualmente cuando se habla de C/S 3-tier se hace referencia


a la PC (tier-1) el servidor de aplicaciones (tier-2) y el servidor
de base de datos (tier-3).

1.1.16.

Componentes 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 grfica (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 en el servidor.


Se puede clasificar en tres categoras de middleware:
a. 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.
b. El sistema operativo de red
Aunque el trmino "de red" ya prcticamente qued en el pasado, pues los
sistemas operativos ofrecen la funcionalidad correspondiente, son las funciones
"de red" las que principalmente son usadas en un ambiente cliente servidor:
Servicios de directorio, comparticin de recursos, seguridad, etc.
Facilidades para internet/intranet son proporcionadas tambin por los
sistemasoperativos.

c. Servicios especficos
Tambin deben 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.

CAPITULO II
TEORA DE RELACIONES MODELO ENTIDAD-RELACIN

2.1.

Definiciones

2.1.1. Conjunto
Aunque en general un conjunto puede agrupar objetos de diversos tipos, para
los casos de estudio se tendr en cuenta que un conjunto agrupa objetos del
mismo tipo.
2.1.2. Subconjunto
Conjunto formado por ningn, algn o todos los elementos de un conjunto.

2.1.3. Cardinalidad
Cantidad de elementos de un conjunto

2.1.4. Producto Cartesiano


En caso de ser dos los conjuntos a "multiplicarse" cada elemento de este
conjunto resultado es un "par ordenado" que tiene como primer elemento a uno
que pertenece al primer conjunto y como segundo a uno del segundo.

2.2.

Relacin

Una relacin entre dos o ms conjuntos es un subconjunto del producto


cartesianoentre estos. Matemticamente una relacin es "fija" o constante a
menos que se indique lo contrario: una vez definida, no vara.
Como se ver ms adelante, esta es una de las diferencias con el modelo
relacional: una relacin de datos si es variable y podr crecer tanto en
cardinalidad (extensin) como en grado (cantidad de datos relacionados).

2.2.1. El aspecto semntico:


Generalmente existe un criterio para la definicin de este subconjunto
"relacin" y es precisamente este criterio el que debe dar el nombre a la
relacin.
El nombre de la relacin hace referencia a un elemento del primer conjunto
teniendoentonces la relacin, una "direccin".

2.2.2. Grado de una relacin


Es la cantidad de conjuntos que intervienen en el producto cartesiano de donde
se toma el subconjunto relacin.

2.2.3. Tupla

Cada elemento del conjunto relacin:

Un par ordenado si el grado es 2.Una terna ordenada si el grado es 3.

Entre dos conjuntos puede existir ms de una relacin.

Efectivamente, incluso dejando de lado el aspecto semntico (de significado),


bastar referirse a la definicin de relacin:
Al ser la relacin un subconjunto, y al existir toda una gama de posibilidades
para definir un subconjunto a partir de un conjunto, existirn tantas posibles
relaciones como subconjuntos puedan definirse.

2.2.4. Desde un punto de vista semntico:


No existe limitacin para el criterio de eleccin del subconjunto del producto
cartesiano, ms que el de la definicin de la relacin misma, por lo tanto cada
elemento del primer conjunto puede repetirse en ms de un par ordenado. Esto
es, que puede relacionarse con ms de un elemento del segundo conjunto.
Y viceversa (por el mismo motivo).

2.3.

Relacin Inversa

Una relacin inversa a otra es el mismo conjunto de grupos de la relacin, pero


con sus elementos invertidos. Desde un punto de vista semntico es la misma
relacin pero haciendo referencia primero a los elementos del segundo conj
unto. Entonces es simplemente un cambio de "direccin".
El nombre de la relacin inversa har referencia a un elemento del segundo
conjunto.

2.4.

Cardinalidades de una Relacin

Cardinalidad mnima de una relacin

Sean dos conjuntos A y B.


La cardinalidad mnima de R(A,B) es la mnima cantidad de tuplas
(interrelaciones) que cada elemento de A puede tener con elementos de B

Cardinalidad mxima de una relacin

Sean dos conjuntos A y B.


La cardinalidad mxima de R(A,B) es la mxima cantidad de tuplas
(interrelaciones) que cada elemento de A puede tener con elementos de B
En el caso que la relacin sea descrita explcitamente es fcil determinar las
cardinalidades mnima y mxima.
En caso que los conjuntos a relacionarse sean expresados en forma genrica,
las cardinalidades deben obtenerse de la semntica asociada a la relacin.
Ejemplo
P = {personas del mundo}
C = {ciudades del mundo}
card-mn R1(P,C) = 1
card-mx R1(P,C) = 1

Relacin Recursiva. Una relacin se dice recursiva cuando el producto


cartesiano de donde se extrajo, fue realizado sobre el mismo conjunto.
Dicho de otro modo, cuando se relacionan elementos de un mismo
conjunto.
Ejemplo
R3 = "es padre de" se define del conjunto P al conjunto P.

2.5.

Clasificacin

Es el proceso de definir o encontrar subconjuntos a partir de un


conjunto genrico.
1. Tipos de clasificacin:

A. De acuerdo a la cobertura sobre el conjunto genrico

A.1. Clasificacin Total


Cada elemento del conjunto genrico corresponde al menos a un elemento de
los subconjuntos. Dicho de otro modo, si la cardinalidad mnima de la relacin
entre el conjunto genrico y sus subconjuntos es 1.

A.2.Clasificacin Parcial
Existe algn elemento del conjunto genrico que no corresponde con ningn
elementode los subconjuntos. Dicho de otro modo, si la cardinalidad mnima de
la relacinentre el conjunto genrico y sus subconjuntos es 0.

B. De acuerdo a la cobertura sobre los subconjuntos

B.1. Clasificacin Exclusiva


Cada elemento del conjunto genrico corresponde a lo ms a un elemento de
algn subconjunto. Dicho de otro modo, si la cardinalidad mxima de la relacin
entre el conjunto genrico y sus subconjuntos es 1.

B.2. Clasificacin Inclusiva o Superpuesta


Existe algn elemento del conjunto genrico que corresponde elemento de ms
de un subconjunto. Dicho de otro modo, si la cardinalidad mxima de la
relacin entre el conjunto genrico y sus subconjuntos es mayor que 1.
En el ejemplo se muestra - de una manera simplificada - el caso de un banco
que ha clasificado a las personas relacionadas con la organizacin en "clientes"
y
"empleados".

2.6.

El Modelo Entidad-Relacin

En 1976 Peter Chen publica "The Entity-Relationship Model - toward a unified


view of data".Este modelo diferencia a los objetos, de quienes representamos
datos, enentidades y relacio nes, 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 "sabor" este modelo.

1) ENTIDAD

Una entidad es una "cosa" u "objeto" del mundo real, con existencia
independiente y distinguible de los dems objetos. Cada entidad tiene un
conjunto de propiedades y valores que la identifican de forma unvoca. Esta
puede ser tanto tangible (existencia fsica), ejemplo: Un carro, como intangible
(existencia conceptual), ejemplo: Un curso universitario. Una entidad es un
objeto concreto o abstracto existente y distinguible de otros. Se representa por

un rectngulo y se le nombra con un nombre en singular, que hace referencia a


la instancia y no al conjunto de entidades del mismo tipo.

2) ATRIBUTO
Dato (abstraccin) para identificar o describir una entidad. Se representa con
un nombre (del dato) dentro de una elipse unida o "conectada" por una lnea a
la entidad asociada.
Las propiedades que califican y le dan vida a la entidad se denominan
atributos.
Ejemplo: la entidad persona se puede describir por las siguientes propiedades:
cdula, nombre, direccin, sexo, peso, altura, color, tipo de sangre, salario.
Cada entidad tendr un valor por cada uno de los atributos, que posteriormente
ser almacenado en la base de datos. El valor de cada atributo est
enmarcado en un conjunto de valores permitidos llamado Dominio. Ejemplo: el
conjunto de valores permitidos (dominio) para el atributo cdula pueden ser
todos los enteros positivos.
2).1. Tipos de Atributos:
Simples: No divisible, es decir es un atributo atmico. Ejemplo: El atributo
cdula, su propiedad no tiene sentido dividirla, no tendr significado para la
entidad, ya que la concepcin de este es un nmero indivisible.
Compuesto: Est conformado por un conjunto de partes que en el momento
de dividirlas pueden formar otros atributos sin perder el sentido bsico de la
propiedad que est calificando la entidad. Ejemplo: los atributos nombre,
direccin pueden estar conformados en su naturaleza funcional por varias
partes. Si tomramos el atributo nombre con un valor de: JUAN PEREZ
CORREA, sin perder la propiedad del mismo, se podrn crear otros dos
atributos simples tales como: primer_apellido,

segundo_apellido. As se tendr: (nombre, JUAN), (primer_apellido, PEREZ),


(segundo_apellido, CORREA).
Univaluados: (univalorados o monovaluados): Son atributos que en el
transcurso del tiempo slo toman un valor para una entidad en particular.
Ejemplo: El atributo cdula, solo toma un valor para una entidad persona en
particular.
Multivaluados: (multivalorados): Son atributos que en el transcurso del tiempo
pueden tener un conjunto de valores para una entidad en particular. Ejemplo: El
atributo grado acadmico para el conjunto de entidades persona puede tomar
diferentes valores desde 0 o primaria o medio, entre otros. Tambin es
caracterstico que este tipo de atributo maneje rangos de valores. Ejemplo: el
atributo sexo, puede tener un rango de valores [F,M] y tomar uno de estos en
algn instante en el tiempo para una entidad especfica.
Nulos: Son atributos que en cualquier instante en el tiempo pueden tomar el
valor nulo para una entidad en particular.
Derivado: Son atributos cuyo valor depende de los valores de otros atributos o
entidades. Ejemplo: el atributo salario pude derivarse a partir del clculo de los
siguientes valores:
PARAMETROS(salario_base,

5000),

NOVEDADES(nro_horas_trabajadas,

240), el valor que tendra el atributo en un instante en el tiempo ser:


PERSONA(salario,1200000).
3) RELACIN
Instancia o elemento del conjunto relacin entre dos o ms conjuntos de
entidades.
Tupla. Se representa por un rombo "conectado" a las entidades relacionadas.

Notacin Genrica para cardinalidades mnimas y mximas en


modelos Entidad-Relacin

En algunas ocasiones, para describir una realidad con un modelo, es suficiente


referirse a las cardinalidades mximas (el lmite de relaciones que puede tener
un elemento de un conjunto de entidades con elementos del otro conjunto de
entidades.

La notacin Information Engineering:

Un crculo corresponde a una cardinalidad mnima CERO.

Una lnea transversal corresponde a una cardinalidad mnima y el


algunasocasiones mxima de UNO.

Tres lneas concurrentes en un punto corresponden a cardinalidad mxima


de msde uno o MUCHOS.

El nombre de la relacin suele colocarse en el sentido ("direccin de la


relacin")

uno a

muchos.

Notacin explcita para cardinalidades


Puede expresarse en forma explcita las cardinalidades, para casos que
sean necesarias las cantidades exactas de las mismas.
En la diapositiva:
m : cardinalidad mnima de R(A,B)

Con cuntas entidades del conjunto de entidades B puede relacionarse


como mnimo una entidad del conjunto de entidades A.
M : cardinalidad mxima de R(A,B) Con cuntas entidades del conjunto
de entidades B puede relacionarse como mximo una entidad del
conjunto de entidades A.

cardinalidad mnima de R-1 (B,A)


Con cuntas entidades del conjunto de entidades A puede relacionarse como
mnimo una entidad del conjunto de entidades B.
N : cardinalidad mxima de R-1 (B,A)
Con cuntas entidades del conjunto de entidades A puede relacionarse como
mnimo una entidad del conjunto de entidades B.

2.7.

Dependencia Existencial

B depende existencialmente de A si para que exista cada entidad de B debe


existir una correspondiente entidad de A: la cardinalidad mnima de R-1 es 1. A
la entidad de quien depende otra se le denomina entidad "fuerte" o "padre" de
la otra. A la entidad dependiente se le denomina "dbil" o "hijo"
Las entidades dbiles tienen por lo menos un atributo que las asocie con la
entidad de quien depende. Este atributo ser uno que identifique a la entidad
fuerte.

Clasificacin

Tal como se vio, la relacin de clasificacin (o viceversa, la generalizacin) es


una relacin de inclusin entre conjuntos. En este caso los conjuntos son
conjuntos de entidades.Los subconjuntos de entidades son llamados tambin
CATEGORAS.
La notacin: ISA proviene del ingls "is a" que significa ES UN, por lo que la
notacin hace referencia a la relacin del conjunto de entidades categora al
conjunto de entidades genrico. Esto es, en el sentido de la generalizacin.
Una entidad del conjunto de entidad genrico puede ser una entidad de las
categoras o ninguna en caso de una clasificacin parcial.

Generalizacin
Muchas veces encontrar iguales atributos es indicativo de una generalizacin.
Slo indicativo, ms no necesariamente.

Agregacin

Mecanismo usado en un modelo Entidad-Relacin para permitir expresar


relaciones entre relaciones.
Al ser una relacin un conjunto, puede vrsele como una "Entidad Virtual" de
manera que pueda ser a su vez relacionada con otra u otras entidades.
La agregacin se representa agrupando grficamente mediante un rectngulo
con lneas discontinuas a las entidades (rectngulos) relacionadas (por un
rombo).

2.8.

Grados de las relaciones

Tal como se vio el grado es la cantidad de conjuntos que se relacionan. A


mayor grado, mayor la dificultad de comprender la semntica asociada a la
relacin. Adems existe siempre la duda de si algo es una entidad o una
relacin. Este es uno de los principales puntos criticados al modelo E-R.
Una relacin de grado mayor a dos siempre se podr convertir en tres o ms
relaciones binarias (de grado 2).
Las relaciones binarias no slo son ms fciles de comprender sino que en
estas pueden apreciarse mejor las dependencias existenciales.

CAPITULO III

EL MODELO RELACIONAL

3.1.

Introduccin

El modelo relacional fue propuesto en 1970 por Codd, y la popularidad de este


modelo ha ido creciendo lenta pero firmemente, de manera que el trmino
relaciona l ha llegado a ser comn entre los profesionales informticos. El
modelo relacional de datos es un modelo simple, potente y formal para
representar la realidad. Tambin ofrece una base firme para enfocar y analizar
formalmente muchos problemas relacionados con la gestin de bases de datos,
como el diseo de la base de datos, la redundancia, la distribucin, etctera. El
formalismo y una base matemtica son las piedras angulares en

Varios avances han tenido lugar en las ltimas dos dcadas que sealan la
falta deexpresividad y riqueza semntica del modelo relacional. Sin embargo, la
sencillez del modelo ha facilitado la construccin de lenguajes de consulta e
interfaces para los usuarios finales de fcil utilizacin, y ha resultado en una
productividad ms alta de los programadores de bases de datos. La gestin de
bases de datos relacinales ser una tecnologa muy til durante varios aos, o
incluso dcadas. En esta parte se muestra cmo ir desde el modelo conceptual
E-R al modelo relacional para implantar una base de datos. Tambin se
muestra cmo tomar un conjunto de relaciones existentes y aplicarles
retroingeniera para convertirlas en un esquema ER, captando la semntica
propuesta para un mejor entendimiento.
El elemento bsico del modelo es la relacin, y un esquema de base de datos
relacional es una coleccin de definiciones de relaciones. El esquema de cada
relacin es una agregacin de atributos; el conjunto de todos los valores que
puede adoptar un atributo en particular se denomina dominio de ese atributo.

Un caso de relacin (tambin llamado extensin de la relacin) es una tabla


con filas ycolumnas. Las columnas de las relaciones corresponden a los
atributos; las filas, denominadas tupias, son colecciones de valores tomados de
cada atributo, y desempean la misma funcin que los casos individuales de
entidades en el modelo ER. El grado de una relacin es el nmero de
columnas; la cardinalidad de una relacin es el nmero de tupias. La siguiente
figura muestra un ejemplo de los conceptos citados.
La relacin ESTUDIANTE tiene tres atributos (NOMBRE, EDAD y SEXO) y
cinco tupias, cada una representando nombre, edad y sexo de un estudiante.
Por tanto, el grado y la cardinalidad de ESTUDIANTE son tres y cinco,
respectivamente.
La definicin matemtica 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 dominios D1, D2,..., Dn, un caso de relacin de grado n es
simplemente un subconjunto del producto cartesiano D1 x D2 ... Dn. Esta
definici n destaca una importante propiedad de las relaciones, a saber, que
son conjuntos de tup las en el sentido matemtico: una relacin en ningn
momento puede tener tupias duplicadas.
Sin embargo, la mayora de los sistemas relacinales no imponen esta
restriccin, yaque en diversas situaciones pueden ocurrir duplicados, y puede
ser til mantenerlos.
En trminos estrictos, tampoco importa el orden de las tupias en una relacin.

3.2.

Claves Primarias y Forneas (externas)

Llave primaria: 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 slo con el mismo dominio, sino con el mismo
significado).
En el modelo relacional, el concepto de clave est definido de una manera muy
Similaral concepto de identificador en el modelo ER; una clave de una relacin
es un conjunto de atributos de la relacin que identifica de manera nica cada
tup la de cada extensin de esa relacin. As, la nica diferencia entre nuestro

uso de identificadores y claves es que en el modelo relacional slo se acepta la


identificacin interna.
En general, una relacin puede tener ms de una clave, y cada clave se
denomina clave candidata. Por ejemplo, la relacin PERSONA puede tener dos
claves candidatas: la primera un nmero de seguro social (NSS); la segunda
una clave compuesta formada por (APELLIDO, NOMBRE). Es comn designar
una

de

las

claves

como

clave

primaria

de

la

relacin.

Nuestro

convencionalismo es subrayar aquellos atributos que componen la clave


primaria.
La sencillez del modelo relacional proviene del hecho de que todas las
relaciones se definen de manera independiente; no hay conceptos como los de
jerarqua, conexin o enlace entre las relaciones en el modelo. Sin embargo,
las interrelaciones del modelo
ER se pueden representar en el modelo relacional por una operacin explcita
de
equirreunin (equi-join) entre atributos de tablas diferentes. Si realizamos una
reunin (join), que es la operacin del lgebra relacional para hacer
correspondencias entre dos tablas, la correspondencia debe hacerse entre
atributos comparables, esto es, atributos en el mismo dominio. La siguiente
figura muestra tres relaciones independientes:

CURSO, ESTUDIANTE y EXAMEN, para la base de datos escolar. La


interrelacinde uno a muchos entre ESTUDIANTE y EXAMEN se obtiene
igualando los atributos
NOMBRE

de

ESTUDIANTE

NOMBRE_ESTUDIANTE

de

EXAMEN.

Obsrvese que por cada caso de ESTUDIANTE existen cero, uno o ms casos
de EXAMEN, relacionados por el mismo nombre de estudiante. De manera
similar, la interrelacin de uno a muchos entre CURSO y EXAMEN se obtiene
igualando los atributos
CDIGO de CURSO y NUMERO-CURSO de examen.
3.2.

Restricciones de integridad en los esquemas relacinales de bases


de datos

Ahora veremos las restricciones de integridad que pueden ser especificadas en


un esquema relacional. Se espera que tales restricciones, una vez
especificadas, se cumplan para cada caso de base de datos de ese esquema.
Sin embargo, en los productos comerciales de DBMS actuales no siempre
pueden ser especificadas todas esas restricciones. Adems, aun especificadas,
no se obliga automticamente el cumplimiento de todas ellas. Se consideran
tres tipos de restricciones como parte del modelo relacional: restricciones de
clave, de integridad de entidades y de integridad referencial. Las restricciones
de clave especifican las claves candidatas de cada esquema de relacin; los
valores de las claves candidatas deben ser nicos para cada tupia en cualquier
caso de ese esquema de relacin. En el ejemplo de la figura anterior,
NOMBRE es una clave para ESTUDIANTE, CDIGO es una clave para
CURSO, y el par (NUMERO_CURSO, NOMBRE_ESTUDIANTE) es un clave
para estudiante.
En una base de datos de muchas relaciones, habr normalmente restricciones
de integridad referencial que correspondan a las interrelaciones de las
entidades representadas por las relaciones. Por ejemplo, en la base de datos
de

la figura anterior,

la

relacin

EXAMEN tiene la

clave

primaria

(NUMERO_CURSO,
NOMBRE_ESTUDIANTE). El atributo NOMBRE_ESTUDIANTE se refiere al
estudiante que hizo el examen, por tanto, se puede designar

NOMBRE_ESTUDIANTE como clave ajena de EXAMEN, refirindose a la


relacin
ESTUDIANTE.
Las restricciones de integridad de entidades establecen que ningn valor de
clave primaria puede ser nulo. Esto es porque el valor de la clave primaria se
usa para identificar las tuplas individuales de una relacin; permitir valores
nulos para la clave primaria implica que no se pueda identificar algunas tup las.
Por ejemplo, si dos o ms tupias tuvieran un valor nulo como clave primaria, no
podramos distinguirlas.
Las restricciones de clave y de integridad de la entidad se especifican en
relaciones individuales. La restriccin de integridad referencial, en cambio, se
especifica entre dos relaciones, y se usa para mantener la congruencia entre
las tuplas de las dos relaciones. Informalmente, la restriccin de integridad
referencial establece que una tupia de una relacin que haga referencia a otra
relacin debe referirse a una tupla existente en esa relacin.

3.3.

Correspondencia de esquemas del modelo E-R al modelo relacional

Este apartado presenta una metodologa para el diseo lgico que tiene como
objetivo el modelo relacional. Se supone que el punto de partida es un
esquema lgico ER. El resultado de la correspondencia es un esquema
relacional. Este consiste en un conjunto de definiciones de relaciones, en el
cual cada relacin tiene una clave primaria. Las relaciones producidas por la
transformacin

de

esquemas

corresponden

entidades

bien

interrelaciones, y mantienen la misma forma normal. El concepto de forma


normal fue propuesto en la literatura relacional como una medida de la
ausencia de las anomalas o dificultades que surgen cuando se trata de
insertar, eliminar o modificar registros de las bases de datos relacinales.
Cuanto ms alta sea la forma normal, mayor ser la pureza o bondad de
la definicin lgica del esquema relacional. Si el lector desea una explicacin
detallada de las formas normales, puede consultar en la siguiente prctica.
La metodologa propuesta en esta seccin convierte un esquema ER en un
conjunto de entidades e interrelaciones, tales que su correspondencia con el
modelo relacional sea sencillo. Esta correspondencia preparatoria consiste
en dos actividades:

a. Laeliminacin de identificadores extemos (este paso tambin se asocia


con la eliminacin de algunas interrelaciones),
b. la eliminacin de atributos compuestos y polivalentes del esquema. Una
vez completada esta correspondencia preparatoria, se est en
condiciones de aplicar los siguientes pasos:
Transformacin de cada entidad del esquema en una relacin.
Transformacin de cada interrelacin: las interrelaciones de muchos
a muchos requieren una relacin individual, mientras que las
interrelaciones de uno a uno o de uno a muchos pueden ser
modeladas aadiendo atributos a las relaciones existentes.

3.4.

Transformacin de entidades

Este paso es bastante simple: se transforma cada entidad del esquema en una
relacin.
Los atributos y la clave primaria de la entidad se convierten en los atributos y la
clave primaria de la relacin. Un ejemplo se muestra en la siguiente figura:

3.5.

Transformacin de interrelaciones de uno a uno

Ahora debemos tratar de las Interrelaciones. Se empieza por considerar las


interrelaciones binarias de una manera general. Se vern las Interrelaciones de
uno a uno, de uno a muchos y de muchos a muchos de manera individual. El
proceso de transformacin es tambin influido por las cardinalidades mnimas
de las dos entidades que participan en la interrelacin.
En principio, las dos entidades E1 y E2 que participan en la interrelacin
producen relaciones individuales; de otro modo se habran fusionado durante el
diseo lgico independiente del modelo. Respecto a la interrelacin, hay que
distinguir si las dos entidades E1 y E2 tienen una participacin total en la
interrelacin, o si una o ambas tienen una participacin parcial en la misma.
As, tenemos los siguientes casos:
3.5.1 Integracin en una relacin. Esta opcin tiene sentido cuando la
participacin de las dos entidades en la interrelacin es total. Hay dos
posibilidades:
Caso 1: Las dos entidades tienen las mismas claves primarias.
Supngase que tantoCLIENTES como INFO_ENVIO tienen la clave

primaria

NUM_CLIENTE.

En

este

caso,

las

dos

relaciones

correspondientes se integran en una relacin combinando todos los


atributos e incluyendo la clave primaria slo una vez. Este caso se ilustra
en la figura (a)
Caso 2: Las dos entidades tienen claves primarias diferentes:
Supngase que CLIENTE e INFO_ENVIO tienen diferentes claves
primarias, digamos
NUM_CLIENTE,

(CODIGO_POSTAL,

CALLE,

NUM_CASA),

respectivamente.
En este caso tambin se integran en una relacin combinando todos los
atributos e incluyendo las claves primarias de ambas. Una de las dos
claves primarias ser la clave primaria de la relacin resultante; por
ejemplo, en la relacin que sigue se escoge NUM_CLIENTE.
ENVIOLCLIENTE (NUM_CLIENTE, NOMBRE_CLIENTE, NUM_CASA,
CALLE, CODIGO_POSTAL)

3.5.2. Definicin de una relacin aparte.


Esta opcin se usa cuando una o las dos entidades tienen una participacin
parcial.
Un ejemplo de cada caso se muestra en las figuras (b) y (c).
Caso 1: Una entidad con participacin parcial. Esto se refiere, por
ejemplo, a los clientes de un banco, a los cuales el banco emite cero o
una tarjetas de crdito. En la figura (b), cada tarjeta de crdito debe
pertenecer a un cliente, pero un cliente puede no tener tarjeta de crdito.
En este caso, las dos relaciones, CLIENTE, y

TARJETA_DE_CREDITO, ya han sido creadas. Se define una relacin


adicional
POSEE_TARJETA (NUM_CLIENTE, TIPO_TARJETA, NUM_TARJETA)
usando la clave primaria de las dos relaciones. Tanto NUM_CLIENTE
como
(TIPO_TARJETA,

NUM_TARJETA)

son

claves

candidatas

de

POSEE_TARJETA, y por consiguiente pueden ser declaradas como la


clave primaria. Obsrvese que se puede usar la primera opcin en este
caso y representar todo en una sola relacin. En ese caso se debe
escoger NUM_CLIENTE como clave primaria de la relacinintegrada;
aquellos clientes que no posean tarjeta de crdito tendrn valores nulos
delos atributos TIPO_TARJETA, NUM_TARJETA.

No se puede

seleccionar
(TIPO.TARJETA, y NUM_TARJETA) como clave primaria de la relacin
integrada, porque en este caso los clientes sin tarjeta de crdito no
podran ser representados.

3.5.3. Transformacin de interrelaciones de uno a muchos


Considrese la interrelacin R entre dos entidades, E1 y E2; supongamos que
R es una interrelacin de uno a muchos. En este caso, se dar cuenta de la
interrelacin incluyendo la clave primaria de E1 en la relacin correspondiente
a E2 como uno o ms atributos simples. Obsrvese que ya se ha dado cuenta
de los identificadores extremos. Por consiguiente, esta transferencia de la clave
no tiene propsitos de identificacin. Los posibles atributos de la interrelacin
tienen que ser trasladados a la relacin que modela la entidad E2. Otra vez son
posibles dos casos:
Caso 1: La entidad en el lado de muchos tiene una participacin
obligatoria. Esto est ejemplificado en la siguiente figura (a), donde hay
una interrelacin de uno a muchos entre ESTADO y CIUDAD, y CIUDAD
tiene una participacin total en la interrelacin; por tanto, la clave
primaria NOMBRE_ESTADO de ESTADO se incluye en la relacin
CIUDAD.

Caso 2: La entidad en el lado de muchos tiene una participacin


parcial. En la figura (b) hay una interrelacin entre VENDEDOR y
PEDIDO. Supngase que los pedidos pueden hacerse por medio de los
vendedores, en cuyo caso se aplica una tasa de descuento, y tambin

directamente sin vendedores, sin aplicar una tasa de descuento. As


pues, existe la posibilidad de valores nulos de
NOMBRE_VENDEDOR y TASA_DESCUENTO en la relacin PEDIDO si
se usan las siguientes correspondencias:

VENDEDOR (NOMBRE, NUM_TELEFONO)


PEDIDO (NUM_PEDIDO, FECHA, NOMBRE_VENDEDOR,
TASA_DESCUENTO)

Si el nmero relativo de esos pedidos es grande, y no se puede admitir


valores nulos, una mejor alternativa sera establecer tres relaciones (lo
cual es el caso ms general):
VENDEDOR (NOMBRE, NUM_TELEFONO)
PEDIDO (NUM_PEDIDO, FECHA)
PEDIDO_VENTAS (NUM_PEDIDO, NOMBRE_VENDEDOR,
TASA_DESCUENTO)
Obsrvese que las dos relaciones, PEDIDO y PEDIDO_VENTAS,
describen pedidos. La primera atae a todos los pedidos; PEDIDOVENTAS contiene un subconjunto de todos los pedidos, aqullos hechos
a travs de vendedores. As, se tiene la restriccin adicional de que el
conjunto de nmeros de pedidos en PEDIDO_VENTAS est siempre
incluido en el conjunto de nmeros de pedidos de la relacin PEDIDO.
Esta

interrelacin

se

denomina

dependencia

de

inclusin

de

NUM_PEDIDO en
PEDIDO_VENTAS respecto a NUM_PEDIDO en PEDIDO en el modelo
relacional.

3.5.4. Transformacin de interrelaciones de muchos a muchos


En el caso de interrelaciones de muchos a muchos, la solucin no depende de
la cardinalidad mnima de la interrelacin. Supongamos que R es una
interrelacin de muchos a muchos entre E1 y E2. Se crea una relacin nueva
que tiene como clave primaria la combinacin de atributos que constituyen las
claves primarias tanto de E1 como de E2, y que incluye como atributos los
atributos de R. En el ejemplo de la figura de la siguiente pgina, una
interrelacin de muchos a muchos
MATRICULADO_EN entre ESTUDIANTE y CURSO se modela como una
nueva relacin MATRICULADO_EN, que tiene como clave primaria el par
(NUMEROESTUDIANTE,
NUMERO-CURSO), con SEMESTRE y NOTA como atributos.

Obsrvese que NUMERO_ESTUDIANTE y NUMERO_CURSO son claves


ajenas y tienen restricciones referenciales respecto a las claves primarias
correspondientes.

3.5.5. Transformacin de interrelaciones n-arias y recursivas


Finalmente, hay que resolver los dos tipos de interrelaciones que quedan: las n
arias (n
> 2) y las recursivas. Las interrelaciones n-arias siguen las mismas reglas de
transformacin que las binarias de muchos a muchos: la relacin hereda todos
los identificadores de las entidades (que forman la clave de la nueva relacin).
En algunos casos especiales, la clave obtenida de esta manera no es mnima,
y un subconjunto de claves primarias es de hecho la clave mnima. La clave
mnima es aquella que no contiene ninguna dependencia funcional. La
siguiente

figura

muestra

lainterrelacin

ternaria

SUMINISTRA

entre

PRODUCTO, PIEZA, y PROVEEDOR; la clave de la relacin SUMINISTRA es


el tro (CODIGO_PRODUCTO,
CODIGO_PIEZA, CODIGO_PROVEEDOR). Esta clave no puede reducirse
ms.

Como ejemplo de la reduccin de la clave por defecto en una correspondencia


as, considrese la interrelacin cuaternaria VENTA_COCHE entre COCHE,

CLIENTE, COMERCIANTE y BANCO_FINANCIADOR de la figura (b). La


relacin resultante tiene la siguiente clave primaria por defecto:
VENTA_COCHE (NUM_COCHE, NOMBRE_CLIENTE,
NOMBRE_COMERCIANTE, NOMBRE_BANCO. PRECIO_COCHE,
IMPORTE_PRESTAMO, TASA_INTERES)
Sin embargo, si un coche pertenece estrictamente a un cliente, NUM_COCHE
determina funcionalmente a NOMBRE_CLIENTE, y ste puede ser retirado de
la clave. De manera similar, si un comerciante usa solamente un banco para el
financiamiento,

NOMBRE_COMERCIANTE

determina

funcionalmente

NOMBRE_BANCO, y ste puede ser retirado de la clave.


Una interrelacin recursiva R de una entidad E a s misma se modela como una
nueva relacin que incluye dos atributos; ambos corresponden a la clave
primaria de E, y sus nombres corresponden a los dos papeles de E en la
interrelacin. Uno de ellos (o ambos) se elige(n) como clave primaria para la
nueva relacin, de acuerdo con el tipo de la interrelacin (uno a uno, uno a
muchos, muchos a muchos), como se expuso anteriormente. En la siguiente
figura la interrelacin cclica SUPERVISOR_DE se transforma en una relacin
SUPERVISOR_DE, cuyos atributos son
NOMBRE_DE_SUPERVISOR y NOMBRE_DE_SUBOR-DINADO (que son
versiones rebautizadas de los atributos NOMBRE de EMPLEADO). Si un
empleado puede tener varios supervisores, la interrelacin es de muchos a
muchos, y la clave primaria de SUPERVISOR_DE contiene los dos atributos.
Por otra parte, si un empleado slo puede tener un supervisor, la interrelacin
es de uno a muchos; la clave primaria de SUPERVISOR_DE es entonces slo
NOMBRE_DE_SUBORDINADO.
Como esta clave es la misma que NOMBRE en EMPLEADO, la relacin
SUPERVISOR_DE es similar a EMPLEADO y puede ser integrada en
EMPLEADO, con NOMBRE_DE_SUPERVISOR como atributo adicional. Esta
ltima solucin de una sola relacin ser en general la preferida, a menos que
un empleado pueda existir sin supervisor, porque entonces se tendran valores
nulos de NOMBRE_DE_SUPERVISOR para algunos empleados.
En este punto se ha completado la correspondencia del esquema lgico ER al
modelo relacional. Todos los rasgos del esquema ER estn modelados como
relaciones con una clave primaria.

CAPITULO IV
ALGEBRA RELACIONAL

El lgebra relacional consiste de algunas simples pero poderosas maneras de


construir nuevasrelaciones a partir de otras. Si pensamos que las relaciones
iniciales son los datosalmacenados entonces las nuevas relaciones se pueden
ver como respuestas a algunas consultas deseadas.

4.1. Conjunto de operaciones en relaciones

R S, la unin de R y S es el conjunto de elementos que estn en R o


S o ambos. Unelemento solo aparece una sola vez.

R S, el conjunto de elementos que aparecen en ambos R y S

R - S, la diferencia de R y S, el conjunto de elementos que estn en


R pero no en S. Esimportante resaltar que R - S es diferente a S - R.

R / S, la divisin de una relacin entre otra, debe cumplirse que para


toda tupla en Rexista su correspondiente en S.

Restricciones:
1. R y S deben tener esquemas idnticos.
2. El orden de las columnas debe ser el mismo
Ejemplos:

Proyeccin
.1.

Crea una nueva relacin a partir de otra, pero incluyendo slo


algunas de las columnas.

.2.

A1,A3,A6 (R)

CAPITULO V
GESTIN DE BASES DE DATOS EN SQL SERVER

5.1. 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 entre 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


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


delservidor (tales como memoria, operaciones de disco, etc) entre las
mltiplespeticiones.

La arquitectura Cliente /Servidor permite desarrollar aplicaciones para realizar


en una variedad de ambientes.
Transact-SQL es una versin de SQL (Structured Query Languaje) usado como
lenguaje de programacin para SQL Server. SQL es un conjunto de comandos
que permite especificar la informacin que se desea restaurar o modificar. Con
Transact SQL se puede tener acceso a la informacin, realizar bsquedas,
actualizar y administrar sistemas de Bases de Datos Relacionales.

5.2. Integracin de SQL con Windows XP/2003

SQL se encuentra totalmente integrado con Windows XP/2003 y toma ventaja


de muchas de sus caractersticas:

SEGURIDAD:

SQL Server est integrado con el sistema de seguridad de Windows


XP/2003. Esta integracin permite accesar tanto a Windows XP/2003
como a SQL Server con el mismo user name y password. Adems SQL
Server una las caractersticas de encriptacin que Windows XP/2003
para la seguridad en red. SQL Server est provisto de su propia
seguridad para clientes no-Microsoft.

SOPORTE MULTIPROCESADOR:

SQL Server soporta las capacidades de multiprocesamiento simtrico


(SMP) de
Windows XP/2003. SQL Server automticamente toma ventaja de
cualquier procesador adicional que sea agregado al Servidor.

SERVICIOS DE WINDOWS XP/2003:

SQL Server corre como un servicio dentro de Windows XP/2003,


permitiendo operarlo remotamente.

MICROSOFT CLUSTER SERVER:

Es un componente de Windows 2003 Enterprise Edition. Soporta la


conexin de dos servidores, o nudos, en un cluster para aumentar las
habilidades y tener un mejor manejo de la informacin y las aplicaciones.
SQL Server trabaja en conjunto con el Cluster Server para intercambiar
papeles automticamente en caso de que el nodo primario falle.

5.3. Servicios de SQL Server

Los servicios de SQL Server incluyen MSSQLServer, SQLServerAgent,


Microsoft Distributed Transaction Coordinator (MSDTC), y Microsft Search.
Aunque estos servicios de SQL generalmente corren en Windows XP/2003,
tambin pueden correr como aplicaciones.

SERVICIO MSSQLServer:

Este servicio es el motor de la Base de Datos. Este es el componente


que procesa todas las declaraciones de Transact-SQL y administra
todos los archivos que definen a la Base de Datos dentro del Servidor.
Sus caractersticas son:
Asignar los recursos de la computadora a mltiples
usuarios simultneos.
Previene problemas l gicos, tales como sincronizacin de
peticiones deusuarios que desean actualizar la misma
informacin al mismo tiempo.
Garantiza la integridad y consistencia de datos.

SERVICIO SQLServerAgent:

Este es un servicio que trabaja conjuntamente con SQL Server para


crear y administrar tareas locales o externas; letras y operadores.

SERVICIO

MICROSOFT

DISTRIBUTED

TRANSACTION

COORDIRATOR:
MSDTC permite a los clientes incluir muchos tipos de datos en una
transaccin.

Coordina la correcta realizacin de las transacciones distribuidas para


asegurar que todas las actualizaciones en todos los servidores son
permanentes; o en caso de errores, que las modificaciones son
canceladas.

SERVICIO MICROSOFT SEARCH:

Este servicio es un motor de full-text que corre como un servicio de


Windows XP/2003.
El soporte Full Text involucra la habilidad de emitir queries hacia los
datos y la creacin y mantenimiento de ndices que facilitan dichos
queries.
5.4. Herramientas de SQL Server

SQL Server incluye una variedad de software para administrar y mantener al


servidor, encontrando ayuda acerca de temas especficos, diseando y
creando Bases de Datos y buscando informacin.
5.4.1. SQL SERVER ENTERPRISE MANAGER SNAP-IN:

SQL Server est provisto de un cliente administrativo, que es el SQL


Server Enterprise Manager, el cual es una Consola de Administracin de
Microsoft (MMC) de tipo Snap- in. MMC es una interface de usuario

compartida para administracin de servidorusada por Back Office. Esta


consola compartida, provee un ambiente consistente para administracin
de herramientas.}

5.4.2. HERAMIENTAS Y ASISTENTES PARA ADMINISTRACIN DE


SQL SERVER:

SQL Server provee un nmero de herramientas administrativas y


asistentes que atienden aspectos particulares de SQL Server. La
siguiente tabla describe las herramientas y asistentes de SQL Server:

5.5. Arquitectura de SQL Server

5.5.1. COMUNICACIN:

SQL Server usa una arquitectura de comunicacin por capas para aislar
aplicaciones internas de red y protocolos. Esta arquitectura permite
desplegar la misma aplicacinen diferentes ambientes de red. Los
componentes en la arquitectura de comunicacin incluyen:

APLICACIN: Una aplicacin es desarrollada usando una aplicacin de


interfazde programacin para Base de Datos (API). La aplicacin no
tiene conocimientode los protocolos internos de red usados para la
comunicacin con SQL Server.

INTERFAZ DE LA BASE DE DATOS: Esta es una interfaz usada por


unaaplicacin para mandar peticiones a SQL Server y procesar los
resultadosdevueltos por SQL Server.

5.5.2. LIBRERA DE RED

Este es un componente de Software de comunicacin que empaqueta


las peticiones de la Base de Datos y los resultados para transmitirlos por
medio del protocolo de red apropiado. Una librera de Red, tambin
conocida como Net-Library, debe ser instalada tanto en el cliente como en
el servidor.
Tanto Clientes como Servidores pueden usar ms de una Net-Library al mismo
tiempo, pero deben usar una Librera de Red comn para comunicarse
satisfactoriamente. SQL Server soporta protocolos de red tales como TCP/IP,
Novell, IPX/SPX, Banyan VINES/IP, Named Pipes,y Apple Talk ADSP.
TABULAR DATA STREAM: (TDS) Es un protocolo por niveles de
aplicacinusado para la comunicacin entre un Cliente y SQL Server.
Los paquetes TDS sonencapsulados en los paquetes de red hechos por
la protocol stak usada por las Net-Libraries.
SERVICIOS OPEN DATA: Este es un componente de SQL Server que
se encargade las conexiones de red, pasando las peticiones del cliente
al SQL Server paraprocesar y regresar cualquier resultado a los
Clientes. Open Data escuchaautomticamente en todas las Net-Libraries
que estn instaladas en el servidor.
DESARROLLO DE APLICACIONES:
Los usuarios accesan al SQL Server a travs de una aplicacin que est
escrita con una interfaz de objetos de datos o con una API. SQL Server soporta
interfaces comunes y APIs nativos de bajo nivel.
INTEFACES DE PROGRAMACIN DE APLICACIONES:
Una Base de Datos API define como escribir una aplicacin para conectar una
Base de Datos y pasar comandos a la Base de Datos. SQL Server provee
soporte nativo para dos clases principales de Bases de Datos API, lo cual
define la interfaz de objetos de datos que se puede usar. Las Bases de Datos
API se usan para tener mayor control sobre el comportamiento y desarrollo de
las aplicaciones.

OLE DB: Esta es una interfaz de acceso a datos basada en el


COM(Component Object Model). Soporta aplicaciones escritas usando
OLE DB oInterfaces de Objetos de Datos basadas en OLE DB. Puede
accesar a la informacin en SQL Server, otras Bases de Datos
relacionales y otras fuentes de datos.
OPEN DATABASE CONNECTIVITY: (ODBC) Es una interfaz por
capas.Accesa directamente al protocolo SQL Server TDS y soporta
aplicaciones o componentes que estn escritos usando ODBC o
interfaces basadas enODBC. Puede accesar a los datos en SQL Server,
y otras Bases de Datos relacionales, pero generalmente no puede ser
usado para accesar otras fuentes de datos.

5.5.3. DATA OBJECT INTERFACES:

En general, estas interfaces son ms fciles de usar que las Bases de Datos
API pero pueden no tener tanta funcionalidad como un API.
ACTIVE X DATA OBJECTS: (ADO) Encapsula la OLE DB API en
unmodelo simplificado de objetos que reduce el desarrollo de
aplicaciones ylos costos de mantenimiento. ADO puede ser usado a
partir de Microsoft
Visual Basic, Visual Basic para Aplicaciones, Active Server Pages (ASP) y el
Scripting Object Model de Microsoft Internet Explorer.
REMOTE DATA OBJECTS: (RDO) Mapea y encapsula al ODBC API.
RDO puede ser usado desde Visual Basic y Visual Basic para aplicaciones.

5.5.4. ADMINISTRACIN:

SQL Server provee una variedad de herramientas de administracin para


minimizar y automatizar las tareas administrativas rutinarias. Las declaraciones
de Transact-SQL son el mecanismo interno usado para administrar SQL
Server.

SQL SERVER AGENT:


Es un servicio que trabaja en conjunto con SQL Server para desempear las
siguientes tareas administrativas:
Administracin de Alertas: Las alertas brindan informacin acerca del
estado deun proceso, tal como cuando un trabajo est completo o
cuando ocurre un error. Elagente de SQL Server monitorea la aplicacin
de Windows XP/2003 y generaalertas.
Notificacin: El agente de SQL Server puede enviar e- mails, o iniciar
otraaplicacin cuando ocurre una alerta, por ejemplo, se puede
programar una alertapara que ocurra cuando una Base de Datos o
cuando una transaccin est casicompleta o cuando un respaldo de la
Base de Datos ha terminado exitosamente.
Ejecucin de Tareas: El agente de SQL Server incluye un motor de
creacin yplaneacin de tareas. Las tareas pueden ser simples
operaciones de un solo paso, opueden ser tareas complejas de varios
pasos que requieren planeacin. Tambin sepueden crear pasos de las
tareas con Transact-SQL, leguajes script, o comandosdel Sistema
Operativo.
Administracin de Rplicas: La replicacin es el proceso de copiar datos
otransacciones de un SQL Server a otro. El agente de SQL Server es
responsable desincronizar los datos entre los servidores, monitorear los
datos para buscar cambiosy replicar la informacin en otros servidores.

5.6. Bases de Datos en 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 administra
una o ms Bases de datos de usuario.

BASES DE DATOS DE SISTEMA Y DE USUARIO:


Cuando SQL Server es instalado, el setup crea 4 bases de datos de sistema 2y
2 de usuario, de ejemplo. La Base de Datos de distribucin es instalada cuando
se configura SQL Server para actividades de replicacin.

5.6.1. OBJETOS DE LA BASE DE DATOS:


Una Base de Datos, es una coleccin de datos, tablas y otros objetos. Los
objetos de la Base de Datos ayudan a estructurar los datos y definir
mecanismos para la integridad de datos.

5.7. Diseo de una Aplicacin Para SQL Server


La planeacin del diseo de una Base de Datos requiere del conocimiento de
las funciones del usuario que se desean modelar, y los conceptos de la Base
de Datos y caractersticas que se usan para representar dichas funciones.
Antes de disear una aplicacin para SQL Server es importante pasar tiempo
diseando una Base de Datos que refleje exactamente las funciones realizadas
por el usuario. Una Base de Datos bien diseada requiere cambios mnimos y
generalmente se desarrolla con mayor eficiencia. La arquitectura que se elija,
afectar la forma en que se desarrolle, administre y visualice la aplicacin de
Software.

5.8. Arquitectura de Software


Se puede elegir de entre muchas arquitecturas de aplicacin para implementar
aplicaciones cliente/servidor. Sin embargo elegir un enfoque de aplicacin por
capas permite flexibilidad y elegir entre opciones de administracin. Las
aplicaciones de Software se pueden dividir entre capas lgicas, las cuales
pueden residir fsicamente en uno o ms servidores.
Las opciones tpicas para visualizar una aplicacin son:
INTELIGENT SERVER (2-TIER): La mayor parte del proceso ocurre en
elservidor con los servicios de presentacin realizados en el Cliente. En
muchasinstancias, la gran mayora de la lgica de los servicios es
implementada en laBase de Datos. Este diseo es til cuando los
clientes no tienen los suficientesrecursos para procesar esta lgica. Sin
embargo, el servidor puede volverse uncuello de botella porque los
servicios de Base de Datos y los de aplicacincompiten por los mismos
recursos de Hardware. Un ejemplo de este diseoson las aplicaciones
asociadas diseadas para un punto de vista de una Base deDatos
cntrica.
INTELLIGENT CLIENT (2-TIER): La mayor parte del proceso ocurre en
elcliente, con los servicios de datos realizados en el Servidor. Este
diseo esampliamente usado. Sin embargo el trfico en la red puede ser
pesado yalargar las transacciones, lo que puede afectar la ejecucin. Un
ejemplo deeste diseo son las aplicaciones desarrolladas para
pequeas empresas conproductos tales como Microsoft Access.
N-TIER: el proceso es dividido entre un servidor de Base de Datos, un
Servidor de Aplicacin y clientes. Este enfoque separa los servicios lgicos de
los de datos, y se pueden agregar fcilmente ms servidores de aplicacin o de
Base de Datos, segn se requiera. Sin embargo, el potencial de complejidad
aumenta, y este enfoque puede ser ms lento para pequeas aplicaciones. Las
aplicaciones de empresa multienlazada sin ejemplo de este diseo.
INTERNET: El proceso es dividido en 3 capas, con los servicios de
presentacin y los de aplicacin residen en el Servidor Web, y los
clientes usansimples browsers. Cualquier cliente que tenga un browser
puede sersoportado, y el Software no necesita estar en el cliente. Un
ejemplo de estediseo es un sitio Web que usa muchos servidores Web

para administrar lasconexiones de los clientes, y una base de Datos de


SQL Server que atiendepeticiones de datos.

5.9. Arquitectura de una base de datos


Los datos de Microsoft SQL Server estn guardados en bases de datos. Los
datos de una base de datos estn organizados en los componentes lgicos
visibles por los usuarios. Adems, una base de datos est implementada
fsicamente como dos o ms archivos de disco.
Al utilizar una base de datos, se trabaja principalmente con los componentes
lgicos, como tablas, vistas, procedimientos y usuarios. La implementacin
fsica de los archivos es casi enteramente transparente. Normalmente, slo el
administrador de la base de datos tiene que trabajar con la implementacin
fsica.
Cada instalacin de SQL Server tiene varias bases de datos. SQL Server tiene
cuatro bases de datos del sistema (master, model, tempdb y msdb) y cada
instalacin de SQL Server tiene una o varias bases de datos de usuario.
Algunas organizaciones slo tienen una base de datos de usuario que contiene
todos los datos de la organizacin.
Otras organizaciones tienen bases de datos diferentes para cada grupo de la
organizacin y, en algunas ocasiones, una base de datos slo es utilizada por
una nica aplicacin. Por ejemplo, una organizacin podra tener una base de
datos para ventas, una para nminas, una para una aplicacin de
administracin de documentos, etc.

Algunas veces, una aplicacin utiliza slo una base de datos; otras
aplicaciones pueden tener acceso a varias bases de datos.
No es necesario ejecutar varias instancias de SQL Server para que varios
usuarios puedan tener acceso a las bases de datos de un servidor. SQL Server
es capaz de controlar el trabajo de miles de usuarios sobre varias bases de
datos en el mismo servidor y al mismo tiempo. SQL Server deja disponibles
todas las bases de datos del servidor para todos los usuarios que conecten con
dicho servidor, de acuerdo con los permisos de seguridad definidos.
Al conectar con SQL Server, la conexin queda asociada con una base de
datos concreta del servidor. Esta base de datos recibe el nombre de base de
datos actual.
Normalmente, el usuario se conecta a una base de datos definida como
predeterminada por el administrador del sistema, aunque puede utilizar las
opciones de conexin de las
API de la base de datos para especificar otra base de datos. Puede cambiar de
una base de datos a otra mediante la instruccin Transact-SQL USE
nombreBaseDatos o mediante una funcin API que cambie el contexto de su
base de datos actual.
SQL

SQL Server le permite cancelar la asignacin de bases de datos de un servidor,


volver a asignarlas a otro servidor e incluso volver a asignar las bases de datos
al mismo servidor. Si tiene un archivo de una base de datos SQL Server, al
conectarse a SQL
Server puede indicarle que quiere asignar a dicho archivo de base de datos un
nombre de base de datos especfico.
5.10. Implementacin de una Base de Datos en SQL Server

Implementar una Base de Datos en SQL Server significa planear, crear y


mantener un nmero de componentes interrelacionados. La naturaleza y
complejidad de unaaplicacin de Base de Datos, as como el proceso de
planearla puede variar enormemente. Por ejemplo, una Base de Datos puede
ser relativamente simple, diseada para ser usada por una sola persona, o
puede ser grande y compleja, diseada para atender todas las transacciones
de cientos o miles de clientes. En cuanto al tamao y complejidad de la Base
de Datos, generalmente la implementacin de una
Base de Datos involucra:
1. Disear la Base de Datos de manera que la aplicacin optimice el uso de
Hardware
y permita crecimiento futuro, identificar y modelar objetos de la Base de Datos y
aplicaciones de lgica, y especificar tipos de informacin para cada objeto y
tipo de relacin.
2. Crear la Base de Datos y los objetos, incluyendo tablas, mecanismos de
integridad de datos, entrada de datos y objetos, ndices y seguridad.
3. Probar la aplicacin y la base de Datos. Cuando se disea una Base de
Datos, se desea asegurar que la Base de Datos realiza las funciones
importantes en forma rpida y correcta.
4. Planear el funcionamiento, lo que incluye analizar la carga de trabajo y
recomendar una configuracin ptima para la Base de Datos de SQL Server.
5. Administrar la aplicacin, lo que incluye configurar a los clientes y servidores,
monitorear el funcionamiento del server, administrar tareas, alertas y
operadores, administrar seguridad y procedimiento de backup de la Base de
Datos.
5.11. Registro de transacciones
Una base de datos de SQL Server tiene, como mnimo, un archivo de datos y
un archivo de registro de transacciones. Los datos y la informacin del registro
de transacciones nunca se mezclan en el mismo archivo, y cada archivo es
utilizado por una sola base de datos. SQL Server utiliza el registro de
transacciones de cada base de datos para recuperar las transacciones. El
registro de transacciones consiste en una serie de registros de todas las
modificaciones de la base de datos y las transacciones que se han realizado en

las modificaciones. En el registro de transacciones figura el inicio de cada


transaccin.
Tambin se registran los cambios de los datos y se facilita suficiente
informacin

para

deshacer

las

modificaciones

(si

fuera

necesario

posteriormente) realizadas durante la transaccin. Para algunas operaciones


largas, como la de CREATE INDEX, el registro de transacciones slo registra
que se llev a cabo la transaccin. El registro crece continuamente a medida
que se producen operaciones en la base de datos y stas se registran

CAPITULO VI

LABORATORIO: CREACIN DE BASES DE DATOS EN SQL SERVER

6.1.

Conectndose al Servidor

1. Iniciar la herramienta Analizador de consultas


2. Ingresar con el usuario sa, contrasea en blanco.
3. Seleccionar la base de datos master.
4. Ejecutar el comando SELECT @@VERSIN
5. Ejecutar el comando SELECT * FROM SYSDATABASES. Qu muestra el
resultado?
6. Modificar la salida de resultados a forma de grid. Regresar a la forma de
texto.

6.2.

Haciendo un reconocimiento de las herramientas del SQL Server

7. Indique en cada llamada la utilidad de cada herramienta:

6.3.

Usando las herramientas

8. Ingrese a la herramienta libros en pantalla. Busque informacin acerca del


comando
CREATE DATABASE

9. Ingrese a la herramienta de red del cliente. Agregue una biblioteca de red


del tipo
TCP/IP, con el nombre Servidor utilice el puerto 1434.

10. Ingrese a la herramienta de red del servidor. Qu bibliotecas estn


activas?
11. Ingrese al administrador corporativo.
12. Qu es MMC?
13. Qu significado tiene el relmpago rojo en el icono del servidor?

6.4.

Preparando la base de datos de prueba

14. El modelo relacional que se utilizar para los laboratorios, corresponde al


siguiente:

6.5.

Creando bases de datos desde el analizado de consultas

15. Desde el analizador de consultas, generar la base de datos


Supermercado:
CREATE DATABASE Supermercado ON PRIMARY
( NAME = Supermercado,
FILENAME = '\\DATA\Supermercado.mdf',
SIZE = 20MB,
MAXSIZE = 100MB,
FILEGROWTH = 10MB )
LOG ON

( NAME = SupermercadoLog,
FILENAME = '\\DATA\SupermercadoLog.ldf',
SIZE = 20MB,
MAXSIZE = 100MB,
FILEGROWTH = 10MB )
16. Genere la base de datos Farmacia:
CREATE DATABASE Farmacia ON PRIMARY
( NAME = Farmacia1,
FILENAME = '\\DATA\Farma1.mdf',
SIZE = 5,
MAXSIZE = 50,
FILEGROWTH = 5 ),
( NAME = Farmacia2,
FILENAME = '\\DATA\Farma2.ndf',
SIZE = 5,
MAXSIZE = 50,
FILEGROWTH = 5 )
LOG ON
( NAME = FarmaciaLog1,
FILENAME = '\\DATA\FarmaLog1.ldf',
SIZE = 10,

MAXSIZE = 10,
FILEGROWTH = 1 ),
( NAME = FarmaciaLog2,
FILENAME = '\\DATA\FarmaLog2.ldf',
SIZE = 20MB,
MAXSIZE = 20,
FILEGROWTH = 2 )
17. Genere la base de datos Restaurante, con 1 archivo para la base de datos
y 2 archivos de registro. Asigne un tamao inicial de 15 Mb, un mximo de 30
Mb, y crecimiento de 5 Mb para cada archivo.
18. Genere la base de datos Ferreteria, con 2 archivos para la base de datos y
2 archivos de registro. Asigne tamaos arbitrarios segn su criterio.

6.6.

Creando bases de datos desde el administrador corporativo

19. Inicie el administrador corporativo.


20. Ingrese a las propiedades de la base de datos Farmacia. Observe las
propiedades y los archivos creados.
21. Genere una nueva base de datos Banco desde el administrador
corporativo. Siga las instrucciones del instructor.
22. Visualice la informacin de la base de datos creada.

6.7.

Visualizando la informacin de las bases de datos desde el


analizador de consultas

23. Desde el analizador de consultas utilice el procedimiento almacenado de


sistema:
sp_helpdb
24. Recuerde el concepto y utilidad de un procedimiento almacenado de
sistema:
25. Visualice la informacin de cada base de datos:
sp_helpdb supermercado
sp_helpdb ferreteria

sp_helpdb banco

6.8.

Especificando opciones para la base de datos

26. Ingrese al administrador corporativo. Ingrese a las propiedades de la base


de datos Supermercado, y luego a la ficha opciones.
27. Describa brevemente la utilidad de activar:
a. Slo para uso del DBO
b. Un nico usuario
c. Solo lectura
28. Ingrese al analizador de consultas. Cierre el administrador corporativo.
Active la opcin Slo para uso del DBO: exec sp_dboption Supermercado,
Read Only, True
29. Verifique desde el administrador corporativo, que efectivamente la opcin
haya cambiado a solo lectura.
30. Desactive la opcin.

6.9.

Expandiendo bases de datos desde el analizador de cons ultas

31. Ingrese al analizador de consultas. Agregue un segundo archivo de base


de datos para Supermercado:
ALTER DATABASE Supermercado
ADD FILE
( NAME = Supermercado1,
FILENAME = '\\DATA\Supermercado1.ndf',
SIZE = 2,
MAXSIZE = 10,
FILEGROWTH = 2)
32. Ingrese al explorador de archivos de windows .Compruebe que se haya
creado el archivo Supermercado1.ndf.
33. Agregue 2 archivos de registro de transacciones: SupermercadoLog1 y
SupermercadoLog2.

6.10. Expandiendo bases de datos desde el analizador de consultas

34. Ingrese al administrador corporativo. Agregue a la base de datos


Ferretera, 1 archivo de base de datos. (Siga las instrucciones del instructor)
35. Ingrese al administrador corporativo. Agregue a la base de datos Banco,
1 archivo de registro de transacciones. (Siga las instrucciones del instructor)

6.11. Cambiando el nombre a una base de datos

36. Cul es la condicin para poder renombrar una base de datos?


37. Desde el analizador de consultas modifique el nombre de la base de datos
Farmacia,porBotica:
EXEC sp_dboption Farmacia, 'Single User', True
EXEC sp_renamedb 'Farmacia', 'Botica'
EXEC sp_dboption Botica, 'Single User', False
38. Ingrese al administrador corporativo. Actualice la carpeta Bases de
Datos.
Verifique que se haya cambiado el nombre a la base de datos farmacia.
39. Renombre la base de datos Banco, por Financiera.

6.12. Eliminando bases de datos desde el analizador de consultas

40. Elimine la base de datos Restaurante:


DROP DATABASE Restaurante
41. Cul es la forma de recuperar una base de datos eliminada?

6.13. Eliminando bases de datos desde el administrador corporativo

42. Ingrese al administrador corporativo. Elimine la base de datos Ferretera.


(Siga las instrucciones del instructor).
NOTA: Se ha omitido las tildes en los nombres de bases de datos, tablas,
campos, etc. Para permitir la compatibilidad con las reglas de identificadores de
SQL Server.

CAPITULO VII
GESTIN DE TABLAS EN SQL SERVER

7.1. Tablas

Las tablas son objetos de la base de datos que contienen todos sus datos. Una
tabla se define mediante una coleccin de columnas. En las tablas, los datos se
organizan con arreglo a un formato de filas y columnas, similar al de una hoja
de clculo. Cada fila representa a un registro nico, y cada columna representa
a un campo dentro de un registro. Por ejemplo, en una tabla que contenga los
datos de los empleados de una compaa puede haber una fila para cada
empleado y distintas columnas en las que figuren detalles de los empleados
tales como el nmero de empleado, el nombre, la direccin, el puesto que
ocupa y su nmero de telfono particular

7.2. Tipos de datos (Transact-SQL)

En Microsoft SQL Server cada columna, variable local, expresin y parmetro


tiene un tipo de datos. El conjunto de tipos de datos suministrados por el
sistema se muestra debajo. Los tipos de datos definidos por el usuario, que son
alias de los tipos de datos suministrados por el sistema, pueden tambin
definirse.

7.2.1. Enteros

bit

Datos enteros con valor 1 0.

int

Datos enteros (nmeros enteros) comprendidos entre -231 (-2.147.483.648) y


231 - 1
(2.147.483.647).

smallint

Datos enteros comprendidos entre 215 (-32.768) y 215 - 1 (32.767).

tinyint

Datos enteros comprendidos 0 y 255.

Decimales y numricos decimal

Datos de precisin y escala numrica fijas comprendidos entre -1038 -1 y 1038


-1. numrico
Sinnimo de decimal.

Moneda

Money

(+922.337.203.685.477,5807), con una precisin de una diezmilsima de la


unidad monetaria.

smallmoney

Valores de moneda comprendidos entre -214.748,3648 y +214.748,3647, con


una precisin de una diezmilsima de la unidad monetaria.

Numricos con aproximacin float

Nmeros con precisin de coma flotante comprendidos entre -1,79E + 308 y


1,79E +
308.

Real

Nmeros con precisin de coma flotante comprendidos entre -3,40E + 38 y


3,40E +
38.
7.2.2. Fecha y hora

datetime

Datos de fecha y hora comprendidos entre el 1 de enero de 1753 y el 31 de


diciembre de 9999, con una precisin de un trescientosavo de segundo, o 3,33
milisegundos.

smalldatetime

Datos de fecha y hora comprendidos entre el 1 de enero de 1900 y el 6 de junio


de
2079, con una precisin de un minuto.

timestamp

Es un nmero nico para toda la base de datos.

uniqueidentifier

Un identificador exclusivo global (GUID).

7.2.3. Cadenas de caracteres

char

Datos de caracteres no Unicode de longitud fija con una longitud mxima de


8.000 caracteres.

varchar

Datos no Unicode de longitud variable con un mximo de 8.000 caracteres.

text

Datos no Unicode de longitud variable con una longitud mxima de 231 - 1


(1.147.483.647) caracteres.
Cadenas de caracteres Unicode

nchar

Datos Unicode de longitud variable con una lo ngitud mxima de 4.000


caracteres.

nvarchar

Datos Unicode de longitud variable con una longitud mxima de 4.000


caracteres.
sysnamees el tipo de datos suministrado por el sistema y definido por el
usuario que es sinnimo de nvarchar(128) y que se utiliza para hacer
referencia a nombres de objetos de bases de datos.
Datos Unicode de longitud variable con una longitud mxima de 230 - 1

(1.073.741.823) caracteres.
Cadenas binarias

binary

Datos binarios de longitud fija con una longitud mxima de 8.000 bytes.

varbinary

Datos Unicode de longitud variable con una longitud mxima de 8.000 bytes.

image

Datos Unicode de longitud variable con una longitud mxima de 231 - 1


(1.147.483.647) bytes.

7.3. Diagramas de bases de datos


Se puede crear, modificar o eliminar objetos de base de datos mientras
mantenga una conexin directa con la base de datos en que estn
almacenados esos objetos. Para interactuar con la base de datos del servidor,
se utilizan diagramas de base de datos. Se puede tener acceso a los
diagramas de base de datos a travs del Administradorcorporativo de SQL
Server. Los diagramas de base de datos representan grficamente las tablas
en la base de datos. Los diagramas de base de datos muestran las columnas
que las tablas contienen, las relaciones entre las tablas, y los ndices y
restricciones de las tablas. Despus de que se haya establecido una conexin
con la base de datos, puede utilizar diagramas de base de datos para:
Ver las tablas y sus relaciones en una base de datos. Realizar
operaciones complejas para alterar la estructura fsica de una base de
datos.
Puede realizar cambios en el diagrama de base de datos sin que afecten
a la base dedatos subyacente. Cuando utiliza un diagrama de base de
datos para modificar unobjeto de base de datos, las modificaciones no
se guardan en la base de datos hastaque guarda la tabla o el diagrama.
Guardar los cambios realizados en las tablas seleccionadas o en el
diagrama debase de datos y hacer que los cambios modifiquen la base
de datos del servidor.

7.4. Integridad de los datos


La integridad de los datos garantiza la calidad de los datos de la base de datos.
Por ejemplo, si se especifica para un empleado el valor de employee_id
(IdEmpleado) 123, la base de datos no debe permitir que ningn otro
empleado tenga el mismo valor de identificador. Si tiene una columna
employee_rating
(clasificacinEmpleado) para la que se prevea valores entre el 1 y el 5, la base
de datos no debe aceptar el valor 6. Si en la tabla hay una columna dept_id
(IdDepto) en la que se almacene el nmero de departamento del empleado, la
base de datos slo debe permitir valores que correspondan a los nmeros de
departamento de la compaa.
Dos pasos importantes en el diseo de las tablas son la identificacin de
valores vlidos para una columna y la determinacin de cmo forzar la
integridad de los datos en la columna. Hay cuatro categoras de integridad de
datos:

Integridad de entidad

Integridad de dominio

Integridad referencial

Integridad definida por el usuario.

Hay varias maneras de forzar cada tipo de integridad.

7.4. Integridad de entidad


La integridad de entidad define una fila como entidad nica para una tabla
determinada. La integridad de entidad fuerza la integridad de la columna o
columnas de los identificadores o la clave principal de una tabla (mediante
ndices, restricciones UNIQUE, restricciones PRIMARY KEY o propiedades
IDENTITY).

Integridad de dominio

La integridad de dominio viene dada por la validez de las entradas para una
columna determinada. Puede forzar la integridad de dominio si restringe el tipo
(mediante tipos de datos), el formato (mediante las reglas y las restricciones
CHECK), o el intervalo de valores posibles (mediante restricciones FOREIGN
KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y
reglas).

Integridad referencial

La integridad referencial protege las relaciones definidas entre las tablas


cuando se crean o se eliminan registros. En Microsoft SQL Server, la integridad
referencial se basa en las relaciones entre las claves externas y las claves
principales o entre lasclaves externas y las claves nicas. La integridad
referencial garantiza que los valores clave son coherentes en las distintas
tablas. Para conseguir esa coherencia, es preciso que no haya referencias a
valores inexistentes y que, si cambia el valor de una clave, todas las
referencias a ella se cambien en consecuencia en toda la base de datos.

Cuando se fuerza la integridad referencial, SQL Server impide a los usuarios:

Agregar registros a una tabla relacionada si no hay ningn registro


asociado enla tabla principal.

Cambiar valores en una tabla principal de manera que queden


registrohurfanos en una tabla relacionada.

Eliminar registros de una tabla principal cuando hay registros


relacionadoscoincidentes.

Por ejemplo, con las tablas sales (compras) y titles (ttulos) de la base de
datos
pubs, la integridad referencial se basa en la relacin entre la clave externa

(title_id) de la tabla sales y la clave principal (title_id) de la tabla titles.


Integridad

Integridad definida por el usuario

La integridad definida por el usuario le permite definir reglas de la compaa


especficas que no pertenecen a ninguna otra categora de integridad. Todas
las categoras de integridad son compatibles con la integridad definida por el
usuario.
ndices
Los ndices de una base de datos son similares a los ndices que hay en los
libros. En un libro, un ndice le permite encontrar informacin rpidamente sin
necesidad de leer todo el libro. En una base de datos, un ndice permite que el
programa de la base de datos busque datos en una tabla sin necesidad de
examinar toda la tabla. El ndice de un libro es una lista de palabras con los
nmeros de las pginas en las que se encuentra cada palabra. Un ndice de
una base de datos es una lista de los valores de una tabla con las posiciones
de almacenamiento de las filas de la tabla donde se encuentra cada valor. Se
puede crear ndices en una sola columna o en una combinacin de columnas
de una tabla; los ndices se implementan en forma de rboles B. Un ndice

contiene una entrada con una o varias columnas (la clave de bsqueda) de
cada fila de una tabla. Un rbol B se ordena con la clave de bsqueda y se
puede buscar de forma eficiente en cualquier subconjunto principal de la clave
de bsqueda. Por ejemplo, un en A, B y C.
Mientras que la mayor parte de los libros contienen un ndice general de
palabras, nombres, lugares, etc., las bases de datos contienen ndices
individuales para tipos o columnas de datos seleccionados. Es como un libro
con un ndice para los nombres de las personas y otro ndice para los lugares.
Cuando cree una base de datos y la optimice para mejorar el rendimiento, es
recomendable que cree ndices para las columnas que se utilizan en las
consultas con el fin de buscar datos.
En la base de datos de ejemplo pubs suministrada con Microsoft SQL Server,
la tabla employee tiene un ndice en la columna emp_id. En la siguiente
ilustracin se muestra cmo almacena el ndice cada valor emp_id y seala a
las filas de datos de la tabla con cada valor.
Cuando SQL Server ejecuta una instruccin para buscar datos en la tabla
employee apartir de un valor de emp_id especfico, reconoce el ndice para la
columna emp_id y lo utiliza para buscar los datos. Si no hay un ndice,
empieza desde el principio de la tabla y va buscando, fila por fila, el valor de
emp_id especificado.
SQL Server crea automticamente ndices para determinados tipos de
restricciones (por ejemplo, restricciones de clave principal (PRIMARY KEY) y
de no duplicados (UNIQUE)). Tambin puede personalizar las definiciones de
la tabla mediante la creacin de ndices independientes de las restricciones.

No obstante, las ventajas que ofrecen los ndices por lo que respecta al
rendimiento tambin tienen un costo. Las tablas con ndices necesitan ms
espacio de almacenamiento en la base de datos. Asimismo, es posible que los
comandos de insercin, actualizacin o eliminacin de datos sean ms lentos y
precisen ms tiempo de proceso para mantener los ndices. Cuando disee y
cree ndices, deber asegurarse cuanto a espacio de almacenamiento y
recursos de proceso.
7.5. Disear un ndice
Cuando Microsoft SQL Server ejecuta una consulta, el optimizador de
consultas evala los costos de los mtodos disponibles para recuperar los
datos y utiliza elmtodo ms eficiente. Puede explorar una tabla o bien utilizar
un ndice, en el caso de que exista. Cuando SQL Server explora una tabla,
empieza desde el principio y examina todas las filas de la tabla, una por una,
para extraer las que cumplen los criterios de la consulta. Cuando SQL Server
utiliza un ndice, busca la ubicacin de almacenamiento de las filas necesarias
para la consulta y extrae nicamente esas filas.
Cuando se plantee la posibilidad de crear un ndice en una columna, tenga en
cuenta si se utilizarn columnas indizadas en las consultas y de qu modo. Los
ndices son tiles cuando una consulta:

Busca filas que coincidan con un valor de clave de bsqueda


especfico(consulta de coincidencia exacta). En una comparacin de
coincidencia exacta,la consulta utiliza la instruccin WHERE para
especificar una entrada de unacolumna con un valor determinado. Por
ejemplo:WHERE emp_id = 'VPA30890F'
Busca filas con valores de clave de bsqueda en un intervalo de
valores(consulta de intervalo). En una consulta de intervalo, la consulta
especificacualquier entrada con un valor que se encuentre entre otros
dos valores. Porejemplo:
WHERE job_lvl BETWEEN 9 and 12 o bien:
WHERE job_lvl >= 9 and job_lvl <= 12
Busca filas de una tabla T1 que, a partir de un predicado de
combinacin,coincidan con una fila de otra tabla T2 (una combinacin de
bucles anidadosde ndice).
Crea una salida de consulta ordenada sin una operacin explcita
deordenacin; en particular, para cursores dinmicos ordenados.
Recorre las filas en orden para posibilitar una operacin basada en
unaordenacin, como una combinacin de mezcla y un agregado de
secuencia, sinuna operacin de ordenacin explcita.
Recorre todas las filas de una tabla con un rendimiento superior al de
unrecorrido de tabla, debido a que el conjunto de columnas y el volumen
de datosque se deben examinar son reducidos (un nd ice de cobertura
para la consultaen cuestin).
Busca duplicados de nuevos valores de clave de bsqueda en
operaciones deinsercin y de actualizacin para exigir restricciones
PRIMARY KEY y
UNIQUE.
Busca filas que coincidan entre dos tablas para las que se ha definido
unarestriccin FOREIGN KEY.
Las consultas que utilizan comparaciones LIKE pueden mejorar con un
ndice si lospatrones empiezan con una cadena de caracteres
especfica, como 'abc%', pero no siempiezan con una bsqueda en la
que se utilizan caracteres comodn (por ejemplo'%xyz').

CAPITULO VIII
8.1.

LABORATORIO: GESTIN DE TABLAS EN SQL SERVER

Implementando las tablas para la base de datos Supermercado


1. Considerar los siguientes tipos de datos para las tablas:

2. Inicie el analizador de consultas. Seleccione la base de datos


Supermercado.
3. Genere la tabla UNIDAD considerando la clave primaria:

4. Genere la tabla ARTCULO considerando clave primaria, clave fornea y


restricciones:

CREATE TABLE Articulo


( IDArticulo char(5) CONSTRAINT PKArticulo PRIMARY KEY,
NombreArticulo varchar(35) NOT NULL,
DescripArticulo varchar(100) NULL,
IDUnidad char(3) CONSTRAINT FKUnidad FOREIGN KEY
REFERENCES Unidad(IdUnidad),
UnidExistencia int NOT NULL CONSTRAINT UniExi DEFAULT 0
CONSTRAINT UnidExi1 CHECK (UnidExistencia>=0),
PrecioUnidad money NOT NULL CONSTRAINT PreUni DEFAULT
0,
UnidMinimo int NOT NULL CONSTRAINT UniMin DEFAULT 0,
Supendido bit )
5. Genere la tabla CAJERO, considerando clave primaria.
6. Genere la tabla CLIENTE considerando clave primaria.
CREATE TABLE Cliente

7. Genere la tabla TIPO. Considere la clave primaria.


8. Genere la tabla DOCVENTA. Considere las claves primarias, forneas y
restricciones.
9. Genere la tabla DETALLES. Considere las claves primarias, forneas y
restricciones.
10. Ingrese al administrador corporativo. Revise las tablas creadas.
11. Ingrese a las propiedades del diseo de la tabla Articulo. Verifique las
propiedades que se crearon desde el administrador de consultas.
12. Desde el administrador corporativo, ingrese al objeto Diagramas, de la
base de datos.
Supermercado.
13. Cancele el asistente.
14. Clic en el icono Agregar tabla.
15. Pulsando la tecla Control, seleccione todas las tablas disponibles. Pulse
Agregar, luego
Cerrar.
16. Clic en el icono Organizar tablas. Observe las relaciones creadas
automticamente.
17. Agregue los campos Distrito y Ciudad, a la tabla Cajero:
ALTER TABLE Cajero ADD
Distrito varchar(30) NULL,
Ciudad varchar(20) NULL
18. Elimine el campo Fecha, de la tabla DocVenta. Vuelva a aadir un campo
FechaEmision
a la misma tabla.
ALTER TABLE DocuVenta DROP
COLUMN Fecha
ALTER TABLE DocuVenta ADD
FechaEmision datetime
19. Modifique los campos Telefono y Fax de la tabla Cliente , al tipo char (16).
ALTER TABLE Cliente
ALTER COLUMN Telefono char(16)

ALTER TABLE Cliente


ALTER COLUMN Fax char(16)
20. Recuerde el concepto de ndice:
21. Explique con sus propias palabras acerca del Factor de relleno.
22. Ingrese al administrador corporativo. Verifique en cada tabla los ndices
creados por defecto. Clic derecho en el nombre de tabla. Ingrese a Todas las
tareas, Administrar
ndices.
23. Ingrese al analizador de consultas. Genere un ndice no agrupado para el
campo
NombreArticulo de la tabla Articulo.
CREATE NONCLUSTERED INDEX IDXNombreArticulo
ON Articulo(NombreArticulo)
24. Genere un ndice con valor nicos no agrupado, para el campo
FechaEmision de la tabla
DocuVenta.
CREATE UNIQUE NONCLUSTERED INDEX IDXFechaEmision
ON DocuVenta (FechaEmision)
25. Genere un ndice con valores no nicos, agrupado, de mltiples campos,
para los campos
IDDocuVenta yIDArticulo, de la tabla Detalles.
CREATE CLUSTERED INDEX IDXDetalle
ON Detalles (IDDocuVenta,IDArticulo)
26. Ingrese al administrador corporativo. Desde el diagrama relacional creado,
verificar los ndices creados. Siga las instrucciones del instructor.
27. Genere un ndice nico no agrupado para los campos ApPatContacto,
ApMatContacto y
NombContacto, de la tabla Cliente. Genere un ndice no nico, no agrupado
para cada clave fornea de la tabla DocVenta.
28. Por qu no convendra indexar el campo Suspendido de la tabla
Artculo, y
Observaciones de la tabla Cliente.

8.2.

GESTIN DE SEGURIDAD Y USUARIOS EN SQL SERVER

8.2.1. Seguridad en SQL Server


SQL Server valida a los usuarios con 2 niveles de seguridad; autentificacin del
login y validacin de permisos en la Base de Datos de cuentas de usuarios y de
roles. La autentificacin identifica al usuario que est usando una cuenta y
verifica slo la habilidad de conectarse con SQL Server. El usuario debe tener
permiso para accesar a las Bases de Datos en el Servidor. Esto se cumple
para asignar permisos especficos para la Base de Datos, para las cuentas de
usuario y los roles. Los permisos controlan las actividades que el usuario tiene
permitido realizar en la Base de Datos del SQL
Server.

8.2.2. Autentificacin del Login


Un usuario debe tener una cuenta para conectarse al SQL Server. Este
reconoce 2 mecanismos de autentificacin: Autentificacin de SQL Server y de
Windows XP/2003. Cada uno tiene un diferente tipo de cuenta.

8.2.3. Autentificacin de SQL Server


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

8.2.4. Autentificacin de Windows XP/2003

Cuando se usa, el usuario no necesita de una cuenta de SQL Server, para


conectarse. Un administrador del sistema debe definir, ya sea cuentas de
Windows XP/2003 o grupos de Windows XP/2003 como cuentas vlidas de
SQL Server.

8.2.5. Modo de Autentificacin

Cuando SQL Server est corriendo en Windows XP/2003, un sistema


administrador puede especificar que est corriendo en uno de 2 modos de
autentificacin:

Modo de autentificacin de Windows XP/2003: Slo est autorizada


laautentificacin de Windows XP/2003. Los usuarios no pueden
usarcuentas de SQL Server.

Modo mixto: Cuando se usa este modo de autentificacin, los usuariosse


pueden

conectar

SQL

Server

con

la

autentificacin

de

WindowsXP/2003 o con la de SQL Server.

8.2.6. Agregar cuentas de inicio de sesin en SQL Server

Si Microsoft SQL Server se configura para funcionar en Modo mixto, o cuando


se ejecuta SQL Server con Microsoft Windows 98 o ME, para autenticar los
usuarios puede ser preferible agregar cuentas de SQL Server que permitan la
conexin con un nombre de inicio de sesin y una contrasea especficos, en
lugar de hacerlo a travs de las cuentas de usuario o de grupo de Microsoft
Windows XP/2003. Esto puede ser necesario por los siguientes motivos:

Para mantener la compatibilidad con aplicaciones creadas para


versiones anterioresde SQL Server, no diseadas para trabajar con
cuentas de Windows XP/2003.

Para las aplicaciones diseadas para trabajar con usuarios en general,


que notengan cuentas de Windows XP/2003.

Para conectarse con SQL Server cuando ste se ejecuta con Windows
95/98, yaque en Windows 98/ME no est disponible la autenticacin de
Windows XP/2003.

8.2.7. El inicio de sesin sa (System Administrador)

Administrador

del

sistema

(sa)

es

una

cuenta

especial.

De

forma

predeterminada, est 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

utilizarsehabitualmente. En su lugar, los administradores deben pertenecer a la


funcin fija de servidor sysadmin y conectarse con sus propios nombres de
inicio de sesin.
Slo debe usarse sa cuando no haya otro modo de iniciar una sesin en SQL
Server; por ejemplo, cuando los dems administradores del sistema no estn
disponibles o cuando hayan olvidado sus contraseas.

8.2.8. Roles o Funciones

Permiten reunir a los usuarios en una sola unidad a la cual se le pueden aplicar
permisos. SQL Server contiene roles de servidor y de Base de Datos
predefinidos, para tareas administrativas comunes, de manera que pueden
asignrsele determinados permisos administrativos a un usuario en particular.
Tambin se pueden crear roles de Base de Datos definidos por el usuario. En
SQL Server, los usuarios pueden pertenecer a varios roles: o Roles fijos del
Servidor: Proveen agrupamientos con privilegios administrativos a nivel del
Servidor. Son administrados independientemente de las Bases de Datos de

usuarios a nivel servidor. O Roles fijos de la Base de Datos: Proveen


agrupamientos con privilegios administrativos a nivel de Base de Datos.
O Roles de usuarios definidos en la Base de Datos: Tambin se pueden crear
roles para Base de Datos, para representar un trabajo desarrollado por un
grupo de empleados dentro de una organizacin. No es necesario asignar y
quitar permisos a cada persona. En funcin de que cambia un rol, se pueden
cambiar fcilmente los permisos del rol y hacer que los cambios se apliquen
automticamente a todos los miembros del rol.
Despus de que los usuarios han sido autentificados, y se les ha permitido
conectarse al SQL Server, deben tener cuentas en la Base de Datos. Las
cuentas de usuario y los roles, identifican permisos para ejecutar tareas.

8.2.9. Cuentas de Usuarios de la Base de Datos

Las cuentas de usuario utilizadas para aplicar permisos de seguridad son las
de usuarios, o grupos de Windows XP/2003 o las de SQL Server. Las cuentas
de usuario son especficas para cada Base de Datos.

8.2.10.

Validacin de permisos

Una vez que se ha autenticado un usuario y se le ha permitido iniciar una


sesin en Microsoft SQL Server mediante su nombre de inicio de sesin, es
necesario que tenga una cuenta en cada base de datos a la que precise tener
acceso. El hecho de requerir una cuenta de usuario en cada base de datos
evita que el usuario pueda conectarse a SQL Server y tener acceso a todas las
bases de datos de un servidor.

Por ejemplo, si un servidor contiene una base de datos llamada personal y otra
llamada contratos, para los usuarios que deban tener acceso a contratos,
pero no a personal , se crear una cuenta nicamente en la base de datos
contratos.
La cuenta de usuario de cada base de datos se utiliza para aplicar los permisos
de seguridad en los objetos (tablas, vistas, procedimientos almacenados,
etctera) que contiene la base de datos. Esta cuenta de usuario puede
asignarse desde cuentas de usuario de Microsoft Windows XP/2003, grupos de
Windows XP/2003 de los que el usuario sea miembro o cuentas de inicio de
sesin de SQL Server. Si no hay ninguna cuenta asignada directamente, el
usuario puede trabajar en la base de datos con la cuenta invitado, si existe.
Las actividades que se permite realizar al usuario se controlan con los

permisos aplicados a la cuenta de usuario utilizada para el acceso a la base de


datos.
SQL Server slo acepta comandos despus de que el usuario haya obtenido
acceso a la base de datos. El usuario puede especificar comandos "ad hoc" o
elegir opciones de men de una aplicacin. Todas las actividades que realiza el
usuario en una base de datos se comunican a SQL Server a travs de
instrucciones de Transact-SQL. Cuando SQL Server recibe una instruccin de
Transact-SQL, comprueba que el usuario tenga permiso para ejecutar esta
instruccin en la base de datos. Si el usuario no tiene los permisos adecuados,
ya sea para ejecutar una instruccin, o para tener acceso a un objeto de la
base de datos que utilice la instruccin, SQL Server devolver un error de
permisos.

8.2.11.

Propietarios de las bases de datos (dbo)

A todos los miembros de la funcin fija de servidor sysadmin se les asigna un


usuario especial dentro de cada base de datos llamado dbo. Todos los objetos
que cree algn miembro de la funcin fija de servidor sysadmin pertenecen
automticamente a dbo.
Por ejemplo, si la usuaria Andrea es miembro de la funcin fija de servidor
sysadmin y crea una tabla llamada T1, T1 pertenecer a dbo y se calificar
como dbo.T1, y nocomo Andrea.T1.
Por otra parte, si Andrea no es miembro de la funcin fija de servidor
sysadmin, pero es miembro de la funcin fija de base de datos db_owner y
crea una tabla llamada T1,T1pertenecer a Andrea y se calificar como
Andrea.T1. No es posible eliminar el usuario dbo. Usuario guest (invitado)

La cuenta de usuario guest (invitado) permite iniciar una sesin sin tener
una cuenta de usuario para obtener acceso a una base de datos. Al
iniciar una sesin se asume laidentidad del usuario guest cuando se
cumplen todas las condiciones siguientes:

El nombre de inicio de sesin tiene acceso a Microsoft SQL Server, pero


no ala base de datos a travs de su propia cuenta de usuario.

La base de datos contiene una cuenta de usuario guest.

Es posible aplicar permisos al usuario guest de la misma forma que a cualquier


otra de usuario. El usuario guest puede eliminarse y agregarse en cualquier
base de datos, excepto en master y tempdb donde siempre debe existir. De
forma predeterminada, al crear una nueva base de datos no existe en ella la
cuenta de usuario guest .

8.2.12.

Funcin public

La funcin public es una funcin de base de datos especial a la que


pertenecen todos los usuarios de la base de datos. La funcin public:

Tiene todos los permisos predeterminados de los usuarios de la base de


datos.

No puede incrementarse con nuevos usuarios, grupos o funciones, ya


que todospertenecen ya a ella de forma predeterminada.

Est contenida en todas las bases de datos, incluidas master, msdb,


tempdb,model y todas las bases de datos de usuario.

No es posible eliminarla

8.2.13.

Permisos

Cuando los usuarios se conectan con Microsoft SQL Server, las actividades
que pueden llevar a cabo se determinan con los permisos otorgados a sus
cuentas de seguridad, a los grupos de Microsoft Windows XP/2003 o a las
jerarquas de funciones a las que pertenecen sus cuentas de seguridad. El
usuario debe tener los permisos adecuados para realizar cualquier actividad
que implique cambiar la definicin de una base de datos o el acceso a su
contenido. Algunas actividades como, por ejemplo, las que no cambien ningn
elemento de la base de datos ni supongan acceso a su contenido, no necesitan
permisos. Dentro de cada Base de Datos, se asignan permisos a las cuentas
de usuarios y a los roles para permitir o limitar ciertas acciones. SQL

Server acepta comandos despus de que un usuario ha accesado a la Base de


datos.

SQL Server realiza los siguientes pasos cuando valida permisos:


1. Cuando el usuario realiza una accin, tal como ejecutar un comando de
Transact-SQL o elegir una opcin de un men, los comandos de Transact SQL
son enviadas al SQL Server.
2. Cuando SQL Server recibe un comando de Transact SQL, checa que el
usuario tenga permiso de ejecutar dicha instruccin.
3. Despus, SQL realiza cualquiera de las siguientes acciones:
a) Si el usuario no tiene los permisos adecuados, SQL Server devuelve un
error.
b) Si el usuario tiene los permisos adecuados, SQL Server realiza la accin.
Permisos de objeto

Al trabajar con datos o ejecutar un procedimiento, es necesario disponer de


una clase de permisos conocida como permisos de objeto. Los permisos de
objeto se basan en una tabla, vista o procedimiento almacenado, y controlan la
capacidad de ejecutar las instrucciones SELECT, INSERT, UPDATE y DELETE

en la tabla o vista, o el permiso EXECUTE en el procedimiento almacenado.


Por ejemplo, si un usuario necesita obtener datos de toda una tabla, ser
necesario otorgarle el permiso de objeto SELECT. Los permisos de objeto son:
Permisos para las instrucciones SELECT, INSERT, UPDATE y DELETE, que
pueden aplicarse a toda la tabla o vista.

Permisos para las instrucciones SELECT y UPDATE, que pueden


aplicarseselectivamente a columnas individuales de una tabla o vista.

Permisos para las instrucciones INSERT y DELETE, que afectan a toda


unafila y, por ello, slo pueden aplicarse a la tabla o vista, y no a
columnasindividuales.

Permisos para la instruccin EXECUTE, que slo afectan a los


procedimientosalmacenados.

Permisos de instruccin

Las actividades que implica la creacin de una base de datos o de uno de sus
elementos, como una tabla o un procedimiento almacenado, necesitan una
clase diferente de permisos, llamados permisos de instruccin. Por ejemplo, si
un usuario necesita crear una tabla en una base de datos, ser necesario
otorgarle el permiso de instruccin CREATE TABLE. Los permisos de
instruccin como, por ejemplo,
CREATE DATABASE, se aplican a la instruccin en s y no a un objeto
especfico definido en la base de datos.
Permisos implcitos

La ltima clase de actividades controladas con permisos en SQL Server la


forman aqullas que slo pueden realizar los miembros de las funciones de
sistema predefinidas o los propietarios de objetos de base de datos. Por
ejemplo, un miembro de la funcin fija de servidor sysadmin hereda
automticamente todos los permisos para realizar cualquier actividad o ver
cualquier elemento de la instalacin de SQL

Server. La funcin sysadmin tiene permisos que no pueden cambiarse y


permisos implcitos, como la capacidad de configurar la instalacin de SQL
Server, que no pueden aplicarse a otras cuentas de usuario.
Los propietarios de objetos de base de datos tambin tienen permisos
implcitos que les permiten realizar todas las actividades con los objetos que les
pertenecen. Por ejemplo, si un usuario es propietario de una tabla, puede ver,
agregar o eliminar datos en ella, modificar la definicin de la tabla o controlar
sus permisos para permitir que otros usuarios trabajen con ella.

8.2.14.

Reglas para los nombres de inicio de sesin, usuarios,

funciones y contraseas de SQL Server

Los nombres de inicio de sesin, usuarios, funciones y contraseas de


Microsoft SQL
Server pueden contener de 1 a 128 caracteres y pueden incluir letras, smbolos
y nmeros (por ejemplo Agustina Rivera, Federico Couto o 13&#57abc). Por
lo tanto,los nombres de usuario de Microsoft Windows XP/2003 y Microsoft
Windows 98 o
ME pueden usarse como nombres de inicio de sesin de SQL Server.
Sin embargo, en las instrucciones de Transact-SQL algunos smbolos slo se
pueden utilizar si el nombre de inicio de sesin, usuario, funcin o contrasea
estn delimitados por comillas dobles (") o corchetes ([ ]). Debe utilizar
delimitadores en las instrucciones de Transact-SQL cuando el nombre de inicio
de sesin, usuario, funcin o contrasea de SQL Server: Contenga o comience
por un espacio, Comience por el carcter $ o @.
Nota No es necesario especificar los delimitadores al escribir los nombres de
inicio de sesin, usuarios, funciones y contraseas en los cuadros de texto de
las herramientas grficas de cliente de SQL Server como, por ejemplo, el
Administrador corporativo de
SQL Server.
Adems, un nombre de inicio de sesin, usuario o funcin de SQL Server no
puede:

Contener el carcter barra diagonal inversa (\), salvo que se refiera a un


usuario ogrupo existente de Windows XP/2003. La barra diagonal
inversa separa el nombredel equipo o dominio de Windows XP/2003 del
no mbre del usuario.

Existir ya en la base de datos actual (o en master, en el caso de los


nombres deinicio de sesin).

Ser NULL, o una cadena vaca ("").

8.2.1 LABORATORIO: GESTIN DE SEGURIDAD Y USUARIOS EN SQL


SERVER

1. Ingrese al analizador de consultas. Agregue los siguientes inicios de sesin


(login), con sus respectivas contraseas:
exec sp_addlogin 'Usuario1', 'Usuario1'
exec sp_addlogin 'Usuario2', 'Usuario2'
exec sp_addlogin 'Usuario3', 'Usuario3'
2. Compruebe los inicios de sesin creados: select substring(name,1,25) as
nombre,substring(password,1,20) as contrasea,
language FROM sysxlogins
3. Seleccione la base de datos Supermercado. Otorgue acceso a los tres
inicios de sesin creados:
exec sp_grantdbaccess 'usuario1'
exec sp_grantdbaccess 'usuario2'
exec sp_grantdbaccess 'usuario3'
4. Verifique los usuarios creados:
sp_helpuser
5. Por qu los usuarios pertenecen al grupo Public por defecto?
6. Incorpore el usuario guest a la base de datos supermercado:
sp_grantdbaccess guest
sp_helpuser
7. Recuerde la funcin que cumple el usuario guest:

8. Recuerde el concepto de Funciones a nivel de servidor, y de Funciones a


nivel de base de datos.
9. Conceda la funcin de lectura de datos db_datareader, al usuario1:
sp_addrolemember 'db_datareader','usuario1'
10. Deniegue la funcin de lectura de datos db_denydatareader, al usuario2:
sp_addrolemember 'db_denydatareader','usuario2'
11. Conceda la funciones de lectura y escritura de datos db_datareader y
db_datawriter, al
usuario3:
exec sp_addrolemember 'db_datareader','usuario3'
exec sp_addrolemember 'db_datawriter','usuario3'
12. Desde el administrador corporativo, ingresar 2 registros a las tablas
Cajero y Cliente, de la B.D. Supermercado.
13. Inicie Microsoft Access. Seleccione el mtodo de creacin: Asistente,
pginas y proyectos de bases de datos.
14. Desde la pestaa General, seleccione el icono Proyecto (Base de datos
existente), ingrese el nombre Supermercado para el nuevo proyecto.
15. Siga las indicaciones del instructor para conectar el proyecto creado a la
base de datos supermercado, del SQL Server, utilizando en primera instancia
al usuario sa.
16. Compruebe que tenga acceso a todas las tablas y al diagrama de la base
de datos.
17. Desde Microsoft Access, ingrese al men archivo, opcin conexin.
18. Seleccione al usuario1. Compruebe si el usuario puede leer y escribir
datos en las tablas.
19. Seleccione al usuario2. Compruebe si el usuario puede leer y escribir
datos en las tablas.
20. Seleccione al usuario3. Compruebe si el usuario puede leer y escribir
datos en las tablas.
21. Ingrese al administrador corporativo. Actualice la base de datos
Supermercado.
Compruebe la existencia de logins, usuarios y funciones creadas desde el
analizador de consultas.

22. Desde el objeto usuarios de la base de datos supermercado, ingrese a


las propiedades del
usuario1.
23. Ingrese a los permisos del usuario. Otorgue los permisos de INSERT y
UPDATE para la tabla Cajero.
24. Reingrese a Microsoft Access como usuario1.
25. Compruebe que puede insertar registros o modificar datos en la tabla
cajero.
26. Compruebe que el resto de tablas sean de solo lectura.
27. Explique el esquema de seguridad que posee el usuario1.
28. Ingrese a los permisos del usuario2. Otorgue el permiso de SELECT para
la tabla Cajero.
29. Reingrese a Microsoft Access como usuario2.
30. Por qu no figura la tabla Cajero disponible para lectura, an as
habindose dado al usuario el permiso respectivo?
31. Qu modificaciones seran necesarias para que el usuario2, pueda
acceder en modo lectura a la tabla Cajero?. Comprubelo.
32. Ingrese a los permisos del usuario3. Otorgue el permiso de SELECT para
la tabla Cajero.
33. Reingrese a Microsoft Access como usuario2. Configure los siguientes
pemisos:

34. Qu significado tienen?


35. Reingrese a Microsoft Access como usuario3. Compruebe los permisos
configurados.
36. Ingrese al analizador de consultas.
37. Otorgue al usuario2, permisos de lectura sobre la tabla Cliente:

GRANT select ON cliente to usuario2


38. Otorgue al usuario1, y al usuario2, permisos de INSERT Y UPDATE,
sobre la tabla
Cajero.
GRANT insert,update ON cajero to usuario1,usuario2
39. Ingrese al administrador corporativo. Compruebe grficamente los permisos
otorgados.
40. Genere un usuario4, que pueda modificar datos en la tabla Cliente, pero
no pueda agregar datos a la misma. Tampoco debe poder leer las dems
tablas.
41. Genere un usuario5,, que tenga permisos de lectura sobre las tablas
Cajero y Artculo,de eliminacin sobre las tablas DocVenta y Cliente, y de
lectura sobre el resto de tablas.
42. Genere un usuario denominado SuperUsuario, con la misma jerarqua y
permisos que el usuario sa. Compruebe su funcionalidad.

CAPITULO IX
NORMALIZACIN

9.1. Formas Normales de Bases de Datos


Las formas normales son reglas que se han desarrollado para evitar las
incongruencias lgicas que se podran producir al actualizar tablas. Cada forma
normal prohibe una forma de redundancia en la organizacin de una tabla, que
pudiera dar lugar a resultados sin sentido si se actualizase una tabla de forma
independiente de las dems tablas. Existen mltiples niveles de forma normal.
Cada nivel superior de forma normal aade una restriccin a la forma normal
anterior. A medida que el diseador de la base de datos va satisfaciendo una
forma normal superior, las tablas tienden a fragmentarse; las formas normales
mejoran la congruencia de la base de datos a costa de ms navegacin y de
una ejecucin ms lenta de las consultas. No debe uno de violar
inadvertidamente las formas normales, pero en ocasiones puede hacerse si
hay una buena razn, tal como el rendimiento.
Una tabla se encuentra en la primera forma normal cuando ninguno de los
valores de sus atributos contiene un grupo repetitivo. La siguiente Figura (a)
tiene una fila con dos entradas en nombre de equipo y por tanto viola la primera
forma normal. Al rehacer la entrada doble en forma de dos filas, se satisface la
primera forma normal
Una tabla se encuentra en la segunda forma normal cuando satisface la
primera forma normal y adems cada fila tiene una clave primaria. Todo campo
clave no primaria debe de depender por completo de la clave primaria. La
Figura (b) viola la segunda forma normal, porque fabricante de equipo y
direccin de fabricante dependen de la clave primaria completa, mientras que
gerente de planta slo depende de una parte de la clave primaria. La Figura (c)
segrega la dependencia parcial en otra tabla, y satisface la segunda forma
normal.

Una tabla se encuentra en la tercera forma normal cuando satisface la segunda


forma normal, y todo atributo clave no primario depende directamente de la
clave primaria.
La Figura (c) viola la tercera forma normal, porque hay una dependencia
transitiva; direccin de fabricante depende de fabricante de equipo, que a su
vez depende de la clave primaria. Una vez ms, la descomposicin en dos
tablas resuelve el problema.
9.2. Un ejemplo de normalizacin
La figura mostrada es una vista de usuario de la compaa de equipo Al S. Well
Hydraulic. El reporte muestra (1) el NMERO DE VENDEDOR, (2) el NOMBRE
DE VENDEDOR y (3) el REA DE VENTA. El cuerpo del reporte muestra (4)
NMERO DE CLIENTE y (5) NOMBRE DE CLIENTE. Luego est (6) el
NMERO DE ALMACN que dar servicio al cliente, seguido por (7) la
UBICACIN DEL ALMACN, que es la ciudad en donde est ubicada la
compaa.
La informacin final contenida en la vista de usuario es (8) IMPORTE DE
VENTA.
Los renglones (uno para cada cliente) de la vista de usuario muestran que los
conceptos 4 a 8 forman un grupo repetido.
Si el analista estaba usando un enfoque de flujo de datos/diccionario de datos,
la misma informacin de la vista de usuario podra aparecer en una estructura
de datos.

A. Primera Forma Normal (1NF).


El primer paso para la normalizacin de una relacin es eliminar los grupos
repetidos.
En nuestro ejemplo, la relacin no normalizada REPORTE DE VEN TAS ser
dividida en dos relaciones separadas. Estas nuevas relaciones sern llamadas
VENDEDOR y
VENDEDOR-CLIENTE.
La siguiente figura muestra cmo la relacin original no normalizada REPORTE
DE VENTAS es normalizada separando la relacin en dos nuevas relaciones.
Observe que la relacin VENDEDOR contiene la llave primaria NUMERO DE
VENDEDOR y todos los atributos que no fueron repetidos (NOMBRE DE
VENDEDOR y REA DE VENTA).
La segunda relacin, VENDEDOR-CLIENTE, contiene la llave primaria de la
relacin VENDEDOR (la llave primaria de VENDEDOR es NMERO DE
VENDEDOR) as como todos los atributos que fueron parte del grupo repetido
(NMERO DE CLIENTE, NOMBRE DE CLIENTE, NMERO DE BODEGA,
UBICACIN DE BODEGA e IMPORTE DE VENTA). Sin embargo, el saber el
NMERO DE VENDEDOR no es suficiente para saber el NOMBRE DE
CLIENTE,
IMPORTE DE VENTA, UBICACIN DE BODEGA, etc. En esta relacin, se
debe usar una llave concatenada (NMERO DE VENDEDOR y NMERO DE
CLIENTE) para accesar el resto de la informacin.

La relacin VENDEDOR-CLIENTE es una primera relacin normal, pero no


est en su forma ideal. Los problemas vienen del hecho de que algunos de los
atributos no son funcionalmente dependientes de la llave primaria, NUMERO
DE VENDEDOR.
NUMERO DE CLIENTE. En otras palabras, algunos de los atributos que no son
llave son dependientes solamente del NMERO DE CLIENTE y no de la llave
concatenada. El diagrama de modelo de datos de la figura 17.27 muestra que
IMPORTE DE VENTA es dependiente tanto de NMERO DE VENDEDOR y
NMERO DE CLIENTE, pero los otros tres atributos son dependientes
solamente del NMERO DE CLIENTE.

B. Segunda Forma Normal (2NF).


En la segunda forma normal todos los atributos sern funcionalmente
dependientes de la llave primaria. Por lo tanto, el siguiente paso es remover
todos los atributos parcialmente dependientes y ponerlos en otra relacin. La
siguiente figura muestra cmo es dividida la relacin VENDEDOR-CLIENTE en
dos nuevas relaciones:
VENTAS y CLIENTE-BODEGA.
La relacin CLIENTE-BODEGA est en la segunda forma normal. Todava
puede ser ms simplificada, debido a que hay dependencias adicionales dentro
de la relacin.
Algunos de los atributos que no son de llave no son solamente dependientes
de la llave primaria, sino tambin de un atributo que no es llave. A esta
dependencia se le menciona como dependencia transitiva.

C. Tercera Forma Normal (3NF).


Una relacin normalizada es tercera normal si todos los atributos que no son
llave son funcionalmente dependientes por completo de la llave primaria y no
hay dependencias transitivas (que no son llave). En una forma similar a los
pasos anteriores, es posible dividir la relacin CLIENTE-BODEGA en dos
relaciones, tal como se muestra en la siguiente figura.
La llave primaria de la relacin CLIENTE es NMERO DE CLIENTE, y la llave
primaria de la relacin BODEGA es NMERO DE BODEGA.
Adems de estas llaves primarias podemos identificar a NUMERO DE
BODEGAcomo llave fornea en la relacin CLIENTE. Una llave fornea es
cualquier atributo que no es llave en una relacin pero que es llave primaria en
otra relacin. Por ltimo, la relacin original no normalizada, REPORTE DE
VENTAS, ha sido transformada en cuatro relaciones tercera normal (3NF). La
tercera forma normal es adecuada para la mayora de los problemas de diseo
de base de datos. La simplificacin que se tiene mediante la transformacin de
una relacin no normalizada a un juego de relaciones
3NF es un beneficio inmenso para la insercin, borrado y actualizacin de
informacin en la base de datos.

Las tablas finales resultantes del proceso de normalizacin son:

Normalizar los siguientes formatos, obtener el modelo relacional.

9.3. EXTRACCIN Y MODIFICACIN DE DATOS

9.3.1. CONSULTAS Y VISTAS EN SQL SERVER

Crear instrucciones de Transact-SQL

Una instruccin SELECT contiene los elementos comunes usados en las


instrucciones de Transact-SQL. Por ejemplo, para seleccionar los nombres,
nombres de contacto y nmeros de telfono de los clientes que viven en
Estados Unidos de la tabla Customers de la base de datos Northwind, se usan
estos elementos:
El nombre de la base de datos que contiene la tabla (Northwind)
El nombre de la tabla que contiene los datos (Customers)
Una

lista

de

las

columnas

cuyos

datos

se

van

devolver

(CompanyName,
ContactName, Phone)
Los criterios de seleccin (slo para los clientes que viven en Estados
Unidos)
A continuacin se muestra la sintaxis de Transact-SQL utilizada para recuperar
esta
informacin:
SELECT CompanyName, ContactName, Phone
FROM Northwind.dbo.Customers
WHERE Country = 'USA'
Entre los elementos adicionales usados en instrucciones de Transact-SQL se
encuentran:

Funciones

Las funciones se usan en las consultas, informes y muchas instrucciones de


Transact- SQL de SQL Server para devolver informacin, de forma parecida a
como se utilizan las funciones de otros lenguajes de programacin. Toman
parmetros de entrada y devuelven un valor que se puede usar en las
expresiones. Por ejemplo, la funcin
DATEDIFF toma dos fechas y una parte de una fecha (semanas, das, meses,
etc.)como argumentos y devuelve el nmero de unidades de parte de fecha
que hay entredos fechas.

Identificadores

Los identificadores son los nombres dados a los objetos, como, por ejemplo,
tablas, vistas, bases de datos e ndices. Un identificador se puede especificar
sin delimitadores (por ejemplo, TEST), con delimitadores entre comillas (por
ejemplo, "TEST") o entre corchetes (por ejemplo, [TEST]).

Comentarios

Los comentarios son fragmentos de texto que no se ejecutan en el cdigo del


programa.

Expresiones

Las expresiones incluyen valores de constantes o literales (por ejemplo, 5 es


un literal numrico), funciones, nombres de columna, aritmtica, operaciones
de bits,
subconsultas escalares, funciones CASE, funciones COALESCE y funciones
NULLIF.

Palabras clave reservadas

Las palabras que SQL Server reserva para su propio funcionamiento. Se


recomienda evitar la utilizacin como identificadores de estas palabras clave
reservadas.

Valores NULL

Los valores NULL son aquellos que son desconocidos. Puede usar valores
NULL para indicar que la informacin se proporcionar posteriormente. Por
ejemplo, si la persona de contacto de la empresa Comercio Leka cambia y no
se conoce la nueva persona de contacto, podra indicar que su nombre es
desconocido con un valor NULL.

Tipos de datos

Los tipos de datos definen el formato en el que se almacenan los datos. Por
ejemplo, puede usar cualquiera de los tipos de datos de carcter o Unicode
(char, varchar, nchar o nvarchar) para almacenar los datos de carcter como,
por ejemplo, los nombres de los clientes.

Lotes

Los lotes son grupos de instrucciones transmitidas y ejecutadas como una


unidad.

Algunas instrucciones de Transact-SQL no se pueden agrupar en un lote. Por


ejemplo, para crear cinco tablas nuevas en la base de datos pubs, cada
instruccin CREATE
TABLE debe encontrarse en su propio lote o unidad. A continuacin se muestra
un ejemplo de un lote de Transact-SQL:
USE Northwind
SELECT *
FROM Customers
WHERE Region = 'WA'
AND Country = 'USA'
ORDER BY PostalCode ASC, CustomerID ASC
UPDATE Employees
SET City = 'Missoula'
WHERE CustomerID = 'THECR'
GO

Operadores

SQL Server incluye operadores que permiten la ejecucin de ciertas acciones


en los datos. Por ejemplo, mediante la utilizacin de operadores aritmticos
puede realizar operaciones matemticas como, por ejemplo, sumas y restas en
los datos.

Aspectos bsicos de las consultas

Una consulta es una peticin de datos almacenados en Microsoft SQL Server.


Una consulta se puede emitir de varias formas:

Un usuario de MS Query o de Microsoft Access puede usar una interfaz


grfica de usuario (GUI) para elegir los datos que desea ver de una o
variastablas de SQL Server.

Un usuario del Analizador de consultas de SQL Server o de osql puede


emitiruna instruccin SELECT.

Una aplicacin de Microsoft Visual Basic puede asignar los datos de


unatabla de SQL Server a un control enlazado, como, por ejemplo, una
cuadrcula.

Aunque las consultas tienen varias formas de interactuar con un usuario, todas
realizanla misma tarea: presentan al usuario el conjunto de resultados de una
instruccin
SELECT. Incluso si el usuario no especifica nunca una instruccin SELECT,
como suele suceder con las herramientas grficas como MS Query, el software
de cliente transforma la consulta de cada usuario en una instruccin SELECT
que se enva a SQL Server.
La instruccin SELECT recupera los datos de SQL Server y los presenta de
nuevo al usuario en uno o ms conjuntos de resultados. Un conjunto de
resultados es una organizacin tabular de los datos obtenidos de SELECT. Al
igual que una tabla de SQL, el conjunto de resultados est formado por
columnas y filas.
La sintaxis completa de la instruccin SELECT es compleja, aunque la mayor
parte de las instrucciones SELECT describen las cuatro propiedades
principales de un conjunto de resultados:

El nmero y atributos de las columnas del conjunto de resultados. Estos


atributos se definen para cada columna del conjunto de resultados:

El tipo de datos de la columna.

El tamao de la columna y, para las columnas numricas, la precisin y


escala.

El origen del valor de los datos devueltos en la columna.

Las tablas cuyos datos del conjunto de resultados se recuperan y


cualquierrelacin lgica entre las tablas.

Las condiciones que deben cumplir las filas de las tablas de origen
parasatisfacer los requisitos de la instruccin SELECT. Las filas que no
cumplenlas condiciones se omiten.

La secuencia en la que se ordenan las filas del conjunto de


resultados.Esta instruccin SELECT busca el identificador del producto,
el nombre y el precio unitario de cualquier producto cuyo precio exceda
de 40 dlares:

SELECT ProductID, ProductName, UnitPrice


FROM Products
WHERE UnitPrice > $40

ORDER BY UnitPrice ASC

Componentes de una instruccin SELECT

La sintaxis completa de la instruccin SELECT es compleja, aunque las


clusulas principales se pueden resumir como sigue:
SELECT listaSeleccin
[INTO nombreNuevaTabla]
FROM listaTablas
[WHERE condicionesBsqueda]
[GROUP BY listaAgrupaciones]
[HAVING condicionesBsqueda]
[ORDER BY listaClasificacin [ASC | DESC] ]
listaSeleccin
Describe las columnas del conjunto de resultados. Es una lista de expresiones
separadas por comas. Cada expresin define tanto el formato (tipo de datos y
tamao) como el origen de los datos para la columna del conjunto de
resultados. Cada expresin de lista de seleccin suele ser una referencia a una
columna de la tabla o vista de origen de la que provienen los datos, aunque
puede ser cualquier otra expresin, como una constante o una funcin de
Transact-SQL. Al usar la expresin * en una lista de seleccin se especifica
que se devolvern todas las columnas de la tabla de origen.
INTO nombreNuevaTabla
Especifica que el conjunto de resultados se usa para crear una tabla nueva.
nombreNuevaTablaespecifica el nombre de la nueva tabla.
FROM listaTablas
Contiene una lista de las tablas cuyos datos del conjunto de resultados se
recuperan.
Estos orgenes pueden ser:

Tablas base del servidor local donde se ejecuta Microsoft SQL


Server.

Vistas del servidor SQL Server local. SQL Server resuelve internamente
lareferencia de una vista a las referencias en las tablas base que
componen lavista.

Tablas vinculadas, que son las tablas de los orgenes de datos OLE
DBaccesibles para SQL Server.

La clusula FROM puede contener tambin especificaciones de


combinacin, que definen la ruta de acceso especfica que debe usar
SQL Server al pasar de una tabla a otra.

La clusula FROM se usa tambin en las instrucciones DELETE y


UPDATE paradefinir las tablas que se modifican.

WHERE condicionesBsqueda
La clusula WHERE es un filtro que define las condiciones que debe cumplir
cada fila de las tablas de origen para satisfacer los requisitos de la instruccin
SELECT. Slo las filas que cumplen las condiciones contribuyen con datos al
conjunto de resultados.
Los datos de las filas que no cumplen las condiciones no se usan.
La clusula WHERE se usa tambin en las instrucciones DELETE y UPDATE
para definir las filas de las tablas de destino que deben modificarse.
GROUP BY listaAgrupaciones
La clusula GROUP BY particiona en grupos el conjunto de resultados segn
los valores de las columnas de la listaAgrupaciones. Por ejemplo, la tabla
Northwind
Orders tiene tres valores en ShipVia. Una clusula GROUP BY ShipVia divide
el conjunto de resultados en tres grupos, uno por cada valor de ShipVia.
HAVING condicionesBsqueda
La clusula HAVING es un filtro condicional que se aplica al conjunto de
resultados.
Lgicamente, la clusula HAVING filtra las filas del conjunto intermedio de
resultados que se genera como consecuencia de la aplicacin de alguna
clusula
FROM, WHERE o GROUP BY en la instruccin SELECT. Las clusulas
HAVING se usan normalmente con una clusula GROUP BY, aunque no se
necesita una clusula GROUP BY antes de una clusula HAVING.
ORDER BY listaClasificacin [ ASC | DESC ]
La clusula ORDER BY define el orden de las filas del conjunto de resultados.
listaClasificacinespecifica las columnas del conjunto de resultados que forman
lalista de clasificacin. Las palabras clave ASC y DESC se usan para
especificar si las filas se ordenan en una secuencia ascendente o descendente.

La clusula ORDER BY es importante porque la teora relacional especifica que


no se puede suponer que las filas de un conjunto de resultados tengan ninguna
secuencia a menos que se especifique ORDER BY. ORDER BY debe usarse
en cualquier instruccin SELECT para la que sea importante el orden de las
filas del conjunto de resultados.
Las clusulas de una instruccin SELECT deben especificarse en el orden
correcto.
Cada referencia a un objeto de base de datos debe ser inequvoco. La
ambigedad puede estar provocada por lo siguiente:
Es posible que haya varios objetos con el mismo nombre en un sistema. Por
ejemplo, tanto User1 como User2 pueden haber definido una tabla llamada
TableX. Para resolver la ambigedad y especificar la TableX que es propiedad
de User1, califique el nombre de la tabla con el identificador del usuario, como
mnimo:
SELECT *
FROM User1.TableX
La base de datos en la que reside el objeto puede que no sea siempre la base
de datos actual cuando se ejecute la instruccin SELECT. Para asegurar que
se usa siempre el objeto correcto, independientemente de la configuracin de
la base de datos actual, califique el nombre del objeto con la base de datos y el
propietario:
SELECT *
FROM Northwind.dbo.Shippers
Las tablas y vistas especificadas en la clusula FROM pueden tener nombres
duplicados de columna. Es muy probable que las claves externas tengan el
mismo nombre de columna que las claves principales con las que se
relacionan. Para resolver la ambigedad entre los nombres duplicados, el
nombre de la columna debe calificarse con el nombre de la tabla o de la vista:
SELECT DISTINCT Customers.CustomerID, Customers.CompanyName
FROM

Customers

JOIN

Orders

ON

Orders.CustomerID)
WHERE Orders.ShippedDate > 'May 1 1998'

Utilizar combinaciones

Customers.CustomerID

Las condiciones de combinacin se pueden especificar en las clusulas FROM


o
WHERE, aunque se recomienda que se especifiquen en la clusula FROM. Las
clusulas WHERE y HAVING pueden contener tambin condiciones de
bsqueda para filtrar an ms las filas seleccionadas por las condiciones de
combinacin.
Las combinaciones se pueden clasificar en:

Combinaciones internas (la operacin de combinacin tpica, que usa

algunos operadores de comparacin como = o <>). En este tipo se incluyen las


combinacin equivalente y las combinaciones naturales.
Las combinaciones internas usan un operador de comparacin para hacer
coincidir lasfilas de dos tablas segn los valores de las columnas comunes de
cada tabla. Un ejemplo sera recuperar todas las filas en las que el nmero de
identificacin de estudiante es el mismo en las tablas students y courses.

Combinaciones externas. Pueden ser una combinacin externa


izquierda, derecha o completa.

Las combinaciones externas se especifican en la clusula FROM con uno de


los siguientes conjuntos de palabras clave:

LEFT JOIN o LEFT OUTER JOIN.


El conjunto de resultados de una combinacin externa izquierda incluye todas
las filas de la tabla de la izquierda especificada en la clusula LEFT OUTER, y
no slo aquellas en las que coincidan las columnas combinadas. Cuando una
fila de la tabla de la izquierda no tiene filas coincidentes en la tabla de la
derecha, la fila asociada del conjunto de resultados contiene valores NULL en
todas las columnas de la lista de seleccin que procedan de la tabla de la
derecha.
RIGHT JOIN o RIGHT OUTER JOIN.
Una combinacin externa derecha es el inverso de una combinacin externa
izquierda. Se devuelven todas las filas de la tabla de la derecha. Cada vez que
una fila de la tabla de la derecha no tenga correspondencia en la tabla de la
izquierda, se devuelven valores NULL para la tabla de la izquierda.

FULL JOIN o FULL OUTER JOIN.


Una combinacin externa completa devuelve todas las filas de las tablas de la
izquierda y la derecha. Cada vez que una fila no tenga coincidencia en la otra
tabla, las columnas de la lista de seleccin de la otra tabla contendrn valores
NULL. Cuando haya una coincidencia entre las tablas, la fila completa del
conjunto de resultados contendr los valores de datos de las tablas base.

Combinaciones cruzadas. Las combinaciones cruzadas devuelven


todas

las filas de la tabla izquierda y cada fila de la tabla izquierda se combina con
todas las filas de la tabla de la derecha. Las combinaciones cruzadas se llaman
tambin productos cartesianos.
Por ejemplo, sta es una combinacin interna que recupera los autores que
viven en la misma ciudad y estado que un editor:
USE pubs
SELECT a.au_fname, a.au_lname, p.pub_name
FROM authors AS a INNER JOIN publishers AS p
ON a.city = p.city
AND a.state = p.state
ORDER BY a.au_lname ASC, a.au_fname ASC

Vistas

Una vista es una tabla virtual cuyo contenido est definido por una consulta. Al
igual que una tabla real, una vista consta de un conjunto de columnas y filas de
datos con un nombre. Sin embargo, la vista no existe como conjunto de valores
de datos almacenados en una base de datos. Las filas y las columnas de datos
proceden de tablas a las que se hace referencia en la consulta que define a la
vista y se producen de forma dinmica cuando se hace referencia a la vista.
Una vista acta como filtro de lastablas subyacentes a las que se hace
referencia en ella. La consulta que define a lavista puede ser de una o de
varias tablas, o bien tratarse de otras vistas de la base de datos actual o de
otras bases de datos. Asimismo, es posible utilizar las consultas distribuidas
para definir vistas que utilicen datos de orgenes diversos. Esto puede resultar
de utilidad, por ejemplo, si desea combinar datos de estructura similar que
proceden de distintos servidores, cada uno de los cuales almacena los datos
para una regin distinta de la organizacin.No hay restricciones que afecten a

las consultas mediante vistas y hay pocas restricciones que afecten a la


modificacin de datos mediante esas consultas.

Funciones de Agregado

Las funciones de agregado (SUM, AVG, COUNT, COUNT(*), MAX y MIN)


generan valores de resumen en los conjuntos de resultados de las consultas.
Una funcin de agregado (con la excepcin de COUNT(*)) procesa todos los
valores seleccionados en una nica columna para generar un nico resultado.
Las funciones de agregado se pueden aplicar a todas las filas de una tabla, a
un subconjunto de la tabla especificado
por una clusula WHERE o a uno o varios grupos de filas de la tabla. Cuando
se aplica una funcin de agregado, se genera un valor individual por cada
conjunto de filas.
En este ejemplo se calcula la suma de las ventas del ao hasta la fecha
(ytd_sales) de todos los libros de la tabla titles.
USE pubs
SELECT SUM(ytd_sales)
FROM titles
El siguiente es el conjunto de resultados:
97446
Con esta consulta, puede averiguar el precio promedio de todos los libros si se
duplicaran los precios.
USE pubs
SELECT avg(price * 2)
FROM titles
El siguiente es el conjunto de resultados:
29.53

Funcin de agregado:

SUM([ALL

DISTINCT]

expression)

Total

de

los

valores

de

la

expresinnumrica.
AVG([ALL | DISTINCT] expression) Promedio de los valores de la expresin
numrica.
COUNT([ALL | DISTINCT] expression) Nmero de valores en la expresin.
COUNT(*) Nmero de filas seleccionadas.
MAX(expression) Valor mayor de la expresin.

MIN(expression) Valor menor de la expresin.


Obs: SUM, AVG, COUNT, MAX y MIN omiten los valores NULL; COUNT(*) no
lo hace.
La palabra clave opcional DISTINCT se puede usar con SUM, AVG y COUNT
para eliminar los valores duplicados antes de que se establezca la funcin de
agregado (el valor predeterminado es ALL).
SUM y AVG se pueden usar slo con columnas numricas, como, por ejemplo,
las de los tipos de datos int, smallint, tinyint, decimal, numeric, float, real,
money y
smallmoney. MIN y MAX no se pueden usar con tipos de datos bit. El resto de
las funciones de agregado que no sean COUNT(*) no se puede usar con los
tipos de datos texto e imagen.

LABORATORIO: CONSULTAS Y VISTAS EN SQL SERVER

1.

Restaure

la

base

de

Datos

Supermercado

desde

el

archivo

SUPERMERCADO.BAK, contenido en el laboratorio N 05.


2. Desde el administrador corporativo, verifique que cada tabla de la base de
datos Supermercado, contenga los datos cargados.
3. Inicie el administrador de consultas.
4. Agregar un nuevo cliente:
INSERT INTO Cliente(IDCliente, RazonSocial, ApPatContacto,
ApMatContacto, NombreContacto)
VALUES ('PASSUP','Pastelera Super Star', 'Salazar', 'Dalton', 'Jos')
5. Eliminar el cliente anteriormente ingresado:
DELETE FROM Cliente WHERE IDCliente='PASSUP'
6. Modificar el precio del artculo Pan Fino, a 15 soles.
UPDATE Articulo SET PrecioUnidad=15
WHERE NombreArticulo='Pan Fino'
7. Una lista completa de Artculos:
SELECT * FROM Articulo
8. Una lista de nombre de Clientes con sus respectivos telfonos:
SELECT RazonSocial,Telefono FROM Cliente

9. Una relacin de artculos con su respectivo precio, y un campo adicional con


el precio incrementado en un 18%
SELECT NombreArticulo,PrecioUnidad,PrecioUnidad*1.18 AS PrecioInc
FROM Artculo
10. Una relacin de los documentos de venta emitidos, y el mes en el que
fueron emitidos.
SELECT IDDocuVenta,DateName(month,Fecha)
FROM DocVenta
11. Una relacin de los Cajeros con su nmero telefnico
SELECT LEFT(ApPatCajero+' '+NombreCajero+REPLICATE('.',30),30)+
Telefono
FROM Cajero
12. Una lista de los documentos emitidos con sus respectivas fechas, y la fecha
de vencimiento de entrega en 10 dias
SELECT IDDocuVenta,Fecha,DATEADD(day,10,Fecha) as Vencimiento
FROM DocVenta
13. Una relacin de clientes que no tienen nmero de Fax
SELECT RazonSocial
FROM Cliente
WHERE Fax IS NULL
14. Una relacin de clientes que si tienen nmero de Fax
SELECT RazonSocial
FROM Cliente
WHERE Fax IS NOT NULL
15. Una relacin de artculos que cuesten ms de S/. 40.
SELECT NombreArticulo,PrecioUnidad
FROM Artculo
WHERE PrecioUnidad>40
16. Una relacin de los nmeros de documento de venta emitidos en el ao
1997.
SELECT IDDocuVenta,Fecha
FROM DocVenta
WHERE Fecha >='01/01/1997' and Fecha <='12/31/1997'

SELECT IDDocuVenta,Fecha
FROM DocVenta
WHERE Fecha BETWEEN '01/01/1997' and '12/31/1997'
17. Los clientes que viven en Mxico D.F.
SELECT RazonSocial
FROM Cliente
WHERE Ciudad='Mxico D.F.'
18. Los artculos cuyas unidades en exitencia son de 10 o 20 unidades.
SELECT NombreArticulo,UnidExistencia
FROM Artculo
WHERE UnidExistencia=10 or UnidExistencia=20
SELECT NombreArticulo,UnidExistencia
FROM Artculo
WHERE UnidExistencia IN (10,20)
19. Los artculos que cuestan mas de 20 soles por unidad y estn suspendidos
SELECT NombreArticulo, PrecioUnidad
FROM Artculo
WHERE PrecioUnidad>20 AND Supendido=1
20. Los artculos cuyo nombre comience por la letra C
SELECT NombreArticulo
FROM Artculo
WHERE NombreArticulo LIKE 'C%'
21. Los clientes cuya segunda letra de la Razn Social sea O
SELECT RaznSocial
FROM Cliente WHERE RaznSocial LIKE "_O%"
22. Los clientes cuyo cdigo empiece con F o G
SELECT IDCliente,RazonSocial
FROM Cliente
WHERE IDCliente LIKE "[FG]%"
23. Una lista de precios de artculos ordenados de menor a mayor
SELECT DISTINCT PrecioUnidad
FROM Articulo
ORDER BY PrecioUnidad ASC

24. Una relacin de Cajeros ordenados Alfabticamente


SELECT ApPatCajero,NombreCajero
FROM Cajero
ORDER BY ApPatCajero,NombreCajero ASC
25. Cul es el precio de artculo mas caro?
SELECT MAX(PrecioUnidad)
FROM Artculo
26. Calcular el monto del total del inventario en stock
SELECT SUM(UnidExistencia*PrecioUnidad)
FROM Articulo
27. Cuntos cajeros tenemos)
SELECT Count(IdCajero)
FROM Cajero
28. Cuntos clientes no tienen FAX?
SELECT Count(IDCliente)
FROM Cliente
WHERE Fax IS NULL
29. Cuntos pedidos se emitieron en Abril de 1998?
SELECT Count(IDDocuVenta)
FROM DocVenta
WHERE DATEPART(mm,Fecha)=4
30. Relacin de N de documentos de venta y los respectivos cdigos de
artculos por cada documento.
SELECT DocVenta.IDDocuventa, Detalles.IDArticulo
FROM DocVenta INNER JOIN Detalles
ON DocVenta.IDDocuventa = Detalles.IDDocuVenta
31. Una relacin de los cajeros con el nmero de pedido atendido en orden
alfabtico y ascendente.
SELECT Cajero.ApPatCajero,Cajero.NombreCajero, DocVenta.IDDocuventa
FROM DocVenta INNER JOIN Cajero
ON DocVenta.IDCajero = Cajero.IDCajero
ORDER BY Cajero.ApPatCajero, Cajero.NombreCajero ASC,
DocVenta.IDDocuventa ASC

32. Una relacin de los clientes con su respectivo nmero de documento de


venta y fecha de pedido.
SELECT Cliente.RazonSocial, DocVenta.IDDocuventa, DocVenta.Fecha
FROM DocVenta INNER JOIN Cliente
ON DocVenta.IDCliente = Cliente.IDCliente
ORDER BY Cliente.RazonSocial
33. Relacin de Documentos de Venta, con sus respectivos artculos, cantidad
y costo unitario.
SELECT DocVenta.IDDocuventa, Articulo.NombreArticulo, Detalles.Cantidad,
Articulo.PrecioUnidad
FROM DocVenta INNER JOIN Detalles
ON DocVenta.IDDocuventa = Detalles.IDDocuVenta INNER JOIN Articulo
ON Detalles.IDArticulo = Articulo.IDArticulo
34. Cuntos pedidos se surtieron por fecha?
SELECT Fecha, COUNT(IDDocuventa) AS [Cantidad de Pedidos]
FROM DocVenta
GROUP BY Fecha
ORDER BY Fecha
35. Cuntos artculos se venden por cada tipo de unidad?
SELECT Unidad.Descripcion, COUNT(Articulo.IDArticulo) AS Cantidad
FROM Articulo INNER JOINUnidad
ON Articulo.IDUnidad = Unidad.IDUnidad
GROUP BY Unidad.Descripcion
36. Listado de artculos y su cantidad vendida. La cantidad debe ser mayor de
500.
SELECT Articulo.NombreArticulo,SUM(Detalles.Cantidad) AS Cantidad
FROM Articulo INNER JOIN Detalles
ON Articulo.IDArticulo = Detalles.IDArticulo
GROUP BY Articulo.NombreArticulo
HAVING (SUM(Detalles.Cantidad) > 500)
37. Una relacin de los artculos con su cantidad monetaria vendida.
SELECT Articulo.NombreArticulo,
SUM(Detalles.Cantidad * Articulo.PrecioUnidad)AS [Total Vendido]

FROM Articulo INNER JOIN Detalles


ON Articulo.IDArticulo = Detalles.IDArticulo
GROUP BY Articulo.NombreArticulo
38. Por cunto dinero compr cada cliente cada da, entre junio y octubre de
1997?
SELECT Cliente.RazonSocial, SUM(Detalles.Cantidad *
Articulo.PrecioUnidad)AS [Monto de Compra], DocVenta.Fecha
FROM DocVenta INNER JOIN Detalles
ON DocVenta.IDDocuventa = Detalles.IDDocuVenta INNER JOIN Articulo
ON Detalles.IDArticulo = Articulo.IDArticulo INNER JOIN Cliente
ON DocVenta.IDCliente = Cliente.IDC liente
GROUP BY Cliente.RazonSocial, DocVenta.Fecha
HAVING (DocVenta.Fecha BETWEEN '1997-01-06' AND '1997-10-31')
ORDER BY RazonSocial,Fecha
39. Genere una vista denominada ArticulosCaros, que visualice los artculos
cuyo costo es mayor de 50 soles.
CREATE VIEW ArtculosCaros AS
SELECT NombreArticulo, UnidExistencia, PrecioUnidad
FROM Artculo
WHERE (PrecioUnidad > 50)
40. Genere una vista que muestre la cantidad de pedidos atendida por cada
cajero por fechas.
CREATE VIEW CajerosVentas AS
SELECT Cajero.ApPatCajero,
Cajero.NombreCajero,COUNT(DocVenta.IDDocuventa) AS [Cantidad de
Ventas]
FROM Cajero INNER JOIN DocVenta
ON Cajero.IDCajero = DocVenta.IDCajero
GROUP BY Cajero.ApPatCajero, Cajero.NombreCajero
41. Ingrese al administrador corporativo. Ingrese a los objetos vistas. Visualice
e interprete grficamente las vistas creadas.
42. Genere grficamente una vista denominada ComprasClientes, donde se
muestre el nombre de cada cliente, seguido por la cantidad total en soles de
todas sus compras.

COPIAS DE SEGURIDAD (BAKUPS) Y RESTAURACIN DE BASES DE


DATOS
El componente para la realizacin de copias de seguridad y restauracin de
Microsoft
SQL Server proporciona una importante proteccin para los datos decisivos
almacenados en bases de datos de SQL Server. La realizacin de copias de
seguridad y la restauracin de las bases de datos permite la restauracin total
de los datos en una amplia gama de problemas posibles en el sistema:

Errores de medios. Si se produce un error en una o ms de las unidades


de disco que contienen una base de datos, se enfrenta a la prdida total
de los datos a menosque pueda restaurar una copia anterior de los
mismos.

Errores de usuarios. Si un usuario o una aplicacin, ya sea por


equivocacin

ointencionadamente,

realiza

un

gran

nmero

de

modificaciones no vlidas en losdatos, la mejor manera de solucionar el


problema puede ser la restauracin de losmismos con los de un
momento dado anterior a aquel en que se realizaron lasmodificaciones.

Prdida permanente de servidores. Si un servidor se deshabilita de


manerapermanente o se pierde un sitio debido a una catstrofe natural,
es posible que debaactivar un servidor de reserva activo o restaurar una
copia de una base de datos enotro servidor.

Adems, la realizacin de copias de seguridad y la restauracin de bases de


datos resulta til para resolver problemas que no son del sistema, como mover
o copiar una base de datos de un servidor a otro. Puede hacerse una copia de
una base de datos rpida y fcilmente mediante la realizacin de una copia de
seguridad de la base de datos de un equipo y su restauracin en otro.

Realizar una copia de seguridad de una base de datos

La copia de seguridad de una base de datos consiste en una copia que se


puede utilizar para restaurar la base de datos si se pierde. Al realizar una copia
de seguridad de una base de datos, se copia todo el contenido de la base de
datos, incluidas las partes necesarias del registro de transacciones.
El registro de transacciones es un registro de serie que mantiene todas las
modificaciones realizadas en una base de datos y la transaccin que ha
realizado cada modificacin. El registro de transacciones se utiliza durante las
operaciones de recuperacin para rehacer transacciones completadas y
deshacer transacciones no completadas.
Al realizar una copia de seguridad de un registro de transacciones, se copian
slo los cambios producidos en el registro desde que se realiz la ltima copia
de seguridad.

La copia de seguridad funciona como una instantnea aproximada de una base


de datos o un registro de transacciones: La copia de seguridad de una base de
datos registra el estado completo de la informacin de sta en el momento en
el que se completa la operacin de copia de seguridad. La copia de seguridad
de un registro de transacciones registra el estado del registro en el momento en
el que se inicia la operacin de copia de seguridad.
Si crea copias de seguridad de una base de datos, pero sin copias de
seguridad independientes del registro de transacciones, el nico procedimiento
de recuperacin necesario es restaurar la ltima copia de seguridad de la base
de datos. Esta operacin crea de nuevo la base de datos tal como estaba
cuando se complet la operacin de copia de seguridad. No obstante, no hay
manera alguna de recuperar las modificaciones realizadas en la base de datos
despus de comp letarse la ltima copia de seguridad de la base de datos.
Algunas de las caractersticas de un sistema para el que podra considerar slo
el uso de copias de seguridad de las bases de datos son:

La importancia de los datos es tan pequea como para que pueda


aceptarse laprdida de las modificaciones realizadas despus de la

ltima copia deseguridad, ya que resulta ms eficaz sobrellevar la


prdida y, posiblemente,volver a crear manualmente los datos que
utilizar copias de seguridad delregistro de transacciones. Por ejemplo,
en una base de datos de prueba utilizadaen el desarrollo de una
aplicacin de bases de datos se puede tolerar la prdidade datos, ya
que los datos no son fundamentales y se pueden volver a
crearfcilmente.

Puede volver a crear los datos, por ejemplo, a partir de cargas por lotes
quetienen lugar por la noche y reemplazar el contenido de la mayor
parte de labase de datos.

Necesita implementar procedimientos de mantenimiento sencillos,


porejemplo, porque no dispone de un administrador de bases de datos.
Losprocedimientos de mantenimiento se pueden simplificar todava ms
con elAsistente para planes de mantenimiento de bases de datos.

Los cambios en la base de datos no son frecuentes, como en una base


de datosde slo lectura.Al realizar una copia de seguridad de una base
de datos, se copia toda la informacinde la base de datos,
independientemente de si se realizaron cambios despus de laltima
copia de seguridad. Esto significa que la copia de seguridad de la base
de datoses totalmente independiente y no necesita otros medios de
copia de seguridad para surestauracin. Tambin significa que la copia
de

seguridad

de

la

base

de

datos

utilizarms

espacio

de

almacenamiento por cada copia de seguridad y, por tanto, la


operacinde copia de seguridad tardar ms tiempo en completarse, en
comparacin con el usode copias de seguridad diferenciales de la base
de

datos

registros

de

transacciones.

Copias de seguridad de registros de transacciones

Al crear copias de seguridad de las bases de datos y de los registros de


transacciones, es posible restaurar una base de datos hasta el momento
exacto del error y minimizar, o eliminar totalmente, la prdida de datos debido
al error.
Algunas de las caractersticas de un sistema para el que podra considerar el
uso de copias de seguridad de los registros de transacciones son:

No se puede aceptar la prdida de los cambios realizados despus de la


ltimacopia de seguridad de la base de datos como, por ejemplo, en un
sistema debases de datos de comercio financiero de OLTP. No se
puede aceptar laprdida de transacciones.

Los recursos necesarios para realizar slo copias de seguridad de la


base dedatos son limitados: puede faltar espacio de almacenamiento
para las copias deseguridad o se dispone de poco tiempo para realizar
la operacin de copia deseguridad. Por ejemplo, para una base de datos
de 10 terabytes se necesitarauna gran cantidad de espacio en disco y
de tiempo para realizar peridicamentecopias de seguridad completas.

Resulta conveniente poder devolver la base de datos a un momento


anterior acuando se produjo un error. Por ejemplo, desea devolver la
base de datos a 10minutos antes de producirse el error en lugar de
recuperar todo o nada.

Los cambios en la base de datos son frecuentes. Una gran cantidad de


cambiosen la base de datos se producen en un periodo relativamente
pequeo, lo quecausa que la ltima copia de seguridad de la base de
datos se quede anticuadarpidamente. La realizacin de copias de
seguridad frecuentes de toda la basede datos debido a estos cambios
rpidos

puede

anteriormente.

no

ser

posible

por

los

motivosmencionados

Restaurar una base de datos

La restauracin de una copia de seguridad de una base de datos devuelve la


base de datos al mismo estado en el que se encontraba cuando se cre la
copia. Las transacciones incompletas de la copia de seguridad de la base de
datos (transacciones que no estaban completas cuando finaliz la operacin de
copia de seguridad) se deshacen para asegurar la coherencia de la base de
datos.
La restauracin de una copia de seguridad de un registro de transacciones
vuelve a aplicar todas las transacciones completadas del registro a la base de
datos. Cuando se aplica una copia de seguridad de un registro de
transacciones, SQL Server va leyendo el registro de transacciones y rehace
cada una de las transacciones del registro. Cuando
SQL Server llega al final del registro de transacciones, ha creado de nuevo el
estado exacto de la base de datos en el momento en el que se inici la
operacin de copia de seguridad. La operacin de restauracin deshace todas
las transacciones que estaban incompletas cuando se inici la operacin de
copia de seguridad.
Al realizar una copia de seguridad de una base de datos, no se realiza una
copia de seguridad de los datos de ndices de texto de los catlogos de texto.
No obstante, si se han definido ndices de texto para tablas, los metadatos de
las definiciones de los ndices de texto se almacenan en las tablas del sistema,
en la base de datos que contiene los ndices de texto. Por tanto, se realiza una
copia de seguridad de losmetadatos de los ndices de texto cuando se crea una
copia deseguridad de la base de datos. Una vez restaurada una copia de
seguridad de la base de datos, se pueden volver a crear y llenar los catlogos
de ndices de texto.

Medios de copia de seguridad

El medio de copia de seguridad es el almacn fsico real que utiliza el


dispositivo de copia de seguridad para almacenar las copias de seguridad de
bases de datos, registros de transacciones o archivos. Los medios de copia de
seguridad pueden ser discos o cintas.
Por ejemplo, un dispositivo de copia de seguridad puede ser el archivo
C:\Backups\Accounting\Full.bak, mientras que el medio de copia de seguridad
es el disco que contiene el archivo. De igual manera, un dispositivo de copia de
seguridad puede ser el dispositivo de cinta \\.\TAPE0 en el equipo local,
mientras que los medios de copia de seguridad son las cintas fsicas utilizadas
para almacenar la copia de seguridad.
Al crear una copia de seguridad, Microsoft SQL Server puede realizar una
de las siguientes acciones:

Utilizar el medio (disco o cinta) que usa el dispositivo de copia de


seguridadpor primera vez.

Anexar la copia de seguridad al final de una copia de seguridad


existente en elmedio.

Sobrescribir

copias

de

seguridad

existentes

en

un

medio

utilizadoanteriormente.

Utilizar copias de seguridad de archivos o grupos de archivos

Se puede realizar copias de seguridad y restauraciones individuales de


archivos o grupos de archivos, o de combinaciones de archivos y grupos de
archivos de una base de datos. Tambin es posible restaurar archivos y grupos
de archivos desde copias de seguridad de bases de datos para permitir la
recuperacin a partir de un error de los medios que slo afecte a un
subconjunto de los archivos de una base de datos.
Normalmente, se crea una copia de seguridad de un archivo o un grupo de
archivosslo si no hay tiempo suficiente para crear un copia de seguridad de la
base de datoscompleta. Por ejemplo, si la copia de seguridad de una base de
datos tarda tres horas en crearse, pero slo hay disponibles dos horas por

noche para crear copias de seguridad, se puede realizar la copia de seguridad


de la mitad de los archivos una noche y de la otra mitad la noche siguiente.
La utilizacin de copias de seguridad de un archivo o de un grupo de archivos
puede aumentar la velocidad de recuperacin al restaurar solamente los
archivos o grupos de archivos daados. Si las partes de una base de datos que
se necesita restaurar estn completamente contenidas en un subconjunto de
los archivos o grupos de archivos de la base de datos, slo se necesita
restaurar dichos archivos o grupos de archivos. Esto se utiliza principalmente
para grandes bases de datos en entornos en que el tiempo es un factor muy
importante.

LABORATORIO: COPIAS DE SEGURIDAD (BAKUPS) Y RESTAURACIN


DE
BASES DE DATOS

1. Iniciar el analizador de consultas. Crear un dispositivo de copia de seguridad


para la base de datos Supermercado, en la carpeta backup por defecto:
sp_addumpdevice 'disk' ,'Supermercado_backup',
'\\BACKUP\Supermercado.bak'
2. Realice una copia de seguridad completa de la base de datos
Supermercado, inicializando el dispositivo:
BACKUP DATABASE Supermercado to Supermercado_backup WITH INIT
3. Cul es la utilidad de del parmetro INIT / NOINIT?
4. Recuerde el concepto de Copia de seguridad diferencial:
NOTA: Para poder apreciar la aplicacin de las bases de datos diferenciales,
es necesario que la base de datos en cuestin cambie de una copia diferencial
a otra. Para el ejemplo, deber insertar un nuevo registro en la tabla Unidad,
cada vez antes de iniciar una copia de seguridad diferencial.
5. Realice la primera copia de seguridad diferencial de la base de datos
Supermercado, en el dispositivo Supermercado_backup:
BACKUP DATABASE Supermercado to Supermercado_backup WITH
differential, NOINIT
6. Desde el administrador corporativo ingrese un nuevo registro para la tabla
UNIDAD.

7. Realice la segunda copia de seguridad diferencial:


BACKUP DATABASE Supermercado to Supermercado_backup WITH
differential, NOINIT
8. Ingrese un ltimo registro a la tabla UNIDAD. Realice una tercera copia de
seguridad difrencial.
9. Genere un segundo dispositivo para realizar la copia de seguridad del
registro de transacciones:
sp_addumpdevice 'disk' ,'Supermercado_log',
'\\BACKUP\SupermercadoLog.bak'
10. Realice la copia de seguridad del registro de transacciones:
BACKUP DATABASE Supermercado TO Supermercado_log WITH INIT
BACKUP LOG Supermercado TO Supermercado_log WITH NOINIT
11. Ingrese al administrador corporativo. Compruebe la existencia del
dispositivo de copia de seguridad creado, as como su respectivo contenido.
12. Ingrese a la opcin Restaurar base de datos..., en la base de datos
Supermercado.
Observe la secuencia de backups realizada.
13. Desde el administrador corporativo, genere dos dispositivos para copia de
seguridad de las bases de datos Northwind y Pubs, en la carpeta de backups
por defecto. (Siga las indicaciones del instructor). Genere copias de seguridad
completas de ambas bases de datos. (Siga las indicaciones del instructor).
14. Verifique la base de datos y archivo de transacciones que se respaldaron
en el dispositivo de copia de seguridad Supermercado_backup:
RESTORE FILELISTONLY FROM Supermercado_backup
RESTORE VERIFYONLY FROM Supermercado_backup
15. Desde el analizador de consultas seleccione la base de datos master.
16. Establezca la propiedad Usuario nico para la base de datos
Supermercado.
17. Cierre el analizador de consultas y vulvalo a abrir para actualizar las
propiedades establecidas.
18. Restaure la versin original de la base de datos Supermercado
RESTORE DATABASE Supermercado FROM Supermercado_backup WITH
RECOVERY

19. Desde el analizador de consultas, compruebe el contenido de la tabla


Unidad. Por qu es necesaria la clusula RECOVERY?
20. Por qu figura sin registros la tabla en cuestin?
21. Restaure la primera copia de seguridad diferencial: (Recuerde que es
necesario restaurar primero la base de datos original con NORECOVERY)
RESTORE DATABASE Supermercado FROM Supermercado_backup WITH
NORECOVERY
RESTORE DATABASE Supermercado FROM Supermercado_backup WITH
FILE=2,RECOVERY
22. Verifique el contenido de la tabla Unidad.
23. Restaure la segunda copia de seguridad diferencial
24. Verifique el contenido de la tabla Unidad.
25. Restaure la tercera copia de seguridad diferencial
26. Verifique el contenido de la tabla Unidad.
27. Restaure la base de datos completa y el registro de transacciones:
RESTORE DATABASE Supermercado FROM Supermercado_LOG WITH
NORECOVERY
RESTORE LOG Supermercado FROM Supermercado_LOG WITH
RECOVERY
28. Verifique el contenido de la tabla Unidad.

PROGRAMACIN EN SQL PROCEDIMIENTOS ALMACENADOS Y


DESENCADENADORES (TRIGGERS)
Procedimientos almacenados
Cuando crea una aplicacin con Microsoft SQL Server el lenguaje de
programacin Transact-SQL es la principal interfaz de programacin entre sus
aplicaciones y la base de datos de SQL Server. Cuando utilice programas
Transact-SQL, dispone de dos mtodos para almacenar y ejecutar los
programas. Puede almacenar localmente los programas y crear aplicaciones

que enven los comandos a SQL Server y procesen los resultados, o bien
almacenar los programas como procedimientos almacenados en
SQL Server y crear aplicaciones que ejecuten los procedimientos almacenados
y procesen los resultados.
Los procedimientos almacenados de SQL Server son similares a los
procedimientos de otros lenguajes de programacin en el sentido de que
pueden:

Aceptar parmetros de entrada y devolver varios valores en forma de


parmetros de salida al lote o al procedimiento que realiza la llamada.

Contener instrucciones de programacin que realicen operaciones en la


base dedatos, incluidas las llamadas a otros procedimientos.

Devolver un valor de estado a un lote o a un procedimiento que realiza


unllamada para indicar si la operacin se ha realizado correctamente o
habido unerror (y el motivo del mismo).

Puede utilizar la instruccin EXECUTE de Transact-SQL para ejecutar


unprocedimiento almacenado. Los procedimientos almacenados difieren
de las funcionesen que no devuelven valores en lugar de sus nombres ni
pueden ser directamenteutilizados en una expresin. Las ventajas de
utilizar procedimientos almacenados enSQL

Server en

vez de

programas Transact-SQL almacenados localmente en equiposclientes


consisten en que:
Permiten una programacin modular.
Puede crear el procedimiento una vez, almacenarlo en la base de datos, y
llamarlodesde el programa el nmero de veces que desee. Un especialista en
programacin de bases de datos puede crear procedimientos almacenados,
que luego ser posible modificar independientemente del cdigo fuente del
programa.
Permiten una ejecucin ms rpida.
En situaciones en las que se necesita una gran cantidad de cdigo TransactSQL, o si las operaciones se realizan varias veces, los procedimientos
almacenados pueden ser ms rpidos que los lotes de cdigo Transact-SQL.
Los procedimientos son analizados y optimizados en el momento de su
creacin, y es posible utilizar una versin del procedimiento que se encuentra
en la memoria despus de que se ejecute por primera vez. Las instrucciones

de Transact-SQL que se envan varias veces desde el cliente cada vez que
deben ejecutarse tienen que ser compiladas y optimizadas siempre que
SQL Server las ejecuta.
Pueden reducir el trfico de red.
Una operacin que necesite centenares de lneas de cdigo Transact-SQL
puede realizarse mediante una sola instruccin que ejecute el cdigo en un
procedimiento, en vez de enviar cientos de lneas de cdigo por la red.
Pueden utilizarse como mecanismo de seguridad.
Es posible conceder permisos a los usuarios para ejecutar un procedimiento
almacenado, incluso si no cuentan con permiso para ejecutar directamente las
instrucciones del procedimiento.
Para crear un procedimiento almacenado de SQL Server se utiliza la
instruccin
CREATE PROCEDURE de Transact-SQL; asimismo, puede utilizarse la
instruccin ALTER PROCEDURE para modificar la instruccin.
La definicin del procedimiento almacenado contiene dos componentes
principales: la especificacin del nombre del procedimiento y sus parmetros, y
el cuerpo del procedimiento que contiene las instrucciones de Transact-SQL
que pueden realizar las operaciones del procedimiento.

Uso de parmetros en procedimientos almacenados.


Cada parmetro de un procedimiento almacenado debe definirse con un
nombre nico.
Los nombres de los procedimientos deben empezar por un solo carcter @,
como una variable normal de Transact-SQL, y deben seguir las reglas definidas
para los identificadores de objetos. El nombre del parmetro se puede utilizar
en el procedimiento para obtener y cambiar el valor del parmetro.
Es posible pasar valores a los procedimientos almacenados de dos maneras:
denominando explcitamente los parmetros y asignando el valor apropiado, o
bien suministrando los valores del parmetro especificados en la instruccin
CREATE PROCEDURE sin denominarlos. Por ejemplo, si el procedimiento

almacenado my_proc espera tres parmetros denominados @first, @second y


@third, los valores pasados al procedimiento almacenado pueden ser
asignados a los nombres de los parmetros; por ejemplo:
EXECUTE my_proc @second = 2, @first = 1, @third = 3 o por posicin, sin
denominarlos:
EXECUTE my_proc 1, 2, 3
Especificar un tipo de datos
Los parmetros de un procedimiento almacenado se definen con un tipo de
datos. Es posible definir un parmetro de un procedimiento almacenado con
cualquiera de los tipos de datos de Microsoft SQL Server incluidos text e
image. Tambin se puede definir los parmetros de los procedimientos
almacenados con tipos de datos definidos por el usuario.El tipo de datos de un
parmetro determina el tipo y el intervalo de valores que se aceptarn para el
mismo. Por ejemplo, si define un parmetro con un tipo de datos tinyint, slo se
aceptarn valores numricos del intervalo comprendido entre 0 y 255. Se
devolver un error si se ejecuta un procedimiento con un valor incompatible con
el tipo de datos.

Especificar la direccin del parmetro

Todos los parmetros de un procedimiento pueden recibir valores de entrada


cuando el procedimiento almacenado es ejecutado por un programa que lo
llama.
Ejemplos
El

siguiente

procedimiento

almacenado,

get_sales_for_title,

utiliza

un

parmetro de entrada. El parmetro @title del procedimiento recibe como


entrada el ttulo de unlibro especificado por el programa que realiza la llamada.
La instruccin SELECT utiliza el parmetro @title para obtener el valor correcto
de ytd_sales y muestra el valor.
CREATE PROCEDURE get_sales_for_title
@title varchar(80) -- This is the input parameter.
AS

-- Get the sales for the specified title.


SELECT "YTD_SALES" = ytd_sales
FROM titles
WHERE title = @title
RETURN
GO
Si especifica la palabra clave OUTPUT para un parmetro en la definicin del
procedimiento almacenado, ste podr devolver el valor actual del parmetro al
programa que lo llama cuando salga. El programa que realiza la llamada
tambin debe utilizar la palabra clave OUTPUT cuando ejecute el
procedimiento para guardar el valor del parmetro en una variable que puede
utilizarse en el programa que realiza llamada.
Especificar un valor predeterminado
Puede crear un procedimiento almacenado con parmetros opcionales
mediante la especificacin de un valor predeterminado para los mismos.
Cuando se ejecuta el procedimiento almacenado, se utiliza el valor
predeterminado si no se ha especificado otro valor.
La especificacin de valores predeterminados es necesaria dado que se
devuelve un error del sistema si, en el procedimiento almacenado, no se
especifica un valor predeterminado para un parmetro y el programa que
realiza la llamada no especifica ningn valor para el parmetro al ejecutar el
procedimiento almacenado.
Si no se puede especificar ningn valor como predeterminado para el
parmetro, puede especificar NULL como valor predeterminado y que el
procedimiento almacenado devuelva un mensaje personalizado si se ejecuta
sin que haya ningn valor para el parmetro.
Nota Si el valor predeterminado es un carcter que contiene signos de
puntuacin o espacios en blanco incrustados, o si empieza por un nmero (por
ejemplo, 6xxx), debe estar delimitado por comillas simples y rectas.
Ejemplos
En el ejemplo siguiente se muestra el procedimiento get_sales_for_title con un
tratamiento especial para los casos en los que el procedimiento almacenado se
ejecuta sin que haya ningn valor para el parmetro @title.
CREATE PROCEDURE get_sales_for_title

@title varchar(80) = NULL, -- NULL default value


@ytd_sales int OUTPUT
AS
-- Validate the @title parameter.
IF @title IS NULL
BEGIN
PRINT 'ERROR: You must specify a title value.'
RETURN
END
-- Get the sales for the specified title and
-- assign it to the output parameter.
SELECT @ytd_sales = ytd_sales
FROM titles
WHERE title = @title
RETURN
GO
En el ejemplo siguiente se muestra el procedimiento my_proc con valores
predeterminados para los tres parmetros: @first, @second y @third, as como
los valores que se muestran cuando se ejecuta el procedimiento almacenado
con otros valores para los parmetros:
CREATE PROCEDURE my_proc
@first int = NULL, -- NULL default value
@second int = 2, -- Default value of 2
@third int = 3 -- Default value of 3
AS
-- Display values
SELECT @first, @second, @third
GO
EXECUTE my_proc -- No parameters supplied
GO
Muestra:
NULL 2 3
EXECUTE my_proc 10, 20, 30 -- All parameters supplied

GO
Muestra:
10 20 30
EXECUTE my_proc @second = 500 -- Only second parameter supplied by
name
GO
Muestra:
NULL 500 3
EXECUTE my_proc 40, @third = 50 -- Only first and third parameter
GO -- supplied
Muestra:
40 2 50
Exigir reglas de empresa con desencadenadores
Un desencadenador es un procedimiento almacenado de tipo especial que se
invoca automticamente cada vez que se modifican los datos de la tabla. Los
desencadenadores se invocan en respuesta a las instrucciones INSERT,
UPDATE o
DELETE. Un desencadenador puede realizar una consulta en otras tablas e
incluirinstrucciones de Transact-SQL complejas. El desencadenador y la
instruccin que lo activa se tratan como una sola transaccin que puede
deshacerse desde el desencadenador. Si se detecta un error grave, se
deshace automticamente toda la transaccin.
Los desencadenadores tienen varias utilidades:
Pueden realizar cambios en cascada a travs de tablas relacionadas de la base
de datos.
Por ejemplo, un desencadenador de eliminacin en la columna title_id (IdTtulo)
de la tabla titles (ttulos) provoca la eliminacin de las filas coincidentes de
otras tablas; y se utiliza la columna title_id como clave nica para localizar las
filas en titleauthor
(ttuloAutor), sales (ventas) y roysched (progRoy).

Los desencadenadores pueden no permitir o deshacer los cambios que


infrinjan la integridad referencial y cancelar, de ese modo, cualquier intento de
modificacin de los datos.
Ese tipo de desencadenador puede actuar cuando se cambia una clave externa
y el nuevo valor no coincide con su clave principal. Por ejemplo, puede crear un
desencadenador de insercin en titleauthor.title_id que deshaga la insercin si
el nuevo valor no coincide con ningn valor de titles.title_id. (No obstante, para
estos casos suelen utilizarse las restricciones de clave externa).
Los desencadenadores pueden exigir restricciones ms complejas que las
restricciones CHECK.
A diferencia de las restricciones CHECK, los desencadenadores pueden hacer
referencia a columnas de otras tablas. Por ejemplo, un desencadenador puede
utilizar una instruccin SELECT de otra tabla para deshacer las actualizaciones
que intenten aumentar el precio de un libro en ms de un 1% respecto a su
adelanto.
Los desencadenadores tambin pueden diferenciar entre el estado de una
tabla antes ydespus de una modificacin de datos para actuar en funcin de
esa diferencia.
Varios desencadenadores del mismo tipo (INSERT, UPDATE o DELETE) en
una tabla permiten que se realicen distintas acciones en respuesta a una
misma instruccin de modificacin.
LABORATORIO: PROGRAMACIN EN SQL PROCEDIMIENTOS
ALMACENADOS Y DESENCADENADORES (TRIGGERS)

1. Recuerde el concepto de identificador en Transact-SQL

Interprete el cdigo de los siguientes ejemplos:

2.
DECLARE @Precio int
SET @Precio=100
PRINT @Precio
3.
DECLARE @maxprecio numeric(9,2)
SELECT @maxprecio=Max(PrecioUnidad)

FROM Articulo
PRINT 'El mximo precio en la tabla artculo es: ' +
Convert(varchar,@maxprecio) + ' soles.'
4.
SELECT * FROM Unidad
PRINT 'Esta operacin genera: ' + Convert(varchar,@@rowcount) + ' filas...'
5.
DECLARE @MinUnidades int
SELECT @MinUnidades=Min(UnidExistencia)
FROM Articulo
IF @MinUnidades<5
PRINT 'Existen artculos con menos de 5 unidades en stock...'
ELSE
PRINT 'El stock todava es suficiente'
6.
SELECT NombreArticulo,
CASE
WHEN PrecioUnidad <10 THEN "Barato"
WHEN PrecioUnidad <50 THEN "Asequible"
WHEN PrecioUnidad >=50 THEN "Caro"
END AS Calificativo
FROM Articulo
7.
DECLARE @Contador Int
SET @Contador=1
WHILE (@Contador<=10)
BEGIN
PRINT @Contador
SET @Contador=@Contador+1
END

Procedimiento almacenado que no recibe ni devuelve parmetros:

7. Procedimiento que imprime una relacin de nombres de cajeros y su


respectiva direccin, ordenados alfabticamente:

CREATE PROCEDURE Cajeros


AS
SELECT ApPatCajero, NombreCajero, Direccion
FROM Cajero
ORDER BY ApPatCajero, NombreCajero ASC

Procedimiento almacenado que recibe parmetros:

8. Procedimiento que recibe como parmetro el cdigo de un artculo, y


devuelve su nombre
y precio unitario.
CREATE PROCEDURE DatosArticulo
@CodigoArt int
AS
DECLARE @Nombre Varchar(50)
DECLARE @Precio Decimal
SELECT @Nombre=NombreArticulo FROM Articulo WHERE
IDArticulo=@CodigoArt

SELECT @Precio=PrecioUnidad FROM Articulo WHERE


IDArticulo=@CodigoArt
PRINT 'El Artculo: ' + @Nombre + ' cuesta: S/.' +
CONVERT(Varchar,@Precio)

Procedimiento almacenado que recibe y devuelve parmetros:

9. Procedimiento almacenado que recibe como parmetro el cdigo de una


cajero, y devuelve en otro parmetro la cantidad de pedidos atendidos por
dicho cajero.
CREATE PROCEDURE PedidosCajeros
@CodCajero int,
@NroPedidos int OUTPUT
AS
SELECT @NroPedidos=Count(*)
FROM DocVenta

WHERE IDCajero=@CodCajero
10. Comprube el procedimiento con el siguiente cdigo:
DECLARE @Cantidad int
EXEC PedidosCajeros 7,@Cantidad OUTPUT
PRINT 'Atendi ' + Convert(Varchar,@Cantidad) + ' pedidos.'
11. Desde el administrador corporativo, revise los procedimientos almacenados
implementados.
12. Disparador que alerte si se ha agregado algn registro en la tabla Cliente:
CREATE TRIGGER SeAgregoCliente
ON Cliente
FOR INSERT
AS
IF UPDATE(IDCliente)
PRINT 'Se agreg un nuevo cliente... Trigger disparado'
13. Pruebe el disparador con la siguiente instruccin:
INSERT INTO Cliente (IDCliente, RazonSocial, ApPatContacto,
ApMatContacto, NombreContacto)
VALUES
('JPF','Restaurente El Remanso','Parker','Ferrer','Jos')
14. Crear un disparador que no permita ingresar un Artculo con precio
negativo:
CREATE TRIGGER VerificaPrecio
ON Articulo
FOR INSERT
AS
IF (SELECT PrecioUnidad FROM Inserted)<0
BEGIN
PRINT 'No se permite precios negativos... Tigger Disparado...'
ROLLBACK
END
15. Pruebe el disparador con la siguiente instruccin:
INSERT INTO
Articulo(IDArticulo,NombreArticulo,UnidExistencia,PrecioUnidad,UnidMinimo

)
VALUES(114,'Spaguetti',50,-5,10)
16. Crear un disparador que no permita modificar las Descripciones
almacenadas en la tabla unidad.
CREATE TRIGGER NoCambiosUnidad
ON Unidad
FOR UPDATE
AS
IF UPDATE(Descripcion)
BEGIN
PRINT 'No se deben cambiar las descripciones... Trigger Disparado...'
ROLLBACK
END
17. Pruebe el disparador con la siguiente instruccin:
UPDATE Unidad
SET Descripcion='Carnes/Embutidos'
WHERE IDUnidad=6