Base de Datos Materia

Ing. Mariuxi Paola Zea Ordoñez - 1 -

Base de Datos

UNIDAD I. Fundamentos de Base de Datos

Reseña Histórica.

Antes, De la aparición de las Bases de Datos, cada aplicación era propietaria de ciertos ficheros de datos que

eran actualizados exclusivamente por ellos. Como mucho podían ser “prestados“ a otra aplicación, pero el

término propiedad era siempre muy rígido.

Al ampliarse las aplicaciones y desarrollarse otras nuevas muy ligadas a los mismos ficheros utilizados para

las aplicaciones antiguas y al implementarse sistemas operativos muy potentes que permitan la

multiprogramación, es decir, que en el mismo instante se podían ejecutar distintos programas que actúan con

los mismos ficheros, aumentaron netamente los problemas para la gestión de los tradicionales ficheros.

Por un lado las características exigidas al fichero variaban según la aplicación que lo utilizaba y por otro

lado, el poder ejecutar simultáneamente dos programas que actualizaran un mismo fichero, las operaciones

que ejecutaba uno, solían y podían ser incompatibles con los que necesitaba el otro.

La situación llegó a un punto insostenible dado que ninguna de las dos opciones a elegir resultaba

satisfactoria.

Si se optaba para satisfacer ficheros independientes para cada aplicación, resultaba que ciertos datos debían

estar repetidos en muchos ficheros, con lo que se utilizaba mucha mas memoria de almacenamiento de la

estrictamente necesaria y por otra parte, al tener copias del mismo datos en más de un fichero, suponía la

necesidad de efectuar múltiples actualizaciones cada vez que se quisiera modificar, con lo que dificultaba

mucho la labor de mantenimiento.

La otra situación era igualmente mala ya que si se unificaban todos los ficheros similares de las distintas

aplicaciones en un único fichero, se llegaba a conflictos irresolubles en cuanto a su utilización conjunta.

Ficheros Propiedad de

la Aplicación 1

(Entrada)

Ficheros Propiedad

de la Aplicación 1

(Salida)

Ficheros Propiedad

de la Aplicación 2

(Entrada)

Aplicación 1

Aplicación 2


Ahora, Con la aparición de la Bases de Datos, los ficheros dejan de ser propiedad de las aplicaciones

pasando a ser compartidas por todos los usuarios.

Base de

Datos

Aplicación 1 Aplicación 2

En casi todos los sectores de actividad humana, cuando se llega a un punto no satisfactorio, se concentran los

esfuerzos de investigación hasta que el problema es obviado; en este caso, el resultado de esos esfuerzos fue

un producto altamente novedoso y que supuso un gran salto en la informática de gestión: los sistemas de

Bases de Datos.

Sistema de Base de Datos. Cuando en el principio de la década de los 60 se puso de moda el término de Base de Datos, muchos centros

de cálculos se limitaron a cambiar de nombres a sus archivos y en vez de seguir llamándolos ficheros,

comenzaron a llamarlos Bases de Datos. Evidentemente este cambio sólo de nombre no aportaba más

ventajas que una simple mejora de imagen.

Para que un fichero pueda dejar de denominarse como tal y pase a ser una Base de Datos, se deben verificar

algunas condiciones obligatoriamente. Estas condiciones son las que caracterizan totalmente a las Bases de

Datos y pueden ser consideradas como parte de su definición.

Definición de Base de Datos. Se llama Base de Datos a un conjunto de datos relacionados entre sí, que se encuentran almacenados en una

única colección, sin redundancias innecesarias y que cumplen las siguientes condiciones.

1. Los datos están almacenados en diversos soportes de información de tal forma que son

independiente de los programas que lo manejan.

2. Su utilización no está restringida a una única aplicación, siendo posible su acceso por varias

aplicaciones, incluso simultáneamente.

3. Para gestionar la información contenida en la Base de Datos, es decir, para incluir nuevos datos,

borrar ya existentes, o modificarlos, se emplean procedimientos especialmente diseñados para

optimizar el funcionamiento del sistema.

Estos procedimientos no sólo se encargan de la actualización, si no que también permiten la obtención de

datos para su utilización mediante programas.


Estas bases según su diseño, se reúnen para facilitar su manejo al realizarlo de forma integral, se dice que el

conjunto de todas las bases reunidas, es un Sistema de Base de Datos.

Colectivo Base

De de

Usuarios Datos

A 1

Colectivo Base

De de

Usuarios Datos

B 2

Mediante la unión de dos o más Bases de Datos se consigue formar un sistema de bases que permite a

distintos colectivos utilizar conjuntamente toda la información del sistema.

¿ Qué es una Base de Datos? El centro de cualquier sistema de gestión de información es una base de datos: un conjunto de información

relacionada agrupada como un todo. (gestión de base de datos), es un término informático, también es

aplicable al modo que la información se cataloga, almacena y utiliza manualmente.

Apellido Nombre Ciudad Provincia N. Cliente

Armijos María Quito 10 0001

Correa Aída Machala 04 0002

Son bases de datos: un archivador de metal que contienen los registros de los clientes, un archivador de

tarjetas con nombres y números de teléfono, una agenda que tenga escrito un inventario de almacén. Sin

embargo el archivador o la agenda no constituyen por si mismo una base de datos; la forma en que está

organizada la información da origen a la base de datos. Los archivadores y las agendas ayudan a organizar la

información; Fox Pro es otra ayuda.

La información contenida en una base de datos; está organizada y almacenada en tablas, por filas y

columnas. Por ejemplo: en la lista de direcciones a las que se envía información periódicamente, (en el

ejemplo) cada fila contiene el nombre, domicilio y el número de cliente. Cada fila se relaciona con las demás

ya que contiene el mismo tipo de información y dispuesta en un orden seleccionado, este ejemplo constituye

una tabla.

Apellido Nombre Ciudad Provincia N. Cliente

Armijos María Quito 10 0001

Correa Aída Machala 04 0002

Una base de datos está constituida por una o más tablas que contienen la información ordenada de una forma

organizada, como vimos en el ejemplo anterior.

Las filas de un archivo de base de datos se denominan registros, y las columnas campos.


Registros

Campos

Comparamos una base de datos con este ejemplo de tarjetas. Puesto que cada tarjeta del archivo tiene el

mismo tipo de información, el archivo de tarjeta constituye una base de datos.

Cada una de las tarjetas es un registro, y cada una de las informaciones contenidas en las tarjetas es un

campo. Los campos pueden contener cualquier tipo de información que pueda clasificarse en categoría.

Utilización de la Base de Datos. Probablemente una de las diferencias más importantes entre los ordenadores actuales y los de hace apenas

unas década de años, estaba en que los equipos modernos deben estar preparados para la utilización masiva

de los datos.

La importancia dada a la información, como recurso vital para la toma de decisiones, hacen que se queden

pequeñas las Bases de Datos.

En teoría, cualquier base de dato está ordenada de forma tal que la información pueda encontrarse fácilmente.

Ejemplo: Si quiere encontrar el número de teléfono de un cliente, simplemente debe localizar el nombre y

leer en ese registro el número de teléfono correspondiente.

Una base de datos manual puede ser difícil de modificar. Ejemplo: Añadir un nuevo número de teléfono a la

lista puede significar su ordenación. Si la compañía de teléfono asignara un nuevo código de zona, alguien

tendría que buscar todos los números de teléfonos que tiene el código de zona antigua y reemplazarlo con el

nuevo. Cuando una base de datos se encuentra asociada a una computadora, se eliminan muchos de estos

problemas:

* Una base de datos informatizada proporciona rapidez: encontrar un número de teléfono de entre

miles de entradas, u ordenar el archivo alfabéticamente, tarda pocos segundos.

* Una base de datos informática es compacta: una base de datos con miles de registros pueden

almacenarse en poco espacio.

Nombre:

Domicilio:

Ciudad:

Teléfono:

C.P.:

Estado:


* Una base de datos informatizada también es flexible: Tiene la posibilidad de examinar la

información desde varias puntos de vistas, de modo que, por ejemplo: podría buscar el nombre

por el teléfono o por el domicilio.

Las tareas que consumen gran cantidad de tiempo cuando se realizan manualmente son más prácticas con una

computadora.

En principio una base de dato de una computadora, no es diferente a una base de datos registrada en papel y

almacenadas en archivador.

Sin embargo la realidad es que la computadora hace el trabajo tedioso de mantener y acceder a la base de

datos, y además, mucho más rápido.

Una base de datos informatizada que pueda hacer todo esto se denomina Sistema de Gestión de Base de

Datos o de forma abreviada SGBD (en ingles Data Base Management System, DBMS).

Componentes de una Base de Datos.

Dentro de una base de datos podemos encontrar los siguientes objetos (que serán analizados más adelante):

Tablas.

Índices.

Vistas.

Diccionario de Datos.

Procedimientos

Usuarios

Importancia Central en este esquema del Diccionario de Datos. Una de las partes más importantes de la base de datos es el diccionario de datos. Que es un conjunto de

referencias acerca de la base de datos, esta información puede estar en tablas que sean usadas como sólo de

lectura. Por ejemplo:

El nombre de todos los usuarios.

Derechos y privilegios de ellos.

Nombre de los objetos de la b/d (tablas, vistas, índices, sinónimos, secuencias, y clusters).

Información sobre la primera y siguientes llaves.

Valores por omisión de las columnas.

Otra información general de la base de datos.

Información de auditoría, tal como quien ha accesado o actualizado varios objetos de la b/d.

Cuantos espacios ha utilizado, por quien es utilizado actualmente un objeto de base de datos.

El diccionario de datos es estructurados en tablas y vistas, al igual que cualquier base de datos. Para accesar

a él, se lo realiza igualmente con un lenguaje denominado SQL.

El diccionario de datos es creado cuando una base de datos es creada. Dentro de Oracle y la mayoría de

manejador de base de datos este diccionario es actualizado cuando la base de datos está en operación y en

respuesta a cada sentencia ejecutada.


A toda hora está disponible como referencia a cualquier usuario, halla o no realizado creado un objeto de

base de datos.

El diccionario de datos es un recurso de información para el usuario final, los diseñadores de aplicación. Es

también crítico para la operación de la base de datos, el cual verifica en el diccionario para grabar, verificar,

y conducir el trabajo.

Debido a que todo cambio en el diccionario es ejecutado por la base en sí, en respuestas a las sentencias,

ningún dato de ningún diccionario debe ser borrado o alterado por ningún usuario, entonces, se debe definir

estas tablas como sólo de lectura.

Cómo es utilizado el Diccionario de Datos dentro de una Base de Datos?

Los datos en las tablas base de los diccionarios de datos, no solamente son útiles para los usuarios y los

desarrolladores de aplicaciones para la base de datos; si no que también es necesario para el funcionamiento

de la base de datos. Además, sólo la base de datos debe escribir o cambiar la información del diccionario de

datos.

La Vista al Diccionario. Lista los objetos del diccionario de datos con una breve descripción, es decir que provee una lista de los

objetos que contiene. Por ejemplo: Si usted olvida el nombre de la tabla que quiere, en algunos manejadores

de base de datos puede comenzar con dictionary o alguna otra sentencia para poder ver la lista de objetos, y

por ende el nombre de la tabla que necesita.

En la columna COMMENTS en la Vista Dictionary; cuando los nuevos objetos son creados, los comentarios

son cargados automáticamente para cada vista y columna, proveyendo explicación documentada en línea de

estos objetos y columnas.

El Administrador de la Base de Datos (DBA, Data Base Administrator).

A la hora de diseñar una base de datos puede surgir varios problemas, pero al superarlos y cuando la base de

datos ya ha sido diseñada e implementada surgen otros problemas de los que vamos a tratar.

Aunque se trate de la base de datos particular de una empresa, es de suponer que van a ser varios los usuarios

de la misma que lo utilicen e incluso varias las aplicaciones por cada usuario.

Para controlar y coordinar la estructura de todos los datos, surge una nueva figura, el Administrador de

Datos. De alguna manera se puede afirmar que es un intermediario entre los datos de la base y los usuarios

que la utilizan.

Ejemplo gráfico:

Base

de

Datos

Administrador de la

Base Usuarios


Es importante destacar que el administrador (puede ser un grupo de personas aunque nos referimos a él en

singular) no es el propietario de los datos, estos pertenecen a los usuarios finales, si no el gestor que se

encarga de facilitar la utilización comunitaria de los mismos.

El DBA juega un papel muy importante en el éxito de una base de datos. Como el gerente primario de un

sistema de base de datos, el DBA es responsable de ver que el software y el Hardware conjuntamente con las

base de datos satisfagan la necesidad de los usuarios de la base de datos. De esta forma, las funciones

generales del DBA que deben incluir son:

Instalación y mantenimiento del software.

Diseño de la base de datos.

Seguridad de la base de datos.

Almacenamiento de los datos.

Disponibilidad de los datos.

Recuperación de datos.

El DBA debe tener buen entendimientos de la base de datos, por ej.: Quienes son los usuarios, cuales son los

datos que se almacenan y a cuales se accesan, y cuan a menudo, que tipos de transacciones están ocurriendo,

etc.

ESQUEMA 1: Tradicional.

Fichero A

Usuario A

Aplicación A

Fichero B

Usuario B

Aplicación B

Fichero C

Usuario C

Aplicación C

Fichero D

ESQUEMA 2: Base de Datos.

Aplicación A

Aplicación B

Base

De Administrador

Datos De Datos

C

e

n

t

r

o

d

e

C

á

l

c

u

l

o

C

e

n

t.

d

e

C

á

l

c


Aplicación C

Entonces podríamos definir que las funciones de administrado de datos son:

1. DEFINICION Y ORGANIZACION:

Las estructuras lógicas de los datos.

La estructura de los registros.

Relación entre los registros.

Criterios de búsqueda.

El almacenamiento físico.

Prever futuras necesidades.

Establecer prioridades de usuario y programas.

Generar esquemas y subesquemas correspondientes.

Cargar la base de datos.

2. DIMENSIONADO:

Asignar el tamaño de los registros.

Calcular el número y el tamaño de los pointer.

Calcular el volumen de los registros.

Calcular los niveles de actualización y de consulta.

Calcular los niveles de cancelaciones.

Calcular el requerimiento de tiempo de respuestas.

Calcular las posibles expansiones.

3. SUPERVISION Y CONTROL:

Proteger los datos en cuanto a su acceso.

Proteger los datos en cuanto a su modificación.

Controlar los tiempos de respuestas del sistema.

4. PROTECCION Y SEGURIDAD.

Establecer el sistema de recuperación.

Crear sistema de detección de errores.

5. REORGANIZACION Y DOCUMENTACION:

Maximizar el rendimiento en cuanto a tiempo y espacio. Según las prioridades, el tiempo

de respuesta del sistema deberá ser muy concreto. Si no se cumplen estos tiempos será una

necesaria reorganización.

Documentar el esquema de la Base de Datos para la Administración.

Documentar el diccionario de los datos para los usuarios.

Controlar las estadísticas con todo lo que sucede en la base de datos.

Nota: Un defecto muy extendido entre las empresas que utilizan base de datos, es precisamente este, el

administrador se convierte en un tirano que, en vez de facilitar una utilización a gusto del usuario. Esta


posibilidad deber ser entrad en todos lo casos. Es importante destacar que el administrador de la base de

datos debe servir para ayudar al resto de usuarios.

Clasificación de las Bases de Datos. Las Bases de Datos pueden clasificar en dos tipos:

Por la forma de Acceso.- Existen dos tipos básicos de base de datos de acuerdo a la forma de acceso por

parte de los usuarios, o el lugar donde se encuentran ubicados:

» Base de Datos Distribuidas

» Base de Datos Centralizadas

Por el modelo (estructura) utilizado.- Existen tres tipos básicos de base de datos con una estructuración

lógica, es decir por medio de su diseño físico, que considera la forma de almacenamiento de los datos y de

sus interrelaciones, así como la mecánica del acceso. Tenemos:

» Base de Datos Jerárquicas

» Base de Datos en Red

» Base de Datos Relacional.

Base de Datos Distribuidas y Centralizadas.

Antes de ver que son las bases de datos distribuidas o centralizadas, vamos a ver los tipos de procesos que

existen.

Proceso distribuido.- Este proceso se realiza cuando las tareas son compartidas (distribuidas) entre el

Servidor y los usuarios. Ocurre cuando una aplicación en el CPU accesa en una base de datos en otro CPU,

otro ejemplo sería, que en cada uno de los terminales (usuarios) se ejecuten cada una de las aplicaciones que

se necesitan, y en el servidor se ejecutan sólo aquellas que necesitan ser compartidas por todos los usuarios.

Algunos de los beneficios son:

Usted puede utilizar el mayor hardware apropiado para el trabajo a la mano, es decir, una

computadora personal puede ser usada para procesos rápidos, mientras que computadoras mini o

mainframes, con rápido I/O y virtualmente limitado en espacio en disco puede almacenar los datos

centrales, para accesar con el CPU.

Pueden accesar más usuarios con hardware más barato. La mayoría de procesos pueden ocurrir en

PC’s, y la capacidad puede ser incrementada comprando partes (adicionar) para el PC que

hardware para el mainframe.

Tanto el proceso departamental y la administración central son posibles. El compartir datos puede

ser administrado centralmente por un DBA, mientras que las aplicaciones y las herramientas de

proceso pueden ser controladas localmente por los usuarios.

Proceso Centralizado.- Este proceso se realiza cuando las tareas son realizadas exclusivamente en el

Servidor. Ocurre cuando cada uno de los terminales (usuarios) tienen que accesar obligatoriamente al

servidor para que se ejecutan las tareas que necesitan. En los terminales (usuarios) no se pueden ejecutar

tareas independientes, necesitan del servidor tanto para ejecutar las aplicaciones como para accesar a la Base

de Datos.


Qué es una Base de Datos Distribuida?

Es un conjunto de bases de datos almacenadas en más de un CPU en las cuales el modo que los usuarios la

ven es como una simple gran base de datos, cuando en realidad son pequeñas bases de datos. Cada base de

datos local puede ser controlada localmente por su DBA (mantenimiento, inicialización, respaldos y así). Es

importante notar que cada CPU corre el Software para accesar a otra base de dato; no hay un software central

el cual coordina todas las bases participantes. Esta provee la ventaja de sitios autónomos y evita un potencial

punto central de errores.

Un sistema de base de datos distribuidos incluye una base de datos distribuidas y herramientas de aplicación

que pueden localizarse en CPU’s separados de la base de datos. La diferencia a simple vista es que las

aplicaciones están en diferentes CPU’s que los datos que se requieren. Así las redes son usadas para que las

aplicaciones accedan a los datos.

Qué es una Base de Datos Centralizada?

Como podemos notar al igual que en los procesos, la Base de datos Centralizada sería aquella en la cual

existe una sola base de datos localizada en un único lugar, controlada por un único DBA (para el

mantenimiento, inicialización, etc.), ubicación al cual deben acceder todos los usuarios para realizar las

respectivas tareas con la Base de Datos.

Modelos de Base de Datos.

La base de datos según el modelo se clasifican en:

Bases de datos Jerárquicas.- Una de las aplicaciones mas importantes de los sistemas de gestión de base de

datos permitidos era el planeamiento de la producción para empresas e facturación. Si un fabricante de

automóviles decidía producir 10000 unidades de un modelo de coche y 5000 unidades de otro modelo,

necesitaba saber cuantas piezas pedir a sus suministradores. Para responder a la cuestión, el producto (un

coche) tenía que descomponerse en ensamblajes (motor, chasis,) que a su vez se descomponen en

subensamblajes (válvulas, cilindros) y luego en subensamblajes, etc. El manejo de estas listas de piezas,

conocidos como una cuenta de materiales, era un trabajo a la medida para las computadoras.

Motor Cuerpo Chasis

Puerta Izq. Puerta Der. Capota Techo

Tirador Ventana Seguro

Coche


La cuenta de materiales para un producto tenía una estructura jerárquica natural. Para almacenar estos datos,

se desarrollo el modelo de datos jerárquico, en este modelo, cada registro de la base de datos representa una

pieza específica. Los registros tienen relaciones padre/hijo, que ligaba cada pieza a su subpieza , y así

sucesivamente.

Las estructuras jerárquicas en ocasiones se denominan árboles, porque los subordinados conectados a las

entidades a las cuales pertenecen se asemejan a las ramas de un árbol, aunque curiosamente dibujadas hacia

abajo, como se puede apreciar en la figura anterior.

Para acceder a la base de datos jerárquica, un programa podría:

Hallar una pieza particular mediante su número (ej.: la puerta izquierda).

Descender al primer hijo.(el tirador de la puerta)

Ascender hasta su padre ( el cuerpo).

Moverse de todo hasta el siguiente hijo (la puerta derecha).

La recuperación de los datos en una base de datos jerárquica requería, por tanto, “navegar” a través de los

registros, moviéndose hacia arriba, hacia abajo y hacia los lados un registro cada vez.

Uno de los sistemas de gestión de base de datos jerárquicos más populares fue la information Managament

System (IMS) de IBM, introducido primeramente en 1968. Las ventajas del IMS y su modelo jerárquico son:

Estructura Simple.- La organización de una base de datos IMS era fácil de entender. La jerarquía de la

base de datos se asemejaba al diagrama de organización de una empresa o a un árbol familiar.

Organización Padre/hijo.- Una base de datos IMS era excelente para representar relaciones padre/hijo,

tales cómo << A es una pieza de B >>, o << A es propiedad de B >>.

Rendimiento.- IMS almacenaba las relaciones padre/hijo como punteros físicos de un registro de datos a

otro, de modo que el movimiento a través de la base de datos era rápida. Puesto que la estructura era

sencilla, IMS podía colocar los registros padre e hijo cercanos unos a otros en el disco, minimizando la

entrada / salida de disco.

“IMS sigue siendo el DBMS más ampliamente instalado en las maxicomputadoras IBM. Se utiliza en el

25% de las instalaciones de maxicomputadores IBM”.

Base de datos en Red.- La estructura sencilla de una base de datos jerárquica se convertía en una desventaja

cuando los datos tenían una estructura más compleja. En una base de datos de procesamiento de pedidos, por

ejemplo, un simple pedido podría participar en tres relaciones padre/hijo diferentes ligando el pedido al

cliente, al vendedor que lo aceptó y al producto ordenado, tal como se muestra en al figura:

Clientes Vendedores Productos

Pedidos

La estructura de este tipo de datos simplemente no se ajustaría a la jerarquiza estricta de IMS.

Acme Bill A.

Art. 4

Nro 123


Para manejar aplicaciones tales como el procesamiento de pedidos, se desarrollo un nuevo modelo de datos

en red. El modelo de datos en red extendía el modelo jerárquico permitiendo que un registro participara en

múltiples relaciones padre/hijo.

Clientes Productos

Ame 1st. Coa. Art. 4 Art. 5

Nro. 1 Nro. 2 Nro. 3 Nro. 4 Nro. 5 Nro. 6

Pedidos

Estas relaciones eran conocidas como conjuntos en el modelo de datos en red en 1971 la conferencia sobre

lenguajes de sistema de datos publicó un estándar oficial para base de datos en red, que se hizo conocido

como el modelo CODASYL. IBM nunca desarrolló un DBMS en red por sí mismo, eligiendo en su lugar

extender el IMS a lo largo de los años. Pero durante los años 70, compañías de software independientes se

apresuraron en adoptar el modelo en red, creando productos tales como el IBMS de Cullinet, el total de

Cincom y el DBMS Adabas que se hizo muy popular.

Para un programador, acceder a una base de datos en red era muy similar a acceder a una base de datos

jerárquicos. Un programador podría:

Hallar un registro padre específico mediante clave (como por ejemplo un número de cliente).

Descender al primer hijo en un conjunto particular ( el pr楩mer pedido remitido por este cliente).

Moverse actualmente de un hijo al siguiente dentro del conjunto (la orden siguiente remitida por el

mismo cliente).

Ascender desde un hijo a su padre en otro conjunto( el vendedor que acepto el pedido o el

articulo).

Una vez mas el programador tenía que recorrer la base de datos registro a registro, especificando cada vez

que relación recorrer además de indicar la dirección.

Flexibilidad.- Las múltiples relaciones padre/hijo permitían a una base de datos en red representar

datos que no tuvieran una estructura jerárquica sencilla.

Normalización.- El estándar CODASYL reforzó la popularidad del modelo de red, y los

vendedores de minicomputadores tales como Digital Equipment Corporation y Duta General

implementaron estas bases.

Rendimiento.- A pesar de su superior complejidad, las bases de datos en red reforzaron el

rendimiento aproximándolo al de las bases de datos jerárquicos. Los conjuntos se representaron

mediante punteros o registros de datos Físicos, y en algunos sistemas, el administrador de la base

de datos podía especificar la agrupación de datos basadas en una relación de conjuntos.


Las bases de datos en red tenían sus desventajas también. Igual que las bases de datos jerárquicas, resultaban

muy dirigidas. Las relaciones de conjunto y la estructura de los registros tenían que ser especificadas de

antemano. Modificar la estructura de la base de datos requería típicamente la reconstrucción de la base de

datos completa.

Tanto las bases jerárquicas como las bases en red eran herramientas para programadores. Para responder a

una cuestión tal como: “¿Cuál es el producto más popular ordenado por Acme Manufacturing?” un

programador tenia que escribir un programa que recorriera su camino a través de la base de datos. La

anotación de las peticiones para informes a medida duraba con frecuencia semanas o meses y para el

momento en que el programa estaba escrito la información que se entregaba con frecuencia ya no merecía la

pena.

Base de datos Relacional.- Las desventajas de los modelos jerárquicos y en red condujo a un intenso interés

en el nuevo modelo de datos relacional, cuando fue escrito por primera vez por el DR. Codd en 1970.

El modelo relacional era un intento de simplificar la estructura de base de datos. Eliminaba las estructuras

explícitas padre/hijo de la base de datos anteriores, y en su lugar representaba todos los datos en la base de

datos como sencillas tablas bidimensionales, las cuales contienen fila (registros) / columna (atributos) de

valores de datos. Una versión relacional de la base de datos en red para procesamiento de pedidos sería:

Tabla Productos

Desc. Precio Existencia

Art. 3 107 207

Art. 4 117 139

Art. 5 350 14

Tabla Pedidos

No. Ped Empresa Producto Cantidad

001 Acme Art. 4 28

002 Uno Art. 3 6

003 Dos Art. 5 35

Tabla Clientes

Empresa Rep-Cli Limite Crédito

Acme 105 50.000

Uno 103 50.000

Los sistemas primeros de gestión de bases de datos relacionales fallaron en implementar algunas partes clave

del modelo Codd, que solo ahora están encontrando su acomodo en productos comerciales.

Definición.- Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario

están organizados estrictamente como tablas de valores y en donde todas las operaciones de la base de datos

operan sobre estas tablas.

La definición está destinada específicamente a eliminar estructura tales como los punteros incorporados de

una base jerárquica o en red. Un DBMS relacional puede representar relaciones padre/hijo, pero estas se

representan estrictamente por los valores contenidos en las tablas de las bases de datos.


Integridad Transaccional.

Antes de comenzar a hablar sobre la integridad transaccional, debemos primero saber que es una transacción.

Transacción.- Es un hecho completo desde el punto de vista computacional, en el que se puede hacer

actualizaciones, borrados independientes o en conjunto. Ejemplo: Pedidos en una factura,

Depósitos, Retiros de fondeos, Cajeros Automáticos en los Bancos, etc. Además se puede hacer

consultas sin que ocurran desastres si hay algún percance.

Hasta ahora se ha considerado el empleo de seguros para proteger la Base de datos. Una incongruencia

temporal, introducida por una transacción de actualización, también puede crear respuestas erróneas en

transacciones que entreguen respuestas a los usuarios.

Sin embargo, un sistema que produzca resultados erróneos con cualquier frecuencia pronto perderá la

confianza de los usuarios. Por lo tanto, en este caso también es adecuado emplear un seguro. La transacción

de actualización ya debería estar asegurada para impedir interferencias de actualización. Las transacciones

sólo de lectura que necesitan ser correctas; esto es, deben ser capaces de soportar una auditoría, y en su caso

seguros para protegerse de actualizaciones simultáneas.

Se ha llegado a la conclusión, según observaciones, que los resultados erróneos solo se crean debido a

actualizaciones que interfieren, las cuales modifican múltiples elementos datos relacionados.

Especificación de un seguro.

Es necesario que exista una forma de avisar al sistema de apoyo a la Base de Datos que se ha solicitado el

seguro de un objeto. Sería de esperarse que el usuario final, el vendedor o el oficinista, solicitará la acción de

aseguramiento.

Cuando se logra el acceso a los objetos reclamados se colocan seguros. Puede haber retrasos, pero

eventualmente una transacción que espere en la línea correspondiente a un objeto tendrá el acceso al objeto

reclamado y podrá proceder.

La transacción coloca un seguro para lograr así el acceso exclusivo al objeto, y este seguro se conservará

hasta que la transacción se ejecute, para luego liberar el objeto. Las reclamaciones conservadas por una

transacción también se liberan cuando la transacción se concluye o aborta. Las transacciones que concluyan

sin liberar sus seguros se consideran defectuosas.

Si el sistema tiene la capacidad de eliminar los efectos de transacciones defectuosas y restaurar la base de

datos, esta restauración se recomienda.

A nivel mínimo, el administrador de sistema deberá ser informado cuando las transacciones se detienen sin

liberar todos sus seguros sobre los recursos. Si los seguros no se liberan, una parte del sistema no está

disponible.

Regiones que deben asegurarse. Se deben asegurar ciertas regiones en el que los datos obtenidos por una transacción de lectura son

inconsistentes debido a una secuencia de actualizaciones necesarias para realizar una transferencia de fondos.


A fin de garantizar que otras transacciones sean correctas es necesario asegurar una región constituida por los

dos objetos asegurados por la transacción de actualización.

Resultará necesario asegurar una región para impedir la interferencia, tanto de transacciones de lectura como

de actualizaciones.

Interacciones entre seguros.

Es necesario proporcionar aseguramiento entre transacciones de actualización y entre consulta sólo de lectura

que requieran resultados que puedan soportar una auditoría y transacciones de actualización. El empleo de

aseguramiento vuelve inaccesible a una parte de la Base de Datos.

Base de Datos Orientada a Objetos.

Gran parte de la investigación en el área de bases de datos durante los últimos años se ha concentrado en

nuevos modelos de datos “posrelacionales”. Al igual que el modelo relacional proporciona claras ventajas

sobre los punteros modelos jerárquicos y de red el objetivo de esta investigación es desarrollar nuevos

modelos de datos que puedan superar algunas ventajas del modelo relacional. Hoy en día la mayoría de la

investigación sobre nuevos modelos de datos está centrada en las llamadas bases de datos “orientadas a

objetos”. Los entusiastas defensores de las bases de datos orientadas a objetos proclama que son la

generación siguiente a los sistemas de bases de datos y se supone que serian una verdadero reto a las bases de

datos relacionales hacia el final del siglo.

No existe un acuerdo sobre que es una base orientada a objetos. Cuando los investigadores utilizan el

término están generalmente describiendo una base de datos que utiliza los mismos principios organizativos

que la programación orientada a objetos estos principios son:

OBJETOS.- En una base de datos orientada a objetos cualquier cosa es un objeto y se manipula como tal la

organización tabular de fila/columna de una base de datos relacional es sustituida por la noción de

colecciones de objetos. En general, una colección de datas es ella misma un objeto y puede ser manipulada

del mismo modo que se manipulan los restantes objetos.

CLASES.- Las bases de datos orientados a objetos sustituyen la noción relacional de tipo de datos atómicos

con una noción jerárquica de clases y subclases. Por ejemplo. “Vehículos” podría ser una clase de objeto, y

los miembros individuales (“instancias”) de esa clase incluirían un coche, una bicicleta, un tren, o un bote.

La clase vehículos podría incluir subclases denominadas coches y botes representada una forma más

especializada de vehículo. Análogamente, la clase coches podría incluir una subclase denominada

convertible, etc.

HERENCIA. Los objetos heredan las características de sus clases y de todas las clases de nivel superior a la

que pertenecen. Por ejemplo, una de las características de un vehículo podría ser el “# de pasajeros” . Todos

los miembros de las clases coches, botes y convertibles, tendrían también el atributo “# de puertas”, y la

clases convertibles heredaría este atributo, sin embargo, la clase bote no hereda el atributo.

MENSAJES Y METODOS. Los objetos se comunican unos con otros mediante el envío y recepción de

mensajes. Cuando recibe un mensaje, un objeto responde ejecutando un método, un programa almacenado

dentro del objeto que determina cómo se procesa el mensaje. Por tanto un objeto incluye un conjunto de

comportamientos descritos por sus métodos. Generalmente un objeto comparte muchos de los mismos

métodos con otros objetos de su clase.


Estos principios y técnicas hacen que las bases de datos orientadas a objetos estén bien adecuadas a

aplicaciones que implican tipo de datos complejos, tales como documentos compuestos o de diseños asistidos

por computador que combinan texto, gráfico y hoja de cálculo.

La base de los datos proporciona un modo natural de representar la jerarquías que aparecen en los datos

complejos. Por ejem: Un documento entero puede presentarse como único objeto, compuesto de objetos más

pequeños (secciones) compuestos de objetos aún mas pequeños (párrafos, gráficos, etc.).

La jerarquía de clases permiten a la base de datos seguir la pista del “tipo” de cada objeto en el documento

(párrafos, gráficos, ilustraciones, títulos, pies, etc.) . Finalmente el mecanismo de mensajes ofrece soporte

natural para una interfaz de usuario gráfica. El programa de aplicación puede enviar un mensaje “extráigalo

Ud. mismo” a cada parte del documento pidiendo que se extraiga de la pantalla. Si el usuario cambia la

forma de la ventana que visualiza el documento, el programa de aplicación puede responder enviando un

mensaje “modifica tu tamaño” a cada parte del documento, etc.

Cada objeto del documento tiene la responsabilidad de su propia visualización por lo que los nuevos objetos

pueden ser añadidos fácilmente a la arquitectura del documento.

Modelo Relacional. - Esquema Conceptual.

Sea una empresa o entidad de cualquier tipo, estas desean almacenar datos que reflejan información sobre sus

actividades.

Hay que empezar acotando que parcela del mundo exterior nos interesa representar en los datos. Estará

formada por los objetos y acontecimientos cuyo conocimiento nos permita una mejor gestión de nuestras

actividades.

El diseñador o analista de datos debe aprehender, comprender y conceptualizar este mundo, transformándolos

en un conjunto de ideas y definiciones, que formen una imagen fiel del comportamiento del mundo real. A

esta imagen del mundo exterior la llamaremos modelo conceptual. Para construir un buen modelo, el analista

debe utilizar una gran dosis de procesos mentales de abstracción, análisis y síntesis. Necesitará además de la

colaboración de personal directivo.

Una vez definido el modelo conceptual, el analista lo transforma en una descripción de datos, atributos y

tablas, incluyendo las posibles interrelaciones entre estos elementos y su significado. A esta descripción la

llamaremos esquema conceptual de datos. A la operación de transformar el modelo conceptual en un

esquema conceptual la llamaremos diseño lógico de datos ( por ello, al esquema conceptual también lo

llamaremos a veces esquema de diseño). Una vez definido el esquema conceptual, hay que traducirlos a

estructuras almacenables en soportes físicos controlados por el ordenador, normalmente discos magnéticos.

Esta transformación se suele llamar diseño físico de datos. (Ver Dibujo 1)

Un buen diseño lógico debe producir un esquema conceptual que sea una imagen fiel y completa del modelo

conceptual, incluyendo algunas interrelaciones y condiciones semánticas, es decir, aquellas que son

consecuencia del significado de los datos.

Por ello vamos a explorar en los siguientes capítulos algunos tipos de condiciones semánticas y cómo

expresarla en el esquema conceptual. En los últimos capítulos propondremos un método y una serie de

reglas que sirven de ayuda al analista en el proceso de diseño lógico.

Empezaremos en los apartados siguientes, definiendo los objetos con los que se construye el esquema

conceptual: atributos, tablas, dominios. Etc.


Modelo Relacional de Datos.

Un modelo de datos es un sistema formal y abstracto que permite describir los datos de acuerdo con unas

reglas y convenios predefinidos. Es formal en el sentido de que los objetos del sistema se manipulan

siguiendo unas reglas perfectamente definidas, y utilizando exclusivamente los operadores definidos en el

sistema, independientemente de lo que estos objetos y operadores pueden significar.

Por el contrario el modelo conceptual de datos, que como ya se ha dicho, es el conjunto de concepto e

interrelaciones que en la mente del analista forman una imagen del mundo real, no es un sistema formal.

El modelo de datos es el lenguaje en el que le analista describe el modelo conceptual que su mente ha

concebido, llamándose esta descripción, como ya se ha dicho, esquema conceptual.

Un modelo de datos es tanto mejor cuanto más capacidad expresiva tengan para producir fielmente en el

esquema conceptual el comportamiento del modelo conceptual, que a su vez deben ser imagen fiel del

mundo real si está bien concebido.

Un modelo de datos tiene tres componentes.

Estructura de datos: Es una colección de objetos abstractos por datos.

Operadores entre las estructuras: Conjunto de operadores, con reglas bien definidas , que permiten

manipulas la estructura de datos.

Definición de integridad: Colección de conceptos y reglas que permiten expresar que valores de

datos pueden aparecer válidamente en nuestro esquema.

Existen varios modelos de datos generalmente aceptados. Entre ellos los más utilizados son el jerárquico, el

modelo de red y el relacional. Este ultimo es el que aquí nos interesa.

La definición del modelo relacional de datos generalmente aceptada en la literatura sobre el tema

generalmente incluye las posibilidades de nulo, lo que lleva a redefinir los conceptos de clave, dominio, etc.

En la forma en que se ha establecido en el apartado anterior. Sin embargo, no suelen incluirse en él las

operaciones algebraicas extendidas (por ejemplo, yunción externa y unión externa). Este será el modelo de

datos al que nos referimos de ahora en adelante. En resumen, tiene los componentes siguientes:

Estructura de datos: Dominio, relaciones, atributos, tuplas.

Operadores: Los primitivos del álgebra relacional, es decir unión, diferencia, producto cartesiano,

proyección y selección.

Definición de integridad: Los conceptos de claves y la posibilidad de valores nulos.

También se incluyen aquí dos reglas de integridad, llamadas:

a) Integridad de claves primarias.

b) Integridad referencial.


Conceptos de los Componentes de la Base de Datos.

Realidad, datos y metadato.- Antes de considerar los componentes de la Base de datos, es importante

entender como se presentan los datos. Solamente el mundo real en sí puede ser mencionado como la

realidad. Aquellos datos que se obtienen de las personas, de lugares o de eventos de la realidad,

eventualmente serán almacenados en base de datos. Con el fin de comprender la forma y la estructura de los

datos, se requiere de información acerca de los datos mismos. Aquella información descriptiva de los datos

se denomina como metadato.

Qué es una Entidad?

Una entidad es cualquier objeto o evento, acerca del cual, se recolectan datos, o también se puede decir que

es una cosa con una existencia independiente.

Una entidad con existencia física puede ser una persona, un lugar o un objeto. Por ejemplo: un vendedor,

una ciudad o un producto. Una entidad con existencia conceptual puede ser un evento o unidad de tiempo,

tal como la descompostura de una máquina, una venta, un mes o un año, una compañía, trabajo o

universidad, etc.

Observación: Quiere decir que todas las entidades pueden contener (describir) varios tipos de datos, por

ejemplo el precio de un producto no sería una entidad, porque ya no podría contener otros tipos de datos, sino

que sólo contiene el valor del producto.

Qué son Relaciones?

Las relaciones son asociaciones entre entidades (y algunas se refieren como asociaciones de datos). Existen

3 tipos de relaciones o asociaciones:

Asociación uno a uno (1:1).- Son aquellas en las cuales solo interviene un objeto de cada entidad.

Ejemplo:

1) 2)

1 1

Se Se le

lista asigna

para

1 1

Descripción: El diagrama número 1 muestra que para cada PRODUCTO existe un sólo EMPAQUE. La

segunda relación de uno a uno muestra que cada EMPLEADO tiene una OFICINA única.

Producto

Oficina

Empleado

Empaque del

Producto


Nota: Observe que todas estas entidades pueden describirse aún más (el Precio de un producto no sería una

entidad, tampoco lo sería una extensión telefónica).

Asociación uno a muchos (1:M o M:1).- Son aquellas en las cuales interviene un objeto de una de las

entidades asociadas a varios objetos de la otra entidad. Ejemplo:

1) 2)

1 M

Trata pertenece

al a

M 1

Descripción: Como se muestra en la figura, en el primer gráfico de este tipo de relación muestra a un

MEDICO dentro de una organización de cuidados médicos se le asignan muchos PACIENTES, pero un

PACIENTE es asignado sólo a un MEDICO. El otro ejemplo (gráfico No. 2) muestra que un EMPLEADO

es un miembro de sólo un DEPARTAMENTO, pero cada DEPARTAMENTO tiene numerosos

EMPLEADOS.

Asociación muchos a muchos (M:N). Son aquellas en las cuales intervienen varios objetos de una de

las entidades asociadas a varios objetos de la otra entidad, es decir que describe la posibilidad de que las

entidades puedan tener numerosas asociaciones en cualquier dirección. Ejemplo:

1) 2)

M M

Atiende

Toma a

Descripción: En el ejemplo número 1 muestra que un ESTUDIANTE puede tener o tomar muchos

CURSOS, mientras que al mismo tiempo, un CURSO puede tener muchos ESTUDIANTES inscritos. El

segundo ejemplo nos muestra cómo un VENDEDOR puede cubrir muchas ciudades, y una CIUDAD puede

ser un área de ventas para muchos VENDEDORES.

Qué es un atributo?

Un atributo es una característica de una entidad, es decir que cada entidad tiene propiedades particulares que

la describen. Puede haber muchos atributos para cada entidad. Por ejemplo, un paciente (entidad) puede

tener numerosos atributos, tales como el apellido, nombre, dirección, ciudad, estado, etc. Otro ejemplo es: la

entidad libro debe ser descrita por el titulo de la obra, autor, editorial, año de edición.

Medico

Departamento

Empleado

Paciente

Estudiante

Ciudad

Vendedor

Cursos


La palabra atributo también se la puede utilizarse de manera intercambiable con la de dato. Los datos de

hecho son las unidades más pequeñas en un base de datos.

Tipos de atributo

Existen Seis tipos de atributos (de acuerdo a los datos que lo componen) los cuales son:

1. SIMPLES.- Aquellos atributos que son indivisibles, son llamados atributos simples o atómicos.

Ejemplo: Título de la Obra, en el caso de la entidad Libro.

2. COMPUESTOS.- Estos atributos pueden ser divididos en subpartes más pequeñas las cuales representan

más atributos básicos, con significados independientes del concepto básico. La concatenación de

atributos simples conforman un atributo compuesto. Ejemplo: La fecha, esta compuesta por Día, Mes y

Año.

3. SIMPLE VALOR.- Son los que tienen un valor simple para una entidad particular. Ejemplo: IVA,

siempre es 10.

4. MULTIVALOR.- Un atributo multivalor debe tener un límite superior e inferior en el número de

valores para cada entidad individual. Ejemplo: Edad mayor a 18 y menor a 85.

5. DERIVADO.- Es cuando el valor de un atributo puede ser determinado en base a otro. Ejemplos: El total

de un articulo es calculado en base a la Cantidad por el Precio Unitario, la edad de una persona, es en

base a la Fecha de Nacimiento de esa persona.

6. ALMACENADO.- En base a este atributo se puede obtener atributos derivados. Ejemplo: La cantidad o

el Precio Unitario sirven para obtener el Total.

En algunos casos una entidad particular, puede no tener un valor aplicable para un atributo, para tal situación

un valor especial denominado nulo es creado. La categoría de los valores nulos pueden ser adicionalmente

creadas en dos casos. El primer caso cuando se conoce que el valor del atributo existe pero es desconocido, y

el segundo caso cuando no se conoce si el valor del atributo existe.

Qué son los Dominios?

Un dominio es un conjunto, finito o infinito, de palabras formadas con un alfabeto finito entre las que existe

un criterio de orden. Este criterio de orden puede ser común para varios dominios, por lo que éstos pueden

participar unos con otros en ciertas operaciones que impliquen comparación y orden. Por ejemplo, tiene

sentido hablar de unión, intersección, etc. , entre ellos. Por ejemplo:

D1: Conjunto de fechas de nacimiento.

D2: Conjunto de los sueldos en sucres de los empleados.

D3: Conjunto de los nombres de los empleados.

Entonces se podría restringir las operaciones de comparación y orden a elementos y subconjuntos de un

mismo dominio. Así se aseguraría evitar hacer operaciones sin sentido, como por ejemplo comparar fechas

con sueldos.

A un dominio se le especifica nombre, tipo de dato y formato, es posible que varios atributos tengan el

mismo dominio, el atributo indica diferentes roles o interpretaciones para el dominio.


Qué son las Tuplas?

Cada elemento de una relación se llama tupla, y también se las conoce con el nombre de registros, que es

una colección de datos elementales que tienen algo en común con la entidad descrita, es decir está compuesta

por los atributos de una entidad.

Se llama grado de una tupla al número de componentes que tiene. El grado de una relación es el de sus

tuplas.

Como las entidades son conjuntos, todas sus tuplas deben ser diferentes. Es decir, en una relación no puede

haber tuplas repetidas. Además, no hay un criterio de orden definido entre ellas.

Una tupla puede representarse o bien como una lista ordenada de valores:

T=<t1, t2, t3, t4, ......, tn>, donde:

T1= Valor del primer dominio

T2= Valor del segundo domino

T3= Valor del tercer dominio

T4= Valor del cuarto dominio

O bien como una lista desordenada de valores identificados por sus nombres de atributos:

T=<Atr3=t3, Atr2=t2, Atr1=t1, ....., Atrn=tkn>.

Qué son las Tablas?

Si colocamos todas las tuplas de una relación una debajo de otra, alineando los componentes

correspondientes de cada atributo en una columna, y colocamos en la cabecera de cada columna el nombre de

sus atributos, obtenemos una representación de la relación a la que designaremos con el nombre de TABLA.

Dentro del Esquema Conceptual, las tablas provienen de las Entidades, y compuestas por los atributos de la

misma que pasan a conformar un registro.

Las tablas están compuestas de registros, y estos de atributos. Una tabla es parecida a una matriz que esta

compuesta de filas y columnas, en donde las filas forman los registros y las columnas los datos. Dentro de

las tablas y atributos encontramos las denominadas Claves o Llaves Primarias.

Qué son las Claves?

Una clave es un dato elemental en un registro que se utiliza como criterio de identificación para éste,

también se le conoce con el nombre de llave. Cuando una llave identifica de manera exclusiva a un

registro se le denomina llave primaria (o criterio primario). Por ejemplo: un # de Orden, puede ser

una llave primaria porque sólo hay un número asignado a cada orden o pedido del cliente, es decir

que no puede tomar valores repetidos. De esta manera, la llave primaria identifica la entidad del

mundo real (orden del cliente). Toda entidad tiene al menos una clave, pero puede tener más de una.

Esto depende del significado de la relación.


Una llave puede denominarse llave secundaria ( o criterio secundario) si no identifica de manera

exclusiva a un registro. Las llaves secundarias se utilizan para seleccionar a un grupo de registros

que pertenecen a un conjunto, por ejemplo: las órdenes que provienen de determinada ciudad.

Cuando no es posible identificar de manera exclusiva un registro utilizando uno de los elementos

dato presentes en el registro, la llave puede construirse mediante la elección de dos o más elementos

dato combinándolos entre sí. A este criterio se le denomina llave concatenada. Cuando se utiliza un

elemento dato en un registro como criterio (llave secundaria), es recomendable subrayarlo

(__________), por el contrario si el atributo es una llave presente en otro archivo (llave ajena), debe

subrayarse con una línea punteada ( _ _ _ _ _ _ ).

Integridad de claves primarias.

Al definir el concepto de claves se dijo que estas pueden utilizarse como identificadores de las tuplas

de una relación, puesto que a cada valor de una clave corresponde una sola tupla y viceversa.

En el modelo relacional, la única manera de encontrar una tupla determinada en una relación, es

conociendo el valor de una clave.

Una relación puede tener varias claves, pero suele aceptarse la conveniencia de usar siempre la

misma como identificador. A esta clave se la suele llamar clave primaria. Las restantes se las llama

claves alternativas.

Puesto que la clave primaria es el identificador designado para una relación, no debería de tomar

valores nulos para evitar ambigüedades. Esta condición es la que hemos llamado regla de integridad

de claves primarias.

Podría pensarse que en el caso de tener varias claves, podríamos emplear como identificador unas

veces a una y otras veces a otra, con lo que tendríamos una única clave primaria y ambas podrían

tomar valores nulos. Esto no es así y podría crear problemas de ambigüedad.

En conclusión en toda relación deber de designarse a una clave como primaria y sus atributos no

deben tomar valores nulos.

Si una relación tiene varias claves cualquiera de ellas puede ser designada a priori como primarias.

Para elegir la más conveniente, el diseñador de la base de datos deberá tener en cuenta el significado

de la relación y sus atributos, y sopesar diversos factores. Pueden considerarse los siguientes.

* Estabilidad.

Considerar si algunas claves son menos propensas a sufrir modificaciones en sus valores.

* Facilidad de uso.

Será, por ejemplo, más fácil de usar una clave numérica corta que otra alfanumérica con otros

caracteres.


* Fiabilidad.

Ver si alguna clave contiene dígitos de validación u otros mecanismos de autodetección o

corrección de errores..

* Universalidad.

Puede haber claves cuyo uso y conocimiento esté muy extendido (por ejemplo el número de

Documento Nacional de Identidad, cédula).

Integridad Referencial.

La integridad referencial es una propiedad muy agradable de la base de datos relacional para

fortificar el sistema de manejo de datos. Especialmente la integridad referencial asegura que las

relaciones representadas por las llaves primarias y secundarias sean mantenidas.

Se podría decir entonces que es una regla que refuerza una relación dentro de un sistema.

Cuando en el esquema conceptual se designa un atributo como llave ajena (secundaria, en las que

sobrecae la responsabilidad de la relación), conviene también especificar las acciones a tomar en

caso de intentar actualizarlo con los valores inválidos. Estas acciones dependerán de los valores de

los datos, esta es una de las reglas de integridad relacional, entonces tenemos ejemplo:

Ejemplo para realizar las validaciones de Integridad:

Tabla Departamento

Código Nombre Extensión

01 Ventas 205

02 Contabil. 190

03 Estadist. 135

04 Administ. 146

Tabla Empleados

Código Nombre Departamento

01 Juan 03

02 Luis 03

03 María 02

04 Carla 04

05 José. 01

Empleados Departamento


06 Pedro 02

Reglas de Inserción:

En función de como se asignan los empleados a departamentos.

a) Inserción en Dpto.

no hay que comprobar nada.

b) Inserción emp

Hay que comprobar que el dpto. de este nuevo empleado en la tabla Dpto. Si así no fuere

se rechazara la petición de inserción en Emp.

Reglas de Actualización.

a) Actualización en Dep modificando el atributo principal .

Hay que comprobar que el dpto. que modificamos no tiene empleados. Si así no fuere, la

acción a tomar para mantener los datos en un estado válido de acuerdo con la integridad

referencial podría ser la siguiente:

Rechazar la petición de actualizar.

Aceptada y propagada a Emp, es decir, actualizar en Emp todos los registros que

hagan al departamento modificado poniendo el nuevo valor en la tabla EMP campos

NomDept.

Aceptarla y anularla referencia es decir, actualizar todas las tuplas de Emp que

hagan referencia al departamento poniendo nulo en el atributo Emp.Nomdpto.

b) Actualización en emp modificando el atributo Departamento.

Hay que comprobar si el nuevo valor de Emp. Departamento no es nulo, existe en Dep. Si

así no fuere, se rechazará la petición de actualización.

Reglas de Borrado.

a) Borrado de un registro en Dpto.

Hay que comprobar que le dpto. que borramos no tiene empleados. Si así no fuere, la

acción a tomar para mantener los datos en un estado válido de acuerdo a la integridad

referencial podría ser una de las siguientes:

Rechazar la petición de borrado.

Aceptada y propagada a Emp, es decir, borrar en Emp todos los registros que hagan

referencia al departamento borrado. Este borrado podría propagarse a su vez a otras

relaciones que hagan referencia a Emp.


Aceptarla y anularla referencia es decir, actualizar todas las tuplas de Emp que

hagan referencia al departamento poniendo nulo en el atributo Emp.Nomdpto.

b) Borrado de un registro de emp.

No hay que comprobar nada.

En conclusión en la tabla Emp no puede ser asignado un Dpto. que no exista en la tabla dpto. Al

borra o actualizar la tupla Dpto. debe verificarse en la tabla Emp.

El primer beneficio de la integridad relacional es la consistencia de los datos. Dentro de Oracle,

como en la mayoría de DBMS, esta integridad se almacena en un archivo conjuntamente con la Base

de Datos. Es decir que puede ser definida en el momento de la creación de las tablas y sus relaciones.

Refuerza el descuido de las aplicaciones o herramientas que accesan a las tablas.

La llave ajena es el mecanismo para soportar la integridad referencial.

Diseño Conceptual de la Base de Datos

Para entender mejor como realizar el diseño conceptual (Modelo Relacional de Datos), utilizaremos

un ejemplo práctico, en el cual se desarrollarán cada uno de los pasos a seguir para conseguir reflejar

la información de las actividades.

Como se mencionó anteriormente, lo primero que se debe hacer es entender el mundo exterior, para

ello hay que elegir la parcela que nos interesa representar los datos. Es decir investigar los objetos y

acontecimientos cuyos conocimientos nos permita una mejor gestión de nuestras actividades.

Descripción de la Parcela Investigada (Ejemplo).

La parcela que vamos a investigar son los procesos realizados en la Biblioteca de la Universidad

Técnica de Machala, ubicada en la Facultad de Ingeniería Civil. Es decir vamos a realiza un Control

de Biblioteca.

Dentro de este departamento se realizan dos procesos:

a) Proceso de Prestación de Libros.

El proceso se puede resumir en los siguientes pasos:

1. El cliente se acerca a pedir un determinado libro.

2. La encargada le atiende el pedido preguntando cual es el autor y tema del texto a

investigar. Como requisito le pide la cédula a la persona particular o carnet al estudiante,

si el texto de consulta se encuentra disponible, la encargada procederá al siguiente control.

3. Se registrará el título del libro, el autor o autores, el nombre de la persona que requirió el

libro, el código del libro y la firma del estudiante, y se procede a la entrega del libro. Esto

se da al momento que se realiza el préstamo solamente interno, es decir, para un

determinado período de tiempo en el mismo día, y en el mismo lugar. Es decir que el


cliente hace uso del libro tomándose el tiempo necesario para realizar sus investigaciones

dentro de la sala.

4. Si se requiere el texto para varios días, se realiza el mismo proceso anterior, registrando

además la fecha de préstamo y la fecha de entrega como campos adicionales, y por el

mismo motivo solo pueden realizarlo los estudiantes que pertenezcan a una de las

facultades de la Universidad Técnica de Machala y no a personas particulares. La fecha

de devolución la da a conocer la encargada de la Biblioteca.

5. Al momento de la devolución, la encargada revisa el libro, si no existe desperfectos en el

mismo, se devuelve la cédula al estudiante, de no ser así la encargada toma las medidas

necesarias. (Ejem. Multa o pago del valor del libro, devolución de un libro igual, etc.).

6. Si el plazo fijado en la fecha de entrega se sobrepasa, los estudiantes se acogen a las

siguientes sanciones:

Si no hay devolución del texto, se negará la matricula al estudiante para el próximo año.

El estudiante que no realice la devolución estará objeto a no presentarse a exámenes; por

lo consiguiente no podrá volver a confiársele otro libro de consulta.

b) Proceso para Inventario de Libros.

Cuando se recibe (como donación) o adquiere (compra) un libro o texto, se procede a realizar el

inventario correspondiente de los datos, como se describe a continuación:

Número del inventario, Clasificación, Fecha de Ingreso del libro, Autor (es), Título, Cantidad,

Página, Ingreso, Precio, Número de Páginas, Observaciones acerca del libro.

A continuación se detallan los datos más importantes del libro o texto en la ficha bibliográfica.

Se procede a llenar la ficha de identificación de la misma que consta adicionalmente de los

siguientes datos:

Fecha de Ingreso, Número de entrada, Número ordinal.

Luego esta ficha será adherida al libro o texto respectivo.

Documentos utilizados dentro de los procesos.

Para completar la descripción de estos procesos, nos avalizamos en los documentos utilizados en los

procesos.

Estos documentos son:


a) Ficha de Préstamo:

b) Ficha del Libro (Adjunto al libro)

c) Ficha Bibliográfica

Universidad Técnica de Machala

Facultad de Ingeniería Civil

BIBLIOTECA

Título: ...........................................................................................

........................................................................................................

Autor: .............................................................................................

Préstamo: ........................................ Entrega: ...............................

Facultad: ........................................ Curso: ...................................

Domicilio: ......................................................................................

Nombre del Estudiante: .................................................................

........................................

F i r m a



BIBLIOTECA

Fecha de Ingreso: ..........................................................................

Clasificación: .................................................................................

No. De Entrada: ............................................................................. No. Ord. : .......................................................................................

Algebra Lineal y Teoría de Matrices 512. 5 Herstein, I. N.

Algebra lineal y teoría de matrices / I. N. Herstein y David J. Winter; traductor Eduardo M.

Ojeda Peña, revisor técnico Francisco Paniagua Bocanegra. México: Edit. Iberoamérica, 1989.

XV, 555 p.: grf., il.

Incluye Símbolos e índices alfabético

ISBN 968-7270-52-7

.............................................................................................................

512. 5 Herstein, I. N.

Algebra lineal y teoría de matrices / I. N. Herstein y David J. Winter; traductor Eduardo M.

Ojeda Peña, revisor técnico Francisco Paniagua Bocanegra. México: Edit. Iberoamérica, 1989.

XV, 555 p.: grf., il.

Incluye álgebra lineal

ISBN 968-7270-52-7


d) Inventario de Libros

e) Registro Diario de Lectores.

Desarrollo del Esquema Conceptual

Una vez que conocemos el mundo exterior, y nos formamos una idea de este mundo (Modelo

Conceptual), debemos pasar a desarrollar el Esquema Conceptual, es decir a definir cada uno de los

componentes de la Base de Datos, para lo cual lo realizamos siguiendo los pasos descritos a

continuación:

1. Definir Entidades.-

Podríamos acotar, que según el concepto estudiado anteriormente, podremos encontrar los siguientes

tipos de Entidades:

De tipo Persona, Objeto, Lugar, Evento o Unidad de Tiempo.

En este paso, debemos encontrar dentro de los procesos o parcela del mundo exterior, que nosotros

hemos conceptualizado, todas las entidades que se necesita para reflejar lo que ocurre en la realidad,

siempre y cuando respetemos su respectivo concepto.

En el ejemplo que hemos expuesto, encontramos las siguientes entidades de acuerdo a su respectiva

clasificación:



BIBLIOTECA Registro Diario de Lectores:

Ordinal Autor Titulo Nombre Firma Entrega



BIBLIOTECA

Clas No.

Inv.

Fec.

Ing.

Autor Titulo Cant Pag. Ingreso Prec. Obs.

310 927 1-1-97 William A. Nash Resistencia de materiales

2 304 Compra 50000 C/u

728 942 3-7-97 Anselmo

Rodríguez

62 Modelos de

chalets

1 Compra 680000 4 tomo

625.85

945 1-4-98 Federal Highway Hot-Mix bituminous

Paving Manual

1 Donación 100000


No

hay Consta

en

Se

registra

De tipo Persona: Los Alumnos (que van a realizar la petición del préstamo).

De tipo Objeto: Los Libros (que van a ser prestado a los alumnos para investigación)

De tipo evento: El Registro (de los libros prestados a los alumnos)

Por el momento son todas las entidades (o datos) que necesitamos utilizar para reflejar lo que ocurre

en el mundo exterior.

2. Definir Relaciones.-

Una vez que nosotros hemos descrito o encontrado las entidades principales del Esquema

Conceptual. Debemos proceder a ubicar o describir las relaciones que existen entre estas entidades.

Para ello debemos tomar encuentra el concepto de relación, y adicionalmente debemos conocer

ciertas reglas para su creación:

No debe existir o no se puede relacionar entidades Externas y entidades Internas. Las

entidades Externas son aquellas que no pertenecen directamente a la parcela del mundo

exterior, pero de alguna forma intervienen en los procesos. En cambio las entidades

Internas son aquellas que pertenecen directamente a la parcela, e intervienen de una forma

activa.

Las relaciones que se crean, van encaminadas en cierta forma, a explicar las posibles

pertenencias (o dependencias) que existen entre estas entidades.

Para poder verificar si existe o no debemos comparar cada una de las entidades con todas

las que existan en el esquema conceptual. Se debe hacer esta comparación, solamente

entre dos entidades a la vez.

Cada relación tiene que estar sustentada, por medio de frases que indican el porqué de la

existencia de esa relación. Si no existe relación se debe indicar este estado.

De acuerdo a esto, hemos encontrado las siguientes relaciones:

1 1 = 1 1 N = N

Alumnos

Libros

Alumnos

Registros

Libros

Registros

N 1 = N N 1 = M


Nota: Como podemos observar, siempre debemos ver las relaciones que existen entre dos

entidades a la vez, y además debemos examinar por los dos lados de la relación. Ejemplo: Primero

desde Alumnos hacia Registros, y luego desde Registros hacia Alumnos, para obtener una visión

global de lo que ocurre.

3. Definir Esquema Inicial.-

Una vez que hayamos terminado de describir las relaciones existentes entre las entidades,

procedemos a realizar el esquema inicial, que no es más que graficar mediante recuadros y flechas

las relaciones existentes entre las entidades.

De esta forma el esquema inicial del ejemplo expuesto es el siguiente:

Una vez que nosotros hayamos terminado de graficar este esquema, debemos revisarlo con el fin de

encontrar Relaciones Terciarias, estas relaciones son aquellas en las que están implicadas tres

entidades que al estar relacionadas, forman un triángulo (figurativamente representa a un círculo

entre estas). En el ejemplo expuesto no existen este tipo de relaciones, pero en el caso de que se

den, estas deben ser eliminadas.

Ejemplo de una relación terciaria:

En este ejemplo aunque no lo parezca, (debemos tratar de conceputalizarlo en nuestra mente), estas

entidades forman un triángulo por medio de sus relaciones. Es decir que las relaciones terciarias son

aquellas que mediante las relaciones unen o enlazan a tres entidades a la vez.

Dentro del esquema conceptual, debemos eliminar, o al menos tratar de que no se den este tipo de

relación, para lo cual debemos revisar las relaciones existentes entre estas entidades y quedarnos

solamente con aquellas que son vitales para el funcionamiento y reflejo de la realidad.

Para ello, debemos realizarnos preguntas de tipo consulta, de tal manera que podamos identificar la

relación con menos prioridad, esta relación que no es de mucha importancia, deberá ser eliminada

para que desaparezca la relación terciaria.

4. Asignar Atributos.-

Una vez que hayamos terminado de depurar el esquema inicial, y las relaciones existentes entre las

entidades estén bien, procedemos a definir o asignar cada uno de los atributos que van a tener las

entidades.

Estos atributos los definimos de acuerdo a los procesos que hemos investigado, es decir que del

Modelo conceptual tomamos la información que va a ser almacenada, conviertiéndose esta en las

características o atributos de las entidades, para el Esquema Conceptual.

Alumnos Registro Libros

Entidad 1 Entidad 2 Entidad 3


De esta forma tenemos:

Entidad Alumnos:

Cédula, apellidos, nombres, dirección, teléfono, facultad, escuela, curso.

Entidad Libro:

Numero_inventario, codigo_materia, nombre_libro, autor, cantidad, precio, observaciones,

ingreso, fecha_de_ingreso, páginas.

Entidad Registro:

Num_registro, fecha_pedido, fecha_entrega.

Nota: Debemos tener en cuenta de que no exista redundancia, por este motivo, una de las

principales reglas para definir atributos es, que no puede existir el mismo atributo en más de dos

entidades, es decir, no se pueden repetir los atributos.

5. Definir Dominios.-

Ahora que ya hemos definido los atributos de cada entidad, es necesario definir los dominios que se

utilizarán.

Para ello debemos recordar que a cada dominio se le debe asignar un nombre, este nombre puede ser

cualquiera, solo hay que establecer uno que sea fácil de recordar y nos ayude a organizar y

comprender su significado; además tenemos que tener en cuenta que un dominio podría agrupar

varios atributos, así que tenemos que tratar que estos dominios agrupen esa información.

De acuerdo a lo mencionado anteriormente encontramos:

Nombre Tipo de Dato Formato

D1 —» Conjunto de nombres : Caracter(30)

D2 —» Conjunto de títulos : Caracter(100)

D3 —» Conjunto de teléfonos : Caracter(10)

D4 —» Conjunto de observaciones: Caracter(30)

D5 —» Conjunto de Fecha : Fecha mm/dd/aa

D6 —» Conjunto de Códigos : Numérico 9999

D7 —» Conjunto de cédulas : Caracter(11)

D8 —» Conjunto de datos : Caracter(15)

D9 —» Conjunto de valores : Numérico 9,999,999.99

6. Definir Tuplas.-

En este momento debemos definir las tuplas, utilizando el nombre de sus atributos, de esta manera

estaremos diseñando como quedará el registro de las Entidades, (cabe recalcar que las entidades se

convertirán en las tablas), y el orden de sus atributos (los atributos pasarán a ser los campos de las

tablas).


Entidad Alumnos.- Reg_Alumnos:

Cédula, apellidos, nombre, dirección, teléfono, facultad, escuela, curso

Entidad Libros.- Reg_libro:

Numero_inventario, codigo_materia, nombre_libro, autor, cantidad, precio, observaciones,

ingreso, fecha_de_ingreso, páginas.

Entidad Registro.- Reg_registro:

Num_registro, fecha_pedido, fecha_entrega.

7. Asignación de atributos a los dominios.-

Una vez que ya tenemos los atributos, y en que orden van a quedar en las tuplas, debemos definir

qué dominio le corresponde a cada uno de los atributos, de esta forma estaremos definiendo el tipo

de dato de cada atributo.

Para realizarlo de una manera organizada, ya que esto debe quedar documentado, pondremos el

dominio y a continuación los atributos que le pertenecen, de esta forma tenemos:

D1 —» Apellidos, nombre, facultad, escuela, dirección, ingreso, autor.

D2 —» Nombre_libro.

D3 —» Teléfono.

D4 —» Observaciones

D5 —» Fecha_ped, Fecha_ent, fecha_de_ingreso.

D6 —» Num_registro, numero_inventario, codigo_materia, cantidad, paginas.

D7 —» Cédula.

D8 —» Curso.

D9 —» Precio.

8. Definición de Llaves.-

A veces no toda relación tendrá un único atributo que sirva como llave, pero siempre habrá una

combinación de atributos que tomados en conjunto posean la característica de unicidad, a esta unión

se la denomina llave compuesta.

El otro caso es en el cual, dentro de la entidad existen varios atributos que pueden ser llave primaria,

a estas se las conoce con el nombre de llave candidata.

Para saber si una llave candidata puede escogerse como llave primaria, podemos hacer algunas

preguntas como:

Si quitamos cualquier elemento de una entidad. Sigue siendo única la llave?

Existe una posible situación en que la llave pudiera ser no única?

Existe alguna parte de la llave que no este definida?

Es decir, debemos hacer una exhaustiva investigación sobre cada una de las llaves candidatas, de tal

forma que escojamos la que mejor represente al registro. Una vez que escogemos una de ellas, el

resto de llaves pasan a ser llaves secundarias.


Dentro de nuestro esquema conceptual tenemos las siguientes llaves:

Llaves principales: Llaves secundarias:

Alumnos: *Cédula

Libros: *Numero_inventario

Registro: *Num_registro

Alumnos: No Hay

Libros: No hay

Registro: No hay

Nota: Al lado de cada llave principal se ha colocado el símbolo asterisco (*). De esta forma, se

podrá identificar claramente que esa será la llave principal.

9. Definición de Reglas Generales (De relación).-

Hasta el momento ya se ha definido las entidades, sus atributos, los dominios, las llaves, y las

relaciones. Con respecto a las relaciones encontramos que existen tres tipos de relaciones: de 1 a 1,

de 1 a N, y de N a M. Pero hasta el momento sólo hemos descrito las relaciones que existen dentro

de nuestro esquema conceptual, pero según la teoría de las bases de datos relacionales, las relaciones

se las efectúa por medio de un valor dentro de las tablas.

Para poder asignarle realmente las relaciones a las tablas, nosotros encontramos una regla para cada

tipo de relación. De esta forma tenemos:

Relaciones de 1 a 1:

Si nosotros encontramos relaciones de 1 a 1, debemos tratar de que estas desaparezcan. Es decir que

se creará una sola entidad que contenga a las dos anteriores. Tomando el nombre que más le indique

el contenido.

Como toda regla tiene su excepción, vamos a encontrar casos en que se necesite dejar estas dos

entidades separadas. Entonces la relación 1 a 1 se convierte automáticamente en relación 1 a N, es

decir debemos buscar cual de estas dos entidades, en un futuro se puede convertir en una entidad

relación N. (Ver regla relación 1 a N).

En el esquema conceptual del ejemplo que estamos realizando no existen relaciones 1 a 1.

Relaciones 1 a N:

Si en nuestro esquema conceptual existen relaciones de 1 a N, debemos hacer lo siguiente:

*código código

La Llave principal (completa) de la entidad relación 1, debe pasar a formar parte de la entidad

relación N. A esta se le conoce con el nombre de Llave Ajena. En el ejemplo del gráfico anterior,

Entidad 1 Entidad 2

Entidad Unificada

Entidad 1 Entidad 2


estamos tomando en cuenta que la llave principal de la entidad 1 es código, y este pasa a formar

parte de la Entidad 2 como llave ajena.

En el esquema conceptual que estamos realizando existe una relación 1 a N.

* Cédula Cédula

En este caso como cédula es la llave principal de la entidad Alumnos que tiene la relación 1, pasa a

formar parte de la Entidad Registro (Relación N) como llave ajena.

Relaciones de M a N:

Cuando encontramos dentro de nuestro esquema conceptual relaciones de M a N debemos ejecutar la

siguiente regla:

Se creará una nueva entidad, que contendrá las llaves principales de las dos entidades en mención.

Entonces esta nueva entidad tendrá la relación N y las dos anteriores se convertirán en relación 1.

Ejemplo:

*Código Código *Cédula

Cédula

En este ejemplo, vemos creada una nueva entidad que contiene tanto el código que es llave principal

de la Entidad 1, como la cédula que es la llave principal de Entidad 2. Esta nueva entidad ahora pasa

a ser relación N, mientras que la Entidad 1 y la Entidad 2 ahora tienen relación 1.

En el esquema del ejemplo que estamos realizando también encontramos una relación de M a N:

* Num_registro *Numero_inventario

Ahora debemos crear una nueva entidad, y en esta colocar las llaves principales (completas) tanto de

la entidad Registro como de la Entidad Libros, y el resultado es el siguiente:

*Num_registro Num_registro * Numero_inventario

numero_inventario

Debemos notar que la relación N a M entre las entidades Registros y Libros se transforma en

Relación de 1 a N entre Registros y Detalle_Registro, y otra relación de 1 a n entre Libros y

Detalle_Registro.

Alumnos Registro

Entidad 1 Entidad 2

Entidad 1 Entidad 2 Entidad Nueva

Registro Libros

Registros Libros Detalle_Registro


10. Definir gráfico según las reglas.-

Como habremos notado, al ejecutar las reglas generales sobre las relaciones pueden existir algunos

cambios en las entidades y sus componentes, por lo tanto se hace necesario que, después de haber

ejecutado cada una de estas reglas debamos realizar un gráfico para mostrar el nuevo estado del

esquema conceptual. El gráfico del esquema conceptual después de las reglas generales para nuestro

ejemplo es:

Normalización de Datos.

¿Qué es la Normalización?

La normalización es una actividad colectiva encaminada a establecer soluciones a situaciones

respectivas.

En particular, esta actividad consiste en la elaboración, difusión y aplicación de normas.

La normalización en general, ofrece importantes beneficios, como consecuencia de adaptar los

productos, procesos y servicios a los fines a los que se destinan, proteger la salud y el medio

ambiente, prevenir los obstáculos al comercio y facilitar la cooperación tecnológica.

¿Qué es una Norma?

Las normas son documentos técnicos con las siguientes características:

Contienen especificaciones técnicas de aplicación voluntaria.

Son elaborados por consenso de las partes interesadas.

Están basados en los resultados de la experiencias y el desarrollo tecnológico.

Son aprobados por un Organismo Nacional / Regional / Internacional de Normalización

reconocido.

Están disponibles al público.

Las normas ofrecen un lenguaje común de comunicación entre las empresas, la Administración, los

usuarios y consumidores.

Se podría decir que establecen un equilibrio socioeconómico entre los distintos agentes que

participan en las transacciones comerciales, base de cualquier economía de mercado, y son un patrón

necesario de confianza entre cliente y proveedor.

Ventajas de la Normalización.

Entre las ventajas que encontramos de normalización (en un plano general, más específico en el

comercio), están:

Mejora la gestión y el diseño

Registros Libros Detalle_Registro Alumnos


Facilita la comercialización de los productos y su exportación

Establece niveles de calidad y seguridad de los productos y servicios

Informa las características del producto

Facilita la comparación entre las diferentes ofertas.

Simplifica la elaboración de textos legales.

Establece políticas de calidad, medioambientales y de seguridad.

Agiliza el comercio.

¿Qué se Normaliza?

El campo de actividad de las normas es tan amplio como la propia diversidad de productos o

servicios, incluidos sus procesos de elaboración.

Así, se normalizan los Materiales (plásticos, acero, papel, etc.), los Elementos y Productos (tornillos,

televisores, herramientas, tuberías, etc.), Métodos de Ensayo, Temas Generales ( Medio ambiente,

calidad del agua, reglas de seguridad, estadística, unidades de medida, etc.), Gestión y

Aseguramiento de la Calidad, Gestión medioambiental (gestión, auditoría, análisis del ciclo de vida,

etc.), Gestión de prevención de riesgos en el trabajo (gestión y auditoria), etc.

Clases de Normas que existen.

Los documentos normativos pueden ser de diferentes tipos dependiendo del organismo que los haya

elaborado.

En la clasificación tradicional de normas se distinguen entre:

Las normas nacionales, son elaboradas, sometidas a un período de información pública y

sancionadas por un organismo reconocido legalmente para desarrollar actividades de

normalización en un ámbito nacional.

En España, estas normas son las normas UNE, aprobadas por AENOR, que es el organismo

reconocido por la Administración Pública española para desarrollar la actividades de

normalización.

Normas regionales, son elaboradas en el marco de un organismo de normalización regional,

normalmente de ámbito continental, que agrupa a un determinado número de Organismos

Nacionales de Normalización. Las más conocidas, aunque no las únicas, son las normas

europeas elaboradas por los Organismos Europeos de Normalización (CEN, CENELEC, ETSI), y

preparadas con la participación de representantes acreditados de todos los países miembros.

AENOR es el organismo nacional de normalización español, miembro de CEN y CENELEC y,

por lo tanto, la organización a través del cual se canalizan los intereses y la participación de los

agentes socioeconómicos de España en la normalización europea.

Normas Internacionales, tienen características similares a las normas regionales en cuanto a su

elaboración, pero se distinguen de ellas en que su ámbito es mundial. Las más representativas

por su campo de actividad son las normas CEI/IEC (Comité Electrotécnico Internacional) para el

área eléctrica, las UIT/IUT (Unión Internacional de Telecomunicaciones) para el sector de las


telecomunicaciones y las normas ISO (Organización Internacional de Normalización) para el

resto.

AENOR, también es miembro de ISO y CEI y, por lo tanto, es la organización a través de la cual

se canalizan los intereses y la participación de los agentes socioeconómicos de España en la

normalización Internacional.

Modelo de Normalización para Bases de Datos Relacionales.

La teoría que vamos a describir fue diseñada por Codd en 1970 y persigue reducir las anomalías en

la gestión de una base de datos relacional.

La Normalización es el proceso de transformación de las complejas presentaciones de usuarios y los

almacenamientos de datos en conjuntos estables de estructuras de datos de menor tamaño. Además

de ser más sencillas, tales estructuras son más estables. Las estructuras de datos normalizados son

más fáciles de mantener.

Al comenzar, ya sea con la presentación del usuario o con el almacenamiento de datos diseñados

para un diccionario de datos, el analista normaliza una estructura de datos en tres (o cinco) pasos.

Cada paso involucra un importante procedimiento de simplificación de la estructura de datos.

La relación (estructura) derivada de la presentación del usuario o del almacenamiento de datos,

generalmente se encontrará no normalizada.

Base no normalizada.- Inicialmente se parte de un diseño de relaciones que no cumple ninguna

condición de antemano. A la base formada por estas relaciones se la denomina base no normalizada.

Los pasos o reglas de los cuales está compuesto la Normalización de datos se denominan Formas

Normales y son:

Primera Forma Normal.-

Esta primera etapa del proceso incluye la eliminación de grupos repetidos. Se dice que una base de

datos relacional está en la primera forma normal cuando todas sus relaciones cumplen la propiedad

de que cada tupla no contiene elementos que sean conjuntos. Es decir, cada dato de la relación es

elemental.

En otras palabras podríamos decir que una tabla está en primera forma normal si y solo si todos los

atributos que la componen son atómicos. Ejemplos:

Tabla Clientes:

Cédula Nombres Apellidos Nombre Madre Ocupación M Teléfono 0702801597 Ariana Camila Lara Zea Andy Zea Abogada 915427,

912043

0706874654 María Isabel Maldonado Cruz María Cruz Profesora 04431735

0702589635 Juan Carlos Vega Alvarez Nancy Alvarez Secretaria 094598695,

912861


En la tabla anterior podemos observar, que el campo teléfono contiene grupos de datos, en

este caso la tabla clientes no se encuentra en primera forma normal.

Tabla Uno:

SN Status Ciudad PN Cantidad

S1 20 Veracruz P1 300




S2 10 Colima P1 300

S2 10 Colima P2 400

S3 10 Colima P3 200



Esta tabla contiene grupos de datos repetidos, por lo tanto tampoco está en primera forma normal

Para corregir las tablas que no se encuentran en la primera forma normal, debemos:

Crear una nueva entidad, que contendrá todos los atributos de la entidad que no cumplen con la

primera forma normal. Esta nueva entidad (tabla) tendrá la relación N, por lo tanto se debe aplicar la

regla general y se pasará a la nueva entidad la llave principal de la tabla que tiene la relación 1.

Las tablas del ejemplo anterior quedarán, para el caso del primer ejemplo:

La tabla Clientes tendrá los siguientes campos:

*Cédula, Nombres, Apellidos, Nombre Madre, OcupaciónM.

Cédula Nombres Apellidos Nombre Madre Ocupación M

0702801597 Ariana Camila Lara Zea Andy Zea Abogada

0706874654 María Isabel Maldonado Cruz María Cruz Profesora

0702589635 Juan Carlos Vega Alvarez Nancy Alvarez Secretaria

La tabla teléfonos contendrá:

Teléfono, Cédula

Cédula Teléfonos

0702801597 915427

0702801597 912043

0706874654 04431735

0702589635 094598695

0702589635 912861

En el caso del otro ejemplo tenemos:

Teléfonos Clientes

SP UNO


La tabla Uno estará conformada por:

*SN, Status, Ciudad

SN Status Ciudad

S1 20 Veracruz

S2 10 Colima

S4 20 Veracruz

La tabla SP estará constituida por:

PN, Cantidad, SN

SN PN Cantidad

S1 P1 300

S1 P2 200

S1 P3 400

S1 P4 200

S2 P1 300

S2 P2 400

S3 P3 200

S4 P1 200

S4 P2 100

Observemos que pasa ahora que la tabla está normalizada, y en la tabla que no esta normalizada, al:

Insertar S5

Eliminar el embarque S3/P3

Cambiar la ciudad de S1, de Veracruz a Tampico

Segunda Forma Normal.-

El segundo paso asegura que todos los atributos no-llave, o sin llave, sean completamente

dependientes de la llave del criterio primario. Se dice que una base de datos relacional está en

segunda forma normal cuando todas sus relaciones cumplen las siguientes propiedades:

Esta en primera forma normal, y todo atributo de cada tupla depende fundamentalmente de cada

clave posible. Es decir, cuando todos los datos de cada tupla se pueden identificar cómodamente.

En otras palabras se podría decir que, una relación está en la segunda forma normal (2FN) si y solo

si esta en 1FN, y cada atributo que no es llave depende funcionalmente de la llave primaria

completa. Ejemplos:

Tabla Clientes:

Cédula Nombres Apellidos Nombre Madre OcupaciónM

0702801597 Ariana Camila Lara Zea Andy Zea Abogada

0706874654 María Isabel Maldonado Cruz María Cruz Profesora

0702589635 Juan Carlos Vega Alvarez Nancy Alvarez Secretaria


La tabla clientes está en primera forma normal. En esta tabla encontramos que la clave o llave

principal completa es el campo cédula, y adicionalmente tenemos que los campos nombre madre y

ocupación no dependen funcionalmente de la llave primaria, por lo tanto la tabla no esta en segunda

forma normal.

Si verificamos y estudiamos estos dos campos veremos que, el campo ocupación M corresponde al

trabajo que desempeña la madre del cliente y no el cliente en sí, por lo tanto, en este caso depende

del nombre de la madre

Tabla SN:

SN Status Ciudad

S1 20 Veracruz

S2 10 Colima

S4 20 Veracruz

La tabla SN está en primera forma normal. Para tener una idea más clara de lo que podría se una

dependencia funcional, observemos que sucede en esta tabla si:

Queremos tener registrado que a la ciudad de Monterrey le corresponde un Status 50.

Queremos borrar la entidad para S5 en la Relación (Tabla) Uno

Deseamos Cambiar el Status de Veracruz de 20 a 30.

Para el último caso, nos vemos en la obligación de buscar todas los registros en cuyo campo ciudad

esté “Veracruz”, lo cual indica que el campo Status depende del campo ciudad y no de la llave

principal de la tabla SN que es el campo SN. En este caso la tabla SN no está en segunda forma

normal.

En el caso de que una tabla no se encuentre en 2FN, tenemos que el siguiente paso sería eliminar

todas las dependencias parciales y colocarlas en otra entidad (o tabla). Esta nueva entidad tendrá la

relación 1, y la entidad anterior la relación N.

Las tablas del ejemplo quedaría de la siguiente manera:

Tabla clientes:

En donde la tabla Madre tendrá los siguientes campos:

Nombre Madre, Ocupación.

(Definimos la llave principal a Nombre Madre).

Nombre Madre OcupaciónM

Andy Zea Abogada

María Cruz Profesora

Nancy Alvarez Secretaria

Cliente Madre


La tabla Cliente tiene:

Cédula, Nombres, Apellidos, Nombre Madre (como Llave ajena),

Cédula Nombres Apellidos Nombre Madre

0702801597 Ariana Camila Lara Zea Andy Zea

0706874654 María Isabel Maldonado Cruz María Cruz

0702589635 Juan Carlos Vega Alvarez Nancy Alvarez

Tabla SN:

La nueva tabla ciudad contiene los siguientes campos:

Ciudad y Status (El campo Ciudad pasa a ser llave principal)

Status Ciudad

10 Colima

20 Veracruz

La tabla SN queda así:

SN y Ciudad (como llave ajena)

SN Ciudad

S1 Veracruz

S2 Colima

S4 Veracruz

Tercera Forma Normal.-

El tercer paso elimina cualquier dependencia transitoria. Una dependencia transitoria es aquella en

la cual sus atributos no-llave son dependientes de otros atributos no-llave.

Decimos que una base de datos relacional está en tercera forma normal cuando todas sus tablas

verifican las siguientes propiedades:

Esta en segunda forma normal, todo atributo de cada tupla no es transitivamente dependiente de cada

clave posible. Con ello se elimina el riesgo de que, al actualizar un atributo, no se actualice los que

dependen transitivamente de él.

Entonces, podríamos decir, que una tabla está en la tercera forma normal si y sólo sí esta en 2FN y

cada atributo que no sea llave (atributos no fundamentales) depende funcionalmente, en forma

directa de la llave primaria (Independencia Mutua).

Con ello se elimina el riesgo de que, al actualizar un atributo, no se actualice los que dependen

transitivamente de él.

SN Ciudad


Nota: Los dos ejemplos anteriores ya están en tercera forma normal, por ello vamos a utilizar otro

ejemplo:

La tabla Embarque.

CustNo. CustName OrdNo. OrDate Shipto ShipDate CustZip

E118 Jhon Smith 030 24/01/97 CA 02/02/97

130 16/05/97 MI 21/05/97 11030

A021 Jane Williams 090 27/01/98 WA 29/01/98

290 10/02/98 CA 15/02/98

800 20/02/98 WA 21/05/98

810 12/05/98 MI 27/05/98 96090

Como podemos observar en el ejemplo, la tabla contiene algunos atributos o campos que tienen

longitud variable, es decir que estos atributos dependen transitivamente de la llave primaria de la

tabla (en el ejemplo la llave primaria es OrdNo.).

Para poner a la tabla en 3FN, hay que eliminar los atributos transitorios, esto lo podemos conseguir

descomponiendo la tabla en dos:

Tabla clientes:

Esta tabla contendrá los siguientes atributos:

CustNo., CustName, CustZip (en donde CustNo será la llave principal).

CustNo. CustName CustZip

E118 Jhon Smith 11030

A021 Jane Williams 96090

Tabla Embarque:

Estará compuesta por:

OrdNo, OrDate, Shipto, ShipDate, CustNo (como llave ajena)

OrdNo. OrDate Shipto ShipDate CustNo.

030 24/01/97 CA 02/02/97 E118

130 16/05/97 MI 21/05/97 E118

090 27/01/98 WA 29/01/98 A021

290 10/02/98 CA 15/02/98 A021

800 20/02/98 WA 21/05/98 A021

810 12/05/98 MI 27/05/98 A021

Como podemos observar, la nueva tabla contendrá los atributos transitorios, y tendrá la relación 1, la

tabla de donde provienen estos atributos tendrá la relación N.

Embarque Clientes


Cuarta Forma Normal.-

El cuarto paso elimina dependencias de valores múltiples. Las dependencias de valores múltiples

conducen a anomalías de modificación.

Se dice que una base de datos está en 4FN sólo y solo si está en 3FN, y cada uno de los atributos de

la tupla no poseen dependencias de valores múltiples con la llave principal.

Vamos a considerar el siguiente ejemplo: Tenemos Estudiantes, y supongamos que los estudiantes

pueden inscribirse en varias especialidades y de la misma forma participar en distintas actividades.

Para ello hemos considerado establecer las siguiente entidad, atributos. En donde la única clave es la

combinación de los atributos (SID, Especialidad, Actividad).

Tabla Estudiantes:

SID Especialidad Actividad

100 Música Natación

100 Contabilidad Natación

100 Música Tenis

100 Contabilidad Tenis

150 Matemáticas Carrera

En los datos de la tabla tenemos que, la estudiante 100 tiene su especialidad en Música y

Contabilidad y también participa en Natación y Tenis. El estudiante 150 sólo tiene especialidad en

Matemáticas y participa en Carrera.

¿Cuál es la relación entre SID y Especialidad? No es una dependencia funcional, porque los

estudiantes pueden tener distintas especialidades. Un valor único de SID puede poseer muchos

valores de Especialidad. Esto también se aplica a la relación entre SID y Actividad.

Podemos observar adicionalmente en la tabla de ejemplo que existe redundancia en los datos. (por

eso se dijo anteriormente que puede conllevar a errores o anomalías en la modificación).

La estudiante 100 tiene 4 registros, cada uno de los cuales muestra una de sus especialidades junto

con una de sus actividades. Si los datos se almacenaran con menos hileras: si hubiera sólo dos

tuplas, uno para música y natación, y otro para contabilidad y tenis, las implicaciones serían

engañosas. Parecería que la Estudiante 100 sólo nadó cuando tenía música como especialidad y jugó

tenis sólo cuando tenía Contabilidad como especialidad, esa interpretación no es lógica. Sus

especialidades y sus actividades son independientes entre sí. Para prevenir tales engañosas

conclusiones se almacenan todas las combinaciones de especialidades y actividades.

Entonces podríamos decir que, existe una dependencia de valores múltiples cuando una afinidad

(tabla) tiene al menos tres atributos, dos de los cuales poseen valores múltiples y sus valores

dependen sólo del tercer atributo. En otras palabras en la afinidad R (A,B,C) existe una dependencia

de valores múltiples si A determina valores múltiples de B, A determina valores múltiples de C, y B

y C son independientes entre sí.


Para evitar tales anomalías, se deben eliminar las dependencias de valores múltiples. Esto se hace

construyendo dos afinidades (tablas), donde cada una almacena datos para solamente uno de los

atributos de valores múltiples. Ejemplo:

Tabla Especialidad:

SID Especialidad

100 Música

100 Contabilidad

150 Matemáticas

Tabla Actividad:

SID Actividad

100 Esquí

100 Natación

100 Tenis

150 Carrera

Nota: Observe, que ahora la tabla Actividad contiene un nuevo registro que es, la estudiante 100

hace Esquí. Y este registro no interviene o no causa anomalías en las modificaciones, ni

redundancias.

Quinta Forma Normal.-

La Quinta forma normal se refiere a dependencia que son extrañas. Tiene que ver con afinidades

(tablas) que pueden dividirse en subafinidades (como se ha venido haciendo), pero que no pueden

reconstruirse. La condición bajo la cual surge esta situación, no tiene un significado intuitivo

preciso. No se sabe cuales son las consecuencias de tales dependencias, incluso si tiene

consecuencias prácticas.

Conclusión:

Cada una de las formas normales que se han analizado, fueron identificadas por investigadores que

encontraron anomalías con algunas afinidades que estaban en una forma normal inferior: la

detección de anomalías de modificación con afinidades en la segunda forma normal condujeron a la

definición de la tercera forma normal. Aunque cada forma normal resolvía algunos de los problemas

identificados, con la forma normal anterior; nadie podía saber cuáles problemas todavía no habían

sido identificadas. Con cada paso, se avanzaba a una definición estructurada de las bases de datos,

nadie podía garantizar que no se encontrarían más anomalías. Existe una forma normal que

garantiza que no habrá anomalías de ningún tipo. Cuando se ponen las afinidades en esta forma, se

sabe que no pueden ocurrir ni siquiera las extrañas anomalías asociadas con la quinta forma normal,

esta forma normal se denomina Dominio / Clave.


Historia de SQL

La historia de lenguaje de SQL está íntimamente interrelacionada con el desarrollo de la base de

datos relacional fue desarrollado originalmente por el Dr. Ef T. Codd quien era un investigador de

IBM. En 1970 el Dr. Codd publicó un articulo titulado "Un modelo relacional de datos para grandes

bancos de datos compartidos". Que esquematizaba una teoría matemática de cómo los datos podían

ser manipulados y almacenados utilizando una teoría tabular.

El articulo desencadenó una racha de investigaciones basado en los datos incluyendo importantes

proyectos de investigación de IBM el objetivo de este proyecto denominado SYSTEM/R fue

demostrar la operatibilidad del concepto relacional y proporcionar alguna experiencia a la

implementación efectiva de una DBMS relacional, el trabajo comenzó en 1978 en Sta. Teresa de

IBM en San José California.

En 1974-75 la primera fase del proyecto produjo un mínimo prototipo de un DBMS relacional a más

de este prototipo el proyecto incluía trabajos sobre lenguaje de consulta, unos de estos lenguajes fue

denominado SEQUEL que es un acrónimo de STRUCTURE ENGLISH QUERY LANGUAJE.

En 1976-77 este prototipo fue reescrito desde principio, la nueva implementación soportaba

consultas multitablas y permitía que varios usuarios compartieran el acceso a los datos.

En 1978-79 IBM realizó instalaciones para clientes para evaluación, esta primera instalaciones de

usuarios proporcionaron cierta experiencia efectiva en el uso de SYSTEM/R y de un lenguaje de

base de datos en que había sido renombrado como SQL.

En 1979 el proyecto de investigación llegó al final e IBM concluyó que esta base de datos no

solamente era factible sino que podía ser una base de datos comercial y útil.

Primeros Productos Relacionales

La publicidad referente al SYSTEM/R atrajo la atención de un grupo de ingenieros en Mom la Park

California que decidió que las investigaciones de IBM presagiaban un mercado comercial para la

base de datos relacional y en 1977 formaron una compañía llamada RELATIONAL SOFTWARE

INC. para construir un DBMS basado en SQL, el producto de nombre ORACLE apareció en 1979 y

se convirtió en el primer DBMS comercialmente disponible y se ejecutaba en minicomputadores.

SQL

Es una herramienta para organizar gestionar y recuperar datos almacenados en una base de datos

informática. El nombre SQL es una abreviatura de Structured Query Languaje que significa

Lenguaje de Estructura de consulta. Como su nombre lo indica SQL es un lenguaje que se puede

utilizar para interaccionar con una base de datos. En efecto SQL trabaja con un tipo especifico de

base de datos llamada Base de Datos Relacionada.

El sistema de Gestión de Base de datos. DBMS


El nombre SQL es realmente y en cierta medida inapropiado ya que es mucho más que una

herramienta de consulta aunque ese fue su propósito original ya que el recuperar datos sigue siendo

una de sus funciones más importantes. SQL se utiliza para controlar todas la funciones que

proporciona a sus usuarios incluyendo:

DEFINICION DE DATOS.- Es decir que permite a los usuarios definir la estructura y la

organización de los datos almacenados y las relaciones entre ellos.

RECUPERACION DE DATOS.- Permite a un usuario o a un programa de aplicación recuperar los

datos almacenados en la base de datos y utilizarlos.

MANIPULACION DE DATOS.- Permite a un usuario o a un programa de aplicación actualizar la

base de datos añadiendo nuevos datos, suprimiendo datos antiguos y modificando datos previamente

almacenado.

CONTROL DE ACCESO.- SQL puede ser utilizado para restringir la capacidad de un usuario para

recuperar añadir y modificar datos protegiendo asilos datos almacenados frente a accesos no

autorizados.

CONPARTICION DE DATOS.- Se utiliza para coordinar la compartición de datos por parte de

usuarios concurrentes asegurando que no interfieran uno con otro.

INTEGRIDAD DE DATOS.- SQL define restricciones de integridad en la base de datos

protegiéndola. contra corrupciones de integridad ocasionadas por actualizaciones indebidas o fallos

inconsistentes.

Por tanto SQL es un lenguaje completo de control, interactualización con sistemas de gestión de la

base de datos. SQL no es realmente un lenguaje informático completo tal como Cobol, Fortran o C

ya que no dispone de las sentencias GO TO para bifurcaciones ni de las sentencia DO o FOR para

interacciones en vez de ello SQL es un sublenguaje de base de datos consistentes en mas de 30

sentencias especializadas para tareas de gestión de base de datos.

Estas sentencias se incorporaran a otros lenguajes como Cobol, Fortran o C para extender ese

lenguaje y permitir el acceso a la base de datos. Actualmente SQL se ha convertido en el lenguaje de

base de datos estándar y aproximadamente 100 productos de gestión de base de datos soportan SQL.

Petición SQL

Datos

Base de

Datos

DBMS


SQL no es un lenguaje estructurado en vez de ello sus sentencias se asemejan a frases en ingles

completadas con palabras de relleno que no añaden nada al significado de la frase pero que hace que

se lea mas naturalmente, es un potente lenguaje y relativamente fácil de aprender:

El Papel De SQL

SQL no es un producto autónomo, tampoco es en si mismo un sistema de gestión de base de datos.

SQL es parte integral de el Sistema manejador de Base de Datos, es decir un lenguaje o una

herramienta que pueden comunicarse con el DBMS.

La máquina de base de datos es el corazón del DBMS responsable de estructurar, almacenar y

recuperar realmente los datos en el disco. Acepta peticiones SQL de otras consulta interactivas desde

los programas escritos por el usuario e incluso de otros sistemas informáticos.

SQL juega muchos papeles diferentes:

SQL COMO LENGUAJE DE CONSULTAS INTERACTIVAS.- Los usuarios escriben ordenes

SQL dentro de un programa SQL interactivo para recuperar datos y mostrarlos a la pantalla

proporcionando una herramienta fácil de utilizar para realizar las consultas.

SQL COMO UN LENGUAJE DE PROGRAMACION DE BASE DE DATOS.- Las

programadores insertan ordenes SQL en sus programas de aplicación para acceder a los datos de la

base tanto los programas escritos por el usuario como los programas de utilidades de la base de datos

tales como los escritores de informes y las herramientas de entradas de datos utiliza esta técnica para

el acceso de la base de datos.

SQL COMO LENGUAJE ADMINISTRADOR DE LA BASE DE DATOS.- El administrador de

base de datos responsable de gestionar en una minicomputadora o un maxicomputador utiliza SQL

para definir la estructura de la base de datos y para controlar el acceso de los datos almacenados.

SQL ES UN LENGUAJE DE CLIENTE SERVIDOR.- Los programas de computador personal

utiliza los SQL para comunicarse sobre una red de área local con servidores de base de datos que

almacena los datos compartidos.

SQL ES UN LENGUAJE DE BASE DE DATOS DISTRIBUIDAS.- Los sistemas de gestión de la

Base de datos distribuida utiliza SQL para ayudar a distribuir datos a través de muchos sistemas

informáticos conectados. Se puede conectar a varios servidores.

SQL COMO LENGUAJE DE PASARELA DE LA BASE DE DATOS.- En una red informática con

una mezcla de diferentes productos DBMS se conecta con otro producto. SQL es una herramienta

potente y útil para enlazar Personas y sistemas informáticos a los datos almacenados en una base de

datos relacional.

Características Y Beneficios De SQL

SQL es a la vez un lenguaje fácil de aprender y un lenguaje completo para gestionar datos. Entre las

principales colocamos:

1. Independencia de Vendedores.


2. Portabilidad a través del sistema

3. Los estándares SQL

4. EL apoyo de IBM

5. Fundamento Relacional

6. Estructura de alto nivel en Ingles.

Estas son una de las razones por lo que SQL se ha convertido como la herramienta estándar para

gestionar datos en minicomputadoras, computadoras personales o maxicomputadoras.

1. INDEPENDENCIA DE VENDEDORES.- SQL es ofertado por los principales vendedores

de DBMS y ningún nuevo producto de base de datos puede tener éxito sin el soporte de SQL. Una

base de datos basada en SQL y los programas que la utilizan transferirse de un DBMS a DBMS de

otro vendedor con mínimo esfuerzo de conversación y poco reentrenamiento de personal.

2. POTABILIDAD A TRAVES DEL SISTEMA INFORMATICO.- Las aplicaciones basadas

en SQL que comienzan en sistemas monousuarios pueden ser transportados a sistemas mayores de

minicomputadores y maxicomputadores cuando crecen los datos procedentes de la base de datos

corporativa pueden ser extraídos y remitidos a base de datos departamentales o personales Y

finalmente los computadores personales pueden ser utilizados para construir prototipos de

aplicaciones basados en SQL antes de transferir a un sistema multiusuario.

3. ESTÁNDARES SQL.- El ANSI o American National Standard Institute y la 150 International

Estándar Organization. Han publicado conjuntamente un estándar oficial para SQL también es un

estándar del US federal information procesing estándar o también conocido como fits lo que lo

convierte en un requerimiento esencial para los grandes contratos informáticos.

En Europa x/open que es un standard para un entorno de aplicación por cable basado en UNIX, han

añadido a SQL como el standard para accesar a la base de datos. La OPEN SOFTWARE

FUNDATION (0SF). Que sea un grupo de vendedores de UNIX. Tiene a SQL como un estándar de

acceso de base de datos. Estos estándares sirven como sello oficial de aplicación.

4. APOYO DE IBM.- SQL fue inventado originalmente por investigadores de IBM y desde

entonces se convirtió en su producto estratégico. SQL es un componente esencial del SYSTEM

APLICATION ARCHITECTURE (SAA), la marca de IBM para la compatibilidad & sus diversos

líneas de productos. El soporte de SQL está disponible a todos sus cuatro líneas o familias de

sistemas que están incluidos en SAA como: - los computadores personales - los sistemas & media

rango AS/400 y los maxicomputadores que ejecutan los sistemas operativos MVS y VM.

5. FUNDAMENTO RELACIONAL.- SQL es un lenguaje de base de datos que se ha

popularizado con este modelo. La estructura tabular de filas y columnas de una base de datos

relacional es intuitiva para los usuarios y hace que el lenguaje de SQL se mantenga simple y fácil de

entender.

7. ESTRUCTURA DE ALTO NIVEL EN INGLES.- La sentencia de lenguaje son fases sencillas

en inglés que lo hace fácil de entender.


SQL Y La Conexión En Red

La creciente popularidad de conexión de computadores por red durante los años anteriores tuvo un

fuerte impacto en la gestión de base de datos y ha dado a SQL una nueva prominencia.

Conforme las redes pasan ha ser más comunes las aplicaciones se han convertido tradicionalmente

en un Minicomputador o en un maxicomputador central se están transfiriendo a redes de área local

con estaciones de trabajo de sobremesa y servidores. En estas redes SQL juega un papel esencial

como vinculo entre una aplicación que corre en una estación de trabajo y el DBMS que gestiona los

datos comparativos en el servidor.

Arquitectura Centralizada

Esta arquitectura es la mas tradicional y es utilizada por DB2 (manejador de datos) o SQL/DS

y las bases de datos sobre minicomputadores tales como Oracle o Ingres cuya arquitectura es:

En esta arquitectura el DBMS y los datos físicos residen ambos en un sistema maxicomputador

central junto con el programa de aplicación que acepta entradas desde el terminal de usuarios y

muestra los datos en la pantalla del usuario.

Ejemplo: Supongamos que el usuario teclea una consulta explora la base de datos para acceder a

cada uno de los registros de datos del disco, calcula el promedio y muestra los resultados en la

pantalla del terminal. Tanto el procesamiento de la aplicación como el procesamiento de la base de

datos se produce en el computador central y como el sistema es compartido por muchos usuarios,

cada usuario experimenta una degradación del rendimiento cuando el sistema tiene una carga fuerte.

Arquitectura de Servidor de Archivos

La introducción de las computadoras personales y las redes de área local condujo al desarrollo de la

arquitectura servidora de archivos. En esta arquitectura una aplicación que se ejecuta en un

computador personal puede acceder de forma transparente a datos localizados en un servidor de

archivos que almacena los archivos compartidos.

Cuando una aplicación en el computador personal solicita datos de un archivo compartido, el

software de la red recupera automáticamente el bloque solicitado del archivo en el servidor. Varias

bases de datos de entre las que se incluye DBASE III, RBASE y PARADOX, soportan esta

estrategia servidora de archivos, donde cada computador personal ejecuta su propia copia del

software DBMS. Esta arquitectura es la siguiente:

Termina

l

Aplicació

n DBM

S

Base de

Datos

Teclas

Caracteres

(Datos)


Para consultas típicas, estas arquitecturas proporcionan facilidad ya que el usuario dispone de la

potencia completa de un computador personal, ejecutando su propia copia del DBMS. Sin embargo,

considerando la consulta que requiere una exploración secuencial de la base de datos, el DBMS

solicita respectivamente bloques de datos de la base de datos, la cual está localizada físicamente a

través de la red, en el servidor de archivos, eventualmente todos los bloques de archivos están

solicitados y enviados a través de la red. Obviamente esta arquitectura provee un tráfico fuerte de

red y un bajo rendimiento para consultas de este tipo.

Arquitectura Cliente Servidor

En los noventa, una nueva clase de computación conquistó a la empresa de hoy y el futuro en todas

las industrias, pequeñas o grandes. La tecnología cliente/servidor de proceso distribuido.

Debido a que la tecnología cliente/servidor integra islas de tecnología existentes (mainframes, minis,

PCs, Macs, Estaciones de Trabajo, etc.) para darles más utilidad y proporcionar a la organización

información precisa a nivel personal, departamental, empresarial, local y global.

En esta arquitectura los computadores personales están combinados en una red de área local junto

con un servidor de base de datos que almacena las base de datos compartidas y tiene la siguiente

arquitectura

Se denomina arquitectura cliente, donde el cliente es la máquina solicitante (computador personal,

estación de trabajo) y el servidor es la máquina proveedora. El cliente suministra la interfase del

usuario y realiza una o la mayor parte del procesamiento de aplicación, el servidor mantiene las

Aplicació

n

DBMS

Software

de red

PC

Base

de Dato

s

Petición de E/S de

disco

Bloques de disco (Datos)

Aplicación

DBMS

PC

Base

de

Datos

Petición de SQL

Datos


bases de datos y procesa las solicitudes del cliente para extraer o actualizar los datos de la base

correspondiente.

El servidor además controla la integridad y seguridad de la aplicación. (Adviértase la diferencia con

procesamiento centralizado, donde los terminales no inteligentes, no procesamiento, se conectan a un

mini o un mainframe).

La arquitectura cliente servidor reduce el tráfico de red y divide la carga de trabajo de la base de

datos.

Las funciones de intensiva relación con el usuario tales como el manejo de la entrada y visualización

de los datos se concentran en el PC; las funciones intensivas en el proceso de datos tales como la

entrada y salida de archivos, se concentran en el servidor de la base de datos, así mismo como el

procedimiento de consulta en el servidor que es lo mas importante en el gráfico.

La arquitectura cliente/servidor a recibido gran atención con la introducción a las redes PC basadas

en 0S2, SQL SERVER, servidor ORACLE para OS/2, DBASE IV, DB2, Delphi, PowerBuilder,

SQL Microsoft, FoxPro y SQL BASE.

Las funciones del DBMS están divididas en dos partes

Los frontales.- también denominados FRONT END de base de datos, deben contener

aplicaciones tales como herramientas de consultas interactivas, escritores de informes y de

programas de aplicación, Herramientas Case, Lenguajes de 4ta. Generación (4GL’s como Cobol,

Pascal, etc.), Usuarios finales, estos se ejecutan en el computador personal.

La Maquina de Soporte.- o BACK END de la base de datos que almacena y gestiona los datos, se

ejecuta en el servidor, es en esencia el DBMS, sus componentes y algunos otros modelos más,

aquí se realiza las siguientes funciones: compactación de memoria, Técnicas de acceso,

Seguridad, Operaciones Directas.

SQL es un lenguaje de dase de datos estándar y permite la comunicación entre las herramientas

frontales y la máquina de soporte que constituye esta arquitectura.

Además, SQL proporciona interfaces bien definidos entre los problemas frontales y de soporte,

comunicando las peticiones de acceso a la base de datos de una manera diferente.

Consideramos una vez más la consulta que solicita el número medio de pedidos, en la arquitectura

cliente servidor, la consulta, viaja a través de la red hasta el servidor de base de datos como una

petición SQL la máquina de base de datos envía de vuelta a través de la red una única contestación

en la petición inicial y la aplicación frontal la muestra en la pantalla del PC.

Principales Comandos SQL

CREATE TABLE .- Crea una tabla que tiene los campos especificados.


Sintaxis

CREATE TABLE NombreTabla1

(NombreCampo1 TipoCampo [(nAnchoCampo [, nPrecisión])]

[NULL | NOT NULL]

[, NombreCampo2 ...] )

Argumentos

NombreTabla1 Especifica el nombre de la tabla que desea crear.

(NombreCampo1 TipoCampo [(nAnchoCampo [, nPrecisión])] Especifica el nombre, el tipo, el

ancho y la precisión del campo (el número de lugares decimales), respectivamente.

Una tabla puede contener hasta 255 campos (250 campos dependiendo del DBMS). Si hay uno o

más campos que permiten valores nulos, el límite se reduce a 254 campos.

TipoCampo es una sola letra que indica el tipo de datos del campo (dependiendo del DBMS, puede

variar, algunos podrían necesitar que se escribiera el nombre completo del tipo de dato). Algunos

tipos de datos de campo necesitan que especifique nAnchoCampo o nPrecisión, o ambos.

La siguiente tabla enumera los valores para TipoCampo y si se necesita indicar nAnchoCampo y

nPrecisión (la tabla hace referencia a algunos tipos de datos de Visual FoxPro).

Tipo nAncho nPrecisión Descripción

C n - Campo de caracteres de ancho n

D - - Date

T - - DateTime

N n d Campo numérico de ancho n con d decimales

F n d Numérico flotante de ancho n con d decimales

I - - Integer

L - - Logical

nAnchoCampo y nPrecisión se pasan por alto para los tipos D, T, I, L. nPrecision tiene como valor

predeterminado cero (ningún lugar para decimales) si no se incluye nPrecision para los tipos N o F.

NULL Admite valores nulos en el campo. Si uno o más campos pueden contener valores nulos, el

número máximo de campos que puede contener la tabla disminuye en uno, de 255 a 254. NOT

NULL Impide valores nulos en el campo.

Ejemplo de CREATE TABLE - SQL (Comando)

En estos ejemplos, se utiliza el comando CREATE TABLE para crear las tablas llamadas (Salesman,

Customer, y Orders).

* Crear una tabla llamada salesman con dos campos

CREATE TABLE salesman ;

(SalesID c(6) , SaleName C(20))


* Crear una tabla customer con 4 campos, en donde se incluye el campo SalesID de la tabla

Salesman

CREATE TABLE customer ;

(SalesID c(6), ;

CustId i , ;

CustName c(20) , ;

SalesBranch c(3))

* Crear una tabla Orders con 4 campos en donde se incluye el campo CustID de la tabla customer

CREATE TABLE orders ;

(OrderId i , ;

CustId i, ;

OrderAmt n(4), ;

OrderQty i )

Nota: Todas las sentencias SQL deben ser escritas en una sola línea, por motivos de apreciación o

de orden, se puede dividir la sentencia en varias líneas, siempre y cuando todas las líneas lleven al

final el punto y coma (;) excepto la última línea de la sentencia. Este punto y coma indica al DBMS,

que no ejecute aún el comando debido a que continúa en la siguiente línea.

SELECT .- Formato Básico.- Recupera datos de una o más tablas.

Sintaxis

SELECT [ALL | DISTINCT]

[Alias.] Elemento_Selección [AS Nombre_Columna]

[, [Alias.] Elemento_Selección [AS Nombre_Columna] ...]

FROM [NombreBaseDatos!]Tabla [Local_Alias]

Argumentos

SELECT Especifica los campos, constantes y expresiones que se mostrarán en el resultado de la

consulta.

ALL Forma predeterminada, se muestran todas la filas del resultado de la consulta.

DISTINCT Excluye duplicados de cualquier fila del resultado de la consulta.

Nota Puede utilizar DISTINCT únicamente una vez por cláusula SELECT.

Alias. Califica nombres de elementos coincidentes. Cada elemento que especifique con

Elemento_Selección genera una columna de los resultados de la consulta. Si dos o más elementos

tienen el mismo nombre, incluya el alias de la tabla y un punto antes del nombre del elemento para

impedir la duplicación de las columnas.

Elemento_Selección especifica un elemento a incluir en el resultado de la consulta. Un elemento

puede ser uno de los siguientes:

El nombre de un campo de una tabla de la cláusula FROM.


Una constante especificando que el mismo valor constante ha de aparecer en cada fila del

resultado de la consulta.

Una expresión que puede ser el nombre de una función definida por el usuario (FDU).

AS Nombre_Columna Especifica el título de una columna en el resultado de la consulta. Esta

opción resulta muy útil cuando Elemento_Selección es una expresión o contiene una función de

campo y desea dar un nombre significativo a la columna. Nombre_Columna puede ser una expresión

pero no puede contener caracteres (por ejemplo, espacios) que no estén permitidos para nombres de

campos de tablas.

FROM Enumera las tablas que contienen los datos que obtuvo la consulta.

Ejemplos de SELECT - SQL (Comando)

Los siguientes ejemplos ilustran la utilización de las funciones definidas por el usuario con SELECT

- SQL:

SELECT * FROM salesman

Dentro de este ejemplo el asterisco (*) representa a todos los campos de los cuales está compuesto

una tabla, por lo tanto muestra todos los campos de la tabla salesman permitiendo ver la información

que estos contienen.

SELECT customer.company ;

FROM customer

En el Ejemplo se muestran los nombres de todas las compañías en customer (un campo de una

tabla).

SELECT DISTINCT customer.company ;

FROM customer

En este Ejemplo se muestran los nombres de todas las compañías en customer, sin que existan

registros duplicados.

SELECT UPPER(CustName) AS NameList, CustID ;

FROM customer

El ejemplo muestra los nombres de customer en mayúsculas y llama NameList a la columna de

salida. UPPER es una función de Visual Fox Pro, así mismo podemos utilizar cualquier tipo de

función dentro del comando SELECT.

SELECT cedula, nombre, Suel+(Com*10/100) AS SueldoNeto FROM empleados

Visualizará los campos nombre, cédula y una columna que contendrá la suma del campo sueldo y el

10 % de las comisiones de la tabla empleados.

SELECT SUM(OrderAmt) AS TotAmt, AVG(OrderQyt) AS ProQyt, ;

COUNT(*) AS CantOrd, MAX(OrderAmt) AS MaxAmt,


MIN(OrderAmt) AS MinAmt FROM Orders

El ejemplo utiliza las funciones estadísticas SUM (Sumar una columna), AVG (Obtener el promedio

de una columna), MAX (Obtener el valor máximo de una columna), MIN (Obtener el valor mínimo

de una columna), COUNT (La cantidad de registros que posee esa columna) para presentar la

información de la tabla orders

ALTER TABLE - SQL (Comando).- Modifica mediante programa la estructura de una tabla.

Sintaxis

ALTER TABLE NombreTabla1

ADD | ALTER [COLUMN] NombreCampo1

TipoCampo [(nAnchoCampo [, nPrecisión])]

[NULL | NOT NULL]

– O bien –

ALTER TABLE NombreTabla1

[DROP [COLUMN] NombreCampo3]

[RENAME COLUMN NombreCampo4 TO NombreCampo5]

Argumentos

NombreTabla1 Especifica el nombre de la tabla cuya estructura se desea modificar.

ADD [COLUMN] NombreCampo1 Especifica el nombre del campo que se desea agregar.

ALTER [COLUMN] NombreCampo1 Especifica el nombre de un campo existente que se desea

modificar.

TipoCampo [(nAnchoCampo [, nPrecisión])] Especifica el tipo de campo, el ancho de campo y la

precisión (número de lugares decimales) de un campo nuevo o modificado.

NULL | NOT NULL Admite valores nulos en el campo. Si uno o más campos pueden contener

valores nulos, el número máximo de campos que puede contener la tabla se reduce en uno, de 255 a

254.

DROP [COLUMN] NombreCampo3 Especifica un campo que se desea eliminar de la tabla.

RENAME COLUMN NombreCampo4 TO NombreCampo5 Permite cambiar el nombre de un

campo de la tabla. NombreCampo4 especifica el campo cuyo nombre ha sido cambiado.

NombreCampo5 especifica el nombre nuevo para este campo.

Precaución: Tenga cuidado al cambiar el nombre de los campos de la tabla; es posible que las

expresiones de índice, las reglas de validación, los comandos, las funciones, etc. hagan referencia a

los nombres originales de los campos.

Comentarios


ALTER TABLE puede regenerar la tabla creando un nuevo encabezado de tabla y anexando

registros en este encabezado. Por ejemplo, modificar el tipo o el ancho de un campo pueden originar

la regeneración de una tabla.

Ejemplos de ALTER TABLE - SQL (Comando)

ALTER TABLE customer ;

ADD COLUMN fax2 c(20) NOT NULL

Este ejemplo agrega una nueva columna (campo) a la tabla customer, que se denomina fax2, va a ser

de tipo carácter con un tamaño de 20, no aceptará valores nulos.

ALTER TABLE customer

ALTER COLUMN cust_id c(11) ;

Este ejemplo modifica el tamaño del campo cust_id que se encuentra en la tabla customer

ALTER TABLE customer;

ALTER COLUMN fax2 NULL;

ALTER COLUMN fax2 c(15).

En el ejmplo se está cambiando 2 características del campo fax2, primero modifica este campo para

que acepte valores nulos, y después cambia el tamaño del mismo campo, note que para cada

característica de un campo necesita una Cláusula ALTER COLUMN.

ALTER TABLE customer;

RENAME COLUMN fax2 TO telfax

En este ejemplo, estamos modificando el nombre del campo de fax2 a telfax

ALTER TABLE customer ;

DROP COLUMN telfax

Con esta sentencia estamos borrando el campo telfax de la tabla customer.

INSERT - SQL (Comando) .- Añade un registro al final de una tabla que contiene los valores de

campo especificados.

Sintaxis

INSERT INTO nombre_dbf [(fnombre1 [, fnombre2, ...])]

VALUES (eExpresión1 [, eExpresión2, ...])

Argumentos

INSERT INTO nombre_dbf Especifica el nombre de la tabla a la que se añadirá un registro.

nombre_dbf puede incluir una ruta de acceso y puede ser una expresión de nombre.


[(fnombre1 [, fnombre2 [, ...]])] Especifica los nombres de los campos del nuevo registro donde se

insertan los valores.

VALUES (eExpresión1 [, eExpresión2 [, ...]]) Especifica los valores de campo que se insertan en el

nuevo registro. Si omite los nombres de los campos, debe especificar los valores de campo en el

orden definido por la estructura de la tabla.

Ejemplos de INSERT - SQL (Comando)

En los siguientes ejemplos se agrega un registro en la tabla employee y salesman.

INSERT INTO employee (emp_no, fname, lname, officeno) ;

VALUES (3022, "John", "Smith", 2101)

INSERT INTO salesman

VALUES (‘123’, ‘Jane With B.’)

Nota: Con la sentencia INSERT INTO, se puede agregar un registro a la vez, cabe recalcar que al

momento de colocar los valores en la cláusula VALUES, debemos seguir las reglas de acuerdo al

tipo de dato que estemos utilizando, por ejemplo: si el campo es de tipo carácter debemos colocar

comillas o apostrofes alrededor del dato, así: “texto”, si el dato es de tipo numérico simplemento

colocamos la información: 93, si el dato es de tipo lógico podrá contener dos valores: verdadero (.V.)

o falso (.F.), si es de tipo Fecha o FechaHora, este dato debe ir entre llaves: {01/05/99}. Estas reglas

pueden varias de acuerdo al DBMS que estemos utilizando.

UPDATE - SQL (Comando).- Actualiza registros de una tabla con nuevos valores.

Sintaxis

UPDATE [NombreBaseDatos1!]NombreTabla1

SET Nombre_Columna1 = eExpresión1

[, Nombre_Columna2 = eExpresión2 ...]

WHERE CondiciónFiltro1 [AND | OR CondiciónFiltro2 ...]]

Argumentos

[NombreBaseDatos1!]NombreTabla1 Especifica la tabla en la que se actualizan registros con

valores nuevos.

NombreBaseDatos1! Especifica el nombre de base de datos no actual en la que se encuentra la

tabla. Es necesario incluir el nombre de la base de datos en la que se encuentra la tabla si no es la

base de datos actual. Incluya el delimitador signo de exclamación (!) después del nombre de base de

datos y antes del nombre de tabla.

SET Nombre_Columna1 = eExpresión1

[, Nombre_Columna2 = eExpresión2] Especifica qué columnas están actualizadas y sus

nuevos valores. Si se omite la cláusula WHERE, se actualizará cada fila de la columna con el mismo

valor.


WHERE CondiciónFiltro1 [AND | OR CondiciónFiltro2 ...]] Especifica los registros que se

actualizan con valores nuevos.

CondiciónFiltro Especifica los criterios que deben satisfacer los registros para actualizarse con

nuevos valores. Puede incluir tantas condiciones de filtro como desee, conectándolas con el operador

AND o con OR. También puede emplear el operador NOT para invertir el valor de una expresión

lógica, o utilizar EMPTY( ) para comprobar si hay campos vacíos.

Comentarios

UPDATE - SQL sólo puede actualizar registros en una sola tabla.

Ejemplo de UPDATE - SQL (Comando)

Observación: Después de ejecutar cada uno de las sentencias UPDATE, consulte la tabla con el

comando SELECT para comprobar los cambios que se realizan en la misma.

UPDATE orders;

SET OrderAmt = 100

Este ejemplo modifica el valor de la columna OrderAmt (todos los registros) a 100 dentor de la tabla

orders

UPDATE orders;

SET OrderAmt = 80, ;

OrderQty = 20

Con esta sentencia modificamos el valor de las columnas OrderAmt y OrderQty a 80 y 20

respectivamente, en todos los registros de la tabla orders.

UPDATE orders;

SET OrderAmt = 90;

WHERE CustID = 123

El comando del ejemplo anterior, modificará en la tabla orders, el valor de la columna OrderAmt,

pero sólo en aquellos registros cuyo campo CustID contiene el valor de 123.

UPDATE orders;

SET OrderQty=OrderAmt*2;

WHERE OrderID = 146 OR CustID = 143

El ejemplo anterior modificará la columna OrderQty colocando el valor de OrderAmt por 2, en

aquellos registros cuyo campo Order ID es igual a 146 o si el campo CustId es igual a 143.

DELETE - SQL (Comando) .- Marca registros para eliminarlos (en otros DBMS se borra

directamente).

Sintaxis


DELETE FROM [NombreBaseDatos!]NombreTabla

[WHERE CondiciónFiltro1 [AND | OR CondiciónFiltro2 ...]]

Argumentos

FROM [NombreBaseDatos!]NombreTabla Especifica la tabla en la que se marcan registros para

eliminar.

NombreBaseDatos! especifica el nombre de una base de datos. Incluya el delimitador signo de

exclamación (!) después del nombre de base de datos y antes del nombre de tabla.

WHERE CondiciónFiltro1 [AND | OR CondiciónFiltro2 ...] Especifica que Visual FoxPro sólo

marca algunos registros para eliminar.

CondiciónFiltro especifica los criterios que deben satisfacer los registros para marcarlos para

eliminación. Puede incluir tantas condiciones como desee, conectándolas con el operador AND u

OR. También puede emplear el operador NOT para invertir el valor de una expresión lógica o

utilizar EMPTY( ) para comprobar si hay campos vacíos.

Comentarios

En Visual Fox Pro, los registros marcados para eliminación no se eliminan físicamente de la tabla

hasta que se emita el comando PACK. Los registros marcados para eliminación pueden recuperarse

(quitarles la marca) con RECALL.

Ejemplo de DELETE - SQL (Comando)

Observación: Después de ejecutar cada uno de las sentencias DELETE, consulte la tabla con el

comando SELECT para comprobar los cambios que se realizan en la misma.

DELETE FROM orders

Este ejemplo marcará todos los registros de la tabla, para borrardo.

DELETE FROM orders WHERE OrderAmt = 0

El ejemplo marcará para borrado todos los registros cuyo campo OrderAmt contenga el valor de 0.

Nota: Observe que al hacer un SELECT a la tabla, en los registros que fueron marcados, al lado

izquierdo de la ventana aparece rellenado con el color negro.

SELECT - SQL (Comando) - Cláusulas Adicionales.

La sentencia SQL, SELECT tiene cláusulas adicionales que permiten optimizar el funcionamiento

del comando y de esta forma realizar una recuperación de la información óptima.

Sintaxis Completa

SELECT [Alias.] Elemento_Selección [AS Nombre_Columna]

[, [Alias.] Elemento_Selección [AS Nombre_Columna] ...]


FROM [NombreBaseDatos!]Tabla [Local_Alias]

[[INNER | LEFT [OUTER] | RIGHT [OUTER] | FULL [OUTER] JOIN

NombreBaseDatos!]Tabla [Alias_Local]

[ON CondiciónCombinación …]

[[INTO Destino]

| [TO FILE NombreArchivo [ADDITIVE] | TO PRINTER [PROMPT]

| TO SCREEN]]

[WHERE CondiciónCombinación [AND CondiciónCombinación ...]

[AND | OR CondiciónFiltro [AND | OR CondiciónFiltro ...]]]

[GROUP BY ColumnaGrupo [, ColumnaGrupo ...]]

[HAVING CondiciónFiltro]

[UNION [ALL] SELECTCommand]

[ORDER BY Elemento_Orden [ASC | DESC] [, Elemento_Orden [ASC | DESC] ...]]

Argumentos

INNER JOIN Especifica que el resultado de la consulta contenga sólo filas para una tabla con la

que coincidan una o varias filas en otra tabla.

LEFT [OUTER] JOIN Especifica que el resultado de la consulta contenga todas las filas de la tabla

a la izquierda de la palabra clave JOIN y sólo las filas que concuerden procedentes de la tabla a la

derecha de la palabra clave JOIN. La palabra clave OUTER es opcional; se puede incluir para

resaltar que se ha creado una combinación externa.

RIGHT [OUTER] JOIN Especifica que el resultado de la consulta contenga todas las filas desde la

tabla hasta la derecha de la palabra clave JOIN y sólo las filas que concuerden desde la tabla hasta la

izquierda de la palabra clave JOIN. La palabra clave OUTER es opcional; puede incluirse para

resaltar la creación de una combinación externa.

FULL [OUTER] JOIN Especifica que el resultado de la consulta contenga todas las filas,

concuerden o no, de ambas tablas. La palabra clave OUTER es opcional; se puede incluir para

resaltar que se ha creado una combinación externa.

ON CondiciónCombinación Especifica las columnas según las cuales se combinan las tablas.

Ejemplos (JOIN):

Use Left Outer Join

Este ejemplo une dos tablas en el campo custid y preserva las filas que no concuerden de la tabla

a la izquierda. La tabla customers es unida con la tabla orders en la columna custid de cada tabla.

Todos los clientes (customers) aparecen en el conjunto resultante, hayan o no hayan realizado

una orden.

SELECT customers.custid, customers.custname,orders.orderid,orders.orderamt;

FROM customers LEFT OUTER JOIN orders;

ON customers.custid = orders.custid

Use Inner Join


Utilizaremos el ejemplo anterior con la cláusula Inner Join, lo que hará es unir las dos tablas en el

campo custid, mostrará registros de una tabla que contengan uno o más registros en la otra.


FROM customers INNER JOIN orders;


Use Full Outer Join

Este ejemplo mostrará todos los clientes y sus respectivas ordenes, también mostrará cualquier

cliente así no haya realizado ninguna orden.


FROM customers FULL OUTER JOIN orders;


Use Right Outer Join

Este ejemplo une dos tablas en el campo custid, y preserva las filas que no concuerdan con la

tabla a la derecha. La tabla clientes es unida a la tabla orders en la columna custid de cada tabla.

Todas las ordenes aparecen en el conjunto resultante, pertenezcan o no a un cliente.


FROM customers RIGHT OUTER JOIN orders;


INTO Destino Determina donde se almacenan los resultados de la consulta. Si incluye una cláusula

INTO y una cláusula TO en la misma consulta, la cláusula TO se pasará por alto. Si no incluye la

cláusula INTO, los resultados de la consulta se mostrarán en una ventana (En visual Fox Pro). Los

resultados de la consulta pueden dirigirse también a la impresora o a un archivo mediante la cláusula

TO.

Destino puede ser uno de los siguientes:

CURSOR NombreCursor, que almacena los resultados de la consulta en un cursor. Si especifica

el nombre de una tabla abierta, Visual FoxPro generará un mensaje de error. Después de que se

ejecute SELECT, el cursor temporal permanecerá abierto y estará activo pero solamente para

lectura. Una vez que cierre este cursor temporal, se borrará.

Ejemplo:

SELECT * FROM customers INTO CURSOR myquery

Nota: El comando SELECT por omisión envia el resultado a una tabla temporal en memoria

(cursor) denominada Consulta.


DBF | TABLE NombreTabla [DATABASE NombreBaseDatos [NAME NombreLargoTabla]]

que almacena el resultado de la consulta en una tabla (queda almacenado físicamente en el

disco). Si no ha especificado ninguna extensión, Visual FoxPro dará una extensión .DBF a la

tabla. La tabla permanecerá abierta y activa después de ejecutar SELECT.

Incluya DATABASE NombreBaseDatos para especificar una base de datos a la que se agregará

la tabla. Incluya NAME NombreLargoTabla para especificar un nombre largo para la tabla. Los

nombres largos pueden contener un máximo de 128 caracteres y pueden utilizarse en lugar de

nombres cortos en la base de datos.

Ejemplo:

SELECT * FROM customers INTO CURSOR temp

TO FILE NombreArchivo Si incluye una cláusula TO pero no una cláusula INTO, podrá dirigir el

resultado de la consulta a un archivo de texto ASCII llamado NombreArchivo.

Ejemplo:

Select * from customers TO FILE listaclientes

ADDITIVE añade la salida de la consulta al contenido existente del archivo de texto especificado en

TO FILE NombreArchivo.

Ejemplo:

Select * from customers TO FILE listaclientes

En este ejemplo se añadirá el resultado del segundo select al archivo que contenía el resultado del

primer select.

TO PRINTER [PROMPT] Dirige la salida de la consulta a una impresora. Utilice la cláusula

PROMPT opcional para que aparezca en pantalla un cuadro de diálogo antes de que empiece la

impresión. En este cuadro de diálogo podrá modificar la configuración de la impresora. Los valores

de la impresora modificables dependen del controlador de impresora instalado en este momento.

Sitúe la palabra clave PROMPT inmediatamente después de TO PRINTER.

Ejemplo:

Select * from customers TO PRINTER

TO SCREEN Dirige la salida de la consulta a la ventana principal de Visual FoxPro o a una

ventana definida por el usuario que esté activa.

Ejemplo:

Select * from customers TO SCREEN


WHERE Indica a Visual FoxPro que incluya únicamente ciertos registros en el resultado de la

consulta. WHERE es necesario para recuperar datos de varias tablas.

CondiciónCombinación, especifica los campos que vinculan las tablas de la cláusula FROM. Si

incluye más de una tabla en una consulta, deberá especificar una condición de combinación para

cada tabla después de la primera.

Las condiciones de combinación múltiple deben conectarse mediante el operador AND. Cada

condición de combinación tiene la forma siguiente:

NombreCampo1 Comparación NombreCampo2

NombreCampo1 es el nombre de un campo de una tabla, NombreCampo2 es el nombre de un campo

de otra tabla y Comparación es uno de los operadores siguientes:

Operador Comparación

= Igual

== Exactamente igual

LIKE SQL LIKE

<>, !=, # Distinto de

> Mayor que

>= Mayor o igual que

< Menor que

<= Menor o igual que

CondiciónFiltro Especifica los criterios que deben cumplir los registros para que se incluyan en el

resultado de la consulta. Una consulta puede incluir tantas condiciones de filtro como se deseen,

conectadas con el operador AND y OR. También puede utilizar el operador NOT para invertir el

valor de una expresión lógica o utilizar EMPTY( ) para comprobar si un campo está vacío.

CondiciónFiltro puede presentar una de estas formas:

Ejemplo 1

En el Ejemplo 1 se muestra la CondiciónFiltro en el formato de NombreCampo1 Comparación

NombreCampo2

customer.custid = orders.custid

Este tipo de filtro se utiliza cuando vamos a presentar información de dos o más tablas. El ejemplo

completo sería:

SELECT * from customer,orders;

WHERE customer.custid = orders.custid


Ejemplo 2

En el Ejemplo 2 se muestra CondiciónFiltro en el formato de NombreCampo Comparación

Expresión

payments.amount >= 1000

Si desearamos buscar todas las ordenes en donde se haya vendido más de 1000. El ejemplo se

presentaria así:

SELECT * FROM orders WHERE orderamt >= 1000

Ejemplo 3

En el Ejemplo 3 se muestra CondiciónFiltro en el formato de NombreCampo Comparación ALL

(Subconsulta)

Cuando la condición de filtro incluye ALL (Todos), el campo debe cumplir la condición de

comparación para todos los valores generados por la subconsulta antes de que se incluya el registro

en el resultado de la consulta.

El siguiente fragmento de un comando SELECT, busca comparar el contenido del campo company

sea igual con todos los resultados de la subconsulta obtenida por el SELECT dentro de los

parentesis.

company < ALL ;

(SELECT company FROM customer WHERE country = "Reino Unido")

Nota: No debemos olvidarnos que el resultado obtenido de la subconsulta debe coincidir en el tipo

de datos con el campo al que se lo está comparando.

Con la comparación ALL se puede utilizar cualquier operador de relación: =, <, >, >=, <=, <>.

Cuando estamos utilizando Subconsultas dentro de un comando SELECT, lo primero que se ejecuta

son estas subconsultas.

Podemos crear una Subconsulta dentro de otra Subconsulta. Como podemos observar, cada

subconsulta debe estar entre parentesis, estos parentesis son los que dan la prioridad de ejecución,

por lo tanto siempre se ejecutan los parentesis más internos hasta llegar al primer parentesis, igual

que en una expresión matemática.

Cada subconsulta puede ser una sentencia SELECT completa, es decir utilizar todas sus cláusulas.

Ejemplo 4

En el Ejemplo 4 se muestra CondiciónFiltro en el formulario de NombreCampo Comparación ANY |

SOME (Subconsulta)


Cuando la condición de filtro incluye ANY o SOME, el campo debe cumplir la condición de

comparación en al menos uno de los valores generados por la subconsulta.

El siguiente fragmento de un comando SELECT, pretende comparar que el valor del campo

company sea menor a cualquiera de los valores obtenidos en la subconsulta que se encuentra entre

parentesis para que la condición de cómo resultado verdadera.

company < ANY ;

(SELECT company FROM customer WHERE country = "Reino Unido")

Ejemplo 5

En el Ejemplo 5 se muestra CondiciónFiltro en el formulario de NombreCampo [NOT] BETWEEN

Inicio_Rango AND Fin_Rango

Este ejemplo comprueba si los valores del campo están dentro de un intervalo (rango) de valores

especificado.

customer.postalcode BETWEEN 90000 AND 99999

Si deseamos mostrar todos los registros en donde se hayan realizado ventas (orderamt) de 1000 a

1500 productos, el comando SELECT podría ser:

SELECT * FROM orders;

WHERE ordersamt BETWEEN 1000 AND 1500

Ejemplo 6

En el Ejemplo 6 se muestra CondiciónFiltro en el formulario de [NOT] EXISTS (Subconsulta)

Este ejemplo comprueba si al menos una línea cumple los criterios de la subconsulta. Cuando la

condición de filtro incluye EXISTS, la condición de filtro se evalúa como verdadera (.T.) a no ser

que la subconsulta sea un conjunto vacío.

EXISTS ;

(SELECT * FROM orders WHERE customer.postalcode = orders.postalcode)

Este ejemplo muestra los nombres de todas las empresas de CLIENTES.DBF con un código postal

que coincida con el código postal de la tabla FACTURAS.

SELECT empresa FROM clientes a WHERE ;

EXISTS (SELECT * FROM oficinas b WHERE a.cp = b.cp)

Ejemplo 7

En el Ejemplo 7 se muestra CondiciónFiltro en el formulario de NombreCampo [NOT] IN

Conjunto_Valor


Cuando una condición de filtro incluye IN, el campo debe contener uno de los valores antes de que

el registro se incluya en los resultados de la consulta.

customer.postalcode NOT IN ("98052","98072","98034")

Si deseamos mostrar las ordenes emitidas a los clientes 01,05,09 y 14; podríamos ejecutar la

siguiente sentencia:

SELECT * FROM orders WHERE custid IN (“01”,”05”,”09”,”14”)

Ejemplo 8

En el Ejemplo 8 se muestra CondiciónFiltro en el formulario de NombreCampo [NOT] IN

(Subconsulta)

Aquí, el campo debe contener uno de los valores devueltos por la subconsulta antes de que su

registro se incluya en los resultados de la consulta.

El siguiente fragmento, compara el campo custid de la tabla customer, con los valores resultantes de

la consulta entre parentesis, si el valor de custid coincide con alguno de los valores en la subconsulta,

devuelve el valor de verdadero.

customer.cust_id IN ;

(SELECT orders.cust_id FROM orders WHERE orders.city="Seattle")

Si necesitamos obtener los clientes que hayan hecho ordenes por más una cantidad mayor a 15000, la

sentencia SELECT podría ser:

SELECT * FROM custemers;

WHERE custid IN;

(SELECT custid FROM orders WHERE orderamt > 15000)

Ejemplo 9

En el Ejemplo 9 se muestra CondiciónFiltro en el formulario de NombreCampo [NOT] LIKE

cExpresión

customer.country NOT LIKE "Reino Unido"

Esta condición de filtro busca cada uno de los campos que coinciden con cExpresión.

Puede utilizar el signo de porcentaje (%) y subrayado ( _ ) como parte de cExpresión. El signo de

porcentaje representa a cualquier secuencia de caracteres desconocidos en la cadena. El subrayado

representa un solo carácter desconocido en la cadena.

Este ejemplo muestra todos los registros de CLIENTES que tengan un que comience por una C

mayúscula y tenga cualquier longitud.


SELECT * FROM customers a;

WHERE a.custname LIKE "C%"

Este ejemplo muestra todos los registros de CLIENTES que tengan un salesbranch que comience por

MA mayúscula seguido de un carácteres desconocido.

SELECT * FROM clientes a;

WHERE a.estado LIKE "MA _"

La cláusula WHERE acepta el operador ESCAPE para la CondiciónCombinación, lo que le permite

realizar consultas significativas sobre datos que contengan caracteres comodín _ y % de SELECT

- SQL.

La cláusula ESCAPE le permite especificar que se traten los caracteres comodín de SELECT - SQL

como si fueran caracteres literales. En la cláusula ESCAPE se especifica un carácter, el cual, cuando

se sitúa inmediatamente antes del carácter comodín, indica que se tratará al carácter comodín como a

un carácter literal.

En el Ejemplo demuestra cómo se puede realizar una consulta de datos que contenga signos de

porcentaje (%). Se colocará una barra inversa (\) antes del signo de porcentaje para indicar que

tendría que ser tratado como un literal, y la barra inversa se especifica como el carácter de escape en

la cláusula ESCAPE.

SELECT * FROM customer WHERE custname LIKE "%\%%" ESCAPE "\"

En el siguiente Ejemplo se demuestra cómo se puede realizar una consulta de datos que contenga

signos de subrayado (_). Se colocará una barra inversa (\) antes del signo de subrayado para indicar

que debería ser tratado como un literal, y se especificará la barra inversa como el carácter de escape

en la cláusula ESCAPE.

SELECT * FROM customer WHERE custname LIKE "%\_%" ESCAPE "\"

En el ejemplo, el carácter Escape se utiliza a sí mismo como un literal. El guión es tanto el carácter

escape como un literal. La consulta devuelve todas las filas en las que el nombre del cliente contiene

un signo de porcentaje seguido de un guión.

SELECT * FROM customer WHERE company LIKE "%-%--%" Escape "-"

GROUP BY ColumnaGrupo [, ColumnaGrupo ...] Agrupa las filas de la consulta basándose en los

valores de una o más columnas. ColumnaGrupo puede ser el nombre de un campo normal de una

tabla, o un campo que incluya una función de campo SQL, o una expresión numérica indicando la

posición de la columna en la tabla resultado (la columna más a la izquierda tiene el número 1).

Ejemplo:

SELECT * FROM order GROUP BY custid


Este ejemplo muestra los registros agrupados por el campo custid, es decir que mostrará un registro

por cada agrupación.

El ejemplo descrito a continuación mostrará el valor del campo custid, la suma de orderamt y

orderqty de todos los registros agrupados por custid.

SELECT custid, SUM(orderamt), SUM(orderqty) FROM order;

GROUP BY custid

HAVING CondiciónFiltro Especifica una condición de filtro que los grupos deben satisfacer para

quedar incluidos en el resultado de la consulta. HAVING debe utilizarse con GROUP BY. Puede

incluir tantas condiciones de filtro como se deseen, conectadas con el operador AND u OR. También

puede utilizar NOT para invertir el valor de una expresión lógica.

CondiciónFiltro no puede contener una subconsulta.

Puede utilizar alias locales y funciones de campo en la cláusula HAVING. Utilice una cláusula

WHERE para acelerar el rendimiento si su cláusula HAVING no contiene funciones de campo. No

olvide que la cláusula HAVING debería de aparecer antes de una cláusula INTO porque, de lo

contrario, se producirá un error de sintaxis.

Ejemplo:

SELECT custid, SUM(orderamt), SUM(orderqty) FROM order;

GROUP BY custid HAVING orderamt > 10000

ORDER BY Elemento_Orden Ordena el resultado de la consulta basándose en los datos de una o

varias columnas. Cada Elemento_Orden debe corresponder a una columna del resultado de la

consulta, y puede ser uno de los siguientes:

Un campo de una tabla FROM que también es un elemento de selección en la cláusula principal

SELECT (no en una subconsulta).

Una expresión numérica que indica la ubicación de la columna en la tabla resultante. (La

columna de la izquierda es la número 1.)

ASC Especifica un orden ascendente para los resultados de la consulta, de acuerdo con el elemento

o los elementos de orden, y es el valor predeterminado para ORDER BY.

DESC Especifica un orden descendente para los resultados de la consulta.

Los resultados de la consulta aparecerán desordenados si no especifica un orden con ORDER BY.

Ejemplo:

SELECT Custid, Custname FROM Customer;

ORDER BY custname DESC.


[UNION [ALL] ComandoSELECT] Combina el resultado final de una SELECT con el resultado

final de otra SELECT. De forma predeterminada, UNION comprueba el resultado combinado y

elimina las filas duplicadas. Puede utilizar paréntesis para combinar múltiples cláusulas UNION.

Utilice la palabra clave opcional ALL para impedir que UNION elimine filas duplicadas de los

resultados combinados.

Las cláusulas UNION siguen las reglas siguientes:

No puede utilizar UNION para combinar subconsultas.

La salida de ambos SELECT debe tener el mismo número de columnas.

Cada columna de los resultados de la consulta de un SELECT debe tener el mismo tipo de dato y

anchura que su columna correspondiente en el otro SELECT.

Únicamente el SELECT final puede tener una cláusula ORDER BY, que debe referirse a las

columnas de salida por su número. Si se incluye otra cláusula ORDER BY, afectará al resultado

completo.

También puede usar la cláusula UNION para simular una combinación externa.

Cuando combina dos tablas en una consulta, solamente se incluyen en la salida los registros que

tengan valores coincidentes en los campos de combinación. Si un registro de la tabla primaria no

tiene un registro correspondiente en la tabla secundaria, el registro de la tabla primaria no se incluye

en la salida. Una combinación externa le permite incluir todos los registros de la tabla primaria en la

salida, junto con los registros coincidentes de la tabla secundaria. Para crear una combinación

externa en Visual FoxPro, necesita utilizar un comando SELECT anidado, como en el siguiente:

Ejemplo:

SELECT customer.company, orders.order_id, orders.emp_id ;

FROM customer, orders ;

WHERE customer.cust_id = orders.cust_id ;

UNION ;

SELECT customer.company, " ", " " ;

FROM customer ;

WHERE customer.cust_id NOT IN ;

(SELECT orders.cust_id FROM orders)

Nota Asegúrese de incluir el espacio que aparece justo delante de cada punto y coma. De lo

contrario, recibirá un error.

La sección del comando situada antes de la cláusula UNION selecciona los registros de ambas tablas

que contienen valores coincidentes. Las empresas cliente que no tengan facturas asociadas no se

incluyen. La sección del comando situada tras la cláusula UNION selecciona los registros de la tabla

customer que no tienen registros coincidentes en la tabla orders.


En lo que respecta a la segunda sección del comando, observe lo siguiente:

La instrucción SELECT incluida entre paréntesis se procesa en primer lugar. Esta instrucción da

como resultado una selección de todos los números de clientes de la tabla orders.

La cláusula WHERE busca todos los números de cliente de la tabla customer que no están en la

tabla orders. Puesto que la primera sección del comando proporcionó todas las empresas que

tenían un número de cliente en la tabla orders, todas las empresas de la tabla customer están

incluidas en los resultados de la consulta.

Puesto que las estructuras de las tablas incluidas en UNION deben ser idénticas, hay dos

marcadores de posición en la segunda instrucción SELECT para representar orders.order_id y

orders.emp_id de la primera instrucción SELECT.

Nota: Los marcadores de posición deben ser del mismo tipo que los campos que representan. Si el

campo es de tipo Date, el marcador de posición deberá ser { / / }. Si el campo es de tipo Character, el

marcador de posición deberá ser la cadena vacía ("").

Comentarios

SELECT es un comando SQL que está incorporado en Visual FoxPro como cualquier otro comando

de Visual FoxPro. Cuando utiliza SELECT para componer una consulta, Visual FoxPro interpreta la

consulta y recupera los datos especificados de las tablas. Puede crear una consulta SELECT:

En la ventana Comandos

En un programa Visual FoxPro (como cualquier otro comando de Visual FoxPro)

El Diseñador de consultas

Una subconsulta, a la que se hace referencia en los argumentos siguientes, es un comando SELECT

dentro de otro SELECT y debe incluirse entre paréntesis. Puede tener múltiples subconsultas al

mismo nivel (es decir no anidadas, esto ocurre dentro de Visual FoxPro) en la cláusula WHERE. Las

subconsultas pueden contener múltiples condiciones de combinación.

Cuando se obtiene el resultado de una consulta, las columnas se denominarán según las siguientes

reglas:

Si un elemento seleccionado es un campo con un nombre único, el nombre de la columna de

resultado es el nombre del campo.

Si hay más de un elemento seleccionado con el mismo nombre, se añadirán un signo de

subrayado y una letra al nombre de la columna. Por ejemplo, si una tabla llamada Cliente tiene un

campo llamado CALLE, y una tabla llamada Empleados también tiene un campo llamado

CALLE, las columnas de resultado se llamarán Extensión_A y Extensión_B (CALLE _A y

CALLE _B). En el caso de un elemento seleccionado con un nombre de 10 caracteres, se


truncará el nombre para añadir el símbolo de subrayado y la letra. Por ejemplo, DEPARTMENT

se convertiría en DEPARTME_A.

Si un elemento seleccionado es una expresión, su columna de resultado se llamará EXP_A.

Cualquier otra expresión recibirá el nombre de EXP_B, EXP_C, y así sucesivamente.

Si un elemento seleccionado contiene una función de campo como, por ejemplo, COUNT( ), la

columna de resultado se llamará CNT_A. Si otro elemento seleccionado contiene SUM( ), su

columna de resultado se llamará SUM_B.

Dado que SQL se basa en la teoría de conjuntos matemática, se puede representar a cada tabla

con un círculo. La cláusula ON que especifica las condiciones de la combinación determina el

punto de intersección, el cual representa el conjunto de filas que coinciden.

En el caso de una combinación interna, la intersección tendrá lugar en el interior o en una parte

“interna” de los dos círculos.

Una combinación externa incluye tanto las filas coincidentes que se han encontrado en la sección

de intersección interna de las tablas, como las filas de la parte externa del círculo a la izquierda, o

a la derecha, de la intersección.

Importante: Tenga presente la siguiente información a la hora de crear condiciones de

combinación:

Si incluye dos tablas en una consulta y no especifica una condición de combinación, cada registro

de la primera tabla se combinará con cada registro de la segunda tabla hasta que surtan efecto las

condiciones del filtro. Una consulta tal puede producir unos resultados interminables.

Sea prudente al utilizar, en condiciones de combinación, funciones tales como DELETED( ),

EOF( ), FOUND( ), RECCOUNT( ), y RECNO( ), que aceptan un área de trabajo o un alias

opcional.

La inclusión de un alias o de un área de trabajo en dichas funciones puede producir resultados

inesperados. SELECT no utiliza sus áreas de trabajo; realiza lo equivalente a USE ... AGAIN.

Las consultas de una única tabla que utilizan estas funciones sin un área de trabajo o un alias

opcional, tendrán resultados correctos. De todas formas, las consultas de varias tablas que

utilicen dichas funciones (incluso sin un área de trabajo o un alias opcional) pueden tener

resultados inesperados.

Sea prudente al combinar tablas que contengan campos vacíos porque Visual FoxPro concuerda

campos vacíos. Por ejemplo:

Si combina CUSTOMER.ZIP e INVOICE.ZIP, y CUSTOMER contiene 100 códigos postales

vacíos e INVOICE contiene 400 códigos postales vacíos, el resultado de la consulta contendrá

40.000 registros más, como resultado de los campos vacíos. Use la función EMPTY( ) para

eliminar los registros vacíos del resultado de la consulta.


SQL Server.- Características:

Es un RDBMS (Relational Database Management System) de alto nivel en perfomance y

escalabilidad .

Integración con Windows NT, uniendo y fijando servicios como el Monitor de Tareas, el Visor

de Eventos. Un simple login de Windows NT para ambos, para la red y para SQL Server,

simplifica el manejo de los usuarios.

Se puede programar el servidor para resolver problemas comunes.

Soporta bases de datos muy grandes (250 campos por tabla y hasta 2.000.000 de tablas por base

de datos).

Provee replicación de datos a través del sistema.

Uno de los mejores desafíos para lo s usuarios de la arquitectura Cliente/Servidor es el manejo

central de múltiples servidores a través de empresa. SQL Server 6.5, maneja estos desafíos con un

sistema empresarial, un armazón administrativo llamado Distributed Management Framework

(DMF).

Herramientas de Administración de SQL Server.

SQL Server provee un numero de herramientas administrativas. Las herramientas son provistas

dependiendo en donde se realizó la instalación de SQL Server, en el cliente o en el servidor, y el

sistema operativo del computador. Estas herramientas son:

Herramientas Descripción

SQL Enterprise

Manager

Provee facilidad, para realizar un amplio manejo de la empresa,

desde un servidor o un cliente. Permite que usted ejecute tareas de

administración del sistema utilizando una interfaz gráfica. Usted

puede configurar servicios, manejar la base de datos y los objetos

de las bases de datos, fijar eventos, configurar y manejar

replicaciones, y hacer muchas cosas mas.

SQL Service

Manager

Usado para comenzar (Start), detener (Pause), continuar (Continue)

o finalizar (Stop) servicios de SQL Server (SQL Server y SQL

Excecutive)

ISQL/w Permite ingresar sentencias de transacción SQL y procedimientos

del sistema almacenados en una interfaz de consulta gráfica.

ISQL/w provee la capacidad para analizar consultas gráficamente.

SQL Security

Manager

Permite manejar las cuentas de usuarios de SQL Server que están

utilizando seguridad integrada con Windows NT.

SQL Trace Monitorea y graba la actividad de las bases de datos. Puede

mostrar o grabar un registro cronológico de todas las actividades

del servidor en tiempo real.

Alternativamente, crea filtros que enfocan las acciones de un

usuario en particular, aplicaciones, o servidores huésped. Puede

visualizar cualquier sentencia SQL y llamada de procedimientos

remotos (Remote Procedure calls, RPC) que son enviadas a


cualquier servidor.

SQL Client

Configuration

Utility

Configura el default de Net-Library y la información de conexión

de los clientes al servidor . También visualiza el número de

versión de DB-Library y Net-Library en su path.

SQL

Perfomance

Monitor

Integra el Monitor de Performance de Windows NT con SQL

Server, proporcionando sobre el minuto de actividad y estática de

ejecución.

Microsoft

Query

Permite al usuario, construir gráficamente consultas SELECT en

cualquier base de datos ODBC, incluyendo SQL Server. MS

Query puede visualizar un esquema básico de información acerca

de una base de datos. Es una herramienta de sólo lectura.

SQL Server

Web Assistant

Genere archivos con estándar HTML desde los datos de SQL

Server, utilizando consultas SELECT, stored procedures, o

extended stored procedures. La pagina Web generada puede ser

vista con cualquier Visor (Browser) HTML

El propietario (Owner) de la Base de Datos.

El propietario de la base de datos o Database Owner (DBO), es el creador de una base de datos. El

DBO tiene todos los privilegios en esa base de datos y determina el acceso y capacidades que son

proporcionadas a otros usuarios para esa base de datos. Cuando un DBO está dentro de otra base de

datos, el DBO es conocido por su nombre de usuario de base de datos. Es estado de DBO puede ser

reasignado a diferentes usuarios, sin embargo, solo un DBO puede existir. Solamente un login de

identificación puede ser el login de identificación DBO. Aunque otra identificación de login puede

ser apodado el DBO.

Estructura del Sistema utilizado en SQL Server (System Catalog).

Hay dos tipos de bases de datos: del sistema y de los usuarios. Ambos almacenan datos, pero SQL

Server utiliza las bases de datos del sistema para operar y manejar el sistema. El catalogo del

sistema consiste de tablas del sistema encontradas solamente en la base de datos master.

Bases de datos del Sistema.- Cuando instalamos SQL Server, cuatro bases de datos del sistema son

creadas: Master, model, tempdb y msdb.

Bases de datos del usuario.- Bases de datos que son creadas por el usuario. La base de datos

pubs, un ejemplo de base de datos que viene con el producto SQL Server, es un ejemplo de base de

datos del usuario.

Base de Datos Master.- Controla las bases de datos de los usuarios y la operación de SQL Server

como un conjunto. El tamaño por omisión de esta base de datos es 25 MB. Debido a la naturaleza crítica de

sus datos, a ningún usuario le es permitido accesar directamente a ella, es importante siempre tener un

respaldo actualizado de esta base de datos.

La base de datos master almacena los siguientes registros:

Cuentas de login


Procesos de ejecución

Mensajes de Error del sistema

Base de datos almacenadas en el servidor

Ubicación del almacenamiento de cada base de datos

Bases de datos disponibles y dispositivos de respaldos

Procedimientos almacenados del sistema, los cuales son utilizados primordialmente para la

administración del sistema

Base de Datos Model.- Esta base de datos provee una plantilla o prototipo de nuevas bases de datos.

(Esta es la base de datos que SQL Server copia cuando crea una nueva base de datos de usuario). De esta

forma, la base de datos model contiene las tablas del sistema (diccionario) que son utilizadas en cada base de

datos de los usuarios. Aquí es donde se colocan los ítems que usted quiere que aparezcan en todas las

subsiguientes bases de datos creadas. Algunos de los cambios hechos comúnmente a model son:

Adición de tipos de datos definidos por el usuario, reglas, valores por omisión o procedimientos

almacenados.

Adición de Usuarios, quienes estarán accesando a todas las bases de datos en un Servidor SQL.

Privilegios por omisión, particularmente para cuentas huésped, son establecidas en model.

Opciones de configuración de la base de datos.

El tamaño por omisión es 1 MB, para las bases de datos.

Base de datos tempdb.- Provee almacenamiento para tablas temporales y otros almacenamientos

temporales necesarios tales como resultados inmediatos de GROUP BY, ORDER BY, DISTINCT, y

cursores. Es creado automáticamente en el dispositivo Master durante la instalación de SQL Server. No se

necesitan permisos especiales para utilizar tempdb. Tiene las siguientes características:

Los contenidos son borrados cuando el usuario cierra la conexión a SQL Server, excepto para

tablas globales temporales. Cuando SQL Server es detenido, cada cosa de tempdb es borrada.

Todas las tablas temporales son almacenadas en tempdb

El tamaño por omisión es 2 MB.

Tempdb puede ser colocada en el RAM. Configurando el SQL Server.

Tempdb puede se alterada en RAM

Base de Datos msdb.- Esta base de datos es el soporte de SQL Executive Service. Este servicio es un

scheduler (fijador, calendario) que habilita actividades tales como replicación, task scheduling, y manejo de

alertas. La msdb contiene estas tablas del sistema, las cuales son específicas para esta base de datos:

Sysalert.- Almacena información acerca de todas la alertas definidas por el usuario. El SQL

Executive Service chequea para ver si hay entradas en esta tabla que es asociada con un grabador de

eventos en el Visor de Eventos del Servidor Windows NT. Si encuentra una alerta asociada,

entonces la alerta es encendida.

Sysbackupdetail.- Especifica un resumen de los dispositivos utilizados para respaldos.

Sysbackuphistory.- Especifica un resumen de cada operación de respaldo.


Syshisory.- Almacena información histórica cuando una alerta o tarea fue ejecutada (éxito y falla),

la identidad del operador a quién se envío un e-mail, el número de intentos para una tarea, y la fecha

y hora de ejecución.

Sysrestoredetail.- Especifica un resumen de los dispositivos utilizados para restauración.

Sysrestorehistory.- Especifica un resumen de cada operación de restauración.

Revisión del Diccionario de Datos

El diccionario de datos está compuesto por tablas del sistema que guardan la información referente a

los usuarios, las bases de datos, sus objetos, etc. para poder acceder a la información que se

encuentra en estas tablas utilizamos stored procedures preestablecidos en el sistema. Los nombres

de los stored procedures definidos en el sistema comienzan con las letras sp seguido de un subguion

y a continuación el nombre (ejemplo: sp_nombre). Antes de ejecutar el procedimiento nos debemos

colocar en la base de datos que deseamos obtener información. Los principales procedimientos son:

Sp_helpuser .- Muestra información acerca de los usuarios de la base de datos. Su sintaxis es:

sp_helpuser [username]

username Es un usuario de la base de datos actual. Si no se especifica el nombre, el procedimiento

muestra todos los usuarios de la base de datos actual.

Ejemplos

A. Lista todos los usuarios

sp_helpuser

B. Muestra la información de un simple usuario. Este ejemplo muestra la información acerca del

propietario de la base de datos.

sp_helpuser DBO

Tablas usadas: master.dbo.syslogins, sysalternates, sysusers

Sp_helpdb .- Muestra información acerca de una o todas las bases de datos. Su sintaxis es:

sp_helpdb [dbname]

dbname. Especifica la base de datos acerca de la cual se desea información.

Ejemplos

A. Ayuda de una base de datos.

sp_helpdb pubs


B. Ayuda sobre todas las bases de datos

sp_helpdb

Tablas usadas: spt_values, sysdatabases, sysdevices, syslogins, sysusages

Sp_help.- Muestra información acerca de los objetos de una base de datos o acerca de tipos de datos

definidos por los usuarios. Su sintaxis e:

sp_help [objname]

objname: es el nombre de cualquier objeto o tipo de dato definido por el usuario. Nombres de Bases

de datos no son aceptados.

Ejemplos:

A. Ayuda de todos los objetos.

sp_help

B. Ayuda de un objeto en particular.

sp_help publishers

Sp_columns.- Muestra información de la columna para un objeto en particular o de una objeto que

puede ser requerido en el ambiente actual. Su sintaxis es:

sp_columns object_name [, column_name]

object_name, es el nombre de la tabla que queremos la información. El nombre del objeto puede ser

una variable cuyo nombre debe tener máximo 32 caracteres. No se aceptan patrones de búsquedas.

column_name, especifica una columna específica, y es usado cuando sólo se necesita la información

de una columna. Si el nombre de la columna no es especificado, se mostrará la información de

todas las columnas.

Ejemplos:

A. Muestra la información de todos los campos:

sp_columns

Elementos del modelo de Datos.

Tablas.-

Ejemplo:

Member

Member_no Lastname Firstname Middle_i Photo

1001 Anderson Andrew A ---


1002 Barr Andrew R ---

1003 Barr Bill Null

1004 Hendson Jack Null ---

Una base de datos contiene muchas tablas. Cada tabla en una base de datos almacena información.

El ejemplo arriba, muestra la tabla de miembros (socios) en la base de datos de una librería. Cada

fila es un miembro individual y cada columna almacena información acerca de ese miembro.

Las tablas tienen las siguientes características:

Tienen un único nombre, usualmente identifica a la entidad. Los nombres de las tabla

comúnmente son en singular.

Las tablas están compuestas de filas (registros) y columnas (campos)

Cada fila describe una ocurrencia de una entidad.

Cada columna o campo describe un atributo de esa entidad.

La filas pueden estar en cualquier orden

Las columnas pueden estar en cualquier orden.

Restricción de las Tablas.- Cuando trabajamos con tablas dentro de una base de datos, debemos

asegurarnos que se cumplan las restricciones de las tablas. Consideremos las siguientes restricciones

cuando creamos tablas:

Los nombres de las tablas deben ser únicos dentro de una base de datos.

Los nombres de una columna deben ser únicos dentro de una tabla.

Las filas o registros deben ser únicos dentro de una tabla. En el caso de que una fila es definida

por una columna en especial, llamada llave primaria. Dos filas no deben tener el mismo valor

en esta columna. Por ejemplo si dos filas en la tabla miembros tienen el mismo número, sería

imposible decir cual fila actualmente representa al miembro.

Columnas Atómicas.- Son columnas que contienen valores o información que no puede ser

dividida en columnas más pequeñas. Si la información dentro de una columna puede ser dividida

dentro de múltiples partes utilizables, la columna debe ser redefinida como dos o más columnas.

Ejemplo:

Member

Member_no Name Photo

1001 Anderson, Allen A ---

1002 Allen, Andrew R ---

1003 Barr, Bill

Member

Member_no Lastname Firstname Middle-i Photo

1001 Anderson Allen A ---

1002 Allen Andrew R ---

1003 Barr Bill Null

Las ventajas de usar columnas atómicas son las siguientes:


Columnas son fáciles de actualizar.

Usted ha actualizado solamente un componente específico de la cadena, no la cadena completa. Por

ejemplo, la columna name podría contener tanto el apellido (last name) como el primer nombre (first

name), (Doe, Jane). Si Jane cambia su apellido a Green, el actualización debería ser name =

“Green, Jane). En esta actualización del primer nombre es cambiado innecesariamente. Si la

columna estuviera descompuesta la actualización debería ser lastname = ”Green” y el primer nombre

no debería ser cambiado.

Columnas son fáciles de consultar.

Al descomponer la información de las columnas dentro de componentes más pequeños, usted puede

referirse a ellos más fácilmente. Usted puede trabajar con un ítem determinado del dato cuando

consulta esa información. Se puede evitar utilizar funciones de caracteres de cadena que filtran los

datos de su columna.

Mantiene mejor la integridad de los datos.

Usted puede aplicar tipos de datos, valores por omisión, llaves, y reglas apropiados. También puede

indicar donde permite o no valores nulos a nivel de campo.

Restricciones de columnas.- En el diseño lógico de una base de datos, se puede configurar varias

restricciones sobre una columna dentro de una tabla. Estas restricciones permiten tener un control

sobre ciertos aspectos de la integridad de datos, poniendo requerimientos sobre los valores que son

permitidos.

Not Null (NN).- Not Null es una restricción que requiere una entrada dentro de una columna.

Cuando un NULL esta dentro de una columna, significa que el usuario o la aplicación no ha

realizado entrada de datos en esa columna. Un valor para la columna es desconocido o no es

aplicable. Null no es sinónimo de cero (un valor numérico) o blanco (un valor de caracter).

Además, valores nulos permiten distinguir entre una entrada deliberada de 0 o espacio en blanco, y

ninguna entrada.

No Duplicates (ND).- Otra restricción en una columna es prevenir valores duplicados. Con No

duplicates, cada entrada es única. Por ejemplo: en la tabla miembros, marque ND en la columna

Member_no para prevenir que dos miembros tienen el mismo número. Los valores duplicados no

son permitidos en una columna que únicamente identifica a las filas. Son implementadas para crear

una llave primaria, llave única, índice único.

No Changes (NC).- Es una restricción que previene que los valores en una columna sean

cambiados. Es implementado para utilizar referencias, permisos. La columna Member_no. Que

identifica de manera exclusiva a la fila es un buen ejemplo de una columna que debería tener la

restricción No Changes.


Primary Key (PK, Llave Primaria).- Es la columna o grupo de columnas que refuerza la integridad

de la entidad, asegurándose de que cada fila dentro de la tabla es única. Algunos requerimientos de las

llaves primarias incluyen:

Cada tabla debe tener una llave primaria.

Solamente puede haber una llave primaria por cada tabla.

Las llaves primarias no deben permitir valores nulos (NN) o duplicados (ND). Es recomendado

que no se le permitan hacer modificaciones (NC).

Foreign Key (FK, Llave ajena).- Una llave ajena hace referencia a una llave primaria de otra tabla.

Puede ser la llave primaria de la misma o de otra tabla. Una columna puede ser a la vez la llave primaria de

su propia tabla y la llave ajena de otra. Algunas ventajas de crear una llave ajena incluye:

SQL Server chequea el valor en la columna marcada FK contra el valor en la columna PK para

verificar que estos valores son consistentes (Legítimos).

Provee una unión entre las dos tablas

Refuerza la integridad referencial asegurándose de que cada valor en la columna FK es un PK

válido.

Distribución del Almacenamiento.- Definición del Almacenamiento de

Datos.

Cuando usted crea una base de datos, es importante que usted especifique exactamente la cantidad

de espacio distribuida para ello. Si usted distribuye demasiado espacio, usted malgastará espacio

del que podría ser usado por otra base de datos. Si usted distribuye espacio no suficiente, la base de

datos puede salirse del espacio de almacenamiento. (Sin embargo, es posible modificar el espacio

distribuido después de que las bases de datos han sido creadas).

Cuando usted crea una base de datos más larga que el espacio disponible, SQL Server distribuirá

tanto espacio como se pueda, redondeándolo lo más cerca de .5MB. Para asegurarse que la estructura

de los datos es válida cuando crea una base de datos, SQL Server asigna ceros a cada página del

disco. Esta operación es ejecutado en bloques de 64k.


SQL Server distribuye el espacio que usted a requerido en un modo ajustado basado en una jerarquía

que asegura una mejor ejecución. Los siguientes términos de almacenamiento en orden de

decrecimiento.

Dispositivos (Devices).- Dispositivos de Base de datos son archivos del sistema operativo. Ellos

pueden almacenar múltiples bases de datos, y partes de base de datos..

Bases de datos (Databases).- Son creadas en uno o más dispositivos. Cuando mas de un

dispositivo es usado, el dispositivo puede existir en discos duros separados.

Unidades de Distribución (Allocation Units).- Cuando una base de datos es creada, el espacio es

distribuido en ½ MB de incremento (256 paginas contiguas de 2 k) conocida como unidades de

distribución.

Extents (extensiones).- Una extensión es de 16 k (8 páginas contiguas de 2k). Cuando una tabla o

índice es creado, SQL Server distribuye una extensión. Cada objeto es distribuido en su propia

extensión; las extensiones jamás son compartidas. Debido a que hay 32 extensiones por cada

unidad de distribución, puede haber 32 objetos (tablas o índices) almacenados en esta unidad de

distribución.

Páginas (Page).- La unidad básica de almacenamiento es una página de 2K (2048 bytes).

Nota: La información de las bases de datos almacenadas, es listada dentro de la base de datos

master, utilizando la tabla sysusages. Cada fila representa un unidad de distribución contigua

asociada con una base de datos.

Dispositivos de Base de datos (Database Devices)

Los dispositivos son archivos que están en el disco duro, y que almacenan bases de datos,

transaction logs (historial de transacciones), y respaldos. Los dispositivos pueden ser

implementados de la siguiente manera:

Un dispositivo puede contener muchas bases de datos.

Una base de datos puede dividirse en muchos dispositivos, aún si los dispositivos son

almacenados en discos duros separados.


Es recomendable que una base de datos y su historial de transacciones se mantengan en

dispositivos separados.

Nombre lógico.- Es usado en una sentencia SQL que hace referencia al dispositivo. Los nombres

lógicos deben corresponder a las reglas de SQL Server para identificarlas, y deben estar encerradas

entre apóstrofes.

Tienen un tamaño entre 1 y 30 caracteres.

El primer caracter debe ser una letra o uno de los siguientes símbolos: _ @ #

Después del primer caracter, los identificadores pueden incluir letras, dígitos, o los símbolos #, $,

o _.

Los espacios no son permitidos en los identificadores a menos que las comillas sean utilizadas.

Palabras reservadas por SQL no deben ser utilizadas.

Nombre Físico.- La letra de la unidad, el path completo, y el nombre del archivo del dispositivo de

base de datos. Los paths para los dispositivos de las bases de datos deben seguir las reglas para los

paths del sistema operativo y los nombres de archivos. El nombre físico es como el sistema

operativo hace referencia al nombre del archivo representando al dispositivo. Por omisión el

nombre físico utiliza el nombre lógico.

Nota: Al momento de la instalación, tres dispositivos son creados: uno es el dispositivo de base de

datos master. El path físico para master por omisión es E:\mssql\data\master.dat (dentro del

servidor) con un tamaño mínimo de 25 MB, note que existe una carpeta denominada MSSQL que se

crea al instalar SQL Server, y una carpeta DATA que va a contener todos los archivos físicos de las

bases de datos. Se puede cambiar la unidad y directorio por omisión. Los otros dispositivos son el

MSDB.dat (6 MB) y el MSDBLOG.dat (2 MB).

Añadiendo un Dispositivo de Base de Datos.

Para añadir un dispositivo de Base de datos utilizamos la sentencia DISK INIT, esta instrucción crea

el archivo de dispositivo de base de datos y lo prepara para almacenamiento. Ingresa el nombre

físico y lógico del dispositivo en la tabla sysdevices en la base de datos master. Distribuye

previamente el almacenamiento al tamaño especificado (en bloques de 2K). Su formato es el

siguiente:

DISK INIT

NAME = ‘nombre_lógico’,

PHYSNAME = ‘nombre_físico’,

VDEVNO = numero_virtual_del_dispositivo,

SIZE = numero_de_bloques_2k

DISK INIT crea un dispositivo en el cual una o múltiples base de datos pueden ser colocadas,

dándole un nombre físico y un nombre lógico.

NAME, el nombre lógico de la base de datos.

PHYSNAME, el nombre físico y la localización del dispositivo de base de datos (incluye la ruta

completa).


VDEVNO, es el número virtual del dispositivo que identifica el dispositivo de la base de datos. Los

número válidos de dispositivos son del 0 al 255. El número de dispositivo 0 esta reservado para el

dispositivo de la base de datos master.

Ejecute DISK INIT una vez por cada nuevo dispositivo de base de datos. Esto puede ser hecho a

través de ISQL/w, el SQL Query Tools, o a través de SQL Enterprise Manager. Cada vez que DISK

INIT es ejecutado, una fila es añadida a la base de datos master en la tabla sysdevices.

Nota: Usted debe estar ubicado en la base de datos master para crear un dispositivo.

Ejemplo:

DISK INIT

NAME = ‘prueba’,

PHYSNAME = ‘E:\mssql\data\prueba.dat’,

VDEVNO = 1,

SIZE = 8142

DISK INIT

NAME = ’prueba_log’,

PHYSNAME = ‘E:\mssql\data\pruelog.dat’,

VDEVNO = 2,

SIZE = 2048

Nota: Para saber los números de dispositivos disponibles utilice la tabla sysdevices o al store

procedure sp_helpdevice. Si usted va a crear el dispositivo desde una máquina cliente, primero

debe crear una unidad de red (con la ruta completa \mssql\data\) y en el path hacer referencia a esa

unidad de red (Ejemplo, la unidad se llama D, entonces la ruta sería D:\nombrearchivo).

Manejo de dispositivos.

Utilizar un dispositivo por omisión y borrar dispositivos permite al DBA un manejo mejor de las

necesidades de almacenamiento en el servidor. Cuando una base de datos es creada y ningún

dispositivo es especificado, SQL Server automáticamente utiliza un dispositivo por omisión. El

dispositivo por omisión es especificado utilizado sp_diskdefault o a través de SQL Enterprise

Manager.

Configurando el Dispositivo de Base de Datos por omisión.

Considere lo siguiente cuando asigne un dispositivo por omisión:

El administrador del sistema (SA) puede configurar dispositivos por omisión para los usuarios,

para crean bases de datos utilizando el procedimiento sp_diskdefault.

El SA debe remover a master (que es el dispositivo por omisión asignado) y configurar un

número del dispositivo de base de datos por omisión para que el usuario pueda crear bases de

datos.


Si el dispositivo no es mencionado específicamente cuando crea una base de datos, SQL Server

buscara por espacio disponible en la lista de dispositivos por omisión.

Cualquier dispositivo puede ser un miembro de las lista por omisión y la lista puede contener

más de un dispositivo.

Los dispositivos por omisión son usados en orden alfabético.

La sintaxis del comando es:

Sp_diskdefault nombre_del_dispositivo , {defaulton | defaultoff}

Ejemplo: remover a master como default.

Sp_diskdefault master, defaultoff

Borrando un dispositivo de base de datos.

Borrar un dispositivo libera espacio de almacenamiento en el servidor, liberando el archivo

manejado y el número de dispositivo. Especificando la cláusula DELFILE, en la sintaxis de

sp_dropdevice, borrará el archivo físico del disco duro sin apagar SQL Server, de esta forma le

permitirá crear inmediatamente un nuevo dispositivo con ese mismo número de dispositivo y nombre

lógico. Los dispositivos pueden ser borrados utilizando sp_dropdevice o a través de SQL Enterprise

Manager.

La sintaxis de ap_dropdevices es:

Sp_dropdevice nombre_lógico [, DELFILE]

Ejemplo: borrar un dispositivo llamado TAPEDUM1

Sp_dropdevice TAPEDUM1

Ejemplo: borrando un dispositivo llamado prueba con su archivo físico.

Sp_dropdevice Prueba, DELFILE

Expandiendo Dispositivos de Base de Datos.

Si usted sobrepasa el espacio de un dispositivo de base de datos, el tamaño del dispositivo puede ser

expandido, utilizando la sentencia DISK RESIZE. El espacio adecuado debe estar disponible en el

medio de almacenamiento para acomodar el nuevo tamaño.

La sintaxis de esta sentencia es:

DISK RESIZE

NAME = nombre_logico,

SIZE = nuevo_tamaño

El nombre lógico es el nombre del dispositivo a ser cambiado de tamaño, el nuevo_tamaño es el

tamaño que tendrá ahora el dispositivo en páginas de 2K.


Ejemplo:

DISK RESIZE NAME = master, SIZE 15360

Este ejemplo cambia de tamaño al dispositivo master para tener un tamaño total de 30 MB.

DISK RESIZE puede ser utilizado en cualquier dispositivo de base de datos, incluyendo el

dispositivo Master. No es necesario reconstruir el dispositivo Master para ser incrementado el

tamaño.

La sentencia DISK RESIZE expande un dispositivo, no disminuye el tamaño de un dispositivo o

altera cualquier base de datos que reside en ese dispositivo. DISK RESIZE no puede ser utilizado

para dispositivos de backups o en dispositivos tempdb, cuando tempdb esta en el RAM.

Creación de una Base de Datos.

El Administrador del Sistema (SA) puede crear bases de datos con la sentencia CREATE

DATABASE. Solamente el SA puede tener o asignar permisos para usar esta sentencia, debido a

que CREATE DATABASE necesita conocer la distribución del almacenamiento.

Al crear bases de datos, las responsabilidades administrativas del SA incluyen:

Distribución del Almacenamiento (Storage Allocation).

Ser el único al que se le permite usar la sentencia CREATE DATABASE (esto protege a SQL

Server contra utilización indebida del espacio de almacenamiento).

Asignar este permiso (privilegio) a otros usuarios.

Crear nuevas bases de datos que son grabadas en las tablas sysdatabases y sysusages de la base

de datos master.

La sentencia CREATE DATABASE. .- Para crear una base de datos, debe estar ubicados en la

base de datos master, y debe tener el permiso de utilizar la sentencia CREATE TABLE. Se debe

definir el nombre de la base de datos, el o los dispositivos en los cuales residirá la base de datos, la

cantidad de espacio (en MB) requerida en cada dispositivo, Localización y tamaño (en MB) el

transaction log. Esta sentencia tiene la siguiente sintaxis:

CREATE DATABASE nombrebd

[ON {DEFAULT | dispositivodb} [= tamaño]

[, dispositivodb [= tamaño]] ... ]

[LOG ON dispositivolog [= tamaño]

[, dispositivolog [= tamaño]] ... ]

[FOR LOAD]

La cláusula FOR LOAD es usada específicamente cuando creamos una base de datos que será

cargada desde un backup. Usando esta cláusula, la inicialización de las paginas de datos durante la

creación de la base de datos no es hecha.


Cuando creamos una base de datos con la sentencia CREATE DATABASE, debemos considerar lo

siguiente:

Si el dispositivo de base de datos no es especificado, SQL Server colocará la base de datos

dentro de uno o más dispositivos por omisión.

El tamaño mínimo de una base de datos es 1 MB.

Las decisiones de distribución son importantes al momento ejecutar CREATE DATABASE; el

almacenamiento puede ser difícilmente regenerado después de haberlo asignado.

Para crear una base de datos puede utilizar SQL Server Enterprise Manager.

Ejemplos de la creación de bases de datos:

Ejemplo Función

CREATE DATABASE prueba Crea la base de datos prueba en el dispositivo de

base de datos por omisión, con el tamaño por

omisión de 2 MB (el tamaño de model)

CREATE DATABASE newprueba

ON default = 10

Crea la base de datos newprueba con un tamaño de

10 MB en el dispositivo de base de datos por

omisión.

CREATE DATABASE newdb

ON nwdata = 5

Crea la base de datos newdb con un tamaño de 5 MB

en el dispositivo de base de datos llamado nwdata

CREATE DATABASE librería

ON default = 3, nwdata = 7

Crea la base de datos librería, y distribuye 3 MB en

el dispositivo de base de datos por omisión, y 7 MB

en el dispositivo nwdata.

* Esto permite que la base de datos sea almacenada

en dos dispositivos.

CREATE DATABASE libre1

ON nwdata = 5

LOG ON nwdatalog = 2

Crea la base de datos libre1 y coloca 5 MB en el

dispositivo nwdata y distribuye 2 MB para el

transaction log en otro dispositivo llamado

nwdatalog.

Nota: generalmente el dispositivo por omisión es master, esto se puede cambiar.

Cambiando el tamaño de la Base de Datos.

El espacio utilizado por una base de datos puede ser incrementado utilizando la sentencia ALTER

DATABASE. Su sintaxis es:

ALTER DATABASE nombredb

[ON {DEFAULT | dispositivo} [= size]

[, dispositivo [= size]] ... ]

[FOR LOAD]

Cuando se altera una base de datos, debemos considerar lo siguiente:

El parámetro size, debe ser expresado en megabytes, es la cantidad de espacio distribuida para la

extensión (incremento) de la base de datos. La cantidad por omisión es 2 MB.

El mínimo tamaño que usted puede utilizar para alterar una base de datos es 1 MB.


Los permisos para utilizar ALTER DATABASE, son transferidos con los permisos de CREATE

TABLE.

FOR LOAD previene la utilización de la base de datos hasta después de haber cargado la base de

datos. Funciona sólo si la base de datos fue creada con esta opción.

Ejemplo:

ALTER DATABASE newdb

ON nwdata = 1

Este ejercicio incrementa la base de datos newdb en 1 MB.

Disminuyendo el tamaño de la base de datos.

DDBC SHRINKDB permite disminuir el tamaño de una base de datos; es totalmente logged y

recuperable. Solamente el SA y el DBO pueden ejecutar este comando. La base de datos resultante

no puede ser mas pequeña que el tamaño de model o el valor por omisión. Si se va a disminuir la

base de datos master, se debe respaldar la base de datos master primero antes de disminuir el

tamaño, debido a que este comando no mueve la información; puede remover completamente las

unidades de distribución vacías, comenzando desde el final de la base de datos.

Si ejecuta este comando sin especificar un nuevo tamaño, automáticamente asignará el tamaño

mínimo al cual la base de datos puede ser disminuida.

La sintaxis de este comando es:

DBCC SHRINKDB (nombredb [, nuevotamaño [, ‘MASTEROVERRIDE’]])

El comando contrae la base de datos al valor especificado en nuevotamaño. El nuevo valor debe ser

especificado en paginas de 2 K. Este comando podría disminuir tanto la porción de datos y el log de

la base de datos. Par cambiar el tamaño solamente de los datos o del log, primero disminuya la base

de datos entera y luego utilice el comando ALTER DATABASE para incrementar el tamaño de los

datos o del log de la base de datos.

Para disminuir una base de datos del usuario debe configurarse en modo single-user (monousuario).

Utilice el store procedure sp_dboption para realizar este proceso. Después de realizar la

configuración, es sugerible respaldar tanto el master como la base de datos que usted desea

disminuir antes de usar este comando.

Ejemplo, que disminuye el tamaño de la base de datos newdb a 8 MB:

DBCC SHRINKDB (newdb, 4096)

Opciones de configuración para las bases de datos.

Las opciones de configuración de una base de datos son manejadas a través del store procedure

sp_dboption. Estas opciones son:


Opción Descripción

ANSI null default Permite al usuario controlar el valor de nulabilidad por

omisión de la base de datos (NOT NULL o NULL)

Dbo use only Configura la base de datos para ser usada solamente por el

propietario de la misma.

No chkpt on recovery Define donde o no un checkpoint de registro es añadido a la

base de datos después de que es recuperada durante un inicio

de SQL Server.

Offline Usado para medios removibles. Permite a una base de datos

ser colocada en linea

Published Permite a la base de datos ser publicada para Replicación.

Read only Define a una base de datos como solo de lectura.

Select into/bulkcopy Define a una base de datos como solo de lectura.

Single user Restringe el acceso de la base de datos a un solo usuario.

Subscribed Permite a la base de datos subscribirse para Replicación

Trunc. Log on chkpt Causa al transaction log ser truncado (las transacciones

committed son removidas) cada vez que el procso

CHECKPOINT ocurre (usualmente una vez por minuto).

Para visualizar la lista de opciones disponibles para las bases de datos, ejecute sp_dboption sin

parametros. Para listar todas las configuraciones de una base de datos en particular, ejecuta el store

procedure sp_helpdb.

Base de Datos Materia

Documents

Transcript of Base de Datos Materia